Разработка ПО под ключ 2026: фича, модуль, интеграция в зрелый продукт

Что этот материал описывает, а что нет. Это материал не про MVP с нуля — для запуска нового продукта см. отдельный гайд по разработке MVP под ключ. Здесь — про добавление функционала к зрелому продукту: фича, модуль или интеграция в существующую кодовую базу. Если нужна одна узкая фича за 6-12 недель — см. фичу под ключ. Если речь про отраслевую специфику (B2B SaaS, fintech, marketplace) — см. вертикальные решения.

Зрелый продукт — это не MVP. Архитектура устоявшаяся, кодовая база большая, команда in-house работает по своим конвенциям. Когда в roadmap появляется новая фича, модуль или интеграция, и она не помещается в текущую загрузку команды, выбор стандартный: нанимать ещё людей или отдать наружу. Найм занимает квартал и не гарантирует результат. Аутстафф даёт людей, но не результат. Разработка под ключ — третья альтернатива, специально заточенная под зрелые продукты: вендор делает результат за фиксированную цену и срок, встраиваясь в архитектуру клиента, без привязки к подрядчику, с честной передачей в in-house команду.

Эта статья — для CTO зрелой продуктовой компании 100-1000 человек. Внутри: подробный разбор результата разработки под ключ, стандарты инструкции по эксплуатации и передачи, принципы senior-only и двухуровневого code review, контрактная структура, типовые ошибки CTO при работе с вендорами под ключ.

Три формата работы под ключ

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

Фича под ключ. Одна функция или связка функций, добавляемая к существующему продукту. Примеры: новая страница в SaaS-приложении с собственной логикой; новый тип уведомлений; SSO-интеграция; экспорт в новый формат; рекомендательный модуль; функция шеринга. Команда 2-3 человека (Solution Architect + 1-2 senior разработчика), срок 6-12 недель, бюджет 1.5-4 млн рублей.

Модуль под ключ. Самостоятельный модуль или сервис, выделенный в отдельную часть архитектуры. Примеры: платёжный модуль; отдельный сервис нотификаций; модуль отчётности; модуль управления доступами; биллинговый модуль; кэш-слой. Команда 3-5 человек, срок 10-16 недель, бюджет 3-6 млн рублей.

Интеграция под ключ. Соединение с внешней системой или внутренним legacy. Примеры: интеграция с CRM, с ERP, с банком, с маркетплейсом, с оператором связи, со специфической отраслевой системой. Команда 2-3 человека, срок 8-14 недель, бюджет 2-5 млн рублей. Особенность — много работы с чужими API и протоколами, важна готовность партнёра к интеграции.

Формат	Команда	Срок	Бюджет
Фича под ключ	2-3 чел.	6-12 нед	1.5-4 млн ₽
Модуль под ключ	3-5 чел.	10-16 нед	3-6 млн ₽
Интеграция под ключ	2-3 чел.	8-14 нед	2-5 млн ₽

Для проектов вне этих диапазонов (например, новый продукт с нуля, рефакторинг ядра системы, миграция всей архитектуры) модель под ключ работает плохо. Это либо проектная разработка с другим контрактом (project-based), либо строительство нового продукта (см. наш партнёрский сайт по разработке MVP — primeit.ru).

Полный стек результата

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

Production-ready код

В репозитории клиента (GitHub, GitLab, Bitbucket — где у клиента), не у вендора. Это критично для отсутствия привязки к подрядчику: после сдачи весь код в собственности клиента, доступен для всех его процессов разработки.

Соответствие стилю и архитектурным паттернам клиента. Мы изучаем существующие модули, документацию, ADR (Architecture Decision Records), общаемся с tech lead клиента до старта разработки. Код пишется в стиле «как мог бы написать сам клиент», а не «по-своему». Это требует senior-уровня — middle часто пишет в своём стиле, и в результате модуль остаётся чужеродным.

CI/CD-интеграция с первого дня. Все билды проходят через CI клиента, не через отдельную среду вендора. Это снимает риск «у нас на серверах работает».

Тесты

Unit-тесты для критичной логики с покрытием 80%+. Не «тесты для галочки», а тесты, которые реально проверяют поведение функций, обработку граничных случаев, ошибочные ветки.

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

End-to-end тесты для критичных бизнес-сценариев (если применимо). Цель — после deploy в production первые проблемы ловятся тестами, не пользователями.

Документация

README — краткое описание модуля, инструкция по локальному запуску, чек-лист первого запуска для нового разработчика.

Архитектурное описание — диаграмма компонентов (C4 model или аналог), схема данных, последовательности для ключевых сценариев, ссылки на ADR.

