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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2. Цели команды и бизнес-задачи
Пишите лаконично и по существу. Сообщайте информацию без скучных подробностей.

3. Предпосылки и согласованность со стратегией
Почему мы работаем над этим? Как эта программа вписывается в общие задачи компании?

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

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

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

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

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

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

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

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

2. Больше возможностей применения agile
Еще одним замечательным достоинством простой страницы, используемой для совместной работы (которое отличает ее от специального средства управления требованиями), является возможность применять agile-методологию к документации! Нет нужды постоянно использовать один и тот же формат. Делайте то, что нужно и когда это нужно в духе agile-методологии. Меняйте свой подход по мере необходимости.

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

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

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

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

6. Добавление дополнительных материалов
С помощью диаграмм, созданных такими средствами, как Visio, Gliffy или Balsamiq, удобнее доносить до команды суть проблем. Кроме того, можно встраивать сторонние изображения, видеоролики и динамический контент.

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

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

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

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

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

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

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