Разработка под ключ, поддержка или выделенная команда: что выбрать

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

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

Если модель не назвать прямо, возникают типовые конфликты: покупают команду, а ждут фиксированный результат; покупают поддержку, а требуют развитие продукта; покупают готовый модуль, но забывают про внедрение, интеграции и приемку.

• нужно выбрать формат закупки или коммерческого предложения;
• задача может быть оформлена как разработка под ключ, поддержка, развитие или выделенная команда;
• есть готовый модуль, но требуется внедрение и адаптация;
• объем работ меняется и нужно понять, можно ли обещать фиксированный результат;
• важно разделить SLA, доработки, приемку и участие заказчика.

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

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

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

Предмет покупки

Приемка, бюджет и роль заказчика

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

Если формат уже выбран и нужна команда на период, смотрите услугу усиление IT-команды.

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

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

• Цель периода: какой результат или прогресс ожидается за ближайшие недели или месяц.
• Backlog или roadmap: задачи, приоритеты, зависимости и понимание, что можно отложить.
• Владелец приоритетов: человек, который принимает решения по очередности задач и спорным вопросам.
• Ответственный за приемку: кто проверяет результат, подтверждает готовность и дает обратную связь.
• Доступы и среда: репозитории, трекер задач, стенды, VPN, правила работы с данными и инфраструктурой.
• Ритм коммуникации: встречи, статусы, каналы связи, сроки реакции и формат отчетности.
• Критерии результата периода: что считается выполненным, как фиксируются часы, артефакты, pull requests, релизы или закрытые задачи.
• Правила замены и безопасности: NDA, права на результат, ограничения доступа и порядок замены специалиста, если роль не подошла.

Если вводные ещё не собраны, начните с чек-листа что подготовить для оценки ИТ-проекта. Если задачи уже есть, но их нужно разложить по этапам, поможет roadmap проекта из требований.

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

• покупать команду, но ожидать фиксированный результат без управления объемом;
• подключать специалистов без владельца приоритетов, backlog и правил приемки периода;
• включать развитие продукта в договор поддержки без отдельных правил;
• считать готовый модуль почти готовой системой без внедрения;
• не описать, как проходят изменения и кто утверждает приоритеты;
• не разделить критерии приемки результата, SLA и подтверждение выделенной емкости;
• называть T&M или capacity-модель проектом под ключ, если результат и scope заранее не зафиксированы.

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