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

О фонде зарплат разработки часто говорят как о проблеме численности. Но сначала это обычно проблема спроса.

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

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

Важна единица спроса, с которой началась работа

Классифицируйте работу по источнику спроса, а не по названию задачи, репозиторию или технической активности. Инженеры часто создают задачи вроде «добавить повторные попытки для webhook», «исправить права доступа» или «перенести данные в новый регион». Эти описания показывают, что изменилось. Но они не объясняют, зачем компания заплатила за изменения.

Рассмотрим три задачи, которые меняют один и тот же код аутентификации:

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

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

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

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

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

Эти ярлыки не обязаны разрешать каждый философский спор. Их задача проще: показать закономерность, которая сейчас не видна в финансовых отчетах.

Двенадцати недель достаточно, чтобы увидеть повторяющуюся работу

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

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

Соберите данные из:

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

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

Начните с такой таблицы:

week_start,engineer,work_item,source,requestor,customer_or_deal,hours,status,reason
2026-04-06,Maya,SCIM mapping change,customer setup,implementation,Northstar,11,done,contracted launch requirement
2026-04-06,Jon,Retry failed exports,support,support team,,5,done,three users blocked but service available
2026-04-13,Maya,Role templates,product development,product,,18,done,planned roadmap item
2026-04-13,Jon,Database failover,incident,on-call,,9,done,production write errors
2026-04-20,Rina,Security questionnaire evidence,sales requests,sales,Northstar,4,done,pre-contract review
2026-04-20,Rina,Dependency upgrade,maintenance,engineering,,7,done,supported version nearing end of support

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

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

Продуктовой работе нужна защита от срочных, но обоснованных запросов

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

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

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

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

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

Полезный вопрос для проверки: «Могли ли мы отклонить этот запрос, не нарушив подписанное обещание или обязательство и не оставив пользователей без возможности пользоваться сервисом?» Если да, запросу место в очереди с ответственным и решением. Он не должен попадать инженеру в личные сообщения как приказ, который подразумевается сам собой.

Настройка клиента это стоимость внедрения, даже если инженеры называют ее подключением

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

Основатели часто недооценивают эту категорию, потому что работа прячется в безобидных местах. Инженер подключается к звонку «на пятнадцать минут». Менеджер по работе с клиентами просит небольшой скрипт импорта. Аккаунт-менеджеру нужно добавить поле до запуска. Разработчик разбирает интеграцию во время передачи дел на выходных. Отдельно ни одна такая задача не выглядит проектом. Вместе они могут поглотить команду, которая должна создавать продукт.

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

Разделяйте три случая:

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

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

Худший вариант, это неформальное обещание: продажи говорят «наши инженеры помогут», customer success ожидает, что разработка завершит детали, а инженеры узнают о запросе уже после подписания договора. Расход попадает в фонд зарплат, но решение никто не принимает.

Запросам от продаж нужны цена и путь согласования

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

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

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

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

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

Это не бюрократия ради бюрократии. Фильтр не дает продавцу, основателю или менеджеру по работе с клиентами тратить инженерную мощность, не видя компромисса. Если кому-то нужен инженер для создания proof of concept, он должен назвать запланированную работу, которая из-за этого сдвинется.

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

Обслуживание, это плановая работа, а инциденты, счет за пропущенное обслуживание

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

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

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

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

incident_id: INC-042
start: 2026-05-18 14:10 UTC
service effect: customers could not create new records
immediate cause: exhausted connection pool after traffic spike
response work: rollback, pool limit change, customer communication
hours charged to incident: 16
follow-up classified separately: load test and capacity alert
follow-up source: maintenance

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

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

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

Поддержка показывает, где продукту все еще нужен оператор

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

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

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

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

• путаница в конфигурации;
• отсутствие инструмента оператора;
• исправление данных;
• дефект продукта;
• поведение интеграции.

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

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

Переведите часы в фонд зарплат, не делая вид, что каждый час стоит одинаково

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

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

Простой расчет выглядит так:

loaded_hourly_cost = annual_loaded_cost / annual_work_hours
source_cost = hours_in_source * loaded_hourly_cost

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

Допустим, за выбранный период инженер потратил 42 часа на настройку клиента, а его полностью загруженная стоимость часа составляет $95. Отраженная стоимость равна $3 990. Это не значит, что клиенту нужно выставить счет ровно на $3 990. Это значит, что компания больше не может считать настройку клиента бесплатной.

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

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

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

Еженедельная проверка сохраняет честность карты и не превращает ее в театр таймшитов

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

Для каждой спорной записи задайте такие вопросы:

1. Кто запросил эту работу или какое событие ее создало?
2. Могла ли компания отложить или отклонить ее?
3. Сделали ли конкретный клиент или сделка эти сроки необходимыми?
4. Сервис уже не работал или заметно деградировал?
5. Если это повторится в следующем месяце, кто должен принять решение до начала инженерной работы?

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

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

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

Если хотите получить независимую оценку до найма новых людей, Team & AI Audit от Oleg изучает спрос, процессы и стоимость разработки за пять рабочих дней. В аудите есть гарантия: экономия составит не менее $50 000 в год, иначе аудит будет бесплатным. Приносите исходную карту работы, а не отполированную историю. Неаккуратные записи часто лучше объясняют фонд зарплат, чем роадмап.