Разработчики на проект

Разработчики на проект 2026: 3 модели найма и сравнение

Q: Чем разработка под ключ отличается от аутстаффа и от найма?

Найм — вы строите команду в штате, платите зарплаты, делите ответственность за результат с командой. Срок до результата — от 3-6 месяцев на закрытие вакансий + 2-3 месяца онбординга. Аутстафф (аутстаффинг) — арендуете разработчиков у внешнего поставщика по часовой ставке (T&M). Вы получаете людей, а не результат. Дата релиза, объём работ и критерии приёмки — на вашей стороне. Бюджет открытый: «работа продлится, пока не закончится». Подряд под ключ — заказываете результат (фичу, модуль, интеграцию) с фиксированной ценой, фиксированной датой и измеримыми критериями приёмки. Команда у вендора, ответственность за результат у вендора. Срок 6-16 недель в зависимости от объёма. На квартал, на который у вас уходит закрытие 2-3 senior-вакансий, команда под ключ успевает сдать готовый продукт. Каждая модель подходит под свой кейс: длинные стратегические задачи — найм; гибкая R&D и расширение команды — аутстафф; конкретный roadmap-дедлайн с измеримым объёмом работ — подряд под ключ.

Q: Сколько стоит реальный TCO найма senior-разработчика в РФ?

TCO найма senior-разработчика в Москве на 2026 год при зарплате на руки 350-450 тысяч рублей в месяц складывается из: 1) Зарплата + НДФЛ + страховые взносы = 1.55× от gross, то есть 540-700 тысяч в месяц. 2) Бонусы и премии — 10-15% годовых от зарплаты = 50-80 тысяч в месяц. 3) HR-расходы на найм — рекрутер, бонус, агентство, ATS — в среднем 700 тысяч - 1.5 млн рублей единоразово на закрытие одной вакансии. 4) Онбординг — первые 2-3 месяца производительности 30-50% от целевой, что эквивалентно потерям 800 тысяч - 1.5 млн на разработчика. 5) Оборудование, ПО, обучение, конференции — 100-200 тысяч в год. 6) Управленческие расходы (тимлид, HR, оффис, оборудование) — добавляют 30-40% к прямым затратам. Полный TCO senior-разработчика на горизонте года — 11-15 млн рублей. На квартал — 2.8-3.7 млн рублей. На 3 senior'а за квартал — 8-11 млн рублей при условии, что вакансии закрыты, а не висят.

Q: Сколько занимает закрытие senior-вакансии в РФ?

Средние сроки закрытия senior-разработчика на 2026 год в Москве и Петербурге: backend Python/Go/Java — 3-5 месяцев, frontend React/Vue senior — 2-4 месяца, mobile iOS/Android senior — 4-7 месяцев, full-stack senior — 4-6 месяцев, специализированные направления (ML, security, DevOps senior) — 5-9 месяцев. Это медианные сроки от старта поиска до выхода на работу. После выхода — ещё 2-3 месяца на онбординг до полной производительности. Итого: senior реально работает на полную через 5-9 месяцев после решения «нанимать». На рынке дефицит, конкуренция за каждую вакансию между 5-15 работодателями. Это структурная проблема российского рынка с 2022 года, и она не улучшается. Для зрелого CTO планирование roadmap под найм senior-команды нереалистично, если дедлайн через 3-4 месяца.

Q: Когда подряд под ключ выгоднее, когда найм, когда аутстафф?

Decision tree для CTO зрелой продуктовой компании. Найм выгоднее когда: горизонт задачи 2+ года, нужна постоянная команда с product knowledge, фича развивается итеративно с непредсказуемыми итерациями. Аутстафф выгоднее когда: нужно временно расширить in-house команду на 3-12 месяцев для R&D или пиковой нагрузки, объём работ меняется по ходу работы, и заказчик готов вести проект сам с открытым T&M-бюджетом. Подряд под ключ выгоднее когда: есть конкретный roadmap-дедлайн через 6-16 недель, объём работ можно зафиксировать заранее, нужен результат, а не процесс. Типичные кейсы для под ключ: новый модуль или сервис, добавляемый к зрелому продукту; интеграция с внешней системой; миграция функционала с одного стека на другой; backend для новой фичи, которую мобильная команда не успевает; временно недостающая компетенция (например, безопасность, ML, специфический DevOps). На квартал — подряд под ключ почти всегда дешевле и быстрее найма.

Q: Что входит в результат под ключ?

Стандартный результат фичи под ключ или модуля: 1) Production-ready код в репозитории клиента с соответствием его coding standards и архитектурным паттернам. 2) Unit-тесты с покрытием 80%+ для критичной логики. 3) Integration-тесты для всех внешних интеграций. 4) Документация: README, архитектурное описание, API-спецификация (OpenAPI/Swagger), руководство по развёртыванию. 5) Инструкция по эксплуатации на 10 разделов: типовые ошибки и их разрешение, процедуры срочных исправлений, мониторинг и алерты, граничные сценарии. 6) Развёртывание на dev / staging / prod-окружениях клиента с использованием его CI/CD-пайплайнов. 7) Передача: 2-3 сессии с in-house командой клиента, парное программирование на первых срочных исправлениях, ответы на вопросы в течение 30-60 дней после сдачи. 8) Опциональный SLA-период 1-3 месяца с гарантированным временем реакции. Это набор по умолчанию, фиксируется в контракте. Дополнительные пункты (нагрузочное тестирование, performance-оптимизация под целевой SLA, инфраструктурный сетап) — отдельно по объёму работ.

