# Когда малому бизнесу пора заменить агентство разработки?

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

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

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

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

## Переход оправдывает стабильный спрос на шесть месяцев

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

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

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

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

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

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

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

## Двум инженерам нужна другая операционная модель

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

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

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

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

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

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

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

## Владение репозиторием нужно передать до команды

Компания должна контролировать репозиторий, облачные аккаунты, домены, реестры пакетов, CI/CD, мониторинг, секреты, аккаунты магазинов приложений и оплату поставщиков до завершения отношений с агентством. ZIP-архив исходного кода не означает владение репозиторием. Контроль означает, что администраторы компании могут выдавать и отзывать доступ, проверять настройки, восстанавливать сервис и платить каждому нужному поставщику без аккаунта агентства.

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

Документация GitHub о передаче репозитория делает различие наглядным. При передаче можно сохранить коммиты, задачи, pull request, релизы, веб-хуки, секреты и ключи развертывания, но права и связанные пакеты могут вести себя по-разному в зависимости от исходного и целевого аккаунта. Я согласен, что нужно пользоваться функцией передачи платформы, а не копировать код. Но я все равно составил бы список каждого соседнего актива, потому что передача репозитория не передает владение облачной подпиской, зоной DNS, внешним реестром или знаниями сотрудников.

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

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

```bash
git remote -v
git branch -a
git tag | tail
git submodule status
git shortlog -sne HEAD
```

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

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

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

## В цену перехода входит временная потеря скорости

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

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

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

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

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

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

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

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

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

## Доступ к специалистам нужно покупать осознанно

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

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

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

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

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

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

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

## Два человека не обеспечат постоянное дежурство

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

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

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

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

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

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

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

## Нанимайте для владения риском, а не под фреймворк

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

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

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

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

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

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

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

## Параллельная работа должна доказать самостоятельность

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

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

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

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

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

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

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

## Некоторым компаниям стоит сохранить агентство

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

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

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

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

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

Заменяйте агентство лишь тогда, когда карта спроса на шесть месяцев подтверждает постоянную ответственность, компания контролирует активы, переход оплачен, пробелы специалистов закрыты договорами, а обещания по инцидентам обеспечены людьми. Мой Team & AI Audit проверяет эти условия за пять рабочих дней и находит минимум $50,000 годовой экономии, иначе плата $5,000 отменяется. Полезный результат не дает разрешение сокращать людей. Он создает операционную модель и показывает, что нужно перенести первым.

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