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

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

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

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

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

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

Что такое PRD?

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

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

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

PRD с учетом принципов Agile

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

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

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

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

Советы по созданию эффективного документа PRD

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

7. Вопросы

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

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

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

Пример PRD

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

Преимущества продуманного документа PRD

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Недостатки

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

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

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

Недостаток активности от участников

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

А теперь за работу!

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

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

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

Связанные ресурсы

• Ресурсы по управлению проектами

  • Ресурсы по выполнению проекта

  • Ресурсы по завершению проекта

  • Ресурсы по запуску продукта

  • Управление событиями и проектами

  • Расширение рынка

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

  • Управление проектами по разработке ПО