An Elegant Puzzle: Systems of Engineering Management

Отличная книга. Советую всем, кто имеет отношение к работе с инженерными командами.
Блог автора: https://lethain.com/

Команды

• Менеджеру должно репортить от шести до восьми человек. Если менеджеру репортит больше девяти человек — он больше тренер, а не менеджер: просто даёт советы и подстраховывает, но не управляет.
• Команды меньше четырёх человек — не команды. Команды из одного-двух человек — всегда плохо. Смысл в том, что команда абстрагирует сложность людей, из которых она состоит. Команды из одного-двух человек — это «дырявые абстракции», управление ими не отличается от работы с конкретными людьми. Также они хрупкие, уход одного человека сильно нарушает равновесие.
• Если нужно создать новую команду, лучше вырастить текущую до восьми-десяти человек и разделить её на две. Создавать пустые команды — нехорошо.
• Оптимальное количество менеджеров на руководителя менеджеров—от четырёх до шести

Четыре стадии команды и что делать на каждой из стадий:

• Команда явно не справляется: каждую неделю беклог длиннее, чем в предыдущую, инженеры вкалывают, прогресса почти нет → нанять людей, пока команда не начнёт топтаться на месте.
• Команда топчется на месте: команда выполняет основную задачу, но не может приступить к починке техдолга или начинать новые большие проекты → урезаем Work In Progress, чтобы команда могла быстрее закончить приоритетные задачи и приступить к техдолгу; помогаем инженерам мыслить в терминах продуктивности команды.
• Платит техдолг: когда начинаешь платить техдолг, попадаешь в снежный ком: чем больше техдолга чинишь, тем больше техдолга вылезает 🙂 → терпим и увеличиваем время.
• Фигачит инновации: Всё классно: энтропия на низком уровне, мораль высокая, команда на всех парах фигачит ценность для клиентов → не перегружать команду, чтобы новые проекты делались с достаточным уровнем качества и можно было оттянуть момент оплаты техдолга.

Хорошая сработанная команда — залог высокой продуктивности

Если разобрать команду, даже сохранив частично её членов, то это всегда потеря продуктивности. Командам надо много времени, чтобы сработаться. Это надо учитывать при росте команды или изменении её состава. Нанимайте в один момент времени в одну команду! Добавление нового члена команды запускает процесс regelling [притирку, склейку, буду использовать оригинальный термин] членов команды, поэтому нанимайте последовательно в команду за командой, не параллельно в несколько команд!

Если нужно переключить фокус команды на другой проект—меняйте скоуп [набор задач] команды и старайтесь не переводить людей в другие команды, так как это запускает процес regelling’а.

Если ваш бизнес удваивается каждые шесть месяцев и вы хотите удваивать количество инженеров раз в шесть месяцев, тогда важно помнить, что производительность инженера будет значительно меньше 1 (одного) обученного инженера:

• допустим, опытный инженер обучает двух неопытных. На обучение уходит 10 часов в неделю на одного обучаемого эти три инженера вместе выдают 1,16 обученных инженеров: 20,33+10,5;
• около 4х часов в неделю уходит у опытных инженеров на найм производительность опытного падает 0,5 > 0,4;
• на каждый новый порядок количества инженеров вам нужно добавлять +1 слой менеджмента;
• на 10 инженеров нужна новая команда и больше коммуникации;
• девопсы должны приносить пользу, не просто быть;
• больше разработчиков—больше отказов, разборов, постмортемов;
• на выходе, производительность опытного инженера падает до 0,275

Как проводить миграции на новую технологию/переписанную в процессе уплаты техдолга:

• снижаем риски: итеративно пишем документацию переезда, затем переводим две самые требовательные команды на новую технологию. Плотно работаем с ними, чтобы полечить все корнер-кейсы;
• переводим основную массу: пишем документацию и self-service инструменты, чтобы программно мигрировать 90% процессов и команд на новую технологию. Сидим с каждой командой и помогаем им мигрировать. Переходим к следующей команде;
• заканчиваем миграцию: останавливаем кровь: убеждаемся, что 100% команд и процессов перешли на новую технологию. Своими руками мигрируем оставшихся. Выключаем старую технологию.

Стратегия

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

• Диагноз описывает саму проблему, вызов, который перед нами стоит, текущую ситуацию и её ограничения.
• Принципы: набор правил, которыми мы следуем, чтобы решить проблему. Хорошие принципы — некомфортные, заставляют чему-то сказать «нет», часто являются компромиссами между противоречащими целями.
• Действия: появляются после применения принципов к диагнозу. Часто тяжёлые абстрактные решения принимаются легко, но никогда не вытекают в конкретные действия. Поэтому действия должны быть конкретные. Такие, чтобы тоже было достаточно некомфортно им следовать (если проблема сложная).
• Абсолютно нормально иметь несколько стратегий — по одной на каждую проблему.

