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

Менеджер по продукту, работает с несколькими командами, чтобы определить требования к нашим продуктам. Спецификация продукта — это инструмент коммуникации, который мы часто используем, чтобы привлечь всех к одной странице.
Раньше продукт-менеджеры использовали шаблоны требований к продукту, такие как BRD (Business Requirement Document) или PRD (Product Requirement Document), чтобы собрать всех на одной странице.
Однако в современную эпоху такие объемные документы слишком медленны и их часто начинают неправильно понимать. Хуже того, это превращает вашу продуктовую команду в функцию сбора требований, а не в функцию доставки ценности.
Как современные менеджеры по продукту, мы должны перейти от громоздких спецификаций продукта к использованию High Fidelity Prototypes + Wiki Pages для написания отличных требований к продукту.

Но подождите — вам все равно нужно написать хорошие спецификации

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

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

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

Итак, вот 5 шагов к использованию высокоточных прототипов для передачи спецификации вашего продукта:

1) Создайте подробный прототип с высокой точностью вместе с вашим дизайнером продукта.

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

  • Начните с эскизов с низкой точностью, чтобы оценить концепции вместе с вашей командой.
  • Согласование основных функций с заинтересованными сторонами с помощью прототипа среднего уровня точности
  • Продолжайте совершенствовать функциональность с помощью макетов, пока ваша команда не будет довольна продуктом ( убедитесь, что вы разговариваете с клиентами! )
  • Создайте прототип с высокой точностью, когда вы уверены на 80–90%

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

  • Все экраны в вашем продукте, включая крайние случаи, всплывающие окна и состояния ошибок
  • Цвета бренда , спецификации таблиц стилей и варианты заполнителя
  • Шаблоны взаимодействия и переходы между страницами
  • Загрузите дизайн в инструмент для совместной работы, такой как Invision, Origami, Zeplin, Figma, Axure или Adobe XD. Вам необходимо использовать функции комментирования и истории версий, чтобы отслеживать изменения с течением времени.

2) Назначьте встречу со своей командой, чтобы обсудить особенности

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

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

  • Назначьте встречу с вашим дизайнером и командой разработчиков
  • Пройдите вместе со своей командой через весь пользовательский поток прототипа, прежде чем углубляться в особенности
  • Вернитесь и пройдитесь по одной функции за раз. (Некоторые функции могут отображаться на нескольких экранах или иметь разные состояния)
  • Проверьте требования Frontend, Backend, Devops и QA для каждой функции.. Запишите эти требования в инструмент отслеживания проектов.
  • Поощряйте своих инженеров писать требования сами, поскольку это помогает им продумать, что необходимо сделать.
  • Если отсутствуют крайние случаи, добавьте комментарий в прототип и продолжите работу после этого.

3) Свяжите все вместе, используя страницу в стиле вики

Теперь, когда у вас есть все требования. Свяжите все вместе, используя инструмент Wiki Page, например Confluence или Notion. Использование Wiki-страницы позволяет будущим обновлениям происходить более органично, и вы избегаете проблем с контролем версий.
У Confluence и Notion есть готовый шаблон требований к продукту . Используйте его, чтобы охватить больше контекста, такого как предыстория, предположения, цели, вехи и т.д. (Пример в конце этого поста)

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

4) Отслеживайте изменения характеристик продукта в вашем инструменте для создания прототипов

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

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

5) Формализуйте документацию перед релизом продукта

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

Вот и все, вот как вы должны создавать современные спецификации продукта, которые будут использовать люди!

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

1. Создайте подробный высокоточный прототип вашего продукта с дизайнером продукта.

2. Назначьте встречу со своей командой, чтобы обсудить особенности прототипа.

3. Свяжите все вместе, используя страницу в стиле вики.

4. Отслеживайте изменения, используя комментарии и историю версий в вашем инструменте создания прототипов.

5. Оформите документацию перед релизом продукта и используйте ее как основу для работы.

Источник — пост автора productcoalition