기획서 작성에서 외부 팀 리뷰 과정의 의미

가상의 바쁜 개발팀을 상상해봤습니다. 마일스톤 목표는 서로 다른 자잘한 기능 목록으로 분리되어 있고 각 기능마다 기획팀 구성원들에게 할당되어 기획서를 작성하는 중입니다. 이번 마일스톤에 개발해야 하는 기능의 수는 기획팀 구성원 전체보다 더 많습니다. 하지만 각각의 기획서를 작성하는데 마일스톤 전체 기간이 필요하지는 않으므로 구성원 한 명이 연이어 서로 다른 기획서를 작성하게 됩니다.

회사마다, 프로젝트마다, 또 팀마다 정책이 다르겠지만 대략 기획서를 작성하고 나면 기획팀 내에서 확인 과정을 거쳐 기획서 작성 완료를 선언합니다. 그러면 담당 기획자가 직접 또는 조금 더 사정이 나은 팀이라면 PM이 리뷰 일정을 수립합니다. 리뷰는 주로 회의 형식으로 이루어지는데 기획서 내용을 담당 기획자가 브리핑하면 이 업무를 담당할 협업팀 구성원들이 질의응답을 하는 형식으로 이루어집니다. 아쉽게도 리뷰는 회의 시간에 주로 진행되므로 회의에서 피드백이 나왔다면 이를 반영하는데 시간이 더 필요합니다. 때때로 리뷰 회의에서 이 계획을 이대로 진행할 수 없다고 판단할 때도 있는데 이때는 이 기능 자체의 요구사항과 일정 등에 대한 재검토가 필요합니다.

여기부터 종종 슬픈 일이 일어나곤 하는데 개발 진행을 폭포수 방식으로 해석할 때 주로 이 슬픈 일이 일어나는 것 같습니다. 폭포수 관점에서 기획서 리뷰 회의는 기획서 작성이 완료되었음을 의미한다고 해석되곤 합니다. 하지만 실제로 리뷰 회의는 협업팀 구성원들이 이제부터 기획서가 제시한 목표에 대한 이해도를 올리기 시작하는 자리일 뿐이고 이 자리에서 제시된 반사적인 피드백 외에도 회의가 끝난 시점부터 본격적으로 여러 채널을 통해 피드백이 나오기 시작합니다. 이를 문서에 반영하는 일은 ‘문서에 한 줄만 추가하면 되는 일’로 쉽게 폄하되곤 하지만 실제로는 그렇지 않은 경우가 훨씬 많습니다. 피드백을 받아들이려고 보면 요구사항을 전면적으로 재설계해야 할 수도 있습니다. 하지만 전체 프로세스 상 이 기획서는 리뷰 단계를 거쳤으므로 작성이 완료되었다고 평가되므로 이 기획팀 구성원은 서둘러 다음 기획서 작성 업무로 진행해야만 합니다. 그렇지 않으면 꽉 짜인 일정을 준수하지 못하고 책임을 추긍당하게 될 겁니다.

사실 요구사항을 정의하는 단계가 이렇게 진행되면 안된다는 점을 이미 모두가 눈치채셨을 겁니다. 마일스톤을 구성하는 각 목표들이 팀 전체에 공유되어 이미 협업팀 구성원들 전체가 대략 무슨 일이 일어날 것인지 예상할 수 있어야 하고 각 요구사항을 기획서에 정의하기 전에, 또는 정의하는 과정에서 이미 결정된 협업팀 구성원들과 사전 협의를 거쳐야 합니다. 하지만 종종 이런 과정을 개개인의 역량으로 치부하곤 합니다. 실제로는 필요한 과정이지만 결코 공식적인 과정에는 드러나지 않습니다. 시간을 아껴 협업팀 구성원들과 사전 협의하는 자리 또는 회의는 분명 있지만 관리되지 않습니다. 이 과정을 거친 기획서는 리뷰 회의가 수월하게 진행되고 그렇지 않은 기획서는 리뷰 회의에서 종종 탈탈 털리게 됩니다.

기획서 리뷰 회의는 기획서의 완성 확인 및 구현 시작을 의미하지 않습니다. 공식적으로 리뷰 회의는 처음으로 요구사항의 실체를 협업팀 구성원들에게 알리는 자리일 뿐이며 기획서를 통한 요구사항 정의는 이제부터 시작합니다. 만약 리뷰 회의를 기획서 작성 완료라고 평가하고서도 그럭저럭 개발이 진행되고 있다면 분명 누군가는 공식적인 업무로 인정받지 못하는 사전 협의를 개인의 역량을 통해 수행하고 있을 가능성이 있다는 의미입니다. 이는 관리되지는 않지만 실제로 존재하는 과정을 일정 예측에 포함하지 않고 또 개발 과정을 개개인의 역량에 지나치게 의존하게 되어 위험합니다.