Привет! Меня давно не было на связи, но я приготовил для вас нечто уникальное: серию мини-статей про стиль управления руководителей прошлого. Я уверен, что у Черчилля, Наполеона, Цезаря и Хидэеси есть, чему поучиться. Первая серия будет посвящена Тойотоми Хидэеси — крестьянину, который стал правителем всей Японии и объединил ее под своей властью после столетних войн. Ни до, ни после никому не удалось подняться из крестьян в правители всей страны.

Тойотоми родился в 1536 году в семье обычного крестьянина-солдата. В Японии тех времен крестьяне часто выступали в роли солдат: страна воевала часто, а держать большую профессиональную армию было дорого. Максимум, на который мог рассчитывать Хидэеси — это стать прислугой какого-нибудь знатного человека. Это и случилось: Хидэеси занял должность носителя тапочек у Оды Нобунаги.

Носитель тапочек — это не преувеличение. Будущий правитель всей Японии начинал с того, что носил тапочки не самого знатного самурая. Что нужно было сделать, чтобы хотя бы начать движение по карьерной лестнице? Сейчас расскажу :)

Посты будут выходить раз в день; комменты открыты. Дайте знать, если такое вам заходит.

Предвосхищайте и превосходите ожидания

Хидэеси не планировал носить тапочки до самой старости. Чтобы начать движение по карьерной лестнице, ему нужно было выделиться из таких же слуг, как и он сам.

Первым делом Хидэеси отказался от места в доме, где жила прислуга. Вместо этого будущий правитель Японии расстелил свою циновку в пристройке рядом с главными воротами. Жить и спать там было ужасно неудобно, но жертва того стоила. Хидэеси мог предугадать намерения руководителя еще до того, как тот их явно выскажет.

Например, когда в поместье случился пожар, Хидэеси проснулся одним из первых и успел подать Нобунаге коня, пока остальные работники только просыпались. Нобунага не успел даже отдать приказ: Хидэеси выполнил задачу еще до того, как руководитель о ней задумался.

В другой раз Нобунага отправился с небольшим отрядом, чтобы напасть на передовой лагерь противника. Когда Нобунага выезжал из ворот замка, Хидэеси уже ждал его верхом — хотя это вообще не входило в его обязанности. Тойтоми всегда делал больше, чем от него ожидали. Иногда Нобунага решал выбраться на соколиную охоту, и Хидэеси вновь был тут как тут. Скоро князь осознал, что без своего нового слуги он как без рук, ведь тот всегда оказывался в нужном месте и делал больше, чем от него ожидали.

В одну зиму Хидэеси заметил, что на дрова тратятся слишком большие деньги. Он сам провел ревизию, пообщался с Главным-По-Дровам (в те времена была и такая должность), а потом сторговал у ближайших деревень сухие деревья в обмен на свежие саженцы. Ода Нобунага узнал об этом лишь из новых отчетов о расходах своего замка. Будущий правитель Японии увидел потребность, закрыл ее и занялся следующими задачами.

За 500 лет с того момента мало что поменялось. Все так же ценятся люди, которые видят потребность компании раньше, чем топы ее осмыслят и спустят вниз в виде задач. Еще ценнее те, кто берет инициативу на себя и закрывает эти потребности.

Распознайте ожидания и превзойдите их — вот первый совет, который вам бы дал Тойотоми Хидэеси.

Побеждает команда, а не индивиды

Князь Нобунага (это руководитель нашего героя, Тойотоми) взял на службу известного мастера копья, самурая по имени Мондо. Как-то раз на празднике у Мондо спросили: какое копье лучше, длинное или короткое? Мондо пустился в долгие рассуждения, в результате которых заявил: короткое копье лучше.

Но князь Нобунага предпочитал копье длинное. Тойотоми это знал и немедленно возразил: длинное лучше! Между Тойотоми и Мондо завязался спор, который можно было решить только на практике.

Мондо и Тойотоми получали по 50 солдат, вооруженных короткими и длинными копьями соответственно. У них обоих было три дня, чтобы обучить солдат. На четвертый группы сойдутся в учебном бою, чтобы выяснить, какое копье лучше.

Тойотоми приуныл, ведь он не был воином и копье держал редко. Он был обречен проиграть спор!.. По крайней мере, так он решил поначалу. А потом он собрал своих подопечных в своем шатре и приказал принести несколько бочек сакэ и закусок.

Пока подопечные Мондо тренировались на плацу, солдаты Тойотоми надирались в шатре халявным бухлом, обменивались историями из жизни и вообще проводили типичный алко-тимбилдинг. В результате, в конце первого дня группа Мондо не знала как зовут своих товарищей, а в группе Тойотоми уже появились зачатки доверия.

На следующее утро Мондо продолжил гонять своих солдат, обучая их выпадам, защите и хитростям короткого копья. Солдаты Тойотоми же учились маневрировать вместе и действовать как единое целое.

Мондо учил каждого солдата управляться с копьем. Тойотоми учил их, как быть командой. Мондо получил пять десятков хороших копейщиков, но Тойотоми получил хороший отряд.

На четвертый день отряд Тойотоми наголову разбил отряд Мондо. Персональные навыки уступили слаженным действиям и выученному плану баталии. Мондо был вне себя от ярости, а Тойотоми добавил в свою копилку еще одну победа интеллекта над силой.

Вот урок, которому учит нас Тойотоми: слаженная команда побеждает группу индивидуммов, даже если уступает этой группе в персональных навыках.

