잘못될 징조 - 요구사항 명세서의 핑퐁

대화가 빠진 문서만의 핑퐁은 확실히 잘못될 징조가 농후한 프로젝트가 될 확률이 크다. 여기에 더하여 부서간 정치가 개입되면 한 층 더한 경우라 하겠는데, 대표적인게 A라는 부서가 발의하고, 실제 쓸 부서는 B가 될 경우이다. B부서는 당연히 업무가 늘어나는 것이 될 테니, 시스템이 알아서 다 해주기만을 바랄테고, 그 요구사항은 가히 인공지능스럽기 마련이다. 이런 정치가 개입된 프로젝트라면, 당연히 A와 B를 불러 모아 대화로써 R/R을 나누어야 한다. 문서만으로 핑퐁만 친다고 될 일이 아닌 것이다. 그런 의미에서 다음의 글은 어떻게 잘못된 징조가 현실화 되는지를 보여주는 사례라 하겠다.

 

요구사항 명세서가 소프트웨어 개발 그룹과 다른 그룹(마케팅 그룹 혹은 제품관리 그룹)사이를 왔다갔다 한다면, 그것은 프로젝트가 잘못된 방향으로 진행되고 있다는 징조다. 상황은 대체로 다음과 같다. 먼저 제품 관리 그룹이나 기타 비슷한 그룹에서 요구사항 명세서를 작성한 후 그것을 개발자들에게 넘긴다. 그리고 개발자들은 제품 관리 그룹에서 작성한 문서에 자신들의 해석을 덧붙여 문서를 재작성한다. 그들은 항상 자신들이 작성한 문서에 기능 명세서(functional sepcification)와 같이 완전히 다른 이름을 붙인다. 새로 작성한 문서가 사실은 문서와 관점만 다를 뿐 같은 문제라는 점을 감추기 위함이다.

해당 그룹들은 소규모 프로젝트가 아닌 이상, 작성된 요구사항 명세서가 읽기 힘들고, 완전히 이해하기도 어려우며, 기대 수준만큼 자세하게 기술하기도 힘들다는 것을 알고 있다. 한 그룹은 다른 그룹이 작성한 문서의 내용에 대해 정확히 이해하기 힘들다. 이로 인해, 최종적으로 문서를 작성한 그룹에서 그 문서 내용의 의미에 대해 어떻게 말하더라도 다른 그룹에서는 그것이 잘못되었다고 말하기 힘들다. 프로젝트가 실패하고 누군가 비난을 받아야 할 때가 되면, 그들은 문서 특정 부분을 가리키며 빠진 부분이 거기에서 의미했던 바였다고 주장한다. 그렇지 않으면, 그 기능이 원래부터 구현 사항에 포함되지 않았다고 주장한다. 이렇듯 서로 책임을 회피하더라도 잘못을 지적하기 힘들다.

여러그룹이 결국은 같은 문서를 다른 형태로 작성하고 있는 것을 자주 보게 된다. 그들은 나중에 비난 받을 것에 대비하여 무언가 준비해 놓고 있는 것일 뿐이다. 사용자 스토리에서는 이렇게 어리석은 일이 발생하지 않는다. 문서보다 대화를 더 중요시 한다는 것은 어떤 것도 최종적인 것은 없다는 것을 의미한다. 문서는 계약서인 듯 보여서 최종적인 것처럼 느껴진다. 그러나 대화는 다르다. 우리는 오늘 대화를 하고 나중에 무언가를 배우고나서 또 다시 대화한다.

 

<사용자 스토리> p.187