Сбор требований: пример из реальной практики

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


Как требования собирались в этой организации ранее:

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

1) Изначально ставится  цель: автоматизировать конкретный бизнес-процесс. Бизнес-аналитик в ходе своей работы не смотрит на картину целиком, ведь есть вероятность, что автоматизация одного бизнес-процесса сильно повлияет на другие процессы;

1) Выявляется лишь 1/3 (если не меньше) всех функциональных требований. Общение идёт лишь с одним представителем одного из классов пользователей, который неизбежно смотрит на проблему узко, через призму исключительно своей работы;

2) Совсем не учитываются не функциональные требования, которые могли бы повысить юзабилити разрабатываемой системы;

3) Полностью отсутствует "погружение" аналитика в сферу жизни пользователей: не практикуются выезды на место, тестирование процессов в реальных условиях, оценка психотипов и привычек пользователей. Упускаются многие неявные требования, которые видны только при живом погружении, сами пользователи их никогда не озвучат;

4) Используется однобокий подход к визуализации требований - только через workflow даиграммы, которые не всегда несут нужную информационную нагрузку.

Как сбор требований происходит теперь

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

Если вы заметили, в нашей схеме требования первоначально фиксируются в облачном сервисе. И я настаиваю, что это важно. Вы поговорили с пользователем и скинули в облачный сервис всю ценную информацию (я делаю это в Evernote), Мозгу нужно время, чтобы переварить услышанное. Рабочий день закончился, вы дома  смотрите интересное кино и вдруг - бац - вы понимаете, что в ходе общения с пользователем сегодня утром упустили из виду одно неявное требование. Тут же открываете Evernote, записываете эту информацию к заметке. Прошли выходные, вы вновь на рабочем месте - и перед вам вся полная информация для анализа требований. Ничего не потерялось. Всё под рукой. Кроме того, информацией в таком виде всегда легко поделиться с коллегами.

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