Q: Что такое senior-only команда и зачем это нужно?

Senior-only — это принцип формирования команды на проект под ключ исключительно из разработчиков с реальным senior-уровнем по опыту, ответственности и техническому уровню. Это противоположность распространённой практике «продать senior, поставить middle с senior-title». Зачем senior-only: 1) На проекте под ключ 6-16 недель нет времени на обучение junior'ов и middle'ов специфике продукта клиента — senior разбирается быстрее. 2) Критерии приёмки — измеримые, senior может оценить риск и предложить компромисс, middle — нет. 3) Архитектурные решения принимаются на ходу, без согласований с тимлидом по каждому вопросу — это требует senior-уровня. 4) Снижение bus-факторов: senior'ы документируют и работают в стиле, понятном следующему разработчику. 5) Меньше команда — типовая команда под ключ 2-4 человека вместо 5-8 в аутстафф-модели, потому что каждый senior закрывает больше задач. Контрактно фиксируется в составе команды: количество и грейд каждой роли, рейт. Замена senior на middle без согласования с клиентом — нарушение контракта.

Q: Как организовать параллельные проекты с одной внешней командой?

Стандартный паттерн для квартального roadmap-блока — серия из 2-4 связанных проектов с одной командой, без перегрузки. Принципы: 1) Контракты — раздельные, по одному на проект, с собственными критериями приёмки и датами. Не «общий бюджет на квартал». 2) Стартуют с интервалом 1-2 недели, чтобы команда могла перераспределять фокус по фазам (старт нового — приёмка предыдущего). 3) Solution Architect один на серию проектов, остаётся core-ролью на 12-14 недель. 4) Senior backend и frontend разделены между проектами: один project — owner у одного senior, другой — у другого. Минимизирует конфликт контекстов. 5) Двухуровневое code review одно на серию: тот же in-house tech lead клиента видит все PR'ы. Это даёт согласованность стиля. Анти-паттерн: одна большая команда на «общий объём работ квартала» без фиксации владельца на каждый блок — приводит к размыванию ответственности.

Q: Что если roadmap меняется во время серии проектов?

Это нормальная ситуация для квартального горизонта. Стандартная процедура: 1) Контракты на не-стартовавшие проекты можно изменить или отменить без штрафа за 2-4 недели до старта (это фиксируется в контракте). 2) Уже стартовавшие проекты — change request с обоснованием изменения объёма работ, дополнительных часов и срока. 3) Если roadmap меняется радикально (например, отменён один из трёх проектов в середине квартала), команда либо разойдётся (по согласованию), либо подберём альтернативный блок работ. 4) Главное правило — изменения оформляются официально, не «давайте сделаем по-другому в чате». На практике в 80% квартальных серий из 3 проектов происходит 1-2 change request'а средней значимости, и серия не разваливается.

Q: Может ли in-house tech lead клиента вести нашу внешнюю команду?

Не полностью, но частично — да, и это часто работает. Распределение ролей: 1) Наш Solution Architect — owner архитектуры проекта, ведёт ежедневную работу нашей команды, отвечает за результат. 2) In-house tech lead клиента — owner архитектурного соответствия (модуль вписывается в существующую архитектуру клиента) и code review на каждый PR. 3) Daily-синхронизация нашего Solution Architect и in-house tech lead клиента — 15-30 минут в день в первые 2-3 недели проекта, далее по необходимости. 4) Спорные архитектурные вопросы решаются их совместным обсуждением, не одним лицом. Анти-паттерн: in-house tech lead клиента полностью ведёт нашу команду как свою — это размывает ответственность и не оставляет нашему Solution Architect полномочий принимать решения. Контракт должен явно фиксировать: ответственность за результат у нашей команды, ответственность за архитектурное соответствие — совместная.

Гайд для CTO: разработчики на проект — найм в штат, аутстаффинг или подряд под ключ. TCO за квартал, сроки, риски, фиксированная цена vs T&M, критерии приёмки.

Обновлено: 15 мая 2026 г.

Что это и что это НЕ: Эта статья — про модели найма разработчиков на конкретный проект (найм / аутстафф / подряд под ключ). Это не про найм одиночек-фрилансеров на разовые задачи. И не про разработку MVP с нуля (для этого см. primeit.ru/razrabotka-mvp/). И не про SaaS-разработку (см. jitech.ru/razrabotka-saas/).

К 2026 году большинство зрелых продуктовых компаний в России столкнулись с одной и той же проблемой: roadmap есть, дедлайны есть, фичи понятны, но команды не хватает. Найм 2-3 senior-разработчиков на квартал стал нереалистичной задачей — рынок не отвечает, HR-цикл занимает 4-6 месяцев, а roadmap-дедлайн через 3 месяца. Параллельно аутстафф-модель (аренда разработчиков по T&M) показала свои пределы: T&M-бюджет открытый, дата релиза не гарантируется, junior подменяет senior без согласования.

Эта статья — для CTO, VP Engineering и Head of Engineering зрелой продуктовой компании 100-1000 человек. Внутри: разбор трёх моделей (найм vs аутстафф vs подряд под ключ), реальный TCO найма на 2026 год, decision tree «когда что выбирать», стандарт результата под ключ, правила объёма работ и критериев приёмки, принцип senior-only. Без обещаний «под ключ всегда лучше» — модель работает не везде, и важно понимать границы.

Три модели разработки: найм, аутстафф, подряд под ключ

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

