Бэклог... Как много в этом слове для сердца продакта слилось! Как много отозвалось!

У многих продуктовых команд процесс проработки и запуска новых фич довольно типичен: бэклог → продуктовая проработка → дизайн и проектирование (если нужно) → разработка/создание → запуск фичи.

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

«О! Они взяли эту фичу в работу, значит скоро сделают!»

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

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

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

На вебинаре поговорим:

• Что такое точка принятия обязательств и триажирование в разрезе продуктового процесса.
• Как выстраивать продуктовые процессы вокруг этих точек
• Как использовать эти точки для работы со стейкхолдерами и командой.
• Как уйти от «тайных» бэклогов и сделать процесс прозрачным и предсказуемым.

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