За прошедшие годы я консультировал многие банки и страховые компании. Единственное, что у них было общего – странный подход к распределению проектов. Банковский проект часто представляет собой относительно малую задачу, которая может быть выполнена одним или двумя программистами за несколько недель. В проект обычно включался руководитель, который одновременно вел другие проекты. К нему добавлялся бизнес-аналитик, который предоставлял требования для других проектов. Дальше добавлялись программисты, которые также работали над другими проектами. Потом один-два тестера, у которых тоже были другие проекты.

Заметили закономерность? Проект настолько мал, что никто не может заниматься только им одним. Все участники уделяют проекту 50 % или даже 25 % времени.

А теперь правило: половины человека не бывает.

Бессмысленно приказывать программисту посвятить половину времени проекту A, а другую половину – проекту B, особенно если в двух проектах участвуют разные руководители, бизнес-аналитики, программисты и тестеры. Разве подобную мешанину можно назвать группой?

Группы формируются не сразу. Между участниками постепенно налаживаются отношения. Они учатся работать друг с другом, узнают странности, сильные и слабые стороны своих коллег. Со временем участники «притираются» друг к другу.

В «притертой» группе есть что-то волшебное: она способна творить чудеса. Участники понимают друг друга, поддерживают и требуют максимальной отдачи. Благодаря их взаимодействию достигаются результаты.

«Притертая» группа обычно содержит около дюжины участников. Их может быть и больше (до 20) или меньше (до 3), но оптимальный размер обычно где-то около 12. В группу должны входить программисты, тестеры и аналитики. И у нее должен быть руководитель проекта.

Соотношение численности программистов и тестеров/аналитиков изменяется в широких пределах, но пропорция 2:1 вполне разумна. Таким образом, хорошо «притертая» группа из 12 человек может состоять из семи программистов, двух тестеров, двух аналитиков и руководителя проекта.

Аналитики разрабатывают требования и пишут для них автоматизированные приемочные тесты. Тестеры тоже пишут автоматизированные приемочные тесты, но отличаются от аналитиков направленностью. И те и другие пишут тесты, но аналитики ориентируются на коммерческую ценность, а тестеры – на правильность работы кода. Аналитики пишут «оптимистичные» тесты, а тестеры беспокоятся о том, что может пойти не так, и пишут тесты для выявления сбоев и граничных случаев.

Руководитель проекта следит за прогрессом и принимает меры к тому, чтобы группа понимала сроки и приоритеты.

Один из участников группы может совмещать выполнение своих обязанностей с ролью наставника, ответственного за соблюдение технологических процессов и методов. Он становится своего рода «коллективной совестью», когда у группы возникает соблазн нарушить правила под давлением сроков.

Чтобы участники разобрались в своих различиях и договорились между собой, а группа действительно «притерлась», потребуется время. Процесс может занять полгода или даже год. Но когда это случается, происходит чудо. «Притертая» группа вместе планирует, вместе решает задачи, вместе разбирается с проблемами и добивается результатов.

Разбивать такие группы только из-за завершения проекта слишком расточительно. Лучше сохранить группу в прежнем составе и поручать ей новые проекты.

Банки и страховые компании пытались формировать группы на базе проектов. Такой подход неверен в принципе: группы просто не могут «притереться». Участники работают над проектом в течение короткого времени, притом посвящая ему лишь часть своего рабочего времени, а следовательно, не имеют возможности сработаться.

Профессиональные фирмы-разработчики поручают проекты существующим «притертым» группам, а не формируют группы для конкретного проекта. «Притертая» команда может вести сразу несколько проектов и распределять работу в соответствии со своими предпочтениями, квалификацией и способностями участников.

У каждой группы имеется определенная скорость работы, а проще говоря, объем работы, выполняемый за фиксированный промежуток времени. Некоторые группы измеряют свою скорость в пунктах в неделю (пункты – единица сложности). Функциональность каждого проекта, над которым работает группа, разбивается на блоки, сложность которых оценивается в пунктах. В дальнейшем производительность группы оценивается по количеству пунктов, реализованных за неделю.

Скорость – статистическая метрика. Группа может реализовать 38 пунктов в одну неделю, 42 пункта в другую и 25 в третью. По мере накопления данных вычисляется усредненный показатель.

Руководство может задать цели для каждого проекта, Например, если средняя скорость группы равна 50 и группа работает над тремя проектами, руководство может попросить группу распределить усилия в пропорции 15/15/20.

Помимо того что над проектами работает «притертая» команда, у этой схемы есть и другое преимущество. В напряженной ситуации бизнес-сторона может сказать: «Проект B в критическом состоянии; в следующие три недели направьте на него 100 % усилий».

Столь быстрое перераспределение приоритетов практически невозможно со случайно подобранными группами, тогда как «притертая» группа, работающая над двумя или тремя проектами одновременно, легко выполняет подобные «развороты на месте».

Один из аргументов против метода, за который я выступаю, заключается в том, что он частично лишает владельцев проекта уверенности и власти. Владельцы проекта, для которого была создана специальная группа, могут рассчитывать на полную отдачу этой группы. Они знают, что формирование и роспуск группы обходится недешево, поэтому бизнес не будет отнимать у них группу по краткосрочным тактическим соображениям.

С другой стороны, если проекты даются «притертым» группам и эти группы ведут сразу несколько проектов, бизнес может менять приоритеты по своему усмотрению. Из-за этого владелец проекта менее уверен в будущем. У него могут внезапно отобрать ресурсы, на которые он рассчитывает.

Честно говоря, я предпочитаю вторую ситуацию. Руки бизнеса не должны быть связаны искусственными сложностями формирования и роспуска групп. Если бизнес решит, что один проект обладает более высоким приоритетом, он должен иметь возможность быстро перераспределить ресурсы. Владелец проекта должен сам привести веские доводы в его пользу.