애자일 조직에서 프로덕트 매니지먼트하기

1. 프로덕트 매니지먼트하기

2. 18년 차, IT서비스 기획자이자 프로덕트 매니저
법학과 행정학 전공
온라인 광고 AE로 IT업계 입문
버디버디, 다날, 패스트캠퍼스 등을 거쳐 17번째 회사 재직 중
그러나 단, 한번도 사수가 없었음
필리핀과 중국에서 2번의 해외 근무 경력
약 3년 간의 스타트업 창업 경험
다양한 서비스 및 플랫폼 기획/구축/운영 경험
패스트캠퍼스를 비롯 다수 강의 경력
유세균무기
@germweapon
https://germweapon.tistory.com

3. 매니지먼트

4. 실력은 없는데
열정과 의욕만 넘치는
고집 센 동료나 주니어
수평적인 조직에서
사수도 없는데
발전과 성장이 없는 동료
수평적 조직에 대한 환상
동기부여 이론에 따르면 열정과 의욕을 고취시키기 위해서는 자율성과 자기결정권을 보장하는 분위기,
즉 수평적 조직문화를 조성하는 것이 중요하다고 한다.
그런데 역설적으로 이런 수평적인 조직문화가 문제를 초래하기도 한다.
회사와 매니저의 실패를
단기간에 극복하기 위해
늘어나는 규칙과 규제
성장과 함께 조금씩
기울기 시작하는 조직

5. 신규 입사자와 주니어
교육
늘어나는 커뮤니케이션과
관리에 드는 비용과 시간
1+1=2가 될 수 없는 프로젝트
회사는 신규 채용을 했다면, 시너지를 통해 1+1은 2 이상의 결과가 나오기를 기대한다.
그런데 정말 1+1이 2 또는 그 이상이 될 수 있을까?
동료 간
능력과 열정의 차이는
평균에 수렴하기 보단
하향 평준화
협업을 통한 시너지보단
시기와 질투, 반목, 갈등이
발생하기 쉬움
프로젝트에서 1+1이 2 이상이 될 수도 있다.
함께 성장할 수 있는 열정 넘치는 동료들이 있고 그 성장을 위한 충분한 시간이 주어진다면 말이다.

6. 1%의 차이; 성공의 경험
그런저런 서비스를 만드는 건 그다지 어렵지 않다.
그런데 속칭 디테일이 쩌는 완성도 높은 서비스를 만드는 것은 무지무지 힘들고 어렵다.
그런데 그 1%의 디테일, 완성도를 높이는 데 가장 어려운 점을 꼽으라고 한다면 제대로 된 걸 만들어 본 경험이 없는 동료들(신입은 제외하자.)과 함께 일할 때이다.
그들은 디테일과 완성도 높은 서비스를 만들고 그 서비스를 사용자에게 제공했을 때 느끼는 감동이나 희열, 보람을 경험해보지 못해서 인지 그런 서비스를 만드는 과정에서 오는 고통부
터 생각한다. 정상에 올라본 적이 없는 사람에게 정상에 오르면 이런 점이 좋다고 설득하지만 저 높은 산을 올라가는 과정에서 오는 고통만 생각하는 것과 같다.
그러니 제대로 된 서비스를 만들어 본 경험이 없는 동료들을 설득하고 끌고 가는 것이 너무 힘들고 어려울 수밖에.
그리고 이들은 어떻게 하면 더 좋은 서비스를 만들지를 고민하기보다는 매번 비용과 시간을 핑계로 어떻게 하면 자신이 해놓은 것을 수정하지 않고 그대로 유지할지를 고민한다. 변경이
나 수정을 요청하면 항상 비용과 시간을 들먹인다. 그런데 내가 다수의 프로젝트를 경험한 바에 따르면 몇몇 업무는 일정이나 인력 등의 리소스에 크게 영향을 받을 수도 있지만 대다수
업무는 시간과 비용이 아니라 작업자의 자세나 의지, 열정 등에 더 큰 영향을 받는다는 것이다.
그런데 이런 자세와 생각을 바꾸는 건 정말 어렵다. 제대로 만들어 본 경험이 없으니 왜 이렇게 까지 해야 하는지에 대해서 반복적으로 설명하고 설득을 하지만 이미 습관화되고 굳어진
자세와 생각을 바꾸는 건 서비스의 완성도를 몇 퍼센트 높이는 것보다 더 어렵다.
때문에 구인 시 이런 경험을 가진 동료들을 채용해야 하는데 이런 경험이나 자세, 생각보다는 학벌과 커리어만 보고 채용을 한다.

