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

⏱ 16 минут чтения

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

По данным Standish Group (CHAOS Report 2024), 66% корпоративных IT-проектов выходят за рамки бюджета или сроков, а 19% признаются провальными. Главная причина — не технические ограничения, а ошибки при выборе исполнителя. Этот чек-лист создан на основе опыта IT Integration (Москва, Инновационный центр Сколково) и десятков корпоративных проектов, чтобы помочь вам принять обоснованное решение и защитить его перед CEO.

Зачем нужен чек-лист выбора подрядчика

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

Три главные боли корпоративного заказчика

Срыв сроков. Подрядчик обещал MVP за 3 месяца, а через полгода просит ещё два. Руководство требует отчёт, а показать нечего. По статистике PMI (Project Management Institute), 48% IT-проектов не укладываются в первоначальные сроки. Для корпоративного клиента это означает не просто задержку — а перенос бюджетных циклов, срыв презентации для совета директоров и потерю конкурентного окна.

Раздувание бюджета. Начинали с 2 миллионов, а итоговый счёт — 7. «Появились дополнительные требования», «нужно было переделать архитектуру», «не учли сложность интеграций». В модели time & materials перерасход на 100-200% — не исключение, а статистическая норма. Финдиректор задаёт неудобные вопросы, а продукт-менеджер не может объяснить, почему цифра выросла втрое.

Некачественный код. MVP запущен, но при первых 50 пользователях падает, не масштабируется, содержит уязвимости. Подрядчик использовал джунов вместо заявленных сеньоров, не писал тесты, не документировал API. Результат — либо дорогостоящий рефакторинг, либо полное переписывание. По данным CISQ (Consortium for IT Software Quality), стоимость исправления технического долга в enterprise-проектах составляет в среднем $3.61 на каждый доллар разработки.

Почему интуиция не работает

«У них красивый сайт», «знакомый порекомендовал», «они дешевле остальных» — три самых распространённых (и самых ненадёжных) аргумента при выборе подрядчика. Красивый сайт не гарантирует качество кода. Рекомендация знакомого не учитывает специфику вашего проекта. А самая низкая цена часто означает самую высокую итоговую стоимость — через доработки, исправления и переделки.

Системный подход к выбору подрядчика для разработки через формализованные критерии снижает риск провала проекта на 40-60% (Harvard Business Review, 2023). Ниже — структурированный чек-лист, который можно использовать как рабочий инструмент для тендера или внутреннего согласования.

Студия vs аутсорс vs штат — сравнительная таблица для корпорации

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

Критерий	Продуктовая студия	Аутсорс-компания	Собственная команда (in-house)
Сроки запуска	2-6 недель (команда готова)	1-3 месяца (формирование под проект)	3-6 месяцев (найм + онбординг)
Стоимость MVP	500K-2M руб. (фиксированная)	1-5M руб. (по часам, T&M)	3-10M руб. (зарплаты + инфра)
Предсказуемость бюджета	Высокая (фикс в договоре)	Низкая (оплата по факту)	Средняя (фиксированные ФОТ)
Качество кода	Enterprise-уровень (специализация)	Зависит от выделенной команды	Зависит от найма
Продуктовая экспертиза	Встроена (помогают с ТЗ, UX, аналитикой)	Только реализация по ТЗ	Зависит от квалификации
Масштабирование	Передача кода + документация	Зависимость от подрядчика	Полный контроль
Корпоративный compliance	NDA + SLA + акты	NDA + SLA + акты	Внутренние политики
Риск vendor lock-in	Низкий (код передаётся)	Средний (без документации)	Нулевой
Когда выбирать	MVP, пилотные проекты, валидация гипотез	Масштабные проекты с детальным ТЗ	Стратегический продукт компании

10 критериев выбора IT-подрядчика

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

1. Портфолио и кейсы (вес: 15/100)

Не количество проектов в каталоге, а релевантность вашей задаче. Что проверять:

Есть ли проекты в вашей отрасли или смежных
Есть ли корпоративные клиенты (не только стартапы)
Указаны ли конкретные метрики результата (конверсия, нагрузка, ROI)
Можно ли связаться с клиентами для получения отзывов
Код проектов доступен для аудита (GitHub, демо-доступ)

Красная линия: если в портфолио только лендинги и интернет-магазины, а вам нужен enterprise-продукт с интеграциями — это несовпадение уровня.

