Книга за 15 минут: Революционный метод управления проектами (Часть 2)

Автономная многофункциональная команда

Высокоэффективные команды имеют три общие черты:

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

1. Стремление к постоянному совершенству. У выдающихся команд есть представление об общей цели. Они не останавливаются на стандартных решениях, высоко оценивают свои возможности и предъявляют строгие требования к себе и своей работе.
2. Автономность. Им присущи черты самоорганизующихся и самоуправляемых систем.
3. Многофункциональность. Они обладают всем необходимым, чтобы без внешнего вмешательства принимать решения и осуществлять их. Передавать проект поэтапно от одного специализированного отдела организации к другому гораздо менее эффективно, чем вести его одной командой, состоящей из разных специалистов.

“Скрам-мастер несет ответственность за ту часть проекта, которая отвечает на вопрос «Как делать?», а владелец продукта — за ту часть, которая отвечает на вопрос «Что делать?»”.

Достичь высоких показателей способны только небольшие команды — от пяти до девяти человек. Скорость работы группы, в которой больше девяти человек, заметно падает. Об этом же говорит и закон Фреда Брукса, сформулированный им в известной книге “Мифический человеко-месяц”: “Если проект не укладывается в сроки, то добавление рабочей силы задержит его еще больше”. Группы, начавшие использовать методику Scrum, повышали эффективность на 300 или 400%, а лучшие команды — даже на 800. Качество работы при этом тоже существенно возрастало. Их успехи показали, что сверхэффективности в работе можно достичь только при соблюдении следующих условий: режим автономности, постоянное совершенствование, атмосфера сотрудничества и взаимное обогащение знаниями и идеями.

“Каждая команда — над чем бы она ни работала — должна сама для себя определить критерий полезности и спрашивать результат с владельца продукта, поскольку именно он в ответе за то, чтобы ценность и стоимость продукта постоянно росли”.

Основные понятия и принципы Scrum

В самом начале проекта, который ведется по методике Scrum, команде необходимо составить максимально полный список требований к функциональным характеристикам продукта. Он называется “бэклог”. В нем могут быть записаны десятки и даже сотни задач — часть из них, естественно, никогда не будет решена. Первым делом отбираются приоритетные требования на основе нескольких критериев. Необходимо определить, какие задачи: “1) имеют самое большое значение для хода работ над проектом; 2) важнее всего для заказчика или будущего потребителя; 3) принесут максимальный доход; 4) проще всего осуществить”.

“Я все время пытаюсь объяснить главное: вместо того чтобы планировать все заранее, дорабатывайте план на протяжении всего проекта”.

Работу над проектом принято делить на короткие, но законченные этапы, или “спринты” (по аналогии с бегом на короткую дистанцию). Принцип разделения проекта на короткие этапы с публичным обсуждением Сазерленд позаимствовал у лаборатории Media Lab при МТИ. Идея “спринта” состоит в том, чтобы за короткое время попытаться решить ограниченное число задач, а затем посмотреть на полученный результат. Продолжительность каждого “спринта” должна быть оговорена заранее: чаще всего это неделя или две и в любом случае меньше месяца. В начале каждого такого цикла члены группы отбирают задачи (“единицы работы”), а в конце — внимательно анализируют свои результаты, взаимодействие между участниками, процессы и возникшие помехи. Члены команды идентифицируют самое важное из препятствий, с которыми им пришлось столкнуться, и решают, как его устранить в следующем “спринте”. Так выполняется правило “непрерывного совершенствования” (по-японски кайдзен).

“Все дело в построении правильной системы с правильными стимулами. Нужно дать людям свободу, уважение и право делать свое дело самостоятельно”.

Промежуточные результаты нужно не только оценивать самим, но и обязательно демонстрировать заказчику, например раз в месяц. Заказчику показывается какой-то завершенный фрагмент: допустим, полностью разработанная функция компьютерной программы или “функциональный прототип” автомобиля — то, что он сможет опробовать в деле, не дожидаясь конца проекта. На основе пожеланий заказчика “бэклог” модифицируется.

