[Прозрачность инженерных затрат: как узнать реальную стоимость каждой фичи]

Это один из тех вопросов, которые кажутся простыми — до тех пор, пока не попытаешься ответить на них по-настоящему.

CPO спрашивает на ревью дорожной карты: "Сколько всего стоил нам редизайн онбординга?". Ты знаешь спринт, в котором его выпустили, примерно представляешь, сколько инженеров его касались, и смутно помнишь, что он вышел за рамки сроков. Но реальная цифра — часы, потраченные каждым, по какой ставке, относительно какой оценки, включая два бага, которые всплыли через два спринта — этого нет нигде, где можно было бы найти за тридцать секунд.

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

Проблема была в том, что реальные данные существовали в четырех разных инструментах, которых никто никогда не просил разговаривать друг с другом: в Jira были тикеты, в GitHub — коммиты, в HR-системе — ставки, а в какой-то таблице — исходная оценка. Никто не связал их в единый ответ на единый вопрос, потому что никто не нуждался в этом достаточно сильно. До тех пор, пока это действительно не понадобилось.

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

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

Вторая проблема: стори-поинты не конвертируются в деньги. CPO или CFO, спрашивающий об ROI фичи, задает финансовый вопрос. "Мы потратили 34 стори поинта" — это не ответ, с которым они могут что-то сделать. А вот "Мы потратили примерно 18 000 долларов инженерного времени против оценки в 11 000, и вот откуда взялась разница" — это другой разговор.

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

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

Прежде чем что-то строить, мне пришлось четко определить, что именно я пытаюсь измерить, — потому что "стоимость фичи" оказывается означает как минимум три разные вещи в зависимости от того, кто спрашивает.

Для разработки это означает время: сколько часов ушло на проектирование, разработку, ревью, тестирование и незапланированную работу, которая последовала за этим.

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

Для продукта это означает ценность: что мы получили от этой инвестиции? Сдвинула ли она ту метрику, для которой создавалась? Продолжаем ли мы ее поддерживать, и какова текущая стоимость этой поддержки?

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

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

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

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

Практическая настройка состояла из трех компонентов:

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

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

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

Видимость затрат создаёт новую проблему: объяснять её людям, которые её не просили и не уверены, что с ней делать.

Когда я первый раз показала CPO представление маржинальности проектов, реакция была не "отлично, теперь я знаю", а "на что я смотрю и это плохо?" Данные были точными — Enji правильно все собрал, но контекста не было.

Вывод: данные о стоимости без нарратива — это просто источник тревоги. Руководству не нужно знать, что фича вышла за рамки на 40%; им нужно знать, почему она вышла за рамки, является ли причина системной или ситуационной, и что следует изменить в результате, если что-то следует.

Моя роль изменилась.

Я перестала представлять данные о стоимости как информацию и начала представлять их как контекст для рекомендации. "Модуль аутентификации вышел на 140% от оценки. Половина объясняется изменением скоупа, которое мы согласовали на второй неделе. Другая половина — паттерн, который мы наблюдаем везде, где код касается устаревшего слоя сессий; это заслуживает отдельного разговора о том, решаем ли мы это проактивно или продолжаем поглощать реактивно".

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

Самым неожиданным эффектом от того, что стоимость фич стала видимой, оказалось то, что это сделало с приоритизацией — не драматично, а тихо и последовательно, накапливаясь со временем.

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

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

Эта информация изменила подход как к планированию, так и к приоритизации. Фичи уведомлений получили стандартный буфер 2× как отправную точку — это помогало, но как универсальное правило создавало перекосы: избыточное выделение емкости на простые задачи и недооценку сложных. Лучше это работало как повод внимательнее смотреть на каждый пункт, а не как правило применять вслепую. Фичи со значительными зависимостями от сторонних API скоупились консервативнее и разворачивались поэтапнее, потому что вариативность была реальной, а направление её предсказать было нельзя.

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

Два момента, которые я бы сделала иначе:

1. Начинать с уровня данных, а не с уровня отчетности. Мы создали дашборд стоимости до того, как наладили надежную дисциплину ворклогов, и в первой версии было столько пробелов, что это подрывало доверие к цифрам до того, как у нас появился шанс продемонстрировать их ценность. Правильный порядок: сначала данные, потом отчётность, потом решения.
2. Приоритизировать последовательность, а не точность. Мы слишком долго спорили о правильной полной ставке, правильном способе распределения накладных расходов и правильной детализации тегов фич. Идеальная методология расчета менее ценна, чем последовательная методология, которую реально используют. Приблизительно и последовательно бьет точно, но непоследовательно — всегда.

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

Первый — связать стоимость фичи с ее ценностью систематически, а не анекдотически. Я могу сказать, сколько стоит построить фичу; не всегда могу сказать в том же дашборде, что она приносит в ответ. Данные об использовании живут в другом месте, а атрибуция выручки — это отдельный разговор с отдельной командой. Левая сторона расчета ROI чище правой.

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

Это не работает, если PM строит это в одиночку: данные живут в разработке; привычки, производящие полезные данные, живут в разработке; а поддержка, делающая эти привычки устойчивыми, должна исходить от руководства разработки.

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

Что мне было нужно конкретно:

• Согласованная таксономия фич. Общий список тегов фич, которые и продукт, и разработка используют последовательно, чтобы записи ворклогов и работа по тикетам агрегировались в одни и те же категории. Без этого вы агрегируете яблоки и офисные стулья.
• Контекст ворклога, а не только часы. Часы, залогированные против номера тикета, говорят о времени. Часы, залогированные с пометкой о том, чем на самом деле была работа (реализация, отладка, переработка, ревью), говорят о том, куда ушло время. Второе полезнее. Оно также требует чуть большего трения в привычке логирования, что означает: руководство разработки должно активно это поддерживать.
• Честный пересчет оценок при изменении скоупа. Если фича вырастает в середине спринта, а исходная оценка не обновляется, данные о стоимости показывают ложный перерасход, не имеющий никакого отношения к качеству исполнения. Мы установили соглашение: любое изменение скоупа выше определённого порога инициирует пересчёт оценки и примечание. Небольшие накладные расходы, значительное улучшение качества данных.
• Доступ к ставкам на уровне ролей. Не индивидуальные зарплаты — полные ставки на уровне ролей, согласованные с финансами и актуальные. Данные о стоимости, основанные на устаревших ставках, дают точно выглядящие цифры, которые тихо неправильны, и это имеет тенденцию проявляться в самый неподходящий момент.

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

Вопрос "Сколько нам обошлась эта фича?" должен иметь реальный ответ. И он может его иметь — нужно только решить, что ответ достаточно важен, чтобы выстроить привычку его фиксировать.