Сквозная команда как страховка от срывов сроков: что внедрить в процессах, чтобы проект шёл по плану

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

Часто срыв сроков разработки начинается при передаче проекта между командами: аналитика отдаёт требования разработке, разработка — тестированию, подрядчик — внутреннему ИТ, команда проекта — поддержке. Так теряется часть контекста и размывается ответственность, потому что передача проекта между командами требует общего регламента.

По данным исследования «Обит», в 2025 году почти каждый второй комплексный ИТ-проект в российских компаниях требует доработки после неудачного внедрения, а затраты на исправление ошибок достигают 10–30% от общего бюджета. При этом лишь 31% ИТ-проектов укладываются в сроки и бюджет.

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

Почему срываются сроки проектов: неочевидные причины

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

• Потеря контекста при передаче.
  
  Когда проект переходит от одной команды к другой, иногда вместе с кодом и документацией передаётся далеко не всё. Остаются устные договорённости, причины архитектурных решений, знание о том, какие модули трогать опасно и где лежат актуальные инструкции. Из-за этого новая команда тратит недели на восстановление этого контекста.
• Scope creep (изменение требований)
  
  Это ситуация (к сожалению, нередкая), когда требования растут по ходу проекта. Условно, заказчик просит небольшую доработку, потом ещё одну, а потом меняет приоритеты. Каждое изменение по отдельности некритично, но вместе они сдвигают сроки (а иногда и стоимость) проекта. В том же исследовании из начала статьи сказано: 35% провалов связаны с тем, что решение не соответствовало фактическим бизнес-требованиям компании. Причина в том, что осутствовал процесс управления изменениями.
• Bus factor, равный единице
  
  Bus factor — ситуация, когда при уходе из проекта ключевого человека всё ломается или сильно стопорится. Если бас-фактор равен единице, значит только один человек знает, как всё устроено, и если он уйдёт, то у проекта появятся проблемы.
  
  Например, в команде только один человек знает, как устроен ключевой модуль или только он помнит, почему интеграция с legacy-системой сделана именно так. Когда он уходит (в отпуск, на другой проект или из компании, неважно), работа останавливается. По оценке Selecty, задержка в 10 рабочих дней для команды из 8–10 человек увеличивает бюджет на 12–15% . При bus factor равном единице (когда важный скоуп знаний есть только у одного человека), такая задержка почти гарантирована.

Цена разрыва: во что обходится смена команды в середине проекта

Прямые потери видны сразу: к ним относятся оплата простоя, расходы на подбор замены и стоимость онбординга нового сотрудника. Косвенные потери сложнее посчитать, но они больше. Например, новый разработчик не знает кодовую базу, поэтому первые недели его производительность близка к нулю. По данным отраслевых исследований, замена senior-разработчика обходится в 150–250% его годовой зарплаты, а по некоторым оценкам — до 200% . В эти цифры входят рекрутинг, потерянные знания, задержки проекта и снижение темпа работы команды.

Возьмём простой пример. Пять специалистов тратят по 24 часа на изучение системы: при стоимости часа 2500 рублей это 300 000 рублей. Ещё 80 часов повторных проверок стоят 200 000 рублей. Прямые потери — 500 000 рублей. Если перенос релиза на две недели обходится бизнесу в условные 150 000 рублей в день, добавляется 1,5 млн. Всего — 2 млн рублей. И это мы не рассчитывали замену условному ведущему разработчику, который, если уходит из проекта, тянет за собой новые сроки найма, онбординга, погружения в проект и оплату всего этого времени.

Что такое сквозная команда и чем она отличается от обычной модели

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

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

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

Процессы, которые удерживают проект в сроках: 5 конкретных решений

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

Общая карта работ

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

Синхронизации с заказчиком

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

Управление изменениями требований

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

Документация и резерв знаний

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

Буфер и техническая готовность

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

Уровни контроля: как понять, что проект идёт по плану

Зелёный уровень

• задачи закрываются в срок, 
• буфер сроков расходуется не больше, чем на 10% в неделю, 
• новые требования проходят оценку влияния, 
• ключевые знания распределены между двумя-тремя людьми 

Проект идёт по плану, всё хорошо.

Жёлтый уровень

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

Пора проводить внеплановую синхронизацию и проверять критический путь проекта.

Красный уровень

• bus factor по ключевому модулю равен единице, а этот человек перегружен
• буфер израсходован больше чем наполовину при половине оставшихся задач 
• сроки по критическому пути уже сдвинулись, но команда продолжает работать по старому плану
• ключевые знания хранятся несистемно или не хранятся вовсе, нет фиксированных ответственных за задачи

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

Когда сквозная команда особенно важна: три типа проектов

Проекты с высокой ценой ошибки. Это банковские системы, интеграции с регуляторными платформами, промышленная автоматизация и тому подобные. Здесь задержка измеряется как деньгами, так и нарушениями SLA или требованиями регулятора. По оценке Selecty, в банковских проектах потери от нарушения сроков достигают 15–25% плановой выручки. Сквозная команда снижает вероятность того, что ошибка будет обнаружена на этапе, когда исправление стоит дороже разработки.

Долгосрочные проекты. Чем дольше проект, тем выше вероятность смены состава. Если команда сквозная, замена одного человека не обнуляет знание о проекте. А если проект передаётся между командами на каждом этапе, к третьему-четвёртому этапу контекст теряется почти полностью.

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

FAQ

Как организовать сквозную команду, если внутри компании разработка и поддержка — разные отделы?

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

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

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

Насколько реально внедрить все перечисленные практики в действующий проект?

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

Заключение

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

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