7. MVP, Lean 등의 용어가 짜증나는 이유
최소 기능 제품(MVP, Minimum Viable Product)이란 고객에게 제품의 가치를 검증하기 위해 최소한의 기능을 구현한 제품을 말한다.
MVP = 최소한의 기능을 구현한 제품 ≠ 낮은 완성도와 퀄리티의 제품
도대체 언제까지 MVP를 제공할 것인가?

8. 제 3자 또는 투자자의
시각
이해 부족
DT 프로젝트가 실패하는 이유
전통적인 오프라인 기업들이 기업들의 미래 생존을 위해 Digital Transformation Project(일명 DT 프로젝트)를 활발하게 진행하고 있고,
이로 인해 스타트업보다 더 좋은 급여와 복지를 제공하는 중견/대기업에서 IT서비스 기획자를 많이 채용하고 있지만...
의심과 반대 확신 없는 경영진

9. 동료들이 공감하고
동의할 수 있는 적정한
프로젝트
프로젝트 진행 과정이
투명하게 공개 및 공유
실패를 박수 쳐주기 위해선
여러분이 기획자로 일하며 진행하는 수많은 프로젝트들은 실패를 경험하게 될 것이다.
그런데 실패는 익숙해지긴커녕 자신감과 자존감을 갉아먹고 있을 것이다.
때문에 그 실패로 인해 자신감과 자존감을 갉아먹히지 않고 주위 동료들로부터 박수를 받기 위해선...
결과에 대한
냉정한 평가와 기록
구성원과 조직원의
성장

10. 업무 집중 시간
만들기
가장 중요한 업무
3가지 하기
프로덕트 매니저가 방해요소를 통제할 수 있는 방법
브라우저 탭
줄이기
말하고 설명하지 않고
문서화하기

11. 워터폴 vs. 애자일
(칸반 보드 운영)

12. KPI
워터폴과 애자일
간트 차트
성과 평가 OKR 칸반 보드
회고

13. 애자일 문화
수평(존중) 효율 성장
애자일 소프트웨어 개발 선언
우리는 소프트웨어를 개발하고, 또 다른 사람의 개발을
도와주면서 소프트웨어 개발의 더 나은 방법들을 찾아가고 있다.
이 작업을 통해 우리는 다음을 가치 있게 여기게 되었다.
공정과 도구보다 개인과 상호작용을
포괄적인 문서보다 작동하는 소프트웨어를
계약 협상보다 고객과의 협력을
계획을 따르기보다 변화에 대응하기를 가치 있게 여긴다.
이 말은, 왼쪽에 있는 것들도 가치가 있지만,
우리는 오른쪽에 있는 것들에 더 높은 가치를 둔다는 것이다.

14. 스크럼
스크럼(Scrum)은 프로젝트 관리를 위한 상호, 점진적 개발 방법론으로 애자일 소프트웨어 개발 중의 하나이다.
칸반보드 운영
Sprint란?
Story Point(or Issue Point)란?
업무의 단위
1. Sprint: 1 스프린트는 2주(워킹데이로 10일)
2. Story Point: 1 스토리 포인트는 2시간임
- 때문에 한 명의 작업자는 1스프린트 동안 최대 40포인트의 일감을 해
결해야 하지만...
- 최초 1 스프린트는 30포인트를 기준으로 함
기본적인 칸반보드의 구성
Backlog > To do > In Progress > Testing > Done

