Как составить продуктовые требования

Как писать функциональные требования

Привет, Хабр!

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

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

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

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

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

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

Функциональные требования: что это такое и зачем они нужны

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

Функциональные требования — это постановка задачи разработчику. Все, что не указано в требованиях, делается на усмотрение разработчика, что часто расходится с представлением продакт-менеджер об ожидаемом результате. Поэтому требования должны содержать ответы на все возможные вопросы по задаче.

Функциональные требования, как правило, состоят из:

• User story — показывает, чего вы ожидаете от команды разработки
• Use cases — показывают сценарии использования фичи
• Wireframes — средство визуализации своей идеи

Сегодня мы сосредоточимся на User story и Use cases.

User story

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

Как правило используется шаблон:

As a/an <Название роли>, I want to <Цель, Действие>, so that <Ожидаемый результат>, to do <Что нужно сделать разработчику>

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

В Retail Rocket мы создаем User Stories в Google Docs, используя таблицы. Это помогает упростить процесс коммуникации между различными командами, поскольку каждый может оставить комментарии и дать фидбек.

Например, так выглядит задача об отслеживании NPS для интернет-магазина:

Благодаря такой визуализации взаимодействия задача пользователя плавно и логично переходит в задачу для разработчиков. Затем наступает очередь use case’ов.

Use cases

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

Задача пользователя — это то, что делает пользователь для достижения краткосрочных целей.

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

Рассмотрим на примере нашей недавно выпущенной фичи — Галерее изображений и шрифтов для массовых рассылок.

Цель пользователя в том, чтобы хранить изображения в нашей платформе и использовать их для создания email-кампаний.

Задачи пользователя:

• Загружать изображения
• Вставлять изображения в шаблон письма
• Удалять изображения

Для каждой задачи нужно написать свой use case — описание того, как пользователь взаимодействует с интерфейсом.

Примеры use case’ов:

Загрузка изображений:

• Email-маркетолог заходит в свой личный кабинет Retail Rocket
• Email-маркетолог открывает раздел «Галерея»
• Email-маркетолог загружает изображения через drag&drop или с помощью клика по кнопке «Выбрать файлы»
• Изображения загружаются
• Пользователь видит уведомление об успешной загрузке изображений

Удаление изображений:

• Пользователь кликает на изображение
• Изображение выделяется
• Выделение можно снять при помощи клика на область за пределами выделенного изображения
• Пользователь нажимает на иконку «три точки»
• Появляется контекстное меню
• Пользователь выбирает в нем ссылку «Удалить файл». Если было выделено несколько изображений, то удалятся все
• Изображение удаляется

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

Почему функциональные требования так важны

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

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

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

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

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

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

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

А как вы подходите к постановке задач разработчикам?

Директор по продукту Гульфия Курмангалеева

Составление требований к разработке фичей: Курс «Создание программного продукта и управление его развитием»

Привет, Хабр! Продолжая серию публикаций по продуктовому менеджменту, сегодня мы обсуждаем требования к разработке. В этом посте речь пойдет о том, как продуктовый менеджер взаимодействует с разработчиками из R&D, зачем нужны требования, как правильно их сформулировать, и какие выводы из требований к разработке должны делать различные специалисты, включая самих разработчиков, менеджеров, QA и так далее. С другой стороны будущие и уже состоявшиеся разработчики узнают, что может (и вообще-то должен) предоставлять вам менеджер продукта. Все подробности — под катом.

Оглавление курса

1. Роль менеджера по продукту и фреймворк
2. Сегментирование рынка и конкурентный анализ
3. Пользовательские персоны
4. Проверка гипотез
5. Позиционирование продукта
6. Дорожная карта продукта
7. Составление требований для разработки < — Вы здесь
8. Бизнес-модель и Бизнес-план
9. Финансовый план и ценообразование
10. Запуск ИТ-продукта и проведение маркетинговой кампании
11. Партнерские отношения, каналы дистрибьюции и продажи продукта
12. Этапы развития компании и продукта

Иногда кажется, что задача для разработчика просто очевидна! Но не стоит слишком сильно полагаться в вопросах постановки задачи на здравый смысл. Для любой, даже самой простой задачи возможны разночтения, потому что людям свойственно жить в мире собственных иллюзий. Например, в Республике Куба считается, что стены должны быть яркими и пестрыми, и если даже заказчик попросит покрасить стены в белый, работники могут добавить цветных пятен, потому что «так ведь красивее». То же самое касается и разработки.

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

