Покер-планирование задач

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

Одной из форм оптимизации планирования является покер-планирование.

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

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

Автором методики является Джеймс Греннинг, впервые представивший ее для обсуждения в 2002 году. Через три года данный подход описал в одной из своих работ, посвященных Agile, Майк Кон. Многие исследователи для данного вида планирования используют название Scrum-покер, так как он получил широкое распространение для Scrum-команд. Используют методики при реализации проектов, связанных с ведением экстремального программирования.

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

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

Связь с покером в данном случае объясняется стремлением превратить планирование в игровой процесс, причем заключается он не в азартной составляющей, а в наличии стандартных карт, каждая из которых предусматривает определенное время для решения конкретного типа задач. Среди специалистов в IT-сфере получили распространение карточки с последовательностью Фибоначчи. Причем вариантов заполнения может быть два:

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

С описанием более-менее понятно, теперь необходимо посмотреть, как данный подход реализуется на практике.

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

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

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

Выбор конкретной задачи для обсуждения ложится на руководителя проекта. В целом каких-либо существенных отличий от процессов планирования спринта нет.

Далее перед началом обсуждения для задачи дается:

После этого каждый из членов команды может задавать уточняющие вопросы, делиться своим мнением с другими участниками. Завершается же все голосованием с использованием предоставленных в начале карт.

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

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

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

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

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

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

Можно найти достаточно много положительных отзывов со стороны IT-специалистов, но данный подход может стать и причиной отрицательного результата, если команда проекта не готова к подобному формату работы. Если деловая среда в коллективе более классическая, то планирование спринтов лучше проводить более привычными методами.

Помочь с планированием задач, контролем установленных сроков позволяет платформа Projecto. Здесь для членов команды представлен внушительный набор инструментов для ведения проектов, обсуждений, информирования участников, контроля планов и так далее.