Оценка задач по методу Planning Poker

Представьте себе команду разработчиков, дизайнеров и менеджеров, собравшихся вокруг стола. На экране — список задач на следующий спринт. В руках у каждого — колода карт с числами: 1, 2, 3, 5, 8, 13… Но это не игра в покер за картами. Это — Planning Poker, метод, который превращает оценку сложности задач в увлекательную, прозрачную и глубоко эффективную процедуру. В мире управления проектами, где ошибки в планировании приводят к просрочкам, перегрузке и разочарованию, Planning Poker стал одним из немногих инструментов, способных не только оценить усилия, но и сблизить команду. Он работает не потому, что «это модно», а потому, что учит слушать, обсуждать и принимать решения вместе.

Что такое Planning Poker: от карточной игры к методу управления

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

Техника была предложена Джеймсом Гренингом в 2002 году как улучшенная версия метода Wideband Delphi, разработанного корпорацией RAND в середине XX века. Популярность Planning Poker вышла на новый уровень после публикации книги Майка Кон «Agile Estimating and Planning» в 2005 году. С тех пор он стал неотъемлемой частью Scrum-практик, особенно в командах разработки ПО. Но его применение не ограничивается IT — Planning Poker эффективен в любых проектах, где требуется коллективная оценка сложности: от маркетинговых кампаний до разработки новых продуктов в производстве.

Суть метода проста: вместо того чтобы спрашивать «Сколько времени займёт эта задача?», команда задаёт вопрос: «Насколько сложна эта задача в сравнении с другими?». Ответ не выражается в часах или днях, а передаётся через относительные значения — баллы. Эти баллы могут обозначать не время, а усилия: количество человеко-часов, риски, зависимости, необходимость координации. Это ключевое отличие от традиционного подхода: Planning Poker оценивает усилия, а не время.

Почему именно карты? Почему не Excel или голосование?

Использование карточек — не просто стилистический выбор. Это психологический трюк, направленный на устранение влияния авторитета и группового давления. Когда человек говорит вслух: «Я думаю, это займёт 5 дней», он подвергает свою оценку критике до того, как услышит мнение других. В результате он либо укрепляет свою позицию, либо подстраивается под мнение большинства — даже если оно ошибочно. В карточной системе все участники одновременно показывают свою оценку, скрывая её до момента вскрытия. Это гарантирует независимость суждений.

Также карточки упрощают процесс. Не нужно вводить данные в таблицу, не нужно ждать ответа от коллег. Все видят цифры мгновенно — и сразу начинается диалог. Карта с цифрой 13 или «?» — это не просто число, это сигнал: «Здесь есть что-то непонятное». Это визуальный триггер для обсуждения, который работает лучше, чем 10-минутный монолог.

Сравните: в традиционном совещании один эксперт говорит: «Это легко, два дня». Все молчат — боятся выглядеть глупо. В Planning Poker кто-то кладёт «8», кто-то — «2». Разница в четыре раза. И это вызывает вопрос: «Почему?» — а не молчание. Именно этот момент и превращает оценку в инструмент обучения, а не просто формальность.

Как проходит процесс Planning Poker: пошаговое руководство

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

Шаг 1. Подготовка: колода и участники

Перед началом сессии важно правильно подобрать колоду. Идеальная колода — не набор всех чисел от 1 до 100, а выборка с разрывами. Наиболее распространённая версия — числа Фибоначчи: 0, 1, 2, 3, 5, 8, 13, 20, 40, 100. Почему именно они?

• Разрывы между числами — с каждым шагом разница увеличивается. Между 5 и 8 — 60% роста, между 20 и 40 — 100%. Это заставляет команду думать: «Это в два раза сложнее?» — а не увязать в спорах про 7 или 9.
• Наличие аномальных значений: «?» (неуверенность), «∞» (невозможно реализовать) и «кофе» (перерыв). Эти карты — не шутка, а инструмент. Когда кто-то кладёт «?», это означает: «Я не понимаю задачу». Когда кто-то кладёт «∞» — это сигнал, что нужно разбить задачу или отложить её. А «кофе» — человечный способ сказать: «Я устал, давайте сделаем паузу».

