Есть несколько вещей, которые вы можете сделать (в таком порядке):
Обновление: Используйте это как возможность укрепить свою команду. Устройте прощальную вечеринку для уходящего парня и убедитесь, что и он, и команда знают, что его вклад был оценен по достоинству. :-) (А если у вас нет бюджета, просто поговорите с членами команды, и вы все скинетесь, чтобы пригласить его на выпивку или два)
.Я согласен с Фрэнси, с небольшим изменением приоритетов:
Начните обсуждение с руководством вашей компании ...
Да. Во всех смыслах. Сегодня. Если лучший результат уходит, то и второе место, вероятно, не сильно отстает. Поговорите с остальными разработчиками. Они счастливы? Вы уверены? Они просто мило разговаривают с вами из уважения к вашему авторитету, но у них возникают загадочные «встречи с врачом»? Если бы вы были членом команды, вы бы искали?
Вы можете найти другого старшего разработчика, который щедро поделится своими отзывами со своими коллегами. Удачи.
Парное программирование является полезной техникой для смягчения проблем, возникающих в связи с уходом квалифицированного сотрудника, поскольку оно распространяет знания. Это также полезно для наставничества новых сотрудников.
Во-первых, избегайте специализации. Если у вас есть более 0 дней на переход, это роскошь. Люди болеют, умирают, убегают, арестовываются, увольняются и т. Д. Каждый день. Таким образом, непрерывность проекта должна предполагать, что рано или поздно кто-то неожиданно перестанет выходить на работу. Я знаю случай, когда парня арестовали за своим столом, увели в наручниках, а его компьютер немедленно отправили в лабораторию для проведения судебно-медицинской экспертизы. Не так много времени на передачу знаний.
Проверка кода, проверка дизайна и ротация проблемных заявок / исследований познакомят всю команду со всеми аспектами системы.