프로덕트 Requirements
요구사항 정리
PM은 프로덕트의 요구사항을 명확히 정리하는 역할을 해야 한다. 프로덕트의 컨셉 혹은 사업에 따라 그에 맞는 요구사항을 파악하여 정의해야 원활하게 제품의 개발이 시작된다. 프로덕트 또는 프로젝트를 시작할 때 사업부서나 VOC, 현장 등 많은 개선, 건의 사항 등 다양한 것들을 고려해야 한다. 참 신기한 것이 모든 요구사항들은 다 급하고, 빠르게 해야 하고, 저 기능이 없으면 안 되고, 사업적으로 심각하고, 대표님 지시사항이고.. 모두 그런 내용들 뿐이다. 시간과 리소스는 한정적인데 모두 다 할 수는 없다. 가장 먼저 요구사항을 잘 정리하고, 그 정리된 내용으로 사업/개발과 협의하여 우선순위를 정하고, 기능명세를 작성하거나 개발기획에 넘기는 순서가 될 것이다. 요구사항을 어떤 방식으로 정리하면 좋을지 한번 생각해 보자.
크게 신규 Product와 운영 Product로 나눌 수 있다. 신규 프로덕트의 경우에는 컨셉 문서 혹은 MRD가 작성이 되어 있는 경우가 있다. 이런 문서가 없더라도, 기획 문서나 하고자 하는 방향성이라도 보고된 자료가 있을 것이다. 가장 좋은 건 신사업기획서나 MRD(Market Requirements Document)가 있으면 좋다. 이 프로덕트가 왜 필요한지 어떤 방향성으로 사업을 할 것이고, 어느 기간에 어떤 성과를 낼 것인지 내용이 있는 경우면 요구사항을 정리하기가 용이하다. 이런 경우에는 사업적 방향을 이해하고, 우리 개발 리소스나 기술력으로 가능한지 파악하고, 타업체에 외주를 줘야 할 항목이 있는지, 직접 해야 하는 항목이 있는지, 모바일, 서버, DB, Client, HW구성 등 다양한 부분에 대해서 검토해서 요구사항에 정의한다. 너무 규모가 큰 경우라면 개발자들과 상의하여 연간 프로젝트로 마일스톤으로 쪼개어 요구사항을 정의할 수도 있고, 비교적 작은 경우라면 요구사항을 한 번에 정의할 수도 있다.
운영 프로덕트의 경우에는 보통 개선이나 건의 혹은 서비스 단위의 업데이트가 많다. 이런 경우에는 요구사항이 문서로 정리되기보다는 회의나 메일, VOC 등을 통해 전달받는 경우가 많다. 해당 내용들을 리스트화하고, 난이도와 우선순위에 따라 분류를 하면 좋다. 현장에서 바로 올라오는 요구사항 중에는 정말 개인적이거나 우리 서비스에 맞지 않는 경우가 많다. 또한 서비스의 방향성과 개발의 대정책에 위배되는 경우도 허다하다. 이런 부분을 잘 걸러주고, 사업 또는 현장에 이해시키는 부분도 중요하다고 생각한다. 그래야 개발기획단계로 넘어갔을 때 불필요한 내용에 대한 검토를 줄이게 되어 리소스와 시간이 아낄 수 있다.
PRD는 이해관계자들이 이해할 수 있는 문서로 작성해야 한다. 우리가 무엇을 만들 것인지에 대한 내용을 표현해야 하며, 각 분야의 개발자 및 디자이너들이 공감할 수 있어야 한다. 개발자들은 전문분야가 많이 쪼개져 있어서 프론트, 백엔드, UX, DB, 서버, 클라이언트 등 각 분야에서 자기가 해야 하는 부분만 보는 경우가 많아서 그런 경우에는 구분해서 작성해 주면 더 이해시키기가 편하다. PM은 문서를 많이 만들어야 하는데, 나중에도 이야기하겠지만, 컨셉, 명세서, PRD, 백로그, 일정표 등 많은 문서를 만든다. 하지만 PM은 문서만 만들어내는 것이 아니라 문서 뒤에 숨은 의도를 전달하는 사람이다. 사실 간단한 부분은 문서보다 회의를 통해 그림으로만 표현해도 무방하다고 생각한다.
[프로덕트 요구사항]미국과 협업하면서 있었던 비교적 최근 경험이다. 미국법인 내 PM과 커뮤니케이션을 자주 한다. 물론 현장에서 이슈도 많고, 한국 직원들과 미국 직원들 사이에서 매우 고생하고 있다는 것은 알고 있다. 하지만 항상 요구사항을 말할 때 화상 회의에서 말로 설명하고, 메신저로 설명을 한다. 직접 만나서 이야기하는 것도 아니고, 문서로 "왜" 필요한지, "어떻게", "뭘"하고 싶은지 요구사항을 작성해 달라고 해도 항상 말로만 하는 사람이 있었다. 그러다 보니 실제 업데이트 진행 하기 직전에 제품을 보고, 의도한 게 아니었다며 긴급하게 변경 요청을 한다. 그러면 이해관계자들이 모두 혼란이 생기며, 일정과 리소스 관리도 안되고 업데이트 일정도 항상 밀리는 경우가 자주 발생했다. 기준이 되는 문서가 없으면 혼란만 발생하며, 제대로 진행이 될 수 없는 사례라고 생각한다. PM은 명확한 요구사항을 PRD로 명확히 표현하여 전달해야 혼선 없이 프로젝트가 원활히 이루어진다.
PM은 문서만 만드는 역할은 아니다. 다만 그 제품에 대해 왜 만들어야 하는지, 어떻게 만들어야 하는지 그 의도와 의미를 이해관계자들에게 인식시켜 주는 것이 매우 중요하다고 생각한다. 많은 이해관계자들에게 모두 말하며 설명할 수 없으니, 모두 이해될 수 있도록 잘 만든 문서 한 장이 매우 중요한 역할을 한다고 생각한다.
*요약
요구사항의 끝은 개발자와 디자이너 등 이해관계자가 "이걸 왜 이렇게 만들어야 하는지.."를 완벽하게 이해하는 상태여야 한다. 이해를 촉진하는 역할이 PM이다.