Отчет об инженерных потерях для более ясных бюджетных решений

Почему разрозненные потери никогда не выигрывают бюджет

Руководство реагирует на острую боль. Крупный сбой быстро привлекает внимание. А вот замедление, которое отнимает по 20 минут в день у шести инженеров, может съедать целую рабочую неделю каждый месяц и при этом выглядеть безобидно.

Такие потери скрываются, потому что никто не видит их в одном месте. Часть живет в мелких тикетах. Часть — в переписках о нестабильных тестах, сломанных скриптах или ручных шагах. Еще часть исчезает на стендапах, когда люди говорят «все еще заблокировано» и идут дальше.

Работа, связанная с выручкой, обычно находится в другом представлении. В планах продукта видны запуски, сделки и обещанные даты. Но там редко видно старый сервис, который задерживает каждый релиз на два дня, или путаницу в отчетности, из-за которой продавец ждет простой ответ от инженеров. Руководство видит запрос на функцию и дедлайн, но не видит трение вокруг этого.

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

Вот почему устранение проблем так часто проигрывает. Каждая отдельная проблема выглядит мелкой, когда она разбросана по инструментам и командам. Вместе же стоимость становится трудно игнорировать.

Одна страница меняет разговор, потому что показывает три вида потерь рядом:

• потерянное время команды
• задержанную или потерянную работу по выручке
• проблемы клиентов, которые возникли или стали хуже

Теперь компромисс виден. Потратить две недели на устранение проблем уже не звучит как «внутренняя работа». Это выглядит как устранение узкого места, из-за которого сдвигаются сроки поставки, обещания продаж и качество клиентского опыта.

Растущие компании сталкиваются с этим постоянно. Проблема редко в нехватке усилий. Обычно проблема в нехватке общей видимости. Как только руководство может прочитать полную стоимость меньше чем за пять минут, устранение проблем начинает честно конкурировать с новыми задачами.

Что должно быть на странице

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

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

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

Работа, связанная с выручкой, тоже должна быть в той же строке. Назовите, что именно задержалось, было отменено или уменьшено из-за того, что команда занималась потерями. Это может быть функция, кампания, запрос от продаж или изменение онбординга. Если можно хотя бы примерно оценить потерянный результат, запишите это. Отложенный тест цены или пропущенный срок интеграции легче сравнить, чем общую пометку о замедленной поставке.

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

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

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

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

Выбирайте правильные пункты

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

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

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

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

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

Используйте простой фильтр:

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

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

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

Если вы можете указать на одну и ту же проблему три раза за квартал, скорее всего, ей место на странице.

Соберите страницу по шагам

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

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

1. Начните с одной строки на каждый пункт потерь. Делайте строки достаточно короткими, чтобы их можно было прочитать за несколько секунд. Хорошие столбцы: пункт потерь, владелец команды, потерянные часы в неделю, сдвинутая функция или работа по сделке, эффект для клиента и срочность.
2. Используйте реальные еженедельные часы из логов команды, тикетов, заметок об инцидентах или передач в поддержку. Не угадывайте. Если инженеры тратили 6 часов каждую неделю на исправление сломанных тестовых данных, пишите 6, а не «много».
3. Назовите точную работу, которая сдвинулась из-за этой проблемы. «Устранение проблем в биллинге задержало pricing по usage-based модели на две недели» звучит сильнее, чем «работа над функцией замедлилась».
4. Опишите боль клиентов простыми словами. Уберите внутренний жаргон. Пишите, что случилось: «новые пользователи ждали день настройки аккаунта», «чекаут падал в часы пик» или «поддержка ответила на один и тот же баг 18 раз в этом месяце».
5. Оценивайте срочность по одному правилу и придерживайтесь его. Например, ставьте высокий приоритет, если клиенты уже чувствуют проблему или она блокирует согласованную работу в этом месяце, средний — если она повторяется каждую неделю, но есть обходной путь, и низкий — если она раздражает, но локальна.

Одна строка может выглядеть так: «Нестабильный pipeline деплоя, 11 часов в неделю, задержка функции для онбординга партнеров, клиенты увидели два неудачных окна релиза, высокий приоритет». Без драмы. Без лишних слов. Просто достаточно деталей, чтобы стоимость стала видимой.

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

Используйте простую оценку, чтобы приоритеты оставались честными

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

Используйте оценку от 1 до 5 для каждого типа потерь: потеря времени, влияние на выручку и боль клиентов. Шкалу специально держите небольшой. Узкая шкала заставляет выбирать и снижает ложную точность.

Правила могут быть простыми:

• 1 — это мелкая проблема, которую легко пережить
• 3 — заметная и повторяющаяся
• 5 — серьезная, частая или дорогая
• оценивайте время, выручку и боль клиентов отдельно
• рядом с каждой оценкой добавляйте короткое объяснение

Это короткое объяснение важнее самого числа. Строка с пометкой «Время: 4» слабая. Строка с пометкой «Время: 4 — инженеры тратят около 6 часов в неделю на повторный запуск неудачных деплоев» дает руководству что-то реальное для оценки.

Держите факты и оценки отдельно. Факты берите из тикетов, количества инцидентов, объема обращений в поддержку, времени цикла, неудачных релизов или фактически учтенных часов. Оценки — это уже обоснованное предположение, например вероятная задержка выручки из-за заблокированной функции или вероятный риск оттока из-за медленного онбординга. Помещайте их в отдельные столбцы или четко помечайте.

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

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

Пример: один квартал избежанных потерь

