Расходы на разработку в расчете на выпущенный результат: месячный scorecard

Почему одного фонда оплаты труда недостаточно, чтобы понять результат разработки

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

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

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

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

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

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

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

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

Применяйте тот же подход к AI-инструментам для разработки. Не оценивайте инструмент по числу предложенных фрагментов кода. Проверьте, помогает ли он выпустить больше клиентской работы, сокращает ли время на исправления или ускоряет ли релизы. В AppMaster.io Oleg Sotnikov сократил операционную команду с 25 человек до двух инженеров, усиленных AI, сохранив объем работы и доступность сервиса. Важен был операционный результат, а не новизна инструментов.

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

Выберите простое определение выпущенного результата

Выпущенный результат, это завершенная работа, которой клиенты могут пользоваться в production. Она прошла обычные проверки, стала доступна реальным пользователям и решает понятную проблему. Задача со статусом «готово» в трекере не считается результатом, если она все еще ждет ревью, релиза или доступа клиента.

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

Считайте результаты, а не story points, закрытые тикеты, pull request или часы. Эти показатели описывают усилия. Они не отвечают основателю на вопрос, создал ли фонд оплаты труда что-то, чем клиенты могут пользоваться.

Для billing-продукта отдельными выпущенными результатами могут быть такие изменения:

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

Дайте каждому пункту короткое описание и дату релиза. Большая функция может считаться одним результатом, если клиент получает ее как одну пригодную к использованию возможность. Не делите ее на тикеты дизайна, API, интерфейса, тестирования и развертывания. Это шаги к одному результату.

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

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

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

Составьте месячную сумму расходов на разработку

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

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

Инженер с годовой зарплатой $120,000 получает $10,000 месячной зарплаты. Если налоги работодателя и льготы добавляют $2,500, запишите $12,500. Подрядчик со счетом на $8,000 также входит в месячную сумму.

Применяйте одно правило к совмещаемым ролям

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

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

• Включайте 100% расходов на выделенные роли разработки, QA, платформы и DevOps.
• Для совмещаемых ролей используйте один и тот же зафиксированный процент, если характер работы не изменился.
• Включайте временных сотрудников, если они поддерживают поставку для клиентов или работу в production.
• Записывайте правило распределения рядом с месячной суммой.

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

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

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

Отслеживайте работу, которая меняет стоимость результата

Фонд оплаты труда показывает, сколько стоила разработка. Он не объясняет, куда ушел месяц. Сначала отследите работу, которая дошла до клиентов, а затем отделите работу, потребовавшую времени, но не создавшую нового результата.

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

Затем фиксируйте доработки. Сюда входят дефекты, найденные после релиза, неверно понятые требования и переделка, потому что первая версия не решила заявленную проблему. Записывайте часы инженеров и исходный запрос. Основатель, который видит, что обновление billing заняло 40 часов, а потом потребовало еще 18 часов исправлений, понимает картину лучше, чем тот, кто видит только запись «billing выпущен».

Внесите нагрузку поддержки в тот же scorecard. Считайте время, которое инженеры тратят на ответы по тикетам, расследование инцидентов, технические вопросы от продаж или ручное исправление клиентских данных. Часть поддержки неизбежна. Но рост этого показателя может объяснить падение результата даже при неизменных фонде оплаты труда и размере команды.

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

Краткая месячная запись может выглядеть так:

• 12 клиентских запросов выпущено
• 76 инженерных часов на доработки
• 54 инженерных часа на поддержку
• Четыре задержанных релиза общей продолжительностью 19 рабочих дней
• Две задержки из-за неясных требований

Эти цифры позволяют справедливо оценить найм и AI-инструменты. Если поддержка и доработки занимают 130 часов в месяц, еще один разработчик функций может не устранить узкое место. Сначала больше capacity могут вернуть улучшенные требования, автоматизированные проверки или workflow поддержки с AI.

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

Настройте scorecard

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

1. Добавьте полный месячный фонд оплаты труда разработки, включая зарплаты, счета подрядчиков, расходы работодателя и людей, которые управляют инженерной работой. Не включайте продажи и общую администрацию.
2. Посчитайте клиентские результаты, которые попали в production в этом месяце. Разделите фонд оплаты труда на их число, чтобы получить расходы на один выпущенный результат.
3. Попросите инженеров отмечать время как новую клиентскую работу, доработки, поддержку, внутреннее обслуживание или другое. Категории должны быть достаточно широкими, чтобы не вызывать споры.
4. Рассчитайте доработки и поддержку как долю общего времени команды.
5. Запишите каждый релиз, который не вышел в согласованный срок, и число дней задержки. Если релиз перенесли с 12 на 22 апреля, задержка составляет 10 дней.

