Зачем, кому это нужно, чем это сделать
Не раз задавалась вопросом: как бы так комфортно организовать входящие требования к системе — на этапе, когда требования только собираются, когда формируются вопросы и озвучиваются ответы, а ещё всё постоянно меняется и пересматривается, а ещё когда в реализации задействовано несколько систем, а ещё, а ещё…
При этом очень бы хотелось:
- видеть связь: требование➝вопрос➝изменение в требовании➝новое требование;
- избежать дублирования требований/вопросов;
- отследить задействованные в реализации системы (от обратного: чтобы представитель каждой системы видел требования, реализация которых хоть как-то касается его системы);
- получать подтверждение по каждому требованию — что да, требование понято и зафиксировано верно, что реализация возможна;
- проследить связь с требованиями другого, очень похожего на наш проект проекта — чтобы иметь знание, что вот это уже там реализовано, и мы будем просто использовать сделанные наработки;
Да и вообще.
Но если вы у себя на проекте уже решили все эти задачи, то текст ниже вам ни к чему, пожалуй, но непременно поделитесь в комментариях — каким образом?
Сразу оговорюсь, что всё, что описано ниже, решает проблемы сбора требования в рамках проекта, где идея всего этого зародилась, если ваш проект отличается от описанного ниже, то вы не решите все свои проблемы этим инструментом — придётся немного подумать, чего хотите именно вы, и изменить предложенный сценарий под свои потребности. Но информация ниже может стать основой для создания своего инструмента и натолкнуть на идеи для его реализации.
В моём случае это проект:
- в котором задействовано несколько систем (сайт, CRM, ERP, система отправки писем и т.д.),
- соответственно, несколько исполнителей-подрядчиков,
- в котором один заказчик,
- а ещё прямо сейчас реализуется аналогичная система со схожим набором функциональностей, и эти наработки (идеи, требования заказчика, код) мы можем использовать в своей работе.
Ещё важное замечание: описанное ниже делалось с помощью Google Таблиц — инструмента, который даёт возможности:
- одновременного доступа всех участников к документу;
- изменения документа в режиме реального времени;
- фильтрации данных.
Конечно, сервис даёт куда-а больше возможностей, но здесь я перечислила важные для решения задач, описанных в статье.
Итак,
Как это оформить
В обычный файл таблицы на двух листах: Требования и Вопросы.
Разберём каждый из них отдельно (а потом вместе).
Требования
Ниже перечислены столбцы в таблице на листе «Требования».
Дата, когда требование зафиксировано. Ну здесь ничего объяснять не надо, всё понятно и так. Единственное, тут также можно указать источник требования (письмо, встреча, личное общение и т.п.) если вы потом планируете как-то эту информацию использовать.
Блок. Требования нужно разбивать по блокам — ну это и так понятно. Но что по-настоящему очень важно: чтобы и понимание границ этих блоков у всех было одинаковое — и у исполнителей, и у заказчиков.
Например, у разных участников разное понимание процесса “Оформление заказа”. Кто-то включает сюда и формирование пользовательской корзины тоже, а кто-то рассматривает эти процессы отдельно (потому что корзина — отдельный процесс со своим набором сценариев обмена данными). И тогда фразы “на этапе оформления заказа мы отображаем то-то” (от заказчика) или “мы отдадим вам на оформлении такие-то данные” (от другой системы) могут иметь разный для всех конечный смысл.
На нашем проекте мы параллельно со сбором требований сразу же рисовали АТС, и блоки у нас по названиям схем. В файле я сделала в ячейках столбца вот такую выпадайку:
В Google Таблицы это делается так: Данные ➝ Проверка. В поле “Критерии” выбираем пункт “Список значений”, в поле справа через запятую перечисляем названия блоков (в моём случае это названия наших АТС).
Это очень удобно: при формировании требований сразу понятно, к какому процессу требование относится. Плюс можно фильтровать по блокам (отобразить только требования относящиеся к конкретному блоку — ниже расскажу подробнее). А ещё при разборе схем также можно сразу же вносить вновь появляющиеся требования.
В столбце Суть требования, собственно, содержится сам текст требования. Причём я предлагаю вносить все требования сразу, как только они будут озвучены и зафиксированы в головах в каком-то виде. Потом в них можно вникнуть, сформировать на основе них новые требования, задать вопросы (на листе «Вопросы»).
Считаю, что требования лучше дробить (до разумных пределов, конечно) и разносить их по разным строкам (в одной строке два требования быть не должно — это усложняет работу с ними в будущем).
Связь с проектом %имя проекта%. Ну этот столбец отвечает как раз за то, о чём я упоминала выше: помогает проследить связь с требованиями параллельного, очень похожего на наш проект проекта.
Здесь указывается, что: 1) такая же функциональность реализовывается в рамках другого проекта или же 2) функциональность в этом требовании связана с функциональностью в другом проекте. Можно ставить лаконичное “есть” или детализировать — в зависимости от потребностей.
В столбце Вопрос лежит номер вопроса, по требованию (подробнее про лист “Вопросы” ниже).
Есть столбец Подтверждено — в нём автор и непосредственный исполнитель ставят своё подтверждение (да, требование сформулировано верно). На проекте предложила делать это в течение двух дней, после того, как требование было внесено (смотрим столбец «Дата»). А по истечении двух дней считать, что требование верно, даже если отметка не стоит.
Конечно, это далеко не обязательный столбец, но вот лично мне так комфортнее — знать, что у всех участников единое понимание требований.
Система — указываются задействованные в реализации требования системы.
В столбец Изменено вносится номер нового требования из этого же документа, связанного с текущим (требование изменилось, стало не актуальным, а что тогда актуально). Подробнее про столбец упоминается ниже в статье (в сценарии в разделе «Вопросы»).
В этот список можно также включить столбец Автор требования, но у себя я его не делала, т.к. в моём случае автор был один, либо требование озвучивалось и формулировалось сразу всеми. Но когда требования собираются с нескольких людей, то он всё же нужен, я думаю.
Можно сделать столбец Статус, и в нём указывать, например, статус реализации требования (полезно, когда на проекте не предполагается документации с требованиями, и задачи формулируются на основе бэклога или же разработка происходит одновременно с формированием требований): статусы тоже формируются исходя из потребностей проекта — здесь не буду перечислять возможные варианты.
Статус актуальности требования отдельно отображать не советую. С эти отлично справляются столбцы Изменено (если есть новое требование, то понятно, что это требование уже не актуально, можно ещё шрифт зачёркнутый сделать — чтоб уж наверняка) и Подтверждено.
А ещё можно сделать столбец, где будет указан приоритет реализации требования — тоже весьма полезный атрибут. Или столбец с названием вайфрейма/макета, где можно подглядеть визуальное оформление.
Можно включить сюда же столбец с номером задачи в багтрекере. Или же, или же верхнеуровневые задачи в багтрекере называть по названию блоков (схем), и тогда, фильтруя по столбцу “Блок”, можно сразу же отобразить все требования в рамках задачи.
Кстати, о фильтрации. Это очень круто! Фильтрация по блокам (чтобы, рассматривая АТС/задачу в багтрекере, смотреть все требования, которые относятся к ним), по системе (чтобы видеть работы в конкретной системе и формировать свой бэклог на основе их), ещё по чему-нибудь в таблице.
В Google Таблицы это делается так: Данные ➝ Фильтр. Предварительно нужно выделить фильтруемую область (фильтрация осуществляется по столбцам).
Вопросы
Содержит столбцы:
- Дата, когда вопрос зафиксирован;
- Блок;
- Вопрос;
- Ответственный;
- Статус;
- Ответ;
- Связь с требованием.
Часть из них разобрана выше в “Требования”. Содержимое части понятно интуитивно (например, “Ответ” и “Ответственный”). Немного распишу свою последовательность работы с вопросами и требованиями на примере:
- Зафиксировали требование на листе “Требования” (например, строка 55), заполнили про него информацию в столбцах.
- Возник вопрос про требование, зафиксировали вопрос в листе “Вопросы”, заполнили информацию в стобцах; в столбце “Связь с требованием” указали номер требования с листа “Требования” (в нашем примере это строка 55), к которому относится вопрос.
- Для требования, по которому возник вопрос, в толбце “Вопросы” указали номер вопроса на листе “Вопросы”.
- Получили ответ, зафиксировали ответ напротив вопроса.
- Сформулировали требование на основе ответа, внесли его на лист “Требования” (например, строка 60). Для требования в строке 55 в столбце “Изменено” указали номер строки 60.
Ну и не забываем статус самого вопроса менять на протяжении всего процесса (можно использовать статусы Открыт, Дан ответ, Решён).
В этом сценарии мы:
Зафиксировали требование, задали вопросы по нему, зафиксировали ответ (пункты 1-4).
Сформулировали новое требование (старое требование стало не актуально — пункт 5).
И теперь можем проследить изменение требования (и даже по датам).
И, конечно, не забываем про возможности фильтрации: по блокам, требованиям, ответственному, статусу и т.д.
В процессе работы на каждом проекте будут возникать свои нюансы работы в таблицах — учитывайте их и вносите в свой сценарий, меняйте таблицы в соответствии с ними. Не забывайте спрашивать себя о том, что вам нужно, чего не хватает сейчас, а потом переспрашивайте — зачем нужно сделать это, какую проблему это решит, облегчит ли или усложнит процессы.
Успехов :)
Автор: arwres
