Короткий ответ
#Принцип
У уходящего разработчика конечное и убывающее количество внимания для вас, и оно конкурирует с новой работой, с передачей дел собственному преемнику и с естественным человеческим желанием отстраниться от того, что заканчивается. Планируйте один хороший час, а не сорок.
Поэтому единственный важный вопрос: чего не даст больше никто?
| Что | Восстановимо без них? | Просить? |
|---|---|---|
| Структура — компоненты, зависимости, интерфейсы | Да, из системы | Нет |
| Поведение — что происходит при неудачном платеже | В основном да, с усилиями | Только то, что анализ пометил как неизвестное |
| Рассуждения — почему построено именно так | Нет | Да, в первую очередь |
| Эксплуатационные привычки — что они проверяют, что игнорируют | Нет | Да, во вторую |
| Владение аккаунтами и доступы | Выясняется — медленно и мучительно | Да, и проверить самому |
#Рассуждения — невосстановимая половина
Задавайте это письменно. Письменные ответы переживают уход; разговор, который оба помните наполовину, — нет.
Шесть вопросов, по приоритету
- Какую часть этой системы вам было бы страшно отдать кому-то на изменение и почему? Самый урожайный вопрос из всех доступных. Он надёжно вытаскивает то, чего иначе не нашли бы полгода.
- Что вы пробовали и что не сработало, и почему вы пошли этим путём?
- Что здесь стоит из-за ограничения, которого больше нет? Не даёт новой команде потратить квартал на удаление того, что несущее, — или на сохранение того, что уже нет.
- Какие решения вы приняли бы сейчас иначе?
- Что вы хотели сделать и на что так и не получили согласия?
- Будь у вас ещё месяц, что бы вы починили?
Почему письменно
Записанный видеообзор лучше, чем ничего, и намного хуже письменных ответов. Двухчасовую запись никто не пересматривает, искать по ней нельзя, а человека, которому она нужнее всего, ещё даже не наняли. Шесть письменных абзацев прочитывают.
#Эксплуатационные привычки — знание для трёх часов ночи
Эту категорию забывают полностью, и именно она бьёт в первую плохую ночь после их ухода.
Ещё шесть
- Что вы проверяете после выкатки?
- Какие оповещения вы игнорируете, а какие действительно что-то значат? Без этого новая команда либо игнорирует всё, либо расследует всё. Плохо и то и другое.
- Что ломается регулярно и что вы с этим делаете?
- Что приходится делать руками и когда? Месячные и квартальные ручные шаги обнаруживают на третий месяц.
- Что вам постоянно приходится объяснять новым людям?
- Что вы проверили бы первым, если бы сайт упал прямо сейчас?
#Факты, которые быстрее спросить, чем вывести
Небольшое число фактических вопросов стоит задать, даже если теоретически ответ можно установить иначе: спросить — минута, установить — неделя.
- Есть ли что-то работающее, чего нет в этом репозитории? Задачи по расписанию на сервере, облачная функция из консоли, скрипт на их машине, отчёт, который они рассылают руками.
- Кто вне компании зависит от этой системы? Партнёры, интеграторы, клиент с API-ключом. Больше этого не знает никто.
- Какими внешними сервисами она пользуется и на чьём аккаунте каждый? Вторая половина вопроса — та, которой в коде нет.
- У кого ещё когда-либо был доступ ко всему этому? Бывшие подрядчики, друг, который однажды помог, агентство трёхлетней давности.
- Есть что-то, что вы хотели бы сказать новому человеку в первый день? Открытый вопрос-мешок, который своё место оправдывает.
#Доступы, в правильном порядке
Инстинкт — отозвать всё немедленно. Этот инстинкт запирает людей снаружи их собственных систем.
-
Сначала установите владение
По каждому аккаунту: личность-владелец — это адрес компании, которым вы управляете, или личный? Всё из второй категории — это перенос, а не отзыв.
-
Перенесите то, что нужно перенести
Домен, облачную организацию, регистратора, магазины приложений, платёжного провайдера. У нескольких процедура на несколько дней, и хотя бы один вас удивит.
-
Создайте собственный путь входа
Админские аккаунты компании везде, с восстановлением на почтовый ящик компании. Проверьте каждый, прежде чем переходить к следующему шагу.
-
И только потом отзывайте и меняйте
Личные аккаунты, личные токены, SSH-ключи, всё, что на их машине. Считайте скомпрометированным каждый доступ, который они могли видеть, — это гигиена, а не обвинение.
#Чего просить не надо
Не просите их написать документацию. Три практические причины:
- Это съедает дни их оставшегося времени и даёт то, что они помнят, а не то, что там есть.
- Это пишется в спешке, уходящим человеком, для читателя, которого ещё не существует.
- Почти всё это выводится из системы ценой одной инструкции — и не ими.
Ход лучше: сначала выведите структурную картину, а потом отправьте им дыры в виде вопросов. На двенадцать конкретных вопросов отвечают и в последнюю неделю. «Напишите, пожалуйста, документацию» даёт документ, которому никто не доверяет и из-за которого всем неловко.
#Что идёт не так
Тянуть до последней недели.
Вместо этого Начинайте в день подачи заявления. Внимания больше всего в первый день и меньше всего в тридцатый.
Задавать открытые вопросы на встрече.
Вместо этого Отправьте пронумерованный список и попросите письменные ответы к дате. На конкретные вопросы отвечают конкретно.
Относиться к этому как к аудиту.
Вместо этого Ставьте это как непрерывность. Большинство уходящих хотят, чтобы построенное ими продолжало работать, и помогут, если просьба не враждебна.
Забыть про адреса восстановления на аккаунтах.
Вместо этого Проверьте их у каждого аккаунта, потерю которого вы не потянете. Аккаунт компании с личным адресом восстановления — не аккаунт компании.
Не спросить, что работает вне репозитория.
Вместо этого Спросите ровно этими словами. Прямо спрошенные люди вспоминают сразу и иначе упомянуть об этом не догадываются.
#Чего это не покрывает
Чего это не делает
- Условия трудовых отношений, сроки уведомления и всё договорное. Спросите того, кто в этом разбирается.
- Что делать, если человек отказывается участвовать. Тогда всё, что является свойством системы, по-прежнему восстановимо, а всё, что является свойством человека, — нет; расставляйте приоритеты соответственно.
- Его преемника. Это про извлечение того, что уходит, а не про онбординг того, что приходит.
- Качество кода. Уходящий разработчик — не тот человек, у которого стоит спрашивать, хорош ли его собственный код.