IT-проект зависит от одного разработчика: как снизить риски

Что делать, если IT-проект держится на одном разработчике

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

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

Такую зависимость часто описывают термином bus factor — количеством людей, потеря доступности которых создаёт критический риск для проекта. Для бизнеса важнее не сам показатель, а практический вопрос: какие операции компания не сможет выполнить, если этот специалист завтра перестанет участвовать в проекте?

Как понять, что проект действительно зависит от одного разработчика

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

Признаки критической зависимости выглядят так:

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

Какие виды зависимости бывают

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

Что бизнесу нужно взять под контроль в первую очередь

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

Проверить стоит как минимум следующие области.

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

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

Что проверить в исходном коде

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

На первом этапе достаточно проверить:

доступен ли весь исходный код;

соответствует ли репозиторий рабочей версии;

можно ли собрать приложение;

есть ли инструкции по запуску;

понятна ли структура проекта;

зафиксированы ли зависимости;

вынесены ли конфигурации отдельно от кода;

не хранятся ли критические секреты непосредственно в репозитории;

есть ли автоматические тесты;

какие модули являются наиболее сложными;

где сосредоточен технический долг;

существуют ли незавершённые изменения, которые есть только на компьютере разработчика.

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

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

Как понять, можно ли запустить проект без основного разработчика

Один из самых показательных тестов — попросить другого специалиста развернуть проект по существующим материалам.

Не спрашивать: «У нас есть README?»

Проверить на практике.

Новый разработчик должен самостоятельно:

1. Получить доступ к репозиторию.
2. Установить необходимые зависимости.
3. Настроить локальное окружение.
4. Запустить проект.
5. Подключить тестовые сервисы или базу данных.
6. Выполнить небольшую безопасную доработку.
7. Собрать тестовую версию.
8. Развернуть её в тестовой среде.

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

Наличие документации и способность другого специалиста выполнить операцию по этой документации — не одно и то же.

Именно практическое воспроизведение процесса показывает реальные пробелы.

Какая документация действительно нужна

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

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

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

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

Часть наиболее ценной информации никогда не попадает в код или стандартную документацию.

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

Особенно полезно спросить:

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

Последний вопрос часто даёт больше полезной информации, чем формальная просьба «опишите архитектуру проекта».

Как организовать передачу знаний

Передача проекта не должна ограничиваться несколькими презентациями.

Лучше сочетать объяснение с реальной работой.

Как проверить инфраструктуру и процесс релиза

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

Нужно отдельно проверить релизный процесс:

как формируется production-сборка;

где находятся переменные окружения;

как выполняется deployment;

есть ли ручные операции;

как применяются изменения базы данных;

кто имеет доступ к серверам;

что происходит при неудачной выкладке;

есть ли возможность rollback;

где находятся резервные копии;

кто получает уведомления мониторинга.

Хорошая проверка — провести тестовую выкладку силами другого специалиста.

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

Что делать, если документации почти нет

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

Восстанавливать информацию лучше по приоритетам.

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

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

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

Сначала необходимо:

1. Проверить все критические доступы.
2. Убедиться, что актуальный код находится в корпоративном репозитории.
3. Зафиксировать инфраструктуру.
4. Записать процесс сборки и релиза.
5. Разобрать наиболее важные интеграции.
6. Передать незавершённые задачи.
7. Зафиксировать известные проблемы.
8. Организовать совместную работу с новым специалистом.
9. После завершения передачи отозвать ненужные доступы по правилам компании.

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

Что делать, если специалист уже недоступен

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

Начать следует с инвентаризации:

репозиториев;

серверов;

баз данных;

резервных копий;

доменов;

CI/CD;

облачных сервисов;

интеграций;

систем мониторинга;

документации;

истории задач;

корпоративной технической переписки, если доступ к ней законно принадлежит компании.

После этого новая команда должна определить:

можно ли получить актуальный код;

можно ли собрать проект;

можно ли запустить его в тестовой среде;

какие компоненты неясны;

какие интеграции требуют дополнительного изучения;

где риск изменения особенно высок.

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

Нужно ли переписывать проект

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

Сначала нужно понять техническое состояние продукта.

После аудита возможны разные решения:

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

Полный rewrite часто сам создаёт дополнительные риски.

Новой команде приходится восстанавливать:

• неописанную бизнес-логику;
• исключения;
• интеграции;
• исторические сценарии;
• требования, которые нигде не зафиксированы.

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

Как понять, что передача проекта завершена

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

Готовность можно проверить практическими критериями.

Проект стал менее зависимым от одного человека, если:

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

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

Как не создать нового «незаменимого» специалиста

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

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

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

План снижения зависимости от одного разработчика