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