Как не потерять знания при уходе разработчика

Короткий ответ

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

Если проект держится на фразе “он всё знает”, это уже риск для бизнеса. Уход одного человека может остановить доработки, усложнить поддержку и сделать новую команду зависимой от расследований.

Какие знания обычно теряются

В web-проектах теряется не только код. Код обычно остаётся, но без контекста он плохо объясняет, почему система работает именно так.

Чаще всего исчезают:

• причины нестандартных технических решений;
• правила бизнес-логики и исключения;
• знания о слабых местах архитектуры;
• порядок релизов и откатов;
• нюансы интеграций с CRM, 1С, ERP и внешними API;
• владельцы доступов и сервисов;
• история ошибок и обходных решений;
• договорённости, которые жили только в чатах.

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

Главный принцип: знания должны иметь владельца и место

У каждого важного знания должно быть два признака:

Владелец. Кто отвечает за актуальность информации.

Место хранения. Где это знание лежит: документация, task tracker, репозиторий, схема, регламент, база знаний, инструкция или карта проекта.

Если знание нельзя найти без звонка конкретному разработчику, оно не управляется. Это особенно опасно для порталов, личных кабинетов, CRM и B2B-систем, где есть роли, статусы, документы, интеграции и права доступа.

Минимальный набор, который должен остаться у бизнеса

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

1. Карта системы

Нужно понимать, из каких частей состоит проект:

• frontend и backend;
• админка;
• личный кабинет или портал;
• база данных;
• очереди, cron-задачи, фоновые процессы;
• внешние сервисы;
• окружения: production, staging, dev.

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

2. Карта бизнес-логики

Техническая команда должна понимать не только код, но и смысл процессов.

Нужно описать:

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

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

3. Карта интеграций

Интеграции часто становятся самым уязвимым местом при уходе разработчика.

Нужно зафиксировать:

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

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

4. Доступы и владельцы сервисов

Доступы должны быть не в личных аккаунтах разработчика, а в управляемом контуре компании.

Проверьте:

• домены и DNS;
• хостинг или серверы;
• репозитории;
• CI/CD или процесс деплоя;
• базы данных;
• аналитика;
• почта и уведомления;
• внешние API;
• CRM, 1С и другие интеграции.

Важно не только получить логины. Нужно понять, кто владелец каждого сервиса и как восстановить доступ при уходе человека.

5. Процесс релиза

Уход разработчика часто вскрывает, что релизы держались на устной инструкции.

Нужно описать:

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

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

Что запросить до ухода человека или подрядчика

Если разработчик или подрядчик ещё доступен, лучше не ждать последнего дня.

Запросите:

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

Запрос должен быть спокойным и деловым. Цель не в обвинении, а в снижении риска для бизнеса.

Что делать, если человек уже ушёл

Если разработчик или подрядчик уже недоступен, нужно не пытаться сразу продолжить разработку, а восстановить контекст.

Порядок действий:

1. Собрать все доступные материалы: код, задачи, переписки, доступы, старые ТЗ, схемы.
2. Проверить возможность локального запуска и деплоя.
3. Составить первичную карту модулей, интеграций и окружений.
4. Найти критичные бизнес-сценарии и зоны риска.
5. Зафиксировать неизвестные области, где нельзя делать быстрые изменения.
6. Подготовить план передачи или восстановления проекта.

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

Как не допустить повторения

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

Практичные правила:

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

Это не бюрократия, если документация помогает принимать решения и передавать проект. Бюрократией она становится только тогда, когда пишется ради формальности.

Какие признаки показывают, что знания уже под угрозой

Стоит остановиться и провести проверку, если:

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

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

Практический вывод

Знания проекта нельзя хранить только в головах разработчиков. Для бизнеса это такой же актив, как код, домен, база данных или CRM.

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

Для первичной проверки можно использовать чек-лист контроля подрядчика и статью как подготовить проект к передаче новой команде.

Материалы по теме