비효율적일 수 밖에 없는 이유
원글: Having Product Owners and Product Managers work together is crazy and ineffective
프로덕트 매니저와 프로덕트 오너가 같이 일하는 것은 아래와 같은 비유를 생각할 수 있음
두 사람 모두 스모 선수이자 발레리나가 되고 싶다고 말하는 것과 같음
미식축구에서 쿼터백이 더이상 공을 던질 수 없다는 것
마스터 바리스타가 더이상 에스프레소를 만들 수 없고, 우유 거품만 만들라고 지시하는 것임
개발자가 더이상 코드를 작성할 수 없고, 다른 개발자의 코드만 리뷰하라는 것을 의미
마치 강제 혼인을 두 사람
동그란 구멍에 네모난 못을 박는 것
즉, 프로덕트 매니저와 프로덕트 오너가 같이 일하는 것이 비효율적임
Product Owners are Product Managers
프로덕트 오너인가 Product Puppet인가?
프로덕트 오너(Product Owner)의 ‘Owner’는 높은 수준의 권한과 자율을 의미함. 프로덕트 오너는 프로덕트 매니저의 지시에 따르는 것이 아닌 실제로 프로덕트를 ‘own’하는 역할임.
프로덕트 오너가 있는 팀에 프로덕트 매니저가 합류하게 되면?
프로덕트 오너가 존재한 상황에서 프로덕트 매니저가 팀에 추가 → 프로덕트 오너의 역할이 Product Puppet(꼭두각시)가 됨. 스크럼을 통한 제품 가치 전달에 부정적임
스크럼과 프로덕트 매니지먼트
팀에 프로덕트 매니저와 프로덕트 오너가 동시에 존재 → 해당 팀이 스크럼과 제품 관리(Product management)를 이해하지 못함 의미
스크럼 프로세스 프레임 워크 관점에서 프로덕트 매니저와 프로덕트 오너는 양립할 수 없음.
스크럼에서 프로덕트 오 = Product management 전문가. 그렇지 않다면 스크럼으로 성과 달성 힘듬
스크럼 팀에 프로덕트 매니저 합류시키는 것은 스크럼이 정상적으로 동작하지 않거나, 프로덕트 오너가 무능하다는 것 → 휘발유로 불을 끄는 것처럼 상황을 악화시키지 말고, 근본적인 해결책을 찾아야함
프로덕트 오너 그리고 프로덕트 오너십
스모 선수처럼 프로덕트 오너 역할은 무게감이 있는 적임자가 필요함.
스크럼 개발 문화에서 프로덕트 오너의 권한을 해지하는 것은 링에서 낮은 체중으로 스모 경기를 치루는 것과 같음
차라리 스크럼을 포기하고 pliés 또는 pirouettes을 시도해야함 (무용 용어 같은데 피봇이나 태세전환을 의미하는 것 같습니다).
결국 프로덕트 오너십이 중요한 것임. 가장 프로젝트를 잘 이해하고 많은 정보를 가진 사람이 올바른 결정정을 내릴 수 있도록 지원해야함
프로덕트 오너 역할을 수직 또는 수평적으로 나누길 원하는가? 만일 프로덕트 오너 역할을 수직적으로 나누면, 의존성(dependencies), 좌절(frustrations), 재작업(rework) 및 문제점 (problems)이 발생함. 수평적으로 나누면 업무 범위 관련하여 누가 어떤 범위를 own할지 이슈가 생김
프로덕트 오너 그리고 LeSS(Large-Scale Scrum)
조직에서 프로덕트 오너의 역할을 확대하는데 문제가 있다면, LeSS 프레임워크(Large-Scale Scrum)를 참고할 수 있음.
LeSS를 활용하면 개별 프로덕트 오너의 오너십(ownership)은 축소되지만, 프로덕트 관련해서 모호한 공통의 오너십을 발생시키지 않음.
LeSS는 프로덕트 오너의 역할을 존중함 → 스크럼을 프로덕트 가치 제공의 프레임워크로 허용함으로써, 프로덕트 오너가 제품 개발의 시작부터 마무리까지 가치를 전달하는 역할을 부여함.
YJ's comment) LeSS에 대해 Jira는 아래와 같이 설명하고 있습니다. LeSS는 2개~8개 팀 규모에 적용되는 LeSS와 8개 이상 규모에 적용되는 LeSS-Huge가 있습니다. LeSS는 한 명의 프로덕트 오너와 복수의 피처팀으로 구성됩니다. 저자가 의미한 LeSS의 프로덕트 오너는 LeSS-Huge의 영역 프로덕트 오너(Area Product Owner)를 의미하는 것 같습니다. Area Product Owner는 Product Owner 팀에 프로덕트 오너와 복수의 Area Product Owner로 구성되는 것 같습니다.
LeSS 프레임워크에 대한 설명은 아래 글에 잘 번역되어 있으니 참고 부탁드립니다
LeSS(Large-Scale Scrum)는 대규모 소프트웨어 개발에 가장 적합합니다. LeSS는 성공을 이루기 위해 확장 프레임워크를 최소화할 것을 제안합니다. 이 제안은 조직에 맞춤화를 요구하는 동시에 너무 많은 규칙, 역할 및 아티팩트를 제공하는 것은 근본적으로 결함이 있다는 생각을 기반으로 한 것입니다. LeSS는 2가지 수준(2~8개의 팀을 위한 LeSS, 8개 이상의 팀을 위한 LeSS-Huge)으로 나뉩니다. 이러한 수준은 팀을 조직 빌딩 블록으로 사용하여 구축됩니다.
제가 발행하는 뉴스레터입니다. Product management에 관심 있으신 분들께서는 아래 뉴스레터 링크에서 구독 부탁드립니다 :)