Найм. Вы строите команду в штате. Платите зарплаты, делите ответственность за результат с командой, инвестируете в team building, культуру, обучение. Срок до полной производительности новой команды — 6-9 месяцев с момента решения «нанимать» (с учётом HR-цикла и онбординга). Подходит для долгосрочных стратегических задач горизонтом 2+ года.

Аутстафф (outstaff, T&M). Арендуете разработчиков у внешнего поставщика по часовой ставке. Они работают в вашей команде, вашими процессами, вашим тулингом. Ответственность за объём работ, дату, качество — на вашей стороне. Бюджет открытый: «работа продлится, пока не закончится». Подходит для гибкого расширения команды на 3-12 месяцев для R&D или пиковой нагрузки.

Подряд под ключ (turnkey, фиксированная цена). Заказываете результат — фичу, модуль, интеграцию — с фиксированной ценой, фиксированной датой и измеримыми критериями приёмки. Команда у вендора, ответственность за результат у вендора. Срок 6-16 недель. Подходит для конкретных roadmap-задач с определённым объёмом работ.

Параметр	Найм	Аутстафф	Под ключ
Кто отвечает за результат	Вы + команда	Вы	Вендор
Структура оплаты	Зарплата + бонусы + накладные	Часовая ставка	Фиксированная цена за результат
Бюджетная определённость	Среднесрочная	Открытая	Точная до подписания
Срок до результата	5-9 мес (найм + онбординг)	1-2 мес (старт) + N	6-16 нед на результат
Гарантия даты релиза	Нет (планирование)	Нет (зависит от вас)	Контрактная
Гарантия критериев приёмки	Нет	Нет	Контрактная
Долгосрочное удержание знаний	Высокое (своя команда)	Среднее	Через передачу
Подходит для	Стратегические задачи 2+ лет	R&D, расширение команды	Конкретный объём работ с дедлайном

TCO найма senior-разработчика в 2026 году

CTO часто оценивают стоимость найма по «зарплате на руки». Это сильно занижает реальный TCO. Развёрнутый расчёт для senior с зарплатой на руки 350-450 тысяч рублей в Москве.

1. Зарплатный фонд. Зарплата на руки 350-450K → gross с НДФЛ 13% = 402-517K → плюс страховые взносы 30% = 540-700K в месяц прямых затрат компании.

2. Бонусы и премии. Годовая премия 10-15% от зарплаты, квартальные KPI-бонусы, акции/RSU в зрелых компаниях. В среднем дополнительно 50-80K в месяц на разработчика.

3. HR-затраты на найм. Внутренний рекрутер (зарплата + время на закрытие вакансии), бонус рекрутёру, агентство (15-25% годового gross на закрытие через агентство), реферал-бонусы, ATS, рекламные кампании на job boards. На одну закрытую senior-вакансию 700K - 1.5M рублей единоразово. На горизонте года это 60-130K в месяц на разработчика.

4. Онбординг. Первые 1-2 месяца — 20-30% от целевой производительности, следующие 2-3 месяца — 50-70%. Полная производительность через 4-6 месяцев. Потери производительности эквивалентны 800K - 1.5M рублей на разработчика за период онбординга.

5. Прочие расходы. Оборудование (ноутбук, монитор, периферия — 200-300K на 3-4 года), ПО и подписки (15-25K в месяц), обучение и конференции (50-100K в год), оффисное пространство (если оффлайн). В среднем 30-50K в месяц на разработчика.

6. Управленческие накладные. Тимлид, HR-партнёр, оффис-менеджер, бухгалтерия, общие сервисы. Эти расходы добавляют 30-40% к прямым затратам команды.

Итого TCO senior-разработчика на горизонте года:

Статья	Месяц	Год
Зарплата с налогами	620K	7.4M
Бонусы	65K	0.8M
HR-затраты (амортизированы)	80K	1.0M
Прочие расходы	40K	0.5M
Управленческие накладные (35%)	280K	3.4M
Полный TCO	~1.1M	~13M

На квартал — около 3-3.5 млн рублей TCO на одного senior’а. На 3 senior’а за квартал — 9-11 млн рублей, при условии что вакансии закрыты с первого месяца квартала. Реалистично это редко так — обычно первый senior появляется на 3-4 месяце поиска.

Сроки закрытия senior-вакансий

Медианные сроки закрытия senior-вакансии в Москве и Петербурге на начало 2026 года по данным рекрутинговых платформ и нашему опыту:

Специализация	От старта поиска до выхода
Backend Python / Go / Java senior	3-5 мес
Frontend React / Vue senior	2-4 мес
Mobile iOS / Android senior	4-7 мес
Full-stack senior	4-6 мес
ML / Data engineer senior	5-8 мес
DevOps / SRE senior	5-9 мес
Security engineer senior	6-10 мес

После выхода — 2-3 месяца на онбординг до полной производительности. Senior реально работает на полную через 5-9 месяцев после решения «нанимать». Для CTO это значит: если roadmap-дедлайн через 3-4 месяца, найм senior-команды нереалистичен.

Decision tree: какую модель выбрать

Базовая логика выбора. Начинать с горизонта задачи и определённости объёма работ.

Горизонт 2+ года, объём работ эволюционирует, нужна команда с product knowledge. → Найм. Окупается через 6-12 месяцев продуктивной работы. Senior разбирается в продукте, владеет архитектурой, проводит онбординг следующих сотрудников.

Горизонт 3-12 месяцев, объём работ меняется, нужно расширить in-house команду. → Аутстафф. Хорошо работает для R&D, пиковых нагрузок, освоения новых технологий. Гибкий контракт T&M, в команде ваши процессы и стандарты.

