Planning Poker — что это, зачем нужен и как правильно проводить оценку задач

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

Главная цель метода — получить максимально объективную и согласованную оценку сложности задачи. В отличие от ситуации, когда один человек единолично определяет сроки выполнения, Planning Poker позволяет учесть мнение всех членов команды. Это помогает выявить скрытые риски, обнаружить неочевидные детали реализации и прийти к общему пониманию того, что именно нужно сделать.

Зачем нужен Planning Poker: основные цели и преимущества.

• Коллективная и честная оценка. Когда в процессе участвует вся группа, результат получается более взвешенным и реалистичным. Разработчики с разным уровнем опыта видят задачу под разными углами: junior-специалист может предвидеть сложности, которые senior посчитает тривиальными просто потому, что давно их не встречал. Одновременно опытный коллега способен указать на подводные камни, о существовании которых менее опытные члены команды даже не подозревают. Коллективное обсуждение позволяет учесть весь спектр возможных трудностей.
• Снижение эффекта якоря. Один из самых коварных когнитивных искажений в командной работе — это эффект якоря, когда первое озвученное мнение непроизвольно влияет на суждения остальных участников. Представьте ситуацию: senior-разработчик первым заявляет, что таск займёт четыре часа. Даже если junior изначально думал иначе, он, скорее всего, подстроится под авторитетное мнение старшего коллеги, опасаясь показаться некомпетентным. Planning Poker элегантно решает эту проблему: все участники выбирают карты одновременно и в закрытую, поэтому никто не знает чужого мнения до момента открытия карт. Это обеспечивает независимость оценок и искренность суждений.
• Устранение недопонимания между заказчиком и исполнителями. Нередко заказчик формулирует таск в общих чертах, полагая, что детали очевидны, а сотрудники интерпретирует требования совершенно иначе. Planning Poker превращает процесс обсуждения в структурированную оценку, где постановщик задачи обязательно присутствует и объясняет, что именно нужно сделать и почему это важно. Команда задаёт уточняющие вопросы, выявляет скрытые требования и предлагает альтернативные пути реализации. В результате все приходят к единому пониманию задачи ещё до начала работы, что существенно снижает риск доработок и переделок.
• Улучшение прозрачности и предсказуемости планирования. Когда сотрудники регулярно используют Planning Poker, накапливается статистика оценок и фактического времени выполнения тасков. Это позволяет рассчитать скорость (velocity) — показатель, который показывает, сколько задач команда реально способна выполнить за спринт. Основываясь на этих данных, можно составлять более точные прогнозы и формировать реалистичные планы, что повышает доверие со стороны заказчика и снижает уровень стресса.

Иллюстрация показывает, как Planning Poker помогает команде перейти от хаотичных и субъективных оценок к согласованному и предсказуемому планированию. Слева — стресс, разрозненные мнения и срывы сроков, справа — общее понимание задачи, точные оценки и уверенность в результате. В центре — коллективная оценка с карточками как ключевой элемент метода.

Подготовка к покер-планированию: правила, требования, единицы измерения

Эффективность Planning Poker напрямую зависит от качества подготовки. Давайте разберёмся, что необходимо сделать до начала сессии, чтобы процесс прошёл максимально продуктивно.

Формулировка задач и сбор входной информации

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

Критически важно обеспечить присутствие постановщика задачи на сессии Planning Poker. Это может быть менеджер продукта, владелец, маркетолог или даже генеральный директор — тот, кто инициировал задачу и понимает её бизнес-контекст. Постановщик объясняет суть таска, рассказывает, как он его понимает, и главное — доносит до сотрудников, почему эта задача важна. Мотивация исполнителей значительно возрастает, когда они понимают ценность своей работы, а не просто получают техническое задание без контекста.

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

Выбор единиц измерения

Один из первых вопросов, который возникает при внедрении Planning Poker: в чём именно измерять сложность? Существует несколько подходов, и выбор зависит от специфики команды и проекта.

