녹호두

애자일 조직 제품 관리자의 고객중심 문서 작성 가이드! (에픽, 유저스토리)

https://youtu.be/Z6tgjS3cMcA

case 1 - 기획자

• 비즈니스 관계자 or 고객으로부터 요구사항 수집
• → 기획자가 분석, 설계
  • 이때 설계된 문서를 "스토리보드"라고 부름 (국내에만 있음)
  • 스토리보드에는 ui, 정책, 기능 명세 등이 담기게 됨
• → 이를 바탕으로 디자이너, 개발자가 작업
  • 디자이너와 개발자는 주로 제작 단계에 참여

# 스토리보드

좌) ui 우) desc

case 2 - pm, po

• 비즈니스 관계자 or 고객으로부터 요구사항 수집
• → po, pm도 분석을 함. 하지만 설계를 하진 않고 고객의 목적과 행동을 정의 (왜 쓰고 뭘 불 편해하고 뭘 원하는지, 니즈) = 니즈를 중심으로 정의
  • 이때 작성된 내용을 Epic, User story라고 함
• → 이 내용을 바탕으로 디자이너, 개발자가 소통해가면서 설계를 함께 진행하고 제작에도 모두 함께

# epic, userstory

문서로 구성

• 테마가 최상단에 가장 크게
  • 에픽
  • (flow chart)
    • 유저 스토리
      • 누가 무엇을 위해서 어떤 기능을 원한다. (유저의 관점에서 작성)
      • acceptance criteria (인수기준)
        • 제품이 최종 사용자 혹은 시스템이 제시하고 있는 요구사항을 만족하고 있는지를 판별하기 위한 기준
        • 인수조건의 가장 큰 특징은 철저하게 사용자의 관점에서 제품의 기능을 정의한다는 것입니다
          • 테스트

→ pm 은 ui 가아니라 위와 같은 문서를 주로 작성한다.

→ 스토리보드는 ppt로 제작해 검색이 어려운데 이런 건 위키로 되어있어서 검색이 용이하다.

→ 유저 스토리는 고객 입장에서 고객이 원하는 것을 고민하는 것으로 서비스 기획과 view(관점)이 많이 다르다.

제품 관리자(PO,PM)의 Product 일정관리 노하우!

https://youtu.be/gg56Z_LlXvE

워터폴 : 프로세스에따라 단계적으로 구현

애자일 : 최소단위제품MVP를 빠르게 출시해 개선하는 방식

->  프로젝트 성격에따라서 워터폴/애자일 둘 중 하나가 잘 맞을 수 있음

금융 플랫폼, 운영체제와 같이 한번에 완제품을 출시해야 하는 경우에는 워터폴이 적합

고객을 사로잡아야 사업의 성패가 결정되는 프로덕트의 경우 애자일 방식이 적합

backlog에 1) 로드맵 2) 내부 이슈, 기술 부채 3) 고객 요구사항 기록

- 고객 → 사용성 개선, 신규기능 추가, 버그

- 개발 → 우리만 아는 내부 이슈, 기술 부채

- 경영진 → 비즈니스 관련 task

* 기술부채 : 현 시점에서 더 오래 소요될 수 있는 더 나은 접근방식을 사용하는 대신 쉬운(제한된) 솔루션을 채택함으로써 발생되는 추가적인 재작업의 비용을 반영 / 기술적으로 해결되어야할 문제들을 뒤로 미루고 비즈니스 문제를 해결하는 것을 앞당기는 것

backlog page

Inbox → pending (요구사항 정리, 분류, 그룹화 → new sprint 형성) → ready (정리된 task 모아둠)

weekly page

• goal - 모든 task는 목표를 기준으로 함
• in progress
  • backlog를 고르게 분배해 In progress를 잘 만들어야 한다.
  • 담당자 배정, 업무 진행 시 pm이 우선순위를 결정하기 때문에 1) 로드맵 2) 내부 이슈, 기술 분배 3) 고객 요구사항 세 가지의 밸런스를 잘 맞춰야 한다. 단, 회사와 협의한 goal 또한 하나의 기준이 되어야 한다.
  • → 중간에 끼어서 스트레스받는 경우가 많긴 하다.. 단, pm이 잘못 결정하면 프로덕트가 산으로 가는 경우가 많다.
  • 기재 시 각 과업마다 사용하는 이유를 함께 기재
• 여러 개의 sprint를 만들고, 운영단에서 발생하는 문제를 위한 sprint( ops )를 별도로 운영하며 비율은 80% 20%로 유지함

회고

• 스프린트 종료 후 각자 잘한점/개선할 점 각자 정리
• 개선할점 미안해서 안 쓰는 경우도 있는데 무조건 적게 해야 함
• 회고 진행 → 회고 미팅 → 최종 정리(by pm) → 다음 스프린트에 반영
  • ex. 000 프로세스 개편 ~

애자일의 핵심은 고객의 피드백을 듣고 원하는 제품을 만드는 것

