1 Week 정리 및 추가

[Chapter 01] 서비스 기획 첫걸음

서비스 기획

사용자들의 겪고 있는 문제를 찾고 해결하는 모든 과정을 설계하는 것

 

기획 시 프로젝트 진행

1. pre-prodution 
	리서치, 타탕성 검토, 사업성 검토, 개발이슈 검토
    	IA 설계, 필요스펙 정리, 화면설계
2. production
	디자인 팀에 디자인 요청 및 시안 검토
   	 퍼블리싱팀에 퍼블리싱 요청 및 산출물 검토
    	개발팀과 개발, QA, 릴리즈
3. Relesed
	마케팅팀과 홍보, 이벤트 제작/운영
    	운영팀과 CS/장애 대응
    	사업팀과 영업관리, 파트너 관리

 

서비스 기획 방법론

방법론	개념	장점	단점
애자일	일정한 주기로 프로토 타입을 계속 만들어 필요 요구사항들을 추가/개선하여 버전	- 개발 과정이 유연하고 빠름 - 테스트 및 리뷰에 따른 빠른 의사결정(변화에 빠르게 대응)	- 변경내역이 너무 잦을 경우 목표에 혼란 - 높은 업무 집중도
워터폴	개발흐름을 일정에 맞춰 순차적으로 진행	- 일정관리가 안정적으로 가능 - 요구사항이 픽스되어 목표변경에 따른 혼란이 방지	- 개발 속도가 상대적으로 느림 - 개발 방향성에 대한 유연성이 부족

---

서비스 기획자의 프로젝트 진행방식과 기본 방법론에 대하여 알 수 있는 강의였다. 이론적인 부분이라 이해는 했지만 애자일 방식은 어떻게 진행되는지 감이 안잡혔다. 아래 글을 읽고 조금더 이해할 수 있었다.
에자일 방법론 참고 문서

애자일

 시장 요구사항의 변동, 외부적 요인, 내부적 요인으로 얼마든 예외 사항이 있을 수 있는 개발 환경에서 처음부터 완벽한 설계를 가지거나 완벽한 구조를 가지고 개발을 하는 것이 아니라 변동 사항과 개선사항에 대해 유연하게 변화하며 제품을 개발하는 개발 방법론을 말한다.

 

 아무런 계획 없는 개발을 뜻하는 것은 아니라, 애자일 개발을 통해 생겨나는 지나친 유연함의 범용성 있는 모듈 단위 개발로 해결할 수 있다. 범용성을 갖춘 부분을 먼저 만들다가 변경이 생기면 만들어진 부분을 튜닝하여 좀 더 효율적으로 만들거나, 기록해둔 개발 기법이나 방식을 활용하여 쉽게 다음 개발을 하는 등 프로젝트의 철저한 관리가 필요하다

애자일 개발 프로세스의 종류

- 익스트림 프로그래밍(Extreme Programming, XP) : 고객과 함께 2주 정도의 반복 개발을 하고 테스트우선 개발(TDD)
- 스크럼 : 매일 정해진 시간에 정해진 장소에서 짧은시간의 개발을 하는 팀을 위한 프로젝트 관리
- 크리스털 패밀리 : 익스트림 프로그래밍 만큼 엄격하지도 않고 효율도 높지 않지만, 프로젝트에 적용하기 쉬운 방법론
- Feature-Driven Development : feature마다 2주정도의 반복 개발을 실시
- Adaptive Software Development : 소프트웨어 개발 == 혼란을 대전제로, 그에 적응할 수 있는 소프트웨어 방법을 제시하기 위해 만들어진 방법론
- 익스트림 모델링 : 언제나 실행할 수 있고 검증할 수 있는 모델을 작성하는 공정으 반복해서, 최종적으로 모델로부터 자동적으로 제품을 생성

 

---

 

[Chapter 02] 서비스 기획자, PM, PO는 왜 필요한가?

서비스 기획자가 하는일 (문제를 찾고 해결하는 방법)

문제 인식 및 우선 사항 정리 → 시장 조사 & 벤치마킹 →  정책 결정 요구사항 정의 → 
서비스 기획 →  커뮤니케이션 & 매니징 →
QA → 메뉴얼 & 가이드 작성 → 
서비스 운영(지표 확인) → 그로스 해킹

 

