Потік процесу бізнес-аналізу: покроковий посібник
⚡ Розумний підсумок
Процес бізнес-аналізу супроводжує бізнес-аналітика від початку проекту до затвердження вимог, охоплюючи виявлення, перевірку зацікавленими сторонами, аналіз документів, формулювання проблемних областей та структуровану презентацію для керівників проектів та спонсорів.
Які кроки необхідно виконати в процесі бізнес-аналізу?
Нижче наведено етапи процесу бізнес-аналізу. Він допоможе вам від процесу бізнес-аналізу першого дня до кінця етапу планування.
Крок 1) Зберіть всю інформацію про проект
Це Бізнес-аналітик відповідальність за збір усіх деталей, пов’язаних із проектом, шляхом ставлення запитань людям, пов’язаним із ним (керівнику проекту, спонсору проекту, функціональному менеджеру або власнику бізнесу).
Зібрана інформація повинна охоплювати такі теми:
- Обсяг та межі проекту
- Поточні фактори, що впливають на організацію
- Ризик і обмеження проекту
- Більш широкий організаційний контекст
Визначте зацікавлених сторін, які активно беруть участь у проекті. Це також гарний момент для проведення Аналіз потреб зацікавлених сторін.
Після збору цієї інформації проаналізуйте свою роль у проекті та складіть контрольний список, який ви як бізнес-аналітик можете включити, наприклад:
- Які уроки з попереднього досвіду ви можете застосувати до поточного проєкту
- Документація та планування, необхідні для поточного проекту
- Обговорення можливих результатів проекту із зацікавленими сторонами
- Визначте учасників, залучених до проєкту
- Організуйте зустріч із клієнтом та зацікавленими сторонами, коли потрібні додаткові поради
- Очікувані результати та формат, у якому вони мають бути надані
- Існуючу документацію, з якою ви можете ознайомитися, щоб краще зрозуміти проєкт
- Методологія (Agile або Waterfall), що буде найбільш підходящим для проекту
Крок 2) Визначте зацікавлені сторони та створіть RevЗустріч
На другому кроці налаштуйте оглядове засідання з керівником проекту, зацікавленими сторонами та членами команди. Нечіткий порядок денний часто призводить до провалу проекту.
- Будьте конкретними щодо того, чого ви очікуєте від проєкту.
- Залучіть до зустрічі керівника проєкту, зацікавлених сторін та членів команди і поставте запитання, пов'язані з проєктом.
- Якщо ви працюєте над абсолютно новим проектом, зверніться до керівника проекту або контактної особи, яка раніше працювала в цій галузі.
Крок 3) Проаналізуйте всі документи, що стосуються проекту
Далі, належним чином аналіз всі документи, що стосуються проекту, такі як:
- Документація бізнес-процесів
- Документи бізнес- та системних вимог
- Бізнес кейси
- Діаграми та блок-схеми
- Плани проекту
- Організаційна схема
- Стратегічні документи та бізнес-плани
- Політика та законодавство
Виявити будь-яку інформацію, приховану в документі з бізнес-вимогами, та tracпрогалини в чинних системах, процесах, процедурах та операціях. Наданий вам документ може бути застарілим, тому перевірте кожен виявлений факт, перш ніж вважати його остаточним.
Крок 4) Запишіть усі факти та інформацію, які ви виявили
Під час дослідження та аналізу ви виявите багато корисних фактів про проект, які потребують змін або впровадження. Запишіть кожен висновок, щоб його можна було переглянути пізніше.
- Бізнес-вимоги, включаючи вимоги до звітності
- Бізнес-процеси та системи підтримки
- Функціональні та нефункціональні вимоги
- Проблеми та ризики, які зараз впливають на проект
Крок 5) Зрозумійте проблемну область
На цьому етапі ви маєте чітке розуміння проекту, тому можете визначити проблемну областьВам потрібно з'ясувати:
- На яку бізнес-функцію це вплине
- Ризики та фактори, що впливають на бізнес
- Політики та обмеження, які впливають на проект
- Цінності, що визначають рівень важливості проекту
- Системи, які наразі підтримують бізнес-діяльність
- Документи, що підсумовують проблемну область, наприклад, річний звіт
- Проблеми, які наразі заважають бізнесу досягти бажаних результатів
- Чи впливає запропонована зміна на проблемну область
Крок 6) Представлення бізнес-вимог
Після того, як ви зібрали всі бізнес-вимоги та зрозуміли проблемну область, наступним кроком буде представлення бізнес-вимог зацікавленим сторонам або керівнику проекту. Загальні методи презентації включають:
- Таблиця або таблиця
- Діаграма або графік
- Прототип або симуляція
- Шаблон структурованого тексту або структуроване речення
Глосарій термінів, що дає короткий огляд процесу бізнес-аналітика:
- Мета: Визначає мету діяльності з аналізу бізнесу, необхідної для запропонованої ініціативи
- Сфера застосування: Визначає результати, які включено та виключено
- Першопричина: Визначає першопричини виявлених проблем
- Поточний стан: Визначає проблему, яка викликає потребу у змінах
- Заплановані заходи: Визначає причину діяльності, результати та дати доставки
- План взаємодії із зацікавленими сторонами: Надає огляд процесу взаємодії із зацікавленими сторонами
- Управління якістю: Описує заходи, які забезпечать якість результатів проекту
- Target стан: Визначає, як будуть вирішені виявлені критичні проблеми
Короткі поради для бізнес-аналітика
- Ставте запитання на зустрічах
- Будьте готові до зустрічі із зацікавленими сторонами або перегляду
- Бути адаптивним до змін та нового досвіду
- Керуйте очікуваннями
- Відповідайте на відгуки
Загальні результати, отримані в процесі бізнес-аналізу
Кожен процес бізнес-аналізу залишає після себе набір документів, які можуть використовувати команда проекту, спонсори та аудитори. tracе назад до. Послідовне створення цих результатів робить процес повторюваним у різних проектах.
- План бізнес-аналізу: Описує підхід, часові рамки та план залучення зацікавлених сторін для аналітичної роботи.
- Реєстр зацікавлених сторін: Перелічує кожну зацікавлену сторону разом з її роллю, впливом, очікуваннями та бажаним каналом комунікації.
- Документ з вимогами до бізнесу (BRD): Фіксує загальні бізнес-потреби, цілі та критерії успіху мовою, зрозумілою для зацікавлених сторін, які не є технічними фахівцями.
- Функціональні та нефункціональні вимоги: Перетворіть BRD на поведінку системи, атрибути якості та обмеження, на яких розробники та тестувальники можуть будувати.
- Моделі процесів та варіанти використання: Покажіть поточний та майбутній стан робочих процесів за допомогою діаграм BPMN, варіантів використання UML або діаграм діяльності.
- Вимога TracМатриця доцільності (RTM): Пов'язує кожну вимогу з її джерелом, елементом дизайну та тестами, які її перевіряють.
- Журнал запитів на зміни: Фіксує кожну зміну обсягу з її впливом, рішенням та особою, яка її затвердила, щоб журнал аудиту залишався неушкодженим.
Ці результати слід зберігати у спільному репозиторії, такому як Confluence, SharePoint або спеціалізованому інструменті керування вимогами, щоб кожен член команди працював з однією й тією ж версією.
Типові помилки, яких слід уникати в процесі бізнес-аналізу
Навіть досвідчені бізнес-аналітики потрапляють у ті ж пастки під тиском постачання. Звертаючи увагу на наступні помилки, ви запобігаєте більшості переробок та несподіванок щодо обсягу робіт пізніше в проекті.
- Джумping до рішення перед формулюванням проблеми: Пропонування системи, інструменту чи функції до того, як буде зрозуміло першопричину, призводить до дорогої переробки та рішення, яке не вирішує реальну потребу бізнесу.
- Пропускатиping перевірка зацікавлених сторін: Вимоги до запису без схвалення людей, які використовуватимуть систему, створюють прогалини, які виявляються лише під час тестування користувачами.
- Обробка вимог як статичних: Потреби бізнесу змінюються під час проекту. Бізнес-аналітик, який не підтримує репозиторій вимог та tracМатриця спроможності незабаром втрачає контроль над обсягом.
- Надмірне документування замість співпраці: Створення 200-сторінкового BRD, який ніхто не читає, гірше, ніж короткий документ у поєднанні з регулярними робочими сесіями та візуальними моделями.
- Зосереджуючись лише на щасливому шляху: Пропуск випадків винятків, обробки помилок та нефункціональних вимог переносить дефекти у продакшн та підриває довіру користувачів.
- Робота в силосі: Аналіз вимог без розробників, тестувальників та операційних команд не враховує ризики доцільності та обмеження подальшого розвитку, які були б виявлені під час спільного огляду.
- Використання нечіткої або двозначної мови: Такі слова, як «зручний для користувача», «швидкий» або «гнучкий» без вимірюваних критеріїв прийнятності створюють розбіжності, які проявляються лише тоді, коли функція демонструється.
Популярні інструменти, що підтримують процес бізнес-аналізу
Правильний набір інструментів підтримує кожен етап процесу бізнес-аналізу, від виявлення запитів до їх узгодження. Більшість команд поєднують легкий інструмент для роботи з беклогами, інструмент моделювання та платформу документації.
- Джира та Azure DevOps: Track-епіки, історії користувачів та дефекти в Agile-командах розробки та пов'язати вимоги зі спринт-роботою.
- Злиття, SharePoint та Notion: Зберігайте план бізнес-аналізу, нотатки зустрічей, рішення та BRD у просторі з можливістю пошуку, до якого мають доступ зацікавлені сторони.
- Microsoft Visio, Lucidchart, та draw.io: Створюйте потоки процесів BPMN, діаграми варіантів використання та моделі даних, які роблять робочі процеси та передачі завдань видимими.
- Джама Коннект, IBM ДВЕРІ, Modern Requirements, та Візуар: Керуйте вимогами в масштабі за допомогою базових планів, tracаналіз доцільності та впливу для регульованих проектів.
- Miro та фреска: Сприяти віддаленому виявленню, карта шляху користувачаpingта карта спорідненостіping семінари в режимі реального часу.
- Бальзамік та Figma: Створюйте низькоточні макетні схеми та високоточні прототипи, які перевіряють запропоновані екрани з бізнес-користувачами перед початком розробки.
Невеликі команди часто починають з Jira, Confluence та LucidchartБільші або регульовані програми додають спеціальний інструмент управління вимогами один раз tracспрощеність, базові показники та журнали аудиту стають обов'язковими.

