Инженер и Менеджер

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

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

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

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

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

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

Salve, patricii!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Барабан, Веревка, Буфер в 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 и рисую: вот эти парни отдают задачи вот сюда, а они ждут, а потом отдают этим... Получается схема, которую уже можно использовать для поиска Гоши. Лучший способ -- это смотреть на количество задач, которые прошли сквозь части системы и которые копятся на ее участках. Когда найдете Гошу, поставьте его во главу системы, оптимизируйте его работу и сделайте так, чтобы ему ничто не мешало.

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

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

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

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

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

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

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

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

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

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

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

Пример: вспомните случай, когда вы ждали выполнения задачи несколько дней, хотя сама задача была всего лишь на 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

#management #strategy

Что такое стратегия
В этом посте начнем говорить о стратегиях. Я недавно услышал о фразу "у человека нет стратегического видения". Когда я спросил, что автор фразы имеет в виду, я услышал нечто вроде: "Ну, он не думает наперед". Так вот, думать наперед — это не стратегическое видение и уж тем более не стратегия.

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

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

- Диагноз — подробное описание сути проблемы, ее последствий, обстоятельств и ограничений. Ваше суждение о фактах, которые у вас на руках. Хороший диагноз упрощает плеяду фактов до простой формулировки, которая указывает на самые важные аспекты.
- Установки — правила, по которым вы собираетесь играть в рамках стратегии.
- Действия — набор четких, связанных и достижимых задач. Сформулированных, например, по SMART.

Давайте разберемся на примере. Я делаю PaaS (Platform as a Service) — продукт от программистов для программистов. Год назад я понял, что платформу воспринимают как запрещающий орган, который всем мешает жить. Это шло вразрез с моим видением платформы, но как это исправить?

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

Диагноз: разработка воспринимает платформу не как помощника, а как оппонента (и это в лучшем случае!).
Установки:
- Платформа — продукт для разработчика и она должна делать разработчикам приятно.
- Каждый клиент платформы должен иметь возможность внести свое предложение по улучшению или изменению платформы.
- Оценка платформы нашими разработчиками важнее нашей собственной.
Действия:
- Провести NPS опрос в течение недели.
- Создать механику Wishlist'а, куда любой разработчик может прийти с предложением по изменению или улучшению в течение спринта.
- Создать еженедельный созвон, где лиды платформы будут проходиться по вишлисту и статусу задач в нем в течение спринта.
- Поставить созвоны с рандомными разработчиками и собрать их боль в течение месяца.
- Провести еще один NPS через квартал.

Мы сделали все действия и NPS опрос показал +30% прироста. Механика вишлиста и еженедельных созвонов по вишлисту осталась с нами и по сей день. Это — стратегия и ее применение. Попробуйте составить подобную для своих задач и посмотрите, насколько сильно в гору пойдут дела.

#management #structure
Чем больше людей, тем больше хаоса в командах. Если компания растет по штату, но не перестраивает свою структуру, она обречена на сложности в коммуникации, функционал без владельцев и другие прелести дизорганизации.

Team Topologies — один из путей организации коллектива от 50-ти человек. Нужно разбить всю ИТ дирекцию на четыре подразделения:

- Stream-Aligned Teams (SAT) — кросс-функциональные команды продуктовой разработки, которые несут ценность клиентам. Например, пилят сервис доставки или корзины заказов. Таких команд должно быть большинство, процентов 60-80.
- Platform Teams — предоставляют SAT удобные и простые инструменты. Например, платформа строит CI/CD, дает возможность канареечных релизов, базовый мониторинг и упрощает работу с Кафкой. Если коротко: платформенная команда должна делать SAT приятно, а больше платформенная команда ничего не должна. В моей практике, на 10 человек в командах SAT нужно нанимать одного платформенного чувака.
- Enabling Teams — команды внедрения. Определение тут дать сложно, поэтому сразу пример: я руковожу платформой и мы сделали возможность канареечных релизов. Команды внедрения идут в проекты и помогают перевести сервисы на канареечные релизы. По размеру смотрите сами: я бы рекомендовал не больше платформенной команды.
- Complicated-Subsystem Teams (CST) — строит сложные системы и подсистемы. Например, аутентификация/авторизация на уровне всей компании или сервисы массовой рассылки. По количеству опять же смотрите сами: сколько у вас сложных подсистем и сколько на них нужно разработчиков.

Идея такого разделения в том, что Stream-Aligned чуваки доставляют ценность, а остальные им помогают и убирают преграды на их пути. При таком разделении продуктовые команды не отправляются пилить сервис рассылки СМС, за них это сделают CST.

Плюсы Team Topologies:
- Ускоряет доставку ценности: люди не путаются друг у друга под ногами, а работают в четких зонах ответственности
- Стабилизирует систему. Например, CI/CD часто являются общей болью. Если же вы выделите платформенную команду, у CI/CD появится владелец, ответственный за стабильную работу.
- Снижает бас-фактор. Помню, в одном из прошлых мест сервис по массовой рассылке делала продуктовая команда. Когда эта продуктовая команда встала и ушла, сервис тоже встал колом: как оказалось, без поддержки он не работает. В парадигме Team Topologies за такие проекты отвечает CST, которые обязаны шарить экспертизу внутри себя.

Минусы:
- Платформенная команда часто начинает думать, что она главная: платформа диктует свои условия и принуждает SAT к чему-либо. Повторю: главная цель платформы — обслуживать SAT и делать им приятно. Точка. Если так не сделать, платформа будет мешать поставке ценности.
- Появляется новый канал коммуникации и новая точка синхронизации. Например, раньше, если вам нужен был функционал в сервисе СМС, вы шли и делали. Теперь нужно заранее просить команды из CST.

Внизу — диаграмма для визуала.

#management #retention
Почему люди увольняются и как их удержать

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

В 2021-ом году ученые из малазийского университета провели исследование: какие факторы подталкивают человека к увольнению. Они собрали научные работы по теме увольнения и удержания, а потом свели причины в список. Вот он:

- Нехватка обратной связи — я видел команды, в которых люди ни разу не получали фидбек от руководителя, хорошо они делают свою работу или плохо.
- Недостаток обучения — сюда входит и обучение внутри компании, и покупка курсов извне, и обучение у коллег.
- Негатив на рабочем месте — слишком много конфликтов и/или подковерной борьбы, неравная оплата труда.
- Отсутствие доверия — излишний контроль убивает интерес к работе.
- Излишний стресс — если человек каждый день тушит пожары, он может пойти искать место поспокойнее.
- Слишком сложные задачи — иногда челленджа становится слишком много.
- Нет удовлетворения от работы — помните притчу про камни и храм? Это оно.
- Рабочее окружение — вот тут интересно. В английском "work environment" может значит и печеньки на рабочем месте, и правила поведения на рабочем месте. Вот подробности.
- Семейные проблемы — у меня есть пример, когда человека все устраивало, но они всей семьей переехали в другую страну.
- Низкая зарплата — да, из-за нее тоже уходят. Но не только из-за нее.
- Размер команды — люди в больших командах создают менее прочные горизонтальные связи, что плохо сказывается на социальном взаимодействии. Представьте: если вы общаетесь с коллегой раз в месяц, вряд ли вам будет так же комфортно, как если бы общались с ним каждый день.
- Из-за руководителя — не сработались, не сошлись характерами. Вспоминаю свою любимую поговорку: люди приходят в компанию, а уходят от менеджеров.

Мораль: если хотите удержать человека, помните про еще 11 (!) факторов помимо зарплаты, которые нужно прокачать. Займитесь обратной связью, убедитесь в его росте, проверьте задачи сотрудника, поинтересуйтесь как у него дела в нерабочее время. Не зарплатой единой удерживаем.

Ссылка на исследованиe

В дополнение к посту выше расскажу вам о гениальном применении Пока-Йоке. Правда, не в ИТ.

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

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

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

#longread #management #process #it
Что такое принцип Пока-Йоке и почему он вам нужен [6 минут]

Когда-то давно я работал в компании, чей продакшн сервер падал минимум по одному разу в неделю на пару часов. Иногда дольше — тогда мы отправляли гонца за энергетиком, а сами садились чинить до ночи, а то и до утра.

Я тогда был джуном и не совсем понимал, что происходит. Мои старшие коллеги старались писать код без ошибок, проверяли его перед отправкой в мастер и протыкивали руками функционал после деплоя на прод. Но мы все равно падали. Что-то шло не так, но что именно?

Тойота и принцип нулевых ошибок
Японцы из Тойоты еще в 60-ых годах очень хотели сделать свои автомобили качественнее и надежнее. Им нужно было побеждать США в борьбе за авторынок, а высокая надежность могла бы стать ценным преимуществом. Но на заводах Тойоты все еще работали живые люди, которые были обречены совершать ошибки. Чтобы обойти американцев, нужно было придумать что-то новое.

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

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

Как я использую Пока-Йоке в ИТ
Парни из истории в начале статьи про Пока-Йоке не знали и стремились не совершать ошибок, вместо того чтобы построить систему, которая не даст их совершить. Самый базовый пример: написать авто-тесты, но Пока-Йоке в ИТ применяется гораздо шире:
- Паттерн Circuit Breaker. У одного из наших партнеров висли сервера через день. Серваки отвечали не 400, не 500, а просто висли и отключались по таймауту. Трафика между нашими системами шло много (больше 1000 rps), так что зависание ТАКОГО количества тредов в таймауте приводило к деградации части системы. Тогда мы завезли Circuit Breaker, который теперь выключает все коннекты до партнера как тольк он виснет.
- Проверка обратной совместимости контрактов. Наши сервисы несколько раз падали из-за того, что один сервис обновил свой контракт и сломал второй сервис, который не может работать с новым контрактом. Мы встроили в наш CI/CD проверки, которые не дадут запушить контракты со сломанной обратной совместимостью. Программист может ошибиться, а наш CI/CD не может.
- Метрики и алерты из коробки. Все знают, что надо писать метрики и алерты на каждый сервис. А вот пишут — не все. У себя в компании я внедрил базовые метрики и алерты в каждый сервис, так что если кто-то выжрал весь CPU или течет по памяти, я про это узнаю.

Это только то, что влезло в пост :) На самом деле примеров гораздо больше.

tl;dr
Не пытайтесь не делать ошибок вообще. Создайте систему, которая не даст совершить ошибку вашим разработчикам. Если не получается, сделайте эту ошибку видимой. Например, напишите громкий алерт.

Ссылки
- [RU][Книга] Дао Тойота — если интересно, как Тойота стала такой крутой и вынесла весь автопром
- [RU] Подробная статья про Пока-Йоке
- [RU] Про паттерн Circuit Breaker
- [RU] Моя статья на Хабре об ошибках в разработке микросервисов

Что будет, если из программиста сделать менеджера? Получится Engineering Manager — такой может и код написать, и Кафку починить, и из едва знакомых людей сделать крепкую команду.

Меня зовут Олег Федоткин и я Engineering Manager. В своем бложике я буду писать про:
- Менеджмент технической команды: как сделать так, чтобы ваши команды делали работу в срок и были счастливы.
- Архитектура (микро)сервисов: как не построить распределенный монолит и не скатиться в Big Ball of Mud.
- Инфраструктура: как победить кубер, зачем вам нужен service mesh и как развернуть 11 кластеров Postgres и выжить.

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

Будет интересно :)

Channel photo updated