수행주체는 사람이기에 팀 세팅이 가장 중요

소모되고 있다는 느낌보다는 의미 있는 일을 하고 있다는 동기부여

정체되어있기보다는 함께 성장하고 발전하는 과정

서로 신뢰하는 팀을 만들어야 한다.

→ 좋은 팀에서 좋은 프로덕트가 나온다.

잘하는 기획자의 기준은 무엇인가?

https://youtu.be/A5yHcKrgTHk

1. 기획을 잘한다는 것 = 업무 스타일이 맞는다는 것

• 넓게 트인 시야로 구체화
• 정리의 신
• 체계적인 위계 정리
• 일정관리의 신

2. 기획을 못한다는 것 = 쟤랑은 일 못하겠어

그게 아니라면, 어느 정도 기획을 하는 범주에 들어오는 것 → 그렇게 되면 업무 스타일이 생기게 된다.

ex. 잘하는 기획자 = 자신과 손발이 잘 맞는 기획자

ㄴ 여러 역량 중에, 동료들과 손발이 잘 맞느냐로 동료들에게 평가받을 수 있다.

ㄴ 기획을 잘한다는 객관적 지표는 없다. 누구와 손발이 잘 맞는가가 잘한다의 기준을 판단하는 것이고 그것은 개인마다 차이가 있을 수 있다.

if 내가 기획을 못하는 거 아닐까란 생각이 들 때

1. 정말 자질이 없을 때
2. 지금 이 팀이 안 맞을 때. 자신의 기획자로서의 성향과 안맞을때 → 조직 또는 팀을 바꿔보자

PO : 프로덕트를 이끄는 전문가

기획자 : 프로덕트의 완성도를 높여주고 현실화해주는 전문가

Con. 잘하는 기획자?

1. 객관적인 기준은 없다.
2. 주변 동료에 의해 평가된다.
3. 나와 손발이 잘 맞는 동료들을 주변에 두면 자연스럽게 잘하는 기획자가 된다.

디자이너와 개발자가 뽑은, 내 인생 최고의 Product Manager!

https://youtu.be/U3JhQlTFxWw

내 인생 최고의 프로덕트 매니저

• 콘텍스트/데이터/리서치 기반으로 커뮤니케이션
• 팀원들과 동등한 위치
• 개발자와 논쟁할 수 있는 지식을 갖춘 pm 이 좋은 pm이다.
• 로드맵을 지속적으로 리뉴얼하는 것이 좋다.
• 마감일보다는 해결책에 초점을 맞춘다 → 마감일도 중요하지만 해결책에 초점을 맞추는 게 중요하다. 마감일을 조금 유연하게 조절했다.
• 고객 중심으로 최고의 제품을 위해 C레벨과 마찰을 이겨냄
• 다양한 이해관계자들과의 커뮤니케이션 ← 디자인과 엔지니어링에 대한 이 해이 필요. 직접 개발/디자인 하진 않더라도 문제를 직접적으로 집어내는 역할은 필요
• 해결책보다는 문제를 찾아내고 소통하는데 더 많은 시간을 사용
• 디자이너와 개발자를 파트너로 대우. 보상보다는 제품 출시에 더 많은 신경을 쓴다.

BEST PM requirement

• 목표와 비전 설정
  • 왜 이 일을 해야 하는지 비전과 목표를 제대로 설명할 수 있다.
  • 지속해서 사용자, 경쟁사, 시장조사를 진행하고 이를 제품에 반영
  • 해결책보다는 문제를 더 깊게 고민
• 의사결정
  • 본인이 아닌 소비자, 비즈니스, 팀을 위한 결정을 내림
  • 중요한 것에 집중하고 불필요한 것들은 걸러낸다
  • 데이터에 기반한 의사결정을 내릴 줄 안다
• 업무지식
  • 해당 산업의 도메인에 대해 깊게 이해
  • 디자인과 엔지니어링을 이해함
  • 데이터를 제대로 사용할 줄 알고, 데이터를 이해하는 사람과 협업할 수 있다.
• 커뮤니케이션
  • 팀원 의견을 경청하고 올바른 실행방안을 만든다.
  • 이해관계자에 따라 상황에 맞는 모자를 쓰고 커뮤니케이션
  • 커뮤니케이션 메시지가 잘 되어있고 일관적이고 명확하다
  • 언더 커뮤니케이션보다는 오버가 낫다.
• 협업
  • 동료를 도구가 아닌 중요한 파트너로 대한다
  • 동료의 업무방식을 존중하고 효율적으로 일할 수 있도록 돕는다 → 마이크로 매니징보다는 역할을 위임함
  • 팀원의 질문 및 요구사항에 제때 답변을 해준다.
• 태도/자세
  • 제품을 더 좋게 만들기 위해 경영진에 의의를 제기할 수 있다.
  • 피드백을 감정적으로 받아들이지 x
  • 자기 아이디어와 사랑에 빠지지 x