Видение

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

Хорошее видение состоит из следующих частей:

• Главное утверждение. Одно-два вдохновляющих предложений, которые описывают всю суть документа. Это главная мысль, которую нужно повторять везде снова и снова;
• Ценность для пользователя. В чём будет наша ценность для пользователя? В чём будет его успех, который мы поможем ему достичь?
• Наши возможности. Что продукту нужно уметь делать, чтобы пользователи смогли получить эту ценность и достичь этого успеха?
• Ограничения. Какие у нас сейчас есть ограничения, но от которых мы избавимся в будущем? Какие у нас возникнут ограничения в будущем?
• Ссылки на остальные документы: метрики, таблицы, планы и так далее. Это всё в дополнение, чтобы не усложнять основной документ.
• История: когда все предыдущие штуки написаны, надо связать их суть в короткую историю. Вставить эту историю после главного утверждения.

Хорошее видение требует нескольких итераций и тестирования на людях. Один-два раза в год видение надо обновлять.

Продуктовый подход

Есть четыре стадии в работе над каким-то изменением:

• Обнаружение проблем. Боли пользователей (опросы и интервью), цели пользователей (куда они хотят прийти?), сравнение с конкурентами и индустрией (чтобы понимать свои слабости и сильные стороны), сравнение поведения своих же когорт (чтобы посмотреть, нет ли новых пользователей с другими нуждами), обнаружение своих competitive moats (какие есть и что это даёт, какие можно построить, какие есть у конкурентов), что можно построить, что даст пользу сейчас, но также будет фундаментом больших хороших штук в будущем.
• Выбор проблемы. Что надо сделать прямо сейчас, чтобы выжить сегодня? Что надо сделать, чтобы выжить в ближайшем будущем? Что надо сделать, чтобы победить? Посмотреть на различные временные рамки: что если у компании кончатся деньги через полгода, над чём тогда работать? А что, если совершенно нет никакого внешнего давления — и результат можно было бы показать через два года? Или через пять? Посмотреть, куда двигаются тренды индустрии. Посмотреть, есть ли быстрые штуки с большим возвратом. Подумать, что можно сделать сейчас, чтобы выбор проблемы в будущем был проще.
• Валидация решения проблемы. Попробовать убрать риски и проверить решение перед его реализацией. Например: написать анонс запуска перед реализацией и посмотреть — полезно и круто ли звучит? Показать его некоторым реальным пользователям. Посмотреть, как решают проблему другие и решают ли. Найти первых пользователей, показать им прототип. Найти способ провести быстрый эксперимент или валидацию идеи.
• Реализация.

Цели и метрики

Просто метрика-число — плохая цель. У хороших целей есть четыре измерения:

• сама цель: чего хотим достичь;
• исходные данные: где мы сейчас;
• тренд: текущий рост этой метрики (например, за прошлый период);
• ограничение по времени — на какой период цель.

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

Метрика — отличный способ внедрения новых заметных изменений во всей организации. Для этого сначала определяешь нужную метрику, смотришь, как каждый отдел на неё влияет, делаешь её публичной (в том числе сравнивая отделы между собой), добавляешь побуждений (дэшборды, письма, если метрика сильно изменилась) и — если есть возможность — задаёшь некий уровень, ниже которого нельзя опускать её. Раз в какой-то период делать ревью по ситуации.

Изменение структуры организации

Лучшая реорганизация — та, которая решает структурную или системную проблему (для улучшения коммуникации, более быстрых решений, лучшего фокуса и так далее), и та, которая не состоялась.

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

Не надо делать реорганизацию, чтобы решить будущие проблемы, которые ещё не настали. Мы не знаем, какие именно у нас будут проблемы.

Как изменять организацию

Как сообщить об изменениях:

• Описать, зачем мы их делаем.
• Описать, как затронет каждого.
• Будут недовольные: проявить эмпатию и дать им возможность высказать свои волнения.

Также в сложных ситуациях стоит:

• Поговорить сначала лично с теми, кого затрагивает сильно.
• Подготовить менеджеров и ключевых ребят к тому, чтобы они могли объяснить, зачем эти изменения, и рассказать детали.
• После этого выслать письмо с деталями и быть готовым отвечать на вопросы.
• Иногда общий личный сбор стоит провести, но не всегда — люди плохо обрабатывают сложные новости в больших группах. Увеличить количество skip level 1-1 после изменения.

