요구사항 문서는 이해를 거들뿐이다.
요구사항 변경은 요구사항에 대한 동상이몽의 결과이다.
요구사항을 정의한 문서는 ‘요구사항 정의서’, ‘요구사항 명세서’, ‘사용자 스토리’등 다양한 이름으로 불린다. 요구사항 문서는 요구사항을 소통하고 요구사항 변경여부를 판단하기 위해 활용한다. 프로젝트에서 요구사항을 정의하는 조직과 요구사항을 구현하는 조직은 다르다. 두 조직은 처한 상황과 추구하는 목표가 다르기 때문에 요구사항 문서의 내용을 서로에게 유리한 방향으로 해석하기 쉽다. 그 결과 요구사항을 다르게 이해하고, 추가 요구사항이 발생할 때 기존 요구사항과 다른 요구사항인지 기존 요구사항을 구체화한 것인지 판단하기 힘들다.
특히 SI 프로젝트와 같이 고객과 프로젝트 팀이 처음 만난 상황에서 충분한 소통 없이 작성한 요구사항 문서를 쌍방이 같은 수준으로 이해하기 힘들다. 이런 상황에서는 요구사항을 상세하게 정의하는 것만으로는 충분하지 않다. 반면 오랫동안 호흡을 잘 맞추며 협업해 온 ‘상품기획팀과 상품개발팀’또는 ‘현업부서와 전산실 조직’은 프로젝트가 늦게 끝나거나 예산을 초과할 수는 있어도 요구사항 문서를 서로 다르게 생각할 가능성은 낮다.
요구사항 문서를 제대로 활용하기 위해서는 다음에 유의해야 한다.
토의결과를 정리한 요구사항 문서보다 요구사항을 토의하는 과정이 중요하다.
프로젝트를 빨리 진행하고 싶은 마음을 상품관리자가 요구사항 정의서를 작성해서 상품개발팀에 메일의 첨부로 전송하면서 ‘요구사항 정의서를 보냈으니 질문 있으면 메일로 답장을 주시고, 아니면 요구사항 정의서 대로 개발해 주세요’라고 메일 본문에 작성했다고 생각해보자. 상품개발팀은 상품관리자가 제공한 요구사항 문서를 보고 아주 헷갈리는 것 한 두 가지를 메일이나 메신저로 물어보고 나머지는 개발팀이 이해한 대로 개발한다. 이렇게 개발된 결과물을 본 상품관리자는 변경을 요청한다. 물론 이렇게 극단적인 경우는 현실에서 드물지만 시간에 쫓겨 충분한 토론 없이 요구사항 정의서를 문서로만 소통하는 경우는 종종 있다.
같은 문서라도 상황에 따라 사람에 따라 달리 이해할 수 있다. 요구사항을 동일하게 이해하려면 요구사항 문서를 명확하고 구체적으로 작성하는 것도 중요하지만, 문서를 작성하기 전에 충분히 소통하는 것이 더 중요하다. 요구사항을 정의하는 과정에 참여하지 않는 사람과 참여하지 않은 사람이 같은 문서를 읽고 같은 수준으로 이해하는 것은 불가능하다.
함께 요구사항을 협의한 사람이라면 화이트보드를 촬영한 사진만 봐도 무엇을 협의했는지 알 수 있지만, 요구사항 협의에 참여하지 않은 사람은 그 사진만 봐서는 어떤 내용을 협의했는지 알 수 없다. 요구사항 문서는 화이트보드의 내용보다는 상세하고 체계적으로 기술하지만 회의 분위기, 주고받은 찬성 및 반대의견, 말이 아닌 미묘한 보디랭귀지 등을 모두 옮길 수 없다. 요구사항 토론을 통해 내용의 80%를 이해한다고 가정하면 요구사항 문서를 통해 이해할 수 있는 내용은 20%에 불과하다. 즉 토론에 참석하지 않고 요구사항 문서만 읽는 사람은 요구사항 내용의 80%의 내용을 다르게 생각할 수 있다.
두 조직이 오랫동안 협업해왔고 충분히 토론했다면 요구사항 문서를 간략하게 작성해도 프로젝트를 진행하는데 무리가 없다. 요구사항에 대해 충분히 소통한 사람들에게 요구사항 문서는 이해하기는 쉬워도 오해하기는 힘들다. 요구사항 문서는 이해하는 것을 거들뿐이다.
요구사항 변경은 요구사항에 대한 동상이몽의 결과이다.
요구사항의 변경은 요구사항을 정의한 문서의 내용이 바뀐다는 것이다. 요구사항 문서의 내용이 바뀌는 경우는 요구사항을 상세화 하면서 변경되는 것이 대부분이다. 요구사항 문서에 A라고 되어 있는 것을 B로 바꾸는 변경은 현실에서 드물다. 이럴 경우는 책임소재가 명확하기 때문에 잘못 정의한 것을 알아도 변경을 요청하지 않는다. 현실에서 흔한 변경은 요구사항 문서에 정의된 A를 보다 구체적으로 a1과 a2를 정의하는 것이다. 주로 요구사항 달성방법을 구체적으로 정의할 때 이런 일이 발생한다. 예를 들어 프로젝트 관리 시스템을 구축하는 프로젝트에서 계획 진척률과 실적 진척률을 관리한다는 요건을 계약서나 프로젝트 계획서에 정의했다고 가정하자. 계획 진척률과 실적 진척률을 측정하는 기준을 정의하지 않은 상태에서 프로젝트 팀은 수기로 진척률을 등록하는 것을 생각했고, 요구사항을 제시하는 상대방은 액티비티에 할당된 원가(또는 MM)의 가중치로 진척률을 계산하는 것을 생각했을 수 있다. 요구사항 변경이 이슈가 되는 시점은 요구사항 변경이 발생한 시점이 아니라 요구사항에 대한 두 조직의 동상이몽이 깨지는 순간이다.
요구사항 변경이 이슈가 되었을 때 요구사항에 대해 서로 다른 생각을 하고 있었다는 것은 명확하지만 누구의 생각이 계약서나 계획서 내용에 부합한 지 입증하기 힘든 경우가 대부분이다. 프로젝트 업무범위를 정의하는 계약서 또는 프로젝트 개발계획서에 상세 구현방안을 모두 정의하기는 힘들기 때문에 이런 일은 흔히 발생할 수 있다. 이 때문에 요구사항을 구현하는 프로젝트 팀은 추가 요구사항은 요구사항 변경이라고 주장하지만, 요구사항을 정의하는 조직이 요구사항 변경을 인정하지 않는다. SI 프로젝트에서 프로젝트 팀은 업무변경의 변경이라고 주장하지만 고객은 업무범위 내의 요청이라고 주장하는 것이 대표적인 예다. 설상가상으로 계약서 내 업무내용에서 ‘~등’과 같은 문구가 있으면 고객을 당해낼 수 없다.
남녀관계에서 상대방이 나에게 관심이 있다고 내가 착각해 놓고 진실을 나중에 알았을 때 상대방이 변심했다고 주장할 수 있을까? 마찬가지로 문서로 명시되지 않은 요구사항을 서로 다르게 생각해 왔음을 알았을 때 그것을 요구사항 변경이라고 말할 수 있을까? 진실은 요구사항을 서로 다르게 이해한 것이다. 이때 어느 한쪽이 요구사항을 틀리게 이해한 것은 아니다. 쌍방이 요구사항을 잘못 이해한 대가는 쌍방이 치른다. 물론 프로젝트 상황에 따라 더 큰 대가를 치르는 쪽은 있다. 그러나 대부분 내가 짊어질 짐이 상대방의 짐보다 무겁게 느껴진다.
요구사항 문구의 해석에 대해 서로 논쟁하는 시점까지 진행된 프로젝트는 쌍방의 신뢰는 회복하기 힘들다. 소위 ‘법대로’까지 갔다면 어느 한쪽에게 변경으로 인한 모든 책임을 지우는 상황이다. 요구사항에 대한 오해를 상대방의 100% 잘못으로 미루기 위해 정치를 하는 프로젝트는 파국으로 이어진다. 이런 프로젝트에서 승자는 없다. 모두 패배자이다.
많은 분량의 요구사항 정의서를 충분한 토의 없이 확정한 뒤 이대로만 개발하고 나머지 요구사항은 계약 변경(또는 계획 변경)으로 진행하겠다는 프로젝트 관리자의 생각은 순진하고 프로답지 못한 생각이다. 문서대로 프로젝트를 진행하려면 프로젝트 팀의 뛰어난 설득력과 리더십이 필요하다. 그런 역량이 없다면 프로젝트 초반에 한번 더 회의하고 하나 더 질문하는 것이 요구사항 변경을 예방하는 길이다. SI 프로젝트에서 고객 측 사유로 계약서 업무변경을 하는 경우를 필자는 본 적이 없다. 드물게 계약변경을 하는 경우는 여러 회사가 참여하는 프로젝트에서 특정 회사 또는 고객측 사유로 프로젝트가 지연되는 경우다.
https://brunch.co.kr/@kbhpmp/160