Как строятся требования

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

Например, в приложении веб-форума могут быть определены следующие акторы:

• Администратор может всё, буквально всё — в том числе назначать роли (персоны) другим пользователям.
• Обычный пользователь может только оставлять сообщения.
• Модератор может оставлять сообщения, удалять чужие сообщения, банить обычных пользователей.

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

Чтобы сформулировать адекватное требование, нужно составить документ, который мы называем Feature Description. А для этого нужно ответить на следующие вопросы:

• Зачем? Какова цель? В чем польза для бизнеса?
• Почему? Каковы риски? Что мы потеряем, если не сделаем? Что случится, если сделаем?
• Что? Какую проблему мы хотим решить? Для кого?
• Как? Функциональные требования и сценарий использования (последовательность действий).

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

Наконец, в документе нужно сделать секцию “Approvals” (согласование), в которой, с одной стороны, заказчики фичи (стейкхолдеры, клиенты, продакт-менеджер) согласятся, что описание соответствует тому, что они хотят получить от продукта. С другой стороны, разработчики (тимлиды, архитекторы) подтвердят, что описание задачи в требованиях является понятным и полным. Все участники процесса разработки таким образом должны сказать: “Да, документ нам понятен, теперь это можно сделать».

Вспомогательные метрики

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

• Definition of Done — краткое описание того, как понять, что фича работает.
• Нефункциональные требования — требования к технических параметрам такие как: скорость реакции UI, загрузка бэкэнда, ограничения CPU и оперативной памяти. Это очень важный пункт, ведь если не озвучить требования, можно получить монстра — встроенный фотошоп вместо простого выбора цвета автомобиля.
• Требования к безопасности — шифрование, хранение персональных данных и т.д.
• Corner Case — тестирование граничных случаев. Что будет, если цена товара 0? Сколько машин такси может заказать человек одновременно?
• Частотность сценариев — определение, какие сценарии встречаются чаще. Например, при добавлении платежей хорошо указать, какой платежной системой, скорее всего, будут пользоваться клиенты — Visa, MasterCard, МИР, приложив ссылку на статистику.
• Требования к мониторингу и сбору метрик. Если есть фича, то нужно собирать данные, отслеживать, кто ее вызывает, как часто использует и так далее. Сбор данных можно вести анонимно, но нужно это делать, чтобы развивать продукт в дальнейшем. Ведь если мы ничего не измеряем, то ничего не знаем о реальной работе приложения.
• Зависимости фичей помогают правильнее распределять ресурсы. Например, нельзя реализовать “возможность оплаты картой Мир”, пока мы не сделали фичу “выбор метода оплаты”.

Функциональные и нефункциональные требования, сценарии использования

Остановимся немного на функциональных и нефункциональных требованиях.

Функциональные требования объясняют, что должно быть сделано, в них перечислены действия приложения, как реакция на действия Актора. Эти требования реализуются в перечисленных Use Scenarios (сценариях использования).

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

• масштабируемость,
• надёжность, минимальное время простоя,
• методы поддержки.

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

Пользовательские сценарии обычно содержат следующие секции:

Секция: Контекст
Отвечает на вопрос: Какой компонент? Какое состояние?
Пример: Пользователь не авторизован.

Секция: Актор
Отвечает на вопрос: Какая персона?
Пример: Обычный пользователь.

Секция: Предварительные условия
Отвечает на вопрос: Каковы особенности?
Пример: Есть приглашение получить VIP-статус.

Секция: Цель
Отвечает на вопрос: Что пользователь намеревается сделать/получить?
Пример: Войти в систему.

Секция: Основной сценарий
Отвечает на вопрос: Какие действия нужно совершить для достижения результата?
Пример: Ввести логин и пароль, нажать кнопку “войти”.

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

Секция: Макеты
Отвечает на вопрос: Возможные макеты или прототипы дизайна UI.
Пример: нарисуйте в Figma или Sketch.

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

Как читают Feature Description?

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