API-спецификация — OpenAPI 3.x для REST API или GraphQL schema. Это формальный контракт между нашим модулем и in-house модулями клиента.

Deployment guide — как развернуть модуль на разные окружения (dev, staging, prod), список переменных конфигурации, секретов, зависимостей.

Инструкция по эксплуатации

Операционная документация для in-house команды. См. отдельный раздел ниже.

Развёртывание

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

Передача

См. отдельный раздел ниже.

Инструкция по эксплуатации: 10 разделов в стандарте

Главный документ для in-house команды клиента. Без инструкции по эксплуатации передача не работает.

1. Архитектура высокого уровня. Одна страница: диаграмма компонентов, ключевые потоки данных.

2. Зависимости. Внешние сервисы (API, СУБД, кэш, очереди), их версии, точки failover’а.

3. Развёртывание и rollback. Как развернуть модуль, как откатить, типовое время операций, проверки после деплоя.

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

5. Мониторинг и алерты. Какие метрики мониторить, какие пороги для алертов, ссылки на dashboards.

6. Типовые ошибки и решения. Топ-15 ошибок, которые мы видели в процессе разработки, или которые ожидаются в production. Каждая ошибка → симптом → диагностика → решение.

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

8. Performance. Где узкие места, какие операции дорогие, как профилировать, какие настройки тюнить.

9. Security. Режим доступов, кто что может, аудит-логи, security-инциденты и реакция.

10. FAQ. Частые вопросы in-house команды, которые мы собрали по ходу проекта.

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

Передача: без привязки к подрядчику

Цель — клиент полностью владеет продуктом и может развивать его без зависимости от вендора.

Структура передачи на 30-60 дней:

Этап 1 (первые 2 недели). Walkthrough архитектуры и кода. 2-3 сессии по 2-3 часа с in-house tech lead клиента. Объяснение архитектурных решений, разбор кодовой базы по модулям, обзор тестов, объяснение нестандартных мест.

Этап 2 (вторые 2 недели). Demo по инструкции. Проход по 10 разделам инструкции по эксплуатации, типовые сценарии операций. Тренировка типовых проблем (например, «БД упала, что делать»).

Этап 3 (3-4 неделя). Парное программирование на первых срочных исправлениях. Когда возникает первый баг в production — разработчик клиента пишет фикс, наш senior смотрит на ходу, объясняет. На втором срочном исправлении — наоборот: наш senior пишет, разработчик клиента проверяет.

Этап 4 (5-8 неделя). Самостоятельная работа клиента. Клиент закрывает следующие баги полностью самостоятельно. Мы доступны на консультации в течение 30-60 дней (не более 2-4 часов в неделю — это включено в стоимость).

Метрика готовности — «первое срочное исправление без нашего участия». Когда клиент закрыл баг полностью сам, без вопросов к нам — передача считается завершённой. Это объективная проверка, что мы не оставили чёрный ящик.

После передачи клиент решает: продолжать ли отношения с нами (SLA-период, расширение, новые проекты) или развивать модуль полностью in-house.

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

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

Зачем senior-only:

• На 6-16-недельном проекте нет времени на обучение junior’ов специфике продукта
• Senior может принимать архитектурные решения на ходу, без согласований
• Меньше команда — типовая 2-4 человека вместо 5-8 в аутстафф-модели

Двухуровневое code review. Каждый PR проходит:

1. Code review у tech lead вендора — качество кода, архитектурное соответствие, тесты
2. Code review у in-house tech lead клиента — product knowledge, соответствие внутренним конвенциям, понимание long-term impact

Без двух approval PR не мержится. Это защита от «улёта в архитектурную фантазию» и от ошибок, которые видны только при глубоком знании продукта клиента.

Контракт: структура и платежи

Стандартный контракт разработки под ключ имеет несколько ключевых разделов:

1. Объём работ (приложение 1). Детальный документ с функциями, критериями приёмки, ограничениями. Это главный документ, на который все ссылаются в спорах.

2. Состав команды (приложение 2). Грейды, имена (или anonymized profiles), рейты per-person.

3. График платежей. Стандарт — 30% при подписании, 30% при промежуточной приёмке (середина проекта), 40% при финальной приёмке.

4. Acceptance procedure. Как клиент проверяет результат, сроки приёмки (обычно 5-10 рабочих дней), процедура замечаний, число итераций по замечаниям.

5. Change requests. Как оформляются и оплачиваются изменения объёма работ.

6. SLA-период. Что входит в гарантию после сдачи (обычно 1-3 месяца с P1 < 4 часов).