Информация о ходе проекта размещается на большой белой доске. Доска делится на три столбца: “Нужно сделать”, “В работе”, “Сделано”. Каждое из действий или заданий, которые группа должна выполнить за один “спринт”, записывается на отдельном стикере. По мере их выполнения стикеры перемещаются членами команды из колонки в колонку. В “Cделано” попадает только то, что было уже протестировано клиентом. Исполнитель каждой задачи известен всем: это обеспечивает взаимопомощь, а значит, саморегуляцию деятельности группы.

Поддерживают работу группы два специально выделенных участника. Один из них — “скрам-мастер”. Это не руководитель, а играющий тренер, “что-то среднее между тренером и капитаном команды”. Основная его задача — отслеживать, как соблюдаются процедуры. Он помогает группе справляться с возникающими препятствиями, проводит ежедневные собрания, постоянно ищет ответ на вопрос, как сделать работу команды еще лучше. Еще одно важное действующее лицо — “владелец продукта” — формулирует концепцию проекта, общается с заказчиком и проясняет его требования, устанавливает основные функциональные характеристики продукта, ведет “бэклог” и помогает определить приоритетность задач. Опыт показал, что совмещать эти две роли одному человеку не под силу.

Как начинать проект

Начните работу над проектом по методике Scrum со следующих шагов.

1. Выберите “владельца продукта”. Он должен хорошо разбираться в сути продукта, знать рынок, быть всегда доступным для команды. “Владелец продукта” формулирует требования на текущий спринт и “несет ответственность за полезность продукта”.
2. Сформируйте команду. В группу должны войти специалисты, сумма навыков которых достаточна для выполнения работы. Команда сама решает, как она будет работать; руководство отвечает лишь за постановку стратегических целей.
3. Выберите “скрам-мастера”. Его задача — проводить все короткие собрания, обеспечивать выполнение всех необходимых процедур и помнить, что сам процесс может стать препятствием к выполнению задач.
4. Создайте “бэклог” продукта. Как можно быстрее продумайте и запишите все функциональные требования. Упорядочьте список по степени важности задач.
5. Оцените и уточните “бэклог”. Объем усилий, которые требуются на выполнение каждой задачи, оценивается не в часах, а относительно. Один из способов такой оценки — присвоить задачам “баллы” на основе последовательности Фибоначчи: 1, 3, 5, 8, 13 и так далее.
6. Спланируйте первый “спринт”. Из верхней части “бэклога” команда выбирает задания для одного “спринта” и решает, какой будет “цель спринта”. Добавлять новые задачи до его завершения нельзя. В конце каждого “спринта” анализируется “динамика производительности”: для этого складываются “баллы” всех выполненных задач. Таким же образом оценивается сложность еще не сделанных работ. Через несколько спринтов уже можно приблизительно рассчитать необходимое для окончания проекта время.
7. Обеспечьте прозрачность. Завершить проект в кратчайшие сроки можно лишь при условии прозрачности процессов. Повесьте на видном месте скрам-доску. Также составьте “диаграмму выгорания задач”. Для этого по одной оси откладывайте число набранных за уже выполненные задачи баллов, а по другой — дни.
8. “Собрания на ходу”. Такие собрания проводятся “скрам-мастером” каждый день в одно и то же время и длятся не более 15 минут. Их цель — обсуждение хода работ.
9. “Обзор спринта”. На этой встрече присутствуют владелец продукта, скрам-мастер, команда и “любые заинтересованные лица — заказчик, представители руководства, потенциальные потребители”. Показывается готовая часть продукта.
10. “Ретроспективные собрания”. После каждой демонстрации заказчику проводится обсуждение, несущее функцию проверки из цикла Деминга “Планировать, действовать, проверять, корректировать” (PDCA). Команда обсуждает, что удалось в завершенном “спринте”, а что можно было сделать лучше, какие улучшения можно внести в работу немедленно. После этого начинается новый “спринт”.