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