Требования

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

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

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

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

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

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

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

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

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

7. Вопросы

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

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

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

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

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

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

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

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вызовы

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

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

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

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

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

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

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

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

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

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