15. 카드 계층 구조
Epic
Story
v1, v2, iOS, Android
User Story
To-do Sub Task
Issue Task
Sub Task To-do
1. Epic: 프로젝트의 단위
ex) 앱 개발, 웹사이트 개발, IPTV 개발
2. Story: 스토리는 유저 스토리의 작성이 필요하기 때문에 PO 또는 기획자가
주로 작성을 합니다.
3. Task: 태스크는 프로덕트 팀의 구성원들이 필요에 따라 백로그(Backlog)에
작성할 수 있습니다.
4. Sub Task: 스토리 및 태스크를 처리하기 위해 작업자들에 의해 작성되는 하
위 일감으로 PO 또는 작업자들이 편의에 따라 마음 껏 쪼개거나 합치며 작성할
수 있습니다.
•이슈 생성 시 주의사항
- 함께 협업을 하는 동료들이 쉽고 빠르게 이해할 수 있도록 최대한 정확하고 자
세하게 작성해주세요.
- 관련된 외부 자료들이 있다면 링크 또는 파일 첨부를 해주세요. 가장 좋은 방
법은 이슈 내용만으로도 충분히 전달이 가능하게 작성해주시는 거예요.
- 각 이슈의 템플릿에 맞게 내용을 잘 작성해주세요.
- 이슈 작성 시, 레이블 및 수정 버전 등을 빼먹지 말고 잘 작성해주세요.
- 이슈가 작성되었다면 해당 이슈와 관련된 사람들에게 공유 및 푸시해주세요.
지라 내에서 푸시는 @ID를 통한 방법과 이슈 우측 상단의 [지켜보기 옵션]을
통해서 가능합니다.
이슈의 유형
Epic, Story, Issue, Sub Task

16. 보드의 설계
QA(수 10시) Deploy(목
15시)
Completed
QA 요청할 카드
(수정완료 후 QA가 필
요한 경우 포함)
수 10시 기준
모두 QA 진행
수정 완료된
카드
목 15시 기
준
모두 실서버
배포
회고 과정
개발/디자인 QA/기획/디자인
To-do
하기로 한 일
In progress Completed Rejected
진행 중인 일 완료한 일 QA중 발견된 버
그
-> 수정이 필요한
경우
Hot fix
버그
Backlog
기획
테스트 서버
앞으로 해야
할 일감
스토리/태스크
에서 가장 처음
작업을 시작하는
사람이 To-do >
In progress로
이동함
스토리/태스크
에서 가장 마지
막으로 작업을
시작하는 사람이
In progress >
Completed로
이동함

17. 보드의 설계
1. Backlog(백로그): 앞으로 해야 할 일감(스토리 및 작업)
- 백로그는 누가 작성하나요?
백로그는 스토리와 작업 2가지 유형의 이슈로 작성을 할 수 있습니다.
스토리는 앞서 이야기한 바와 같이 유저 스토리를 생성하는 PO 및 기획자가 작성하며,
작업은 프로덕트 팀의 구성원이 필요에 따라 누구나 작성할 수 있습니다.
2. To do(해야할 일): 이번 스프린트에서 하기로 한 일감
- 백로그에서 To do로 일감은 어떠한 방법과 과정을 통해서 이동하게 되나요?
백로그에 작성된 일감은 회사의 요구, 고객의 니즈, 동료들의 필요 등 여러 과정을 통해서 작성됩니다.
수많은 백로그 중에서 다음 스프린트에 해야 할 일감을 정하는 플래닝 미팅은 한정된 리소스로 최대한의 효과를 달성하기 위해 스프린트에서 중요한 과정입니다.
때문에 수많은 일감 중에서 우선순위를 정하고 어떤 일감까지를 다음 스프린트로 진행할지 결정하기 위해 아래와 같은 플래닝 미팅 과정을 거칩니다.
1) PO가 회사와 비즈니스 팀 등의 의견을 반영하며 다음 스프린트에 해야 할 일감들을 대략적으로 정리합니다.
2) 일감에 스토리 포인트 부여
- Sub Task(하위 작업)를 기준으로 작업에 필요한 직군별로 스토리 포인트를 부여합니다.
- 직군이 N명인 경우에는 빠른 포인트 산정을 위해 협의보다는 플래닝 포커를 칩니다.
- 플래닝 포커를 통해 산출된 평균값을 기준으로 해당 하위 작업에 필요한 스토리 포인트를 정합니다.
3) 일감에 ICE(RICE) Score 부여
- 스토리 & 작업을 기준으로 ICE Score를 부여합니다.
- ICE Score는 Impact, Confident, Ease를 기준으로 각 10점 씩을 부여하지만 이해의 편의를 위해 수익성, 사용성, 개발 및 작업의 속도를 기준으로 10점 씩을 부여합니다. 때문에 인원
이 10명인 경우에 스토리 & 작업에 부여될 수 있는 만점은 300점입니다.
- ICE Score가 높은 순 정렬을 통해서 작업의 우선순위를 정하고 작업 직군별 가능한 스토리 포인트의 합산으로 먼저 채워지는 스토리 & 작업까지를 다음 스프린트의 To do 일감이 됩니
다.
3. Hot fix(버그): 버그로 올라온 일감
- Hot fix는 스프린트 및 포인트에 영향 없이 먼저 수정되어야 하는 일감으로 별도의 포인트를 부여하지 않습니다.

