[주니어 PM의 협업] 개발, 기획 리뷰
너, 내 동료가 돼라.. 아니 되어주세요
이번 글에서는 디자인 이후, 개발 단계에서 진행되는 일들을 다뤄보고자 합니다.
디자이너와의 협업에 대한 내용은 이전 글을 참고해 주세요.
1. 도입 배경
특히 개발이 진행되는 단계에서, 기획 시 고려하지 못한 로직이나 정책, 영향 범위 등으로 인해 예측하지 못했던 케이스들이 뒤늦게 수면 위로 떠오르는 경우가 많은데요, 이로 인해 발생하는 비효율을 최대한 방지하고자 기획 리뷰를 도입하게 되었습니다.
기획 리뷰는 디자인 초안이 완성된 이후 PM/디자이너/개발자/QA가 한 자리에 모여 진행됩니다.
태스크의 스콥을 고려하여 진행 여부를 판단하고 있으며, 만약 새로운 기능이 추가되거나 로직이 수정되는 경우라면 대부분 필수적으로 진행하고 있습니다.
2. 진행 방식
0) 기획서 구성
매끄러운 논의 진행을 위해, PM이 기획안을 사전에 잘 구성해 두는 것 또한 중요합니다. 저의 경우, 아래 내용이 특히 잘 담길 수 있도록 노력하고 있습니다.
[기획안 구성]
- 기획 배경 : 해당 태스크 진행 배경, 목표
- 유저 플로우 : 유저가 경험하게 될 전체적인 여정
- 요청 사항 : 위를 구현하기 위한 개발 요청 사항
만약 디자인 와이어프레임이 구성된 상태라면, 이도 함께 추가하여 가시성을 높입니다.
1) 맥락 및 task 파악
본격적인 개발 일정이 시작되기 전, 약 30분 간 전체적인 맥락을 파악하고 요구 사항을 검토합니다. 전체 기획을 담당하는 PM에게는 꽤나 긴장되는 순간이기도 한데요 -
기획안을 토대로 전체적인 맥락과 요청사항을 PM이 전달한 후, 디자이너, 개발자, QA가 기존 정책이나 로직을 중심으로 검토하며 질문을 주고받는 식으로 진행됩니다.
이때 저는 화이트보드를 애용하는데요, 참가자 각각이 개인의 모니터에 집중한 상태에서는 몰입도가 자연스레 떨어지기 쉽다고 생각했기 때문입니다.
화이트보드, 이면지를 끼고 사는 사람입니다동시에, 참여도나 의견 제시의 자유도를 높이는 데에 있어서도 적절한 장치라고 판단했는데요 -
이미 채워져 있는 기획안이 아닌 대주제만 적혀있는 화이트보드에서 서로의 의견을 주고 받을 때, 훨씬 편안한 분위기에서 자유롭게 논의가 이뤄지는 것을 실감할 있었습니다.
2) 추가 논의
발생할 수 있는 여러 케이스를 정리하고, 의견을 나누다 보면 개발적으로 미처 고려하지 못했던 예외케이스들을 발견하게 됩니다.
이때 디자이너는 UI/UX 측면에서 어색하지 않은지, 개발자는 개발 구조상 충돌되는 건은 없는지, QA는 정책 간 어긋나는 부분은 없는지를 중심으로 기획안을 살펴보게 됩니다. 기존 프로덕트의 맥락을 가장 잘 알고 있는 담당자가 한 자리에 모여 있는 것이기에, 빠른 호흡으로 의사결정을 진행할 수 있는 것 또한 큰 장점입니다. (어벤저스 못지 않은 든든함을 느낄 수 있습니다.)
만약 기존 정책으로 인한 복잡도가 예상보다 높다면, 스콥을 수정하거나 일정을 수정하는 등의 의사결정이 요구되기도 합니다.
3) 요청 사항 확정
여러 차례 질문 - 답변을 주고받으며 대략적인 논의가 완료되었다면, PM은 디자인 추가 요청 사항, 최종적인 개발/QA 사항을 문서 내에 업데이트하고 미팅을 마무리합니다.
최종적 요청 사항은 체크리스트 형태로 정리합니다. 3. 돌아보며
최근 담당하는 프로덕트에서 퍼널을 완전히 (!) 리뉴얼하는 태스크를 진행했었는데요, 이때 기획 리뷰가 큰 도움이 되었습니다. 처음으로 진행되었음에도 불구하고, 모두가 적극적으로 참여했던 덕에 에너지 넘치는 분위기에서 진행할 수 있었어요. 결과적으로, 태스크의 스콥이나 복잡도가 매우 높았음에도 불구하고 빠르고 정확하게 배포를 진행할 수 있었습니다. 이를 가능하게 했던 기획 리뷰의 장점들을 돌아보자면 아래와 같습니다.
1) 높은 이해도
기획 리뷰의 가장 큰 장점은 모든 참여자의 이해도를 압도적으로 끌어올릴 수 있었다는 점입니다.
기획 리뷰의 경우 '솔루션'이 아닌, 본질인 '문제'를 기반으로 논의가 진행됩니다.
PM이 프론트엔드/백엔드 개발자, 디자이너 등 담당 업무 단위로 소통하는 경우 문제에 대한 이해의 범위가 제한되기 쉬운데요. 기획 리뷰에서는 문제를 충분히 파악하고 이를 중심으로 논의가 진행되기에, 최적의 솔루션을 함께 찾아나가는 경험을 가져갈 수 있다는 점이 특히 좋았습니다.
2) 더 좋은 솔루션을 위한 논의
문제나 요구 사항에 대해 충분히 이해한 상태에서 개발이 진행되기에, 커뮤니케이션이 아닌 작업에 집중할 수 있었다는 점도 좋았습니다. 단순히 작업 속도가 높아졌다는 점 외에도, 문제를 해결하기 위한 '더' 좋은 해결책은 무엇일까를 중심으로 논의할 수 있었다는 점이 특히 의미 있었는데요 -
기획 리뷰를 통해 공통 문제를 인식하고, 각자의 하드 스킬을 통해 문제를 해결해 나간다는 의식을 가질 수 있었기 때문이 아닐까 생각합니다.
기획 직후 진행되는 디자인에서의 소통 볼륨에 비해, 개발 단계에서의 논의가 상대적으로 부족하다는 것을 깨달았을 때, 특히 죄송하고 부끄러웠습니다. 늘 개발은 그냥 하면 된다며, 묵묵하고 든든하게 자리를 지켜주시는 분들이기에 더욱이 그랬던 것 같습니다.
이후에는 의식적으로 기획단에서의 소통을 늘려가고자 노력하고 있습니다. 늘 물음표와 함께 찾아가는 저라도 흔쾌히 반겨 주시는 개발자 분들께 감사를 전하며 글을 마무리합니다.
ps) 기획 리뷰를 준비하며 실제로 참고했던 자료들을 참고차 첨부합니다.
