그건 바로 공식 요구사항정의서와 별도로 개인용 요구사항 정의서를 정의하는 것이 편할 수 있다는 점입니다.(어쩌면 더 효율적일 수 있습니다.)
일반적으로 프로젝트는 모듈별로 담당 기획자가 나뉩니다. 그리고 요구사항정의서 작성은 모듈별 담당 기획자가 완성한 후 취합하는 형식으로 완성됩니다.
이 부분에서 공식 버전과 별도로 개인용 요구사항 정의서 문서의 필요성을 경험했습니다.
공식버전의 경우 요구사항의 중복없이 완성됩니다. 그래서 취합하는 과정에서 유관하다 판단해 제 모듈에서 작성되었더라도 타 모듈과 내용이 중복될 경우 둘 중 하나의 모듈에선 빠지게 됩니다. 이 사실을 프로젝트 기간 동안 계속 염두하고 있으면 좋지만..시간은 언제나 부족하고..그럼 요구사항 정의서에서도 제 모듈에 정의된 요구사항 정의서만 보는 상황이 발생합니다. 물론 기획자라면 자신의 모듈것만 볼 게 아니라 타 모듈이라도 관련된 내용이라면 계속 확인하는 게 당연하지만 놓치는 상황이 분명 발생할 수 있습니다. 따라서 저는 이번 프로젝트를 통해 개인용과 공식 버전 요구사항 정의서의 필요성을 느꼈는데요.
다만 이렇게 문서를 분리하다보면 요구사항 정의서가 수정될 경우 문서를 2개 업데이트해야하는 상황이 발생하기에 이 경우에도 역시 업데이트가 되었음에도 놓치는 요구사항이 생길 수 있습니다. 그럼 어떻게 해야하나?
여기서 "개인용"이라는 부분을 놓치면 안되는데요. 즉, 공식 요구사항의 양식을 따를 필요가 없다는 점입니다. 모든 컬럼을 따를 필요없이 개인용 요구사항정의서에는 요구사항ID만 기록해두는 것입니다. 이러면 내용을 관리할 필요도 없기에 요구사항 내용 혹은 협의된 내용이 수정되어도 이를 따로 개인용 문서에 반영해야할 일이 생길리 없겠죠. IA를 관리하듯 요구사항 ID만 관리하면 되는 것입니다. 그럼 타 모듈에 정의된 요구사항이라도 놓칠 염려를 덜 수 있겠죠?
이 글은 제 개인적인 경험을 바탕으로 작성되었습니다. 댓글을 통해 부족한 부분은 채우고, 다른 부분은 맞춰갈 수 있길 희망합니다.
해당 문서는 결국 이번 프로젝트에서 뭘 할 것이냐를 공식적으로 약속한 내용을 담고 있다. 따라서 프로젝트 진행에 있어서 범위를 정의하는데 근간이 되는 문서이기도 하다.
요구사항 정의서는 사용자 인터뷰 등을 통해 도출된 요구사항을 분석하여 정리된 문서이다. 여기서 "분석"이라는 점이 중요한데, 수행사 관점에서는 결국 해당 문서에서 이행하기로 약속한 기능을 "구현"해야하는 의무를 갖고 있다. 따라서 모든 요구사항을 기능 단위로 분리하고, 구현 관점에서 제한된 인력과 기간 내에 수용 가능한 요구사항인지를 분석해야 한다.
*기획자 입장에선 현업의 요구사항을 상당 부분 수용해주고 싶다. 그러나 프로젝트 입장에선 기한 내 불가능한 요구사항을 수용할 경우, 수행사 프로젝트팀의 고생을 떠나서 기한 내 아예 오픈을 못해버리는 불상사가 발생할 수도 있다. 그리고 기한 초과는 곧 예산 초과로 이어진다. 이러면 최악의 경우 법적 다툼으로까지 이어질 수 있다..
기능 단위의 분석이라 하면 요구사항 하나에 2가지 이상의 기능을 담는 걸 지양해야 한다는 것을 의미한다. 이는 요구사항에 따라 수용할 수 있을 수도, 없을 수도 있기 때문이다. 즉, 요구사항A에 기능A와 기능B 개발을 포함할 때, 기능A는 수용 가능한데 기능B는 그렇지 못할 수 있다. 물론 이 경우, 요구사항 정의 단계에선 부분 수용이라하고 고객사와 협의를 통해 요구사항을 수용 가능한 요구사항으로 수정할 수 있는 여지가 있다. 그러나 요구사항 다 확정하고 구현 단계에서 수행사가 막상 개발하려니 기능A는 되는데 기능B는 안된다고 해버릴 순 없는 노릇이다. 따라서 기능 단위의 요구사항 분리가 개인적으로 중요하다고 생각한다.
*이는 개발 관점에서 기능단위이다. 요구사항을 가령 체크박스 옵션 단위나 지나친 세분화하는 것 또한 지양해야한다. 요구사항이 너무 많아질 경우 관리가 어려워지기 때문이다.
요구사항 정의서는 또한 분석된 내용을 토대로 작성되는데, 여기서 중요한 점은 단순히 프로젝트 범위만 정의하면 안된다는 점이다. 요구사항은 수행사가 검토 후 고객과 협의를 결정되는데, 여기서 수용하기로 했다면 구체적으로 어떤 기능을 수용했는지, 그리고 미수용으로 결정되었다면 무엇 때문에 어떤 걸 미수용하기로 했는지 구체적으로 정의되어 있어야 한다.
이러한 사유들을 정의서에 포함해야 하는 이유는 아무리 워터폴 방법론을 채택하더라도 설계 또는 구현 단계에서도 여전히 요구사항은 추가되기 때문이다. 물론 모든 요구사항을 반영할 수 있다면 좋겠지만, 프로젝트는 제한된 자원 안에서 진행되기에 끊임없이 추가되는 요구사항은 프로젝트의 실패를 야기할 가능성이 높다.
따라서 추가되는 요구사항에 대해 가능한 범위를 한정지어야 하는데, 이때 요구사항 정의서에 정의된 사유를 통해 미수용했던 요구사항, 즉 이번 프로젝트에서 진행불가한 요구사항을 받아들이는 사고의 발생 가능성을 줄일 수 있다.
+ 요구사항 정의서를 정리하는 순서는 아래와 같다
사용자 인터뷰 등을 통한 요구사항 조사
기능 단위 요구사항 정의
수행사 검토를 통한 요구사항정의서 정리
고객사-수행사 협의를 통한 요구사항 확정
수행사 검토를 통한 수용여부 확정 - 수행사의 프로젝트팀 전체가 함께 검토함
수행사-고객사 협의를 통한 최종 요구사항 확정
이 글은 제 개인적인 경험을 바탕으로 작성되었습니다. 댓글을 통해 부족한 부분은 채우고, 다른 부분은 맞춰갈 수 있길 희망합니다.
이런 맥락에서 일까, 사용자 인터뷰에도 항상 직접 참여할 것을 강조했다. 사용자 인터뷰를 보고받는 것이 아닌 그 현장과 과정을 관찰해야 한다는 것이다.
왜 고객에 대한 이해를 전문가 수준이 되어야 할 정도로 강조하는 가에는 제품관리자의 핵심 역할 중 하나인, 제품의 발견과 관련이 깊은 듯 하다.
데이터에 대한 이해 또한 강조한다. 사내 데이터 전문가가 있다 할지라도 본인이 궁금한 건 직접 데이터로 해결할 정도는 되어야 한다고 소개한다. 정확히 말하면, 데이터를 보고 분석하는 것을 남에게 전가하면 안된다고 본다. 제품관리자에게 있어 데이터 분석 업무는 하루 업무의 시작이다.
비즈니스에 대한 깊은 이해도 필수적이다. 여기서 산업과 책임이 중첩되는 것은 아닌가 할 수 있다. 여기서의 비즈니스는 비즈니스 모델에 대한 이해를 의미하는 듯 하다. 비즈니스를 이해하는 것은 곧 이해관계자를 파악하는 것이다.
그렇다면 제품관리자는 왜 이러한 역량이 요구되는가? 책에서 소개하는 제품관리자는 백로그만 추적하는 사람이 아니다. 책이 바라는 제품관리자는 업무를 실행하는 사람이다. 내가 보기에 이것은 하나의 창업과도 같다. 자기 자본으로 창업을 하는 게 아니라면 창업가는 무수한 투자자를 만나 자신의 아이디어를 소개하고 그들을 설득해내야 한다. 그리고 제품관리자는 사내 인력을 제품관리자가 바라는 업무에 배치하고 또 실행하고 위해선 무수한 이해관계자들을 설득하는 과정이 필요하다. 이때 지피지기면 백전백승이라 하니 이해관계자를 이해하고 파악하는 건 필수적이라 할 수 있을 것이다.
마지막으로 산업에 대한 이해이다. 시장과 산업을 이해해야 하는 이유는 비교적 간단하다. 경쟁자보다 확연히 나은 제품을 만들어야 하기 때문이다. 책도 알고 있고 우리도 알고 있듯 이제 단순히 경쟁자와 똑같은 제품만으론 시장에서 성공하기 어렵다. 그냥 딱 봐도 나은 제품이어야 한다.
2. 제품관리자의 역량
위에 책임을 기술했다면 이번엔 내가 읽으며 느낀 제품관리자에게 필요한 역량이다.
개인적으로 느낀 제품관리자에게 필요한 역량은 학습능력이다. 물론 책에서도 제품관리자의 역량으로 소개된다.
정확히 말하면 성공적인 제품관리자가 되기 위해서 똑똑하고 창의적이고 집요해야 한다고 한다. 여기서 똑똑하다는 것은 지적 호기심이 많고 빠르게 학습할 수 있는 능력이라 한다. 이러한 역량에 내가 이해한 바를 한 스푼 더하자면 바로 어떤 상황이든 유의미한 인사이트를 끌어낼 수 있는 학습능력이다.
책에서 소개한 제품 발견 계획 기법 중 고객 발견 프로그램 기법이 있다. 간단히 말하면 참조고객과 함께 제품을 발견하는 기법인데 이때 참조 고객은 실제 돈을 내고 사용하는 것에서 나아가 다른 이들에게까지 제품에 대한 찬사와 함께 제품을 소개하는 이들을 말한다. 제품 발견을 위해 참조 고객을 통해 검증해가는 것이 매우 효과적인데 만약 제품 발견 계획 기법을 실행하려는 팀에게 참조고객이 구해지지 않는다면? 제품관리자는 바로 이 상황에서조차 한가지 배울 수 있다. 어쩌면 팀이 풀고 있는 문제는 그다지 중요한 문제가 아닐 수 있다는 것이다.
고객의 일탈 행동에서도 제품관리자는 무언갈 배울 수 있다. 이베이는 Everything else라는 카테고리를 만들었는데 말 그대로 기존의 카테고리 이외 모든 것을 거래할 수 있는 카테고리이다. 그리고 이 카테고리 덕에 이베이는 세계 최대 중고차 거래 회사가 되었다고 한다. 이러한 고객의 일탈을 통해 어떤 수요가 있는지 제품관리자는 학습할 수 있어햐 한다는 것이다.
전자는 계획하지 않았던 상황에서 얻은 인사이트이고 후자는 계획된 것이외의 상황을 예측해 얻어낼 수 있는 인사이트이다. 어떠한 상황이 되었든, 상황이 계획대로 흘러가든, 계획대로 흘러가지 않든 어떤 상황에서도 고객, 데이터, 비즈니스, 산업에 대해 유의미한 자료, 즉 업무에 활용할 수 있는 자료를 학습할 수 있어야 하는 것 같다.
3. 제품관리자는?
아직 책을 끝내지 못했고 모든 내용을 파악하지 못했다. 지금까지 읽으며 느낀 제품관리자는 마치 감독과 비슷하다 할 수 있을 것이다.
"제품이 성공하면 그건 팀의 모든 사람이 제 역할을 해냈기 때문이다. 하지만 제품이 실패하면 그건 제품관리자의 잘못이다."
