애자일 사상을 바탕으로 협업하기
크로스 펑셔널 팀의 프로덕트 오너
"잘나가는 서비스 기획자 도그냥은 왜 PM/PO가 되었을까?" 리뷰 2편.
주니어 PM의 시선에서 배우고 느낀 점을 정리해 본다.
기획자/PM/PO의 역할
기획자가 모든 것을 결정한다고?
기획자는 보통 프로젝트의 전반적인 진행 상황을 이해하고 있어야 하며, 주요 의사결정에 직접적으로 관여하게 된다. 심지어 모든 옵션을 기획자가 이해한 후에 결정하고, 개발자는 정리된 일만 하면 되는 프로세스를 가진 조직도 존재한다.
그러나 세부적인 옵션의 경우에는 개발/디자인 직군의 주도 하에 결정해 나가는 것이 더 효율적일 때가 많다. 만약 세세한 부분들까지 기획자가 모두 이해하고 결정해야 한다면, 개발/디자인 직군의 커뮤니케이션 에너지가 소모될 뿐만 아니라 프로젝트 진행 속도마저 더뎌질 것이다.(물론, 개발/디자인 직군의 커뮤니케이션 중요도가 낮다는 것은 아니다.)
비즈니스 임팩트로 설득하라
다양한 직군의 능동적인 참여를 통해 굴러가는 크로스 펑셔널 팀의 PM/PO가 해야 하는 중요한 역할은 따로 있다. 개발자/디자이너가 이 작업을 왜(Why) 해야 하는지, 즉 '목적'을 전파하는 것. 수치적 근거를 바탕으로 한 비즈니스 임팩트를 명확하게 설명할 수 있어야 한다.
‘당연히 해야 되니까’, ‘더 많은 발전을 위해’와 같은 뻔한 문장으로는 팀원을 설득하기 힘들다. 이 일을 하는 것이 지표의 성장에 어떤 식으로 기여하게 되는지 논리적으로 풀어낼 수 있어야 한다.
애자일 프로젝트 방법론
애자일(Agile) 소프트웨어 개발 선언의 핵심 사상
포괄적인 문서도 중요하지만, 작동하는 소프트웨어가 더 가치 있다.
계획에 따르는 것도 중요하지만, 변화에 대응하는 것이 더 가치 있다.
기획 직군이라면 누구든, 기획서를 완벽하게 만들고 싶은 욕심이 생긴다. MBTI 'J' 호소인이 되어 프로젝트 로드맵을 촘촘하게 수립해보기도 한다.
하지만 스타트업의 PM/PO라면 이 욕구들과 적당히 타협하고, 위 애자일 사상을 받아들이는 것이 좋다(정신 건강에 이롭다). 기획자의 관점에서 아무리 완벽한 기획서를 작성하더라도, 디자인 및 개발이 진행되다 보면 기획 방향이나 로드맵을 조정해야 하는 일이 많이 발생한다. 어떻게든 빠르게 결과물(프로덕트)을 만들고 시장의 반응을 보며 개선해 나가는 것이 중요하다.
스크럼 프레임워크
애자일 사상에 대한 이해와 합의 하에서 효율적으로 협업하는 방식을 알아보자. 우선, 프로덕트 오너, 개발자, 디자이너가 모여 크로스 펑셔널 팀을 이룬다.(스크럼 마스터, QA 담당자가 별도로 존재할 수 있음)
PO는 프로덕트의 방향성에 대한 의견을 내는 이해관계자(고객, 타 팀 동료 등) 모두와 커뮤니케이션하며 필요한 기능을 프로덕트 백로그에 정리한다. 이때, 이 기능이 필요한 이유와 목적도 함께 정리되어야 한다.
스크럼은 1~4주 정도를 기간으로 하는 스프린트 단위로 구성되는데, 한 스프린트 동안 작업할 백로그를 리뷰하여 Task로 선정하는 스프린트 플래닝 미팅을 먼저 진행한다. 정해진 백로그와 목표는 웬만하면 바뀌지 않는 것이 좋지만, 외부 경쟁사 이슈 등이 발생하면 바뀔 수도 있다.
그리고, 매일 작업 내역과 현황을 15분 내에 공유하는 데일리 스크럼 또는 스탠드업 미팅을 진행한다. 스프린트를 마무리할 때에는 디자인/코드를 리뷰하고, 완료한 백로그의 배포 결과를 회고하며 스프린트를 종료한다.
개발 효율 측면에서의 완결성 vs 효용성
기능의 완결성을 추구한다는 것
최대한 많은 케이스와 확장 가능성을 고려하여, 지금 당장 필요한 기능이 아니더라도 일단 개발 설계에 녹인다.
기능의 효용성을 중시한다는 것
확장 가능성을 고려하지 않고, 당장 오픈하고자 하는 한 가지 기능에 집중하여 개발한다. 이후 필요가 생겼을 때 기존 시스템을 허물고 다시 개발하는 것을 기꺼이 감수한다.
같은 시스템을 두 번 개발하는 것보다, 아직 필요하지도 않은 것을 개발하는 것이 더 비효율적이다.
평소에 프로덕트 팀원들과 함께 기획 Scope를 정의할 때 항상 고민되는 지점이 있었는데, 이것이 완결성과 효용성 사이에서의 갈등이었다는 것을 깨달았다.
기왕 하는 김에 완결성을 높이는 것이 좋다는 생각이 들 수 있지만, 그렇게 하면 결국 작업 범위와 기간이 늘어나 빠르게 가설을 증명하기가 힘들어진다. 기능의 비즈니스 임팩트를
뾰족하게 정의하고 그에 맞는 적절한 범위의 기획을 뽑아내는 것이 중요하다.
