비즈니스 분석 프로세스 흐름: 단계별 튜토리얼
찰스 무어
⚡ 스마트 요약
비즈니스 분석 프로세스 흐름은 프로젝트 시작부터 요구사항 승인에 이르기까지 비즈니스 분석가의 전반적인 과정을 안내하며, 요구사항 파악, 이해관계자 검토, 문서 분석, 문제 영역 정의, 그리고 프로젝트 관리자 및 스폰서에 대한 체계적인 프레젠테이션을 포함합니다.
비즈니스 분석 프로세스에서 따라야 할 단계는 무엇입니까?
다음은 비즈니스 분석 프로세스에 포함된 단계입니다. 1일차 비즈니스 분석 프로세스부터 계획 단계의 끝까지 안내해 드립니다.
1단계) 프로젝트에 대한 모든 정보 수집
그것은이다 비즈니스 분석가 프로젝트와 관련된 사람들(프로젝트 관리자, 프로젝트 스폰서, 기능 관리자 또는 사업 책임자)에게 질문하여 프로젝트와 관련된 모든 세부 정보를 수집할 책임이 있습니다.
수집된 정보는 다음 주제들을 포함해야 합니다:
- 프로젝트 범위 및 경계
- 현재 조직에 영향을 미치는 요인
- 프로젝트 위험 및 제약
- 더 넓은 조직적 맥락
프로젝트에 적극적으로 참여하는 이해관계자를 파악하십시오. 이 시점은 또한 다음과 같은 조치를 취하기에 좋은 시기입니다. 이해관계자 요구사항 분석.
이 정보를 수집한 후, 프로젝트에서 자신의 역할을 분석하고 비즈니스 분석가로서 포함할 수 있는 체크리스트를 작성하세요. 예를 들면 다음과 같습니다.
- 이전 경험에서 얻은 교훈 중 현재 프로젝트에 적용할 수 있는 것은 무엇입니까?
- 현재 프로젝트에 필요한 문서 및 계획
- 이해관계자들과 프로젝트의 예상 결과에 대해 논의하기
- 프로젝트에 참여하는 구성원을 확인하십시오.
- 추가적인 의견이 필요할 경우 고객 및 이해관계자와의 회의를 마련하십시오.
- 예상되는 결과물과 요구되는 형식
- 기존 문서를 검토하시면 프로젝트를 더 잘 이해하실 수 있습니다.
- 방법론 (애자일 또는 폭포수프로젝트에 가장 적합한 (
2단계) 이해관계자를 파악하고 회의를 준비합니다. Review 미팅
두 번째 단계에서는 설정을 진행합니다. 검토 회의 프로젝트 관리자, 이해관계자 및 팀원들과 함께 진행해야 합니다. 불분명한 의제는 종종 프로젝트 실패로 이어집니다.
- 프로젝트에서 기대하는 바를 구체적으로 명시하십시오.
- 회의에 프로젝트 관리자, 이해관계자 및 팀원을 참여시키고 프로젝트와 관련된 질문을 하십시오.
- 완전히 새로운 프로젝트를 진행 중이라면, 해당 분야에서 이전에 근무한 경험이 있는 프로젝트 관리자나 담당자에게 문의하십시오.
3단계) 프로젝트 관련 모든 문서를 분석합니다.
다음으로, 제대로 분석하다 프로젝트 관련 모든 문서(예: ...)
- 비즈니스 프로세스 문서화
- 비즈니스 및 시스템 요구 사항 문서
- 비즈니스 사례
- 차트 및 흐름도
- 프로젝트 계획
- 조직도
- 전략 문서 및 사업 계획
- 정책 및 법률
비즈니스 요구사항 문서에 숨겨진 정보를 모두 찾아내십시오. trac현재 시스템, 프로세스, 절차 및 운영과의 차이점이 있습니다. 제공된 문서는 최신 정보가 아닐 수 있으므로, 최종본으로 간주하기 전에 발견한 모든 사실을 검증하십시오.
4단계) 발견한 모든 사실과 정보를 기록하세요
조사 및 분석 과정에서 프로젝트에 대해 변경하거나 구현해야 할 유용한 사실들을 많이 발견하게 될 것입니다. 나중에 검토할 수 있도록 모든 발견 사항을 기록해 두십시오.
- 보고 요구 사항을 포함한 비즈니스 요구 사항
- 비즈니스 프로세스 및 지원 시스템
- 기능적 요구사항과 비기능적 요구사항
- 현재 프로젝트에 영향을 미치는 이슈 및 위험
5단계) 문제 영역 이해하기
이 시점쯤 되면 프로젝트에 대해 확실히 이해했을 테니, 이제 문제 도메인 식별당신은 다음을 알아내야 합니다:
- 어떤 비즈니스 기능이 영향을 받을까요?
- 사업에 영향을 미치는 위험 및 요인
- 프로젝트에 영향을 미치는 정책 및 제약
- 프로젝트의 중요도를 결정하는 가치
- 현재 비즈니스 활동을 지원하는 시스템
- 문제 영역을 요약한 문서, 예를 들어 연례 보고서
- 현재 사업체가 원하는 결과를 달성하는 데 방해가 되는 문제점들
- 제안된 변경 사항이 문제 영역에 실질적인 변화를 가져오는지 여부
6단계) 비즈니스 요구사항을 제시합니다.
모든 비즈니스 요구사항을 수집하고 문제 영역을 파악했다면 다음 단계는 다음과 같습니다. 비즈니스 요구사항 제시 이해관계자 또는 프로젝트 관리자에게 발표할 때 사용하는 일반적인 프레젠테이션 기법은 다음과 같습니다.
- 테이블 또는 스프레드시트
- 다이어그램 또는 그래프
- 프로토타입 또는 시뮬레이션
- 구조화된 텍스트 템플릿 또는 구조화된 문장
비즈니스 분석가 프로세스를 빠르게 개괄적으로 보여주는 용어집:
- 목적 : 제안된 이니셔티브에 필요한 비즈니스 분석 활동의 목적을 정의합니다.
- 범위: 포함 및 제외되는 결과물을 정의합니다.
- 근본 원인: 파악된 문제의 근본 원인을 정의합니다.
- 현재 상태: 변화의 필요성을 야기하는 문제를 정의합니다.
- 계획된 활동: 활동 이유, 결과물, 배송 날짜를 정의합니다.
- 이해관계자 참여 계획: 이해관계자 참여 프로세스에 대한 개요를 제공합니다.
- 품질 관리: 프로젝트 결과물의 품질을 보장하는 활동들을 설명합니다.
- Target 조건: 파악된 주요 문제들을 어떻게 해결할 것인지 정의합니다.
비즈니스 분석가를 위한 빠른 팁
- 회의에서 질문하기
- 이해관계자 회의 또는 검토 전에 준비하십시오.
- 변화와 새로운 경험에 적응할 수 있어야 합니다.
- 기대치 관리
- 피드백에 응답
비즈니스 분석 과정에서 생성되는 일반적인 산출물
모든 비즈니스 분석 프로세스는 프로젝트 팀, 스폰서 및 감사자가 활용할 수 있는 일련의 문서를 남깁니다. trac다시 돌아가서, 이러한 결과물을 일관되게 생산하는 것이 프로젝트 전반에 걸쳐 프로세스를 반복 가능하게 만드는 핵심입니다.
- 사업 분석 계획: 분석 작업에 대한 접근 방식, 일정 및 이해관계자 참여 계획을 설명합니다.
- 이해관계자 등록부: 이해관계자 전체와 그들의 역할, 영향력, 기대치, 선호하는 의사소통 채널을 나열합니다.
- 비즈니스 요구 사항 문서(BRD): 고수준의 비즈니스 요구사항, 목표 및 성공 기준을 비기술적 이해관계자들이 이해할 수 있는 언어로 표현합니다.
- 기능적 요구사항 및 비기능적 요구사항: BRD를 개발자와 테스터가 활용할 수 있는 시스템 동작, 품질 속성 및 제약 조건으로 변환합니다.
- 프로세스 모델 및 사용 사례: BPMN 다이어그램, UML 유스케이스 또는 활동 다이어그램을 사용하여 현재 상태 및 미래 상태 워크플로를 보여주세요.
- 요구조건 니즈 TracRTM(실효성 매트릭스): 모든 요구사항을 해당 요구사항의 출처, 설계 요소 및 이를 검증하는 테스트와 연결합니다.
- 변경 요청 기록: 감사 추적을 위해 범위 변경 사항, 그 영향, 결정 사항 및 승인자를 모두 기록합니다.
이러한 결과물은 모든 팀 구성원이 동일한 버전을 사용할 수 있도록 Confluence, SharePoint 또는 전용 요구사항 관리 도구와 같은 공유 저장소에 저장해야 합니다.
비즈니스 분석 과정에서 피해야 할 일반적인 실수
경험이 풍부한 비즈니스 분석가조차도 마감 압박 속에서 똑같은 함정에 빠지곤 합니다. 다음의 실수들을 주의하면 프로젝트 후반에 발생하는 대부분의 재작업과 예상치 못한 범위 변경을 예방할 수 있습니다.
- 점ping 문제를 정의하기 전에 해결책을 먼저 찾는 것: 근본 원인을 파악하기 전에 시스템, 도구 또는 기능을 제안하면 비용이 많이 드는 재작업이 발생하고 실제 비즈니스 요구 사항을 해결하지 못하는 솔루션으로 이어집니다.
- 건너뛰기ping 이해관계자 검증: 시스템 사용자가 될 사람들의 승인 없이 기록 요건을 정하면 사용자 수용 테스트 중에만 드러나는 문제점이 발생합니다.
- 요구사항을 고정된 것으로 취급하기: 프로젝트 진행 중에 비즈니스 요구사항이 변화합니다. 요구사항 저장소를 관리하지 않는 비즈니스 분석가는 이러한 변화에 제대로 대응하지 못할 수 있습니다. trac가능성 매트릭스는 곧 범위에 대한 통제력을 잃게 됩니다.
- 협업 대신 과도한 문서화: 아무도 읽지 않는 200페이지짜리 BRD를 만드는 것은, 짧은 문서와 정기적인 워크숍, 시각적 모델을 함께 활용하는 것보다 더 나쁩니다.
- 행복한 길에만 집중하기: 예외 처리, 오류 처리 및 비기능적 요구 사항이 누락되면 결함이 실제 제품에 배포되어 사용자 신뢰를 저해합니다.
- 고립된 환경에서 일하는 것: 개발자, 테스터 및 운영팀 없이 요구사항을 분석하면 공동 검토를 통해 파악할 수 있는 실현 가능성 위험과 후속 제약 조건을 놓치게 됩니다.
- 모호하거나 애매한 표현을 사용하는 것: 측정 가능한 수용 기준 없이 "사용자 친화적", "빠른", "유연한"과 같은 단어를 사용하면 해당 기능이 시연될 때에만 의견 불일치가 발생합니다.
비즈니스 분석 프로세스를 지원하는 인기 도구
적절한 도구 세트는 요구사항 도출부터 최종 승인까지 비즈니스 분석 프로세스의 모든 단계를 지원합니다. 대부분의 팀은 가벼운 백로그 도구, 모델링 도구 및 문서화 플랫폼을 함께 사용합니다.
- 지라와 Azure DevOps : Trac애자일 개발 팀 전반에 걸쳐 k개의 에픽, 사용자 스토리 및 결함을 관리하고 요구 사항을 스프린트 작업과 연결합니다.
- 컨플루언스, 셰어포인트, 그리고 Notion: 비즈니스 분석 계획, 회의록, 결정 사항 및 BRD를 이해 관계자가 접근할 수 있는 검색 가능한 공간에 저장하십시오.
- Microsoft Visio, Lucidchart그리고 draw.io: 워크플로와 인수인계를 시각화하는 BPMN 프로세스 흐름도, 유스케이스 다이어그램 및 데이터 모델을 작성하세요.
- 자마 커넥트, IBM 문, Modern Requirements그리고 Visure: 기준선을 활용하여 대규모 요구사항을 관리하세요. trac규제 대상 프로젝트에 대한 타당성 및 영향 분석.
- Miro 그리고 벽화: 원격 탐색 및 사용자 여정 지도 작성을 지원합니다.ping그리고 친화도 맵ping 실시간으로 진행되는 워크숍.
- 발사믹과 Figma: 개발 시작 전에 비즈니스 사용자를 통해 제안된 화면을 검증할 수 있도록 저해상도 와이어프레임과 고해상도 프로토타입을 제작합니다.
소규모 팀은 흔히 Jira, Confluence 등으로 시작합니다. Lucidchart규모가 크거나 규제를 받는 프로그램의 경우, 요구사항 관리 전용 도구를 한 번 추가합니다. trac안정성, 기준선 및 감사 추적이 필수 사항이 됩니다.
