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