 |
|
난이도 : 초급 S. E Slack, Author and business transformation consultant, 자유기고가
2008 년 10 월 07 일 이 글은 프로젝트 요구 사항과 요구 사항 주기를 자세히 살펴봄으로써 요구 사항 계획에서 비즈니스 분석가의 역할을 이해하는 데 도움을 줍니다.
'요구 사항'은 프로젝트를 계획하고 솔루션을 디자인할 때 많은 사람을 당황하게 하거나 수긍하지 못하도록 만든다. 하지만 이 낱말은 그렇게 어려운 것이 아니다. 모든 프로젝트에서 요구 사항은 바로 성공으로 가기 위해 프로젝트에 포함되어야 하는 필수 항목이며 그 이상도 이하도 아니다. 사람들을 당황하게 만드는 것은 프로젝트 요구 사항은 어떤 것이어야 하며, 이에 대해 누가 책임이 있는가, 정확히 어떻게 성취되는가를 결정하는 것과 관련된 역할과 실제 책임이다.
1단계: 요구 사항 계획 단계
대부분의 조직에서 일반적으로 비즈니스 분석가가 이러한 특정 업무를 맡는다. 요구 사항 계획이라 부르는 작업은 프로젝트에서 지루한 작업으로 도출, 문서화, 분석, 상호 교환, 추적, 유효성 확인 및 모든 사람이 프로젝트에 속해 있다고 생각하는 모든 요구 사항을 확인하는 것이 여기에 포함된다. 어떤 회사에서는 이러한 환영 받지 못하는 작업을 설계자에게 떠맡겨 이미 충분히 바쁜 설계자에게 또 다른 책임감을 추가하기도 한다. 이런 경우라면 요구 사항 계획 업무를 관리하는 비즈니스 분석가가 따로 있으면 좋겠다고 생각할 것이다.
요구 사항 계획의 각 부분을 일반적인 방법으로 살펴보자.
- 도출(Elicit): 현재 프로세스에서 어디에 문제가 있는지, 모든 그룹에 가장 유용한 해결 방법이 무엇인지 이해하기 위해 최종 사용자와 비즈니스 담당자에게서 정보를 도출한다.
- 문서 작성(Document): 최종 사용자나 기타 사람의 잘못이 아닌 프로세스 자체의 결과로 나타나는 문제를 문서로 기록한다.
- 분석(Analyze): 왜 문제가 발생하는지 분석한다. 분석에는 단순히 프로세스를 변경하는 것으로 문제를 해결할 수 있는지 또는 해당 문제가 디자인을 완전히 바꾸어야 해결되는지 여부를 결정하는 일이 포함된다.
- 상호 교환(Communicate): 발견한 정보를 비즈니스 담당자와 상호 교환하고 수행해야 할 추가 단계를 담당자에게 전달한다. 상호 교환은 프로젝트 최종 기한 메모 또는 새로운 발견으로 인한 요구 사항 변경이 있을 때마다 지속적으로 이루어진다.
- 추적(Track): 디자인 솔루션을 사용해서 도출 과정에서 포함되지 않은 문제를 해결하는 방법과 디자인이 실제로 최종 사용자와 담당자의 요구에 부응하는지 여부를 추적한다.
- 유효성 확인(Validate): 모델링, 테스트, 시뮬레이션을 통해 디자인 솔루션의 유효성을 확인한다.
- 확인(Verify): 디자인 솔루션이 최종 사용자와 비즈니스 담당자의 요구 사항을 충족하는지 확인한다.
첫 항목 세 개는 일반적으로 계획 단계에서 고려된다. 목록으로만 보면 이 계획 단계를 수행하는 데 불과 몇 시간 정도 걸릴 것이다. 하지만 실제로는 몇 개월 동안 작업해야 한다. 비즈니스 분석가는 수행해야 할 작업, 작업 수행의 가치, 요구 사항에서 지원하는 비즈니스 목표, 성취할 수 있는 방법, 또 다른 대안 및 요구사항의 처리 또는 처리하지 않는 것과 관련된 위험을 확인하느라 분주하다. 요구 사항 계획 주기는 아키텍처 작업을 모두 수행하기 전에 시작해야 한다. 결국 아직 문제가 무엇인지도 모르고, 문서로 작성되지도 않았으며 분석되지 않았다면 어떻게 문제를 해결하기 위한 솔루션을 디자인할 수 있겠는가? 이것은 마치 자전거에 바퀴도 달기 전에 자전거를 타려고 시도하는 것과 같다. 자전거에 앉아서 어디로 갈 것인지 생각할 수는 있겠지만 실제로 아무 곳에도 가지 못한다.
놀랍게도 일부 설계자는 그러한 자전거를 타려고 시도한다. 그들은 요구 사항을 결정한 뒤 그러한 요구 사항이 왜 처음부터 존재하는지 또는 요구 사항이 실제로 있는지 여부조차 이해하려 하지 않은 채로 해당 요구 사항에 대한 솔루션을 만든다. 심지어 문제가 있다는 사실이 아주 명백한 경우에도 요구 사항 계획의 가치를 간과할 수 있다. 예를 들면 문제의 요점이 특정 소프트웨어에 대한 최종 사용자 교육의 필요에 있을 수도 있다. 이 경우는 새로운 디자인 작성이나 기존 디자인 수정과는 전혀 관계가 없다. 솔루션을 만드는 데 급급한 경우 사용자에게는 여전히 기술이 없기 때문에 문제가 계속 해결되지 않을 수 있다. 따라서 솔루션 디자인 주기는 문제를 찾고 솔루션을 디자인하며, 관련된 모든 사람이 여전히 만족하지 못하고 비생산적이 되는 문제가 지속되는지 확인하는 것이다.
"Why you shouldn’t ignore business analysts"라는 글에서 비즈니스 분석가는 설계자를 고객에게 연결해 준다고 설명되어 있다. 그 이유는 목록에 있는 항목에서 찾을 수 있다. 전체 요구 사항 계획 과정에서 비즈니스 분석가는 전면에 서서 최종 사용자와 대화하여 그들의 실제 문제가 무엇인지 확인함으로써 해당 요구와 희망 사항을 좀 더 기술적인 언어로 바꾸어 프로젝트 설계자와 담당자들에게 전달한다. 비즈니스 분석가는 계획 단계를 완료하는 데 많은 시간을 들이는 것처럼 보이며 실제로도 그럴 수 있다. 그 시간은 대부분 사람들의 스케줄과 관련되어 있고 계획 단계에서 발생하는 작업에 따른 일정 관리와 관련된 시간의 양을 과소평가하기 때문에 발생한다
이것은 비즈니스 분석가가 조직적이지 못함을 의미하는 것은 아니다. 그런 경우는 거의 없기 때문이다. 단지 요구 사항 계획에서 이 부분이 일반적으로 과소 평가되는 것뿐이다. 비즈니스 분석가는 표면적으로 드러나는 문제 이외에 발견되는 종류의 문제들을 모르기 때문이다. 여러 문제 계층이 발견된다면 요구 사항 계획 프로세스는 스케줄링 관점에서 대단한 적중을 한 것이 된다. 이러한 문제 계층을 무시할 수 없기 때문에 비즈니스 분석가는 스케줄을 연장할 수 밖에 없다.
2단계: 요구 사항 계획
비즈니스 분석가의 역할과 관련된 책임은 요구 사항 계획 단계에서 끝나지 않는다. 비즈니스 분석가가 해당 요구와 희망 사항(프로젝트 요구 사항)을 결정하고 나면 작업이 시작된다. 이제 비즈니스 분석가가 사용될 노력과 방법의 범위에 대해 담당자로부터 얻어낸 것을 가져올 수 있도록 실제 요구 사항 계획에 대한 작업이 시작된다. 이 시점의 요구 사항 계획에 상호 교환, 추적, 유효성 확인, 확인 항목이 포함된다. 요구 사항 계획 주기를 완료할 수 있도록 다음과 같은 유형의 작업이 시작된다.
- 수행될 요구 사항 활동 정의
- 프로젝트에서 해당 활동을 수행할 방법 결정
- 해당 요구 사항과 관련된 주요 역할 확인
- 관련 요구 사항 활동 선택
- 요구 사항 범위 관리, 해당 상태에 대한 정보의 상호 교환
이러한 특정 작업에 대해서는 프로젝트에서 비즈니스 분석가와 작업을 수행하는 동안 알게 될 것이다. 프로젝트의 바로 이 시점에서 비즈니스 분석가를 놓치기는 힘들 것이다. 바로 그 시점에 비즈니스 분석가가 디자인을 샅샅이 살펴보고 어떤 작업을 언제 수행할지 제안하기 때문이다. 이에 대해 짜증을 내기보다는 다음 사항을 명심해야 한다. 요구 사항 계획이 잘못되면 담당자의 자신감과 함께 많은 비용과 평판을 잃게 된다. 하지만 정통한 요구 사항 계획을 제대로 수행하고 나면 너무나 간단해 보여서 간과되고 과소 평가될 가능성이 있다.
프로젝트를 시작하기 전에 정말로 뛰어난 비즈니스 분석가는 프로젝트 매니저가 따라야 할 자세한 로드맵을 포함하는 작업 계획을 전달한다. 조직에서 회의를 비공식적으로 하고 있으며 요구 사항 계획을 문서로 남기지 않는다면 프로젝트 스케줄이나 예산이 초과할 때 골치 아픈 일과 설명할 일이 많아질 수 있다. 최소한 요구 사항 계획에 특정 조직 또는 산업에 따라 포함되는 추가 항목과 함께 다음 항목이 포함되어야 한다.
- 명확하고 간단하며 기술적이지 않은 언어를 사용한 요구 사항에 대한 보고용 요약
- 프로젝트에 대한 제안 전략
- AS-IS 요구 사항 프로세스(작업 순서도와 프로세스 설명 포함)
- TO-BE 요구 사항 프로세스(작업 순서도와 프로세스 설명 포함)
- 제안 변경 관리 프로세스
- 권장 메커니즘, 방법, 도구
- 산업 요구 사항의 최상의 방법에 대한 검토
- 프로젝트에 대한 제안 디자인 접근(항상 프로젝트 설계자로부터의 입력이 포함되어야 함)
제대로 작성된 계획은 프로젝트를 목표와 예산에 맞추는 데 사용할 수 있다. 또한 임원에게 선호하는 프로젝트가 있는 경우나 디자인에 대한 "단지 사소한 변경"을 원하는 부서를 제어하는 데도 사용할 수 있다. 사람들은 요구 사항 변경 내용을 문서로 작성해야 한다는 것을 깨닫는 순간 뒤로 물러서는 경향이 있다. 또한 계획의 전반적인 목적은 고객과 개발자가 프로젝트 요구 사항에 대한 공통적인 이해에 도달하도록 하는 데 있다.
이전에 요구 사항을 전혀 작성해 본적이 없다면 참고자료 절에서 훌륭한 예제들을 찾아보도록 한다. 계획의 일부로 사용되는 IBM Rational® RequisitePro®는 오랜 사용으로 효과가 입증된 요구 사항 및 케이스 관리 도구이며 조직에 대한 효율적인 요구 사항 관리 프로세스를 작성할 수 있게 한다. 이 글에 무료 평가판에 대한 링크가 포함되어 있다.
3단계: 성공 측정
프로젝트가 끝나도 요구 사항 계획 프로세스는 한동안 계속 되어야 한다. 조직의 성공에서 요구 사항의 상태가 성취되었는지 여부가 중요하다. 예를 들어 요구 사항이 성공적으로 해결되었는가? 또는 프로젝트 범위에서 빼서 다가올 프로젝트에 포함시켰는가? 또한 프로젝트를 수행하는 동안 요구 사항을 얼마나 많이 변경했는지 검토하는 것도 좋은 생각이다. 이 정보를 알면 비즈니스 분석가가 프로세스 중 어느 단계에서 실수가 있었는지 또는 도출이나 문서 작업, 분석의 향상 내용이 향후 어디에 적용될 수 있는지 이해할 수 있다.
완벽한 사람은 없으며 우리는 누구나 실수하면서 배운다. 하지만 요구 사항 계획 과정의 시작부터 끝까지 프로젝트에 관련된 모든 사람이 신중하게 작업한다면 요구 사항 계획이 그저 필요악에 불과하다고 생각하는 사람들이 수행하는 프로젝트에서 훨씬 더 실수를 줄일 수 있다. 아마도 오스트레일리아의 유명한 사업가인 Chris Corrigan이 한 다음과 같은 말이 이 상황에 가장 적합할 것이다. "계획하고 준비해야 하는 필요는 결코 과대 평가될 수 없다. 저질러지는 실수의 대부분은 공통적으로 이전에 계획을 잘못했기 때문에 발생한다. 비즈니스에서 지나친 준비란 있을 수 없다."
참고자료 교육
제품 및 기술 얻기
토론
필자소개 | 
| | S.E.Slack은 자신의 이름으로 된 기술 서적을 열 권 이상 쓴 작가다. 그녀는 가족과 함께 콜로라도에서 산다. 최근 작품은 Windows Vista: Home Entertainment with Windows Media Center and Xbox 360(Microsoft Press, 2007)이다. 다음 작품은 PowerPoint 2007 Graphics and Animations Made Easy로 McGraw-Hill에서 출간될 예정이다. |
기사에 대한 평가
|
| 이 문서 북마킹 하기
|
| 