Горизонт 6-16 недель, объём работ можно зафиксировать, нужен результат. → Подряд под ключ. Закрывает конкретный roadmap-пункт без расходования управленческого ресурса CTO. Фиксированная цена снимает T&M-риск.

Типовые кейсы для под ключ:

Новый модуль или сервис к зрелому продукту (платёжный модуль, отчётность, аналитика, нотификации)
Интеграция с внешней системой (CRM, ERP, банк, оператор связи, маркетплейс)
Миграция функционала с одного стека на другой
Backend для новой фичи, который не успевает основная команда
Временно недостающая компетенция (security audit, ML-модуль, специфический DevOps)
Замена устаревшего модуля без рефакторинга остального продукта

Когда подряд под ключ не подходит:

Объём работ невозможно зафиксировать (исследовательская задача, R&D)
Горизонт меньше 4 недель (нет времени на предпроектное обследование и контракт)
Задача глубоко интегрирована с эволюцией продукта (тогда нужна команда внутри)
Внутренние политики компании требуют только in-house разработки (security, регуляторика)

Стандарт результата под ключ

Что должно быть в финальной поставке проекта с фиксированной ценой. Это стандартный набор, фиксируемый в контракте.

Production-ready код. В репозитории клиента (его GitHub/GitLab/Bitbucket), с соответствием его coding standards, code style, архитектурным паттернам. Не «своя экосистема», в которую потом сложно входить.

Тесты. Unit-тесты с покрытием 80%+ для критичной логики, integration-тесты для всех внешних интеграций. Тесты проходят в CI клиента, не в отдельной среде вендора.

Документация. README с инструкцией по локальному запуску; архитектурное описание (диаграмма компонентов, схема данных, последовательности для ключевых сценариев); API-спецификация (OpenAPI/Swagger или GraphQL schema); руководство по развёртыванию.

Инструкция по эксплуатации. Документ на 10 разделов для in-house команды клиента: типовые ошибки и их разрешение; процедуры срочных исправлений; мониторинг и алерты; граничные сценарии; миграционные процедуры; rollback-процедуры; чек-лист релиза; FAQ.

Развёртывание. Через CI/CD-пайплайны клиента на dev / staging / prod-окружениях. Не «у нас на серверах работает». Конфигурация инфраструктуры как код (Terraform, Helm chart, Ansible) включается в репозиторий.

Передача. Метрика готовности — «первое срочное исправление без нашего участия». 2-3 сессии с in-house командой клиента: walkthrough архитектуры, разбор кодовой базы, demonstration инструкции по эксплуатации. Парное программирование на первых 1-2 срочных исправлениях. Ответы на вопросы в течение 30-60 дней после сдачи.

Опциональный SLA-период. 1-3 месяца с гарантированным временем реакции. P1 (production down) — 4 часа; P2 (degraded) — 24 часа; P3 (minor issue) — 5 рабочих дней. Если в этот период обнаруживаются баги в нашем коде — фикс бесплатно.

Senior-only и двухуровневое code review

Принцип senior-only — это противоположность распространённой аутстафф-практики «продать senior, поставить middle с senior-title».

Senior-only означает:

Каждый разработчик в команде имеет реальный senior-уровень (5+ лет коммерческого опыта, опыт ведения сложных проектов, способность принимать архитектурные решения)
Состав команды фиксируется в контракте с указанием грейда каждой роли
Замена senior на middle без согласования с клиентом — нарушение контракта
Минимальный CV-skip от клиента до старта работ

Двухуровневое code review:

Каждый PR проходит code review у tech lead вендора (это качество кода, архитектурное соответствие)
Параллельно — code review у in-house tech lead клиента (это product knowledge, соответствие внутренним конвенциям)
Без двух approval PR не мержится
Это снижает риск принятия PR с неудачной интеграцией в продукт клиента

Объём работ и критерии приёмки: правила формулирования

Главный документ проекта под ключ. Все споры решаются ссылкой на объём работ.

Что входит в объём работ:

Список функций с измеримыми критериями приёмки по каждой. Не «добавить поиск», а «поиск по полям A, B, C с фильтрацией по D; отдача результата за < 200 мс на 100 тысячах записей; поддержка пагинации с курсором; поиск работает в кэше и в БД с fallback».
Архитектурные ограничения — стек (язык, фреймворк, БД), паттерны, что можно и что нельзя.
Интеграции — какие API клиента и внешних систем нужно использовать, с какой логикой (REST, GraphQL, события, файлы).
Non-functional requirements — производительность, доступность, безопасность, локализация, мониторинг.
Что не входит — явный список вещей, которые объём работ не покрывает.
Допущения и зависимости — на каких внешних факторах основана оценка.

Критерии приёмки должны быть:

Измеримыми (можно проверить выполнение)
Конкретными (не «работает быстро», а «P95 < 200ms»)
Привязанными к функциям (не общая «производительность системы», а «производительность операции X»)

Этап предпроектного обследования перед подписанием контракта — 1-2 недели работы tech lead вендора + 2-3 сессии с клиентом. Без предпроектного обследования объём работ получается размытым, и проект едет в спор о том, что входит, а что нет.

Контракты проекта под ключ

Стандартная структура контракта:

Объём работ (приложение 1) — детальный документ
Состав команды (приложение 2) — грейд каждой роли, рейт
График платежей — обычно 30% при подписании, 30% при промежуточной приёмке, 40% при сдаче
Acceptance procedure — как клиент проверяет результат, сроки приёмки, процедура замечаний
Change requests — как оформляются и оплачиваются изменения объёма работ
SLA-период — что входит в гарантию (обычно 1-3 месяца)
Передача — что включает передача, ответственности сторон