Доверие нужно завоевать

Продолжаем цикл про самурая без меча, Тойотоми Хидэеси.

В нашем мире фраза "он мне не доверяет" произносится осуждающе. Мол, какой плохой человек, отказывается мне доверять! Вариантов этой фразы много:
- Сотрудники мне не доверяют
- Коллеги мне не доверяют
- Руководитель не доверяет мне важное задание

Вы и сами такое не раз слышали. Но позиция "мне не доверяют" ставит человека в положение жертвы, как будто бы доверие зависит только от другой стороны. Тойотоми считал, что доверие это большой подарок и его нужно заслужить делами.

Как-то раз Тойотоми договорился с командиром крепости по имени Сайто о сдаче укреплений. Самурай Сайто оставлял за собой крепость и земли вокруг, но присягал на верность хозяину Тойотоми — Ода Нобунаге. Сайто согласился.

Когда Тойотоми прибыл обратно в свой лагерь вместе с Сайто, Ода не разделил милосердие своего слуги. Нобунага вообще был очень горяч в подобных вопросах. В тот раз Нобунага приказал убить Сайто. Логика была простая: крепость сдана, Сайто беззащитен, зачем оставлять живым опасного врага?

Однако, Тойотоми не мог выполнить приказ убить человека, который ему доверился. Кроме того, такой поступок очернил бы репутацию самого Тойотоми. На следующих переговорах и сдаче другой крепости этот факт станет весомым аргументом против.

Тойотоми сделал невероятное. Он пришел к Сайто и предложил ему свои мечи — сам Сайто находился в лагере без оружия. Вместе с мечами Тойотоми рассказал пленнику, как сбежать из лагеря. Сайто сбежал, а Тойотоми едва не лишился головы за такое: как я уже сказал, Нобунага был скор на расправу.

В тот раз все обошлось и сыграло на руку. Тойотоми не только не испортил свою репутацию, но и приобрел славу человека, слово которого непоколебимо ни при каких условиях.

Доверие — главный капитал в отношениях с другими людьми. Стремитесь завоевать его любой ценой и никогда не теряйте — вот совет, который дает нам Тойотоми.

Всем привет! Давно меня не было, исправляюсь — у меня для вас абсолютно уникальный контент с доступом исключительно по ссылку!

Вот он: https://www.youtube.com/watch?v=8mwJJvdqjLs&ab_channel=TechLeadChannel. Это мое выступление на TechLead 2022. Вот примерный план:
- История распада одной команды
- Как оценить размер техдолга
- Как неконтролируемый техдолг может погубить вашу команду
- Как правильно считать и платить техдолг

А бонусом на 16-ой минуте доклада будет про львов, зебр, дорожные пробки, пролитый кофе, опыты над крысами и мемас из Darkest Dungeon. Если уж это не заменит сериальчик вечером понедельника, то я даже уже и не знаю.

Без вопросов на скорости х1 идет 30 минут.

Время Ожидания Выполнения
В видосе я про это рассказываю, но у меня есть ощущение, что текст не помешает. Слишком неочевидная тема.

Главная мысль: если вы хотите, чтобы разработчик перестал справляться с работой, загрузите его фичами до отказа. Чем больше у человека задач, тем хуже он справляется с работой.

Пример: вспомните случай, когда вы ждали выполнения задачи несколько дней, хотя сама задача была всего лишь на 30 минут. К примеру, ваша заявка на доступ к ресурсу ждет неделями и затягивает свежий релиз. Если такое было -- читайте дальше, я расскажу, почему.

Представим график. На оси X у нас будет процент рабочего времени работника, а на оси Y -- время простоя. Допустим, Никита работает 50% времени, а 50% отдыхает. Время Ожидания Выполнения считается по формуле busy / idle. Для Никиты это 0.5 / 0.5 == 1. Запомним.

Но вообще-то 50% отдыха -- это многовато. Другой сотрудник Вася (синий) работает 80%, а 20% отдыхает. Для него ВОВ равен 0.8 / 0.2 == 4.

Попробуем загрузить еще одного человека, Виктора (фиолетовый), на 95% и получим ВОВ 19. А ведь я еще видел менеджеров, которые стремятся к загрузке 99% и ВОВ такого сотрудника будет равен 99.

Все эти цифры ВОВ не значат ничего: важно сравнение. Разница в ВОВ показывает, насколько дольше задача будет ждать своего исполнителя. Так, если вы отдадите задачу Никите (рыжий) он возьмет ее в работу в среднем через одну условную единицу. Давайте предположим, что это час -- но это может быть и день, и стори поинт. Если же мы отдадим задачу Васе (синий) -- то задача будет ждать в четыре раза дольше. Чем больше ВОВ, тем медленнее делается работа.

Отсюда вывод: если вы хотите, чтобы ваша система работала, вам необходимо оставлять людям свободное время, хотя бы 10% в условном спринте. Как это время выделить и что с ним делать я обязательно расскажу, но -- потом.

P.S. Изначальная идея принадлежит Элияху Голдратту, книжка "Цель". Или "Проект Феникс", если хочется более про IT.

Барабан, Веревка, Буфер
Представьте: вы идете в поход. В вашем отряде человек 10, все с разной степенью физической подготовки. Одного из членов отряда зовут Гоша, и у него все очень плохо с подготовкой: Гоша быстро выдыхается, медленно ходит и у него постоянно развязываются шнурки.

