디자이너/개발자에게 요구사항은 어떻게 전달하나요?
PPT, 노션, 피그마를 고민하는 당신에게
나도 주니어지만 같은 주니어 PM들에게 자주 듣는 질문이 있다.
"디자이너에게 요새는 피그마로 전달하나요?"
"플로우 차트는 만드는 게 좋나요?"
"PPT에 디스크립션 적는 게 좋나요?"
사실 정답은 없다.
본인이 처한 상황에 따라, 요구사항에 대한 작업자나 누구인지에 따라, 어떤 요구사항인지에 따라, 전달하기 좋은 방법은 다르기 때문이다.
전환율을 높이기 위한 UX 개선을 한다면, 현재 발생하는 문제와 해결책에 대한 가설을 검증하기 위해 가설과 근거를 기반으로 어느 정도 UI에 대한 요구사항이 담긴 와이어프레임이 필요할 수 있다.
반면, 히스토리가 많이 쌓여있고, 정책서가 중요한 백엔드 단에는 정책서가 중요할 수 있다. 시각화된 툴보다는 기존 정책이 무엇이고, 이번에 어떤 정책을 어떤 사유로 어떻게 개선하는지에 대한 명세가 더 중요할 수 있다.
또한, 정책서가 중요한 시스템 도메인의 경우, 위키에 변경된 정책에 대해 꾸준히 업데이트하며 관리해야 할 것이다.
하지만 여기서 우리는 가장 중요한 사실을 놓쳐서는 안 된다.
완벽한 기획서보단, 작업자와 완벽히 싱크를 맞췄을 때
요구사항을 충족한 결과물이 나올 수 있다.
빈틈없이 완벽한 기획서를 만들어 개발자에게 전달한다고 하면, 과연 개발자는 요구사항에 꼭 맞는 개발을 해낼 수 있을까?
꼭 그렇지만은 않다. 문서나 플로우 차트 등으로 충분히 직관적으로 전달할지라도, 그것을 개발자가 100% 이해했을 것이라는 보장이 없다.
프로덕트 매니저의 역할은 단순히 기능 기획을 잘하는 것이 아니다.
내가 생각한 프로덕트 매니저의 역할은 다음과 같다.
1. 내 제품의 내/외부 고객 요구사항을 검토해 문제를 정의하며,
2. 정의한 문제를 해결하기 위한 최적의 기능을 기획을 하고,
3. 작업자(개발자/디자이너)와 싱크를 맞춰 문제를 해결할 기능을 만들어내고,
4. 결론적으로 문제를 해결해낼 수 있도록 한다.
그렇기 때문에, PM은 요구사항은 어떤 배경으로, 왜 생겨났으며, 이 문제를 해결하기 위해 어떤 방법으로 작업해야 하는가를 작업자가 100% 이해할 수 있도록 만들어야 한다.
그러므로, 모든 맥락과 검토 내용, 히스토리는 문서에 기록하되, 이 모든 내용을 작업자에게 시간을 잡아 리뷰하며, 작업자가 제대로 이해했는지 역으로 되물어보기도 하며 제대로 싱크(sync)를 맞추기 위해 노력해야 한다.
이렇게 정리해보면, 요구사항을 전달하는 도구는 그렇게 중요하지 않다.
요구사항이 변경되었다면, 그때에 맞춰 즉각 변경된 사항을 작업자에게 이해시키고 싱크를 맞추어야 한다.
그래서 나는 이런 방법으로 기획문서를 작성한다.
(이렇게 작성하려고 노력한다.)
1. 우리 제품에 요구사항이 생겨난 배경에 대해 검토하며, 과제를 정의한다.
2. 과제를 통해 해결해야 할 문제와 목적을 정리한다.
3. 과제를 해결하는데 풀어야 할 영향범위와 영향도에 대한 검토를 기록한다.
4. 영향범위를 모두 고려해, 우리 팀에서 작업해야 할 요구사항을 정의한다.
5. 검토/기획하며 쌓이는 논의와 변경된 요구사항 등 히스토리와 결론을 함께 기록한다.
문서는 대외비이므로, 목차만 첨부하겠다그리고, 이렇게 개발자와 싱크를 맞춘다.
1. 개발이 들어가기 전 기획/검토 기간에 함께 검토할 개발자의 리소스를 확보한다.
2. 작업 사항에 대해 개발자에게 위키(문서) 리뷰와 함께 싱크를 맞춘다.
3. 작업자로부터 작업 사항을 역으로 리뷰받는다.
- 요구사항이 복잡한 과제의 경우, PM의 일방적인 설명으로는 개발자가 100% 이해했는지 확인하기 어렵다.
- 이럴 땐 역으로 기획 리뷰를 받아보는 것도 싱크를 맞추는데 큰 도움이 된다.
4. 고객(예: 사업실)의 요구사항이 달라지면, 변경사항과 작업 내용에 대해 짧게 싱크를 맞춘다.
- 재택근무로 인해 주로 슬랙 메시지로 소통하다 보니, 슬랙 허들 기능을 이용해 짧게 3~5분 두구로 싱크를 맞추고 슬랙 & 문서에 정리하여 기록한다.
변경사항이 생길 땐 짧게 시간을 잡아 싱크를 맞추는 것이 많은 도움이 되었다.결국 우리가 기획을 하는 이유는 고객에게 좋은 결과물을 제공하기 위함이다. 하지만 초년생 때에는 기획서에 대해 피드백을 많이 받게 되면 내가 일을 못한다고 생각하는 경향이 있다. 그래서인지 기획 툴에 조금 더 집착하는 경향이 있는 것 같다.
단순히 개발을 하거나 디자인 시안을 만드는 것이 아니라, 그것이 고객에게 얼마나 큰 감동을 줄 수 있는지 각자 충분히 인지할 수 있도록 설명하는 것도 PO의 몫이다.
- 김성한 님의 <프로덕트 오너> 중 일부 발췌-
PM의 역할은 기획을 넘어 좋은 제품을 제공하는 것이다. 그렇기 때문에 당장 내가 받은 기획에 대한 피드백들을 잘 반영하고, 이것을 만들어낼 수 있도록 작업자들을 설득하며 합을 맞추는 것이 더 중요하다는 것을 말하고 싶었다.
그러니 기획서로 일희일비하지 않았으면 한다. 받은 피드백을 두려워하지 말고, 의논하며 반영해내는 과정이 곧 당신이 성장하는 과정이라는 것을 잊지 않았으면 한다.
