Artyom_Harris
New member
Полтора года назад я столкнулся с ситуацией, которую, наверное, знает каждый тимлид. Мой ключевой разработчик положил на стол заявление об уходе, и до его последнего рабочего дня оставалось ровно две недели. Первое, что я почувствовал, — это не злость и не паника, а глухое понимание: половина знаний о нашей системе живёт только в его голове и уйдёт вместе с ним. Именно тогда я понял, что передача знаний — это не про вежливость на прощание, а про выживание продукта.
Начал я не с документации, а с трезвой инвентаризации. Мы сели и выписали всё, что знает только он: почему в биллинге есть странная ветка с округлением, зачем в деплое вручную правят один конфиг, какие кнопки в админке лучше не нажимать, где лежат ключи и к каким сервисам у него личный доступ. Список получился длинным и честно меня напугал. Зато сразу стало видно, что успеть целиком нереально, и нужно расставлять приоритеты. Главный критерий у меня был простой: что сломается в первый же день после его ухода, а что может подождать месяц.
Дальше я отказался от идеи устроить серию лекций. Уходящий человек в режиме рассказа всё равно пропускает самое важное, потому что считает это очевидным. Работает другое: он делает задачу при свидетеле, а свидетель задаёт вопросы и ведёт записи. Мы взяли двух принимающих разработчиков, а не одного, — так меньше риска снова получить единственную точку отказа. И я специально не экономил на этом время: передвинул спринт, снял с человека часть рутины и оставил ему только передачу. Две недели — это не так много, но если не отвлекать, получается удивительно много.
С документацией я советую не гнаться за объёмом. Мы не писали красивую книгу о нашей архитектуре, вместо этого делали короткие заметки прямо у сложных кусков кода и один короткий сценарий на каждый критичный процесс: как выкатить релиз, как откатить, как поднять сервис после падения, что смотреть в логах в первую очередь. Каждая такая инструкция умещалась на одну страницу и была написана так, чтобы её понял человек, который видит систему впервые. Полезным побочным эффектом стало то, что часть таких страниц потом пригодилась в реальных авариях, когда автор уже уволился.
Отдельным блоком у нас шли доступы и ответственность. Мы прошли по чек-листу и сняли все личные привязки: пароли и ключи перевели на сервисные аккаунты, права выдали команде, а не конкретному человеку, и записали, кто теперь владелец каждого сервиса. Это скучная часть, но именно она чаще всего превращается в катастрофу в пятницу вечером. Не поленитесь также отметить, какие внешние интеграции и договорённости держались на личных контактах уходящего человека, и познакомьте новых владельцев с этими людьми.
Самый честный вывод, который я вынес из этой истории, звучит неприятно, но полезно. Если передача знаний за две недели кажется вам невыполнимой задачей, значит, вы уже давно жили в зоне риска, а не просто попали в неудобную ситуацию. После того ухода мы ввели простое правило: критичные модули не могут иметь одного знающего человека, и раз в квартал кто-то из команды специально делает задачу из чужой зоны. Это не идеально и это стоит времени, но следующее заявление об уходе мы встретили уже гораздо спокойнее и без аврала.
И ещё одно наблюдение напоследок, уже про человеческую сторону. Уходящий коллега почти никогда не саботирует передачу, если вести себя по-человечески: спокойно, без упрёков и без попытки удержать любой ценой. Мне помогло договориться о честной сделке — мы уважаем его сроки и планы, он выкладывается в последние две недели и остаётся на связи для пары коротких вопросов уже после увольнения. Это гораздо эффективнее, чем обиды, и часто сохраняет хорошие отношения на годы вперёд.
А как вы действовали, когда из команды уходил ключевой человек? Что реально помогло вам сохранить знания и не потерять продукт, и что вы сделали бы иначе, если бы пришлось начинать эти две недели сначала?
Начал я не с документации, а с трезвой инвентаризации. Мы сели и выписали всё, что знает только он: почему в биллинге есть странная ветка с округлением, зачем в деплое вручную правят один конфиг, какие кнопки в админке лучше не нажимать, где лежат ключи и к каким сервисам у него личный доступ. Список получился длинным и честно меня напугал. Зато сразу стало видно, что успеть целиком нереально, и нужно расставлять приоритеты. Главный критерий у меня был простой: что сломается в первый же день после его ухода, а что может подождать месяц.
Дальше я отказался от идеи устроить серию лекций. Уходящий человек в режиме рассказа всё равно пропускает самое важное, потому что считает это очевидным. Работает другое: он делает задачу при свидетеле, а свидетель задаёт вопросы и ведёт записи. Мы взяли двух принимающих разработчиков, а не одного, — так меньше риска снова получить единственную точку отказа. И я специально не экономил на этом время: передвинул спринт, снял с человека часть рутины и оставил ему только передачу. Две недели — это не так много, но если не отвлекать, получается удивительно много.
С документацией я советую не гнаться за объёмом. Мы не писали красивую книгу о нашей архитектуре, вместо этого делали короткие заметки прямо у сложных кусков кода и один короткий сценарий на каждый критичный процесс: как выкатить релиз, как откатить, как поднять сервис после падения, что смотреть в логах в первую очередь. Каждая такая инструкция умещалась на одну страницу и была написана так, чтобы её понял человек, который видит систему впервые. Полезным побочным эффектом стало то, что часть таких страниц потом пригодилась в реальных авариях, когда автор уже уволился.
Отдельным блоком у нас шли доступы и ответственность. Мы прошли по чек-листу и сняли все личные привязки: пароли и ключи перевели на сервисные аккаунты, права выдали команде, а не конкретному человеку, и записали, кто теперь владелец каждого сервиса. Это скучная часть, но именно она чаще всего превращается в катастрофу в пятницу вечером. Не поленитесь также отметить, какие внешние интеграции и договорённости держались на личных контактах уходящего человека, и познакомьте новых владельцев с этими людьми.
Самый честный вывод, который я вынес из этой истории, звучит неприятно, но полезно. Если передача знаний за две недели кажется вам невыполнимой задачей, значит, вы уже давно жили в зоне риска, а не просто попали в неудобную ситуацию. После того ухода мы ввели простое правило: критичные модули не могут иметь одного знающего человека, и раз в квартал кто-то из команды специально делает задачу из чужой зоны. Это не идеально и это стоит времени, но следующее заявление об уходе мы встретили уже гораздо спокойнее и без аврала.
И ещё одно наблюдение напоследок, уже про человеческую сторону. Уходящий коллега почти никогда не саботирует передачу, если вести себя по-человечески: спокойно, без упрёков и без попытки удержать любой ценой. Мне помогло договориться о честной сделке — мы уважаем его сроки и планы, он выкладывается в последние две недели и остаётся на связи для пары коротких вопросов уже после увольнения. Это гораздо эффективнее, чем обиды, и часто сохраняет хорошие отношения на годы вперёд.
А как вы действовали, когда из команды уходил ключевой человек? Что реально помогло вам сохранить знания и не потерять продукт, и что вы сделали бы иначе, если бы пришлось начинать эти две недели сначала?