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

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

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

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

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

## Оставьте ответственность за продукт одной команде

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

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

Это и есть ответственность. Она не означает, что нужно лично написать каждую строку.

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

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

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

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

## Привлекайте специалиста, когда цена ошибки непропорционально высока

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

Полезная проверка состоит из пяти вопросов. Спросите, будет ли работа:

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

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

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

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

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

## Начинайте работу с безопасностью до закрепления функции

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

OWASP Application Security Verification Standard по отдельности рассматривает вопросы проектирования и реализации не случайно. В рекомендациях говорится о документировании границ доверия, компонентов, значимых потоков данных и моделировании угроз, а стандарт проверки дает командам конкретные меры контроля для тестирования. NIST Secure Software Development Framework так же рассматривает безопасную разработку как работу на всем жизненном цикле, а не как финальную проверку перед релизом.

Небольшой команде стоит привлекать специалиста по безопасности в таких случаях:

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

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

### Бриф по безопасности, который приводит к полезному результату

Перед началом дайте специалисту короткий бриф. Его можно уместить в один документ:

```text
Система: рабочие пространства организаций и доступ к API
Бизнес-событие: корпоративные клиенты приглашают сотрудников и подключают автоматизацию
Активы: данные клиентов, токены API, история аудита
Границы доверия: браузер и API, API и база данных, API и сторонние интеграции
Вопросы:
- Может ли пользователь пересечь границы организации?
- Как создаются, ограничиваются, хранятся, ротируются и отзываются токены?
- Для каких действий нужна запись в аудите?
- Какие меры контроля должны существовать до общего запуска?
Обязательная передача: модель угроз, результаты с оценкой риска, pull request или патчи,
приемочные тесты и 60-минутная передача работы с участием обоих инженеров основной команды
```

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

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

```text
Дано: пользователь A принадлежит организации red
И: пользователь B принадлежит организации blue
Когда: пользователь A запрашивает счет blue с номером 1842
Тогда: API возвращает 404 или 403
И: поля счета не появляются в логах, трассировках или сообщениях об ошибках
```

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

## Специалисты по данным нужны, когда цифры влияют на решения

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

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

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

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

```yaml
metric: paid_active_organizations
definition: Организации с активным платным правом доступа на 23:59 UTC
source_of_truth: entitlement_history
excludes:
  - внутренние тестовые организации
  - возвращенные платные права доступа
owner: продуктовая разработка
freshness_expectation: обновление в течение 6 часов
known_limit: Не измеряет дату окончательного проведения платежа
```

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

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

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

## Специалисты по мобильной разработке решают платформенные риски продукта

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

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

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

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

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

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

## Дизайнеры исправляют решения, а не украшают экраны

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

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

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

В конце ограниченного проекта по дизайну попросите четыре результата:

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

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

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

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

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

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

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

Начните работу с конкретного описания сервиса. Например:

```text
Сценарий пользователя: клиент отправляет документ на обработку.
Цель: 99% принятых документов получают итоговый статус в течение 10 минут каждого календарного месяца.
Измерение: время от успешного принятия API до статуса «завершено» или «ошибка».
Исключения: отмена клиентом и некорректные загрузки, отклоненные до принятия.
Владелец: основная инженерная команда.
```

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

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

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

## У проекта со специалистом должны быть условия выхода еще до начала работы

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

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

Используйте такую последовательность:

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

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

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

Достаточно компактной записи:

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

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

## Ретейнеры обычно плохо заменяют план

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

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

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

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

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

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