Простой способ организовать требования на этапе сбора требований (или первый шаг к формированию уютного бэклога)

Зачем, кому это нужно, чем это сделать

Не раз задавалась вопросом: как бы так комфортно организовать входящие требования к системе — на этапе, когда требования только собираются, когда формируются вопросы и озвучиваются ответы, а ещё всё постоянно меняется и пересматривается, а ещё когда в реализации задействовано несколько систем, а ещё, а ещё…
При этом очень бы хотелось:

• видеть связь: требование➝вопрос➝изменение в требовании➝новое требование;
• избежать дублирования требований/вопросов;
• отследить задействованные в реализации системы (от обратного: чтобы представитель каждой системы видел требования, реализация которых хоть как-то касается его системы);
• получать подтверждение по каждому требованию — что да, требование понято и зафиксировано верно, что реализация возможна;
• проследить связь с требованиями другого, очень похожего на наш проект проекта — чтобы иметь знание, что вот это уже там реализовано, и мы будем просто использовать сделанные наработки;

Да и вообще.

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

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

В моём случае это проект:

• в котором задействовано несколько систем (сайт, CRM, ERP, система отправки писем и т.д.),
• соответственно, несколько исполнителей-подрядчиков,
• в котором один заказчик,
• а ещё прямо сейчас реализуется аналогичная система со схожим набором функциональностей, и эти наработки (идеи, требования заказчика, код) мы можем использовать в своей работе.

Ещё важное замечание: описанное ниже делалось с помощью Google Таблиц ^[1] — инструмента, который даёт возможности:

• одновременного доступа всех участников к документу;
• изменения документа в режиме реального времени;
• фильтрации данных.

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

Как это оформить

В обычный файл таблицы на двух листах: Требования и Вопросы.
Разберём каждый из них отдельно (а потом вместе).

Требования

Ниже перечислены столбцы в таблице на листе «Требования».
Дата, когда требование зафиксировано. Ну здесь ничего объяснять не надо, всё понятно и так. Единственное, тут также можно указать источник требования (письмо, встреча, личное общение и т.п.) если вы потом планируете как-то эту информацию использовать.
Блок. Требования нужно разбивать по блокам — ну это и так понятно. Но что по-настоящему очень важно: чтобы и понимание границ этих блоков у всех было одинаковое — и у исполнителей, и у заказчиков.

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

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

В Google Таблицы это делается так: Данные ➝ Проверка. В поле “Критерии” выбираем пункт “Список значений”, в поле справа через запятую перечисляем названия блоков (в моём случае это названия наших АТС).

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

В столбце Суть требования, собственно, содержится сам текст требования. Причём я предлагаю вносить все требования сразу, как только они будут озвучены и зафиксированы в головах в каком-то виде. Потом в них можно вникнуть, сформировать на основе них новые требования, задать вопросы (на листе «Вопросы»).
Считаю, что требования лучше дробить (до разумных пределов, конечно) и разносить их по разным строкам (в одной строке два требования быть не должно — это усложняет работу с ними в будущем).
Связь с проектом %имя проекта%. Ну этот столбец отвечает как раз за то, о чём я упоминала выше: помогает проследить связь с требованиями параллельного, очень похожего на наш проект проекта.

Здесь указывается, что: 1) такая же функциональность реализовывается в рамках другого проекта или же 2) функциональность в этом требовании связана с функциональностью в другом проекте. Можно ставить лаконичное “есть” или детализировать — в зависимости от потребностей.

В столбце Вопрос лежит номер вопроса, по требованию (подробнее про лист “Вопросы” ниже).
Есть столбец Подтверждено — в нём автор и непосредственный исполнитель ставят своё подтверждение (да, требование сформулировано верно). На проекте предложила делать это в течение двух дней, после того, как требование было внесено (смотрим столбец «Дата»). А по истечении двух дней считать, что требование верно, даже если отметка не стоит.

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

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

В этот список можно также включить столбец Автор требования, но у себя я его не делала, т.к. в моём случае автор был один, либо требование озвучивалось и формулировалось сразу всеми. Но когда требования собираются с нескольких людей, то он всё же нужен, я думаю.
Можно сделать столбец Статус, и в нём указывать, например, статус реализации требования (полезно, когда на проекте не предполагается документации с требованиями, и задачи формулируются на основе бэклога или же разработка происходит одновременно с формированием требований): статусы тоже формируются исходя из потребностей проекта — здесь не буду перечислять возможные варианты.
Статус актуальности требования отдельно отображать не советую. С эти отлично справляются столбцы Изменено (если есть новое требование, то понятно, что это требование уже не актуально, можно ещё шрифт зачёркнутый сделать — чтоб уж наверняка) и Подтверждено.
А ещё можно сделать столбец, где будет указан приоритет реализации требования — тоже весьма полезный атрибут. Или столбец с названием вайфрейма/макета, где можно подглядеть визуальное оформление.
Можно включить сюда же столбец с номером задачи в багтрекере. Или же, или же верхнеуровневые задачи в багтрекере называть по названию блоков (схем), и тогда, фильтруя по столбцу “Блок”, можно сразу же отобразить все требования в рамках задачи.

Кстати, о фильтрации. Это очень круто! Фильтрация по блокам (чтобы, рассматривая АТС/задачу в багтрекере, смотреть все требования, которые относятся к ним), по системе (чтобы видеть работы в конкретной системе и формировать свой бэклог на основе их), ещё по чему-нибудь в таблице.

В Google Таблицы это делается так: Данные ➝ Фильтр. Предварительно нужно выделить фильтруемую область (фильтрация осуществляется по столбцам).

Вопросы

Содержит столбцы:

• Дата, когда вопрос зафиксирован;
• Блок;
• Вопрос;
• Ответственный;
• Статус;
• Ответ;
• Связь с требованием.

Часть из них разобрана выше в “Требования”. Содержимое части понятно интуитивно (например, “Ответ” и “Ответственный”). Немного распишу свою последовательность работы с вопросами и требованиями на примере:

1. Зафиксировали требование на листе “Требования” (например, строка 55), заполнили про него информацию в столбцах.
2. Возник вопрос про требование, зафиксировали вопрос в листе “Вопросы”, заполнили информацию в стобцах; в столбце “Связь с требованием” указали номер требования с листа “Требования” (в нашем примере это строка 55), к которому относится вопрос.
3. Для требования, по которому возник вопрос, в толбце “Вопросы” указали номер вопроса на листе “Вопросы”.
4. Получили ответ, зафиксировали ответ напротив вопроса.
5. Сформулировали требование на основе ответа, внесли его на лист “Требования” (например, строка 60). Для требования в строке 55 в столбце “Изменено” указали номер строки 60.

Ну и не забываем статус самого вопроса менять на протяжении всего процесса (можно использовать статусы Открыт, Дан ответ, Решён).

В этом сценарии мы:
Зафиксировали требование, задали вопросы по нему, зафиксировали ответ (пункты 1-4).
Сформулировали новое требование (старое требование стало не актуально — пункт 5).
И теперь можем проследить изменение требования (и даже по датам).

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

В процессе работы на каждом проекте будут возникать свои нюансы работы в таблицах — учитывайте их и вносите в свой сценарий, меняйте таблицы в соответствии с ними. Не забывайте спрашивать себя о том, что вам нужно, чего не хватает сейчас, а потом переспрашивайте — зачем нужно сделать это, какую проблему это решит, облегчит ли или усложнит процессы.
Успехов :)

Автор: arwres

Источник ^[2]