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

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

A product requirements document defines the product you are about to build: It outlines the product's purpose, its features, functionalities, and behavior.

Next, you share the PRD with (and seek input from) stakeholders - business and technical teams who will help build, launch or market your product.

Once all stakeholders are aligned, the PRD serves as a compass, providing clear direction toward a product's purpose while creating a shared understanding among business and technical teams.

Что из себя представляет процесс сбора требований в мире 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. Пользовательские истории можно менять в зависимости от хода разработки и поставки, а также в соответствии с обратной связью. Всегда поддерживайте высокое качество и здоровую культуру разработки — даже если придется сократить количество поставляемых возможностей.