Управление ожиданиями и планирование в продуктовой разработке

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

Сегодня мы рассмотрим основные аспекты управления ожиданиями бизнес-заказчиков и планирования в продуктовой разработке после создания минимального жизнеспособного продукта (MVP).

Что делать после MVP?

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

• Бизнес-заказчики — люди или компании, которые изначально были заинтересованы в продукте и ожидали его появления на рынке. Они являются основными инвесторами и заказчиками продукта, и их ожидания необходимо учитывать в первую очередь. Бизнес-заказчики могут быть как внутренними (сотрудники компании), так и внешними (клиенты, партнеры, инвесторы).
• Пользователи — люди, которые впервые сталкиваются с продуктом и принимают решение о его использовании. Их ожидания и потребности связаны с эффективностью продукта и удобства его использования.

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

Что важно бизнесу?

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

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

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

Как управлять ожиданиями?

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

Процесс управления ожиданиями

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

Анализ бизнес-потребностей

• Фиксация целей, потребностей и предоставление обратной связи.
• «Нет» — это тоже ответ.

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

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

Почему важно уметь отказывать:

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

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

Декомпозиция и приоритезация

• Перечень функциональностей, интерфейсов и интеграций.
• Определение приоритетов и скоринг бизнес-целей.

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

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

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

Приоритетность можно расставлять по методике ICE Score — это метод оценки приоритетности задач, основанный на трех критериях: Impact (Влияние), Confidence (Уверенность) и Ease of estimation (Легкость оценки). Этот метод позволяет команде разработки определить, какие задачи имеют наибольшее влияние на проект, насколько они уверены в оценке их сложности и насколько легко можно оценить их трудоемкость.

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

Планирование — ключевой элемент управления ожиданиями

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

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

Как повысить прогнозируемость релиза?

В данном блоке хочется поговорить о понятии «Сделано». Что для бизнеса означает «Сделано» (Definition of Done)? Ответ прост: это то состояние функциональности, когда ее могут использовать пользователи.

Существует разработка, тестирование и сборка релиза. Затем идет подготовка релизных заметок (release notes) и передача проверенного функционала бизнесу. Здесь каждый участник процесса может иметь свое понимание этого состояния, поэтому в идеале всем иметь одинаковое понимание состояния «Сделано», а именно — то состояние функциональности, она доступна на Production-окружении. Следовательно, при планировании следует также учитывать время на сборку, тестирование, развертывание и формирование релиза. Это позволит и команде, и бизнес-заказчикам быть в одном контексте и убедиться, что продукт будет полностью готов к использованию в обещанные сроки.

Наглядная коммуникация

• Регулярность — для синхронизации, контекста и фокуса.
• Фокус на функциональностях с бизнес-заказчиком и командой разработки.
• Наглядный контроль выполнения.
• Оформление release notes (документ, который содержит информацию о новом выпуске продукта, изменениях, улучшениях и исправлениях ошибок. Он помогает понять, что нового появилось в данной версии продукта и какие проблемы были решены).

Особый интерес здесь вызывает пункт с фокусом на функциональностях —  еще одна причина, почему так необходимо прийти к единому пониманию DoD. При взаимодействии с бизнесом и командой разработки product/project manager должен держаться акцента не на реализации той или иной задачи при разработке функциональности, а именно на готовности самой функциональности. Обусловлено это тем, что интерес бизнес-заказчика лежит как раз в появлении новой функциональности, а не в том, как она разрабатывалась. Команда разработки во время спринта может терять этот фокус и концентрироваться именно на одной задаче.

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

Оценка результатов

• Количественные метрики
• Качественные метрики

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

Оба типа показателей важны для принятия решений о развитии продукта и оценке результатов работы команды.

Риски отсутствия управления ожиданиями

• Увеличение времени и затрат на разработку
• Выгоревшая команда
• Потеря доверия
• Нарушение сроков

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