• Story Points (очки сложности). Это абстрактная единица измерения, которая оценивает относительную сложность  без привязки к конкретным временным рамкам. Задачи оцениваются относительно друг друга: одна может быть в два раза сложнее другой, получив соответственно вдвое больше очков. Преимущество этого подхода в том, что он не создаёт иллюзии точности — сотрудники оценивают сложность, а не пытаются предсказать, сколько конкретно часов или дней потребуется. Со временем накапливается статистика, которая позволяет понять, сколько story points сотрудники способны выполнить за спринт.
• Рабочие дни или часы. Некоторые сотрудники предпочитают оценивать таски в днях или часах трудозатрат. Этот подход кажется более понятным и прямолинейным, особенно для менеджеров, которые привыкли оперировать временными рамками. Однако здесь есть подводный камень: оценка в днях создаёт ложное ощущение точности и может привести к тому, что команда будет оцениваться по способности угадать точное время выполнения, а не по результатам работы.
• Размеры одежды (T-shirt sizing). Метод, при котором таски оцениваются по аналогии с размерами футболок: XS (очень простая), S (простая), M (средняя), L (сложная), XL (очень сложная). Этот подход особенно удобен на ранних стадиях проекта, когда информации ещё мало, а детальное обсуждение невозможно. T-shirt sizing помогает быстро отсортировать задачи по уровню сложности и расставить приоритеты, а уже потом, при необходимости, можно провести более детальную оценку в story points или днях.

Договорённости перед началом

До первой сессии Planning Poker сотрудникам необходимо договориться о базовых правилах игры. Прежде всего, нужно выбрать шкалу значений для карт. Чаще всего используется последовательность Фибоначчи: 0, 1, 2, 3, 5, 8, 13, 20, и так далее. Логика здесь в том, что чем сложнее задача, тем труднее оценить её точно — поэтому разница между соседними числами увеличивается. Некоторые команды дополнительно включают в колоду карты со специальными символами: вопросительный знак (не уверен в ответе), ½ (очень простой таск), бесконечность ( слишком большой и требует декомпозиции), чашка кофе (нужен перерыв).

Инструменты для Planning Poker: физические и онлайн

Для проведения Planning Poker необязательно изобретать велосипед — существует множество готовых инструментов, как физических, так и цифровых, которые упрощают процесс и делают его более удобным для команд любого формата.

• Физические карточные колоды. Классический вариант — специальные наборы карт для Planning Poker, которые можно приобрести или изготовить самостоятельно. Такие колоды обычно содержат карты с числами Фибоначчи (0, 1, 2, 3, 5, 8, 13, 20, и так далее), а также дополнительные карты со специальными символами: вопросительный знак (не уверен в оценке), символ бесконечности (задача слишком большая), половина (очень простая задача), чашка кофе (нужен перерыв). Физические карты хорошо работают для команд, которые собираются в одном офисе — есть что-то в тактильном ощущении карт, что делает процесс более вовлекающим и похожим на настоящую игру.
• Мобильные приложения. Для команд, которые работают частично удалённо или хотят сократить использование бумажных материалов, существуют мобильные приложения для iOS и Android. Они позволяют каждому участнику использовать свой смартфон как колоду карт. Некоторые приложения синхронизируются между устройствами, позволяя участникам видеть результаты голосования на общем экране в режиме реального времени.
• Онлайн-сервисы для удалённых команд. С ростом распределённых команд особую популярность приобрели специализированные веб-платформы для проведения Planning Poker онлайн.

Рассмотрим основные варианты:

Planningpoker.com — один из самых известных сервисов, который включает в себя не только инструмент для оценки, но и обширный блог с материалами о методике. Можно использовать с компьютера или смартфона. Бесплатная базовая версия подходит для команд до пяти человек, платные тарифы позволяют интегрироваться с Jira и добавлять неограниченное количество участников.

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

Интерфейс сервиса с картами и игрокам. Источник: официальный сайт

Planningpoker.ru — русскоязычная платформа, где можно заказать физическую колоду карт с доставкой. Онлайн-версия продукта на момент написания статьи доступна только пользователям одной из социальных сетей, что ограничивает её применимость для международных команд.

Пошаговая инструкция: как проводится Planning Poker

Теперь, когда мы разобрались с подготовкой, перейдём к самому процессу проведения Planning Poker. Рассмотрим каждый шаг детально, чтобы понять механику метода и логику, которая за ним стоит.

Шаг 1. Выбор задачи и раздача карт

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

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

Шаг 2. Независимая скрытая оценка

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

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

Здесь действует железное правило: никакого обсуждения до выбора карт. Каждый участник независимо, не глядя на других и не советуясь, выбирает карту, которая, по его мнению, соответствует сложности задачи. Это принципиальный момент — если кто-то выскажет своё мнение до того, как остальные выберут карты, он неизбежно повлияет на оценки коллег. Особенно сильно этот эффект проявляется, когда первым высказывается senior-разработчик или другой авторитетный член команды: остальные могут усомниться в своих суждениях и подстроиться под мнение лидера, даже если изначально думали иначе.

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

Шаг 3. Открытие карт и сравнение результатов