Отряд идет через лес по узкой тропе, так что идти приходится друг за другом. Вопрос: в какое место цепочки лучше поставить Гошу?

Можно поставить в конец. Но тогда Гоша отстанет от отряда и потеряется, а вы будете его искать до вечера.

Можно поставить куда-нибудь в середину. Тогда часть отряда перед Гошей быстро оторвется от вас, а часть отряда за Гошей отстанет. Те, кто оторвался, будут регулярно делать остановки и ждать тех, кто отстает.

Можно поставить Гошу идти первым. Тогда кажется что никто не потеряется и все будут двигаться плюс-минус с одной скоростью. Задача решена!

А теперь новая вводная: пусть Гоша будет идти в случайном месте нашей цепочки. Задача -- придумать такую механику, чтобы отряд двигался максимально быстро.

Элиаху Голдратт предложил такое решение:
1. Выдать Гоше барабан, чтобы именно Гоша диктовал остальному отряду темп ходьбы.
2. Привязь к поясу каждого члена отряда веревку, чтобы исключить возможность слишком быстрых ходаков убежать далеко. Максимум, на который член отряда сможет оторваться -- это длина его веревки.
3. Создать буфер между членами отряда.

С барабаном и веревкой вроде все понятно. А буфер зачем? Ну например: Гоша остановился перевязать шнурок. Если люди за ним идут буквально по пятам, им тоже придется остановиться.

Окей. Мы разобрались, как оптимизировать отряд людей, которые решили пойти в поход. Давайте теперь перенесем это на нашу повседневную работу.

Барабан, Веревка, Буфер в IT
Я работал с кросс-функциональными командами: разрабы, DevOps, QA, дизайнеры -- все в одной команде и работают над одними задачами. Когда менеджера спрашивают, как повысить эффективность такой команды, он отвечает: пусть все работают на свой максимум!

Но это так не работает. Точнее: это вообще не так работает.

Мой ответ: сначала найдите Гошу. Представим: в команде есть только 5 разрабов и 3 QA. Все задачи должны пройти тестирование. Каждый разраб делает по 3 задачи в день, итого -- 15 задач в день со всех. Каждый QA тестирует 4 задачи в день, итого -- 12 на всех. Если вы заставите разрабов делать по 16, 17 или даже 20 задач в день, пропускную способность системы вы не измените. Ваша команда все равно будет делать по 12 задач в день.

Барабан здесь нужно выдать именно QA. Перед ними же нужно организовать буффер: у QA всегда должен быть запас для тестирования, даже если все разрабы ушли в отпуск. Веревкой же в IT будет WIP-лимит, чтобы каждый отдел и каждый человек не набирали на себя слишком много задач. Про WIP-лимит я еще отдельно напишу.

В вашей команде или отделе найти Гошу будет не так легко. Кроме разрабов и QA есть еще тонна людей, которые влияют на процесс: DevOps, DevSecOps, дизайнеры, продакты, аналитики, проджекты, архитекторы -- их правда очень много. Да и сама работа это не просто делать задачи: вашим Гошей вполне могут стать ваши DevOps, которые катят задачи по три дня.

Я начинаю поиск Гоши (вообще-то правильно это называется "бутылочное горлышко") с помощью визуала. Беру листочек А4 и рисую: вот эти парни отдают задачи вот сюда, а они ждут, а потом отдают этим... Получается схема, которую уже можно использовать для поиска Гоши. Лучший способ -- это смотреть на количество задач, которые прошли сквозь части системы и которые копятся на ее участках. Когда найдете Гошу, поставьте его во главу системы, оптимизируйте его работу и сделайте так, чтобы ему ничто не мешало.

О важности контекста
Внимательно посмотрите на картину. Это кусочек полотна Босха, называется "Сад райских наслаждений". Недавно в Москве была выставка Босха, и я залип возле этой картины где-то минут на двадцать: рассматривал со всех сторон, пытался понять, что автор вложил в картину.

Для меня все было очевидно: хитиновый фонтан это либо источник жизни, либо источник знания. Сова внутри фонтана -- символ мудрости. Стало быть, мы видим метафору на мирскую суету, в тени которой скрывается мудрость.

Но ведь Босх жил 500 лет назад. Тогда совы ассоциировались с еретиками, потому что отвергали свет и охотились ночью. В те времена сова считалась символом коварства, предательства и шарлатанства. Босх помещает сов почти на все свои произведения, чтобы подчеркнуть негатив или злые намерения.

Маленький кусок контекста перевернул смысл картины с ног на голову. Теперь мы понимаем, что на самом деле Босх изобразил изначальную порочность людей, когда поместил символ греха внутрь фонтана жизни.

В менеджменте и разработке контекст еще важнее. Например, менеджер жалуется, что разработчик медленно делает задачи. Можно сразу рубануть с плеча, а можно разобраться в причинах и выяснить, что он гребет сразу от нескольких менеджеров, которые перегружают его работой.

Прежде чем делать выводы, постарайтесь расширить свой контекст. Неверный контекст рождает ошибочное представление, а оно ведет к плохим решениям.

Игра победителя
Давайте сегодня чуть-чуть отвлечемся от процессов, ИТ и всякого. Я вот люблю игры, особенно МОВА, особенно доту. Играю я редко, но постоянно замечаю нюанс: все члены моей команды пытаются победить... И из-за этого проигрывают. Да-да, именно так: люди проигрывают, потому что стараются выиграть. Я не сошел с ума: дайте мне буквально пару минут, и я все объясню.