2. Технический стек (вес: 12/100)

Стек должен соответствовать задаче, а не моде. Что проверять:

Совместимость с вашей корпоративной инфраструктурой
Зрелость и поддержка выбранных технологий (не экспериментальные фреймворки)
Наличие экспертизы в AI/ML, если проект предполагает AI-компоненты
Возможность масштабирования стека под будущий рост
Документация по архитектурным решениям

3. Команда и компетенции (вес: 15/100)

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

Кто конкретно будет работать над вашим проектом (поимённо)
Уровень разработчиков (сеньоры vs джуны) — попросите резюме или LinkedIn-профили
Наличие выделенного проект-менеджера или product owner'а
Стабильность команды (текучка — красный флаг)
Готовность к техническому интервью ключевых специалистов

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

4. Процессы разработки (вес: 10/100)

Наличие выстроенных процессов отличает зрелую команду от «группы фрилансеров с ООО». Что проверять:

Методология: Scrum, Kanban или гибрид с фиксированными спринтами
Code review на каждый pull request
Автоматическое тестирование (unit, integration, e2e)
CI/CD пайплайн для автоматического деплоя
Система управления задачами (Jira, Linear, Notion) с доступом для заказчика

5. Коммуникация и отчётность (вес: 12/100)

Для продукт-менеджера, который отчитывается перед руководством, прозрачность процесса — не «бонус», а необходимость. Что проверять:

Частота и формат отчётов (еженедельные демо, письменные саммари)
Каналы связи (Slack, Telegram, email) и время реакции (SLA на ответ)
Доступ к трекеру задач в реальном времени
Готовность к внеплановым звонкам и эскалациям
Помощь в подготовке отчётов для руководства

6. Юридическая чистота (вес: 10/100)

Корпоративный клиент не может работать с «ИП Иванов без договора». Что проверять:

Юридический статус: ООО с историей не менее 2-3 лет
Финансовая стабильность (проверка по СПАРК, Контур.Фокус)
Отсутствие судебных споров с клиентами
Готовность работать по вашему договору (а не только по своему шаблону)
Налоговая чистота и отсутствие признаков «технической» компании

7. NDA и безопасность (вес: 8/100)

Подписание NDA до предоставления детальной информации о проекте
Политика хранения данных и доступа к репозиториям
Соответствие ФЗ-152 (защита персональных данных)
Процедура передачи и удаления данных после завершения проекта
Опыт работы с compliance-требованиями корпоративных клиентов

8. SLA и гарантии (вес: 8/100)

Гарантийный период после сдачи (минимум 2 недели, оптимально — 1-3 месяца)
SLA на исправление критических багов (4-8 часов)
Условия технической поддержки после гарантии
Штрафные санкции за срыв сроков (зафиксированы в договоре)
Процедура приёмки и критерии «завершённого проекта»

9. Передача прав и кода (вес: 5/100)

Полная передача исходного кода и прав на него заказчику
Документация: архитектурная, API, пользовательская
Доступ к репозиториям, CI/CD, серверам
Отсутствие vendor lock-in (проприетарные фреймворки, закрытые библиотеки)
Возможность привлечь другую команду для доработки

10. Стоимость и ценообразование (вес: 5/100)

Прозрачность ценообразования (детализация до задач, а не «общая сумма»)
Модель оплаты (фикс, T&M, milestone-based)
Что входит и что НЕ входит в стоимость (хостинг, поддержка, доработки)
Порядок согласования дополнительных работ
Сравнимость с рыночными ценами в Москве

Скоринговая таблица для оценки подрядчиков

Критерий	Вес	Подрядчик A	Подрядчик B	Подрядчик C
Портфолио и кейсы	15	__/15	__/15	__/15
Команда и компетенции	15	__/15	__/15	__/15
Технический стек	12	__/12	__/12	__/12
Коммуникация и отчётность	12	__/12	__/12	__/12
Процессы разработки	10	__/10	__/10	__/10
Юридическая чистота	10	__/10	__/10	__/10
NDA и безопасность	8	__/8	__/8	__/8
SLA и гарантии	8	__/8	__/8	__/8
Передача прав и кода	5	__/5	__/5	__/5
Стоимость	5	__/5	__/5	__/5
ИТОГО	100	__/100	__/100	__/100

