После диагностики были выделены спорные зоны, восстановлен список технических вопросов и подготовлен план передачи проекта.
Карта разбора
Ситуация, риски и решение
Бизнес хотел заменить подрядчика, но не понимал, какие задержки связаны с командой, архитектурой, требованиями или потерей контекста.
- потеря доступов, решений и знаний о проекте
- новая команда начнёт с повторного расследования
- резкий разрыв усилит задержку вместо решения проблемы
- backlog, историю требований и спорные зоны
- модули, интеграции, доступы и инфраструктуру
- готовность проекта к технической передаче
- сформировать технический пакет передачи
- подготовить вопросы текущему подрядчику
- отделить критичные риски от управленческого шума
- решение о смене подрядчика стало основано на фактах
- новая команда могла получить реальное состояние проекта
- снизился риск остановки разработки при передаче
Почему сценарий обезличен
Разбор показывает типовую ситуацию перед сменой подрядчика. В нём нет названия клиента, фальшивого отзыва, точных сумм и публичных обещаний. Цель - показать, почему независимая диагностика полезна до резкого решения.
Контекст
Проект шёл дольше запланированного. Подрядчик ссылался на сложность требований, бизнес считал, что команда не справляется. Обе стороны говорили о проекте по-разному, а объективной технической картины не было.
Заказчик уже рассматривал замену подрядчика, но прямой разрыв мог привести к потере контекста, доступов, знаний о решениях и ещё большей задержке.
Симптомы
- сроки переносились, но причины задержек не были разложены по фактам;
- оценки задач не показывали технических зависимостей;
- часть требований менялась без фиксации решений;
- критичные решения принимались в переписке и не попадали в документацию;
- не было актуальной карты интеграций и окружений;
- бизнес не понимал, что именно можно передать новой команде.
Что проверяли
- backlog и историю изменения требований;
- состояние документации и технических решений;
- карту модулей, интеграций и доступов;
- качество коммуникации по срокам, рискам и блокерам;
- готовность проекта к передаче новой команде;
- спорные зоны, где нужна дополнительная позиция подрядчика.
Что нельзя терять при смене подрядчика
При смене команды бизнес рискует потерять не только код. Часто важнее сохранить контекст:
- актуальные доступы и владельцев доступов;
- карту окружений, доменов, серверов и репозиториев;
- список интеграций и внешних зависимостей;
- принятые архитектурные решения и причины этих решений;
- открытые риски и технический долг;
- незакрытые вопросы по бизнес-логике;
- критерии готовности ближайшего релиза.
Чек-лист передачи проекта
| Что подготовить | Зачем это нужно |
|---|---|
| Репозитории и ветки | Новая команда должна понимать, где актуальный код |
| Доступы и инфраструктура | Без них передача превращается в ручной поиск владельцев |
| Документация по интеграциям | Ошибки обменов часто становятся скрытым риском |
| Список открытых задач | Помогает отделить недоделки от новых требований |
| Карта модулей | Снижает риск сломать работающие сценарии |
| Вопросы текущему подрядчику | Позволяет забрать контекст до разрыва отношений |
| Риски для новой команды | Помогает честно оценить сроки следующего этапа |
Что стало понятно
Задержки были связаны не только с исполнительской частью. Часть проблем возникала из-за неполной фиксации требований, неочевидных технических зависимостей и отсутствия единой картины проекта.
Это не отменяло претензии к подрядчику, но меняло порядок действий. Сначала нужно было подготовить техническую передачу и список вопросов, затем принимать решение о смене команды.
План действий
- Зафиксировать текущее состояние проекта и спорные зоны.
- Сформировать технический пакет передачи.
- Подготовить вопросы текущему подрядчику.
- Отделить критичные риски от управленческого шума.
- Оценить, какие работы можно продолжать, а какие лучше остановить.
- Подготовить новую команду к реальному состоянию проекта, а не к ожиданиям из старого плана.
Вывод для похожих проектов
Смена подрядчика может быть правильным решением, но её нельзя делать как эмоциональный рывок. Сначала нужно понять, что именно передаётся новой команде, какие риски она унаследует и какие вопросы нужно закрыть до перехода.
Для похожих ситуаций полезны технический контроль подрядчика, аудит web-проекта, аудит проблемного проекта и статья как контролировать разработку портала.