Стандартные сроки:

Предпроектное обследование — 1-2 недели
Контракт — 1-2 недели на согласование
Старт работ — следующая неделя после подписания
Промежуточная приёмка — на середине проекта
Финальная приёмка — за 1-2 недели до окончания работ
Передача — параллельно финальной приёмке

Сопутствующие материалы — разработка под ключ, найм senior-разработчика vs под ключ: реальный TCO, аутстафф vs под ключ, фича под ключ: как принять результат, контракты разработки: фиксированная цена vs T&M.

Сравнительная таблица: модели привлечения разработчиков

Модель	Скорость старта	Стоимость	Ответственность	Гибкость	Зависимость от одного разработчика
In-house найм	Медленно (4-8 мес)	TCO 600+ тыс/мес/senior	Полная у заказчика	Высокая	Зависит от культуры
Аутстафф	Средне (2-4 нед)	350-650 тыс ₽/мес/senior	Делится	Высокая	У заказчика
Под ключ	Быстро (1-2 нед до старта)	Фиксированная цена за результат	У подрядчика	Низкая (через CR)	Закрыта передачей
Гибрид	Зависит	Зависит	Зависит	Высокая	Зависит

RACI для команды под ключ на проекте 3-4 месяца

Активность	Заказчик (CTO/TL)	Подрядчик (SA/TL)	Подрядчик (Senior)	In-house team
Формирование объёма работ	R, A	C	I	I
Критерии приёмки	A	R	C	C
Архитектурные решения	A	R	C	C
Разработка	I	A	R	C
Двухуровневое code review	C (review)	A	R (PR)	C
Документация	C	R	R	C
Инструкция по эксплуатации	C	A	R	I
Передача (приёмка)	A	R	C	C
Парное программирование на первом срочном исправлении	I	A	R	R

Обозначения: R — Responsible (исполнитель), A — Accountable (отвечает за результат), C — Consulted (консультант), I — Informed (информируется).

Полная decision matrix: что выбрать на горизонте 1-12 месяцев

Горизонт	Roadmap-обязательство	Зрелость объёма работ	Рекомендация
< 3 мес	Жёсткое	Зрелый объём работ	Фича под ключ
3-6 мес	Жёсткое	Зрелый объём работ	Модуль под ключ
3-6 мес	Жёсткое	Развивающийся объём работ	Аутстафф + in-house TL
6-12 мес	Гибкое	Развивающийся объём работ	Аутстафф или гибрид
12+ мес	Постоянная функция	Развивающийся объём работ	Найм
6-12 мес	Жёсткое	Зрелый объём работ	Серия модулей под ключ

Антипример: «универсальная команда на все случаи»

Зрелая продуктовая компания на квартал нанимала «универсальную аутстафф-команду из 4 человек» под общую разработку. Структура: 1 PM, 1 frontend, 1 backend, 1 QA. Без специализации, без выделенного tech lead. За квартал команда:

Не закрыла ни одной из 3 запланированных roadmap-фич
Накопила технический долг ~150 человеко-часов
Расходовала 30% времени на «согласования» с разными in-house владельцами компонент
Сожгла 4,2 млн рублей на ставках

Альтернатива той же стоимости: 1 фича под ключ (1,5 млн ₽) + 1 модуль под ключ (2,5 млн ₽) с измеримыми результатами. Урок: «универсальная команда без фокуса» — это не команда, а 4 индивидуальных контрактника, каждый из которых не отвечает за общий результат.

Источники по теме формирования команды

«Team Topologies» (Manuel Pais, Matthew Skelton) — типы команд по специализации.
GitLab Handbook: Engineering Team Structure — открытая методология.
Хабр: статьи о составе продуктовой команды — практика российских компаний.
«Joel on Software» — классические эссе о найме и команде.

Связанные материалы — фича под ключ, найм senior-разработчика, аутстафф vs под ключ, контракты разработки.

Кейс: закрытие квартального roadmap-блока через двух senior на проект

Один из проектов 2026 года, который иллюстрирует модель «разработчики на проект под ключ» — расширение функциональности образовательной B2B-платформы (далее — Заказчик В). Контекст: SaaS-платформа корпоративного обучения, 180 клиентов, выручка ~140 млн рублей в год, in-house команда 12 разработчиков.

Задача. За квартал реализовать три связанных roadmap-фичи: 1) Модуль адаптивного тестирования с алгоритмом подбора сложности вопросов. 2) Аналитический дашборд прогресса учеников для HR-руководителей корпоративных клиентов. 3) Интеграция с двумя популярными корпоративными LMS-платформами для импорта пользователей.

Контекст принятия решения. In-house команда Заказчика В была загружена релизом мобильного приложения. CTO рассматривал три варианта: 1) Найм двух senior backend на квартал (нереалистично — рынок не отвечал, прошлая попытка дала 8 месяцев на одного человека). 2) Аутстафф четырёх middle-разработчиков на T&M (риск дрейфа объёма работ, сложно гарантировать качество). 3) Подряд под ключ на три фичи с фиксированной ценой и сроками.

Структура контракта. Не один общий контракт на «квартал работы», а три связанных контракта-обязательства: 1,8 млн на адаптивное тестирование (8 недель), 2,1 млн на аналитический дашборд (10 недель параллельно), 1,4 млн на интеграции LMS (6 недель в конце квартала). Команда — Solution Architect, два senior backend, один senior frontend (на дашборд), QA. Двухуровневое code review с in-house tech lead Заказчика В. SLA-период 2 месяца на каждую фичу.