Ученый Саймон Рамо проанализировал тысячи теннисных матчей игроков всех уровней, от начинающих до звезд. Саймон старался понять, почему одни игроки побеждают чаще других.

Открытие его поразило. Оказалось, что новички и любители играют в принципиально другой теннис. Если в профессиональном теннисе побеждает игрок, который забил больше мячей, то в играх классом ниже побеждает тот, кто меньше пропустил. Саймон пошел еще дальше и свел все к выводу: "В профессиональном теннисе 80% игр выигрываются, а в любительском те же 80% проигрываются."

Игрой победителя Саймон назвал те матчи, где исход решил игрок, который забил больше мячей. Матчи, где победителем стал тот, кто меньше пропустил, Саймон назвал игрой проигравшего.

И под конец еще один парадокс: чем больше любитель старается победить, тем больше он фокусируется на победных действиях и тем больше любительских ошибок допускает, ведь его внимание заключено в победных действиях. Если бы вместо этого он старался бы избегать ошибок, шансов победить у него бы прибавилось.

Аналогий с работой избежать не получится. Я часто вижу, как начинающие тимлиды, проджекты и продакты пытаются сыграть в игру победителя: отойти от лучших практик, закостылить свой фреймворк, срезать углы, которые лучше не срезать... Иными словами, я вижу, как игроки-любители играют в игру победителя и совершают ошибки, из-за чего срывают себе проекты.

В доте и любых онлайн играх все то же самое. Если вы не профи и не тратите 8 часов в день на теннис или доту, предпочтите игру проигравшего и минимизируйте количество ошибок. Так вы начнете побеждать чаще.

Если интересно прочитать подробнее, вот книга Саймона

Salve, patricii!

В блоге я уже говорил о стиле управлении Хидэеси, императора-крестьянина Японии. Сегодня мы перенесемся еще дальше во времени и начнем разговор об управлении в Римской Империи.

Нам поможет Марк Сидоний Фалкс — патриций, который написал трактат об управлении рабами. Нам повезло, что трактат выжил спустя две тысячи лет и был переведен плебеем Джерри Тонером — за что мы говорим ему спасибо и жалуем сотни серебряных сестерциев. Если надумаете его поддержать, приобретайте его книгу "Как управлять рабами".

Марк Сидоний Фалкс владел сотнями рабов, то есть управлял очень большой компанией. Коллектив был пестрый: все-таки, рабов в Империю поставляли со всех уголков Pax Romana. Вы увидите, что Марк вполне сносно относился к своим сотрудникам и рекомендовал остальным вести себя так же. Он задавался примерно теми же вопросами, что и текущие менеджеры: возможно, вас удивит, насколько они похожи на ваши собственные вопросы.

И не читайте эту серию постов на слишком уж серьезных щах. Abeamus!

Как выбрать раба
Давайте поговорим о римском найме. Точнее — о покупке раба.

Марк Сидоний Фалкс пишет, что вопрос покупки нельзя переоценить. Если ошибиться с рабом на стадии покупки, потом придется потратить в разы больше усилий, чтобы он вышел на нужный уровень производительности.

Прежде всего Марк отмечает, что покупка раба — само по себе не лучшее решение. Лучшие, самые лояльные рабы, получаются их тех, кто был рожден и выращен в доме владельца. Найм — то есть покупка — приходится к месту тогда, когда вырастить нет возможности. Люди ведь не растут на деревьях.

Марк поначалу не дает четких рекомендаций, каких рабов стоит приобретать. Вместо этого он рекомендует спросить себя вопрос: что ты собираешься построить? Если скульптор намеревается создать великое произведение, ему нужна подходящая глина. Для простенькой статуи сойдет глина подешевле. Так же и с рабами: для гладиатора или раба-спутника нужен совершенно особенный материал, а для сборщика винограда подойдет почти любой.

Потом Марк дает несколько простых советов:
- Заранее определите работу, которую будет выполнять раб. Исходя из его должности, составьте список требований и с ним идите на рынок.
- Избегайте грустных. Они заразят своим унынием весь коллектив, отчего упадет и дисциплина, и желание работать.
- Не покупайте рабов без нужды. В книге Марк приводит примеры рабов, которые были куплены напрасно, без четких целей. Такое расточительство вредит кошельку.
- Не покупайте рабов с общим бэкграундом, которые говорят на одном языке. Такие рабы будут тратить больше времени на разговоры, меньше — на работу. А если они достаточно подружатся, смогут решиться на совместный побег.

Вот и все советы, которые патриций дает в своем трактате. Лично я вижу в этом несколько пересечений с нашей реальностью. Если видите и вы, то добро пожаловать в комментарии!

Как добиться максимума от рабов
Salve, patricii! Я продолжаю рассказывать вам о римском менеджменте, и сегодня мы поговорим о повышении эффективности рабов. Но прежде, чем мы начнем, рекомендую прочитать комментарии к прошлому посту: тот случай, когда комментарий не уступает статье.

Применяйте грубую силу, наказывайте, запугивайте — от Марка Сидония я ждал любых советов. Все-таки, нравы в Древнем Риме были пожестче, чем наши с вами. Но вместо этой жести Марк первым делом советует: не забывайте о прянике! "Жестокость это палка о двух концах, и больнее всего она попадает по хозяину, а не рабу" пишет Марк. Он считает, что опытного управленца отличает понимание, что одним кнутом нельзя добиться успехов.