7. Передача. Что включает, ответственности сторон, метрика готовности.

8. IP и code ownership. Весь код, который мы пишем для клиента, переходит в его собственность с момента оплаты соответствующего этапа.

Change requests: правила обращения с изменениями

В 6-16-недельном проекте 1-3 change request — норма. Если больше 5 — это сигнал, что предпроектное обследование было неполным.

Стандартная процедура CR:

1. Клиент или вендор инициирует обсуждение изменения объёма работ
2. Вендор оценивает: дополнительные часы команды, влияние на сроки, влияние на бюджет
3. Оформляется CR: «Добавление функции X — +120 часов, +900K рублей, +2 недели к дате релиза»
4. Клиент подписывает или отклоняет CR
5. Если подписан — объём работ обновляется, новые критерии приёмки включаются в финальную приёмку

Главное правило — никаких изменений объёма работ без CR. Иначе ломается контракт с фиксированной ценой. Параллельно — никакого «давайте сделаем по дороге», когда клиент устно просит добавить мелочь. Это путь к спорам.

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

Ошибка 1: Размытый объём работ. Контракт подписан с объёмом работ «сделать платёжный модуль». Через 3 недели начинаются споры: «а это входит?», «а оплата по разным платёжным методам — это одно или несколько?». Стандарт — предпроектное обследование 1-2 недели с детальным объёмом работ и критериями приёмки.

Ошибка 2: Игнорирование архитектурного align. Клиент даёт объём работ, не даёт доступ к существующему коду и архитектуре. Через 4 недели обнаруживается, что наш модуль не вписывается в кодовую базу. Стандарт — предпроектное обследование включает walkthrough кодовой базы и согласование архитектурного решения с tech lead клиента.

Ошибка 3: Отсутствие in-house tech lead на проекте. У клиента нет выделенного человека, который смотрит наши PR, отвечает на архитектурные вопросы. В результате коммуникация ломается, PR накапливаются, передача не работает. Стандарт — у клиента выделен tech lead, минимум 4-8 часов в неделю на проект.

Ошибка 4: Поздний старт передачи. Передача начинается за 1-2 недели до окончания проекта. In-house команда не успевает разобраться, после сдачи продукт остаётся чёрным ящиком. Стандарт — передача параллельно последней трети проекта.

Ошибка 5: Игнорирование SLA-периода. Контракт без SLA-периода. После сдачи возникает баг — никто не отвечает. Стандарт — SLA 1-3 месяца с P1 < 4 часов в контракте.

Ошибка 6: Отсутствие плана развития после сдачи. Модуль сдан, но дальнейшее развитие не запланировано. In-house команда не успевает встроить модуль в свой roadmap, и он становится устаревшим. Стандарт — план развития на 6-12 месяцев после сдачи, либо передача в in-house roadmap.

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

Сравнительная таблица: что входит в «под ключ»

Компонент	Минимальный под ключ	Расширенный под ключ	Full-cycle разработка
Предпроектное обследование, ТЗ	Опционально	Включено	Включено
Архитектура (ADR, диаграммы)	Включено	Включено	Включено
Production-ready код	Включено	Включено	Включено
Unit + Integration тесты	Включено	Включено	Включено
E2E + нагрузочные тесты	Опционально	Включено	Включено
Документация (README, API)	Включено	Включено	Включено
Инструкция по эксплуатации на 10 разделов	Опционально	Включено	Включено
Передача 30-60 дней	Опционально	Включено	Включено
SLA-период 1-3 мес	Опционально	Включено	До 12 мес
Развёртывание и CI/CD	Опционально	Включено	Включено
Управление облачной инфраструктурой	Не включено	Опционально	Включено
Длительная поддержка 12+ мес	Не включено	Не включено	Включено

Минимальный под ключ подходит зрелой in-house команде, которая возьмёт на себя передачу и эксплуатацию. Расширенный подряд под ключ — стандарт для зрелых продуктовых компаний без избытка тактических ресурсов. Full-cycle — для стартапов раннего этапа, у которых нет своей команды вообще.

Контракты с фиксированной ценой vs T&M: расширенный разбор

В разделе контракты разработки — подробный разбор моделей. Краткое резюме для разработки под ключ: 90% контрактов под ключ оформляются по фиксированной цене. T&M используется только в исключительных случаях — длинная разработка с непрогнозируемым объёмом работ или когда заказчик хочет полного контроля над архитектурными решениями.

Защита заказчика при фиксированной цене: критерии приёмки + штрафы за просрочку + SLA-период. Защита подрядчика: процедура change request + лимит изменений в пределах изначального объёма работ. При нарушении этого баланса контракт оказывается выгодным только одной стороне, что в перспективе разрушает отношения.