Что получилось. Три фичи сданы в срок. Прохождение в среднем 92% критериев на первой приёмке. Передача за 4-6 недель на каждую фичу. Через 14 недель после окончания работ in-house команда Заказчика В самостоятельно поддерживала все три модуля, без обращений к нам за рамками SLA.

TCO квартала. Прямо: 5,3 млн рублей за разработку + 0,4 млн SLA = 5,7 млн. Альтернатива в найме: 2 senior × квартал × 0,35 ЗП + налоги + HR-расходы + потери на подключение пользователей + риски = ~4,8 млн прямых затрат, но: 0% вероятность найти двух senior за квартал по опыту прошлого года Заказчика В. По факту альтернативой был бы сдвиг релизов на квартал, потеря 2-3 крупных корпоративных контрактов (~25 млн рублей упущенной выручки). Прямая разница в TCO — около 1 млн в пользу под ключ; косвенная (упущенная выгода) — на порядок больше.

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

Сравнительная таблица: квартал работы — три модели

Параметры для одной квартальной задачи объёмом работ 1500-2500 человеко-часов (две связанные фичи или модуль среднего размера).

Параметр	Подряд под ключ	Аутстафф 3 разработчика	Найм 2 senior
Прямые затраты	3,5-5,5 млн ₽	4,2-5,8 млн ₽ (T&M)	2,5-3,2 млн ₽ (ЗП)
Налоги и страховые	0 (в стоимости)	0 (в стоимости)	0,8-1,0 млн ₽
HR-расходы	0	0	0,5-0,8 млн ₽
Подключение пользователей	0	0,2-0,3 млн ₽	0,5-0,8 млн ₽
Управление CTO (eq)	0,15 млн ₽	0,5-0,7 млн ₽	0,8-1,2 млн ₽
Риск разрыва оффера	0	0,05 млн ₽	0,3-0,5 млн ₽
Гарантия даты релиза	Да	Нет	Нет
Гарантия результата	Да (критерии приёмки)	Нет	Нет
Готовность к работе	Сразу	2-4 недели ramp-up	4-8 мес поиск + 1-2 мес ramp-up
Передача в in-house после	Включена	Нет (нет процесса)	Не применимо
Итого квартал	3,7-5,7 млн ₽	4,9-6,8 млн ₽	5,4-7,5 млн ₽ (плюс задержка релиза)

Под ключ выигрывает по гарантии даты и итоговому TCO для квартальных задач с зафиксированным объёмом работ.

Чек-лист подготовки к подряду на проект под ключ

Что должно быть готово на стороне клиента до подписания контракта на 3-7 млн рублей. Если хотя бы 4 пункта из 9 не выполнены — нужна discovery-фаза.

Список фич/модулей с приоритетами. Не «развитие продукта», а конкретные 1-4 deliverable.
Владелец продукта на каждый блок. Кто будет согласовывать критерии приёмки и проводить приёмку.
In-house tech lead для code review. Кто будет вторым уровнем code review с нашей стороны.
Доступ к репозиторию и документации архитектуры. Discovery невозможно без этого.
CI/CD клиента. Тесты должны проходить в его пайплайне, не в нашем.
Стандарты кода и архитектурные паттерны. Зафиксированы в репозитории; если нет — выяснить устно.
Roadmap на 3-6 месяцев вперёд. Чтобы понимать контекст приоритизации.
Бюджет и сроки. Не «обсудим», а конкретный бюджетный коридор и допустимые сроки.
Готовность к фиксированной цене. Не «давайте T&M, потом разберёмся».

Типовые ошибки CTO при подряде на серию проектов

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

Ошибка 1. «Один общий контракт на квартал». Соблазн упростить документооборот и подписать единый контракт на «квартал работы» с общим бюджетом. Результат — размытая ответственность, нет ясных дедлайнов на каждую фичу, change request’ы накапливаются. Стандарт — отдельный контракт на каждый функциональный блок.

Ошибка 2. Discovery-фаза «на потом». CTO хочет начать «прямо сейчас, чтобы успеть к дедлайну», discovery — на ходу. Результат — на 5-й неделе обнаруживаются архитектурные конфликты с существующим кодом, проект перепланируется. Discovery — 1-2 недели до старта основного контракта.

Ошибка 3. Внешняя команда без in-house tech lead. На стороне клиента нет выделенного tech lead, который code-reviewит каждый PR. Вендор работает в вакууме, архитектурное соответствие не проверяется. Через 3-4 месяца модули вендора и in-house расходятся. In-house tech lead — обязательное условие.

Ошибка 4. Слабый owner продукта на стороне клиента. Критерии приёмки согласованы с product manager, который не имеет полномочий принимать решения. На приёмке его правки противоречат подписанному контракту. Owner должен иметь mandate и право быстрого решения.

Ошибка 5. «Команда из senior — это слишком дорого». CTO выбирает вендора, обещающего цену на 30% ниже за счёт middle-разработчиков. На проекте 12 недель экономия 0,5-1 млн съедается доработками после сдачи и продлением SLA-периода. Senior-only — обоснованная цена, не премиум.

Ошибка 6. Игнорирование передачи. Контракт заканчивается сдачей кода. Никакого walkthrough, парного программирования, инструкции по эксплуатации. Через 2 месяца in-house команда жалуется, что код «непонятный». Передача — критическая часть, без неё проект не считается успешным.

