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