В первую очередь, раба нужно обучить. Марк Сидоний не утруждает себя объяснением процесса обучения, но из двух параграфов понятно: он имеет в виду онбординг. На этапе онбординга раба знакомят с будущей работой, коллективом, обязанностями и ответственностями.

Важно определить для раба четкую долгосрочную цель. Чаще всего для трудолюбие и усердность рабу с Древнем Риме даровали свободу: держать раба в неволе до его смерти считалось моветоном. За успехи в работе нужно давать выходные дни и улучшать бытовые условия раба. Марк Сидоний считал неприемлемой ситуацию, в которой раб-трудоголик и раб-бездельник живут в одних и тех же условиях и едят одну и ту же пищу.

Нужно определить для каждого раба его обязанности. За каждую работу отвечает определенный раб и он это знает. Если к вечеру трава будет не скошена, все знают, чья эта провинность. Если же скошена хорошо — чье достижение. Здесь Марк еще раз подчеркивает, что если раб трудится усердно, его труд не должен уходить в "общую копилку".

Рабов следует объединить в группы не слишком большие, но и не слишком маленькие. Если группа большая, ей будет сложно управлять, ответственность начнет размазываться. Идеальный размер группы — 5-10 человек. Такие группы нужно разбросать по всему имению и следить за тем, чтобы рабы не работали поодиночке или по два-три человека.

Марк считал, что у рабов должен быть и досуг. Ему была противна идея Катона, что раб должен лишь спать и работать. Марк был уверен, что хороший отдых вечером повышает эффективность труда днем.

Вдумайтесь: это советы рабовладельца! Поощрять рабов, давать им отдых, следить за выгоранием — в современном мире я знаю руководителей, которые лихо забивают на все эти нюансы и заставляют людей работать на износ. Поэтому впервые за серию я дам вам свой совет: если вы управляете коллективом менее гуманно, чем рабовладелец, вам пора задуматься о ваших решениях и подходах. Правда.

А на этом на сегодня у меня все. В следующий раз я расскажу, как Марк Сидоний Фалкс рекомендует выбирать управляющих из числа рабов. Если вам понравилось, то репост станет для меня самой приятной оценкой.

У Римской Империи не было недостатка в новых рабах. Плутарх пишет, что война Юлия Цезаря в Галлии принесла Риму один миллион новых рабов за восемь лет. Это 125 тысяч рабов каждый год только с одного театра военных действий, на деле их было больше. Современные ученые считают, что до 20% населения всей Империи были рабами.

Но соотношение пять граждан на одного раба не работало. В городской среде это соотношение было ниже, ведь в городах находилось больше граждан и меньше рабов. А в сельской местности, там, где возделывались поля и производилось всякое, соотношение менялось в пользу рабов. Бывало и так, что в имении кроме хозяйской семьи и рабов никто не проживал.

Если сложить эти два пункта, получается вот такое:
- Рабов в имениях было много
- Управленцев не хватало
- Эпизодически происходил бурный рост числа рабов.
Если заменить рабов на сотрудников, получается почти правильное определение гипер-роста: это время, когда компания вырастает в разы или даже в десятки раз.

Сейчас я расскажу, как Марк Сидоний Фалкс предлагал выживать во времена такого бурного роста.

Марк рекомендовал не искать управляющих на стороне. Конечно, управляющий из числа рабов ничего не стоил, но это не было решающим плюсом. Марк считал, что такой управляющий уже хорошо знает хозяйство, привык общаться с хозяином, выучил язык (подавляющее число рабов было не из Италии). Чтобы выбрать управляющего из числа рабов, Марк рекомендовал обращать внимание на следующее:
- Назначьте человека опытного, который давно работает в поле. В современных реалиях я бы сказал так: менеджер должен быть от станка. Я не верю в тимлидов разработки, которые не писали код. Я и в СТО не-программиста не очень верю. Марк вообще считает, что лучший способ для управляющего добиться авторитета -- это делать свою работу лучше всех.
- Никогда не назначайте раба, который "склонен тратить время впустую, гоняясь за городскими удовольствиями". Уже спорно для наших реалий, но Марк имел в виду склонность к вредным привычкам. Если утрировать, то не стоит нанимать человека, который потенциально может напороться во вторник днем и весь день быть не на связи.
- Слишком молодому рабу будет сложно командовать более взрослыми, потому что его не будут воспринимать всерьез. В современном мире все так: поставьте тимлида 20-ти лет в команду опытных дядек за 40 и убедитесь сами, что это плохая идея.

Для эффективной работы управляющего Марк рекомендовал:
- Не давайте управляющему жить или есть отдельно от коллектива. Цитата: "ничто так не раздражает усталого раба, как созерцание начальника работ, поглощающего вкусную еду, когда сам раб получил лишь скудный паек". Мысль глубокая, так что оставлю ее вам самим на размышление.
- Запрещайте управляющему покидать территорию имения. Кажется, что неприменимо к нашей с вами реальности, но нет -- еще как применимо. Замените "территорию имения" на "скоуп работ". Если человек берется за все сразу, это плохо.
- Внушите управляющему, что он знает совсем мало. Хороший управляющий постоянно учится. Забавно, но сейчас (последние N лет) все говорят о learning mindset, так вот Марк Сидоний Фалкс изобрел его две тысячи лет назад.
- Не пускайте в имение магов и волшебников. В современном мире волшебники -- это сомнительные практики, которые обещают повысить эффективность работы всего лишь за семь простых шагов. Или фреймворки, у которых три звезды на гитхабе.