Ошибка 7. Параллельный найм без координации с подрядной командой. CTO одновременно нанимает 2 senior на параллельный найм и не информирует подрядную команду. Когда найм проходит, in-house tech lead «возвращает себе» модули, которые делал вендор. Конфликты приоритетов, дублирование работы. Параллельный найм — нормально, но новые senior подключаются к проекту постепенно, не ломая текущую работу.

Внешние источники

«Death March» (Ed Yourdon) — про управление проектами с жёсткими дедлайнами.
«Domain-Driven Design» (Eric Evans) — про границы модулей и архитектурное соответствие.
«Software Estimation» (Steve McConnell) — про реалистичные оценки и фиксированную цену.
GitLab Handbook: Engineering Procedures — открытые процессы код-ревью и приёмки.
martinfowler.com/articles — паттерны интеграции внешних команд.

FAQ о разработчики на проект

Чем разработка под ключ отличается от аутстаффа и от найма?

Найм — вы строите команду в штате, платите зарплаты, делите ответственность за результат с командой. Срок до результата — от 3-6 месяцев на закрытие вакансий + 2-3 месяца онбординга. Аутстафф (аутстаффинг) — арендуете разработчиков у внешнего поставщика по часовой ставке (T&M). Вы получаете людей, а не результат. Дата релиза, объём работ и критерии приёмки — на вашей стороне. Бюджет открытый: «работа продлится, пока не закончится». Подряд под ключ — заказываете результат (фичу, модуль, интеграцию) с фиксированной ценой, фиксированной датой и измеримыми критериями приёмки. Команда у вендора, ответственность за результат у вендора. Срок 6-16 недель в зависимости от объёма. На квартал, на который у вас уходит закрытие 2-3 senior-вакансий, команда под ключ успевает сдать готовый продукт. Каждая модель подходит под свой кейс: длинные стратегические задачи — найм; гибкая R&D и расширение команды — аутстафф; конкретный roadmap-дедлайн с измеримым объёмом работ — подряд под ключ.

Сколько стоит реальный TCO найма senior-разработчика в РФ?

TCO найма senior-разработчика в Москве на 2026 год при зарплате на руки 350-450 тысяч рублей в месяц складывается из: 1) Зарплата + НДФЛ + страховые взносы = 1.55× от gross, то есть 540-700 тысяч в месяц. 2) Бонусы и премии — 10-15% годовых от зарплаты = 50-80 тысяч в месяц. 3) HR-расходы на найм — рекрутер, бонус, агентство, ATS — в среднем 700 тысяч - 1.5 млн рублей единоразово на закрытие одной вакансии. 4) Онбординг — первые 2-3 месяца производительности 30-50% от целевой, что эквивалентно потерям 800 тысяч - 1.5 млн на разработчика. 5) Оборудование, ПО, обучение, конференции — 100-200 тысяч в год. 6) Управленческие расходы (тимлид, HR, оффис, оборудование) — добавляют 30-40% к прямым затратам. Полный TCO senior-разработчика на горизонте года — 11-15 млн рублей. На квартал — 2.8-3.7 млн рублей. На 3 senior'а за квартал — 8-11 млн рублей при условии, что вакансии закрыты, а не висят.

Сколько занимает закрытие senior-вакансии в РФ?

Средние сроки закрытия senior-разработчика на 2026 год в Москве и Петербурге: backend Python/Go/Java — 3-5 месяцев, frontend React/Vue senior — 2-4 месяца, mobile iOS/Android senior — 4-7 месяцев, full-stack senior — 4-6 месяцев, специализированные направления (ML, security, DevOps senior) — 5-9 месяцев. Это медианные сроки от старта поиска до выхода на работу. После выхода — ещё 2-3 месяца на онбординг до полной производительности. Итого: senior реально работает на полную через 5-9 месяцев после решения «нанимать». На рынке дефицит, конкуренция за каждую вакансию между 5-15 работодателями. Это структурная проблема российского рынка с 2022 года, и она не улучшается. Для зрелого CTO планирование roadmap под найм senior-команды нереалистично, если дедлайн через 3-4 месяца.

Когда подряд под ключ выгоднее, когда найм, когда аутстафф?

Decision tree для CTO зрелой продуктовой компании. Найм выгоднее когда: горизонт задачи 2+ года, нужна постоянная команда с product knowledge, фича развивается итеративно с непредсказуемыми итерациями. Аутстафф выгоднее когда: нужно временно расширить in-house команду на 3-12 месяцев для R&D или пиковой нагрузки, объём работ меняется по ходу работы, и заказчик готов вести проект сам с открытым T&M-бюджетом. Подряд под ключ выгоднее когда: есть конкретный roadmap-дедлайн через 6-16 недель, объём работ можно зафиксировать заранее, нужен результат, а не процесс. Типичные кейсы для под ключ: новый модуль или сервис, добавляемый к зрелому продукту; интеграция с внешней системой; миграция функционала с одного стека на другой; backend для новой фичи, которую мобильная команда не успевает; временно недостающая компетенция (например, безопасность, ML, специфический DevOps). На квартал — подряд под ключ почти всегда дешевле и быстрее найма.

Что входит в результат под ключ?

