[도서 리뷰] 프로덕트 오너

다음주까지 휴가중이고 열심히 놀면서 책을 한권 한권 읽어나가고 있다. 이번에는 "프로덕트 오너" 라는 책을 읽고 간단히 정리하면서 현재 회사에서의 업무와 연관지어 보려고 한다. 마지막에는 어떻게 내 일을 지금 회사에서 가지고 갈지에 대한 이야기까지 간단히 하려고 한다.

 

우선 프로덕트 오너 (PO)와 PM (Project Manager), PM (Product Manager)에 대한 정의를 이야기해봐야할 것 같다. 기존에 알고 있던 개념과 이책에서 이야기하는 PO의 개념은 살짝 PM (Project Manager, Product Manager) 모두 섞어 놓은 역햘과 비슷해보이기 때문이다. 물론 이 개념을 구분하는 것도 중요하지만 각 회사의 JD (Job Description)을 보고 그에 맞는 역할을 하는것도 중요하다고 생각한다. 그러기에 이 책을 통해 고객 중심으로 이야기하고 어떻게 고객 (외부, 내부)들, 개발팀, 디자인팀, 경영진 등과 소통을 하는지를 배우는 것도 중요하다.

개념 정의 (PO, PMs)

이 책에서 나오는 정의를 따르는 것이 아니고 스크럼, 구글링, 현재 회사에서의 역할 등의 용어를 통해 이해한 대로 적어보려고 한다.

출처: https://teamhood.com/project-management/product-owner-vs-project-manager/

 

위의 글에서와 같이 Product Manager (PM)은 전체 제품을 총괄하고 고객의 요구사항을 이해한 후 전체적인 전략을 세우는 역할이다. 이 전략을 바탕으로 Product Owner (PO)는 실제 개발을 해야하는 아이템들을 나열하고 우선순위를 정한다. 다른 Scrum 팀과의 필요한 의사소통을 한다. Project Manager (PM)은 프로젝트의 일정을 관리하고 팀을 관리하는 역할을 한다.

 

회사마다 이 역할들을 조금씩 다르게 운영되고 일부 역할들은 하나로 합쳐지기도 한다. 지금 다니고 있는 회사의 경우 PM은 전체 프로젝트를 관리하고 PO는 스크럼팀을 리딩한다. EL (Engineering Lead)은 팀을 관리한다. PO도 EL이 관리하는 팀 구성원이다. 솔직히 여전히 PO, EL, PM간의 역할은 명확하지 않고 일부 겹쳐지는게 사실이다. EL이 팀을 관리하면서 팀원에 대한 평가, 승인 등을 하기 때문에 모든 권한이 있다.

도서 리뷰

다시 이 책의 리뷰로 돌아와서 이 책에서는 위에서 이야기하는 Product Manager (PM)과 Product Owner (PO)의 역할을 합쳐 PO로 이야기하는 것처럼 느꼈다. 책의 표지에서도 보여지듯이 미니 CEO라 불리지만 실제 인사권은 없는 리더이다. 좋은 점은 팀원 관리와 같은 HR적인 것에서 벗어나 정말 제품만 생각할 수 있다는 점이지만 힘든 점은 실제 인사권이 없기 때문에 개발팀과 소통하기가 힘들 수도 있다.

 

이 책에서는 프로젝트에 관련된 팀들로부터 신뢰와 인정을 받아서 공식적인 루트로 권한을 받을 수 있는 몇가지 방법을 이야기한다. 데이터를 기반으로 모든 결정을 하는 방법, 효율적으로 일정 관리를 하는 방법, 디자인/개발팀 등과 잘 협업하는 방법, 고객 테스트를 하고 제품에 반영하여 개선하는 방법, 제품 출시 시기, 마지막으로 적합한 역량을 가진 PO를 선발하는 방법등을 소개한다.

 

궁극적으로 고객에게 만족을 줄 수 있는 제품을 만드는 것을 목표로 하고 이 과정에서 관련된 팀들과 어떻게 협업을 잘 할 수 있는지에 대한 이야기를 이 책에서는 이야기한다. 책을 읽다보면 PO의 역할은 거의 슈퍼맨이고 밤낮 쉴새 없이 일만 하는 것처럼 보인다. 모든 것이 중요하고 해야할 일이지만 어떻게 잘 할 수 있을지, 여러개의 제품을 맡아서 하는 경우 지속가능성이 있는지 과연 의문이기도 하다.

 