Рекомендация: подрядчик с оценкой ниже 60 баллов — высокий риск для корпоративного проекта. Оптимальный кандидат набирает 75+ баллов. Подробнее о том, как устроен бюджет IT-проектов и что влияет на итоговую стоимость.

Red flags при выборе подрядчика: 10 признаков ненадёжной команды

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

Организационные red flags

Нет конкретных имён в команде. «У нас 50 разработчиков» — но кто именно будет работать на вашем проекте? Если подрядчик не может назвать конкретных людей до подписания договора, скорее всего, команду будут собирать под проект из тех, кто свободен.
Нет процесса оценки и ТЗ. «Сделаем всё, что скажете, за 500К» — без детального ТЗ это обещание стоит ровно ничего. Серьёзный подрядчик тратит время на аналитику, декомпозицию и формализацию требований перед началом работ.
Цена значительно ниже рынка. Если средняя стоимость MVP в Москве — 800K-2M руб., а подрядчик обещает 200К «со скидкой» — значит, будут либо джуны вместо сеньоров, либо урезание scope, либо доплаты в процессе.
Отказ от NDA до начала работ. Корпоративный клиент не может обсуждать детали инновационного проекта без соглашения о конфиденциальности. Если подрядчик «не работает с NDA» — он не готов к enterprise-клиентам.
Нет фиксированных условий в договоре. «Сроки ориентировочные», «цена может измениться» — в корпоративной среде это неприемлемо. Продукт-менеджер не может защитить бюджет «ориентировочными» цифрами.

Технические red flags

Нет code review и тестирования. Если команда не практикует code review на каждый pull request и не пишет автоматические тесты — качество кода непредсказуемо. Для enterprise-продукта это критично.
Проприетарный фреймворк. Подрядчик использует собственную CMS, фреймворк или платформу, от которой вы будете зависеть. Это vendor lock-in: при расторжении договора код остаётся бесполезным.
Нет DevOps-практик. Ручной деплой, отсутствие CI/CD, нет мониторинга — признаки незрелой инфраструктуры. При масштабировании такая система будет падать регулярно.
Отказ показать код предыдущих проектов. «Всё под NDA» — удобная отговорка. Серьёзная студия имеет демо-проекты, open source вклады или готова организовать демо-доступ с разрешения клиента.
Обещание «всё за неделю». Нереалистичные сроки — это либо непонимание масштаба задачи, либо намеренное занижение для получения контракта. В обоих случаях результат предсказуем: срыв сроков и конфликт. Подробнее о типичных провалах — в материале типичные ошибки корпоративных IT-проектов.

Как проводить тендер на IT-разработку в корпорации

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

Этап 1. Подготовка тендерной документации (1-2 недели)

Составьте Brief — документ, описывающий проект для потенциальных подрядчиков:

Бизнес-контекст: какую проблему решает продукт, целевая аудитория, ключевые метрики успеха
Функциональные требования: user stories, основные функции, приоритеты (must have / nice to have)
Технические требования: интеграции с корпоративными системами, требования к безопасности, compliance
Ограничения: бюджет (диапазон), сроки (дедлайн), технологические предпочтения
Критерии оценки: веса параметров из скоринговой таблицы выше
Формат ответа: что подрядчик должен предоставить (коммерческое предложение, оценка, план проекта)

Совет: не указывайте точный бюджет — укажите диапазон или «до N рублей». Это поможет отсечь несерьёзных кандидатов и понять реальную рыночную стоимость.

Этап 2. Сбор и отсев кандидатов (1 неделя)

Источники поиска для корпоративного тендера в Москве:

Рейтинги: Clutch, GoodFirms, Рейтинг Рунета, Tagline
Рекомендации от коллег из других компаний (CIO-клубы, конференции)
Площадки: VC.ru, Habr (профили компаний), LinkedIn
Кластеры: Сколково, технопарки (если важна географическая близость)

Оптимальное количество кандидатов: 5-7 на длинный список, 3 в финал. Больше — затягивает процесс. Меньше — нет конкуренции.

Этап 3. Оценка предложений (1-2 недели)

Для каждого финалиста проведите:

Презентация подхода (60 мин) — как команда планирует реализовать проект, архитектурные решения
Техническое интервью (30-45 мин) — вопросы к ключевым разработчикам (попросите присутствовать вашего CTO или техлида)
Проверка референсов — позвоните 2-3 прошлым клиентам, задайте конкретные вопросы о сроках, качестве, коммуникации
Скоринг — заполните скоринговую таблицу по 10 критериям

Этап 4. Финальное решение и согласование (3-5 дней)

Подготовьте для руководства краткую записку:

Скоринговая таблица с 3 финалистами и итоговыми баллами
Сравнение ценовых предложений
Рекомендация с обоснованием (не только цена, но и риски)
План project kickoff с выбранным подрядчиком

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

Стоимость и формат оплаты: фикс vs T&M vs ретейнер

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

Параметр	Фиксированная цена (Fixed Price)	Time & Materials (T&M)	Ретейнер
Суть	Фиксированная сумма за фиксированный scope	Оплата по часам/дням	Ежемесячная подписка на команду
Риск перерасхода	На подрядчике	На заказчике	Разделён
Гибкость scope	Низкая (change request = доплата)	Высокая	Средняя
Предсказуемость бюджета	Высокая	Низкая	Средняя
Контроль для заказчика	По milestone'ам	Ежедневный	Еженедельный
Подходит для	MVP, пилотные проекты	Масштабные проекты с гибким ТЗ	Долгосрочная поддержка
Типичная стоимость (Москва)	500K-2M за MVP	2 500-5 000 руб./час	300K-1.5M руб./мес

Когда выбирать фиксированную цену

Для корпоративного MVP — это оптимальная модель. Фиксированная цена означает: продукт-менеджер точно знает бюджет и может защитить его перед финдиректором. Никаких «ориентировочно» и «возможны корректировки». В IT Integration стандартный пакет разработки MVP стоит до 900 000 рублей с фиксированными сроками 22 рабочих дня — всё прописано в договоре.

Условие для фиксированной цены — чётко определённый scope. Именно поэтому серьёзные подрядчики начинают с подготовки детального ТЗ (3-5 рабочих дней), а не с «присылайте задачу, назовём цену за час».

Когда T&M оправдан

Если scope проекта не определён до конца (например, R&D, исследовательская разработка) или проект масштабный (6+ месяцев), T&M даёт гибкость. Но это требует:

Сильного технического менеджера на стороне заказчика
Еженедельных ревью расходов
Cap (потолок) на общий бюджет в договоре
Права расторгнуть договор при превышении согласованного бюджета

Скрытые расходы: на что обращать внимание

При сравнении предложений учитывайте:

Хостинг и инфраструктура — входит ли в стоимость или оплачивается отдельно
Техническая поддержка — гарантийный период и стоимость после гарантии
Изменения в scope — стоимость change request'ов
Лицензии — проприетарное ПО, платные API, облачные сервисы
Документация — часто не входит в базовую стоимость при T&M

Чек-лист итоговой проверки перед подписанием договора

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

Юридическая часть

☐ Проверена юридическая чистота подрядчика (СПАРК, Контур.Фокус, ЕФРСБ)
☐ Подписан NDA (до передачи детальной информации о проекте)
☐ В договоре указаны фиксированные сроки и стоимость
☐ Прописан порядок приёмки (критерии «сделано»)
☐ Определены штрафные санкции за срыв сроков
☐ Права на исходный код переходят заказчику
☐ Прописан порядок change request'ов (дополнительные работы)
☐ Указан гарантийный период и SLA на исправление багов
☐ Определён порядок расторжения и условия возврата аванса

Техническая часть

☐ Утверждено детальное ТЗ с user stories и критериями приёмки
☐ Согласован технический стек (фронтенд, бэкенд, БД, инфраструктура)
☐ Определён состав команды (поимённо, с уровнями)
☐ Прописан план интеграций с корпоративными системами
☐ Согласованы требования к безопасности и compliance
☐ Определён формат передачи кода и документации
☐ Согласована инфраструктура деплоя (облако, on-premise)

Управление проектом

☐ Определена частота и формат отчётности (еженедельные демо)
☐ Настроен доступ к трекеру задач для заказчика
☐ Согласованы каналы коммуникации и время реакции
☐ Назначены ответственные с обеих сторон (RACI-матрица)
☐ Запланирован kickoff-звонок с полной командой
☐ Определены контрольные точки (milestone) для промежуточной приёмки

Финансовая часть

☐ Согласован график платежей (аванс, промежуточные, финальный)
☐ Определены скрытые расходы (хостинг, лицензии, поддержка)
☐ Есть сравнительная таблица с другими кандидатами для обоснования выбора
☐ Подготовлена записка для руководства с обоснованием выбора подрядчика

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

