В идеале сформированная в начале проекта команда успешно работает до его завершения (а то и переходит в полном составе в следующий проект). Но на практике всегда возникают проблемы, требующие «замены коней на переправе». Решать задачи найма и увольнения нужно исходя из принципа минимизации рисков для проекта в целом, что требует от ПМ определенной самодисциплины.
Подход к увольнению разработчика должен основываться на сравнении двух рисков: потерь от его дальнейшего участия в проекте и потерь от его увольнения. Потери от дальнейшего участия – это разница между ожидаемым (исходя из уже завершенных заданий) вкладом разработчика в проект и потенциальным падением производительности других разработчиков (исходя из уже имевших место проблем). Потери от увольнения складываются из затрат на замену разработчика (если таковая требуется, бывают и стопроцентные бездельники) и падением производительности других разработчиков от осознания факта, что их тоже могут уволить. Если разработчик просто ничего не делает, не мешая при этом другим, – его увольнение приведет к дополнительным потерям и потому нецелесообразно. А вот в случае, когда разработчик работает за троих, но при этом постоянно демотивирует команду (называет разработчиков тупыми или заставляет переделывать работу, исходя из своих прихотей), увольнение может оказаться полезным. В некоторых случаях, например при демонстративном нарушении неписаных правил команды, увольнение является единственным возможным выходом.
Идеальным режимом работы ПМ является «недеяние» (предоставление ресурсов, позволяющих разработчикам самим принимать все необходимые решения), поэтому запрос на увольнение должен исходить от самих разработчиков. Поскольку они заняты основной работой и прекрасно понимают, какие с ней возникают осложнения, поведение кандидата на увольнение может считаться токсичным только тогда, когда на него начинают жаловаться другие разработчики. Разумеется, чтобы такая информация доходила до ПМ, он должен пользоваться у разработчиков доверием (см. п. 3.2.6).
Следует помнить, что увольнение даже очевидно токсичного разработчика все равно наносит урон команде в целом и поэтому должно проводиться по определенным правилам.
1. ПМ создает и использует атмосферу доверия со стороны всех разработчиков для постоянного мониторинга возникающих в ходе работы проблем.
2. Если эти проблемы оказываются связаны с конкретным разработчиком (на него жалуется больше одного человека), оценивается соотношение рисков по его сохранению в проекте (с перемещением на менее ответственный участок, в другую команду и т. д.) и увольнению.
3. Проверяется возможность представить увольнение как то, чего не может случиться с другими разработчиками (ХХХ нарушил правило, которое никому больше в голову не придет нарушать).
4. Если такая возможность есть и риски для проекта при сохранении разработчика выше, чем при увольнении, запускается процедура увольнения:
1) ПМ подыскивает варианты альтернативного трудоустройства разработчика (другие отделы той же компании, другие проекты и т. д.);
2) ПМ организует «коллективное мнение», что кандидат не вписался в проект, и когда тот придет на доверительную беседу, соглашается, что есть такая проблема и ее нужно решать;
3) само увольнение производится утром, по американскому сценарию, и оставляет у всех разработчиков, включая увольняемого, ощущение «ну вот теперь дела пойдут на лад».
Результат. Увольнение разработчика воспринимается им самим и другими разработчиками как успешное разрешение затянувшейся неприятной ситуации, вызванной нарушением правил, которые никогда больше не будут нарушаться.
Поскольку увольнение даже самого бестолкового разработчика оставляет часть заданий «подвешенными», во многих случаях ему имеет смысл подыскивать замену, а не увеличивать нагрузку на других разработчиков (особенно в ситуации, когда увеличение зарплаты пропорционально нагрузке не предусмотрено, то есть в 99 % случаев). Для этого используется метод найма нового разработчика.
1. ПМ обращается к заметкам по кандидатам, отсмотренным в ходе собеседований на проект, либо проводит новый цикл собеседований (в случае замены критически важного разработчика). Делается это, разумеется, до, а не после увольнения предыдущего разработчика.
2. После получения согласия кандидата ПМ в буквальном смысле слова берет его под руку и проводит через все формальные этапы трудоустройства, знакомя с внешней средой команды проекта.
3. ПМ организует знакомство нового разработчика с командой, руководствуясь карточками аффилянтов и заранее прогнозируя, с кем из команды новый разработчик сможет установить наиболее дружеские отношения. Для скорейшего формирования отношений используется прием импринтинга – новый разработчик в первую очередь знакомится именно с наиболее подходящим членом команды. В идеале ПМ организует им возможность пообщаться – что-нибудь вроде совместного ожидания совещания или заполнения каких-то бумаг («старый» разработчик должен быть вырван из хода проекта, чтобы появилась возможность переключить внимание на новичка).
Результат. Новый разработчик, вписавшийся в команду буквально с первых же дней работы.