Как выбрать IT-подрядчика: критерии, красные флаги, контракт

Введение. Подрядчик определяет не только код, но и темп обучения организации работать с цифровым продуктом. Материал для product- и engineering-лидеров, которые принимают решения на горизонте 12–24 месяцев, а не гонятся за хайпом в презентации.

Как считать подрядчика

Большинство срывов в теме «выбор IT-подрядчика» начинается не с кода, а с размытого scope: маркетинг обещает одно, продажи фиксируют другое, а ИТ закрывает техдолг третьим приоритетом. В итоге бюджет уходит в интеграции «на скотч» и ручные сверки в Excel. Мы видим это в проектах, где не описаны границы MVP, нет владельца метрик и не зафиксированы SLA на данные между системами.

Проекты с подрядчиком без зафиксированного scope и критериев приёмки перерасходуют 20–40% бюджета уже на стадии MVP — не из-за некомпетентности, а потому что «доделаем по ходу» заказчик и вендор понимают по-разному. Без письменного definition of done смета — ориентир, а не обязательство.

Критерии выбора

Опорный принцип: сначала поток ценности, потом стек. Нарисуйте journey от первого касания до оплаты и поддержки, отметьте ручные шаги и точки отказа. Только после этого выбирайте кастомная разработка и модель данных. Для выбор IT-подрядчика мы обычно рекомендуем бриф → shortlist → техническое интервью → пилот → контракт с этапами приёмки: она даёт предсказуемый TCO и не блокирует масштабирование команды.

Зафиксируйте ADR по ключевым решениям: хранилище, очереди, авторизация, наблюдаемость. Включите в Definition of Done контрактные тесты API, схему событий и политику миграций. корпоративный сайт имеет смысл заказывать только когда есть согласованный backlog с приоритетами P0/P1 и измеримые KPI на квартал.

Прозрачность процесса — это не «еженедельный созвон», а доступ к трекеру задач, репозиторию и билд-логам в реальном времени. Без этого о срыве сроков узнают постфактум, на демо. Требуйте доступ к staging и CI на старте, а не после подписания финального акта.

Риски фиксированной сметы и time&material

Кейс A (производство). Клиент пришёл с болью: прошлый подрядчик без документации. Мы разбили релиз на три волны: стабилизация данных, автоматизация рутины, персонализация. Через 14 недель новый vendor восстановил CI и передал runbook за 6 недель. Критично было не «переписать всё», а остановить утечку лидов на стыке каналов.

Кейс B (стартап). Другая ситуация: фикс-цена без discovery. Здесь сработала обратная стратегия — сначала интеграция с CRM и нормализация справочников, затем редизайн витрины. Итог: time & materials с cap и weekly demo снизили конфликты.

Процесс discovery

1. Выбор по цене без сопоставимого объёма работ в смете.
2. Пропуск технического интервью — решение принимают только по питчу sales.
3. Фикс-цена на проект с неопределённым scope, который неизбежно «поплывёт».
4. Отсутствие проверки референсов у реальных клиентов, а не только кейсов на сайте.
5. Подписание договора без явных условий передачи кода и доступов при разрыве отношений.

Договор и SLA

• [ ] В договоре явно прописана передача исходного кода и доступов
• [ ] Определена модель (fixed / T&M / гибрид) под конкретный этап
• [ ] Есть SLA на реакцию по критичным багам после запуска
• [ ] Прописан порядок change request и его влияние на смету
• [ ] Проверены референсы минимум у двух прошлых клиентов
• [ ] Критерии приёмки согласованы на каждом этапе, а не только в конце

Чеклист перед подписанием

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

• Релевантные кейсы за 2 года
• Прозрачная смета по этапам
• Референсы на поддержку

Критерии отбора

Выбор IT-подрядчика — это оценка fit по домену, процессу и прозрачности сметы. Запросите 2–3 релевантных кейса с контактами, не только скриншоты. Проверьте, как ведут discovery: есть ли workshop, backlog, критерии приёмки. Red flags: фикс-цена без scope, «сделаем как у Apple» без метрик, отсутствие тестов и staging. Сравните бриф ответы: кто задаёт неудобные вопросы про данные и интеграции — тот снижает риск.

Модель контракта: T&M с cap для discovery, fixed scope для MVP после согласованного ТЗ. IP, доступ к репозиторию, документация и bus factor — в договоре, не устно. Пилот 4–6 недель на ограниченный модуль дешевле, чем разрыв контракта через полгода. Оценка через смету должна раскладываться на фазы, а не одной цифрой «под ключ».

Проверьте процесс post-launch: SLA на баги, кто on-call, как передаётся документация. Спросите про последний провальный релиз и что изменили в процессе — честный ответ ценнее идеального кейса. Разделите вендоров на «body shop» и «product partner» по глубине вопросов на discovery. NDA и доступ к staging до подписания — нормальная практика для кастомной разработки.