Как выбрать подрядчика для разработки ПО — процесс и чек-лист

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

Идти к подрядчику без требований — всё равно, что просить оценить ремонт квартиры по телефону. Вы получите вилку «от миллиона до двадцати», которая ничего не значит, а подрядчик потратит время на уточнения, которые вы могли сделать заранее.

Нужен документ. Не техническое задание на 200 страниц по ГОСТу, а структурированное описание того, что вы хотите получить.

Что должно быть в документе:

• Функциональные требования — что система делает, сценарии использования, роли пользователей
• Нефункциональные требования — ожидаемая нагрузка, требования к безопасности, интеграции с внешними системами, совместимость с устройствами
• Бизнес-контекст — зачем эта система нужна, кто ей пользуется, метрики успеха, что происходит сейчас без неё
• Ограничения — бюджетная рамка, жёсткие дедлайны, регуляторные требования, legacy-системы, с которыми нужно жить

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

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

Этап 2. Соберите предложения, которые можно сравнивать

Сначала — длинный список потенциальных контрагентов. Рейтинги, рекомендации коллег, профильные площадки. 10–15 компаний. Первичный фильтр: релевантный опыт в вашей отрасли, живое портфолио с описанием кейсов, а не просто список логотипов. Если на сайте подрядчика нет ни одного кейса с деталями — это красный флаг. Если написано «мы делаем всё» — ещё один.

Дальше начинается то, что отличает системный подбор от стихийного: RFP — Request for Proposal. Это не «пришлите КП». Это структурированный запрос, на который подрядчики отвечают в едином формате. Без этого вы получите 10 документов, которые невозможно сравнить: один подрядчик пришлёт презентацию на 40 слайдов, другой — письмо на полстраницы, третий — таблицу с часами.

Что отправляете подрядчикам:

• Описание проекта с приложением документа требований
• Единый шаблон ответа — какие разделы заполнить, в каком формате
• Критерии оценки — чтобы подрядчик понимал, по чему его будут оценивать
• Сроки подачи

Что должно быть в ответе подрядчика:

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

На этом этапе список сокращается до 5–7 компаний.

Этап 3. Сравнение цен: как понять, кто недозаложился

Это ключевой этап. Здесь теряются или экономятся миллионы.

Главное правило: самое дешёвое предложение — почти всегда самое дорогое. Не потому что дешёвые подрядчики плохие, а потому что низкая цена обычно означает, что в оценку не вошло что-то важное. И это «что-то» вы оплатите потом — через change requests, доработки или полную переделку.

Как разбирать предложения. Берёте 5–7 ответов, сводите в единую таблицу по одинаковым строкам: аналитика, дизайн, backend, frontend, тестирование, DevOps, управление проектом, документация. Смотрите на пропорции.

Красные флаги в декомпозиции:

• Тестирование — 5% от бюджета. Нормальная доля тестирования — 15–25%. Если заложено 5%, тестировать не будут. Баги найдут ваши пользователи в production. Или подрядчик придёт за доплатой, когда вы спросите: «а почему ничего не работает».
• Аналитика — 0%. Значит команда начнёт писать код без понимания задачи. Через месяц выяснится, что сделали не то.
• Нет DevOps и CI/CD. Деплой будет руками, без автоматизации. Каждое обновление — ручной процесс с рисками.
• Нет строки «документация». После проекта вы не сможете без дополнительных усилий передать продукт другой команде.
• Нет буфера на риски. Адекватный буфер — 10–20%. Если его нет, оценка нереалистична.

Что обычно забывают заложить — и заказчик узнаёт об этом после подписания контракта:

• Миграция данных из старой системы
• Интеграция с legacy через нестандартные API
• Нагрузочное тестирование (отдельная экспертиза, а не «мы нажмём F5 сто раз»)
• Обучение пользователей
• Поддержка и багфикс после запуска — первые 1–3 месяца
• Инфраструктура: серверы, лицензии, SSL-сертификаты, CDN

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

Этап 4. Личные презентации: выбираем ТОП-3

Коммерческое предложение показывает, что компания предлагает. Встреча показывает, как она думает.

