Scrum. Революционный метод управления проектами

Идея проста. Каждому участнику дается колода карт с числами Фибоначчи – 1, 3, 5, 8, 13 и так далее. Каждая единица работы, которая должна быть оценена, выкладывается на стол. Затем каждый участник группы берет ту карту, число на которой, по его мнению, соответствует объему необходимых усилий, и кладет ее на стол рубашкой вверх. Затем все одновременно открывают карты. Если расхождение не больше чем на две карты (скажем, пятерка, две восьмерки и тринадцать), команда просто их складывает, берет среднее арифметическое (в данном случае 6,6) и переходит к следующей задаче. Помните, мы говорим об оценках, а не о жестких планах. И оценках небольших фрагментов проекта.

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

Например, вы красите стены в доме, и вам нужно оценить, сколько времени уйдет на покраску гостиной, кухни и двух спален. Вы работаете с мастерами, с которыми уже красили стены раньше. Итак, сначала две спальни: все оценивают их на три. Никаких особых разногласий, вы делали такое раньше, и вам не кажется, что со спальнями могут возникнуть сложности. Затем команда оценивает гостиную. Это довольно большое помещение, но там все просто. Оценки расходятся от пяти до тринадцати, затем сходятся на средней оценке – шесть. И снова нет смысла спорить. Затем дело доходит до кухни, и тут на столе оказываются и три, и восемь, и тринадцать, и еще пять. Тот, кто положил тройку, уверяет, что комната небольшая, площадь даже меньше, чем у двух спален. Человек, положивший цифру тринадцать, напоминает, что стоит учесть все то время, которое понадобится, чтобы заклеить шкафчики и столы, а красить отдельные маленькие участки придется кистью, а не валиком. Команда быстро выкладывает новые карты. Цифра три превратилась в восемь, все остальные оценки остались старыми. Теперь оценки довольно близки друг к другу, можно их сложить, вычислить среднее арифметическое и переходить к следующей задаче.

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

Я научился всему этому на собственном горьком опыте, когда работал в Пенсильвании в GSI Commerce, занимавшейся интернет-продажами. С тех пор их купила компания eBay. GSI специализируется на создании онлайн-магазинов для таких компаний, как Levi’s, Toys “R” Us, Major League Baseball и Zales Diamond. Это не мелкие проекты. И GSI с ними очень неплохо справляется.

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

Как выяснилось, этот путь до такой степени плох, что эксперты остановились на полпути, успев оценить ровно сорок проектов. Сразу приходят на ум срочно прерванные клинические исследования лекарств, в процессе которых выяснялось, что препараты скорее убивают, чем лечат. Экспертные оценки в GSI были настолько далеки от реальности, что оказались совершенно бесполезными.

Ничто не выполнялось вовремя. Клиенты оставались недовольными. Рабочие группы были деморализованы. В общем, полная катастрофа. Руководители вернулись к старому варианту: теперь группы разработчиков снова самостоятельно проводили оценку проектов. Вот чудеса! Оценки вновь стали сходиться с реальностью.