답변.
변경 관리는 비즈니스 분석가의 주요 작업 중 하나입니다. 프로젝트 진행 중에 요구 사항이 자주 수정되기 때문입니다. 변경 관리(change management)에는 다음이 포함됩니다:
- 변경 영향 평가. 분석가는 새로운 요청이 비즈니스 및 기술 아키텍처에 미치는 결과를 평가합니다.
- 변경 형식화. 모든 변경 사항은 원래 요구 사항과의 명확한 연결로 문서화되어야 합니다.
- 정보 제공 및 조정. 변경 사항을 통보할 모든 이해 관계자를 정의하고 이들과 조율합니다.
- 구현 및 모니터링. 수행된 수정 사항을 모니터링하고 변경 후 개선 또는 위험을 분석합니다.
주요 특징:
- 변경 사항 추적을 위해 규정(예: Change Request)을 사용하는 것이 중요합니다.
- 각 요청은 결과 평가 및 승인을 거쳐야 합니다.
- 변경 사항의 명확한 이력을 추적하기 위해 변경 기록(version control)을 유지해야 합니다.
함정 질문.
고객의 확인 없이 팀과 직접적으로 변경을 협의할 수 있습니까?
아니요. 모든 변경 사항은 고객과 합의해야 하며, 이는 갈등과 오해를 피하는 데 필요합니다.
변경이 항상 제품을 개선합니까?
아니요. 변경은 일정과 비용을 증가시킬 수 있으며, 때로는 제품을 악화시킬 수 있습니다. 항상 결과에 대한 철저한 평가가 필요합니다.
각 변경 사항을 별도의 문서로 기록하는 것이 필수입니까?
필수는 아니지만, 전반적인 요구 관리 시스템이나 개별 Change Request에서 기록하는 것이 중요합니다. 변경 이력을 명확히 추적하는 것이 핵심입니다.
일반적인 실수 및 안티 패턴
- 변경 사항을 기록하지 않거나 요구 사항 버전을 관리하지 않음.
- 공식 합의 없이 변경 사항을 구현함.
- 변경이 제품의 다른 부분에 미치는 영향을 무시함.
실제 사례
부정적인 케이스:
변경은 관리자에 대한 구두 요청으로 구현되었고, 기록이나 영향 평가가 없었습니다.
- 장점: 새로운 기능을 신속하게 구현함.
— 단점: 예기치 않은 오류와 다른 모듈과의 충돌이 발생함.
긍정적인 케이스:
각 요청은 Change Request로 포장되었고, 위험 평가 및 조정이 수행되었습니다.
- 장점: 예기치 않은 상황 최소화, 투명성.
— 단점: 서류 작업에 더 많은 시간이 소요됨.