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

2026-08-25 10:09

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

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

Что должен обеспечить IT-подрядчик в корпоративной разработке в РФ

Для корпоративной разработки подрядчик должен обеспечить управляемый процесс, прозрачную ответственность, интеграцию с существующими системами, требования ИБ и передачу результата заказчику. Корпоративный ИТ-проект сложен сам по себе, а от выбора подрядчика зависят его сроки, бюджет и результат.

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

Исход корпоративного проекта обычно определяют три фактора:

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

Плагин для Jira из портфеля IMS для Газпромбанка показывает эту логику. Даже небольшой модуль внутри корпоративной системы затрагивает права доступа, регламент обновлений, поддержку и совместимость с окружением заказчика. Это часть рабочих процессов компании.

Критерии выбора IT-подрядчика: 8 проверяемых пунктов

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

№	Критерий	Что проверить	Какой артефакт запросить	Почему важно для компании
1	Опыт и специализация	Похожие задачи, отраслевые ограничения, глубина участия подрядчика	Описание кейса с ролью команды и составом работ	Логотип заказчика не доказывает компетенцию
2	Методология	Как подрядчик ведет аналитику, разработку, тестирование и приемку	Регламент проекта, пример плана этапов	Без процесса сроки могут стать предметом спора
3	Прозрачность цены	Из чего складывается стоимость	Детализированное коммерческое предложение	Общая сумма без состава работ неуправляема
4	Управление изменениями	Как фиксируются новые требования и отклонения	Шаблон запроса на изменение и порядок согласования	Корпоративные проекты почти всегда меняются по ходу работы
5	Права на результат	Кому принадлежат код, документация, дизайн, доступы и репозиторий	Проект договора с разделом об исключительных правах и передаче артефактов	Иначе продукт может остаться под контролем подрядчика
6	Команда	Роли аналитика, архитектора, разработчиков, тестировщика, менеджера проекта и т.д.	Состав ролей, занятость, зона ответственности	Одна роль на пять функций срывает сроки и влияет на качество
7	Документация	Готовность передать техническую и пользовательскую документацию	Обезличенный пример документации по прошлому проекту	Без документации сопровождение остается у автора кода
8	Поддержка после релиза	SLA, порядок исправлений, доработки, обновления	Регламент сопровождения и пример отчета	После релиза проект не заканчивается, начинается эксплуатация

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

Как проверить IT-подрядчика до договора: 10 вопросов CIO и CTO

Главная задача проверки — понять, как команда работает с неопределенностью, ограничениями и ответственностью.

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

Какие похожие проекты выполнены и какая роль в них была у команды?
Какие ограничения заказчика сильнее всего влияли на архитектуру и сроки?
Как проводится предпроектный анализ и что заказчик получает на выходе?
Как выглядит типовой план этапов, статусов и приемки?
Кто войдет в команду и сколько времени эти специалисты будут выделять проекту?
Как оценивается стоимость и что считается изменением объема?
Как устроены тестирование, приемка и исправление дефектов?
Кому принадлежат исходный код, репозиторий, проектная документация и доступы после завершения работ?
С чего начинается проект: с анализа процессов и интеграций или сразу с разработки?
Как обеспечивается передача кода, документации и доступов, чтобы заказчик не зависел от подрядчика?

Если подрядчик уходит от вопросов о правах, репозитории и передаче документации, это само по себе показательно. В корпоративном проекте такая неясность гарантированно приведет к вашей зависимости от исполнителя.

Как оценивать кейсы

Кейс оценивается по роли подрядчика и результату, который получил заказчик. Если подрядчик не может объяснить задачу, границы ответственности и переданные артефакты — это плохой знак.

Четыре вопроса к любому кейсу:

Какая бизнес-цель стояла за проектом?
Какую роль играл подрядчик: полный цикл, отдельный модуль, поддержка, интеграция?
Какие работы вошли в проект: аналитика, архитектура, разработка, тестирование, внедрение?
Какие артефакты заказчик получил после завершения: код, документация, доступы, инструкции, схемы интеграций?

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

И не пугайтесь, если в кейсе нет точных бюджетов, сроков или ROI. Часто это просто следствие NDA. Короткий и честный рассказ о задаче и проделанной работе всегда надежнее, чем громкие проценты роста.

Бюджет и коммерческое предложение

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

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

Блок коммерческого предложения	Что должно быть раскрыто
Аналитика	Интервью, разбор процессов, требования, ограничения, карта заинтересованных сторон
Дизайн и прототипирование	Число ключевых экранов, состав прототипа, правила согласования правок
Архитектура	Схема компонентов, интеграции, требования к инфраструктуре и безопасности
Разработка	Функции по этапам, стек, зависимости, допущения по внешним системам
Тестирование	Виды проверок, приемочное тестирование пользователями, критерии приемки
Внедрение	Порядок выкладки, миграции, обучение, план отката
Сопровождение	Срок реакции, порядок доработок, состав команды, отчетность

Сравнивать подрядчиков по одной строке «разработка» нельзя. Одна команда может включить аналитику, тестирование, документацию и передачу репозитория, а другая — заложить только часть работ. Сначала кажется, что второй вариант дешевле, но в процессе использования он почти всегда обходится дороже.

Договор, ТЗ и контроль разработки: 6 обязательных условий

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

Шесть условий, которые проверяют до подписания:

Предмет договора. Что именно создает подрядчик: продукт, модуль, интеграцию, прототип, документацию, сопровождение.
Этапы и приемка. Какие результаты сдаются по этапам и кто со стороны заказчика принимает работу.
Требования и изменения. Как фиксируются ТЗ, уточнения, новые требования и влияние правок на срок и бюджет.
Права на результат. Как передаются исходный код, документация, дизайн, схемы, инструкции и иные материалы.
Доступы и репозитории. Когда и как заказчик получает доступ к репозиторию, таск-трекеру, средам и документации.
Сопровождение и выход. Как проект передается при смене подрядчика и кто отвечает за поддержку после релиза.

ТЗ не обязательно должно быть длинным и подробным. Главное, чтобы в нем были четко прописаны рамки первого этапа, критерии приемки, интеграции, ограничения и все открытые вопросы. Иначе вместо обсуждения качества работы вы будете бесконечно спорить о том, что вообще нужно было делать.

Модели сотрудничества: почасовая разработка и фиксированный срок

Модель сотрудничества выбирают после анализа требований.

Параметр	Почасовая разработка	Фиксированный срок и объем
Когда подходит	Требования уточняются в процессе, приоритеты меняются	Состав работ описан до старта достаточно подробно
Как управлять	Через бэклог, лимиты бюджета, регулярные отчеты и приоритизацию	Через ТЗ, этапы, приемку и контроль изменений
Преимущество	Гибкость при неопределенности	Предсказуемость при понятных требованиях
Основной риск заказчика	Рост объема без контроля бюджета	Жесткая рамка при изменении требований
Что запросить	Пример отчета по часам и задачам	План этапов и критерии приемки

Компании с большим ИТ-ландшафтом стоит выбирать модель после предпроектного разбора. Аналитика показывает, где требования устойчивы, а где еще есть неопределенность. Если интеграции, роли и ограничения не описаны, фиксированная рамка становится формальной.

Как избежать зависимости от поставщика

Чтобы не зависеть от поставщика, нужны четкий договор, полные доступы и порядок в разработке. Проверяйте выполнение этих условий до первого платежа.

Семь пунктов по принципам IMS:

Исходный код передается заказчику в согласованном репозитории.
Техническая и пользовательская документация передается вместе с кодом.
Заказчик имеет доступ к задачам, репозиторию и документации на протяжении проекта.
Порядок передачи проекта при смене подрядчика описан заранее.
В договоре закреплены права на результат и условия использования сторонних компонентов.
Архитектурные решения объяснены и задокументированы, а не остаются в голове команды.
Проект начинается с анализа, поэтому архитектура не подстраивается только под удобство конкретного исполнителя.

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

Типичные ошибки выбора IT-подрядчика: 6 сценариев риска

№	Ошибка	Как проявляется	Чем опасна для компании 500+	Как снизить риск
1	Выбор по логотипам	В презентации есть крупные бренды, но нет роли подрядчика	Непонятно, что команда реально делала	Запросить описание задачи, работ и артефактов
2	Выбор по минимальной цене	Короткое КП без требований, часть работ не раскрыта	Доплаты появятся после старта	Сравнивать состав работ, а не итоговую строку
3	Старт без анализа	Подрядчик сразу предлагает разработку	Архитектура не учитывает процессы и интеграции	Начать с предпроектной диагностики
4	Нет условий передачи кода	В договоре общие фразы о результате	Заказчик зависит от подрядчика после релиза	Закрепить передачу кода, документации и доступов
5	Слабая команда проекта	На встречах только продажа, технические роли не подключаются	Риски всплывут после подписания	Провести встречу с аналитиком и архитектором
6	Нет правил приемки	Не описаны критерии готовности и дефектов	Споры по качеству станут регулярными	Зафиксировать этапы, критерии и ответственных

Главный сигнал риска — подрядчик легко обещает срок и бюджет до анализа процессов. В корпоративной разработке такая скорость создает риск срыва сроков после старта.

Специфика выбора подрядчика в РФ

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

Четыре фактора стоит проверять отдельно:

Безопасность. Требования ИБ, режим работы с чувствительными данными, доступы, журналирование, окружения.
Интеграции. Обмен данными с учетными, корпоративными и отраслевыми системами заказчика.
Документация. Комплект материалов, который сможет читать не только автор кода.
Управляемость изменений. Порядок согласования правок объема, приоритетов, сроков и бюджета.

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

Финальный чек-лист перед стартом работ

Готовность к старту измеряется только артефактами. Нет документа или рабочего доступа? Значит, этап фактически не пройден, независимо от устных заверений.

Что важно не упустить:

Компания реализовывала подобные кейсы ранее.
Понятна роль подрядчика в каждом релевантном кейсе.
Проведена встреча не только с продажами, но и с аналитиком или архитектором.
Описаны процессы заказчика, ограничения и ключевые интеграции.
Согласованы этапы проекта и результаты каждого этапа.
Коммерческое предложение раскрывает состав работ, а не только сумму.
Определены роли команды подрядчика и занятость специалистов.
Назначен владелец продукта со стороны заказчика.
Зафиксированы критерии приемки и порядок работы с дефектами.
В договоре закреплена передача исходного кода и документации.
В договоре закреплено отсутствие зависимости от поставщика и порядок передачи проекта.
Согласованы правила сопровождения после релиза.

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

Частые вопросы

Что делать, если подрядчик отказывается передавать исходный код?

Обсудить передачу кода на хранение независимой третьей стороне (депонирование), с понятными условиями доступа при прекращении договора. Если подрядчик не хочет отдавать исходный код, это огромный риск. Права на код и готовые библиотеки нужно прописывать в договоре. А если он отвергает даже схему депонирования, вы попадаете в полную зависимость от этого поставщика.

Можно ли ориентироваться на срок 3–4 месяца для корпоративного проекта?

Нет, если речь идет о системе с интеграциями, требованиями ИБ и несколькими группами пользователей. Срок корпоративного проекта определяется после анализа процессов, архитектуры, зависимостей и приемки. Быстрый ориентир без этих данных полезен только как предварительная гипотеза.

Стоит ли делить проект между двумя подрядчиками?

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

Как проверить подрядчика, если у него нет публичных кейсов из-за соглашения о неразглашении?

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

Что делать, если единственный подходящий подрядчик дороже бюджета на 30%?

Разумнее сократить объем первого этапа, а не качество анализа, архитектуры и приемки. Первый этап может закрыть диагностику, прототип, ядро функций и план дальнейшей разработки. Это безопаснее, чем урезать, например, тестирование.

Можно ли начинать разработку без ТЗ, если сроки поджимают?

Чтобы ускорить запуск, нужно зафиксировать ТЗ на первый этап, а следующие этапы описывать параллельно. Полный отказ от требований почти всегда ведет к спору в конце проекта, та как у сторон разные ожидания.

Как оценить отчетность подрядчика до контракта?

Стоит попросить обезличенный отчет по действующему или завершенному проекту и посмотреть на выполненные задачи, отклонения от плана, риски, решения и следующие шаги. Хороший отчет помогает управлять проектом, а не просто показывает занятость команды.