프로젝트 매니저는 프로젝트에서 무엇을, 매니지먼트 해야할까?
첫째는 고객의 필요, 그리고 프로덕트의 요구사항을 관리 해야한다.
고객의 필요
프로젝트는 프로덕트를 만든다. 그리고 프로덕트는 고객의 필요에서 출발한다. '고객의 필요' 라는 첫 번째 끈을 놓치면 아무리 훌륭한 디자이너, 아무리 훌륭한 개발자가 프로젝트에 투입될 지라도 아무도 사용하지 않는 예쁘고, 빠르고, 정확한 프로덕트가 만들어지는 대 참사가 일어난다. 우리는 예쁜 화면, 정교한 소프트웨어를 만드는 대회에 참여한 것이 대게는 아니다.
프로젝트 매니저는 프로젝트의 시작인 고객의 필요를 캐치하고 이를 관리해 나가야한다.
프로덕트 전체 요구사항
요구사항이라고 하면 고객이 정의 내려준 고객이 원하는 것 이라는 느낌을 많이 준다. 그래서 때때로 고객이 전해준 두리뭉실하고 뒤죽박죽인 요구사항을 그대로 들고 개발 단계에 들어가는 경우도 있지만 적절한 방법이 아니다. 요구사항은 정확히 말하면 '프로덕트 명세'(Product Specification)가 되어야 한다. 고객의 요구로부터 시작되지만 그것으로부터 우리의 프로덕트는 어떻게 동작해야 하고 어떤 기능을 가져야 하는지 구체화하여 개발사에서 정의한 것이라 할 수 있다.
그리고 우리는 '프로덕트 명세' 가 문서화 되도록 해야 한다. 글로 정리되어 공유되지 않은 내용은 자주 후에 분쟁을 일으키고 고객과 그리고 개발자 간에도 서로 다른 이해를 낳아 프로젝트에 큰 위기를 가져오는 경우가 많다.
마지막으로 놓쳐서는 안되는 중요한 포인트는 '전체' 라는 단어이다. 우리는 종종 일부 요구사항을 놓치고 중요한 몇몇 요구사항만 문서로 관리하는 실수를 범한다. 이는 요구사항 자체가 누락될 수 있다는 중요한 문제이기도 하지만 매니지먼트 관점에서 볼 때, 추후 프로젝트 일정 관리에도 큰 구멍을 가져온다.
개인적인 느낌일 수도 있지만 고객의 전체 요구사항에 대한 프로덕트 명세가 간결하게 한 문서에 정리되어 있으면 고객에게도, 팀에게도, 매니저 개인에게도 큰 안정감을 준다. 물론 프로젝트 초기에 '전체' 요구사항이 완벽하게 정의되어야 한다는 뜻은 아니다. (사실 그럴 수 없다) 프로젝트 초기부터 정의되어 온 '전체' 요구사항은 프로젝트가 진행되며 점점 정교하게 개발되어져 가야한다.
요구사항 추적표
프로젝트 규모에 따라 프로젝트 전 영역에서 아래와 같은 요구사항 추적 테이블이 활용 되기도 한다. (대게 큰 규모의 프로젝트)
때때로 개발자들이 이런 추적 테이블을 요식행위라고 비판하기도 하고, 불필요한 문서작업이라고 불평하기도 하지만 그건 고객의 입장이, 그리고 매니지먼트 관점에서 생각해 보지 않았기 때문이라고 생각한다.
고객은 자기가 필요 하다고 전달한 요구사항 항목들이 개발되는 소프트웨어에서 빠지지는 않는지 불안하다. 왜냐하면 개발단계가 진행될 수록 내가 요구한 것들이 어디에 어떻게 반영되고 있는지 따라가기가 쉽지 않기 때문이다. 이것은 고객 뿐만아니라 매니저에게도,개발자에게도 쉬운일이 아니다. 프로젝트가 한참 무르익어 야근이 한 창일 때, 빠진 요구사항이 갑자기 수면위로 드러나 야근 위해 야근을 더하는 슬픈일이 일어나기도 한다.
요구사항의 버그를 찾아라
흔히 버그 하면 프로그램의 소스코드의 버그를 뜻한다. 그러나 요구사항에도 버그는 있다. 다른 요구사항과 논리적으로 상충되는 요구사항이 있을 수 있고, 도메인 환경과 맞지 않는 요구사항도 있을 수 있다. 소스코드의 버그를 찾아서 해결하는데 1주일이 걸린다면 요구사항의 버그를 프로젝트 초기에 발견하여 수정한다면 1주일의 10배, 20배의 시간을 아낄 수 있을 가능성이 크다. 그래서 프로젝트 매니저는 요구사항에 버그가 있는지 신중하게 검토해야 한다.
