[월간 글쓰기] 한 달에 한 편, 글을 씁니다. 기획자로 커리어를 밟아가며 느낀 점들을 가감없이 풀고, 기록합니다. 작성일 : 2022. 3. 4 Title 18. PO(Product Owner

[월간 글쓰기] 한 달에 한 편, 글을 씁니다. 기획자로 커리어를 밟아가며 느낀 점들을 가감없이 풀고, 기록합니다. 작성일 : 2022. 3. 4 Title 18. PO(Product Owner)란 PO(Product Owner) 직군이란? 잘나가는 IT 회사에서 일하는, 소위 agile 한 조직 구성엔 PO/PM이라 불리는 직군이 있다. Product Owner, Product Manager이라고 한다. IT업계가 일하는 방식이 변화하면서 새로 생긴 직군이다. 회사 크기마다 PO/PM 업무 범위가 다른 듯하다. 이전에 기획자 직군의 사람들이 자연스레 PO/PM으로 포지션 변경하고 있다. 나 역시 서비스 기획자에서 PO로 넘어온 케이스이긴 하나 사짜?에 가깝다. 직전 회사에서는 PO였지만 IT 서비스를 운영하지는 않았고, 지금은 서비스 기획팀장으로 있으니. 기왕 팀을 리드하니 agile 조직 문화를 도입하여 PO/PM이 프로덕트를 주도하여 성장시키는 조직을 만들고 싶었다. PO 체계를 제대로 갖췄다고 생각한 회사들의 채용공고, 기술 블로그, 책, 교육 플랫폼의 커리큘럼 등을 찾아봤다. 그동안의 실무 경험에 비추어 볼 때 기획자가 했던 일(50%)+PO/PM으로 하는 일(50%)이 있다고 결론 내렸다. 그래도 기획자 류 직군(서비스 기획자, UX 기획자 등)과 PO/PM이 요구하는 역량은 꽤 다르다. 더 큰 회사일수록 PO에게 요구하는 역량은 더 크고, 전략적이다. PO(Product Owner)는 뭐 하는 사람인가? PO는 스쿼드(혹은 사일로) 팀을 리드하는 사람이다. 이 정의를 이해하려면 agile과 목적 지향 조직(cross-functional team)을 먼저 이해해야 한다. agile 이란, 쉽게 말하면 빠르게 개발하기 위한 IT 개발 문화이자 방법론이다. 예전엔 IT 서비스를 개발할 때 소위 폭포수 방법론(waterfall)을 썼다. 기획자가 기획을, 디자이너가 디자인을, 개발자가 개발을 했다. 이론 상 문제가 없다. 그러나 가장 큰 문제가 있다. 워터폴 방법론의 가장 큰 문제는 속도가 너무 느리다는 것이다. 기획자가 정의한 요구사항을 본 디자이너와 개발자는 나름대로 작업을 한다. 그런데 결과물은 기획안과 전혀 다르다. 왜 이런 문제가 발생하는가? 기획자가 아무리 기획을 잘 해도 구멍은 발생하고, 디자이너와 개발자는 그것을 메꾸기 위해 나름대로 보완한다. 그러다 안되면 기획자한테 얘기한다. 그때 되면 너무 늦어서 다른 방안을 만들어 내기가 어렵다. 그래서 기획을 다시 시작하거나 어정쩡한 대안을 만든다. 시간과 노력을 투자한 것 대비 결과물이 제대로 안 나온다. 급변하게 변화하는 IT 트렌드에 맞추기 위해선 빨라야 했다. 이때 등장하는 개념이 lean, MVP, agile 등이 있는데, 핵심은 결국 불완전하지만 짧은 주기로 빠르게 만들어서 배포하자는 것이다. 이것이 agile 문화이자 방법론이다. 그런데, agile 하려면 조직 구조가 바뀌어야 했다. 기획/디자인/개발로 구분하는 것을 기능지향조직이라고 한다. 대부분 기업에서 이와 같이 구성한다. 그런데, 이러면 개발이 느리다. 왜? 프로젝트 진행할 때마다 기획팀장 컨펌받고, 디자인팀장 컨펌받고, 개발팀장 컨펌받고,,, 합의 안 되면 팀장끼리 지지고 볶는다. 컨펌받는 데만 세월이 걸린다. 한 팀에서 모든 것을 해결해야 했다. 그것을 스쿼드(혹은 사일로) 팀이라고 한다. 스쿼드 팀은 목적지향조직(cross-functional team)이다. 목적지향조직에는 기획자, 디자이너, 개발자가 있다. 어떤 곳은 마케터, 데이터 사이언티스트도 있다. 프로젝트의 모든 의사결정을 팀 내부에서 한다. 의사결정이 빨라지고, 상황에 유연하게 대처 가능하다. 조직이 가벼워지는 것이다. 스쿼드 팀은 누군가가 리드해야 한다. 그 팀을 리드하는 직군이 PO(Product Owner)이다. 보통 기획자가 하기 때문에 기획자 직군의 사람들이 PO로 많이 이동한다. 기획자와 PO(Product Owner)는 다른가? 기획자가 PO로 많이 이동했지만, 요구하는 역량은 꽤 다르다. 기획자는 서비스 관점에서 기획을 하고, 요구사항을 받아서 기획서로 풀어내는 역량이 중요했다. 기능 정의서, 와이어프레임, 화면 기획, 프로젝트 일정 조율, 이슈 대응 등의 업무가 대부분이었다. PO는 팀의 목표를 설정하는 것부터 프로젝트를 리딩하는 역량이 더 중요하다. 목표는 사업적인 가치를 만들어내는 무엇(매출, 재구매율, 사업, 신규 서비스 론칭 등)이어야 한다. 사업을 읽을 수 있어야 하고, 그것을 서비스로 풀어내는 전략을 만들고, 팀을 리드할 수 있어야 한다. mini-CEO라고 부르는 이유가 그 과정에서 필요한 의사결정을 하는 사람이기 때문이다. 모든 PO(Product Owner)가 다 동일한가? 그렇지는 않다. 회사 크기, 조직도, 문화, 역할 범위에 따라 다 다르다. PO를 채용하는 기업들도 실제로 면접 가서 프로세스가 어떻게 되냐고 물어보면 기획-디자인-개발 방식으로 일한다고 하는 곳도 많다. 기능 조직으로 구성되어 있는데, 말만 PO인 것이다. 반쪽짜리 PO이거나. 스쿼드 팀이 독자적으로 의사결정을 내리는 조직을 갖춘 IT 회사는 그리 많지 않다. 왜? 그만큼 조직원 개인의 역량이 매우 뛰어나야 하는데, 그렇지 못한 경우가 많다. 게다가 의사결정을 팀에게 위임하는 게 임원진들 입장에서 쉽지 않다. 손이 벌벌 떨릴 것이다. 자기들이 결정하면 결과가 안 좋더라도 자기들이 책임지면 된다. 그런데 결정을 팀에게 위임한다고? 어지간한 믿음 없이 실행하기 어렵다. 우리 팀은? 서비스 기획팀장으로 있지만 agile 조직 문화를 만들고자 했다. 채용할 때도 PO/PM을 뽑기도 했고. 팀장이긴 하지만, 최대한의 권한을 주고 있다. 팀원이 직접 어젠다를 만들어서 프로젝트를 발의하게 하고, 업무를 주도적으로 맡아 진행할 수 있는 환경을 제공하기 위해 노력했다. 작은 회사라 어쩔 수 없는 부분도 있었다. 수직적으로 커뮤니케이션 되는 것들이나, 내가 관리뿐만 아니라 실무도 같이 해야 하는 것들. 그래도 agile에 맞는 OKR을 전사적으로 도입시키고, TF 형태로 전사적 자원을 끌어모아 PM(Project Manager)을 팀원에게 맡겼다. 기능 단위 조직에서 agile하게 업무를 수행하기 위한 나름의 고육지책이었다. 관리는 CFR 방법론으로 수행했다. 1:1미팅으로 진행 상황을 파악하고, 피드백했다. 개인적 고민이나 커리어 성장, 역량 강화를 위해 내가 무엇을 도와줄 수 있는지, 어떤 것을 하고 싶은지 얘기도 하고. 삘 받아서 내가 바라는 PO가 무엇인지, 어떤 역량을 가졌으면 좋겠는지 작성한 것도 있는데, 그건 다음 기회에 쓰겠다. 쓰다 보니 주절주절했지만, 생각 정리도 할 겸.