Рядом с сырыми часами показывайте проценты. Если команда из пяти человек потратила на поддержку 180 из 720 доступных часов, нагрузка поддержки составила 25%. Часы показывают объем работы, а проценты позволяют сравнивать месяцы при изменении праздников или состава команды.

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

• Расходы на один выпущенный результат = общий фонд оплаты труда разработки / число завершенных результатов
• Доля доработок = часы на доработки / общее время команды
• Нагрузка поддержки = часы поддержки / общее время команды
• Задержка релизов = общее число дней просрочки и количество задержанных релизов

Команда с месячным фондом оплаты труда $90,000, которая выпускает 15 результатов, тратит $6,000 на каждый результат. Если в прошлом месяце показатель составлял $5,000, не спешите нанимать или обвинять команду. Проверьте, выросла ли поддержка, требовали ли результаты ремонта или меньше релизов вышло вовремя.

Рядом с каждым необычным изменением напишите короткое пояснение. Фраза «Два инженера девять дней занимались инцидентом у клиента» объясняет рост стоимости лучше, чем красная цифра. Такой scorecard превращает разговор о фонде оплаты труда в обсуждение фактов о работе, задержках и capacity.

Реальный пример за месяц

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

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

Поддержка также изменила картину месяца. Два инженера потратили примерно четверть времени на срочные тикеты, проверку проблем в production и ответы клиентам. Это примерно половина полной инженерной ставки за месяц. Поддержка использовала около $7,500 из общих $90,000.

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

Scorecard

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

Добавьте рядом с цифрами короткую заметку: «Один платный релиз перенесен на следующий месяц; поддержка заняла половину инженерного месяца». Контекст предотвращает необдуманную реакцию, например немедленный найм из-за падения результата или празднование низкой стоимости результата при росте дефектов.

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

Ошибки, которые искажают цифры

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

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

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

Не прячьте поддержку и доработки

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

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

Месячное распределение может выглядеть так:

• 55% на новые клиентские результаты
• 20% на поддержку и реакцию на инциденты
• 15% на доработки после релиза
• 10% на внутреннее обслуживание

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

Воспринимайте плохую цифру как подсказку о процессе

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

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

Быстрые проверки перед решением по scorecard

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

Включите каждого, кто заметно участвует в инженерной работе: сотрудников, подрядчиков, специалистов на неполной занятости, инженерных менеджеров, которые продолжают программировать, и основателей, регулярно разблокирующих релизы. Добавьте налоги работодателя, льготы и счета подрядчиков, если они применимы. Если не учесть подрядчика за $6,000 в месяц, стоимость результата будет выглядеть ниже реальной.

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

Перед обсуждением цифр проверьте следующее:

• Каждый участник инженерной работы включен в месячную сумму расходов.
• У каждого учтенного результата есть дата выхода в production и описание, понятное клиенту.
• У доработок есть заметная метка, владелец и причина, например неясный объем или дефект в production.
• Дни задержки рассчитаны от фактической даты и исходной согласованной даты, а не от пересмотренного плана.
• Команда может объяснить крупные изменения от месяца к месяцу фактами.

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

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

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

Если цифры по-прежнему неясны, Team & AI Audit поможет отделить проблему измерения от проблемы поставки до того, как вы примете дорогое решение о найме.

Используйте факты для следующего решения

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

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

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

До найма сформулируйте ограничение одним предложением. Например: «Два изменения для онбординга enterprise-клиентов ждали 18 дней, потому что наш единственный backend-инженер занимался поддержкой production». Это проблема capacity, которую можно оценить в деньгах. Если scorecard показывает 30% доработок, найм может лишь увеличить стоимость этих доработок.

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

Используйте такой тест для решения:

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

Цель, не минимальный фонд оплаты труда. Цель, платить за работу, которая доходит до клиентов и не возвращается в виде проблемы, которой можно было избежать. Для внешней оценки Team & AI Audit Oleg Sotnikov анализирует расходы на разработку, workflow и практические возможности для экономии за пять рабочих дней. Фиксированная цена составляет $5,000, а если аудит не выявит экономию минимум $50,000 в год, он будет бесплатным.