OKR(목표와 핵심 결과)

목표를 설정하고 전 직원이 달성하기 위해 노력하고 실제 어디까지 달성되는 지 성과는 수치화하는 방법론

프레임워크	개념
RICE	네 가지 항목을 적용하여 점수를 도출하고 우선순위를 설정하는 방식
MoSCow	업무에 관한 중요성을 직관적으로 구분하여 우선순위를 판별

프레임 워크 참고 문서

※ 백로그 : 개발해야 할 기능과 우선순위

 

우선순위 설정에 중요성

: 제한적 리소스안에서 효율적으로 활용하여 제품의 빠른 성장을위해 선택과 집중할 수 있도록 도와줌

 

우선순위 고려사항

리소스 투자 대비 효과, 개발 공수, 제품의 방향성 등등

 

1. MoSCow

개념	업무를 네 가지로 구분하여 판단하는 매우 간단한 방법 업무에 관한 중요성을 직관적으로 구분하여 우선순위를 판별
	Must have	꼭 만들어야 하는 기능, 서비스의 핵심을 위해 꼭 구현해야하는 기능
	Should have	운영할 때 당장 적용하지 않아도 서비스에 영향이 없는 기능 중 우선순위가 높은 기준
	Could have	서비스를 운영할 때 전혀 영향이 없는 기능 중 우선순위가 낮은 기준
	Won’t have	서비스를 운영하는 데 있어서 전혀 영향이 없으며, 우선순위가 가장 낮은 기준
장점	1.  빠르고 간단하게 판단할 수 있다. 2. 활용 범위가 넓다.
단점	1. 중요도를 정확하게 판단하기 어렵다. 2. 객관전인 판단 가능성이 다소 떨어진다.

 

2. Rice

개념	진행해야 할 업무에 네 가지 항목을 적용하여 점수를 도출하고 우선순위를 설정하는 방식
	Reach	얼마나 많은 수의 사용자에게 영향을 주며, 그들에게 영향이 미치는지에 대한 기준 특정 기간 동안에 얼마나 많은 사용자가 사용할 수 있는지 DAU,(Daily Active Users), MAU(Monthly Active Users)같은 수치로 평가
	Impact	사용자들이 해당 기능을 사용할 때 얼마나 큰 영향을 받게 되는지에 대한 기준 명확한 기준을 수립할 수 없지만, 영향의 척도를 5단계 정도로 구분해서 상대적인 점수를 부여하는 것이 일반적
	Confidence	개발하게 될 기능이 성공할지에 대해 얼마나 확신을 가지는지에 대한 기준 사용자에게 얼마나 만족스러운 가치를 전달하는지
	Effort	백로그를 개발하는 과정에서 시간이나 인력이 얼마나 소요되는지에 대한 기준
장점	제품 관점에서 우선순위를 디테일하게 선정할 수 있음 비교적 정확하고 논리적인 순서로 정할 수 있음
단점	계산 공식이 각각 존재하기에 빠르게 판단하기 어렵다 Confidence이 주관적인 평가나 포함될 여지가 있다

---

 

[Chapter 03] 서비스 기획자에게 꼭 필요한 스킬셋

	필요 역량	추가 설명
1	사용자와 제품에 대한 이해	복잡성 보존의 법칙 어떤 일을 수행 시 복잡성은 정해져있으며 그것을 어떻게 분담하느냐가 사용자 편의에 영향을 준다.
2	비지니스 및 사업 모델에 대한 깊은 이해	생각을 유연하게 가지고 비즈니스를 잘 이해해야 한다.
3	동료들로부터 신뢰를 형성하고, 리드하는 능력	기획자는 프로덕트 팀에게 업무의 이해와 방향성에 대한 신뢰와 동기부여가 중요
4	IT 서비스 개발 업무를 협업하기 위한 도메인 지식
5	성과를 달성하기 위한 아이디어 도출 능력	아이디어는 집념을 가지고 사고하고 데이터로 검증하는 과정이 필수
6	데이터를 이용해서 결과치를 뽑아내고 분석할 수 있는 능력	어떤 시장을 우리가 먼저 진입할지 분석 - CVR : 전환률이 높은 UI로 수정하는데 필요 데이터 - Cohort retention : 동일 기간 특정 이벤트를 경험한 동일군 유저를 세부적으로 나눠 분석하여 서비스에 돌아오는 비율을 추적하여 기획 방향을 정하는데 도움을 주는 데이터
7	논리적 사고와 커뮤니케이션 능력	논리적 사고를 위한 MECE 기법 참고문서  커뮤니케이션 능력 - 두괄식 말하기 - 아마존 6페이지 작성법 : 서론, 목표, 원칙, 현재상황, 이전상황, 앞으로의 계획

