Что происходит с проектом, когда уходит единственный разработчик

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

Что именно уходит

Доступы. Ключи от серверов, панель хостера, регистратор доменов, реестр образов, объектное хранилище. Полного списка не существует ни у кого — он складывался по одному за год.

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

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

Контекст заказчика. О чём договаривались устно, что обещали, чего он боится.

Первое восстанавливается ротацией. Остальные три — нет.

Арифметика ротации

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

Реалистичная оценка — три-четыре рабочих дня и почти гарантированно пропущенная машина. Не по небрежности: список составляется по памяти, а память не полна по определению.

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

Что помогает, кроме дисциплины

Хранилище с журналом раскрытий. Когда участника снимают с проекта, всё, что он открывал, помечается «сменить» — списком. Вспоминать не нужно, и это ровно та часть, где память подводит.

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

Решения, записанные отдельно от кода. Не комментарий «что делает функция», а запись «почему выбрали это, что рассматривали ещё, чем оплачено». У нас таких записей около шестидесяти, и половина ценности — в перечислении отвергнутых вариантов: без них следующий человек пойдёт по тому же кругу.

Связи между документами. Вопрос «где мы это решили» должен решаться переходом от документа, который вы помните, а не поиском по словам, которых вы не знаете.

Как проверить готовность

Три вопроса, ответы на которые стоит знать до того, как понадобятся:

1. Сколько времени займёт ротация, если сегодня уйдёт любой один человек? Не «сколько машин», а сколько дней.
2. Есть ли список того, что он открывал? Не «можно ли восстановить по логам», а есть ли он готовым.
3. Где написано, почему база устроена так? Если ответ «он знает» — это и есть ответ на весь вопрос.

Что из этого следует

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

Хорошая новость в том, что всё это пишется не в спешке при увольнении, а по одной строке в момент, когда решение принимается. Плохая — что именно в этот момент писать не хочется никогда.

---

Доступы проекта у нас лежат в хранилище с журналом раскрытий, а решения — рядом с документами, на которые ссылаются. Как это устроено — Хранилище доступов.