Лучше внедрять изменения по одному, измеряя результат после каждого.

Управление и вовлечение менеджера

Есть разные уровни вовлечения менеджера в зависимости от задачи:

• Я это делаю. Я делаю эту штуку и отвечаю за неё целиком — ты смотришь и вовлекаешься по необходимости.
• Предпросмотр. Ты делаешь, но я хочу быть вовлечён часто и много. Мы, скорее всего, не согласны в чём-то, частая синхронизация поможет избежать выкидывания ненужной работы.
• Ревью. Покажите мне перед публикацией или запуском. Я хочу убедится, что всё будет нормально перед запуском, но в целом у нас нет расхождений во мнениях.
• Давайте апдейты. Сообщайте время от времени, как дела, чтобы я знал, что к чему и как всё движется. Не ждите никакого фидбэка от меня, чтобы продолжать работу.
• Без сюрпризов. Сообщайте, только если что-то сильно изменилось в проекте (задаче) или есть серьёзные проблемы. Главная цель: не должно быть сюрпризов в моём понимании того, как движется проект или задача.
• Дайте мне знать, если нужна помощь. Если от меня требуется помощь в решении проблемы — скажите. В остальном нам не надо тратить время на обсуждение этой штуки.

Как говорить с журналистами

Три правила:

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

Правила в организации

Главная мысль: надо улучшать правила, а не делать исключения. Хорошие правила в компании — это маленькие стратегии, они тоже имеют цели, ограничения и действия. Они также не делают счастливыми всех-всех и не подходят всем. Если не получается написать ограничение или хорошее правило, возможно, есть какая-то невысказанная цель, которую надо найти и проговорить.

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

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

Исключения в правилах подрывают их силу и создают ощущение несправедливости. Вместо исключений надо делать так:

• Собирать запросы на исключения.
• Время от времени (раз в какой-то период или когда много накопилось) ревьювить правила и ограничения, принимая во внимание эти новые обстоятельства.
• Или изменить правило (или ограничения), или оставить их без изменений (подтвердив, что они были правильные).

То есть запросы на исключения тут работают как информация для обновления правил и не обрабатываются отдельно.

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

Разное

• Надо уметь говорить «нет» своему руководству и объяснить, почему предложенный путь ведёт к проблеме или нежелателен. Два самых частых кейса: скорость («почему эта штука делается так долго?», «а давайте ещё сделаем и вот это?») и приоритеты («а почему мы делаем это, а не то?»). Эти вещи надо уметь объяснять.
• Для продуктивности хорошо работает ограничение случайных отвлечений «мне просто спросить» в Slack или лично, нотификации и так далее: автоматизировать их, сделать бота, просить делать тикеты, направлять вопросы дежурному и так далее. Ещё хорошо работает общий список, кто за что отвечает, и хорошая внутренняя документация (но это очень сложно).
• Системы, как правило, имеют какие-то свойства, помогающие им самоисцеляться. Например, перегруженная база данных замедлит работу сервиса, это заметит дежурный инженер и починит. Хорошие системы (необязательно именно технические даже) имеют эффективные и явные системы самолечения.
• Хорошие правило менеджмента: у каждого должна быть зона ответственности, за которую он отвечает. Награда и статус должны выдаваться за завершение качественной работы. Не проси делать то, что бы не сделал сам. Менеджмент он во многом про этику.
• Корень почти каждой внутренней проблемы: плохие или отсутствующие отношения.
• Люди важней процессов. С правильными людьми любой процесс подойдёт. С неправильными людьми никакой процесс не заработает. Если процесс не работает, иногда дело не в процессе.
• Делать сложные вещи надо, не откладывая: плохие отношения с кем-то, конфликт в команде и так далее. Если их откладывать — они выстрелят сильно позднее и с ними всё равно надо будет разбираться.
• Правильный фрейм принятия решения: что хорошо для компании? Что хорошо для моей команды? Что хорошо для меня? Именно в таком порядке.
• Есть два состояния: сильный рост и недостаток роста. Когда рост сильный, новые идеи не так важны — и так понятно, что делать, важно делать. Если роста сильного нет — наоборот, важны новые идеи.

Правила хорошего спринта

Команда знает:

1. Над чем работать.
2. Почему это важно.
3. Может определить, когда работа закончена.
4. Знает, над чем работать дальше.

Стейкхолдеры знают:

1. Над чем работает команда.
2. Над чем будет работать команда.
3. Как повлиять на планы.