Поток на процеса на бизнес анализ: Урок стъпка по стъпка

по: Чарлз Мур Чарлз Мур
Hours Обновено

⚡ Умно обобщение

Процесът на бизнес анализ насочва бизнес анализатора от стартирането на проекта до одобряването на изискванията, обхващайки откриване, преглед от заинтересованите страни, анализ на документи, формулиране на проблемни области и структурирано представяне пред ръководители на проекти и спонсори.

  • 🧭 Шест стъпки: Съберете информация за проекта, идентифицирайте заинтересованите страни, анализирайте съответните документи, запишете констатациите, очертайте проблемната област и представете официално изискванията.
  • 👥 Фокус върху заинтересованите страни: Ясен дневен ред, конкретни въпроси и структурирани срещи за преглед поддържат проекта напред track и предотвратяване на изненади в късен етап.
  • 📄 Анализ на документи: Бизнес казусите, процесните диаграми, политиките и законодателството се преглеждат и валидират, тъй като предоставените документи може да са остарели.
  • 🎯 Проблемна област: Разбирането на засегнатите бизнес функции, рискове, политики и блокиращи проблеми превръща суровите открития в целенасочено предложение за промяна.
  • 🛠️ Инструменти: Джира, Сливане, Microsoft Visio, Lucidchart, Jama Connect и Miro подкрепяйте всяка фаза от предизвикването до подписването.
  • ⚠️ Клопки: джъмping към решения, пропуснетеping Валидирането и използването на неясен език остават най-скъпоструващите грешки в процеса на бизнес анализ.
Прочетете повече

Процесът на бизнес анализ

Какви са стъпките, които трябва да следвате в процеса на бизнес анализ?

Следват стъпките, включени в процеса на бизнес анализ. Той ще ви води от първия ден на процеса на бизнес анализ до края на етапа на планиране.

Стъпка 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 епични ситуации, потребителски истории и дефекти в екипите за гъвкава доставка и свързване на изискванията със спринт работата.
  • Confluence, SharePoint и Notion: Съхранявайте плана за бизнес анализ, бележките от срещите, решенията и BRDs в пространство с възможност за търсене, до което заинтересованите страни имат достъп.
  • Microsoft Visio, Lucidchartи draw.io: Начертайте BPMN потоци от процеси, диаграми на случаи на употреба и модели на данни, които правят работните процеси и предаванията видими.
  • Джама Кънект, IBM ВРАТИ, Modern Requirementsи Визурен анализ: Управлявайте изискванията в мащаб с базови линии, tracанализ на осъществимостта и въздействието на регулирани проекти.
  • Miro и стенопис: Улесняване на дистанционното откриване, карта на пътя на потребителяpingи карта на афинитетping семинари в реално време.
  • Балсамик и Figma: Създавайте нискокачествени wireframes и висококачествени прототипи, които валидират предложените екрани с бизнес потребителите, преди да започне разработката.

Малките екипи често започват с Jira, Confluence и LucidchartПо-големите или регулирани програми добавят специален инструмент за управление на изискванията веднъж tracУдобството, базовите линии и одитните следи стават задължителни.

Въпроси и Отговори

Копилотите с изкуствен интелект обобщават интервютата, клъстерират обратната връзка от заинтересованите страни, изготвят потребителски истории от първи етап и маркират противоречиви изисквания. Бизнес анализаторите използват изкуствен интелект, за да ускорят откриването и документирането, като същевременно поддържат...ping приоритизиране, преценка на заинтересованите страни и окончателно одобрение в човешки ръце.

Да. Моделите GitHub Copilot Chat и GPT могат да превърнат план за откриване в първи проект на BRD с цели, обхват и критерии за приемане. Бизнес анализаторът валидира бизнес съответствието, редактира двусмисления език и получава одобрението на заинтересованите страни, преди екипът да се ангажира с обхвата.

Бизнес анализът обхваща целия жизнен цикъл на проекта, включително стратегия, изисквания и оценка на решенията. Анализът на бизнес процесите се фокусира по-специално върху моделирането, измерването и подобряването на текущите работни процеси и е една от техниките, използвани в рамките на по-широк ангажимент за бизнес анализ.

В Agile проектите бизнес анализаторът си партнира със собственика на продукта, за да прецизира натрупаните задачи, пише потребителски истории с критерии за приемане, присъединява се към планирането и прегледите на спринтове и актуализира хранилището с изисквания за всеки спринт, вместо да създава една голяма предварителна спецификация.

BABOK е сборникът от знания за бизнес анализ, публикуван от IIBA. Той групира работата по бизнес анализ в шест области на знанието – планиране, извличане на данни, жизнен цикъл на изискванията, анализ на стратегията, анализ и проектиране на изискванията и оценка на решенията – които оформят процеса.

Изисквания TracМатрицата на ефективността свързва всяко изискване с неговия източник, елемент от дизайна и тестовете, които го проверяват. Тя дава на екипа доказателство, че не е било отпаднало изискване и ви позволява бързо да оцените въздействието на заявка за промяна.

Регистрирайте всяка заявка за промяна с нейната бизнес обосновка и въздействие върху разходите, графика и качеството. Насочете я през съвет за контрол на промените или собственика на продукта за вземане на решение, актуализирайте хранилището с изисквания и tracматрица на ефективността и съобщаване на резултата на всяка заинтересована страна.

Използвайте формата „Системата трябва...“ с измерим критерий за приемане. Заменете неясните термини като „бърз“ или „лесен за ползване“ с метрика, праг и метод за проверка. Всяко изискване трябва да съответства на поне един тестов случай в tracматрица на ефективността.

Обобщете тази публикация с: