Публикации и ответы на комментарии в блогах JetBrains не выходят на русском языке с 2022 года.
Приносим извинения за неудобства.
Управляйте требованиями к продукту с базой знаний YouTrack
YouTrack используется для создания отличных продуктов в командах разного профиля — маркетинг, разработка, управление проектами и продуктами. Всем им необходим эффективный процесс по управлению требованиями к продукту. Как правило, такой процесс включает создание пользовательских сценариев, описание проекта с помощью диаграммы Ганта, сбор публичных и внутренних запросов на новую функциональность, исправление ошибок и совместную работу над задачами с другими командами.
Однако теперь есть и другой способ. Управлять требованиями к продукту можно прямо в базе знаний — используйте YouTrack для создания и ведения документации с требованиями к вашему продукту, а также отслеживания всех ее изменений.
Давайте посмотрим, как это работает.
Зачем нужен документ «Требования к продукту»?
Если вы владелец продукта или запускаете продукт, если вы участник команды, работающей над проектом, и хотите узнать, что продукт умеет и как он работает, — документ «Требования к продукту» будет для вас важнейшим источником информации.
Требования к продукту описывают и определяют общее назначение вашего продукта, его поведение, возможности и функциональные характеристики — с самого начала проекта вплоть до его завершения. Но просто записать всю эту информацию недостаточно. Ви́дение продукта часто меняется со временем, в результате чего требования к продукту также корректируются. Часто очень много времени уходит на то, чтобы привести продукт в соответствие с обновленными требованиями.
Вот почему грамотно настроенный процесс управления требованиями так важен. Будучи корректно организован, такой процесс поможет вам отслеживать все важные пункты требований и вовремя реагировать на их изменения.
Вот несколько советов, которые помогут вам грамотно организовать работу с требованиями к продукту.
Соберите вместе все источники ваших будущих требований
Начинать проект с нуля может быть непросто. Соберите все данные по предстоящему проекту — исследования, отзывы потенциальных пользователей, все материалы, созданные на этапе планирования, и результаты уже проведенных мозговых штурмов. На этом этапе лучше «сгрести все в одну кучу». Отфильтровать ненужное можно будет позже.
В зависимости от специфики вашего проекта источники требований могут быть следующими.
- Актуальные материалы по вашей бизнес-стратегии и целям вашего продукта.
- Информация от команды, работающей над продуктом.
- Результаты исследований (к примеру, это могут быть стратегические исследования или анализ соответствия продукта рынку).
- Обратная связь от потенциальных пользователей. Пообщайтесь с представителями вашей команды поддержки — у них может быть много полезной информации.
- Анализ конкурентов. Другие люди уже могли столкнуться с определенными трудностями, которых вы можете избежать.
- Результаты встреч с клиентами — собеседований, опросов и демонстраций.
- Ваш публичный баг-трекер (при наличии).
- Ваше представление о поведении продукта или его функциональности. Не стоит недооценивать свою интуицию!
Основная цель на данном этапе — собрать все воедино. Создайте черновик в базе знаний YouTrack и добавьте в него свои документы. Есть разные способы сделать это: можно встраивать Google-документы с исследованиями, вставлять ссылки на задачи с отзывами пользователей, а также прикреплять файлы, содержащие анализ стратегии вашего продукта.
Как только максимальный объем информации будет собран, следует тщательно изучить все требования и привести их в удобный для управления вид.
Итак, первый черновик
Что касается формулирования требований к продукту, здесь почти нет каких-либо стандартов и правил. Как сделать материал согласованным и понятным? Мы с радостью дадим вам несколько советов из своего опыта.
- Кратко опишите назначение продукта или функциональности.
- Перечислите ответственных, чтобы на каждом из основных этапов (к примеру, на этапе тестирования или проектирования) была возможность быстро определить, с кем можно связаться.
- Укажите крайний срок или дату планируемого запуска, чтобы у всех участников команды была согласованная информация об объеме работы по проекту и его графику.
- Разместите ссылки на соответствующие эпики или пользовательские истории, чтобы обеспечить связь требований с реальным процессом разработки (более подробно об эпиках см. ниже).
- Определите основные отличительные черты поведения, инфраструктуры и дизайна продукта.
Старайтесь излагать идеи простым языком — они должны быть понятны любому человеку с первого раза. Используйте таблицы и упорядоченные списки для грамотного структурирования информации.
«Используй структуру, Люк!»
Настало время упорядочить требования и сделать их удобными для просмотра.
Если пользователи не знают, где размещена нужная информация, они могут воспользоваться полнотекстовым поиском — просто ввести ключевое слово и увидеть содержащие его статьи базы знаний. Однако лучше не вынуждать их пользоваться поиском — структурируйте требования так, чтобы все нужное легко находилось без него.
Наглядная древовидная структура позволит вам избежать повторений и противоречий в требованиях, а также позволит читателю быстро находить необходимые статьи. Как правило, на данной стадии структура требований является одноуровневой и состоит из собственно документа «требования к продукту», а также нескольких документов с материалами стратегического значения. Однако по мере разработки продукта структура, скорее всего, будет разрастаться, вбирая в себя новые материалы (информацию, полученную в результате опросов клиентов, встреч команд и прочего). Рекомендуется с самого начала придерживаться четкой структуры, даже если сперва кажется, что она вам не понадобится вовсе. Например, для консолидации структуры вы можете создать на втором уровне «статьи-заготовки» для документов, которые планируется добавить позже.
Далее вы можете перемещать статьи, посвященные конкретным требованиям, между различными деревьями, чтобы таким образом построить иерархию, которая соответствует потребностям вашей организации.
Время сотрудничать
Готовы услышать мнения и точки зрения других людей? Упоминайте в комментариях коллег и клиентов, чтобы вовлекать их в дискуссии. Выдавайте контрибьюторам права редактирования, чтобы они могли самостоятельно добавлять свои предложения; ведите диалог в комментариях, чтобы сделать дискуссию более прозрачной. Вы будете получать уведомления обо всех изменениях во всех статьях.
Важно вовремя вовлекать в процесс нужных людей. Например, можно организовать встречу, на которой у всех заинтересованных сторон будет возможность просмотреть требования к продукту и обсудить все потенциальные возражения лично.
«Хорошее» требование должно удовлетворять нескольким критериям: оно должно быть кратким, понятным, проверяемым, согласованным и реализуемым. Изучите свои статьи в базе знаний и при необходимости доработайте требования. Рекомендуем создать универсальный способ маркировки проверенных и одобренных требований; например, это может быть комментарий к требованию или примечание в таблице.
Также рекомендуем сохранять результаты (протоколы) ваших встреч в виде специальных дочерних статей. Это поможет вам вспомнить, какие темы обсуждались, какие решения были приняты, а какие вопросы отложены.
Используйте (или не используйте) Agile
В зависимости от принятых у вас процессов требования к продукту могут меняться динамически в течение всей разработки или будут формализованы перед началом каждого нового этапа. Если вы предполагаете, что изменения будут вноситься в течение всего процесса разработки, необходимо постоянно следить за согласованностью понимания задач. Если изменения вносятся только перед началом нового этапа разработки, то новые требования должны быть одобрены всеми вовлеченными сторонами до начала их реализации.
Если вы применяете Agile, лучше корректировать требования сразу же при появлении изменений — это означает, что вам нужно быть в курсе всех последних изменений. После каждого этапа стоит проводить опрос клиентов, чтобы удостовериться, что ваше понимание требований все так же совпадает. Рекомендуем также уделять внимание приоритетной сортировке очереди (важное должно идти первым). Кроме того, не взваливайте все обязанности на себя — вовлекайте в дискуссии и встречи с клиентами участников соответствующих команд.
Если вы используете каскадную модель, то прежде чем переходить на новый этап разработки, проведите несколько встреч с разбором требований к продукту с участием всех вовлеченных сторон. Это поможет вам избежать противоречивости требований и убедиться, что все понимают их одинаково.
Вне зависимости от выбранного процесса вы всегда сможете просмотреть и восстановить любые предыдущие версии ваших страниц.
Завершите историю
Готовы начать реализацию? Используйте связи и типы задач в YouTrack для создания эпиков и дробления их на более мелкие задачи для вашей команды.
Преобразование ваших требований в реальную функциональность и задачи является важнейшим шагом в разработке продукта. На этом этапе вы можете осознать, что некоторые требования нуждаются в повторном изучении и доработке, — это нормально. Рекомендуем выполнять несколько итераций ревью, чтобы обеспечить максимальную приближенность требований к реальности.
Если вы используете каскадные процессы, уделите внимание такой функциональности YouTrack для планирования, как диаграммы Ганта. Они помогают прогнозировать дедлайны проекта, учитывая возможные даты его начала и зависимости между задачами.
Если вы работаете с Agile-процессами, воспользуйтесь функциональностью «Agile-доски», чтобы получить удобный панорамный обзор ваших эпиков и их дочерних задач на одном экране. Хотя эпик можно использовать для представления всей функциональности, его задачи должны быть достаточно малы, чтобы их можно было выполнить в течение 1–3 дней. Назначайте задачам приоритеты, устанавливайте между ними зависимости и отслеживайте прогресс прямо на доске. Мы считаем, что это один из самых эффективных способов сохранять полную синхронизацию с вашим продуктом.
Создайте очередь из своих задач (при необходимости поменяйте их порядок вручную, чтобы назначить им приоритет согласно важности) и встройте ее на страницу требований. Очередь будет раскрыта прямо в статье, избавляя вас от необходимости постоянно переключаться между трекером и базой знаний.
А теперь к разработке
Мы надеемся, что эти советы помогут вам настроить процессы под свои конкретные нужды и создать отличный продукт.
У нас есть несколько идей о том, как сделать базу знаний YouTrack еще лучше. А что думаете вы? Расскажите нам — так мы сможем скорректировать наши собственные требования к продукту, чтобы вам было удобнее работать с ним.
ваша команда YouTrack
The Drive to Develop
Subscribe to YouTrack Blog updates