Когда все карты лежат на столе, участники одновременно переворачивают их, открывая свои оценки. Теперь можно анализировать результаты. Если все карты близки по значению — например, четыре участника выбрали «5», а один «8» — это означает, что сотрудники примерно одинаково понимают таск и согласны с его сложностью. В таком случае можно принять среднее арифметическое или медианное значение и двигаться дальше.

Диаграмма наглядно показывает различия в оценках одной и той же задачи у разных участников. Такой разброс указывает на разное понимание объёма и рисков. Именно эти расхождения становятся отправной точкой для обсуждения.

Однако часто случается, что баллы сильно расходятся. Например, один разработчик оценил таск в два рабочих часа (выбрал карту «2»), а другой — в четыре дня (карта «20»). Это сигнал о том, что участники по-разному понимают задачу или планируют решать её разными способами. Именно такие расхождения особенно ценны — они выявляют пробелы в понимании и помогают сотрудникам синхронизироваться до начала работы.

Шаг 4. Обсуждение минимальных и максимальных оценок

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

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

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

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

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

Шаг 5. Повторная оценка

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

Обычно во второй попытке баллы становятся более согласованными. Если разброс всё ещё велик, процесс повторяется: снова обсуждаются крайние позиции, снова проводится голосование. Цель — достичь консенсуса, когда большинство участников выбирает одинаковые или близкие по значению карты.

Важно понимать, что консенсус не означает полного единогласия. Если пять участников выбрали карту «5», а один — «8», это приемлемый результат. Можно зафиксировать оценку как «5» или «8» в зависимости от того, насколько убедительны аргументы того, кто предвидит дополнительные сложности. В случае сомнений разумнее выбрать большую — лучше заложить запас времени и закончить раньше, чем недооценить и сорвать сроки.

Шаг 6. Запись итоговой оценки и добавление в бэклог

Когда сотрудники пришли к согласованной оценке, результат фиксируется в карточке задачи в таск-менеджере — будь то Jira, Trello, Asana или любой другой инструмент, который использует команда. Важно записать не только финальную оценку, но и ключевые договорённости, которые возникли в процессе обсуждения: какой подход к реализации выбран, какие риски учтены, какие зависимости от других тасков или команд существуют.

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

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

Как использовать результаты покер-планирования в работе

Проведение Planning Poker — это лишь первый шаг. Настоящая ценность метода раскрывается тогда, когда сотрудники начинают системно использовать накопленные данные для улучшения планирования и прогнозирования. Давайте разберёмся, как превратить результаты оценок в практические инструменты управления проектом.

• Расчёт скорости (velocity). Когда команда завершает несколько спринтов, появляется возможность подсчитать её velocity — суммарное количество story points (или других единиц измерения), которое сотрудники реально выполняют за один спринт. Например, если за последние три они выполнили таски на 35, 38 и 36 story points соответственно, средняя скорость составляет примерно 36 points за спринт. Эта метрика становится базой для планирования будущих итераций.
• Определение объёма задач для спринта. Зная скорость, можно принимать обоснованные решения о том, сколько тасков брать в следующий спринт. Если средняя velocity составляет 36 points, нет смысла планировать 50 — сотрудники просто не справятся, что приведёт к стрессу, переработкам и снижению качества. И наоборот, если запланировать только 20 points, команда будет недогружена, что тоже неэффективно. Опираясь на исторические данные, можно формировать реалистичные планы, которые сотрудники способны выполнить без героических усилий.
• Формирование прогнозов для заказчика. Результаты Planning Poker позволяют давать заказчику реалистичные прогнозы по срокам. Если в бэклоге осталось задач на 180 story points, а команда выполняет в среднем 36 points за спринт, можно с высокой степенью уверенности сказать, что для завершения работы потребуется ещё пять спринтов. Конечно, это приблизительная оценка — в процессе могут появиться новые таски или измениться приоритеты, но она даёт заказчику понимание масштабов и помогает планировать запуск продукта или выход на рынок.
• Обновление и актуализация бэклога. По мере накопления опыта сотрудники начинают лучше понимать, какие типы они недооценивает, а какие переоценивает. Например, может выясниться, что задачи, связанные с интеграцией внешних API, систематически занимают на 30-40% больше времени, чем планировалось. Это сигнал к тому, что нужно пересмотреть подход к обсуждению подобных задач и закладывать больший запас времени. Регулярный анализ расхождений между оценками и фактом помогает команде постепенно повышать точность планирования.

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

Майнд-карта показывает Planning Poker как инструмент перехода от хаотичных оценок к предсказуемому планированию. Слева — проблемы и скрытые риски без коллективной оценки, справа — процесс и бизнес-результат метода. Такая схема помогает понять, зачем вообще проводить Planning Poker, а не просто как он устроен.

