Как измерить здоровье системы до того, как все сгорит
Важно: Все истории, описанные в этой статье, основаны на реальном опыте, но имена и некоторые детали изменены. Любые совпадения с реальными людьми случайны.
Предыдущая статья:
Вы можете быть гениальным лидером. Вы можете проводить правильные 1-на-1, давать вызовы, поддерживать, растить. Но если у вас нет системы, которая показывает реальное состояние дел — вы всегда будете в режиме пожарной команды.
То есть там, откуда мы так хотели уйти.
Сегодня поговорим о том, как выстроить пульс команды — набор сигналов, которые подсветят проблемы.
Часть 1. Почему «чуйка» не работает
Самый частый ответ лидера на вопрос «как дела в команде?» — «нормально, я чувствую».
Чуйка — это круто. У опытных лидеров она действительно работает.
Но у чуйки есть три проблемы:
1.1. Чуйка приходит слишком поздно
Вы начинаете «чувствовать» проблему, когда она уже случилась. Когда Леша стал огрызаться на код-ревью. Когда Петя перестал задавать вопросы. Когда Коля ушел в больничный без объяснения причин.
К этому моменту вы уже в зоне пожара.
1.2. Чуйка не масштабируется
Вы можете чувствовать 5-7 человек. А если у вас 3 команды по 8 человек? А если 10 команд?
Чуйка превращается в «чуйку вообще», которая работает как случайность.
1.3. Чуйку не передать
Когда вы уходите в отпуск или передаете команду другому лидеру, вместе с вами уходит и ваше «чувствование». Новому человеку придется набивать шишки заново.
Система нужна не чтобы заменить чуйку. Система нужна чтобы:
— Подтверждать чуйку данными;
— Замечать проблемы раньше чуйки;
— Передавать знание о команде дальше.
Часть 2. Четыре слоя здоровья команды
Давайте вспомним четыре слоя устойчивой системы из первых статей:
Если слои здоровы:
— Новый человек выходит на первую задачу за 3 дня, а не за 3 недели;
— Код-ревью проходит за час, а не за неделю;
— Люди предлагают улучшения, а не просто чинят баги;
— В пятницу вечером никто не выкатывает фичи с мыслью «лишь бы не упало».
Теперь давайте разберем, как это измерять.
Часть 3. Метрики здоровья: что и как измерять
Важное предупреждение: метрики — это не цель, а инструмент.
Если вы начнете гоняться за цифрами, команда начнет гоняться за цифрами, и все сломается.
Метрики нужны только для одного: вовремя заметить, что что-то пошло не так.
3.1. Метрики фундамента (процессы)
Что измеряем: насколько процессы помогают, а не мешают.
Ключевые показатели:
— Время онбординга нового человека (от выхода до первого PR в прод). Если растет — процессы усложнились или документация устарела;
— Время от коммита до прода (lead time). Если растет — где-то затор; — Частота выкаток (deployment frequency). Если падает — страх релизов или проблемы с CI/CD;
— Процент откатов (rollback rate). Если растет — качество падает.
Красные флаги:
— Онбординг дольше месяца;
— Релиз раз в две недели, хотя технически можно каждый день;
— Каждый третий релиз откатывают.
3.2. Метрики инструментов (технический долг)
Что измеряем: насколько инструменты помогают не думать о рутине.
Ключевые показатели:
— Время сборки проекта. Если билд собирается 10 минут — разработчики теряют контекст;
— Процент покрытия тестами (не самоцель, но тренд важен); — Количество обращений к поддержке инфраструктуры. Если DevOps тонет в вопросах — инструменты плохие;
— Время восстановления после сбоя. Если фикс занимает часы — плохая отчуждаемость знаний.
Красные флаги:
— Билд собирается дольше, чем пьется кофе;
— Один и тот же вопрос задают разным людям трижды;
— После ухода разработчика его модуль нельзя трогать полгода.
3.3. Метрики умений (рост людей)
Что измеряем: растут ли люди или застыли.
Ключевые показатели:
— Скорость прохождения код-ревью (не сколько ждут, а сколько правок требуется). Если мидл делает те же ошибки, что и год назад — он не растет;
— Разнообразие задач. Если человек полгода чинит баги в одном модуле — он деградирует;
— Участие в сложных задачах. Кто берет архитектурные задачи, а кто отдает?;
— Внутренние активности. Кто пишет в Handbook, кто проводит воркшопы, кто помогает новичкам?
Красные флаги:
— Коля третий год на том же уровне, хотя объективно мог бы расти;
— Никто не хочет брать сложные задачи;
— Handbook не обновлялся полгода.
3.4. Метрики ответственности (вовлеченность)
Что измеряем: есть ли у людей энергия или они просто дорабатывают.
Ключевые показатели:
— Инициативы снизу. Сколько улучшений предложила команда за месяц?;
— Участие в ретроспективах. Не формальное присутствие, а реальные инсайты;
— Текучка идей. Обсуждают ли люди рабочие вопросы вне обязательных встреч?;
— Индекс счастья. Да, звучит по-детски, но работает, если мерить правильно.
Красные флаги:
— На ретро все молчат;
— В пятницу в 17:00 офис пустеет за 5 минут (окей, это не всегда флаг, но если всегда — задумайтесь);
— Люди не спорят с продактами, а просто кивают.
Часть 4. Инструмент: тепловая карта команды
Все эти метрики бесполезны по отдельности. Они работают только в связке.
Один из удобных способов — тепловая карта (или health check).
Раз в квартал вы проходите с командой по 8-10 параметрам и оцениваете каждый от 1 до 5.
Пример карты:
Главное правило: оценки ставит команда, а не лидер.
Лидер может предложить свое видение, но итоговая цифра — результат обсуждения.
Часть 5. Адизис: диагностика стадии по метрикам
А теперь самое интересное. Если наложить эти метрики на модель Адизиса, можно понять, на какой стадии ваша команда и куда ее штормит.
5.1. Признаки «Давай-давай» (хаос, герои)
— Онбординг не описан — новые люди впадают в ступор;
— Релизы когда получится, а не когда надо;
— Технический долг растет, потому что «сначала сделаем, потом переделаем»;
— Инициативы снизу есть, но они хаотичные и часто ломают прод;
— Люди горят, но выгорают.
Что делать: строить фундамент. Handbook, регламенты, код-ревью.
5.2. Признаки «Юности» (болезненный переход)
— Появились процессы, но их много и они бесят;
— Опытные разработки ностальгируют по хаосу;
— Джуны не понимают, зачем столько правил;
— Метрики скачут: то быстро, то тормозим;
— Конфликты между «стариками» и «новичками».
Что делать: работать с людьми. Лечить опытных разработчиков, направлять джунов, растить мидлов.
5.3. Признаки «Расцвета» (здоровье)
— Онбординг быстрый и предсказуемый;
— Релизы частые и безболезненные;
— Люди растут и меняют роли;
— Есть и стабильность, и обновление;
— Метрики используются для улучшений, а не для отчетов.
Что делать: не расслабляться. Поддерживать баланс, следить за сигналами старения.
5.4. Признаки старения (бюрократия, застой)
— Процессов много, результата мало;
— Люди не предлагают идей — зачем, всё равно не одобрят;
— Мидлы застыли, опытные разработчики уходят, джуны не задерживаются;
— Метрики есть, но они формальные и ни на что не влияют;
— Главный вопрос — «как отчитаться», а не «как сделать лучше».
Что делать: встряска. Новые люди, новые вызовы, пересмотр процессов.
Часть 6. Реальный пример: как карта спасла команду
В одной из команд была ситуация: вроде всё хорошо, спринты идут, задачи закрываются, но лидер чувствовал — что-то не так.
Сделали тепловую карту.
Выяснилось:
— Онбординг — 5 (супер, новые люди влетают);
— Скорость релизов — 4 (норм);
— Качество кода — 4 (норм);
— Вовлеченность — 2 (все молчат);
— Рост людей — 2 (никто не растет);
— Отношения с бизнесом — 1 (продакты продавливают, команда молча соглашается).
Оказалось, что команда тихо ненавидит свою работу, но продолжает делать задачи из чувства долга.
Продакты последние полгода просто ставили задачи сверху, не обсуждая. Команда перестала спорить, потому что спорить было бесполезно. Люди отключили эмоции и превратились в роботов.
Метрики задач были зеленые. Метрики людей — красные.
Мы начали работать с отношениями с бизнесом. Провели серию встреч, где команда училась говорить «нет» и аргументировать. Продакты учились слушать.
Через три месяца вовлеченность поднялась до 4. Люди снова начали спорить, предлагать, злиться. Команда ожила.
Метрики спасли ситуацию до того, как люди начали увольняться.
Часть 7. Внедрение: с чего начать завтра
Если у вас нет системы метрик, не надо внедрять всё сразу. Это провалится.
Шаг 1. Начните с одного
Выберите одну метрику, которая сейчас болит больше всего.
— Если долго заходит новичок — начните с онбординга;
— Если релизы — ад — начните с lead time;
— Если люди скучают — начните с тепловой карты раз в квартал.
Шаг 2. Сделайте видимым
Повесьте метрику на общую доску. Обсуждайте на ретро.
Не для контроля, а для осознания: «ребята, смотрите, время онбординга выросло — давайте подумаем почему».
Шаг 3. Добавляйте следующие
Когда одна метрика прижилась и перестала пугать, добавляйте следующую.
За год вы построите пульс команды, который работает сам.
Итог: система, которая дышит
Помните, с чего мы начинали?
Был Леша, который страдал. Был Петя, который бунтовал. Был Коля, который застыл.
Вы можете быть гениальным лидером и работать с каждым лично.
Но если у вас есть пульс команды, вы заметите Лешину грусть до того, как он начнет огрызаться.
Вы заметите Петин бунт до того, как он перепишет половину системы.
Вы заметите Колин застой до того, как он превратится в робота.
Метрики не заменяют лидера. Метрики дают лидеру время.
Время подумать. Время поговорить. Время помочь.
Адизис говорит: здоровая организация — это организация, которая умеет замечать проблемы на ранней стадии и реагировать на них адекватно.
Пульс команды — это ваш инструмент для этого.
Ссылка на оригинальную статью: