Кейс. Zero Bug Policy: как мы снизили бэклог багов в 4 раза за месяц

[skovoroad]

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

• исправление проблемы, регулярная работа над техдолгом, это долго и сложно, зато решает проблему по-настоящему

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

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

[Eskimo]

Специфика стартапа: жизнь от раунда к раунду инвестиций.

Безусловно вы правы, закон Гудхарта так и говорит. Поэтому самой команде мы никогда такие цели не ставили. Это договор и трекинг на уровне sales, csm, engineering, support. Zero Bugs Policy - это входная точка на практику работы с качеством и ориентированием на клиента: когда начнут отваливаться платящие клиенты, вы сразу поймете что команду больше держать не на что - и дело в качестве. Поэтому поставите (как в тойоте) линию на стоп и будете фиксить дефекты или переделывать системно работу с качеством (shift left, re-architecture, refactoring, еще что-то релевантное вам).

У команды есть явная ответственность за Uptime своего сервиса (который потом обвалится), у руководителя - есть ответственность по архитектуре перед своим CIO. Для остального есть сонар и внешний аудит.

Поэтому там и написано про то что данные потом идут в общую ретроспективу, на которой надо принимать системные решения - и вкорячиваются в Definition of Done.

[Viacheslav01]

За весь опыт работы не встречал более тупой метрики чем ZPB. Эта метрика реально сначала работает на качество, потом на улучшение метрики любыми способами кроме поднятия качества. Но менеджерам это не жоказать им нужны красивые картинки.

[Eskimo]

Но это же не метрика, а подход. С какой целью вы его применяете - это уже другой вопрос.

Я упоминаю психологическую безопасность не просто так.

[Viacheslav01]

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

[Eskimo]

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

Так-то, вы можете любую метрику хакать, это нормально. Если вы хотите какое-то ультимативное решение - то сферических коней в вакууме не бывает :)

[denenis]

Хороший кейс. Особенно зацепило ETA for ETA: клиенту часто важнее предсказуемость, чем обещание “починим как можно быстрее”.

Мне кажется, рядом с Zero Bug Policy полезен weekly review не только багов, но и клиентских диалогов вокруг них: где Support/CSM пообещал срок раньше уверенности, где клиент не понял следующий шаг, где won't fix прозвучал как “мы вас бросили”, хотя процессно всё корректно.

Вы отдельно смотрели качество коммуникации Support/CSM после внедрения политики — consistency формулировок, обещания сроков, reopen/repeat cases? Или due dates + SLA оказалось достаточно?

[Eskimo]

Мы смотрели шире, на качество коммуникации тоже. Support / CSM / Sales могут пороть ерунду, могут преувеличивать проблемы. Там, по-хорошему, надо еще и в то как они свою работу делают погружаться и мониторить. Но это совсем другая история (там моделька - тогда еще ранний gemini - ходила по заметкам общения с клиентами в google meet / gong / salesforce и очень базово репортила если были паттерны общения, которые мы не поощряем). Это было на заре начала chatGPT и всяких суммаризаторов google meet (в end 2022- mid 2023)