18. 보드의 설계
4. In progress(진행중): 작업을 진행하고 있는 일감
- 스토리/작업의 하위 작업(Sub Task) 중 가장 처음 작업을 시작하는 사람이 To do에서 In progress로 일감을 이동해야 합니다.
5. Completed: 완료한 일
- 스토리/작업의 하위 작업(Sub Task) 중 가장 마지막으로 완료한 사람이 In Progress에서 Completed로 일감을 이동해야 합니다.
6. QA: 테스트 서버에서 테스터들이 테스트를 진행할 수 있는 상태
- 스토리/작업의 모든 하위 태스크가 완료되어 해당 스토리 및 작업이 Completed로 이동된 상태에서 개발 서버에 최종 배포가 완료되면 배포를 한 개발자가 해당 보드로 배포된 스토
리/작업을 이동해야 합니다.
- QA는 최소 스프린트 둘째 주의 수요일 오전 10시까지 이동이 완료된 건에 대해서는 QA가 진행됩니다.
7. Rejected: QA 중 수정이 필요한 일감
- QA 중 수정이 필요하다고 판단된 일감을 테스터에 의해 해당 보드로 이동하게 됩니다.
- 작업자는 해당 이슈를 확인하고 당일 해결이 완료되면 다시 QA 칸반으로 이동 또는 당일 해결이 어려운 경우에는 In progress 보드로 이동합니다.
8. Deploy: 실서버 배포 완료된 일감
- 스프린트 둘째 주 목요일 오후 3시에 QA에 남아있는 일감을 실서버에 배포하고 배포된 일감을 배포한 개발자가 해당 보드로 이동합니다.
- Deploy에 이동된 일감은 QA에 의해 재확인을 진행합니다.
9. Done: 회고가 완료된 일감
- 매주 금요일 오후 4시에 스프린트 회고가 진행되고 회고가 완료된 일감을 회고 담당자에 의해 해당 보드로 이동합니다.
•칸반 사용 시 주의사항
- 현재 지라 칸반의 필터 및 소팅이 제대로 작동하지 않아 현재 진행 중인 스프린트에서 태스크 생성 시, 우선순위를 Highest 또는 High로 지정해서 작업해주시기 바랍니다.
그럼 이슈에서 상단 필터 옵션 중 [더보기 > 우선순위]에서 Highest 또는 High로 필터를 걸어 이번 스프린트에서 작업해야 할 이슈를 필터하여 쉽게 확인이 가능합니다.

19. 데일리 스크럼 미팅
데일리 스크럼의 목적은 동료들에게 어제 한 일과 오늘 한 일을 공유하고 일을 하면서 겪
거나 예상되는 허들이나 바틀넥을 공유하여 이를 빨리 해결하고 업무를 효율적으로 진행
할 수 있도록 하는데 그 목적이 있습니다.
• 데일리 스크럼 양식 작성 시 주의사항
- 업무의 집중이나 효율을 떨어뜨리는 허들이나 바틀넥 이슈를 잘 공유해주시기 바랍니
다. :)
ex) 포인트 지급 개발을 하는데 정책이 누락되어 업무 흐름이 끊겼음
빈번한 미팅으로 인해 업무 효율이 떨어졌음
- 업무 공유 시에는 꼭 해당 이슈의 코드 또는 링크를 함께 기재해주시기 바랍니다.

20. 스프린트 회고하기
스프린트가 종료되는 둘째 주 금요일 오후 4시에 스프린트 회고를 진행합니다. 회고를 통해 이번 스프린트를 정량적으로 평
가하고 좋았던 점, 아쉬웠던 점, 해결책(KPT 회고, Keep, Problem, Try) 등을 서로 공유합니다.
단, 비판적인 내용을 공유할 때에는 반드시 본인이 생각하는 해결책을 함께 제시해야 합니다.
그리고 이번 스프린트의 업무 진행 결과를 공유하고 다음 진행해야 할 작업을 정리합니다.