Представьте продуктовую команду, которая постоянно теряет время на нестабильные деплои. Сама по себе ни одна ситуация не выглядит драматично. Где-то откат, где-то неудачная миграция, где-то release engineer, которого в конце дня дергают в Slack. Но команда ведет учет один квартал и видит один и тот же паттерн каждую неделю.

Итоговая потеря — 6 часов в неделю. За 13 недель это 78 часов командного времени, ушедших на проблемы с деплоем вместо запланированной работы. Это почти две полные рабочие недели, и чаще всего они пропадают у людей, которым нужно завершать работу, связанную с выручкой.

В том же квартале два релиза, о которых продажи уже упоминали клиентам, сдвигаются на три недели. Один был нужен, чтобы существующий клиент увеличил использование. Другой был связан с новой сделкой, где перед подписанием требовалась обещанная возможность. Задержка возникает не из-за плохих продуктовых решений. Она возникает потому, что команда останавливает работу над функциями, чтобы присматривать за релизами, перепроверять изменения и разбирать неудачные деплои.

Поддержка показывает человеческую сторону проблемы. Платящие пользователи продолжают жаловаться на таймауты, особенно во время окон релиза. Отдельный тикет не выглядит катастрофой. Вместе они показывают устойчивый удар по доверию. Клиенты ждут дольше, поддержка тратит больше времени на объяснения, а аккаунт-менеджеры идут на более сложные разговоры о продлении.

На одной странице эта строка могла бы выглядеть так:

• источник потерь: нестабильные деплои
• потеря времени за квартал: 78 часов
• бизнес-эффект: 2 релиза, связанные с продажами, задержаны на 3 недели
• эффект для клиента: повторяющиеся жалобы на таймауты от платящих пользователей
• оценка стоимости устранения: небольшое исправление процесса деплоя, например упрощение pipeline и усиление проверок отката

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

Ошибки, которые ослабляют аргумент

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

Двойной учет создает ту же проблему. Один нестабильный релиз может съесть время поддержки, задержать обещание для продаж и отвлечь инженеров от запланированной работы. Это не значит, что его нужно посчитать трижды как три разные стоимости. Покажите одну корневую проблему, а ниже перечислите все ее эффекты.

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

Язык тоже важен. Руководство редко реагирует на фразы вроде «проблема developer experience» или «расчистка архитектуры». Они реагируют на простое описание того, что теряет бизнес: 14 часов за спринт, запуск, сдвинутый на две недели, или 18 тикетов поддержки из-за одного и того же бага. Сначала пишите про эффект. Технические термины используйте только если они объясняют причину.

Быстрая проверка перед отправкой

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

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

Перед отправкой отчета проверьте пять вещей:

• Поместите вверху краткое резюме с тремя простыми числами: потерянные часы, задержанная работа по выручке и влияние на клиентов.
• Сделайте так, чтобы в каждой строке были одни и те же поля, тогда пункты будет легко сравнивать.
• Честно подписывайте числа. Показывайте, какие цифры взяты из тикетов, журналов инцидентов, счетчиков поддержки или данных о поставке, а какие являются оценками.
• Сделайте математику проверяемой. Продукт и финансы должны уметь проследить каждое число до источника, даже если это простая таблица или отчет спринта.
• Заканчивайте прямым запросом: сумма бюджета, фиксированный блок времени команды или названный квартал для устранения проблем.

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

Честность важнее показной точности. Если вы оцениваете, что сломанный test pipeline съел примерно 25 часов, так и пишите «оценка» и укажите, кто ее сделал. Люди доверяют аккуратной оценке больше, чем фальшивой точной цифре.

Полезно сделать еще одну последнюю проверку. Попросите одного product lead и одного человека из финансов прочитать страницу до того, как ее увидит руководство. Если оба смогут пересказать суть без вашей помощи, отчет готов.

Что делать дальше

Назначьте 30-минутный разбор с одним человеком из инженерии, одним из продукта и одним из поддержки. Покажите страницу на экране и задайте простой вопрос к каждой строке: изменит ли это бюджетное решение в этом месяце? Если ответ нет, уберите пункт. Более короткую страницу читают. Перегруженную — игнорируют.

Оставляйте строки, которые связывают потерянное время команды, заблокированную выручку и боль клиентов в одном месте. Вот где бюджетное обоснование становится реальным. Если проблема только раздражает команду, но не задерживает релизы и не бьет по клиентам, уберите ее из основного отчета.

Затем сделайте обновление частью спринт-рутины:

• Обновляйте цифры каждый спринт.
• Убирайте строки, когда проблема исчезает.
• Сохраняйте один и тот же метод оценки каждый раз.
• Храните старые версии, чтобы руководству было легко сравнивать кварталы.

Простой фильтр помогает сохранить честность отчета. Одна строка может показывать 18 потерянных инженерных часов за спринт из-за неудачных деплоев, одну задержанную функцию для продаж и 14 тикетов поддержки, связанных с той же проблемой релиза. Оставляйте такую строку. Другая может говорить, что команде не нравится внутренний скрипт, но он не вызывает ни задержки, ни проблемы для клиентов. Уберите его из бюджетной версии.

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

Если страница все еще кажется слабой, может помочь внешний взгляд. Oleg Sotnikov на oleg.is работает как Fractional CTO и стартап-советник, и именно с такими задачами он помогает командам: четко показать, сколько стоит потеря сейчас, что стоит исправлять первым и как превратить это в план, который руководство сможет одобрить.