На этом этапе вы приглашаете около 5 компаний на личную (или видео) презентацию их предложения. Каждая встреча — 1–2 часа.

На что обращать внимание:

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

Насколько глубоко разобрались в задаче. Подрядчик задаёт вопросы или презентует шаблон? Хороший подрядчик спросит: «Почему вы выбрали именно такую архитектуру? Мы видим альтернативы». Плохой кивнёт на всё и скажет «сделаем».

Задают ли неудобные вопросы. Если подрядчик на всё отвечает «да, конечно, без проблем» — это плохой знак. Любой сложный проект содержит компромиссы. Если подрядчик их не видит, он либо не разобрался, либо боится потерять сделку.

Вопросы, которые стоит задать:

• «Расскажите про проект, который пошёл не так. Что произошло и что вы сделали?»
• «Что бы вы изменили в наших требованиях?»
• «Кто конкретно будет работать над проектом? Можно поговорить с техлидом?»
• «Как вы сообщаете о проблемах и задержках? Покажите пример еженедельного отчёта.»

Как свести к ТОП-3. Скоринговая таблица по критериям: понимание задачи, релевантный опыт, качество команды, адекватность оценки, коммуникация. Каждый критерий — балл от 1 до 5. Субъективно, но структурирует решение и делает его прозрачным для всех заинтересованных лиц.

Этап 5. Тестовый контракт: проверка на совместимость

Не подписывайте контракт на 12 месяцев с компанией, с которой вы никогда не работали.

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

Тестовый этап: 2–4 недели, ограниченный скоуп. Варианты:

• Proof of Concept на одном модуле — проверить ключевую технологическую гипотезу
• Детальная аналитика и прототипирование (предпроектный анализ) — получить документ, по которому можно начинать разработку
• Аудит текущей системы, если вы модернизируете существующий продукт

Стоимость тестового этапа — 5–10% от общего бюджета проекта. Это страховка на 100% бюджета.

Что оцениваете:

• Скорость коммуникации — отвечают за час или за три дня?
• Качество артефактов — код, документация, отчёты
• Соблюдение сроков — обещали через неделю, сделали ли через неделю?
• Прозрачность — сообщают о проблемах сами или молчат до дедлайна?
• Человеческий фактор — насколько комфортно работать

Что делать, если тестовый этап провален? Берёте компанию №2 из ТОП-3 и повторяете. Вот зачем нужен ТОП-3, а не ТОП-1.

Этап 6. Заключение контракта

Тестовый этап прошёл хорошо. Вы готовы подписывать контракт на основной проект. На что обратить внимание:

• Скоуп первого этапа. Фиксируйте не весь проект, а первый этап с чёткими критериями приёмки в формате рамочного договора. Это снижает риск для обеих сторон.
• Условия изменений. Как меняется стоимость при изменении требований. Каждый change request — согласование и пересчёт, а не «сделайте ещё вот это в рамках бюджета».
• Владение кодом. Весь исходный код и интеллектуальная собственность принадлежат вам после оплаты. Это должно быть в договоре явно.
• Условия расторжения. Что происходит, если одна из сторон хочет выйти. Как передаются код и документация.
• Отчётность. Еженедельные отчёты, а не ежемесячные. Месяц без отчёта — это месяц без контроля.
• Поддержка после запуска. SLA на исправление багов: критические — в течение суток, остальные — в течение недели.

Резюме: 6 этапов выбора подрядчика

1. Требования — сформулируйте и согласуйте со стейкхолдерами до выхода на рынок
2. RFP — соберите предложения в едином формате от 10–15 компаний, отсейте до 5–7
3. Сравнение цен — разберите декомпозицию, найдите что не заложено, пересчитайте реальную вилку
4. Презентации — оцените команду и подход, сведите к ТОП-3
5. Тестовый контракт — 2–4 недели, проверка на совместимость в реальной работе
6. Контракт — фиксированный скоуп первого этапа, еженедельная отчётность, владение кодом

В зависимости от согласованности внутри компании, этот процесс занимает от 4 недель до 2 месяцев. Это кажется долго — до тех пор, пока вы не сравните с 6–12 месяцами переделок после неудачного выбора.