А еще у меня для вас есть 2 (два!) бесплатных билета на https://podlodka.io/techcrew. Я там буду выступать, расскажу про пост мортемы, инцидент менеджмент и как вообще увидеть 99.95% на метрике доступности системы.

Чтобы принять участие в розыгрыше, нужно оставить коммент к этой записи. Вообще любой коммент, но если напишите отзыв о контенте, что нравится, чего не хватает, я буду очень рад :)

Двух победителей выберет рандом 14-го числа (пятница). Не реклама — Подлодка дает 2 билета спикеру, их мы и разыгрываем.

Билеты мы разыграли, но пятничный контент у меня для вас еще есть :) "Микросервисы: проблемы, которые мы не замечаем" — это 40 минут (+вопросы) полезной инфы о сервисах. В программе:
- Что такое контракты, где их хранить и как катить
- Как построить стейджи в распределенной системе
- Зачем нужен Circuit Breaker и Rate Limiter
- Бонусом небольшой заход в отказоустойчивость

И еще многое другое. Наверное, этот доклад съел у меня больше всего времени среди прочих.

https://www.youtube.com/watch?v=VtlS8ETYXvc&ab_channel=TechLeadChannel

Что делать, если дел стало слишком много

Привет всем, кто задолбался. Вы когда-нибудь ощущали совокупность этих прекрасных эмоций?
- Пока делаешь одну задачу, вспоминаешь про другую, третью, десятую — ощущение, что 24 часа в сутках слишком мало для твоей работы
- Новые задачи появляются быстрее, чем делаются старые
- Дедлайны горят, задачи не делаются
- Изо дня в день ситуация становится только хуже

Я в ней провел пару месяцев. Отсюда и пустота в этом блоге. В моем личном трекере запись "написать в блог статью" висела больше месяца и переносилась каждый вечер на следующий день, вместе с другими задачами.

Ужасное ощущение.

И это с учетом, что я выполнял все методики управления временем! Исправно вел и веду список своих задач, планирую день и неделю, не скроллю телеграм. Не помогает. Поэтому я решил, что нехватка времени и есть норма. И вообще, у какого-нибудь Безоса времени еще меньше.

Неделю назад мне попалась на глаза избитая временем фраза "если вы оказались в яме, первое, что вам нужно сделать — перестать копать". Меня осенило — это же про меня! Я в яме, факт. Ситуация становится хуже, значит, я продолжаю копать. Но что такое "копать" в моей ситуации?

Если вас завалило делами, копать — это соглашаться на новые дела. Этим я и занимался: когда кто-то просил помочь или что-то сделать, я с радостью соглашался, потому что я люблю помогать людям... Но вообще нет. Вот основные причины, почему мы любим отвечать "да":
- Говорить "да" просто приятнее и легче.
- Хотим выглядеть командными игроками. В корпоративной культуре это важно.
- Боимся не понравится. Говорить "нет" не так выгодно, если ты хочешь поддерживать хорошие отношения со всеми вокруг.
- Хотим попробовать что-то новое. Даже если ты загружен работой, возможность получить опыт работы с какой-нибудь новинкой может пересилить.
- Не понимаем масштаба задачи. Задача на пять минут легко оборачивается засадой на пару часов или весь день.
- Ищем социального одобрения. Желание быть для всех хорошим парнем и поддерживать горизонтальные связи ценится в коллективе.

Что делать? Начинать говорить нет. Будет непросто, поэтому вот пару советов:
- Не соглашаться ни на что сразу. Можно взять время на подумать, перезвонить или пообещать написать ответ позже. Не очень хороший способ, потому что если решил отказать, лучше отказать сразу. Быстрый отказ — проявление уважения к времени партнера.
- Не соглашаться, потому что хочется. Любое "да" должно вести человека к цели. Если "да" не приближает человека к целям, оно отодвигает от них.

tl; dr желание постоянно соглашаться и говорить "да" — токсичная штука, которая может похоронить вас в делах и задачах. Лучше говорите "нет". Вот хорошая статья из моих закладок на эту тему.

А статьи теперь вернутся обратно. Про рабов момент упущен, так что перейдем к следующей теме — моей любимой компании, которая делает лучшие процессы и лучшие машины.

Почему позитивный опыт не так важен

Я настороженно отношусь к чужим историям успеха. Не всегда из них можно извлечь что-то полезное. В худшем случае, попытка повторить чужую историю успеха может мне навредить.

Например, пусть Вася прочитал биографию Оззи Осборна -- он как раз такую написал, называется "Все, что мне удалось вспомнить". Вы можете подумать, теперь у Васи есть пошаговый рецепт, как стать рок-звездой. Но если Вася попытается по шагам повторить все действия Оззи Осборна, он не станет рок-звездой, это очевидно. Вероятнее, Вася просто откинет копыта от передоза: маэстро употреблял феноменальное количество веществ, запрещенных к обороту на территории РФ.

Мысль понятна: если повторить по шагам историю успеха Оззи, самому рок-звездой не стать. Это так не работает. Чужая история успеха не воспроизводится. Оззи жил в другое время, в другом месте, по телевизору шли другие новости, по дорогам ездили другие машины. Истории успеха часто зависят от контекста, а без контекста история успеха теряет воспроизводимость. Знание "как надо" сложно перенести на себя и свой контекст.

