Post #800

Нашел прекрасный шаблон 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, у него тут целый набор на разные случаи.