TCO разработки модуля под ключ на горизонте 24 месяца

Статья	Сумма, млн ₽
Разработка модуля с фиксированной ценой (10-16 нед)	4,5
Передача 60 дней	Включено
SLA-период 3 мес	0,3
Эксплуатация in-house (зарплата 0,5 sr × 24 мес)	4,2
Минорные доработки (изменения регуляторики и т.п.)	0,5
Инфраструктура (cloud, мониторинг)	0,5
Итого TCO 24 мес	10,0

Альтернатива той же функциональности через найм 2 senior на 6 месяцев разработки + 18 месяцев поддержки:

Статья	Сумма, млн ₽
Поиск 2 senior (5 мес рекрутинга)	0,8 (HR + потерянная скорость)
2 senior × 24 мес × 0,35 млн ЗП	16,8
Налоги (~30%)	5,0
Потери на подключение пользователей (8 нед × 2 чел × 50%)	0,7
Управление tech lead (15% × 24 мес × 1 млн eq)	3,6
Инфраструктура	0,5
Risk-adjusted уход одного из senior (30% × 1 чел × 4 мес поиска замены)	1,0
Итого TCO 24 мес	28,4

Разница — 2,8 раза. Это типичная экономика разработки под ключ для зрелой компании. Найм оправдан только в одном случае: функция нужна постоянно, и есть стабильный поток фич на следующие 24+ месяцев для тех же двух senior. Иначе после первого модуля они сидят на bench или ищутся новые задачи, что снижает их продуктивность.

Антипример: под ключ без критериев приёмки

В разделе фича под ключ описан кейс fintech-проекта с провалом по причине отсутствия критериев приёмки. То же правило применимо к разработке под ключ в целом: без формальных критериев приёмки оба участника контракта оказываются в правовом тумане. Подрядчик считает «всё сделано», заказчик — «не работает». Споры решаются через суд, который не имеет компетенции в IT-специфике и обычно ссылается на условия контракта. Если в контракте только «выполнить разработку модуля» — суд встанет на сторону формального исполнителя.

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

• «The Mythical Man-Month» (Brooks) — классическая работа о фиксированной цене и сроках в разработке.
• «Software Estimation» (McConnell) — методики оценки проектов с фиксированной ценой.
• Хабр: программная инженерия — российская практика проектов под ключ.
• GitHub Engineering Blog — open-source практики разработки.

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

Кейс: модуль маркетплейс-интеграций для логистической платформы

Один из проектов, который иллюстрирует разработку под ключ для зрелого продукта — модуль интеграций с маркетплейсами для b2b-логистической платформы (далее — Заказчик Б). Контекст: SaaS-платформа управления курьерскими доставками для интернет-магазинов, 320 корпоративных клиентов, выручка ~280 млн рублей в год, in-house команда 18 разработчиков.

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

Контекст принятия решения. In-house команда Заказчика Б была загружена релизом нового приложения для курьеров. CTO оценил: либо отодвинуть релиз приложения на квартал, либо нанимать ещё команду (4-6 месяцев процесса). Выбор — отдать наружу под ключ с условием, что архитектура модуля интегрируется в существующий монолит без рефакторинга ядра.

Архитектурное соответствие. До подписания контракта была проведена двухнедельная фаза discovery: наш Solution Architect изучил архитектуру Заказчика Б (Django-монолит на ~250 тысяч строк, PostgreSQL, Redis, очереди на RabbitMQ). Согласовали: модуль будет реализован как отдельное Django-приложение в том же монолите, без выделения микросервиса; интеграции — через выделенный паттерн Adapter с фабрикой, чтобы добавление нового маркетплейса было feature-flag-управляемым. ADR (architectural decision record) на 8 страниц зафиксирован в репозитории Заказчика Б до старта основной разработки.

Объём работ. 1) Базовая инфраструктура модуля — модели данных, миграции, аутентификация в API маркетплейсов, обработка rate limiting. 2) Адаптеры под три маркетплейса — каждый со своей спецификой API. 3) Синхронизация заказов в обе стороны с разрешением конфликтов. 4) Синхронизация остатков (push/pull в зависимости от маркетплейса). 5) Webhook-обработка статусов и нотификации клиентам. 6) Админ-панель управления подключениями. 7) Мониторинг и алерты на расхождения.

Контракт. Фиксированная цена 4,2 млн рублей, срок 14 недель, 92 критерия приёмки. Команда — Solution Architect, три senior backend, один senior DevOps part-time, QA. Двухуровневое code review с in-house tech lead Заказчика Б. SLA-период 3 месяца с реакцией P1 < 1 час (важно для production-критичного интеграционного модуля).

