84. 커스터마이징 프로젝트 요구사항 관리
성공적인 소프트웨어 신상품 개발가이드
기 출시된 상품을 커스터마이징하는 프로젝트는 요구사항 관리가 중요하다. 특히 확정가 계약(Fixed Price Contract)을 하는 경우 요구사항 변경은 프로젝트 손익에 직접적인 영향을 미친다. 커스터마이징 프로젝트의 요구사항을 관리할 때 유의사항은 다음과 같다.
- 단계별 승인의 의미를 정확하게 이해한다.
커스터마이징 프로젝트는 폭포수 모델을 적용하는 경우가 많다. 폭포수 모델을 적용하는 경우에는 프로젝트 분석, 설계 단계별로 고객의 승인을 받는데 프로젝트 팀은 다음과 같이 생각하기 쉽다.
“○○단계를 승인 받았으니, 확정된 내용은 향후 변경이 없을 거야. 그리고 승인된 문서는 계약서와 같은 효력을 가질 거야.”
반면 고객의 생각은 다를 수 있다.
“절차상 필요하다고 해서 승인을 하긴 했지만 모든 것을 꼼꼼히 읽어볼 시간이 없었고, 알기 힘든 문서도 많았다. 그리고 내가 승인한 내용을 모두 내가 안다고 하더라도 그것이 향후 변경이 불가능하다는 것을 의미하지는 않는다.”
단계별 산출물 승인에 너무 많은 의미를 부여하면 승인 자체가 힘들어진다. 단계별로 산출물을 승인한다는 것의 정확한 의미는 해당 시점의 산출물이 현재 상황의 요구사항과 구현방법을 가장 정확히 정리한 것임을 프로젝트 팀과 고객이 동의하는 것이다.
<소프트웨어 요구사항, 2003)>에서 올바른 의미를 다음과 같이 설명하고 있다.
본인은 현재 이 프로젝트에 대한 요구사항을 이 문서가 가장 잘 나타내주고 있다는 것과, 설명된 시스템이 우리의 요구를 충족시켜 줄 것이라는 것에 동의합니다. 프로젝트에 정의된 변경 프로세스를 통해 이 기본요소를 향후에 변경한다는 것에 동의합니다.
완벽한 요구사항은 프로젝트가 끝나는 시점의 모습이다. 분석단계에서 고객이 승인했다고 그것을 요구사항의 최종 확정으로 생각해서는 안 된다. 경직되고 막힌 마음가짐으로 고객과 소통해서는 프로젝트를 끝낼 수 없다.
- 완벽해야 할 상품 요구사항과 아닌 상품 요구사항을 구분한다
상품 요구사항의 내용에 따라 완벽하게 구현하는 것과 적정 수준으로 구현하는 것이 고객의 입장에서 별 차이가 없을 수 있다. 대개 적정 수준의 목표를 달성하기 위해서는 20퍼센트의 노력이면 충분하나, 목표 수준을 완벽하게 달성하기 위해서는 80퍼센트의 노력을 더 기울여야 한다. 고객 입장에서 20퍼센트의 상세화 수준이면 충분한 상품 요구사항과 100퍼센트 상세화 해야 할 요구사항을 구분하여 프로젝트 요구사항 변경에 대응하는 것도 현실적인 방안이 될 수 있다.
그러나 그러한 업무를 사전에 구분하기란 쉽지 않다. 사전에 그렇게 예상되는 기능을 파악하기 위해서는 상품 요구사항의 사용빈도, 주 사용자 계층, 업무 활용목적 등을 검토하여 쓸 만한 수준의 기능으로 구현해도 되는 요구사항을 식별해야 한다.
- 역지사지의 관점에서 요구사항 변경인지를 판단한다.
프로젝트를 수행하는 과정은 고객사와 수행사가 같은 배를 타고 목표지점까지 항해하는 것에 비유할 수 있다. 프로젝트를 성공적으로 종료하기 위해서는, 고객과 프로젝트 팀은 목적지 도착이라는 큰 목표를 공유해야 한다. 사소한 입장의 차이로, 바다 한가운데서 서로 논쟁하다 배가 난파되면 양쪽 모두 피해를 보는 것이 프로젝트의 특성이다.
프로젝트 관리자 못지않게 성공적인 프로젝트 종료를 원하는 고객이 왜 요구사항 변경을 요청할까? 역지사지로 생각해보면 프로젝트 관리자의 입장에서는 보지 못했던 관점이나 생각하지 못했던 논리들이 보일 것이다. 자기 생각만 하는 일방적인 주장은 억지와 투정에 불과하며, 논리와 근거가 부족한 일방적인 주장으로는 상대방을 설득시킬 수 없다.
요구사항의 변경관리는 요구사항의 변경인지 아닌지에 대하여 상호가 합의하는 것부터 시작한다. 이때 상대방은 합리적이며 나와 동일한 목표를 공유한다고 믿어야 한다. 나 스스로 나를 합리적이라 생각하는 만큼 상대방이 합리적이라고 생각해야 한다. 합리적인 사람은 합리적인 논리와 근거가 있으면 설득이 가능하다.
- 계약서를 펼쳐 업무범위에 관한 논쟁을 하는 것은 최후의 수단이다
국내 프로젝트 수행 정서를 볼 때 프로젝트 진행 도중 업무범위를 명확하게 하기 위해 계약서를 펼치는 시점은 최악의 상황에 직면한 경우가 많다. 계약서를 펼치는 것은 신의성실의 원칙에 따라 프로젝트를 진행하자는 것이 아니라 법대로 하자는 것이다. 불가피한 경우에는 할 수 없지만, 결과적으로는 고객과 프로젝트 모두에게 상처를 준다(대개는 프로젝트 팀이 더 큰 상처를 입는다). 그렇다고 해도 프로젝트 관리자는 계약서의 업무범위에 관한 내용을 숙지해야 한다. 해외의 경우 각국의 문화에 따라 수시로 계약서의 내용을 참조하며, 계약서를 보면서 고객과 의사소통 하는 것이 별로 흠이 아닐 수도 있다.
- 요구사항을 이해관계자들의 관심과 정치의 맥락에서 조망한다
고객 요구사항의 이면에는 조직의 비즈니스 니즈와 이해관계자의 정치적인 니즈가 있을 수 있다. 지엽적인 요구사항에 함몰되다 보면 보다 중요한 큰 맥락을 놓칠 수 있다. 프로젝트가 끝나는 시점에서 성공과 실패를 판단하는 기준이 되는 핵심 이해관계자의 핵심 요구사항은 프로젝트를 수행하는 도중 항상 집중해야 한다. 그러기 위해서는 프로젝트 단계별로 핵심 이해관계자의 이해관계나 기대수준의 진행현황을 모니터링해야 한다
- 요구사항 변경에 관한 의사결정을 본사로 넘기는 것도 좋은 방법이다
요구사항 변경 요청에 대하여 프로젝트 관리자가 회사를 대표하여 고객에게 악역을 해야 하는 순간이 있다. 그러나 때로는 경영층 혹은 회사의 관리부서에 그 역할을 맡기는 것도 문제해결의 실마리일 수 있다. 프로젝트 관리자가 “나도 개인적으로는 고객의 요구사항을 반영하고 싶은데 회사의 규정상 경영층의 승인을 받아야 합니다. 같이 경영층을 설득시켜 봅시다”라는 입장을 취한다면 의외의 해결책을 구할 수 있다.
- 시간이 약인 경우도 있다
고객의 요구사항 변경 요청에 대하여 즉석에서 거절을 해야 하는 경우도 있지만, 대개 요구사항 변경을 확정하기 위해서는 일정 기간 동안 아이디어 숙성기간을 가지는 것이 좋다. 고객과 협의하는 과정에서 고객이 번뜩이는 아이디어를 제시하는 경우가 있다. 예를 들어 흥분한 고객이 “○○씨 내가 어젯밤에 고민해봤는데, 설계를 이렇게 변경하고 이 기능을 추가하는 것이 좋겠어”라는 식이다. 문제는, 좋아 보이는 아이디어 하나가 전체 프로젝트를 힘들게 할 수도 있다는 것이다. 그 순간에는 고객이 그 아이디어를 반드시 반영해달라고 요구하는 것처럼 느낄 수 있지만 시간이 지나면 그렇지 않은 경우가 많다. 고객이 번쩍이는 아이디어를 냈을 때 그 자리에서 프로젝트 팀이 방어적인 논리를 강하게 펼친다면 고객은 자신을 변호하기 위하여 더 튼튼한 로직을 만들게 된다. 뿐만 아니라, 논리적 대화에서 상대방을 이기고 싶은 욕구를 자극하게 된다. 그냥 “좋은 아이디어입니다. 다양한 측면을 고려해보겠습니다”라고 넘어가는 것도 좋은 방법이다.
- 댐에 난 구멍 하나가 전체 댐을 무너뜨릴 수 있다
흔히 ‘foot in the door’라 부르는 유형이다. 프로젝트 관리시스템을 구축할 때 범위에 없던 ‘산출물 관리’ 기능을 요청하는 것을 예로 들 수 있다. 처음에는 게시판 기능처럼, 작성한 산출물을 등록만 하게 해 달라는 작은 요구사항으로 시작하지만 그것이 점점 커져, 산출물 분류체계, 형상관리 문제로까지 번질 수 있다. 없으면 몰라도 눈에 보이는 것이 조악하고 미흡할 때 경영층 혹은 관련 이해관계자들로부터 추가적인 요청을 받을 수 있다. 사소하게 끝날 수 있는지 아니면 확대될 수 있는 업무인지를 잘 판단해야 한다. 작은 구멍 하나로 막으려면 최초 협의하는 시점에서 범위에서 제외되는 것들을 명확하게 해야 한다. 가장 좋은 방법은 별도의 프로젝트로 연결시키는 것이다. 떡 본 김에 제사 지낸다고 기왕 계약했을 때 이것저것 평소 못했던 것을 구현하고자 하는 고객도 더러 있다. 그렇게 하면 고객과 프로젝트 팀 모두에게 손실이 된다는 진심이 전달될 수 있게 설득해야 한다.
- 프로젝트 업무범위의 경계에 있는 업무에 유의한다
소프트웨어 상품 커스터마이징 프로젝트는 고객사 리거시(legacy) 시스템과 연계를 포함하는 경우가 많다. 이때 연계업무는 어떤 수준까지 프로젝트 범위에 포함할 것인지를 명확하게 해야 한다.
- 특정 이해관계자에게는 ‘+’, 특정 이해관계자에게는 ‘–‘가 되는 요구사항도 있다
특정 요구사항이 이해관계자에 따라 좋고 나쁨이 명확하게 갈리는 경우 해당 요구사항은 프로젝트 후반부에 변경될 가능성이 높다. 프로젝트는 초반부에는 ‘+’가 되는 이해관계자 그룹이 리딩하고 ‘–’가 되는 이해관계자 그룹은 외형적으로는 따라가는 것처럼 보이나, 프로젝트 후반부에 ‘–’가 되는 이해관계자 그룹이 결정타를 날려 그 동안 진행했던 업무의 방향을 전환시키거나 지연시킬 수 있다.
새로운 일을 성공적으로 추진하는 것보다, 새로운 일이 잘 되지 않게 하는 것은 훨씬 쉽다는 것을 기억해야 한다.
- 요구사항 변경 근거를 관리한다
요구사항 변경 시 변경요청서를 작성해야 한다. 물론 바람직한 것은 요청자가 직접 작성하는 것이지만 그렇지 않을 경우 프로젝트 팀 자체적으로 기록을 관리해야 한다. 고객에게 요구사항 변경이 얼마나 발생하였는지를 설득할 때 그동안 모아두었던 요구사항의 변경 내역을 보여주는 것도 도움이 된다.요구사항 변경은 여러 가지 요인 때문에 발생하지만 모든 변경은 이해관계자와 관련이 있다. 따라서 범위변경 통제를 위해서는 범위변경 요인에 영향을 끼치는 이해관계자들의 합의를 도출하기 위해서는 이해관계자들을 설득할 수 있는 합리적인 근거나 자료를 준비해야 한다.
https://brunch.co.kr/@kbhpmp/160