매일 15분, 30분 단위의 연속적은 회의, 그것을 준비하는 과정, 중간중간 멀티태스킹, 관련 내용 파악.. 정말로 중요하지만 참 어려운 것 같다. 우리 회사에서 과연 이런 것이 가능할까.. 라는 생각도 든다.

배운점

이 책을 읽으면서 여러 가지를 배우고 생각하게 되었다. 데이터를 기반으로 사고하고 결정해야하는 것과 이를 쉽게 볼 수 있는 Dashboard를 만드는 것도 그 중에 하나이다. 이미 회사에서 강조하고 있지만, 일부 부족한 점이 있어서 다시 한번 생각하게 되었다.

 

PO의 일부 역할 중에 정리하고 회사의 OKR과 연계시키며 Planning 및 회고 할 때 함께 연계시키면 좋겠다는 것도 느끼게 되었다. 물론 일부는 하고 있지만 좀 더 체계적으로 하면 좋겠다는 생각도 들었다. OKR, Dashboard, Sprint Planning, 회고 등등

 

차량용 소프트웨어를 개발하고 있어 이 책에서 이야기하는 예시와 거리가 있지만 A/B 테스트의 일부 좋은 점들을 개발 과정에 적용하면 좋겠다는 생각도 들었다. 여기서 이야기하는 A/B 테스트를 임베디드 개발에 적용하는 것은 어렵지만 일부 업무상 필요한 일들에 대해서는 비슷하게 프로세스를 가지고 가는 것도 좋을 것 같다. 예를 들어 Jenkins를 Gitlab CI로 이관할 때 점진적으로 하는 것 등등이 예가 될 수 있다.

 

고객의 목소리를 듣는 창구도 일원화 해서 마련하면 좋겠다는 생각도 들었다. 현재 우리 팀의 고객은 개발 팀이다. 팀 채널이 있지만 이를 좀 더 개선하고 발전시켜서 주기적으로 듣고 피드백을 주는 것도 좋은 방법이다. 몇번 시도를 해봤지만 잘 되지 않았다. 가끔 내일이 아니고 PO일인데라는 생각을 가지고 있었던 것도 있지만.. 이를 주도할 수 도 있을 것 같다.

 

개발 이외에도 새로운 아이디어와 일을 찾아서 팀과 회사에 공유하는 것도 좋은 일이다. 너무 현재 일에 매몰되지 말고 컨퍼런스, 밋업, 외부 네트워킹을 활용하여 다양한 분야의 사람들과 이야기해보는 것도 미래를 고민하는데 좋은 것 같다.

앞으로의 계획

People Leadership으로 가는 방향, Technical Leadership으로 가는 방향 중에 확실히 결정을 하지 못했다. 그래서 일단 두가지 모두 가능성을 열어두고 2025년도에 업무를 진행해볼 생각이다. People Leadership으로 가기 위해 회사에서 하는 교육들을 계속 듣고 일부 프로젝트를 리딩하고 싶은 마음이다.

 

내년에 할일은 3~4가지 정도의 옵션이 있다. 현재 제품 기여, 2-3년 후 제품 기여, 5-6년 후 제품 기여에 각각 관련된 것이라서 여전히 고민중이고 내년에 매니저와 상의후 결정할 것 같다.

 

개발팀장 (EL)이 아니면 일을 하는데 영향력이 제한될 수 밖에 없을 것 같다는 생각이 계속 들었고, 실제 업무를 할 때도 많이 느꼈다. 특히나 여러 팀에서 사람들을 십시일반하여 모아서 프로젝트를 진행하는 경우가 더 그렇다. 의도했던 의도하지 않았던 정치와 각각의 팀에 연결되어 힘들 수도 있다. 이미 몇번 경험을 했고 이를 해결하는 과정도 순탄치 않았다. 물론 이 과정중에 한단계 성장한 것 같은 느낌도 든다.

 

그럼에도 불구하고 가능하면 한 개발팀장 밑에 있는 동료들과 하나의 제품/프로젝트/스크럼 팀을 꾸려서 가는것이 효율적이라고 생각한다. 가능하다면 이렇게 내년 프로젝트는 진행하고 싶다.

 

이제 다음 책은 조금 가볍게 "반도체 삼국지"라는 책을 읽어볼까 한다.