Пошаговая инструкция для бизнес-аналитика (часть 2)

Продолжим описание последовательности действий бизнес-аналитика, начатое в первой части этой статьи.

Итак:

1. Мы выявили всех стейкхолдеров.

2. Провели опросы, постарались выявить «боли» каждой роли.

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

Учти все, согласуй во всеми, «продай» лучший вариант для команды - звучит как минимум непросто. Да, хороший аналитик отличается тем, что не просто соглашается реализовать то, чего хочет заказчик, а предлагает варианты и умеет убедить заказчика, что один из вариантов наиболее подходящий, учитывая потребности всех сторон.

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

Итак, список бизнес-требований сформулирован и согласован. Далее необходимо его детализировать и описать как должен с точки зрения бизнеса проходить процесс. Отрисовать процесс можно в разном виде – обычной блок-схемы, в нотации IDEF0, BPMN – в разных компаниях могут быть свои требования и традиции, по сути это не так важно, главное не забыть нарисовать и описать все альтернативные сценарии и ограничения в сценариях. Постепенно детализируя описание целевого бизнес-процесса аналитик разбивает его на отдельные функции, формируя функциональные требования, которые станут основой технического задания.

Параллельно с этим, как уже говорилось в наших предыдущих статьях, необходимо собрать нефункциональные требования к будущему продукту.
Минимальный список нефункциональных требований:

· Количество пользователей системы.

· Максимальное количество обращений к системе в секунду.

· Максимальное время отклика системы на действия пользователя при определенной скорости передачи данных (например, при 100 Мбит/сек).

· Время наработки на отказ (Mean time between failures (MTFB)).

· Время восстановления после сбоев.

📌 Определить стейкхолдеров

📌 Выявить "боли" каждого стейкхолдера

📌 Составить общий список требований всех стейкхолдеров и выявить в нем противоречия

📌 Устранить противоречия в списке требований

📌 Согласовать итоговый список со всеми стейкхолдерами

📌 Описать целевой бизнес-процесс на основании собранных требований (не забыть про альтернативные сценарии и ограничения)

📌 Нарисовать схемы целевого бизнес-процесса

📌 Декомпозировать целевой бизнес-процесс до отдельных функций, описать функциональные требования

📌 Собрать нефункциональные требования

Уф, выполнить в реальной работе все эти шаги было непросто! На нашем телеграм-канале можно получить в подарок первый стикер нашего будущего аналитического стикерпака