Если перенести эту идею на наше ИТ, получается вот что:
- Если у кого-то взлетел SCRUM и ему похорошело, это не значит, что вам нужен SCRUM
- Если кто-то перешел с PG на MongoDB, не факт, что вам оно надо
- Правила управления Netflix применимы только в рамках Netflix, если вы бездумно затащите их к себе, можете навредить
- И так далее

Мысли кажется очевидные, но почему-то попытки "построить иерархию как у Spotify" совершаются с поражающей частотой. И закономерно плохим итогом.

С другой стороны, есть истории провала. Их редко выставляют напоказ, о них не пишут книги и стараются побыстрее забыть. Но такие истории содержат в себе ошибки, которые и привели автора к провалу. Это и есть знание "как не надо". Оно менее зависимо от контекста, а потому более ценно.

Например, между докладами "как мы построили иерархию Spotify у себя в компании" и "как у нас не получилось построить модель Spotify" я выберу последний. Если докладчик расскажет про свои ошибки, то я не буду их повторять и повышу свои шансы на успех, если вдруг надумаю затащить модель Spotify к себе. А вот если я буду повторять чужую историю успеха без чужого контекста, то сам смогу выступить с докладом о факапе.

Итак: получить негативный опыт более ценно, чем получить позитивный опыт. Это не значит, что истории успеха вообще бесполезны. Это не так. Просто предпочтение я был отдавал опыту провалов.

А если вы захотите послушать про чужие факапы, регайтесь на нашу конфу Fuckup Meetup'22. 14-го Декабря мы соберемся оффлайн и онлайн и послушаем пять прекрасных историй про факапы :) Я буду ведущим, но если успею, тоже что-нибудь расскажу из последних факапов.

P.S. У нас на ютубе и запись с прошлого митапа есть. Вот мой рассказ про NASA, шаттлы и мистическое исчезновение всей базы данных утром субботы.

О компании, которая делает лучшие процессы
Пришло время рассказать вам про принципы управления лучшей компании на свете, которая делает лучшие на свете машины.

БМВ и Мерседес, сядьте, вам завтра в сервис. Я про Тойоту. Первый пост будет не про принципы управления, а про историю Тойоты.

В 1965-ом году Тойота пришла на американский рынок с новой Короной. Это такой маленький автомобильчик, по-японски компактный и бережливый. Думаю, с его двигателем в 1.2 литра, автомобиль мог ездить даже на парах бензина. Просто нюхнул 95-го и поехал.

В 60-70-х годах в США автомобильный двигатель начинался литров от 3-ех, и это еще была малолитражка! Настоящие ковбои катались на пятилитровых зверях, которые жрали по 25 литров на сто километров. Иначе как-то не солидно. Но Тойоту Корону покупать все же стали: в отличие от тогдашних поделий автопрома США, Тойота могла проехать 100к километров и не сломаться. Американский автопром ломался чаще и ремонтировался дороже. Этим Тойота и начала завоевывать США.

Завоевание США продолжалось бы еще десятки лет, если бы не топливный кризис 70-х годов. Цена за баррель подскочила с 10 баксов сначала до 40, а потом до 65. Строить тачки с большими моторами стало как-то невыгодно, а строить тачки с маленькими моторами Америка не умела. Тут-то Тойота (а так же Хонда, Ниссан и все-все-все) очень быстро начали съедать рынок США. Правда, вмешалось государство и ввело заградительные пошлины, чтобы родной автопром хоть как-то выжил. В итоге Тойота была вынуждена строить заводы в США и иными способами инвестировать в местный автопром. Да-да, свободный рынок выглядит именно так, а что вы хотели?

Но это все был приквел, чтобы у вас в голове появился вопрос: как страна, вбомбленная буквально в средние века в 45-ом году, смогла основать Тойоту? Между ядерными ударами и захватом автопрома США прошло меньше 20 лет!

Ответ: бережливое производство. Понятие очень широкое, но в следующих статьях я постараюсь раскрыть его пошире.

Интересно другое: принципы бережливого производства описал великий инженер и руководитель Тайити Оно в 1977 году в своей статье "Система Оно" на английском языке. Подчеркиваю, Тайити не изобрел, а лишь описал принципы Тойоты. Позже он и книгу про принципы Тойоты выпустит.

В 88-ом году Джон Крафчик выпускает статью "Триумф системы бережливого производства", после чего слово Lean и Lean Manufacturing вообще появляется как термин. Идеи Джона вторят идеям Тайити Оно и принципам Тойоты.

В 95-ом Сазерленд и Швабер на конференции презентуют Scrum -- новую методологию управления проектами. Пишутся книги, статьи, а в 2009-ом году появляется Scrum Guide. И сам Scrum, и Scrum Guide основаны на принципах бережливого производства.

Получается, что Scrum основан на Lean, а Lean -- на принципах Тойота, которые были заложены еще в конце 19-го века. Не имею ничего против, но на мой вкус, Scrum неправильно понимает часть принципов Тойоты, а другую часть он просто игнорирует. Яркий пример: ретроспектива, тесно увязанная с понятием "хансей", которого в европейской культуре просто нет. Про хансей будет целый отдельный пост.

Пока что у меня все. В следующих постах я расскажу вам о принципах Тойоты, с которых все началось и которыми все до сих пор продолжается. Без искажений.

Хансей
Первый принцип Тойоты это хансей. Все принципы, которые мы рассмотрим дальше, опираются на хансей. Поэтому нет смысла говорить о Тойоте, если сначала не понять смысл хансей.