Когда именно стоит использовать Planning Poker

Понимание того, в каких конкретных ситуациях Planning Poker даёт максимальную отдачу, помогает сотрудникам применять метод точечно и эффективно, не превращая его в формальную процедуру ради процедуры.

• Старт нового проекта. Когда сотрудники приступают к работе над новым продуктом, Planning Poker помогает оценить весь объём предстоящей работы, составить реалистичный план и расставить приоритеты. На этом этапе особенно важно, чтобы все участники одинаково понимали масштаб проекта и могли спланировать ресурсы. Коллективное обсуждение на старте позволяет избежать ситуации, когда через месяц выясняется, что команда взяла на себя обязательства, которые физически невозможно выполнить в заявленные сроки.
• Начало каждого спринта. Регулярное проведение Planning Poker перед началом очередного спринта стало стандартной практикой в Scrum-командах. Это позволяет сотрудникам пересмотреть приоритеты в бэклоге с учётом результатов предыдущего спринта, оценить новые таски и определить, какой объём работы реалистично взять в текущую итерацию. Систематическое использование метода помогает поддерживать устойчивый ритм работы и избегать перегрузок.
• Появление новых задач в процессе работы. Проекты редко развиваются строго по плану — появляются новые требования, меняются приоритеты, возникают технические ограничения, о которых никто не знал на старте. Когда в бэклог добавляется новый таск, проведение быстрой сессии Planning Poker помогает сотрудникам понять, насколько он трудоёмок и как впишется в текущие планы. Это позволяет принимать обоснованные решения о том, стоит ли браться за него немедленно или лучше отложить на следующий спринт.
• Пересмотр бэклога и актуализация оценок. Если задача провисела в очереди на выполнение больше недели, имеет смысл вынести её на повторное обсуждение. За это время сотрудники могли получить новую информацию, изменилась архитектура системы, появились или исчезли зависимости — всё это влияет на сложность реализации. Повторная оценка помогает избежать ситуации, когда разработчик берётся за таск и обнаруживает, что он требует совершенно иного подхода, чем планировалось изначально.
• Систематическое несоответствие оценок и реальности. Если сотрудники регулярно не укладываются в свои баллы — например, таски, оценённые в один день, фактически занимают два-три, — это сигнал к тому, что нужно провести ретроспективную сессию Planning Poker. Возможно, команда недооценивает определённый тип задач, не учитывает какие-то регулярные накладные расходы или просто излишне оптимистична. Анализ расхождений и корректировка подхода к обсуждению помогают постепенно повысить точность планирования.
• Работа в любом формате. Planning Poker одинаково хорошо работает независимо от того, собирается ли вся команда в одной переговорной комнате, работает полностью удалённо или использует гибридный формат. Для распределённых команд существуют специализированные онлайн-платформы, которые полностью воспроизводят механику физических карт и позволяют проводить сессии с тем же уровнем вовлечённости и эффективности.

Ключевой принцип здесь — использовать Planning Poker не по расписанию, а по необходимости, когда сотрудникам действительно нужно прийти к общему пониманию сложности.

Типичные ошибки в Planning Poker (и как их избежать)

Даже сотрудники с опытом проведения Planning Poker иногда попадают в ловушки, которые снижают эффективность метода или вовсе превращают его в пустую формальность. Давайте разберём наиболее распространённые ошибки и способы их предотвращения.

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

Решение: сделайте присутствие постановщика обязательным условием проведения Planning Poker. Если заказчик не может участвовать, перенесите сессию или отложите оценку этой задачи.

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

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

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

Решение: создайте на сессиях атмосферу психологической безопасности, где каждый может высказать своё мнение без страха критики. Менеджер должен подчёркивать, что его цель — получить честную оценку, а не услышать желаемые цифры.

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

Решение: если задача оценивается более чем в пять дней (или 13 story points), остановитесь и разбейте её на несколько более мелких подзадач и обсуждайте по отдельности.

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

Решение: если разброс оценок велик (например, от 2 до 13), обязательно выслушайте аргументы участников с крайними позициями и проведите повторное голосование. Повторяйте процесс до тех пор, пока они не сойдутся или пока не станет ясно, какой информации не хватает для принятия решения.

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

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

Осознание этих типичных ошибок и активная работа по их предотвращению помогает сотрудникам получать максимальную пользу от Planning Poker и избегать превращения метода в бюрократическую процедуру.

Пример сценария покер-планирования на реальной задаче

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

Контекст:

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

