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

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


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

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

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

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

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

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

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

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

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

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

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

10 простых правил при общении с бизнес-аналитиком

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

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

Что следует учитывать при общении с бизнес-аналитиком:

#1 Бизнес-аналитик в порыве творчества может забыться и начать использовать специфическую терминологию. Не стесняйтесь напомнить, что он должен говорить на понятном Вам языке.

#2 Бизнес-аналитик не всегда знает специфику Вашей работы, но очень хочет о ней узнать. Общение будет комфортным, если вы кратко и понятно опишите аналитику свои должностные обязанности, которые хотелось бы автоматизировать

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

#4 Если вы вспомнили что-то важное уже после согласования требований, обязательно сообщите об этом аналитику. Ему очень важно, чтобы программное обеспечение отвечало вашим потребностям и нуждам.

#5 Бизнес-аналитик – профессионал и друг, который может подсказать вам интересный путь решения ваших профессиональных проблем

#6 Бизнес-аналитика интересует не только функционал разрабатываемого для Вас программного обеспечения. Он хочет, чтобы на выходе вы получили приятный в использовании продукт. Обязательно расскажите аналитику о своих требованиях в области дизайна и удобства использования будущей программы

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

#8 Чем быстрее вы согласуете требования к программному обеспечению – тем быстрее получите толкового помощника в виде работающего программного продукта

#9 Разработчики не всемогущи, но сделают всё, что возможно

#10 Для удобства обсудите с бизнес-аналитиком критерии приёмки программного обеспечения. Это позволит вам точно знать, что вы получите то, что хотите