[제로베이스 PM스쿨 19기] 학습일지 Day 5

이번 강의는 뜻하지않게 아티클 스터디랑 겹쳤다...

강의 보기 전에 아티클 스터디부터 끝냈는데 이번 주 강의 마지막이 프로젝트 관리 방법이었다.

아티클 스터디로 먼저 접한 후 강의를 접해서 뭔가 복습 느낌이라 강의내용이 더 잘 이해됐다.

---

Chapter 05. 프로젝트 관리 방법

1. MoSCoW (모스코우)

작고 복잡하지 않은 프로덕트/서비스를 위한 가장 간단한 접근 방법

• Must Have : 이 기능을 빼고 제품/서비스 론칭을 생각할 수 없는 것들이다. 여기에는 법적, 보안 문제, 비즈니스 이유 등 여러가지가 있을 수 있다. 제품/서비스의 생사여탈권을 갖고 있다고 생각하라. 자격이 있는지 알아내는 가장 쉬운 방법은 해당 기능을 포함하지 않은 최악의 시나리오와 최선의 경우를 생각해보면 조금 쉽게 이해할 수 있다. 이것 없이는 프로덕트/서비스의 성공을 상상할 수 없다면, 그것이 Must Have 필수품이다.
• Should Have : 높은 우선순위를 지니는 기능이지만 이것이 없어도 프로덕트에 재앙이 닥칠 운명까지는 아닐 때 사용한다.
• Could Have (=Nice to Have) : ‘할 수 있었을’것들이지만, 성공을 위해 꼭 필요한 것은 아닐 때 이 순위를 사용한다. Should Have와 헷갈린다면 각 요구 사항이 사용자 경험에 어떤 영향을 미칠지 생각해보고 우선순위를 정하면 된다.
• Won’t Have : “다음 버전에 포함시키도록 신중하게 검토하겠습니다”라고 말하는 것들이 이 순위이다. “절대 포함시키지 않을 것이다.”라는 의미가 아니라 “이번 버전에는 포함되지 않을 것이다.”를 의미한다. 주로 리소스의 부족과 같은 이유 때문이다.

2. Walking Skeleton (워킹 스켈레톤)

최소화된 프로덕트의 End to End를 구현한 것이므로, 윤곽 정도가 아닌 실제로 실행 가능하고 테스트도 함께 가능해야한다. 때문에 최소 실행 가능 제품(MVP)의 기능의 우선순위를 정하는데 사용된다. 하지만 요즘 회사에선 보기 어려운 방법이다.

3. RICE (라이스)

우선순위를 설정하기 위해 등급 점수 모델이라는 방법을 사용한다. RICE는 Reach, Impact, Confidence 및 Effort를 나타낸다. 우선순위를 지정할 때 각 기능을 평가하기 위한 입력 값이다.

• 리치 Reach : ‘도달 범위’, 특정 기간 동안 사용할 수 있는 유저 수를 반영한다. DAU/MAU 등 실제 프로덕트 지표로 평가한다.
• 임팩트 Impact : 유저가 이 기능을 사용함으로써 어떤 영향을 받을지 생각해 볼 때이다. “매우 큰 임팩트”의 경우 3점, “높음”의 경우 2점, “중간” 1점, “낮음”은 0.5점, 마지막으로 “최소”의 경우 0.25점을 사용하여 평가한다.
• 컨피던스 Confidence : ‘신뢰도’값. 기능이 유저에게 얼마만큼의 혜택을 주는지에 대한 추정 값이다. “고 신뢰도 100%”, “중간 신뢰도 80%”, “낮은 신뢰도” 50% 등 객관식 척도를 사용하는 것이 좋다.
• 노력 Effort : 제품, 디자인 및 개발팀이 소요한 시간을 보여준다. person-month나 시간 등으로 계산한다.

입력값이 정해졌다면 RICE = (Reach x Impact x Confidence)/Effort, 다른 입력치의 곱을 시간으로 나누는 것이다.

---

백로그(Back log) : 제품/서비스 구현에 필요한 요구사항 및 예상소요 비용을 산정하는 단계

• ID - 각 스토리를 분류하기 위한 순번
  -> ID값을 설정하는 이유는 그때그때 요청을 받는 내용확인이 빠르게 가능하기 때문.
• 분류 - 페이지 뎁스(Depth) 구분
  -> 페이지를 기준으로 뎁스를 구분한다. 해당 기능이 어떤 페이지에 위치하는지 직관적으로 메이커들에게 알려주기 위함.
• 사용자스토리 - 사용자가 제품을 이용하는 케이스
  -> 사용자의 입장에서 제품을 사용함으로써 기대하는 것. 혹은 사용자의 플로우에서 사용자가 당연히 거쳐야하는 정리해 놓은 것.
• 제약사항 - 사용자 스토리에 대한 예외케이스
  -> 실제로 구현 가능성에 대한 검토 여부
• 상세 - 스토리에 서술된 내용을 구현하기 위해 필요한 작업 내용
• 우선순위 - 각 스토리의 구현 우선순위

 이렇게 백로그를 작성해 놓으면 지속해서 계속해서 업데이트가 되고 초안에서 추가/제거되는 항목을 알 수 있다.

 

WBS (Work Breakdown Structure) : 프로젝트 범위와 최종 산출물을 기준으로 세부요소로 분할한 문서

간트차트 (Gantt Chart) : 업무일정의 시작과 끝을 바(bar)형태의 그래프로 표기하여, 전체 일정을 한 눈에 볼 수 있게 만든 차트
WBS에서 작성된 워크패키지를 기준으로 일정 산정 및 관리

---

이번주도 어찌저찌 수업과 과제를 무사히 끝냈다...(제일 중요한 LMS과제는 아직도 못함...)

사실 강의 시작 전, 첫 2주는 이렇게 빡세게 진도만 겨우 따라갈 수 밖에 없다고 생각했다.하루만 더 출근하면 퇴사니까 나름 잘 버텼다.2주동안 느꼈던 건 사실 강의/과제를 쳐내기 바빠 제대로 공부도 못했다고 생각했다.앞으로 남은 3개월 반은 진짜 쏟아부어보자! 할 수 있다! (일단 당장 LMS과제부터 해결해보자...)