• Разработчики — Им важно знать, зачем нужна фича, какой вопрос она решает. Для того, чтобы не тратить потом время на исправления, разработчикам нужно предоставить полный список всех сценариев, а также обратить внимание на Corner cases. Если вовремя сообщить разработчику о том, что мы потом добавим, например, платежи картой МИР, он сможет предусмотреть эту возможность на уровне архитектуры. Таким образом, можно значительно сократить затраты, избежав переделок.
• Тестировщики, QA — Ожидают от вас получить данные о частотности сценариев, чтобы проверять в первую очередь самые критичные. Также им важны четко описанные Corner Cases. Для проверки нужно указать различия сценариев в зависимости от локализации, а также четко определить все пределы — максимальную длину имени, максимальное количество машин в заказе и т.д. Для инженеров нужно описать реакцию на возможные внешние изменения (пользователь переключился, вышел, закрыл окно) и принять базовое состояние для работы приложения. Это необходимо, чтобы не сломалась логика бизнес процесса. Также очень важны требования к производительности и отказоустойчивости.
• DevOps и Datacenter Operations— Им нужно знать, с какими компонентами работает продукт, какая инфраструктура для него требуется, сколько ресурсов будет использоваться софтом от серверных мощностей. DevOps должны знать, какие метрики мониторинга важнее других, как убедиться, что всё работает с их стороны.
• Технический писатель — Он должен четко понимать, какая проблема может возникнуть у пользователя, и как ее решить. Поэтому писатель тоже будет изучать сценарии использования, частотность сценариев, характеристики мокапов и тексты ошибок.

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

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

Руководствуйтесь простым правилом: начинайте с главного и только потом добавляйте детали. Кроме этого нужно получить обратную связь от QA, Developers, DevOps и других заинтересованных лиц. Скорее всего, Feature Description обрастет новыми деталями после общения со стейкхолдерами.

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

Заключение

В следующем материале мы поговорим о бизнес-плане и ценообразовании для нового продукта.

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

→ Видео-запись всех лекций курса доступна на YouTube

Лекция про дорожную карту и требования для разработки:

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

1. Введение —

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

1.1. Цель

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

Этот раздел должен быть коротким: достаточно 1-2 абзацев.

1.2. Целевая аудитория

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

1.3. Использование по назначению

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

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

1.4. Объем

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

В этом разделе должны быть описаны:

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

1.5 Определения и сокращения

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

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

2. Общее описание

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

2.1 Потребности пользователей

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

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

2.2 Допущения и зависимости

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

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

3. Особенности системы и требования

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

3.1 Функциональные требования

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

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

3.2 Требования к внешнему интерфейсу

Функциональные требования составляют значительную часть спецификации системных требований. Чтобы охватить все необходимые функции системы, вам понадобится 4-5 страниц информации. Некоторые команды разбивают их по темам, чтобы документ было легче читать.

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

В зависимости от проекта требования к внешнему интерфейсу могут состоять из четырех типов:

• Интерфейс пользователя
• Программный интерфейс
• Аппаратный интерфейс
• Интерфейс связи

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

3.3 Системные требования

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

Создание системных требований перед началом создания продукта может показаться сложным, но это необходимо. Разработчики должны придерживаться требований к оборудованию, чтобы им не пришлось перезапускать проект позже. Мобильные приложения (с множеством переменных, которые необходимо учитывать) и приложения, требующие высокой реактивности (игры, любой продукт с VR/AR или IoT), особенно уязвимы.

3.4 Нефункциональные требования 

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

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

Документы с требованиями к продукту, сокращенные

Никто не любит писать раздутые, ультра-подробные документы с требованиями к продукту. Оказывается, никто не любит их использовать, вообще.

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

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

Затем вы делитесь PRD с заинтересованными сторонами (и запрашиваете информацию) — деловыми и техническими командами, которые помогут создать, запустить или продать ваш продукт.

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

Сбор требований в agile мире

Как выглядит процесс сбора требований в agile мире? Это звучит сложно — и это так. Но не волнуйтесь. В Atlassian мы знаем все о создании PRD в agile среде. Вот несколько вещей, которые нужно иметь в виду:

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

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

Создание общего понимания между командами

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

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

Хотите попробовать?

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

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

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

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

АНТИ-ОБРАЗЦЫ, ЧТОБЫ СМОТРЕТЬ ЗА НИМИ

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

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

Сохранение требований с помощью одностраничной панели управления

При написании документа с требованиями полезно использовать единый шаблон для всей команды, чтобы каждый мог следить за ним и давать отзывы. В Atlassian мы используем Confluence для создания требований к продукту с помощью шаблона документа требований к продукту. Мы обнаружили, что в следующем разделе «достаточно» контекста, чтобы понять требования проекта и его влияние на пользователей:

1. Определите специфику проекта

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

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

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

