Вам вероятно приходилось работать на различных аналитических проектах: где-то с самого начала, а когда-то вы присоединялись к ним где-то посередине, или же, когда подводились их итоги. Единственный вопрос, которым вы точно задавались и который всегда объединяет все эти и последующие ваши аналитические проекты – как правильнее их начинать?
Возможно, вы уже искали на него ответ в написанных сложным языком статьях и руководствах, но не нашли универсального рецепта. Ведь не существует конкретного всеобъемлющего свода правил, которые следует соблюдать всегда. Но точно можно сказать, что вашу работу значительно упростят следующие наиболее важные аспекты, на которые следует обратить внимание:
1. Зафиксируйте всех заинтересованных в проекте лиц (стейкхолдеров) – неважно, в какого рода проекте вы работаете, вы всегда должны знать о всех его стейкхолдерах. В проекте может быть множество стейкхолдеров, и чтобы определить их, вы можете создать соответствующий документ для анализа. Это может быть простой лист Excel, в котором вы перечислите их имена, должности, отделы, роль в проекте и любые другие важные детали, специфичные для вашего проекта. Такой документ будет полезен на протяжении всего жизненного цикла проекта и еще долго после того.
2. Теперь у вас есть список всех ваших заинтересованных сторон, а что дальше? Не все стейкхолдеры одинаково важны или влиятельны в проекте. К чьему мнению следует больше прислушиваться? Чтоб определить это вы можете создать матрицу заинтересованных сторон, в которой сопоставить стейкхолдеров с их ролями на проекте:
o Владелец проекта - управляет проектом / владеет проблемой, отвечает за его результаты. Очень влиятелен.
o Заказчик – формулирует задачу и выступает в качестве утверждающего её решения. Обычно принимает результаты работы.
o Группа поддержки – ваши подчиненные или коллеги, они предоставляют ресурсы или оказывают помощь, но не могут влиять на управление проектом.
o Консультанты, эксперты – хорошо разбираются в зоне своей ответственности и в соответствующей предметной области, к таким часто приходится обращаться за специализированной помощью.
o Информируемые – их достаточно держать в курсе происходящего на проекте.
3. Примите решениях о методах получения информации о требованиях к проекту. Таковых существует множество, например, мозговой штурм, интервью, семинары и т.д. В силу ограниченности располагаемых ресурсов на проекте, особенно времени вовлеченных в него людей, настал лучший момент заглянуть в матрицу заинтересованных сторон, чтобы не забыть ни о ком важном и подобрать соответствующий инструмент для коммуникации. Например, мнение директора по производству может быть значимым для конкретного проекта и описания текущего состояния AS IS, но, возможно, его будет недостаточно для полного формирования целевого представления TO BE. В таком случае вы возьмете у него интервью, чтоб понять его точку зрения, опасения и аргументацию, но не будете пытаться встроиться в его перегруженный график и пригласить на продолжительный мозговой штурм. Обязательно уточняйте доступность, уровень влияния, должность, наличие интереса к проекту у стейкхолдеров, прежде чем выбирать метод получения информации об их требованиях к проекту.
4. Сделайте домашнюю работу. Не все проекты начинаются с приглашения заинтересованных сторон на личные встречи и общие собрания, с рассылки опросных листов или организации семинаров. На самом деле, большинство из аналитических проектов, если не все, где запланировано развитие уже существующих бизнес-процессов (например, цифровая трансформация) не начинаются с нуля. Как правило, такие AS IS-процессы уже устоялись и, вероятно, задокументированы. Вы можете найти описания, регламенты и множество сопутствующих процессу документов, формирующие представления о том, как они работают сейчас. Как бизнес-аналитик внимательно и критически изучите бизнес-правила, собранные документы и соответствующие информационные потоки. Не пропускайте деталей, выявляйте противоречия, уточняйте неоднозначную информацию, если же вы ограничитесь своими предположениями, то это может вам в последующем выйти боком.
5. Вы собрали требования и уверены в их содержании? Отлично. Теперь пора их проанализировать. Анализ подобен тому, что выполнялся на предыдущем шаге, который может иногда и пропускаться, но это упражнение носит обязательный характер. Анализ требований включает в себя выявление любых аномалий, закрепление предположений и ограничений на проекте, декомпозицию требований на уровень конкретной функциональности, группировку требований и уточнение того, что важно на самом деле, а что нет. Чем больше вы потратите сил и времени на этом этапе, тем меньше вас будет ждать сюрпризы в дальнейшем ходе проекта.
6. Настал черед определения приоритетности требований. У вас есть полная картина с проанализированными и задокументированными требованиями, а теперь в зависимости от задач проекта и списка заинтересованных сторон, вам может потребоваться выбрать из требований более приоритетные. В таком случае вы можете применить часть гибкой методологии Agile, в которой функциональные требования к продуктам/приложениям реализуются итерационно. Несмотря на то, что у вас есть заказчики / владельцы проекта, вы в качестве бизнес-аналитика должны владеть полной картиной, знать все требования и понимать их влияние на бизнес. Продуманный план реализации требований проекта сравним по значимости с самим проектом.
7. Проверьте себя, как вы можете проследить историю изменений требований до проекта и в ходе его реализации. Когда проект будет подходить к концу, и будут тестироваться его результаты, вы вероятно столкнетесь с тем, что результат не будет совпадать с озвученными ранее требованиями. На такой случай вы как бизнес-аналитик должны быть способны обнародовать историю изменений этих требований вплоть до первоисточника. Особенно это актуально в постоянно изменяющейся сфере ИТ, или в случаях, когда кто-то другой подключится к вашей работе и вносит в нее изменения. Таким образом, хорошо задокументированные и прослеживаемые требования сэкономят время и энергию, и, конечно же, предупредят разочарование, которое мы обычно наблюдаем, просматривая неполные и двусмысленные требования от других.
Источник: адаптированный перевод https://www.batimes.com/articles/how-to-get-started-with-business-analysis.html