Участники сессии — это не просто разработчики. Это все, кто вносит вклад: Scrum-мастер (модератор), владелец продукта, разработчики, тестировщики, UX-дизайнеры. Каждый из них видит задачу под своим углом. Разработчик думает о технической сложности, дизайнер — о деталях интерфейса, тестировщик — о возможных багах. И именно их объединённый взгляд даёт реалистичную оценку.

Шаг 2. Ознакомление с задачей

Владелец продукта (Product Owner) кратко представляет задачу. Он не должен давать оценку, только объяснить: «Что нужно сделать?», «Кому это поможет?», «Как мы поймём, что задача выполнена?»

Это критически важно. Если владелец продукта говорит: «Это же просто — сделаем за день», это подавляет инициативу. Если он говорит: «У нас была похожая задача в прошлом спринте — она заняла 8 баллов, но тогда мы не учли интеграцию с API», — это открывает пространство для дискуссии. Цель — не убедить команду в правильности своей оценки, а дать контекст.

Шаг 3. Обсуждение: выявление скрытых рисков

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

• Какие компоненты системы затронуты?
• Есть ли зависимости от других команд?
• Какие тесты нужно написать?
• Что будет, если внезапно сменится поставщик API?
• Кто будет участвовать? Сколько времени потребуется на обучение?

В этом этапе раскрываются скрытые риски. Например, разработчик может сказать: «Я думал, это просто кнопка. А теперь понял — нужно менять архитектуру, потому что текущий модуль не поддерживает кэширование». Без такого обсуждения задача оценивалась бы как «2», а на деле заняла бы 3 дня. Это и есть ценность Planning Poker: он превращает планирование в сессию выявления рисков, а не формальность.

Шаг 4. Голосование: карты рубашкой вверх

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

Важно: каждый участник кладёт одну карту. Нет «я бы поставил 3, но может, 5» — только одна оценка. Это заставляет человека сделать выбор, а не колебаться. В этот момент важно сохранить молчание — никаких комментариев, жестов, взглядов. Только карты.

Шаг 5. Открытие и консенсус

Карты открываются одновременно. Теперь команда видит распределение оценок.

• Близкие значения (например, 5, 8, 5) — оценка принята. Консенсус достигнут.
• Значительные расхождения (например, 2 и 13) — начинается обсуждение. Участники с экстремальными оценками объясняют: «Я поставил 2, потому что это повторение» или «Я поставил 13 — там три интеграции, и у нас нет документации».

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

Шаг 6. Запись и последующие действия

Оценка фиксируется. В онлайн-сервисах (planningpoker.com, planningpoker.ru) это происходит автоматически. Вручную — в таск-менеджере: WEEEK, Jira, Trello. Важно не просто записать число — а зафиксировать обоснование. Например: «Оценка 8 — из-за необходимости интеграции с CRM, где нет API». Это критически важно для будущих спринтов: если задача будет повторяться, команда сможет оперативно оценить её, опираясь на прошлый опыт.

Scrum-мастер фиксирует, что было сложным: «Слишком много неясностей в требованиях», «Не хватило тестировщика». Эти инсайты становятся основой для улучшения процессов. Planning Poker — не разовая процедура, а обратная связь, которая делает команду умнее с каждым спринтом.

Преимущества и недостатки: реальные плюсы и подводные камни

Planning Poker — не волшебная палочка. Он работает, но только если применять его осознанно. Разберём плюсы и минусы — без прикрас.

Преимущества: почему это работает

1. Командный дух и вовлечённость. Участник, который раньше молчал на совещаниях, теперь может сказать: «Я поставил 13». И его мнение услышали. Это повышает моральный дух и снижает уровень выгорания.

