В среднем post-mortem пишется 4 часа и порождает ноль action items, которые команда закрывает в течение 30 дней. Мы посмотрели на 120 post-mortem документов у трёх наших on-prem клиентов перед тем, как собрать этот шаблон. 83% action items оставались в статусе "open" через полгода. Это не разбор инцидента — это кладбище документов.
Post-mortem имеет смысл писать только если он что-то меняет. Всё остальное — прикрытие.
Команда из восьми инженеров, которую я консультировал в прошлом году, держала правило: любой тикет больше 3 story points требует design doc. Получалось около четырёх документов в неделю, по полдня на написание и ещё полдня на циклы ревью. Итого 32 инженерных часа в неделю — четыре полных рабочих дня на документы, которые большинство людей пробегало глазами один раз и больше не открывало. CTO считал, что у них высокая дисциплина. Данные говорили, что у них перегруз документации и провал по velocity.
Обратная крайность ещё хуже. Stack Overflow Developer Survey 2019 года назвал «плохую документацию внутренних систем» блокером продуктивности №2 — сразу после технического долга. Полностью отказаться от design docs значит, что каждый рефакторинг через полгода превращается в археологические раскопки.
Это фреймворк, которым я пользуюсь, чтобы решить: какие изменения заслуживают документа, какие — комментария на 3 предложения в RFC, а какие — ничего.
Среднее инженерное ретро длится 60 минут, рождает пять стикеров и ноль действий, которые доедут до следующего спринта. В опросе Scrum Alliance 2023 года жалоба №1 от senior-разработчиков звучала так: «ретро ощущается как спектакль». Это не проблема митинга — это проблема измерений. Команда обсуждает ощущения, потому что никто не вытащил цифры до звонка.
В этой статье — 30-минутное ретро, которое начинается с данных, заканчивается именами и сроками, и работает на командах от 5 до 25 инженеров.
Два разработчика на одну задачу. Удвоенная стоимость труда, вдвое меньше багов, и никто не может договориться, окупается ли это. Самое цитируемое исследование на эту тему — Cockburn & Williams, The Costs and Benefits of Pair Programming (2000) — показало +15% времени при парной работе и −15% дефектов. На бумаге это ничья. В реальности — нет. Математика "баг пойман рано" выводит ROI примерно к 2×, если учесть сэкономленный rework и предотвращённые production-инциденты.
В этой статье мы скрестили академические данные Cockburn-Williams с нашим IDE heartbeat датасетом по 100+ B2B-компаниям — включая команды, которые практикуют pair programming ежедневно, и те, что не используют его вовсе. Не "хорош ли pair programming?", а "когда он окупается, а когда это театр?".
Прямо сейчас у вашей команды несколько pull request'ов застряли в ревью. Скорее всего, три или больше. Один из них провисел пять дней. Исследование Google 2018 года (Sadowski et al., Modern Code Review: A Case Study at Google) показало: медианный review в Google закрывается за менее чем 4 часа. В большинстве команд, которые мы наблюдаем, этот показатель — 4 дня. Разница в 24 раза, и она почти полностью объясняется процессом, а не уровнем разработчиков.
Это чеклист из 11 правил, которые режут время ревью вдвое без потери качества. Каждое правило подкреплено внешним исследованием, проверено на реальных данных инженерных команд и разнесено по трём фазам: дисциплина автора, дисциплина ревьюера, дисциплина команды.
Отчёт McKinsey о продуктивности разработчиков (2023) показал, что инженеры тратят лишь 25–30% времени на написание кода. Остальное исчезает в митингах, переключении контекста и ожидании. Если вы Engineering Manager и полагаетесь на интуицию — вы не видите, куда уходит 70% мощности вашей команды.
Вот 10 метрик, которые заточат ваши решения. Без воды и совета «отслеживайте всё» — только то, что отличает управление на основе данных от гадания.
Большинство попыток внедрения DORA проваливаются не из-за инструментов или данных — а потому что превращаются в 6-месячные проекты, умирающие в комитетах. Исследование Accelerate (Forsgren, Humble, Kim, 2018) показало, что организации с видимыми метриками доставки улучшаются быстрее. Ключевое слово — видимыми: дашборд, на который никто не смотрит, хуже, чем отсутствие дашборда, потому что создаёт иллюзию измерения. Вот пошаговый план: от нуля до рабочих DORA-дашбордов за две недели — достаточно быстро, чтобы инерция не рассеялась.
Исследование Глории Марк из UC Irvine показало, что после одного прерывания требуется в среднем 23 минуты 15 секунд, чтобы вернуться к задаче. А теперь представьте типичное утро разработчика: в 9:07 пришло сообщение в Slack, в 9:15 — напоминание о стендапе, в 9:45 — «быстрый вопрос» от PM. К 10:30 он «работал» 90 минут, но написал ровно 11 строк кода. Три прерывания съели примерно 70 минут когнитивного восстановления.
Это не проблема продуктивности. Это проблема Focus Time. И данные показывают, что она обходится вашей команде гораздо дороже, чем вы думаете.
Никто не увольняется в понедельник. Заявление об увольнении, которое вы получите в случайный четверг, было написано — эмоционально — шесть недель назад. Отстранение началось три месяца назад. И данные видели это всё время.
Опрос Stack Overflow Developer Survey 2023 показал, что более 70% разработчиков отметили те или иные симптомы выгорания. Замена среднего разработчика обходится примерно в 50–200% его годовой зарплаты, если учесть рекрутинг, онбординг и потерю институциональных знаний. Фреймворк SPACE (Forsgren et al., 2021) прямо включает «Удовлетворённость и благополучие» как ключевое измерение продуктивности — признавая, что выгоревшие разработчики не просто несчастны, они существенно менее продуктивны. Но сигналы видны в данных активности задолго до заявления об увольнении.
Вот пять паттернов, которые проявляются в данных активности IDE за недели — иногда месяцы — до того, как разработчик выгорит или уволится.
Ваш сениор-разработчик назначен на три проекта. Вы полагаете, что он отдаёт каждому проекту треть времени. Джеральд Вайнберг посчитал реальную математику в Quality Software Management (1992): при трёх параллельных проектах каждый получает около 20% времени разработчика — а оставшиеся 40% испаряются в виде накладных расходов на переключение контекста.
Это не предположение. Это хорошо задокументированный когнитивный феномен, подтверждённый данными нашей платформы по B2B-инженерным командам и согласующийся с исследованиями Глории Марк из UC Irvine, показавшими 23 минуты восстановления после каждого прерывания. Переключение контекста — одна из самых дорогих невидимых затрат в разработке ПО.