IT-подрядчика для корпоративной разработки можно оценить по кейсам с описанной ролью команды, составу специалистов, объемам работ, входящих в стоимость контракта, договорным этапам, правилам приемки и условиям передачи результата. Отдельно фиксируют передачу исходного кода, документации, доступов и репозитория — без этого передать продукт другой команде в будущем без потерь будет сложно.
IT-подрядчик — это внешняя команда, которая по договору берет на себя анализ, проектирование, разработку, тестирование, внедрение и сопровождение программного продукта. Разберем, как проверить такого подрядчика по критериям и вопросам, что смотреть в кейсах, цене и договоре, и какие ошибки повторяются от проекта к проекту.
Что должен обеспечить IT-подрядчик в корпоративной разработке в РФ
Для корпоративной разработки подрядчик должен обеспечить управляемый процесс, прозрачную ответственность, интеграцию с существующими системами, требования ИБ и передачу результата заказчику. Корпоративный ИТ-проект сложен сам по себе, а от выбора подрядчика зависят его сроки, бюджет и результат.
Обычно разработка начинается с предпроектного анализа. Команда разбирает бизнес-процессы, ограничения, роли пользователей, источники данных и точки интеграции. Только после этого можно обсуждать архитектуру, этапы, модель работы и состав артефактов.
Исход корпоративного проекта обычно определяют три фактора:
- ИТ-ландшафт заказчика. Новый сервис должен работать внутри действующих систем компании, обмениваясь с ними данными.
- Безопасность. Требования ИБ, доступы и режим работы с чувствительными данными фиксируются до проектирования.
- Интеграции. Важно заранее договориться, как системы обмениваются данными, кто имеет доступ, как устроен единый вход и кто отвечает за смежные системы.
Плагин для Jira из портфеля IMS для Газпромбанка показывает эту логику. Даже небольшой модуль внутри корпоративной системы затрагивает права доступа, регламент обновлений, поддержку и совместимость с окружением заказчика. Это часть рабочих процессов компании.
Критерии выбора IT-подрядчика: 8 проверяемых пунктов
В практических обзорах критерии выбора сводят к опыту, методологии, команде, репутации, юридической и финансовой надежности, коммуникации и поддержке после релиза.
Документация напрямую связана с принципом IMS — передавать заказчику все артефакты проекта. Когда у компании есть код, описание архитектуры, инструкции, доступы и история решений, гораздо легче удержать контроль над продуктом.
Как проверить IT-подрядчика до договора: 10 вопросов CIO и CTO
Главная задача проверки — понять, как команда работает с неопределенностью, ограничениями и ответственностью.
Вопросы, которые стоит задать подрядчику:
- Какие похожие проекты выполнены и какая роль в них была у команды?
- Какие ограничения заказчика сильнее всего влияли на архитектуру и сроки?
- Как проводится предпроектный анализ и что заказчик получает на выходе?
- Как выглядит типовой план этапов, статусов и приемки?
- Кто войдет в команду и сколько времени эти специалисты будут выделять проекту?
- Как оценивается стоимость и что считается изменением объема?
- Как устроены тестирование, приемка и исправление дефектов?
- Кому принадлежат исходный код, репозиторий, проектная документация и доступы после завершения работ?
- С чего начинается проект: с анализа процессов и интеграций или сразу с разработки?
- Как обеспечивается передача кода, документации и доступов, чтобы заказчик не зависел от подрядчика?
Если подрядчик уходит от вопросов о правах, репозитории и передаче документации, это само по себе показательно. В корпоративном проекте такая неясность гарантированно приведет к вашей зависимости от исполнителя.
Как оценивать кейсы
Кейс оценивается по роли подрядчика и результату, который получил заказчик. Если подрядчик не может объяснить задачу, границы ответственности и переданные артефакты — это плохой знак.
Четыре вопроса к любому кейсу:
- Какая бизнес-цель стояла за проектом?
- Какую роль играл подрядчик: полный цикл, отдельный модуль, поддержка, интеграция?
- Какие работы вошли в проект: аналитика, архитектура, разработка, тестирование, внедрение?
- Какие артефакты заказчик получил после завершения: код, документация, доступы, инструкции, схемы интеграций?
В хорошем кейсе важно показать, что именно делала команда и какой результат в итоге получила. Если в презентации мелькают красивые цифры, но непонятно, как их считали, — смело задавайте вопросы. То, как подрядчик отреагирует, расскажет о нем гораздо больше, чем сами слайды.
И не пугайтесь, если в кейсе нет точных бюджетов, сроков или ROI. Часто это просто следствие NDA. Короткий и честный рассказ о задаче и проделанной работе всегда надежнее, чем громкие проценты роста.
Бюджет и коммерческое предложение
Стоимость разработки зависит от состава работ, интеграций, требований ИБ, количества ролей, сроков и режима сопровождения.
В коммерческом предложении важно понять, что именно покупает заказчик и где начинаются дополнительные работы.
Сравнивать подрядчиков по одной строке «разработка» нельзя. Одна команда может включить аналитику, тестирование, документацию и передачу репозитория, а другая — заложить только часть работ. Сначала кажется, что второй вариант дешевле, но в процессе использования он почти всегда обходится дороже.
Договор, ТЗ и контроль разработки: 6 обязательных условий
Договор должен закреплять не только сумму и срок, но и способ управления результатом. При разработке ПО юридические особенности часто остаются без внимания, хотя ИТ-аутсорсинг давно стал рабочим инструментом бизнеса.
Шесть условий, которые проверяют до подписания:
- Предмет договора. Что именно создает подрядчик: продукт, модуль, интеграцию, прототип, документацию, сопровождение.
- Этапы и приемка. Какие результаты сдаются по этапам и кто со стороны заказчика принимает работу.
- Требования и изменения. Как фиксируются ТЗ, уточнения, новые требования и влияние правок на срок и бюджет.
- Права на результат. Как передаются исходный код, документация, дизайн, схемы, инструкции и иные материалы.
- Доступы и репозитории. Когда и как заказчик получает доступ к репозиторию, таск-трекеру, средам и документации.
- Сопровождение и выход. Как проект передается при смене подрядчика и кто отвечает за поддержку после релиза.
ТЗ не обязательно должно быть длинным и подробным. Главное, чтобы в нем были четко прописаны рамки первого этапа, критерии приемки, интеграции, ограничения и все открытые вопросы. Иначе вместо обсуждения качества работы вы будете бесконечно спорить о том, что вообще нужно было делать.
Модели сотрудничества: почасовая разработка и фиксированный срок
Модель сотрудничества выбирают после анализа требований.
Компании с большим ИТ-ландшафтом стоит выбирать модель после предпроектного разбора. Аналитика показывает, где требования устойчивы, а где еще есть неопределенность. Если интеграции, роли и ограничения не описаны, фиксированная рамка становится формальной.
Как избежать зависимости от поставщика
Чтобы не зависеть от поставщика, нужны четкий договор, полные доступы и порядок в разработке. Проверяйте выполнение этих условий до первого платежа.
Семь пунктов по принципам IMS:
- Исходный код передается заказчику в согласованном репозитории.
- Техническая и пользовательская документация передается вместе с кодом.
- Заказчик имеет доступ к задачам, репозиторию и документации на протяжении проекта.
- Порядок передачи проекта при смене подрядчика описан заранее.
- В договоре закреплены права на результат и условия использования сторонних компонентов.
- Архитектурные решения объяснены и задокументированы, а не остаются в голове команды.
- Проект начинается с анализа, поэтому архитектура не подстраивается только под удобство конкретного исполнителя.
Пункт о передаче проекта другому подрядчику часто вызывает у исполнителей отторжение, но это отличный тест на профессионализм. Уверенная в себе команда легко опишет не только то, как она начнет работу, но и как грамотно передаст дела при завершении сотрудничества.
Типичные ошибки выбора IT-подрядчика: 6 сценариев риска
Главный сигнал риска — подрядчик легко обещает срок и бюджет до анализа процессов. В корпоративной разработке такая скорость создает риск срыва сроков после старта.
Специфика выбора подрядчика в РФ
Для крупных компаний на первый план выходят безопасность, интеграции, документация, управляемость изменений и ответственность перед внутренними заказчиками.
Четыре фактора стоит проверять отдельно:
- Безопасность. Требования ИБ, режим работы с чувствительными данными, доступы, журналирование, окружения.
- Интеграции. Обмен данными с учетными, корпоративными и отраслевыми системами заказчика.
- Документация. Комплект материалов, который сможет читать не только автор кода.
- Управляемость изменений. Порядок согласования правок объема, приоритетов, сроков и бюджета.
В корпоративном проекте почти всегда участвует несколько сторон: бизнес-заказчики, ИТ, безопасность, юристы, эксплуатация и владельцы смежных систем. До договора обязательно согласуйте правила коммуникации: формат статусов, протоколы встреч, зоны ответственности и порядок решения проблем.
Финальный чек-лист перед стартом работ
Готовность к старту измеряется только артефактами. Нет документа или рабочего доступа? Значит, этап фактически не пройден, независимо от устных заверений.
Что важно не упустить:
- Компания реализовывала подобные кейсы ранее.
- Понятна роль подрядчика в каждом релевантном кейсе.
- Проведена встреча не только с продажами, но и с аналитиком или архитектором.
- Описаны процессы заказчика, ограничения и ключевые интеграции.
- Согласованы этапы проекта и результаты каждого этапа.
- Коммерческое предложение раскрывает состав работ, а не только сумму.
- Определены роли команды подрядчика и занятость специалистов.
- Назначен владелец продукта со стороны заказчика.
- Зафиксированы критерии приемки и порядок работы с дефектами.
- В договоре закреплена передача исходного кода и документации.
- В договоре закреплено отсутствие зависимости от поставщика и порядок передачи проекта.
- Согласованы правила сопровождения после релиза.
Этот чек-лист стоит пройти до первого платежа. После запуска проекта менять договор, доступы и правила приемки сложнее, потому что у сторон уже появляются сроки, ожидания и зависимость от текущего темпа работ.
Частые вопросы
Что делать, если подрядчик отказывается передавать исходный код?
Обсудить передачу кода на хранение независимой третьей стороне (депонирование), с понятными условиями доступа при прекращении договора. Если подрядчик не хочет отдавать исходный код, это огромный риск. Права на код и готовые библиотеки нужно прописывать в договоре. А если он отвергает даже схему депонирования, вы попадаете в полную зависимость от этого поставщика.
Можно ли ориентироваться на срок 3–4 месяца для корпоративного проекта?
Нет, если речь идет о системе с интеграциями, требованиями ИБ и несколькими группами пользователей. Срок корпоративного проекта определяется после анализа процессов, архитектуры, зависимостей и приемки. Быстрый ориентир без этих данных полезен только как предварительная гипотеза.
Стоит ли делить проект между двумя подрядчиками?
Да, но только при понятных границах модулей и назначенном владельце интеграционного слоя. Иначе ответственность за дефекты на стыке работ будут перекладываться между командами. Решение принимает CIO вместе с архитектором заказчика.
Как проверить подрядчика, если у него нет публичных кейсов из-за соглашения о неразглашении?
Стоит запросить демонстрацию под соглашением о конфиденциальности, обезличенное описание задачи и состав работ. Закрытость названия заказчика и полное отсутствие подтверждаемых проектов — разные ситуации. В первом случае можно проверить опыт, во втором — остается только доверять словам.
Что делать, если единственный подходящий подрядчик дороже бюджета на 30%?
Разумнее сократить объем первого этапа, а не качество анализа, архитектуры и приемки. Первый этап может закрыть диагностику, прототип, ядро функций и план дальнейшей разработки. Это безопаснее, чем урезать, например, тестирование.
Можно ли начинать разработку без ТЗ, если сроки поджимают?
Чтобы ускорить запуск, нужно зафиксировать ТЗ на первый этап, а следующие этапы описывать параллельно. Полный отказ от требований почти всегда ведет к спору в конце проекта, та как у сторон разные ожидания.
Как оценить отчетность подрядчика до контракта?
Стоит попросить обезличенный отчет по действующему или завершенному проекту и посмотреть на выполненные задачи, отклонения от плана, риски, решения и следующие шаги. Хороший отчет помогает управлять проектом, а не просто показывает занятость команды.