Как создать документ с требованиями к продукту (PRD)

Основные моменты

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

• Требования к продукту в Agile отражают общее понимание и потребности клиентов и могут меняться. Слишком подробные спецификации не используются.

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

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

Создание успешного продукта начинается с формирования четкой концепции и согласования действий. И здесь не обойтись без требований к продукту (PRD).

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

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

Что такое документ с требованиями к продукту (PRD)?

В требованиях к продукту (PRD) описывается продукт, который предстоит создать: его назначение, возможности, функции и принцип работы.

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

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

Требования к продукту с учетом принципов Agile

Как происходит сбор требований в мире Agile? Если вам кажется, что это сложно, то вам не кажется! Но не стоит переживать.

В Atlassian мы знаем все о создании PRD в среде Agile. Требования к продукту, составленные по принципам Agile, — лучшее подспорье для владельца продукта.

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

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

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

Советы по созданию эффективных требований к продукту

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

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

• Пусть типы клиентов разрабатывает и использует вся команда. У каждого участника команды есть своя уникальная точка зрения и свои соображения, и каждому участнику нужно понимать, как типы клиентов определяют разработку продукта.

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

Хотите попробовать? Зарегистрируйтесь в Confluence.

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

• Создавайте информативные страницы о разговорах с клиентами.

• Извлеките из информации ценные выводы с помощью пирамиды разговора с клиентами.

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

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

Что должно входить в PRD?

При составлении документа с требованиями рекомендуется использовать один и тот же шаблон для всей команды. Благодаря этому участники смогут сверяться друг с другом и давать обратную связь. У нас в компании Atlassian для составления требований к продукту используют Confluence с шаблоном документа с требованиями к продукту.

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

1. Определите особенности проекта

В верхней части страницы рекомендуется задать общий курс работы, отразив следующее:

• Участники: кто участвует в работе? Включите в список владельца продукта, команду, заинтересованных лиц.

• Статус: в каком состоянии находится программа в настоящий момент? Работа может идти по плану, находиться под угрозой, отставать от графика, откладываться на более поздний срок и т. д.

• Ожидаемая дата выпуска продукта: когда, согласно прогнозам, произойдет поставка продукта?

2. Цели команды и бизнес-задачи

Сразу переходите к сути. Информируйте, но не утомляйте деталями. Полезно использовать ПО, которое поможет детализировать цели в удобном формате.

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

3. Исходные данные и соответствие стратегии

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

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

4. Предположения

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

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

5. Пользовательские истории

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

6. Интерфейс пользователя и дизайн

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

7. Вопросы

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

8. Области, в которых не ведется работа

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

Преимущества хорошо составленных требований к продукту

Главный вывод этой статьи заключается в следующем: важнее понимать «почему», а не «что», так как в этом случае вы сможете определить, что лучше для вашей команды.

Вот какие преимущества и недостатки мы заметили при использовании одностраничного дашбоарда для работы с требованиями к продукту.

1. Одна страница — один источник

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

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

2. Больше возможностей применения agile

Одно из достоинств совместной работы с использованием простой страницы (вместо специального средства управления требованиями) — это возможность применять принципы Agile при ведении документации. Нет нужды постоянно использовать один и тот же формат. Делайте то, что нужно и когда это нужно в духе гибкой методологии. Меняйте свой подход по мере необходимости.

3. Только необходимая информация и детали

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

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

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

• Страницы или блоги, в которых излагаются аналогичные идеи

• Прошлые обсуждения или техническая документация и диаграммы

• Видеоролики с демонстрацией продуктов или другой связанный контент из сторонних источников

4. Истории, обновляемые в режиме реального времени

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

Благодаря двусторонней синхронизации между Confluence и Jira у нас есть возможность автоматически отслеживать текущий статус каждой задачи на странице с требованиями.

5. Коллективная мудрость

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

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

6. Добавление дополнительных материалов

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

7. Совместная работа

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

Оставляйте комментарии, задавайте вопросы, стимулируйте обмен мыслями и идеями. Это особенно важно для рассредоточенных команд, у которых не так часто появляется возможность обсудить проект лично.

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

У каждого подхода есть минусы. Мы и наши клиенты столкнулись с двумя главными недостатками:

1. Документация может устаревать

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

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

2. Недостаточно активная работа участников

Как побудить сотрудников высказываться и чаще делиться спецификациями и историями во внутренней сети?

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

Начните составлять PRD с помощью Jira и Confluence

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

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

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

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