Что получилось. Сдача с задержкой 4 рабочих дня по причине неожиданного изменения API одного из маркетплейсов на 12-й неделе. Прохождение 89 из 92 критериев на первой приёмке. Инструкция по эксплуатации на 54 страницы. Передача за 6 недель: walkthrough архитектуры, разбор адаптеров по типовым сценариям, парное программирование на трёх production-багах. За SLA-период — 3 P1-инцидента (все связаны с изменениями API маркетплейсов на стороне самих маркетплейсов), реакция в среднем 42 минуты, фикс — в 1,8 часа.

TCO на горизонте 24 месяца. Прямо: 4,2 млн разработка + 0,4 млн SLA + 0,8 млн расширение модуля под четвёртый маркетплейс через 14 месяцев = 5,4 млн рублей. Альтернатива в найме: 3 senior на 6 месяцев разработки + 18 месяцев поддержки = 3 × 24 × 0,35 = 25,2 млн прямых ЗП + 7,5 млн налогов + HR/риск/инфраструктура ≈ 35 млн рублей. Разница — 6,5х в пользу под ключ для разовой функциональности, которая не требует постоянного development’а.

Урок. Архитектурное соответствие — главный фактор успеха проекта под ключ для зрелого продукта. Без предварительной discovery-фазы с участием Solution Architect модуль был бы реализован «по нашим паттернам», что сделало бы in-house поддержку дорогой и потребовало рефакторинга через 12 месяцев. Discovery — это 5-10% бюджета, но 80% риска проекта.

Decision tree: разработка под ключ vs аутстафф vs найм для зрелого продукта

Чек-лист для CTO, который выбирает модель закрытия roadmap-задачи.

Выбирайте разработку под ключ, если:

• Roadmap-задача — функциональный блок объёмом работ 6-16 недель с понятными границами
• Архитектурно блок умещается в существующий продукт без переписывания ядра
• Есть владелец продукта, способный сформулировать измеримые критерии приёмки
• Дата релиза критична — есть жёсткий внешний дедлайн или зависимость от других команд
• In-house команда загружена и не может выделить 2-4 senior на 3-4 месяца
• Готовы к фиксированной цене и формальной приёмке
• Есть бюджет на 2-7 млн рублей за модуль или 1,5-3,5 млн за фичу

Выбирайте аутстафф, если:

• Объём работ не зафиксирован, направление будет уточняться 4-8 месяцев
• Сильный in-house tech lead, который ведёт разработчиков
• Бюджет T&M с принятием рисков по дате релиза
• Длинная разработка с переменными приоритетами

Выбирайте найм, если:

• Направление развития требует постоянной команды на 18-24+ месяцев
• HR-ресурс позволяет вести 4-6 месяцев поиска
• Бюджет на 30-50 млн рублей TCO на горизонте 24 месяцев для 2-3 senior
• Стратегическая важность: эта функциональность — core product

Сравнительная таблица: TCO модуля под ключ на 24 месяца

Развёрнутый расчёт для типового модуля под ключ объёмом работ 1500-2500 человеко-часов, который после сдачи поддерживается in-house командой.

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

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

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

Перед подписанием контракта на 3-7 млн рублей проверьте вендора по следующим пунктам.

• Опыт. 3+ проекта под ключ в той же категории за последние 2 года, с возможностью получить обратную связь от заказчиков.
• Senior-only состав. Минимум middle+ уровень в команде. Уровни уточняются на интервью с tech lead вендора и Solution Architect.
• Discovery-фаза в предложении. Вендор сам предлагает 1-3 недели discovery до основного контракта. Если предлагают сразу «давайте начнём, по ходу разберёмся» — это красный флаг.
• Готовность к двухуровневому code review. Каждый PR — code review нашего senior + code review in-house tech lead клиента. Без этого качество архитектурного соответствия не контролируется.
• Стандарт инструкции по эксплуатации. Спросите шаблон документа. Если шаблона нет — вендор не передавал проекты в in-house, передача будет первой попыткой.
• Структура контракта. Фиксированная цена + критерии приёмки + SLA-период. Не «time & materials», не «agile-разработка без дедлайна».
• Готовность к change request-процедуре. Должен быть формальный процесс. Скрытое расширение объёма работ — антипаттерн.
• Архитектурное соответствие. Вендор изучает существующую архитектуру клиента и встраивается в неё. Не «давайте у нас всё на микросервисах», если у клиента монолит.
• Передача и парное программирование. Включены в стоимость. Не отдельная опция.