Стандартный результат фичи под ключ или модуля: 1) Production-ready код в репозитории клиента с соответствием его coding standards и архитектурным паттернам. 2) Unit-тесты с покрытием 80%+ для критичной логики. 3) Integration-тесты для всех внешних интеграций. 4) Документация: README, архитектурное описание, API-спецификация (OpenAPI/Swagger), руководство по развёртыванию. 5) Инструкция по эксплуатации на 10 разделов: типовые ошибки и их разрешение, процедуры срочных исправлений, мониторинг и алерты, граничные сценарии. 6) Развёртывание на dev / staging / prod-окружениях клиента с использованием его CI/CD-пайплайнов. 7) Передача: 2-3 сессии с in-house командой клиента, парное программирование на первых срочных исправлениях, ответы на вопросы в течение 30-60 дней после сдачи. 8) Опциональный SLA-период 1-3 месяца с гарантированным временем реакции. Это набор по умолчанию, фиксируется в контракте. Дополнительные пункты (нагрузочное тестирование, performance-оптимизация под целевой SLA, инфраструктурный сетап) — отдельно по объёму работ.

Что такое объём работ и как его правильно сформулировать?

Объём работ — это формальное описание того, что входит и что не входит в проект под ключ. Хорошо составленный объём работ содержит: 1) Список функций с измеримыми критериями приёмки по каждой. Не «добавить поиск», а «поиск по полям A, B, C с фильтрацией по D, отдача результата за < 200 мс на 100 тысячах записей, поддержка пагинации». 2) Архитектурные ограничения — стек, фреймворк, паттерны, что можно и что нельзя. 3) Интеграции — какие API клиента и внешних систем нужно использовать, с какой логикой (REST, GraphQL, события, файлы). 4) Non-functional requirements — производительность, доступность, безопасность, локализация. 5) Что не входит — явный список вещей, которые объём работ не покрывает (например, «не делаем мобильную версию», «не делаем рефакторинг существующего модуля Х»). 6) Допущения и зависимости — на каких внешних факторах основана оценка (например, «клиент предоставит доступ к staging API внешнего сервиса до 1 февраля»). Объём работ формируется на этапе предпроектного обследования за 1-2 недели до подписания контракта. Это критический документ, потому что все споры в проекте под ключ решаются ссылкой на объём работ.

Что такое senior-only команда и зачем это нужно?

Senior-only — это принцип формирования команды на проект под ключ исключительно из разработчиков с реальным senior-уровнем по опыту, ответственности и техническому уровню. Это противоположность распространённой практике «продать senior, поставить middle с senior-title». Зачем senior-only: 1) На проекте под ключ 6-16 недель нет времени на обучение junior'ов и middle'ов специфике продукта клиента — senior разбирается быстрее. 2) Критерии приёмки — измеримые, senior может оценить риск и предложить компромисс, middle — нет. 3) Архитектурные решения принимаются на ходу, без согласований с тимлидом по каждому вопросу — это требует senior-уровня. 4) Снижение bus-факторов: senior'ы документируют и работают в стиле, понятном следующему разработчику. 5) Меньше команда — типовая команда под ключ 2-4 человека вместо 5-8 в аутстафф-модели, потому что каждый senior закрывает больше задач. Контрактно фиксируется в составе команды: количество и грейд каждой роли, рейт. Замена senior на middle без согласования с клиентом — нарушение контракта.

Как организовать параллельные проекты с одной внешней командой?

Стандартный паттерн для квартального roadmap-блока — серия из 2-4 связанных проектов с одной командой, без перегрузки. Принципы: 1) Контракты — раздельные, по одному на проект, с собственными критериями приёмки и датами. Не «общий бюджет на квартал». 2) Стартуют с интервалом 1-2 недели, чтобы команда могла перераспределять фокус по фазам (старт нового — приёмка предыдущего). 3) Solution Architect один на серию проектов, остаётся core-ролью на 12-14 недель. 4) Senior backend и frontend разделены между проектами: один project — owner у одного senior, другой — у другого. Минимизирует конфликт контекстов. 5) Двухуровневое code review одно на серию: тот же in-house tech lead клиента видит все PR'ы. Это даёт согласованность стиля. Анти-паттерн: одна большая команда на «общий объём работ квартала» без фиксации владельца на каждый блок — приводит к размыванию ответственности.

Что если roadmap меняется во время серии проектов?

Это нормальная ситуация для квартального горизонта. Стандартная процедура: 1) Контракты на не-стартовавшие проекты можно изменить или отменить без штрафа за 2-4 недели до старта (это фиксируется в контракте). 2) Уже стартовавшие проекты — change request с обоснованием изменения объёма работ, дополнительных часов и срока. 3) Если roadmap меняется радикально (например, отменён один из трёх проектов в середине квартала), команда либо разойдётся (по согласованию), либо подберём альтернативный блок работ. 4) Главное правило — изменения оформляются официально, не «давайте сделаем по-другому в чате». На практике в 80% квартальных серий из 3 проектов происходит 1-2 change request'а средней значимости, и серия не разваливается.

Может ли in-house tech lead клиента вести нашу внешнюю команду?

Не полностью, но частично — да, и это часто работает. Распределение ролей: 1) Наш Solution Architect — owner архитектуры проекта, ведёт ежедневную работу нашей команды, отвечает за результат. 2) In-house tech lead клиента — owner архитектурного соответствия (модуль вписывается в существующую архитектуру клиента) и code review на каждый PR. 3) Daily-синхронизация нашего Solution Architect и in-house tech lead клиента — 15-30 минут в день в первые 2-3 недели проекта, далее по необходимости. 4) Спорные архитектурные вопросы решаются их совместным обсуждением, не одним лицом. Анти-паттерн: in-house tech lead клиента полностью ведёт нашу команду как свою — это размывает ответственность и не оставляет нашему Solution Architect полномочий принимать решения. Контракт должен явно фиксировать: ответственность за результат у нашей команды, ответственность за архитектурное соответствие — совместная.