В продуктовой B2B‑компании, где я отвечал за надёжность, поставили амбициозную цель: сократить цикл разработки (dev cycle time) на 20%. Забегая вперёд, скажу: к концу года цель достигли. Но уже через несколько месяцев после старта я смотрел на график инцидентов и не верил своим глазам: рост в два раза год к году.

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

Как цель съедает систему

Сокращение цикла разработки на 20% — цель понятная и измеримая. Проблема была не в ней, а в том, что она была одна.

Когда у команд есть одна метрика, за которую спрашивают, система оптимизируется под неё за счёт всего, за что не спрашивают. У нас цель достигалась ровно так: сокращали тестирование, отступали от регламентов, срезали углы везде, где срезание не было видно немедленно. Никто не делал этого злонамеренно. Каждое отдельное решение выглядело разумным компромиссом: «здесь можно без полного регресса», «этот шаг процесса пропустим, релиз горит».

Точнее всего этот механизм описывает Дитрих Дёрнер в «Логике неудачи» — книге о принятии решений в сложных системах, которую я советую каждому руководителю: фиксация на одной цели порождает побочные эффекты, которые никто не отслеживает, потому что они лежат вне поля зрения цели. Ровно это и происходило: побочные эффекты копились больше трёх месяцев, прежде чем стали видны на графике инцидентов. К тому моменту они уже были системой, а не отклонением.

Почему инциденты казались «дешёвыми»

Отдельная деталь, которая многое объясняет: инженеры не считали рост инцидентов проблемой. Инцидент воспринимался как дешёвое событие — упало, подняли, поехали дальше. Быстро починить — даже повод для гордости.

Причина в том, что ни один человек в компании не видел полной стоимости инцидента. Разработчик видел свой баг. Дежурный инженер — свою ночь. Саппорт — свой поток обращений. Менеджер — сорванный спринт. Каждый кусок по отдельности выглядел терпимо. Целиком картину не видел никто, потому что она нигде не собиралась.

И здесь важный момент про «качество по умолчанию». Когда я поднял вопрос, главное возражение звучало так: «О качестве все и так думают, это подразумевается». Я проверил: опросил менеджеров и разработчиков, как именно качество учитывается в их ежедневных решениях. Ответы говорили об обратном: в момент выбора «успеть к сроку или сделать полный регресс» побеждал срок — потому что за срок спрашивали, а за качество нет. «По умолчанию» на практике означало «никогда».

Контрметрики: противовес вместо тормоза

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

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

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

«Здоровье продукта»: как это выглядело

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

Внедряли его в три этапа.

Этап первый — единый набор метрик. Он может быть любым — важно, чтобы он охватывал и техническую, и бизнесовую сторону. Технические — например, uptime, бюджет ошибок, MTBF, количество багов, доехавших до прода. Бизнесовые — например, количество обращений в саппорт. Смысл не в дашборде как таковом, а в том, что вся стоимость ненадёжности впервые оказалась собрана в одном месте — та самая полная картина, которой не видел никто.

Этап второй — целевые значения, под которыми подписались CPO и CTO. Не «стремимся к лучшему», а конкретные числа. Это критично: пока целевые значения не согласованы наверху, здоровье продукта остаётся мнением инженеров, а не обязательством компании.

Этап третий — заранее согласованные действия при отклонении. Самая важная и самая трудная часть. Для здоровья продукта работал светофор. Зелёная зона — работаем как работали. Жёлтая — в течение следующего спринта команда обязана выявить причину просадки и запланировать на следующий квартал мероприятия по возвращению к целевым значениям. Красная — причина выявляется в течение текущего спринта, а мероприятия планируются уже на следующий спринт. Никаких наказаний — только заранее известные обязательства с заранее известными сроками. Правило, принятое на берегу, срабатывает; правило, которое изобретают в момент конфликта — нет.

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

Как продать это руководству

Честно: продажа заняла у меня около полугода.

Возражение было одно, и оно будет у вас тем же: «О качестве все думают по умолчанию, зачем это формализовывать».

Аргумент, который сработал: «Давайте оцифруем вот это „по умолчанию“». Если качество и так у всех в голове — целевые значения не будут нарушаться, и метрики просто подтвердят, что всё хорошо. Возразить на это нечем: несогласие с оцифровкой означает признание, что „по умолчанию“ не работает. Плюс на моей стороне были опросы: конкретные ответы менеджеров и разработчиков о том, что в реальных решениях качество проигрывает срокам.“»

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

Не всё прошло гладко: одну из метрик на финальном согласовании отклонили — хотя на всех предыдущих этапах её удавалось отстоять. Это нормально: здоровье продукта не обязано согласоваться целиком с первого захода — работает и неполный набор метрик.

Заметьте: не понадобилось ни одного нового инструмента и почти ни одной новой метрики. Продавали не проект внедрения, а договорённость: вот числа, вот подписи, вот действия при отклонении.

Что изменилось

На пилотных продуктах количество инцидентов сократилось в два раза.

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

С чего начать у себя

Если узнали свою компанию в первой половине статьи, порядок такой. Сначала проверьте, есть ли у ваших текущих целей контрметрики — у каждой цели вида «ускорить/удешевить/нарастить» должен быть противовес. Затем соберите то, что уже собирается: почти наверняка всё важное у вас уже измеряется — просто лежит в разных местах и ни на что не влияет. Согласуйте целевые значения наверху — без подписи CPO/CTO это останется инженерной самодеятельностью. И договоритесь о действиях при отклонении до того, как отклонение случится.

А первый вопрос, который стоит себе задать: за счёт чего ваша компания «ускоряется» прямо сейчас — и кто в ней видит полную стоимость этого ускорения?