Получить прямо в точку. Сообщите, но не надоедайте.

1. Предпосылки и стратегическое соответствие

Зачем мы это делаем? Как это вписывается в общие цели компании?

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

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

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

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

1. Взаимодействие с пользователем и дизайн

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

1. Вопросы

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

1. Что мы не делаем

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

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

Пример одностраничного PRD

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

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

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

• Как создать документ с требованиями к продукту.

Основные выводы из одностраничного подхода:

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

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

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

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

1. Повышенная гибкость

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

1. Достаточно контекста и деталей

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

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

1. Живые истории

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

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

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

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

1. Привлечение «накладных расходов»

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

1. Сотрудничество!

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

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

Вызовы

У каждого подхода есть свои недостатки. Здесь есть два основные вызовы, с которыми мы столкнулись и наблюдали от клиентов:

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

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

1. Недостаток участия

«Что я могу сделать, чтобы побудить людей комментировать?», «Как я могу побудить людей писать больше спецификаций и историй в нашей интрасети?». Это является  крепким орешком, и он сводится к различным методам принятия вики в вашей организации. Есть много ресурсов, чтобы помочь вам здесь. Здесь могут быть и более глубокие культурные проблемы.

Теперь приступайте  к работе!

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

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

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

По материалам Agile Coach «Requirements»

Практический метод написания RPD для менеджеров по продуктам

Менеджер по продукту отвечает за написание документа с требованиями к продукту («PRD»). Этап написания PRD выполняется после выполнения нескольких предварительных шагов: описания рыночных возможностей, определения проблемы пользователя, сбора потребностей пользователя и их анализа. Менеджер по продукту и менеджер проекта также должны создать отдельные документы, касающиеся управления проектом и плана тестирования обеспечения качества, графика рассмотрения, стоимости, методов разработки, этапов разработки, результатов и процедур тестирования.

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

Введение

1. Имя системы
2. Автор
3. Дата
4. Лист редакции (версия, дата, описание редакции)

Цель и предыстория

В этом разделе описывается обзор цели и предыстории документа с требованиями к системе. Он должен включать:

1. Цель, предыстория и аудитория
2. Общий деловой контекст
3. Краткое введение в организацию и назначение различных разделов
4. Обзор разрабатываемой системы
5. Ограничения проекта, такие как стоимость и график
6. Прилагаемые документы

Сфера

1. Этот раздел определяет границы продукта
2. Что он будет и не будет делать продукт
3. Что есть и что не будет реализовано
4. Основной функционал и возможности системы

Определения, сокращения и сокращения

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

1. Потенциально неизвестные или неоднозначные слова
2. Акронимы
3. Сокращения

Продуктовая среда

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

1. Предположения и зависимости
2. Среда установки
3. Блок-схема, показывающая важные интерфейсы между системой и ее окружением.
4. Интерфейсы системы: API, входные и выходные файлы
5. Рабочий процесс системы
6. Аппаратные системы и программные системы
7. Интерфейс системы управления базами данных
8. Пользовательский интерфейс, который характеризует интерфейс между системой и ее окружением.

Характеристики пользователя

Раздел характеристик пользователя представляет собой полное и точное представление о конечных пользователях. Общие характеристики конечных пользователей включают в себя:

1. Роли пользователей, категории пользователей и типы пользователей
2. Обязанности пользователей
3. Знание домена пользователями
4. Техническая искушенность пользователей
5. Опыт и образование пользователя
6. Приоритизация

Ограничения

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

Нефункциональные требования

1. Эксплуатационные требования: характеристики физической среды для продукта.
2. Требования к производительности: скорость, безопасность, точность, надежность, доступность, емкость, масштабируемость, ремонтопригодность и переносимость.
3. Требования безопасности
4. Другие атрибуты качества

Функциональные требования

1. Список приоритетных вариантов использования
2. Уникальный номер для помощи в отслеживании
3. Для каждого варианта использования или части рабочего процесса: список соответствующих системных требований.
4. Действия, которые продукт должен выполнять в ответ на входные данные, поступающие от пользователей или других программных систем.
5. Ответы как для допустимых, так и для недопустимых входных значений.
6. Каркасы
7. Мокапы
8. Скриншоты
9. Иллюстрации
10. Дополнительные варианты использования для будущего использования, расширения и обслуживания.
11. Предварительная смета предоставляется застройщиком.

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

Автор Мааян Гальперин