Большинство книг или статей сразу заявят вам: хансей -- это рефлексия. Я скажу: нет. Хансей это не только и не столько рефлексия. Чтобы разобраться в истинном смысла слова, давайте начнем с его составляющих.

Что такое хансей
Слово "хансей" состоит из двух иероглифов: 反省.

反 (Хан) может означать противоположность, противопоставление, сомнение или отрицание. Но так же иероглиф может значит "отражать". Например, слово "反光 板" буквально означает "отражатель".

省 (Сей) имеет примерно дофига значений: сущ. провинция, глаголы оставлять или пропускать. Для нашего контекста подходит перевод "понимать" или "проверять себя".

Я перевожу хансей как "сомнение по поводу собственных действий и достижений". Хансей -- это постоянный поиск причин, которые привели к провалу или успеху. Конечно, я не переводчик и японский знаю очень условно, так что здесь на научную точность не претендую.

Почему хансей -- это не рефлексия
Первое и главное различие: рефлексия -- это разовое действие, процесс размышления над своими действиями из прошлого. Хансей -- это постоянный способ восприятия мира.

Второе: европейцы рефлексируют над провалом, но не над успехом. Даже уважаемый Рей Далио (миллиардед и автор книг про личный рост) пишет: "Успех -- это боль плюс рефлексия". Над победами у нас рефлексировать вроде не принято. Победителей не судят, говорим мы. Хансей предполагает рефлексию и над провалом, и над успехом.

Что значит хансей для Тойоты
Для Тойоты хансей это главный инструмент развития. После завершения задачи, исполнители собираются на встречу "хансей-кай", где обсудят свои действия и результаты. Цель встречи -- выяснить причины, которые привели к успеху или провалу. Если принятые решение были неудачными, их не следует повторять. Хорошие решения стоит запомнить и начать применять дальше, а в будущем, если они пройдут проверку временем, начать применять как стандарты.

Как вы можете практиковать хансей
Во-первых, задумайтесь, а надо ли оно вам. У японцев другой менталитет, у них хансей в школах преподают. Если вы начнете задумываться и даже сомневаться насчет своих достижений, может получиться не очень хорошо.

Если вы решили, что добавите хансей в свою жизнь, начните с себя. В конце дня уделите несколько минут, чтобы записать итоги дня. Что вы сделали хорошо, что вы сделали плохо, к чему все это привело и как в следующий раз сделать лучше. В идеале записать все ручкой или карандашом на бумаге, но и клавиатура сойдет.

tl;dr Каждый сотрудник Тойоты подвергает сомнениям любой успех и ищет причины любого провала, чтобы избежать его в будущем. Постоянное сомнение и поиск причин любого результата -- это и есть хансей.

_Генти Генбуцу
"Мы смотрим на процесс доставки ценности и убираем из него все, что не приносит ценности" -- цитата Тайити Оно, одного из мастодонтов Тойоты. Фраза очень похожа на высказывание Микеланджело. Великого скульптора спросили, как ему удается создавать свои шедевры? Он ответил: "Я беру камень и отсекаю все лишнее".

__Как определить лишнее
Несложно убрать из процесса лишнее. Сложно лишнее найти. В нашем любимом ИТ для поиска проблем мы используем метрики. Например, для Scrum спринтов можно следить за такими циферками:
- Сколько задач осталось открытыми после завершения спринта
- Сколько задач включили в спринт после старта спринта
- Сколько задач удалили из спринта
- И так далее, циферок можно придумать еще много

Если любая из трех метрик не равна нулю, значит процессы в команде неэффективны. Где-то затесалось лишнее, которое нужно немедленно искоренить. Это правда. Подвох кроется в другом: ни одна из цифр не сообщает нам, где находится неэффективность внутри процесса. Например, команда можем выбрасывать задачи в ходе из спринта из-за факторов:
- У продакта семь пятниц на неделе и он постоянно меняет планы и задачи
- Команда не успевает сделать все таски и скидывает балласт
- Неправильно распилили эпик на задачи, пришлось выкинуть старые
- И так далее

Значит, метрика только сигнализирует о проблеме, но не указывает прямо на нее.

__Как найти лишнее
Тут и включается генти генбуцу (現地現物). Давайте для начала переведем на русский.
現地 (генти) -- местный, локальный.
現物 (генбуцу) -- реальный, настоящий.

Дословный перевод генти генбуцу -- это "реальное место". То место, где нам нужно находиться, чтобы найти лишнее в своих процессах. Сейчас объясню.

Например, Тайити Оно узнавал о проблеме: один из участков конвейера стал выдавать больше брака, чем в прошлом месяца. Тогда Тайити Оно буквально рисовал круг на полу в цеху, рядом с проблемным участком. Небольшой круг, чтобы внутри него можно было стоять, но не гулять туда-обратно.

Внутрь круга Тайити своего подчиненного и поручал следить за участком в течение нескольких часов. Человек наблюдал производственный процесс, действия рабочих и результат каждого действия. Спустя несколько часов, у него появлялось представление о реальном положении дел на участке линии. Не домыслы или предположения, а факты.

На основании собранных фактов Тайити Оно с командой принимал решения и исправлял проблему.

__Как использовать генти генбуцу в ИТ
Вернемся к примеру выше, про выброшенные из спринта задачи. Неопытный менеджер примет решение сразу же, без похода "на производство". Это неправильно. Настоящий менеджер должен начать ходить на дейли синки команд, на их PBR (или груминги), возможно устроить skip-the-level встречи. Это и есть генти генбуцу. Это путь к решению настоящей проблемы.