21. 애자일 조직의 평가

22. 구글이 목표를 달성하는 기준, OKR
1. 첫째, 영감을 주고 측정 가능한 목표를 세워라.
2. 둘째, 바라는 최종 상태를 향해 언제나 당신과 당신의 팀이 진보하게 하라.
3. 셋째, 자신이 달성하려고 애쓰고 있는 것이 무엇인지 상기하고 서로 공동 책임을 지고 있다는 사실을 팀 전체가 기억하도록 정기적인 점검 시간을 만들어라.
O는 달성하고자 하는 목표를 뜻하는 Objective,
KR은 목표를 달성했는지 알 수 있는 척도인 핵심 결과지표를 뜻하는 Key Results를 나타낸다.

23. 애자일 조직에서의 평가 시스템
회사의
정량적 목표 달성
40%
직군별
정량적 목표 달성
30%
스프린트
동료 평가
30%
나의 평가
100%

24. 애자일 조직에서의 OKR 설정
전사 OKR 설정
회사/CEO PO 리더/담당자
PO OKR 논의
직군/담당자별 OKR 논의
전사/PO OKR 전달
직군/담당자별 OKR 생성
PO/직군/담당자별 OKR 정
리 및 협의 진행
PO/직군/담당자별 OKR
확정
CEO와 전사 OKR 협의 진행
PO와 OKR 논의
전사 OKR 확정
인사팀, 인센티브 정책 수립
CEO, 인센티브 및 OKR 공표
PO OKR 생성
전사 OKR 전달
CEO와 OKR 논의
PO OKR 협의
PO OKR 확정 지표 확인
CEO와 OKR 논의

25. 데이터 조직과 지표 모델
Channel / AD
AARRR Metrics (일명 해적지표)
Acquisition
사용자 획득/유치
Activation
사용자 활동
Retention
사용자 유지
Referral
추천
Revenue(Monetization)
매출
유입경로 분석 순위 분석, 유저환경 분석 사용행태 분석 Funnel 분석 추천 분석 매출 분석
매출 지표
사용자 지표
1 MAU
- 3개월 평균 MAU/앱스 기준
전사 OKR
PO/개발자
UI/UX디자이너
원/안나
마케터
PD(콘텐츠)
영업/제휴
운영
CS
2
완독률
- 콘텐츠를 시청한 사람 중 5분 이상 시청
한 비율의 3개월 평균/서버 기준
3 리텐션
- 3개월 평균/GA4 기준
4
ARPU
- 3개월 평균 매출(+B2B 매출 포함)/서버
기준
1 리텐션
- Organic Retention
2 CVR
- 구매(정기/약정)전환율
2 리텐션
- Organic Retention
1 Avg. CVR
- 주요 이동 경로의 평균 화면 전환율
1
2
Search Growth Rate
- 구글, 네이버 검색 트렌드 기준
ROAS
3 CAC
- Paid 매체를 통한 유저 획득 비용
1
2
3
ROI
완도율
주간 이용율
2 시장점유율 3 매출 성장율
2 SNS Share Rate
2
3
NPS
별점/리뷰
3 ARPU
1 고객유치성장율
1 Churn rate
1 재활성화율
1
OMTM
- 전체 유저 중 매주 2번은 10분 이상 시청
(운동)한 비율
1 매출 성장률
- IP사업을 위한

26. 애자일 조직에서의 동료 평가
스프린트가 종료되면 프로젝트 멤버간 상호평가를 진행합니다.
모든 프로젝트 멤버는 3개의 구슬을 갖고 있으며 자신을 제외한 이번 스프린트에서 가장 공헌도가 높은 3명의 동료에게 구
슬을 주는 이유를 모두의 앞에서 설명하고 구슬을 줘야 합니다.
그리고 3개월 마다 보유한 구슬을 합산하여 해당 분기의 동료 평가를 진행하게 됩니다.
평가의 기준은 동료마다 다면적이고 복합적입니다.
우리 모두는 동료들의 판단을 존중하고 신뢰합니다.
구글을 주는 행위는 모두의 앞에서 투명하고 공개적으로 평가됩니다.