Нашел прекрасный шаблон PRD!

Какой документ составляет бизнес-аналитик? Ну, BRD. Business Requirements Document.

Но мне больше нравится PRD — Product Requirements Document, продуктовый требования. Я разделяю мнение, что ко всем современным ИТ-системам нужно подходить, как к продуктам, даже если они сугубо внутренние.

Это только кажется, что у внутренних пользователей нет выбора. На самом деле он всегда есть: саботировать, отказываться (вплоть до ухода из вашей дурацкой организации), использовать альтернативы (мы тут в эксельке всё ведём, а потом в систему вносим), делегировать. Например, почти все электронные дневники и LMS настолько неудобны для преподавателей, что во многих организациях они сами их никогда не ведут — материалы и оценки туда вносят специальные люди — секретари, ассистенты, помощники. Преподаватель туда может и не заходить никогда, не сталкиваться с этим ужасом. А при найме крутого препода специально оговаривается, что LMS за вас будем сами вести, не переживайте.

Поэтому я рекомендую подходить к каждой задаче, как к продуктовой. И начинать c PRD.

А вот и шаблон для него (англ.), на примере гипотетической фичи "Эмодзи-реакции на сообщения в Твиттере".

Что в шаблоне:

⭐️ Ссылки на питч док (документ-основание, ага), технические спецификации для бэкенда и фронтенда, спецификации дизайна, план QA. (Самих ссылок нет, подразумевается, что они в виде отдельных документов разрабатываются, как ТЗ и ЧТЗ, или ТЗ и техпроект).

⭐️ Описание фичи одним предложением

⭐️ Обоснование, почему стоит делать эту фичу:
👉 Почему именно в этой функциональной области:
— эта функциональная область продукта достаточно востребована (10% DAU)
— по данным анализа данных, использование этой функциональной области на 40% увеличивает краткосрочное удержание (STR 7 дней)
— рост этой метрики (STR7DAY) включен в OKR как цель
👉 Почему именно эту фичу:
— 14% всех сообщений — это эмодзи
— 10% ответов на сообщения являются эмодзи
— 5% ответов являются одной из трех эмодзи (👍, 😂, ❤️)
— По данным опроса, реакция на сообщения — вторая среди запрашиваемых фич
— По результатам фокус-группы, реакции на сообщения названы must-have фичей
— 20% всех тикетов (обращения в поддержку, упоминания в соц.сетях, отзывы в сторах) упоминают реакции
— Конкуренты внедрили эту фичу более года назад и она активно используется (25% пользователей по данным группы исследования конкурентов)

(Естественно, на источники всех данных приведены ссылки)

⭐️ Почему сейчас стоит делать именно эту фичу, а не другую? (ссылки на дорожную карту, анализ альтернативных элементов бэклога, таблицу с расчетом приоритетов)

⭐️ Перечень основных пользовательских историй (буквально 4 штуки)

⭐️ Цели реализации фичи

⭐️ Метрики успеха (целевые значения метрик использования и метрики продукта, которую улучшаем — в данном случае STR)

⭐️ Метрики отслеживания (тут метрики успеха, и связанные метрики — например те, значения которых могут снизиться или перестать быть релевантными из-за изменения логики расчета)

⭐️ Список принятых решений и матрица информирования DACI (Driver-Approver-Contributors-Informed)

⭐️ Продуктовые требования с приоритетами, этапами и статусами готовности

⭐️ Макеты интерфейсов и пути пользователей

⭐️ План информирования и обучения пользователей

⭐️ Что не входит в рамки проекта

⭐️ Настраиваемость (где и как можно включать/отключать фичу)

⭐️ Открытые вопросы

⭐️ Ссылки на протоколы совещаний по проекту

Мне кажется, очень классный шаблон! Я был бы рад, если бы мои аналитики/продакты мне такое приносили (+на одну страницу краткое резюме). И это то, что может и должен делать бизнес-аналитик. Для сложных внутренних доработок ещё стоит добавить модель бизнес-процесса (если он есть), для сложных интеграций — предполагаемую верхнеуровневую архитектуру. И на этом, по моему мнению, фокусироваться. А вот конкретные требования к фронту, бэку и интеграциям — это уже работа системного аналитика.

Шаблон взят из блога Manas J. Saloi, у него тут целый набор на разные случаи.