PO로서 역할과 기술 회사에서의 역할
기술 세계에서 프러덕트 오너를 찾는 것은 결코 쉬운 일이 아니며, 그 자체도 모호합니다.
많은 기업이 이것을 「비즈니스 분석가」라고 부르고 있습니다. 또, 「프로젝트 매니저」, 「프러덕트 매니저」, 또는 「스크럼 마스터」와 혼용하는 경우도 있습니다.이 때문에, 테크 기업내의 관리 역할의 혼란이 가중되고 있습니다. 프로페셔널한 경험을 바탕으로 다양한 역할의 의미와 PO로서의 접근법에 대해 조금 더 명확히 설명하겠습니다.
기술 관리 역할
프로젝트 매니저
프로젝트 매니저의 역할은 디지털이든 아니든 모든 프로젝트에서 가장 중요한 역할에서 시작하여 일반적으로 예산 관리와 관료주의, 기술(소프트웨어 구입, 라이선스 등), 인프라와 직원(인력 및 급여),이를 프로젝트 요구에 항상 맞추면서 이해관계자와의 명확한 접촉을 확립하고 유지합니다.이 역할은 인력 및 팀 리더와 함께 주로 사람에 초점을 맞춘 비교 역할입니다.
프로덕트 매니저
제품 자체가 프로젝트이거나 회사 전체일 때도 있지만, 특히 대기업에서 프로젝트가 여러 제품을 포괄하는 경우가 많습니다.프로덕트 매니저는, 특히 고객의 사용 상황 데이터나 이해관계자의 요구의 분석을 통해서, 제품의 장래를 형성하는 것을 전적으로 책임지는 사람입니다 .통상, 프로덕트 매니저는, 이러한 에픽(대규모의 작업 항목)을 마일스톤의 스케줄 툴인 로드맵에 기재합니다.이 툴은, 이해관계자에게 장래의 진화와 제품에의 영향에 대한 개요를 제공하는 데 매우 도움이 됩니다.또한 제품 관리자는 모든 기존 기능과 새로운 기능에 대한 메트릭(성공 측정)을 작성합니다.이해관계자가 제품에 대해 논의할 필요가 있는 경우 프러덕트 매니저가 연락 창구입니다.
스크럼 마스터
기술 회사들은 그들의 제품 개발을 위해 몇 가지 절차를 따릅니다.많은 경우 신속한 개발 마인드 아래 SCRUM 프레임워크입니다.스크럼 마스터는 프로세스의 건전성을 지속적으로 체크하고 개선해야 할 점을 발견하고 개선의 여지와 최적화를 모색하는 책임자에 불과합니다.이는 작업 방식뿐만 아니라 스크럼 세리머니와 같은 도구 및 프로세스 진화에 대한 효과에도 적용됩니다.어떤 프로젝트에도 딱 맞는 공정이 없기 때문에 커스텀 프로세스를 지속적으로 커스터마이즈하는 스크럼 마스터를 생각하고 있습니다.
프러덕트 오너
SCRUM 프레임워크에 따라 작업하게 되면 개발팀은 성과물(작업물)을 스프린트 단위로 제공합니다(매주, 격주 또는 매월 일정 시간).프러덕트 오너는 각 스프린트의 스프린트 용량(각 개발자의 작업 능력을 합한 전체 팀의 작업 능력)을 바탕으로 에픽을 사용자 스토리(기술적으로 더 적은 양의 작업)로 분류하고 계획 및 우선순위를 정하는 책임을 집니다.미완료된 작업 항목은 작업 항목의 목록이며, 제품 소유자는 항상 모든 사용자 스토리에 우선순위를 부여하고 설명해야 합니다. 왜냐하면 많은 긴급한 작업이 들어오기 때문에 제품, 특히 진행 중인 작업에 대한 제품 진행 상황을 평가해야 하기 때문입니다.
궁극적으로 제품 소유자는 제품 제공에 대한 책임을 집니다. 따라서 적절하고 기본값이 없는 구현을 보장할 수 있습니다.
PO의 의무와 책임
개발 과정에서 제 임무가 시작되는 곳이죠
PO로서 입력은 프러덕트 매니저에 의해 제공되며, 비전에 대해 논의한 후 각 구현의 큰 그림을 제공하는 제품 에픽을 백로그에 추가합니다.심지어 몇몇 서사시들이 복잡해서 프로젝트로 전환되는 경우도 직면했어요!
일정하게 미룬 업무의 개선과 우선순위 부여.
PO의 가장 큰 임무는 항상 에픽을 사용자 스토리로 분류하고 가능한 한 기술적인 측면에서 지정하며 워크로드에 대한 대략적인 견적을 수행하는 것입니다.지금까지 워크로드의 약 75%를 차지했습니다.리페어 세션은 기술적인 의구심이 있는 경우에 대한 해명을 의미합니다.리페어 세션은 리드 개발자와 스프린트 사이에 한 번 실시합니다.그것은, 그들은 전문가이며, 폭넓은 기술적 개요를 가지고 있기 때문입니다.
각 유저 스토리에 대해서, UX디자이너로서 작업해, 유저 여행의 작성시에 사용한 것과 같은 구조를 따르는 유저 스토리의 설명입니다.
[제품 관련 역할]로서 [액션을 하고 싶다] [제품 가치 제안]을 실현합니다.
또한 글머리 기호로 표시된 허용 기준도 자세히 설명합니다. 이 기준은 구현 및 완료 마크를 어떻게 해야 하는지 알기 위해 엔지니어들에게 매우 유용합니다.또, 기능이 완전하게 제공되도록 유효한 품질 보증을 실시하기 위해서도 매우 도움이 됩니다.
제품 사례 과제를 위해 개발한 사용자 사례의 예를 아래에 참조하십시오.
팀 전체의 할당 워크로드와 각 아이템의 워크로드의 추정을 바탕으로 다음 스프린트에 중점을 두고 다음 스프린트에 대한 사용자 스토리를 주문하고 우선순위를 부여합니다.
여기서 궁극적인 목표는 몇 번의 단거리 주행을 위해 충분히 많은 아이템을 완벽하게 기술하고 정리하는 것입니다.
스프린트 세리머니.
업무의 또 다른 부분은 개발 진행 상황을 추적하고 새로운 문제나 의구심을 즉시 해결할 수 있도록 팀과 짧지만 빈번한 업데이트 미팅(5~15분, 이상적이지만 반드시 매일은 아닙니다)을 실시하는 것입니다.우리는 시간을 낭비하고 싶지 않습니다.또, 제시간에 납품하는 것은 PO의 책임이라는 것을 잊지 말아 주세요.
각 스프린트를 실제로 시작하기 전에 개발팀과 함께 과제를 추산하고 사용자 사례의 수정은 소위 스프린트 계획 세션 중에 이루어집니다.
각 스프린트가 종료되기 직전과 모든 커밋된 작업이 완료된 후에만 스프린트 리뷰/데모는 이해관계자와 다른 팀원들에게 제공된 기능을 보여주기 위해 제품 소유자가 수행합니다.
마지막으로, 스프린트 소급 세션이 만들어지며, 이 세션은 프로세스에서 현재 스프린트의 문제점 및 상승점을 파악한다.이론적으로는 이 회의는 주로 공정을 다루므로 Scrum Master가 주도해야 하지만, 저는 가끔 제품에 대해서도 논의했기 때문에 PO로서 이 회의에 참여했습니다.
내 임무가 끝나는 곳.
이론적으로 PO의 역할은 제품 기능이 품질과 함께 제공되면 종료됩니다.즉, 모든 항목에 대한 PO의 연장은 개발뿐만 아니라 QA에도 한정되지 않습니다.전략이나 어떤 UX는 책임 있는 것은 프로덕트 매니저의 의무이기 때문에 빠지는 분야라고 말할 수 있습니다.
#프러덕트오너 #피엠