2. Выявление скрытых рисков. Когда разработчик говорит: «Я не могу оценить, потому что нет документации», — это ценный сигнал. Без Planning Poker он бы молчал, а задача провалилась бы на этапе реализации.

3. Устранение авторитетного влияния. Тимлид или владелец продукта не могут «наказать» команду своей оценкой. Все голосуют одновременно — и мнение бывалого разработчика не перевешивает мнение джуна.

4. Обучение через диалог. Команда учится оценивать сложность, понимать архитектуру, видеть зависимости. Это не просто «оценка» — это обучение.

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

Недостатки: где Planning Poker проваливается

1. Субъективность. Оценка — это всегда субъективная оценка. Два разработчика могут по-разному понимать «сложность». Один думает: «Это просто — я делал это вчера». Другой: «Но там три неизвестных библиотеки — я боюсь». Это нормально. Главное — обсудить, а не игнорировать.

2. Ложный консенсус. Иногда команда сходится на оценке, не потому что она верна, а потому что никто не хочет спорить. Это опасно. Нужно создавать культуру, где «я не согласен» — это нормально.

3. Групповая оптимистичность. Люди в группе склонны переоценивать возможности. «Мы справимся!» — это мантра, которая разрушает планирование. Planning Poker не устраняет этот эффект полностью — он лишь делает его видимым.

4. Доминирование авторитетов. Если владелец продукта говорит: «Это критично — нужно в этом спринте», команда может снизить оценку, чтобы угодить. Это разрушает метод. Решение — владелец продукта не даёт оценку до обсуждения.

5. Перегрузка и усталость. Если сессия длится больше 90 минут, люди перестают думать. Обсуждение становится формальным. Решение — лимит времени: 15 минут на задачу, максимум 6–8 задач за сессию.

Частые ошибки и как их избежать

Даже опытные команды допускают одни и те же ошибки. Вот пять самых опасных — с практическими советами по их предотвращению.

Ошибка 1: Оценка времени, а не усилий

Проблема: Команда думает: «Сколько часов мы потратим?» — и начинает считать рабочие часы, перерывы, встречи. Это приводит к недооценке.

Решение: Постоянно напоминайте: «Оцениваем усилия — сколько работы нужно сделать, а не сколько времени пройдёт». Пусть каждый вспомнит: «Если я буду работать 8 часов в день, сколько задач я смогу сделать?». Это приведёт к более реалистичным оценкам.

Ошибка 2: Влияние авторитета

Проблема: Тимлид говорит: «Я думаю, 3». Все подстраиваются. Команда теряет независимость.

Решение: Владелец продукта и тимлид должны молчать до того, как все проголосовали. Их мнение — позже. Можно даже попросить их голосовать первыми, чтобы «засорить» оценки — но это рискованно. Лучше: они не голосуют до обсуждения.

Ошибка 3: Слишком много карточек

Проблема: Колода с числами от 1 до 50. Команда спорит: «8 или 9?» — и тратят час на одну задачу.

Решение: Используйте только 10–12 карточек. Лучше всего: 0, 1, 2, 3, 5, 8, 13, 20, 40, 100. И «?», «∞». Больше — не нужно.

Ошибка 4: Нет нужных людей

Проблема: Оценивают только разработчики. Тестировщики и дизайнеры не участвуют — а потом обнаруживают, что задача требует 2 дня на тестирование.

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

Ошибка 5: Игнорирование результатов

Проблема: Оценки записаны, но не используются. Спринт планируется по «похоже на прошлый раз», а не по оценкам.

Решение: Каждый спринт начинайте с анализа прошлых оценок. «Мы поставили 8, а сделали за 15 дней — почему?». Это превращает Planning Poker из процедуры в инструмент улучшения.

Альтернативы Planning Poker: когда он не подходит

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

1. Async Poker (асинхронный покер)

Когда использовать: Удалённые команды, разница во временных зонах, большие группы.

