너, 내 동료가 돼라.. 아니 되어주세요
프로덕트를 개선하는 과정에서 PM이 경험하는 전반적인 협업을 다루고 있습니다. 이번 글에서는 배포 전 진행되는 CX/QA 와의 협업에 대해 다루고자 합니다. 이전 글은 아래 링크를 참고해 주세요.
기능 개발이 완료된 이후에는 QA 단계가 진행됩니다.
이 과정에서는 기획 의도에 맞게 구현이 완료되었는지, 신규 기능이 추가됨으로써 기존 시스템에 발생할 수 있는 버그가 없는지 등을 검토하며, 각 유저 관점에서 발생할 수 있는 문제들을 면밀히 확인합니다.
이처럼 QA는 단순히 하나의 태스크를 점검하는 것을 넘어, 프로덕트의 안정성과 신뢰도를 확보하는 데 핵심적인 역할을 합니다.
얼마 전까지만 해도 저희 팀에서는 QA의 역할을 별도로 분리하지 않고, PM - 디자이너 - 개발자가 함께 모여 QA를 진행해 왔는데요. 팀과 제품의 규모가 점점 커지며 QA 매니저를 모시게 되었습니다. QA 매니저와의 협업이 새롭게 시도됨에 따라, 팀적으로도 여러 유의미한 변화가 있었습니다.
기존에는 태스크를 직접 개발한 담당자가 배경이나 맥락을 충분히 이해하고 있었기 때문에, 간단한 맥락 공유만으로 QA를 진행할 수 있었습니다. 그러나 QA 매니저와 협업하게 되면서, 각 테스트 케이스를 꼼꼼히 점검하고 전후 맥락을 세세히 전달하는 과정이 매우 중요했습니다.
이전에는 하나의 태스크의 완결성에 집중했다면, 이후로는 프로덕트 전반에 미치는 영향을 함께 고민하게 되었는데요. 이로 인해 기획 단계에서 훨씬 깊이 있는 고민과 액션 설계가 필요했기에, 개인적으로도 크게 성장할 수 있었습니다.
현재 저희 팀은 Jira와 같은 협업 툴 없이 노션을 활용해 협업을 진행하고 있습니다.
기존의 경우 개발/디자인 요청시 전달하는 스토리 문서가 메인 기획안으로 활용되며, 이후에도 해당 문서를 통해 히스토리를 파악해 왔기에 별도의 정책서는 존재하지 않았는데요. 사업부에서 여러 사업을 새롭게 시도하게 됨에 따라 전체 히스토리를 한 눈에 볼 수 있는 문서의 부재가 큰 문제로 떠올랐습니다.
핵심 맥락을 파악하기 위해서는 해당 태스크를 담당했던 팀원과의 추가적인 소통이 필요했기에, 커뮤니케이션 과정에서의 비효율이 지속적으로 발생했기 때문이에요. (매주 새로운 일이 창발되는 스타트업에서는 커뮤니케이션 비용을 최소화하는 것 또한 매우 중요한 일입니다.)
해당 문제를 해결하고 이해도의 간극을 최소화하기 위해, PM-디자이너-개발자, 그리고 QA가 모여 점심시간마다 스터디를 진행하게 되었습니다.
스터디의 목표는 단 하나. "하나의 정리된 문서를 통해 프로덕트의 히스토리를 파악할 수 있도록 하자. 그리고 앞으로도 잘 쌓아가자."는 것이었습니다.
가장 먼저, 여러 스토리 문서에 산재되어 있었던 정책들을 하나의 문서에 정리하는 것부터 시작했습니다.
각 프로덕트를 구성하는 여러 퍼널에 대해 유저 사이드에서 확인되는 화면 구성부터 백오피스, CRM 등을 한 판으로 정리하고, CX/QA 매니저와 함께 내용을 검토하며 서로 간의 그라운드 룰을 잡아가기도 했습니다.
해당 스터디를 통해 기존 정책을 정리할 수 있었을 뿐만 아니라, 앞으로 더욱 구조적으로 협업을 진행하기 위해, 어떤 노력들이 필요할지에 대해서도 함께 고민할 수 있어 유의미한 시간이었습니다.
스터디가 종료된 지금도 해당 DB는 적극적으로 활용되고 있는데요. 의식적으로 각 프로덕트를 담당하는 PM이 루틴 하게 정책서를 업데이트하는 방식으로 문서를 관리해 나가고 있습니다.
CX는 고객의 목소리를 최전선에서 듣고 소통하는 직군입니다. 고객의 목소리를 전해주시는 메신저 역할을 해주시기도 하는데요. 전달주시는 의견이나 인사이트를 통해 프로덕트의 방향성에 대한 힌트를 얻거나, 개선해야 할 점들을 새롭게 발견하기도 합니다.
고객이 갖고 있는 궁금증을 해소하고, 상황에 맞는 도움을 제공하는 것이 특히 중요하기에, CX 매니저가 담당하는 프로덕트에 대해 높게 이해하고 있는 것 또한 매우 중요한데요 -
CX 매니저 분들께서 빠르게 프로덕트의 핵심만 파악할 수 있도록, 큰 프로젝트가 마무리되는 시점에는 관련 내용을 한 판으로 정리하여 전달드리고 있습니다.
프로덕트의 타겟이나 구성에 대해 높이 이해하고 있다면, 적합한 페인포인트를 가지고 있는 고객에게 프로덕트를 맞춤형으로 추천하고, 이에 대한 도움을 제공하기도 훨씬 쉬워지기 때문입니다.
매순간 새로운 프로젝트가 창발 되는 스타트업에서 룰을 정하고, 지켜나가는 것은 생각보다 쉽지 않습니다. 그럼에도 불구하고 더 좋은 협업을 위해서는 어떤 시도들이 필요할까를 고민하는 것은 나에게도, 우리에게도 유의미한 일임을 다시 한 번 깨닫습니다.
늘 많은 시도와 변화 속에서 큰 안정감을 주시는 스쿼드 분들께 깊은 감사를 전하며, 글을 마무리합니다.