Как запускать проекты по бизнес-аналитике?

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

1. Стейкхолдеры

Зафиксируйте всех заинтересованных в проекте лиц (стейкхолдеров)— неважно, в проекте какого рода вы работаете, вы всегда должны знать о всех его заинтересованных лицах. В проекте может быть множество стейкхолдеров, и чтобы определить их, вы можете создать соответствующий документ для анализа. Это может быть простой лист Excel, в котором вы перечислите их имена, должности, отделы, роль в проекте и любые другие важные детали, специфичные для вашего проекта. Такой документ будет полезен на протяжении всего жизненного цикла проекта и еще долго после этого.

2. Матрица заинтересованных сторон

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

• Заказчик — формулирует задачу и выступает в качестве утверждающего её решения. Обычно принимает результаты работы.
• Группа поддержки — ваши подчиненные или коллеги, они предоставляют ресурсы или оказывают помощь, но не могут влиять на управление проектом.
• Консультанты, эксперты — хорошо разбираются в зоне своей ответственности и в соответствующей предметной области, к таким часто приходится обращаться за специализированной помощью.
• Информируемые — их достаточно держать в курсе происходящего на проекте.

3. Требования к проекту

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

4.Подготовка

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

5. Анализ

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

6. Приоритеты

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

7. История изменений

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