MECE

'누락 없이, 중복 없이'라는 내용으로, 빠뜨리거나 중복되는 부분 없이 내용을 '정리'하는 것

 

장점

1. 사람들이 기억하기 쉽게 내 제품/서비스를 전달할 수 있다.

2. 내가 원하는 콘셉트를 짤 수 있다.

3. 어떤 부분이 부족한지 알 수 있다.

---

서비스 기획자의 필요 역량을 알아보는 강의였다. 여기서 나는 도메인 지식은 어느정도 있었는나, 비즈니스의 깊은 이해와 논리적인 사고 커뮤니케이션 그리고 리드하는 능력이 다소 부족하지 않을까 싶었다. 제일 중요하게 생각되는 부분이라 이 역량을 키워야겠다는 생각이 들었다.

 

---

 

[Chapter 04] 서비스 기획자의 업무

MVP

고객에게 가치를 제공할 수 있는 최소한(핵심)의 기능을 구현한 제품

사업 가설을 PMF가 맞는지 테스트하는 용도

 

PMF

Product-Market-Fit

 

PMF 측정법 참고 문서

1. 정량적 지표

순 추천 점수(NPS) : 고객에게 제품이나 서비스를 다른 사람에게 추천할 가능성이 얼마나 있지 확인하는 방법
성장률 : 특정 기간(하루, 주, 월, 분기 등) 내 지표들의 점점 커지는지 비율, 꾸준한 우상향이 중요
재방문율 : 제품을 다시 사용하기 위해서 방문하고, 그 수치가 일정하게 유지 시
LTV : 한 명의 고객이 제품을 이용하는 전체 기간 내 가져다주는 수익의 합
CAC : 한명의 고객이 제품을 사용하게끔 하는 데 드는 비용
- LTV : CAC 3:1 배율이 이상적
40% rule : ‘제품을 사용할 수 없다면 어떻겠습니까?'라는 설문조사의 응답에 40% 이상이 매우 실망으로 답변받는 경우

2. 정성적 지표

시장 반응
입소문과 추천

PMF 찾는 과정

비즈니스 모델을 세운다.
- 가설을 세우고 실험을하고 계속 고객을 만나 수정한다. 이전 실패로 빠르게 학습한다.
시장 검증
- 해결하려는 문제에 고객이 관심이 있는지 그 문제를 위해 대가를 지불할 의지가 있는지 조사
인터뷰
- 어떤 문제가 있어서 서비스에 어떤 가치를 느끼는지 어느정도의 비용 지불 의사가 있는지, 어떤 행동패턴이 있는지, 구체적인 동기가 무엇인지  조사
제품 개발과 고객 유입
- MVP를 하며 고객을 세분화하고 조사해나가면서 어떻게 발전해 나갈 것인지 고민 

 

OMTM(One Mectric That Matters)

가장 중요한 단 한가지 지표
한정된 자원을 가진 스타트업에선 하나의 목표 지표에 집중해야 함
각 서비스 카테고리마다 달라짐

---

각 기업의 성장도 별로 서비스 기획자의 업무가 달라지는데, PMF를 찾지 못한 스타트업 기준으로 PMF를 찾고 MVP를 만들어 가설을 측정하는 법과 단기간에 목표를 설정하는 OMTM에 대해서 배웠다.

PMF가 이해는 됐지만, 측정 방법이 이해하기 너무 어려워서 따른 문서를 찾아봤다. PMF를 찾는 과정을 하게된다면, 무엇보다 데이터 분석 능력이 중요하지 않을까 생각해 보았다. 또 무엇보다 찾기 어려운 만큼 이것을 찾아 서비스를 성공시킨다면 무엇보다 PM으로써 가장 뿌듯한 일이 될 작업같다.