# Минимальный состав инженерной команды выше, чем показывает планирование функций

> Практический рабочий лист поможет рассчитать минимальный состав инженерной команды для SaaS с учетом доменов, внедрений, дежурств, соответствия требованиям и ревью.

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

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

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

## Минимальный состав команды ограничивает операционную модель, а не оценивает функции

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

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

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

Для первого расчета используйте формулу:

```text
FTE по нагрузке = ОКРУГЛВВЕРХ(общее число годовых инженерных часов / доступные часы одного инженера)
минимальный состав инженерной команды = МАКС(FTE по нагрузке, минимальное покрытие)
```

Не помещайте в знаменатель все рабочие часы. Начните с 2 080 часов в год для штатного сотрудника, затем вычтите время на праздники, отпуск, общие встречи, найм, встречи один на один, планирование, прерывания из-за инцидентов и внутреннюю поддержку. Оставшееся число и есть доступная емкость. Для многих небольших SaaS-команд 1 250-1 450 доступных часов честнее, чем 2 080, но лучше опираться на собственный календарь и данные о времени, а не выбирать цифру только потому, что она выглядит эффективной.

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

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

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

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

На сводной вкладке используйте такие поля:

```text
Ввод: доступные годовые часы одного инженера                 1 350
Ввод: запланированные часы по продуктовым доменам             [сумма]
Ввод: часы на клиентские внедрения                             [сумма]
Ввод: активная работа в продакшене и дежурствах                [сумма]
Ввод: работа по соответствию требованиям и безопасности        [сумма]
Ввод: емкость на ревью и релизы                                [сумма]

Общее число годовых инженерных часов = СУММА(всех пяти категорий)
FTE по нагрузке = ОКРУГЛВВЕРХ(общее число годовых инженерных часов / доступные годовые часы)
Минимальное покрытие = [необходимое число квалифицированных людей]
Минимальный состав = МАКС(FTE по нагрузке, минимальное покрытие)
```

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

Если объем меняется, используйте диапазоны. Например, стандартное внедрение может занимать 18-30 часов, а клиенту, которому нужны интеграция идентификации, импорт исторических данных и индивидуальная отчетность, может потребоваться 70-120 часов. Занесите в таблицу ожидаемую структуру. Если вы продаете двенадцать стандартных и четыре сложных внедрения, годовая оценка должна отражать оба предположения.

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

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

## Продуктовым доменам сначала нужны назначенные владельцы, а потом дополнительные люди

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

Для типичной B2B SaaS-компании доменами могут быть идентификация и доступ, биллинг, правила арендаторов и прав, основной рабочий процесс, отчетность и экспорт данных, интеграции, перемещение данных и инфраструктура доставки. Ваш продукт может объединять несколько таких областей. Проверка проста: может ли проблема в продакшене или обязательство перед клиентом потребовать специальных знаний, которых нет у других инженеров?

Сделайте таблицу примерно такого вида:

| Домен | Что произойдет при отказе | Годовые часы разработки | Годовые часы поддержки | Основной владелец | Резервный владелец |
|---|---|---:|---:|---|---|
| Права арендаторов | Клиенты потеряют доступ или увидят чужие данные | 280 | 90 | Назначенный инженер | Назначенный инженер |
| Биллинг и права по тарифам | Остановятся сбор платежей и применение тарифов | 180 | 110 | Назначенный инженер | Назначенный инженер |
| Клиентские интеграции | Пострадают внедрения и удержание клиентов | 360 | 160 | Назначенный инженер | Назначенный инженер |
| Путь доставки | Релизы замедлятся или начнут падать | 140 | 180 | Назначенный инженер | Назначенный инженер |

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

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

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

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

## Клиентские внедрения часто поглощают первого скрытого инженера

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

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