Как работает: Модератор отправляет задачи в Slack, Notion или Jira. Участники оценивают в течение 2–3 дней. Затем модератор анализирует расхождения и проводит короткую сессию обсуждения. Все остальные оценки фиксируются.

Плюсы: Участники могут подумать, не спешить. Не надо собирать всех в одно время.

Минусы: Меньше живого диалога. Нет эффекта «командного взрыва» идей.

2. RICE-модель

Формула: (Reach × Impact × Confidence) / Effort

Когда применять: Когда нужно сравнить 20+ задач и выбрать самые перспективные. Особенно полезно для продуктовых команд без Scrum.

Плюсы: Объективно, быстро, масштабируемо.

Минусы: Не учитывает техническую сложность. Слишком абстрактно для разработчиков.

3. Метод Дельфи (Delphi)

Когда использовать: Крупные компании, сложные проекты (например, госзаказы, научные исследования).

Как работает: Анонимная оценка экспертами. После первого раунда — обратная связь, второй раунд — пересмотр оценок. Процесс повторяется 3–5 раз до достижения консенсуса.

Пример: Япония использует метод Дельфи для прогнозирования научного прогресса раз в 5 лет. Германия — для государственных проектов.

Плюсы: Устраняет влияние авторитетов, глубокий анализ.

Минусы: Требует 2–4 недели. Слишком медленно для спринтов.

4. Техника «T-Shirt Sizing»

Когда использовать: На этапе «планирование продукта», когда задачи ещё слишком неясны.

Как работает: Задачи сортируются по размерам: S, M, L, XL. «Это M — мы делали подобное». «Эта задача XL — нужна новая архитектура».

Плюсы: Быстро, визуально. Подходит для первичной оценки.

Минусы: Нет точности. Не подходит для планирования спринта.

Рекомендации от практиков: как внедрить Planning Poker без боли

Внедрение Planning Poker — это не просто запуск сессии. Это изменение культуры. Вот практические рекомендации, основанные на реальных кейсах.

1. Начните с одной задачи

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

2. Объясните «зачем»

Не говорите: «Сегодня делаем Planning Poker». Говорите: «Мы хотим понять, почему задачи всё время срываются. Эта техника поможет нам увидеть скрытые риски и не перегружать команду».

3. Используйте цифры, а не часы

Скажите: «Не думайте о времени. Думайте: “Это в 2 раза сложнее, чем задача с оценкой 5?”». Постоянно напоминайте: «Оцениваем усилия».

4. Записывайте причины

После каждой оценки фиксируйте: «Почему 8?». Это станет базой знаний. Через месяц вы увидите: «Мы постоянно переоцениваем интеграции с CRM». И начнёте работать над этим.

5. Позвольте «?» и «∞»

Не наказывайте за «?». Это не провал — это сигнал. Пусть кто-то скажет: «Я не знаю, как это сделать». Это — шаг к ясности.

6. Не забывайте про отдых

Сессия не должна длиться больше 90 минут. Сделайте перерыв на кофе — и пусть «кофе» станет картой. Это снимет напряжение.

7. Анализируйте результаты

Каждый спринт сравнивайте: «План vs Факт». Если оценка 8, а сделали за 15 дней — найдите причину. Возможно, у нас нет тестовой среды? Или мы не знаем API? Это — источник улучшений.

Заключение: Planning Poker как инструмент культуры, а не процесса

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

Когда команда начинает использовать Planning Poker, она перестаёт бояться сложных задач. Она учится говорить: «Я не знаю», «Это сложно» и «Давайте разберёмся». Это — основа здоровой команды. А когда команда становится здоровой, проекты начинают справляться — даже если план не идеален.

Используйте Planning Poker не потому, что «это в Scrum». Используйте его, потому что он делает вашу команду сильнее. Пишите оценки на карточках, не отменяйте «?», слушайте джунов и уважайте время. Потому что в конечном счёте, не цифры на картах решают успех, а то, как вы слышите друг друга.

Ваша следующая задача — не оценить её. А начать диалог.