Шаг 1: Презентация задачи. Владелец продукта описывает функциональность: «Нам нужна кнопка «Добавить в избранное» на карточке товара. Когда пользователь нажимает на неё, товар сохраняется в его личном списке желаний. Пользователь может зайти в этот список через меню и увидеть все сохранённые товары. Это важно, потому что по аналитике 40% пользователей возвращаются к товару несколько раз перед покупкой, но сейчас им приходится искать его заново».

Шаг 2: Вопросы команды. Frontend-разработчик спрашивает: «Список желаний должен сохраняться только для авторизованных пользователей или для всех, включая гостей?» Владелец продукта уточняет: «Для начала только для авторизованных. Для гостей сделаем в следующей итерации».

Backend-разработчик интересуется: «Нужна ли синхронизация списка между устройствами?» Ответ: «Да, если пользователь добавил товар в избранное с телефона, он должен увидеть его и на компьютере».

UX-дизайнер задаёт вопрос: «У нас уже есть готовые макеты или их нужно создавать?» Владелец продукта: «Макеты готовы, они в Figma, ссылку скину после встречи».

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

Результаты первого раунда:

• Senior frontend-разработчик: 3.
• Junior frontend-разработчик: 8.
• Backend-разработчик: 5.
• QA-инженер: 13.
• UX-дизайнер: 2.

Шаг 4: Обсуждение расхождений. Ведущий просит участников с крайними оценками объяснить свой выбор.

UX-дизайнер (оценка 2): «Макеты уже готовы, мне нужно только проверить их финальную версию и убедиться, что всё соответствует гайдлайнам. Это займёт пару часов максимум».

QA-инженер (оценка 13): «Я учитываю, что нужно будет протестировать синхронизацию между устройствами, проверить поведение при нестабильном интернете, убедиться, что список корректно отображается при большом количестве товаров. Плюс нужно проверить, что происходит, если товар удалили из каталога, а он остался в чьём-то избранном. Ещё нужно написать автотесты для всех этих сценариев».

После этого высказываются участники со средними оценками. Backend-разработчик объясняет: «Мне нужно создать новую таблицу в базе данных, написать API для добавления и удаления товаров из избранного, реализовать получение списка. Плюс нужно подумать о производительности — если у пользователя тысяча товаров в избранном, запрос не должен тормозить».

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

Шаг 5: Дополнительные вопросы. В процессе обсуждения выясняются новые детали. Backend-разработчик спрашивает: «А нужна ли нам аналитика — отслеживание, какие товары чаще всего добавляют в избранное?» Владелец продукта: «Да, хорошая мысль, давайте добавим базовую аналитику».

Шаг 6: Повторная оценка. Команда проводит второй раунд голосования с учётом всей обсуждённой информации.

Результаты второго раунда:

• Senior frontend: 5.
• Junior frontend: 8.
• Backend: 8.
• QA: 8.
• UX-дизайнер: 3.

Шаг 7: Финальное решение. Оценки стали гораздо ближе. Команда решает зафиксировать в 8 story points, учитывая мнение большинства и принимая во внимание, что у junior-разработчика может потребоваться больше времени на разбор кодовой базы. Также договариваются, что senior будет доступен для консультаций и при необходимости они могут применить парное программирование.

Вся сессия заняла около семи минут, но за это время сотрудники не только оценили задачу, но и выявили важные детали (аналитика, обработка удалённых товаров), согласовала подход к реализации и распределила зоны ответственности. Именно в этом и состоит главная ценность Planning Poker — не столько в цифре на выходе, сколько в процессе синхронизации команды.

Заключение

Planning Poker за почти два десятилетия своего существования доказал свою эффективность в самых разных командах и проектах — от небольших стартапов до крупных корпоративных разработок. Метод работает не потому, что даёт магически точные оценки (их не существует в принципе), а потому что решает более фундаментальную проблему: он синхронизирует понимание задач внутри команды и превращает процесс планирования из односторонней директивы в коллективное обсуждение. Подведем итоги:

• Planning Poker — это метод коллективной оценки задач. Он помогает команде прийти к общему пониманию сложности и объёма работы.
• Покер планирование снижает влияние субъективных мнений. Закрытое голосование уменьшает эффект якоря и давление авторитетов.
• Метод выявляет скрытые риски ещё до начала работы. Обсуждение расхождений позволяет заранее учесть сложности и зависимости.
• Регулярное использование Planning Poker повышает точность планирования. Команда накапливает статистику и лучше прогнозирует сроки.
• Ценность метода — не в цифрах, а в синхронизации команды. Planning Poker делает планирование прозрачным и предсказуемым.

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