| Тип внедрения | Годовой объем | Часы на клиента | Годовые часы |
|---|---:|---:|---:|
| Самостоятельная настройка с эскалацией в поддержку | 40 | 4 | 160 |
| Стандартная настройка и импорт данных | 18 | 26 | 468 |
| Интеграция идентификации или API | 10 | 55 | 550 |
| Миграция крупного клиента и поддержка запуска | 4 | 105 | 420 |

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

Добавляйте встречи по изучению требований, только если в них должен участвовать инженер. Учитывайте proof of concept, если отдел продаж ожидает, что его подготовит инженерная команда. Включайте переделки из-за неясных требований. Добавляйте первый месяц после запуска, если клиент обычно находит крайние случаи, когда начинают работать реальные пользователи. Не учитывайте пассивное время ожидания ответа клиентом. Считайте активное время сотрудников.

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

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

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

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

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

Вкладка по продакшену может выглядеть так:

```text
Срабатывания в месяц x среднее активное время на срабатывание       [часы]
Расследования с влиянием на клиентов в месяц x время               [часы]
Исправления и профилактика после инцидентов в месяц x время        [часы]
Поддержка релизов, обновления, резервные копии, доступы             [часы]
Операционные тикеты и повторяющаяся ручная работа                    [часы]
Годовая активная работа в продакшене и дежурствах = 12 x месячная сумма
```

Если оповещение будит инженера на 45 минут, а на следующий день приводит к шести часам расследования и исправления, запишите 6,75 часа, а не 0,75. Именно последующие действия создают настоящую стоимость. Основатели часто считают только само срабатывание, потому что исправление поглощается спринтом и теряет свое название.

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

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

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

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

## Работа по соответствию требованиям это регулярная инженерная нагрузка

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

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

Внесите в вкладку соответствия регулярную работу:

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

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

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

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

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

## Емкость на ревью не может быть остатком спринта

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

Типичная ошибка планирования проста: руководители отдают всю неделю каждого инженера под работу, которую он пишет сам, а ревью оставляют «между встречами». Так не работает. Ревью ждут. Инженеры одобряют изменения слишком быстро. Старшие специалисты становятся постоянным узким местом. Младшие инженеры перестают получать полезную обратную связь, потому что люди с нужным контекстом заняты исправлением продакшена.

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

```text
Годовые часы авторской работы x доля ревью = годовые часы на ревью
```

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

Допустим, в разделах по продукту, внедрениям и соответствию требованиям содержится 4 000 часов авторской работы. При доле ревью 25% нужно зарезервировать 1 000 часов. При 1 350 доступных часах на инженера это 0,74 FTE. Именно так команда из трех человек постоянно начинает не укладываться в сроки, когда эту долю просто округляют до нуля.

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

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

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

## Разберите честный пример SaaS-компании

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

Рабочий лист показывает такую годовую активную работу:

| Категория | Годовые часы |
|---|---:|
| Разработка и поддержка продуктовых доменов | 2 900 |
| Клиентские внедрения | 1 450 |
| Активная работа в продакшене и дежурствах | 820 |
| Соответствие требованиям и безопасность | 520 |
| Емкость на ревью и релизы | 1 140 |
| Итого | 6 830 |

При 1 350 доступных годовых часах на инженера расчет нагрузки выглядит так: 6 830 / 1 350 = 5,06, то есть после округления нужны шесть инженеров. Карта покрытия также требует четырех квалифицированных людей для основной производственной ротации. Минимальный состав равен шести, а не трем и не четырем.

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

Предположим, они делают три изменения: упаковывают самую распространенную интеграцию, устраняют 250 годовых часов ручной работы по внедрению, автоматизируют повторяющуюся операционную процедуру и убирают 140 часов, а также сокращают 180 часов на ненужные индивидуальные отчеты. Новый итог составляет 6 260 часов. После округления минимальная нагрузка все еще соответствует пяти инженерам. Операционная модель стала лучше, но исходной команде по-прежнему не хватает людей.

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

## Чтобы снизить минимальный состав, нужно изменить бизнес-модель

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

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

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

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

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

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