FAQ о выборе подрядчика для разработки

Сколько времени занимает выбор подрядчика для IT-разработки?

Полный цикл — от составления тендерной документации до подписания договора — занимает 3-5 недель для корпоративного проекта. Подготовка Brief'а: 1-2 недели. Сбор предложений и предварительный отсев: 1 неделя. Оценка финалистов (презентации, техинтервью, проверка референсов): 1-2 недели. Согласование договора: 3-5 рабочих дней. Попытка ускорить процесс до нескольких дней увеличивает риск ошибки.

Как проверить портфолио IT-подрядчика в Москве?

Три обязательных шага. Первый — запросите контакты 2-3 клиентов из портфолио и позвоните им. Задайте конкретные вопросы: уложились ли в сроки, менялся ли бюджет, как быстро реагировали на проблемы. Второй — попросите демо-доступ к одному из проектов или проведите code review фрагмента кода с вашим техлидом. Третий — проверьте компанию в рейтингах (Clutch, Tagline, Рейтинг Рунета) и на наличие судебных споров с клиентами (СПАРК, kad.arbitr.ru). IT Integration, например, работает из Инновационного центра Сколково, что даёт дополнительную верификацию.

Что выгоднее — фиксированная цена или оплата по часам (T&M)?

Для корпоративного MVP фиксированная цена выгоднее в 80% случаев. Главное преимущество — предсказуемость: продукт-менеджер знает итоговую сумму и может защитить бюджет перед руководством. В модели T&M средний перерасход составляет 30-100% от первоначальной оценки. T&M оправдан для масштабных проектов с неопределённым scope (R&D, исследования), но требует сильного технического контроля со стороны заказчика и cap на бюджет в договоре.

Какие критерии самые важные при выборе подрядчика для корпоративного проекта?

Три критерия с наибольшим весом: портфолио с релевантными кейсами (15/100), команда и компетенции с возможностью техинтервью (15/100), коммуникация и формат отчётности (12/100). Стоимость — важный, но не решающий фактор (вес 5/100). Самый дешёвый подрядчик часто оказывается самым дорогим — через доработки, исправления и переделки. Используйте скоринговую таблицу из 10 критериев и выбирайте кандидата с итогом 75+ баллов из 100.

Как защитить компанию от vendor lock-in при работе с подрядчиком?

Четыре обязательных условия в договоре. Первое — полная передача исходного кода и прав интеллектуальной собственности заказчику. Второе — запрет на использование проприетарных фреймворков подрядчика. Третье — полная техническая документация (архитектурная, API, пользовательская). Четвёртое — доступ к репозиториям, CI/CD и инфраструктуре. После завершения проекта код должен быть самодостаточным — другая команда может подхватить разработку без участия первоначального подрядчика.

Нужно ли проводить тендер для IT-проекта в частной компании?

Юридически — нет (для госкомпаний действуют 44-ФЗ и 223-ФЗ). Практически — да. Даже упрощённый тендер с 3 финалистами даёт: объективное сравнение цен и подходов, аргументы для руководства при защите бюджета, снижение риска ошибки при выборе. Минимальный вариант: Brief → 3 коммерческих предложения → скоринг по 10 критериям → финальное решение. Это занимает 2-3 недели и экономит месяцы потенциальных проблем.

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

Запишитесь на бесплатный Zoom-колл через форму на сайте IT Integration. На первой встрече (30-40 минут) команда обсудит вашу бизнес-гипотезу, оценит техническую сложность и предложит архитектурное решение. Далее — подготовка детального ТЗ (3 рабочих дня), согласование, договор с фиксированной ценой (до 900 000 рублей) и сроками (22 рабочих дня). Еженедельные демо, промежуточные отчёты для руководства, 2 недели гарантии после сдачи. Офис расположен в Инновационном центре Сколково, работаем с компаниями по всей России.

Выбор подрядчика для разработки — это стратегическое решение, определяющее судьбу инновационного проекта. Используйте скоринговую таблицу и чек-лист из этой статьи как рабочие инструменты для объективной оценки кандидатов. А если хотите обсудить ваш конкретный проект — запишитесь на бесплатный Zoom-колл с командой IT Integration. Расскажем о нашем подходе, покажем релевантные кейсы и поможем определить оптимальный формат сотрудничества для вашей задачи.