08. 서비스 기획 업무 A~Z 알아보기
3. 서비스 비즈니스를 이해하기 _ 린캔버스
1) PO에게 비즈니스가 중요한 이유
- PO(Product Owner)는 UX, Tech, Business 세 가지 분야에 대한 이해를 바탕으로 팀을 이끌며, 비즈니스와 개발자의 요구사항을 매니징.
- (비즈니스의 요구사항) ← (Product Owner) → (개발자의 요구사항)
2) 린캔버스의 정의
- 린캔버스는 스타트업의 비즈니스 모델을 쉽게 표현할 수 있는 도구.
- '비즈니스 모델 캔버스'에서 파생되었으며, 일부 항목이 추가/삭제되었습니다.
- 삭제항목: 스타트업 기준으로 시기상조인 항목 제외 (고객관계, 핵심자원, 핵심파트너십)
- 추가항목: 가설검증 항목 추가 (문제, 솔루션, 핵심지표, 경쟁우위)
3) 린캔버스의 활용
- 초기 창업자가 본인이 새로 진행하게 될 사업에 대해 이해하고, 비즈니스 기획에 대해 평가하기 위해 활용 (스타트업, 신사업 진행 시, 비즈니스 구체화)
- 린캔버스는 서비스 기획자가 회사의 핵심 비즈니스 모델과 프로덕트에 대해 명확하게 이해하는 데 도움을 줍니다. 이를 통해 서비스 기획의 퀄리티가 상승하며, 시장 내 성공 가능성이 높아집니다.
4) 린캔버스의 세부 항목
1. 문제(Problem): 서비스가 해결하고자 하는 문제를 정의.
- 기업이 해결하고자 하는, 고객들이 해결이 필요한 문제 TOP3
2. 고객세그먼트(Customer Segments): 서비스의 타겟 고객을 세분화
- (모든 사용자가 사용하면 좋겠지만) 사업초기에는 타겟을 세분화, 핀포인트로 공략 → 최근 시장 내, 다양한 제품 → 고객의 나이대, 성별, 취미생활 등 구체화 및 이해하여 제품 개발
3. Unique Value Proposition(UVP, 고객에게 제안할 차별화된 가치): 서비스의 차별화된 가치를 제안. (차별화 포인트)
4. 솔루션(Solution): 문제 해결을 위한 서비스의 핵심 솔루션을 제시.
- 솔루션 가설을 TEST하여 핵심 UVP 강화 & 최고의 솔루션 제안
5. 채널(Channels): 잠재 고객과 만날 수 있는 접점을 정의.
- 우리 프로덕트는 어디서 잠재고객을 만나는가?
- 잠재고객은 우리 프로덕트를 어디서 발견하는가?
6. Revenue Streams: 수익 창출 방법을 설정.
- Ex) 페이스북, 유튜브: 광고비를 통해서 수익창출
- 리그오브레전드: 무료게임 제공하고 스킨판매로 수익창출
- 블라지드: 유료게임으로 수익창출
7. 비용 구조(Cost Structure): 서비스 유지를 위해 필요한 비용을 계산.
- CAC(Customer Acquisition Cost): 우리 서비스가 한 명의 고객을 끌고 오는데 드는 비용
- Distribution Costs: 마케팅
- Hosting: 서버 호스팅 비용
- People: 인건비 등
8. 핵심 지표(Key Metrics): 서비스 성공 여부를 파악할 수 있는 핵심 지표를 설정.
- 데이터 기반의 의사결정, 서비스 기획(아이디어)의 큰 부분
9. 불공정한 장점(Unfair Advantage): 경쟁사가 쉽게 따라할 수 없는 서비스의 독특한 장점을 찾는다.
- 경쟁사 or 돈 많은 경쟁사가 동일한 시장에 들어와서, 쉽게 따라 할 수 없는 우리 프로덕트의 장점은?
4. 애자일 방법론이란?
1) 애자일 방법론이란?
- 미리 모든 것을 계획하고 개발을 시작하는 전통적 개발 방법론(Waterfall) 과 다르게,
최소 기능 제품을(MVP) 빠르게 개발하여 유저들의 피드백을 받고, 해당 피드백을 바탕으로 지속적으로 개선해나가는 개발 방법론
2) 애자일 방법론과 워터폴 방법론 비교
- 애자일: 순환형 사이클, 작고 빠르게 실행, 유저 반응에 민첩하게 반영, 지속적 개선
- 워터폴: 순차적 진행, 요구사항에 대한 세부적인 계획 및 문서화, 심플하고 적은 변경사항
3) 애자일 방법론의 장점
- 잘못된 제품 개발 시간 최소화
- 실패 확률 낮춤 (더 자주 유저의 피드백을 얻을 수 있기 때문)
- 계획이나 기능 수정에 유연 (급변하는 시장에 유연하게 대처 가능)
4) 애자일 방법론의 단점
- 요구사항이 명확한 경우 속도가 늦어질 수 있음
- 최종 제품이 요구사항과 달라질 수 있음
- 기술적 완성도가 떨어질 수 있음 (급격하게 성장한 스타트업이 레거시 코드를 리펙토링 하는데, 시간 소요가 큼)
5. 애자일에서의 일을 쪼게는 단위
1) 애자일에서의 작업 단위
1. Theme: ex) 모바일 배달음식 플랫폼
2. Epic: ex) 고객은 배달 음식점의 리뷰를 본인에 맞춰 개인화함 확인 가능(다양한 이야기 구성, 고객의 Story가 모여서 고객을 만족시키는 큰 스토리)
3. Story(기본단위): 고객의 행동을 나타냄 / ex) 고객은 배달음식점의 사진 리뷰만 모아 볼 수 있다.
4. Task: Story를 가능하게 하기 위해서 직접 수행해야 하는 업무 / ex) 사진리뷰 필터 구현
2) 애자일에서의 일을 쪼게는 단위
- PO는 특정 기간 동안, 어떠한 Story 를 개발할 것인지를 정하고,
해당 Story 를 완성하기 위해서 어떠한 작업을 해야할 지 파악하여 Task 를 생성하여 담당 개발자들에게 할당
이후, 정기적인 미팅을 통해 각 Task 들의 진행상황을 지속적으로 파악하는 것이 PM 의 주요 역할
→ 실제 유저에게 배포 후, 1) 유저에게 어떤 가치를 줬는지? 2) 실제로 제품은 얼마나 개선되었는지? 3) 개선된 수치 파악해서 개발팀과 공유
3) 애자일 방법론 활용 예시: 당근마켓 아르바이트 중개 기능
1. Theme: 지역기반 중고거래 플랫폼 → 지역기반 종합 플랫폼
2. Epic: 유저는 지역기반의 아르바이트 중개 기능을 사용할 수 있다.
3. User Story: 다양한 유저 스토리를 작성 후, 개발팀과 업무 우선순위 결정
- 업체 사장님은 아르바이트 공고 작성할 수 있다 (High)
- 일반 유저는 아르바이트 광고 리스트 확인할 수 있다 (High)
- 일반 유저는 아르바이트 광고 리스트 중 광고를 선택하여 열람할 수 있다 (High)
- 일반 유저는 아르바이트 광고 리스트를 업무별, 시급별 등 필터링 할 수 있다 (Low)
- 일반 유저는 아르바이트 광고 중 원하는 광고는 저장할 수 있다 (Low)
- 일반 유저는 아르바이트 광고 중 원하는 광고는 지원할 수 있다 (Medium)
4. Task: 스토리를 달성하기 위한 세부적인 업무
- 업체 사장님은 아르바이트 공고 작성할 수 있다 (High)
- 아르바이트 광고작성 페이지 개발
- 일반 유저는 아르바이트 광고 리스트 확인할 수 있다 (High)
- 아르바이트 공고 리스트 개발
- 지역별 공고 리스트 추천 로직 개발
- 일반 유저는 아르바이트 광고 리스트 중 광고를 선택하여 열람할 수 있다 (High)
- 아르바이트 공고 디테일 페이지 개발
6. 스크럼(Scrum)이란?
- (1995) Ken Schwaber와 Jeff Sutherland가 착안한 소프트웨어 개발 방법론
- 기존과 다르게, 부분적으로 완성된 결과물들이 만들어지고, 이를 통해서 유저에게 가치 전달
- 반복주기: Agile(애자일) = lteration(리터레이션) / Scrum(스크럼) = Sprint(스프린트)
- Scrum은 이 Sprint를 반복적으로 진행하면서 제품을 개발해 나아가는 방법
- Scrum은 관리도구 X, 진행도구 O
(Waterfall과 다르게, Agile은 팀 전체가 협동해서 일정한 속도로 지속적으로 유저들에게 가치 전달 & 이를 통해서 피드백을 받는 것이 매우 중요하기 때문에 '진행도구' 관점으로 개발)
1) 스크럼의 어원
- 스크럼은 럭비 용어로, 모든 팀원이 한 덩어리로 뭉쳐서 공을 주고 받으며 함께 밀고 나가는 럭비 경기 형태에서 유래.
2) 스크럼의 활용 시점
2-1) 스크럼 활용시점
- Not fully knowable but reasonably predictable, the unknown unknowns : Unknown Unknowns(알려지지 않은 불확실한 일)
- Neither requirements nor the execution are clear
- 세로축: What (위로 갈수록 무엇을 만드는지 잘 모름 ~ 아래로 갈수록 명확함)
- 가로축: How (좌측으로 갈 수록 잘 아는 영역 ~ 우측으로 갈 수록 모르는 영역)
- 무엇을 하고, 어떻게 하는지 모두 복잡한 경우에는 워터폴과 애자일을 사용하며, 더욱 복잡한 상황에서는 스크럼을 사용합니다.
- 극단적으로 높은 불확실성이 있는 경우에는 완료 예상 방법에 대해 명확하게 정하지 않는 칸반(Kanban) 방법론을 사용합니다.
1) 무엇을 하는지? 무엇을 어떻게 하는지? → Waterfall
2) 무엇을 하는지? 어떻게 하는지 복잡할 경우? → Waterfall, Agile
3) 더 복잡한 상황이 될 수록 → 스크럼(Scrum) > 워터폴에 비해서 좋음
4) 극단적으로 높은 불확실성(목표완료 일정 잡기 어려움) → (완료 예상 방법에 대해 명확하게 정하지 않는) 칸반(Kanban) 방법론
7. 스크럼 스플린트 전 프로세스
- 스크럼(Scrum) 개발 방법롭의 핵심: 전체적인 과정이 반복적으로 지속되는 것
: 프로덕트 백로그 관리 → 스프린트 플래닝 미팅 - 스프린트 백로그 선정 → 스프린트 (스프린트 진행되는 도중에 매일진행되는 데일리 스크럼) → 업무 완료되면 스프린트 리뷰
1) 제품 백로그(Product Backlog) 관리 (by Product Owner)
- 제품 개선을 위해 필요한 다양한 요구사항을 포함.
- 제품과 관련된 다양한 인원들로부터 요구사항을 수집.
- 요청자, 백로그 생성 이유, 추정시간, 요구명세 등을 포함.
- 우선순위는 반드시 포함되며, 시장과 비즈니스 중요도를 고려하여 백로그의 우선순위를 관리.
2) 제품 백로그(Product Backlog) 작성법
- 요구사항을 작성하되, 구체적인 실행방안은 작성하지 않아도 된다.
- 백로그 진행이 중요한 이유에 대해 자세히 작성하면, 우선순위 산정 및 제품 개발에 용이.
3) 제품 백로그(Product Backlog) 우선순위 산정
- 제품 소유자(Product Owner)는 비즈니스적 & 테크적 중요도를 파악하여 각 백로그별 우선순위를 정해야 한다.
- 우선순위가 높은 백로그는 구체화하고, 당장 다음 '스프린트'에서 개발 가능한 상태로 만들어야 한다.
4) 스프린트 플래닝 미팅(Sprint Planning Meeting)
- 통상 1~4주 정도의 Time box 성격을 가진 개발주기 (보통 2~4주)
: 제품 주기가 빠르거나, 개선을 반영할 수 있는 상황이라면, Sprint 단위를 짧게
- 이번 스프린트에서 진행할 백로그를 모든 팀원들이 함께 논의하는 회의.
- 제품 소유자는 독단적으로 목표를 설정하면 안 된다.
- 스프린트 플래닝 미팅을 통해 스프린트 백로그를 선정.
5) 스프린트(Sprint) 진행
- 1~4주 정도의 개발주기를 가집니다.
- 각 스프린트 단계 종료 시 새로운 기능이 추가되어 제품에 반영되는 것이 목표.
- 스프린트가 지속적으로 반복되면서 제품이 개선되고, 유저에게 새로운 가치를 제공.
8. 스크럼 스플린트의 진행
- Sprint 진행 (by Scrum Master)
1) 스크럼 마스터(Scrum Master) 역할
- 스프린트의 진행 상황을 검토하고, 목표 달성에 위협이 되는 사항들을 확인하여 해결하는 역할을 담당.
- 커뮤니케이션 이슈, 우선순위 선정에 대한 이견 등 모든 문제들을 조정. (Servant Leadership(섬기는 사람) 필요)
- 대부분의 경우, 제품 소유자(PO)나 프로젝트 매니저(PM)이 스크럼 마스터 역할을 병행.
2) 데일리 스크럼 미팅(Daily Scrum Meeting)
- 목표 달성 확률을 최적화하기 위해 팀원들에게 공유하고, 팀원의 도움을 요청하는 자리.
- 스크럼이 진행되는 동안, 매일 약 15분 동안 진행되는 짧은 미팅.
- 스프린트가 목표에 맞게 진행되고 있는지, 스프린트 백로그의 작업이 잘 완성되고 있는지를 검토.
3) 스크럼 미팅에서의 주요 확인 사항
- 나는 어제 하루 동안 개발팀의 <스프린트 목표 달성을 위해> 무엇을 했는지?
- 나는 오늘 하루 동안 개발팀의 <스프린트 목표 달성을 위해> 무엇을 할 것인지?
- 나 혹은 개발팀이 <스프린트 목표 달성을 위해> 위험/방해요소가 있는지?
'PM(Product Manager) > 학습일지 3주차' 카테고리의 다른 글
| 5 day 2024.01.19. (0) | 2024.01.19 |
|---|---|
| 4 day 2024.01.18. (0) | 2024.01.18 |
| 3 day 2024.01.17. (0) | 2024.01.17 |
| 2 day 2024.01.16. (0) | 2024.01.16 |
