# Инженерный аудит или найм для команды стартапа

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

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

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

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

## Дополнительная мощность помогает только тогда, когда работа готова

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

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

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

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

Хорошее обоснование найма звучит примерно так:

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

Это повторяющийся спрос с понятной зоной ответственности. Нанимайте под такую задачу.

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

## Ожидание нужно измерять ущербом для бизнеса

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

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

Запишите конкретный сбой, который станет возможен из-за ожидания. Чем конкретнее, тем лучше.

| Если мы ждем | Что произойдет | Кто почувствует это первым | Во что это обойдется |
|---|---|---|---|
| Нет владельца инцидентов в продакшене | Те же два инженера постоянно прерывают плановую работу | Клиенты и служба поддержки | Срыв сроков и риск оттока |
| Нет мощности для подписанной интеграции | Клиент не может завершить внедрение | Продажи и представитель клиента | Отложенная или потерянная выручка |
| Нет времени на ревью | Изменения остаются незавершенными и накапливаются до крупных релизов | Инженеры и продуктовая команда | Переделки и риск дефектов |
| Нет владельца миграции данных | Срывается регуляторное или договорное обязательство | Руководство и юристы | Штрафы или блокировка бизнеса |

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

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

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

## Цена сбоя определяет, сколько уверенности вам нужно

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

Основатели часто не учитывают две разновидности цены ошибки.

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

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

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

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

Например:

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

Такую гипотезу можно проверить. Вы изучаете выборку изменений, фиксируете исходные показатели, проводите ограниченный эксперимент и сравниваете результат. Фраза «нам нужно больше ИИ» не дает ничего, кроме нового счета.

## Повторяющийся спрос отличает найм от временного решения

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

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

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

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

Это не разовые проекты. Это постоянные обязанности.

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

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

## Пробелы в ответственности ухудшают любой вариант

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

Больше инженеров этот пробел не закроет. Он лишь получит больше мест, где можно спрятаться.

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

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

До одобрения любых расходов письменно назначьте следующие роли:

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

В небольшой компании один человек может совмещать несколько ролей. Это нормально. Оставлять роль без владельца нельзя.

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

## Инструменты ИИ нужно начинать с процесса, а не с лицензий

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

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

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

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

Для каждого процесса используйте небольшую карточку эксперимента:

```text
Процесс: подготовка черновиков миграций для одобренных изменений схемы
Владелец: руководитель backend-разработки
Входные данные: одобренное изменение схемы и существующие правила миграций
Результат: черновик миграции, инструкции по откату, тесты
Проверка человеком: руководитель backend-разработки проверяет каждый черновик до слияния
Исходный показатель: зафиксировать затраченное время и число откатов для последних 10 изменений
Эксперимент: использовать инструмент для следующих 10 сопоставимых изменений
Решение: оставить, изменить или прекратить эксперимент по времени ревью, сроку выполнения и числу инцидентов
```

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

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

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

## Для выбора между аудитом и наймом нужен скоринг

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

Оцените каждый вариант от 0 до 5. Чем выше число, тем лучше вариант соответствует условию. Не усредняйте оценки, создавая ложную точность. Цель таблицы - показать несоответствия.

| Критерий решения | Инженерный аудит | Инструменты ИИ | Еще один сотрудник |
|---|---:|---:|---:|
| Мы не можем определить реальное узкое место | 5 | 1 | 1 |
| Работа повторяется по стабильному шаблону | 2 | 5 | 4 |
| Ошибочное решение будет дорого отменить | 5 | 3 | 2 |
| У нас есть понятный владелец результата | 3 | 4 | 5 |
| Нам нужно облегчение до завершения долгого цикла найма | 4 | 4 | 1 |
| Спрос сохранится как минимум год | 2 | 3 | 5 |

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

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

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

## Срыв поставки обычно начинается до запроса на найм

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

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

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

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

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

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

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

## Порядок расходов должен соответствовать уровню уверенности

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

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

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

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