서비스의 비즈니스를 이해하기
PO 에게 비즈니스가 중요한 이유
🧑🏻💻 PO(Product Owner)란?
- IT회사에서 하나의 프로덕트가 완성되기 전까지 꼭 필요한 분야 3가지(UX, Tect, Business)
모두에 대한 이해를 바탕으로 서비스를 기획하고 프로덕트팀이 올바른 일을 효율적으로
할 수 있게끔 팀을 이끄는 역할
- 비지니스 관계자들의 요구사항, 개발 관계자들의 요구사항 이 두가지를 심도 깊게 이해하고
양사이드를 서로 간에 설득하면서 양측에 니즈가 적절하게 반영된 프로덕트를 만들어 나갈 수 있도록 프로덕트 팀을 리드하고 매니징 하는 역할⇨ 즉, 프로덕트 오너는 프로덕트 팀이 무엇을 어떻게 만들지 계획하고 팀을 이끄는 역할!
이러한 프로젝트 오너는 본인이 속한 기업이 어떤 사업을 하고 어떻게 돈을 벌 것이며, 향후 어떤 방식으로 성장해 나갈 것인지에 대해 정확히 이해해야한다!
서비스의 비지니스를 돕는 툴, 린 캔버스
✅ 린 캔버스
스타트업의 Business Model을 쉽게 표현할 수 있는 도표
초기 창업자가 신사업에 대해 이해하고 비지니스 기획에 대한 평가, 비지니스 모델 구체화할 때 사용
1. Problem : 고객이 필요로 하고 기업이 해결하고자 하는 문제점 Top3
⇨ 우리는 어떤 문제를 해결하고자 하는가?
2. Customer Segment : 프로덕트의 타겟 고객
⇨ 우리 프로덕트는 어떤 고객을 위해서 존재하는 가?
3. UVP(Unique Value Propositon) : 고객에게 제안할 차별화된 가치 ✨가장 중요✨
⇨ 우리 프로덕트를 고객들이 왜 구매/사용해야 하는 가? 우리 프로덕트는 무엇이 다른가?
⇨ 고객의 관점에서 서술하는 것이 가장 중요!!!
4. Solution : 고객 문제에 대한 해결책
⇨ 우리 프로덕트는 고객 문제를 해결하기 위해 어떤 기능을 제공하는 가?
⇨ 기업 입장에서 작성
⇨ UVP가 작성되어 있다면 유저에게 핵심적인 가치 제안을 하기 위해 우리 기업이 제공할 수 있는 해결책에 대한 내용
ex)
- 🥕당근마켓🥕
지역 인증을 통한 지역 기반 중고 거래 (UVP : 당신 근처의 마켓)- 🏠오늘의 집🏠
제품 태그 기능을 통해서 집들이를 보다가 제품 구매로 이어질 수 있도록 연결
역으로 제품을 보다가 해당 제품을 사용된 집들이 콘텐츠를 볼 수 있게 만들어 주면서 본인이 갖고 있는 핵심 UVP를 강화시킴
⇨ 솔루션은 제품 초기 단계에서 확정할 수 없다
⇨ 다양한 솔루션들을 가설로 만들고, 지속적인 실험을 통해 최고의 솔루션 발견 중요
사업 초기는 최대한 작게 시도하고 이를 통해 레슨을 얻어가면서 솔루션을 발견하고 개선해 나가는 것이 중요!
5. Channels : 고객과의 점점
⇨ 우리 프로덕트는 어디서 잠재 고객을 만날 것인가? 잠재고객들은 우리의 프로덕트를 어디서 발견하게 될 것인가?
⇨ 핵심고객을 빠르게 만나 그들로부터 빠르고 즉각적인 피드백 얻을 수 있는 채널을 발견하는 것이 중요
6. Revenue Streams : 수익 창출에 관련된 모든 내용
⇨ 우리 프로덕트는 어떻게 수익을 창출할 것인가? 어떠한 부분을 강화해서 수익 창출할 것인가?
⇨ 프로덕트의 수익 구조를 인지하는 것이 중요
7. Cost Structure : 서비스를 유지하기 위해 발생되는 비용 구조 LTV
⇨ 우리 프로덕트가 지속적으로 서비스 되기 위해서는 어떤 비용들이 발생하는가?
⇨ 우리 서비스가 한 명의 고객을 끌고 오는 데 있어서 얼마의 비용이 소비되는가?(서버 호스팅, 마케팅, 인건 비용)
8. Key Metrics : 핵심 지표
⇨ 우리 프로덕트가 제대로 서비스 되고 있는 가를 파악할 수 있는 핵심 지표는 무엇인가?
⇨ 핵심 지표를 지속적으로 측정 및 관리하는 것은 PO의 매우 중요한 능력
⇨ 데이터 기반의 의사결정/서비스 기획에 핵심 지표는 큰 부분!
⇨ 서비스에 대한 Key Metrics를 뽑아낼 수 있다면 어떠한 가설이 옳은 것인 지 판단 가능
9. Unfair Advantage : 불공평한 장점
⇨ 경쟁자가 생긴다고 해도 쉽게 따라올 수 없는 우리 프로덕트만의 장점은 무엇인가?
⇨ 돈으로 해결할 수 없는/쉽게 따라할 수 없는
핵심 장점을 이해하하고 이를 크게 강화시킬 수 있는 서비스를 제안하는 것이 중요
서비스 기획자는 린캠퍼스를 통해 프로덕트에 대해서 명확히 이해하고 서비스를 기획해야 한다!
애자일 방법론 기반으로 프로젝트 진행하기
애자일
🤔 애자일 방법론이란?
최소 기능 제품을 빠르게 개발하여 유저들의 피드백을 받고
해당 피드백을 바탕으로 지속적으로 개선해나가는 개발 방법론
장점
- 잘못된 제품을 개발하는 데 사용하는 시간 최소화
- 더 자주 유저의 피드백을 얻을 수 있기 때문에 실패할 확률 ↓
- 계획/기능에 대한 수정/변경에 유연하게 대처 가능
단점
- 요구사항이 명확할 경우, 오히려 속도가 늦춰질 수 있음
- 최종 제품이 요구사항과 달라질 수 있음
- 고객에게 제공하는 가치에 집중하기 때문에 기술적 완성도가 떨어질 수 있음
🪄애자일에서의 일을 쪼개는 단위
Theme > Epic > Story> Task
-
Theme: 플랫폼
ex) 모바일 배달 음식 플랫폼 -
Epic: 스토리가 모인 것
ex) 고객은 배달 음식점 리뷰를 본인에 맞춰 개인화하여 확인할 수 있음 -
Story(기본단위) : 고객의 행동 ⇨ 배포
ex) 고객은 배달 음식점의 사진리뷰만 모아볼 수 있음 -
Task: Story를 완성함에 있어서 직접 수행해야 하는 업무
ex) 사진리뷰 필터 구현
⇨ 유저 스토리들이 있고, 이 유저 스토리 등의 복수의 유저 Story들이 모여 Epic을 이루고,
이 Epic들이 모여 Theme를 이룬다.
유저 Story들을 쪼개서 Task를 만들고, 이 Task보단 작은 Task들은 Sub Task로 진행한다.
❓쪼개진 단위로 실제로 어떻게 업무가 진행될까요❓
1. PO 또는 프로덕트 팀이 모여서 특정 기간동안 우리가 만들어진 다양한 필요 Story들 중
실제 개발할 Story를 선정
2. 개발팀은 이 유저 Story를 완성하기 위해 어떤 작업들이 필요한 지 파악해서 Task들을 생성
3. Task 담당자 지정
4. 정기적 미팅을 통해 각 Task들의 진행 상황 지속적 파악하고 완료 상태로 만듦
⇨ PM의 주요 역할
5. 유저에게 Story 배포
6. 유저에게 어떤 가치를 주었는 지 파악해서 개발팀에게 공유이 과정 지속적으로 반복
ex)
🥕당근 마켓 아르바이트 중개 기능🥕
1. Theme :
지역 기반 중고 거래 플랫폼 ▶ 지역 기반 종합 플랫폼
2. Epic :
유저는 지역 기반의 아르바이트 중개 기능을 사용할 수 있다.
3. User Story :
- 1) 업체 사장님은 아르바이트 공고를 작성할 수 있다
上 - 2) 일반 유저는 아르바이트 공고 리스트를 확인할 수 있다
上 - 3) 일반 유저는 아르바이트 공고 리스트 중 공고를 선택하여 열람할 수 있다
上 - 4) 일반 유저는 아르바이트 공고를 업무별/시급별 필터링 할 수 있다
下 - 5) 일반 유저는 아르바이트 공고 중 원하는 공고를 저장할 수 있다
下 - 6) 일반 유저는 아르바이트 공고 중 원하는 공고를 지원할 수 있다
中
Task:
- 1) 업체 사장님은 아르바이트 공고를 작성할 수 있다
上
1-1) 아르바이트 공고 작성 페이지 개발 - 2) 일반 유저는 아르바이트 공고 리스트를 확인할 수 있다
上
2-1) 아르바이트 공고 리스트 개발
2-2) 지역별 공고 리스트 추천 로직 개발 - 3) 일반 유저는 아르바이트 공고 리스트 중 공고를 선택하여 열람할 수 있다
上
3-1) 아르바이트 공고 디테일 페이지 개발
대표적인 애자일 개발 방법론 - 스크럼
애자일 개발 방법론에서는
각 반복 주기가 종료됨에 따라 부분적으로 완성된 결과물이 만들어진다.
이를 통해 유저에게 가치가 전달되는 데 이 반복 주기를
- 애자일에서는
"Iteration", 스크럼에서는"Sprint"라고 한다.
🤔 스크럼이란?
- 애자일 소프트웨어 개발 방법론 중 하나로 반복적이고 점진적인 개발 방법
- 스크럼은 Sprint를 반복적으로 진행하면서 제품을 개발해 나가는 방법론
- 스크럼은 관리 도구 X 진행 도구 O
✅ 스크럼 활용 시점
- 무엇을 어떻게 할 지 명확/심플 ⇨ 워터폴
- 무엇을 어떻게 할 지 불확실/복잡 ⇨ 스크럼
BUT! 스크럼 또한 주기를 가지고 개발되기에 어느 정도의 확실성은 보장되어야 함!
목표 완료 일정 설정이 어렵다면 칸반 방법론 등을 사용하는 것이 좋다.
스크럼 :: 스프린트 전 프로세스
1. Product Backlog
- 제품 개선을 위해 진행되어야 할 요구사항
- 제품 관련 다양한 인원들로부터 수집
- 요청자, 백로그 생성 이유, 추정 시간, 요구 명세 등 다양한 내용 포함
- 우선 순위 반드시 포함
📝 Backlog 작성법
- 요구사항을 작성하되, 구체적인 실행방안에 대해선 작성하지 않아도 됨
⇨ 실행방안에 대해서는 프로덕트 팀이 직접 솔루션을 찾아내는 것이 효율적 - 백로그 진행이 중요한 이유에 대해 자세히 작성할수록 우선 순위 산정 및 제품 개발에 용이
BUT! 필수 작성 조건 너무 많이 만들어두면 다양한 인원들로 부터 쉽게 얻을 수 없게 됨!
⇨ 부담감은 줄이되 필요 사항들은 최대한 받아낼 수 있는회사마다의 조건을 만들어 두는 것이 좋음
🧑🏻💻 PO가 수행해야할 Product Backlog 우선 순위 설정
- 지속적으로 다양한 백로그를 관리하면서 시장/팀 상황 그리고 비지니스 중요도를 고려해 백로그 우선순위들을 관리
- 백로그 ⇨ 현재 유저가 갖고 있는 문제점 또는 그 문제점을 해결할 수 있는 가설 정도로 작성
명확한 솔루션 ⇨ 프로덕트 팀이 만들어 나가도록 해야 함 - 각 구성원들에게 백로그의 요구사항과 백로그 중요한 이유에 대해 명확하게 작성되면 될 수록 우선순위가 높게 산정되고 제품 개발이 빠르게 될 수 있다는 것을 충분히 인지시키면서 제품 백로그의 질을 높여 나감
- 높은 우선 순위 ⇨ 자세히 작성, 최대한 작고 구체화 ⇨ 바로 개발이 용이하도록 만듦
낮은 우선 순위 ⇨ 크고 넓은 단위, Epic
2. Sprint Planning Meeting > Sprint Backlog 선정(by Team)
♻️ Sprint란?
- 1~4주 정도의 타임박스 성격을 가진 개발 주기
- 각 스프린트 단계 종료시 새로운 기능이 추가되어 제품에 반영되는 것을 목표
- 스크럼은 Sprint를 반복하며 제품을 개발해나가는 과정
🤝 Sprint Planning Meeting란?
- Backlog들 중 이번 스프린트에 어떤 백로그를 진행할 지 모든 팀원들이 함께 논의하는 회의
- PO가 단독적으로 목표 설정 X
- Sprint Planning Meeting을 통해 Sprint Backlog를 선정
- 보통 Sprint Backlog는 일단 Spring가 시작된 이후에는 변경하지 않는 것을 원칙으로 함
스크럼 :: 스프린트의 진행
🙌🏻 Sprint 진행 ⇨ Scrum Master
- Sprint 진행 상황 검토, 목표 달성에 위협이 되는 사항 확인하여 해결
- 커뮤니케이션 이슈, 우선 순위 선정에 대한 의견 등 모든 문제들을 조정
- 보통 Scrum Master를 따로 두는 기업은 드물고 PM or PO가 주도적으로 운영
📌 데일리 스크럼 미팅에서 주요 확인 사항
- 어제 목표 달성을 위해 무엇을 했는지
- 오늘 목표 달성을 위해 무엇을 할 것인지
- 목표 달성에 방해요소가 있는지?
- 어제 한 일, 오늘 할 일, 이슈 사항 공유 (보고 하는 자리X, 목표 달성을 최적화 하기 위한 공유의 자리)
스크럼 :: 스프린트 종료 후 프로세스
🗣️ 스프린트 리뷰
- 모든 팀원 참여
- Sprint를 통해 무엇이 완료되었는 지 팀원, 이해관계자들에게 리뷰
⇨ 주로 유저 Story 공유 및 제품 데모를 보여줌
⇨ 유저에게 전달된 가치를 유저 입장에서 이해할 수 있어야 함
⇨ 개발을 통해 얻고자 했던 이유, 성과, 기대 효과등을 설명 - 리뷰 결과와 스프린트 수행 중 변경된 백로그 고려하여 다음에 무엇을 할 지 논의
- 경과 보고를 위한 미팅이 아닌, 스프린트를 통해 완료된 개선 사항을 발표
⇨ 피드백을 받고 협력 촉진하기 위한 회의
💭 스프린트 회고
- 다음 스프린트 동안 무엇을 개선할 수 있을 지 계획할 기회 제공
- 팀워크 & 생산성을 높힐 수 있는 자리
스프린트 회고 방법 :: KPT
Keep: 좋았던/계속 유지되었으면 하는 부분Problem: 잘 되지 않았던/고쳐져야 하는 부분Try: 해결할 수 있도록 실천할 수 있는 부분(구체적/실행가능한)
애자일 방법론 :: 칸반
⏩칸반이란?
- 연속적 흐름 처리 방식
- 이슈는 큐에 입력되고, 개발 프로세스의 단계에 따라 당겨짐
- 각 단계가 Push가 아닌 특정 단계의 작업이 완료되었을 때 전 단계의 수행을 지시하여 Pull 방식으로 진행
- 칸반은 칸반 보드로 시각화되고 각각 단계는 열로 표시
📌칸반 실천법
- 시각화
- 칸반 보드는 시작, 끝 지점이 열로 나눠져 있어 왼쪽부터 오른쪽으로 흘러가도록 구성
- 카드 : 작업단위 | 카드가 속해있는 열 : 해당 카드의 프로세스 단계 | 행 : 스윔레인(epic으로도 나눌 수 있음
- 각 단계 사이에 진행 중 업무 WIP(Work In Progress) 제한이 표기되어 있어야 함
- 어떤 열에 다음 열로 옮기기 전에 완료되어야 하는 일이 무엇인 지 명확히 정책을 만들어두어야 함
- 진행 중 업무 제한 WIP(Work In Progress)
- WIP 제한 -> push가 아닌 Pull로 업무 방식 변경
- 하나의 열에 WIP 제한 기준만큼 카드가 있을 경우, 카드 완료 후 다음 단계로 보내기 전까지 새로운 카드 당겨올 수 없음
- 부분적 완료한 업무가 많아져 발생하는 낭비 줄임
- 완성된 제품을 배포할 때까지 리드 타임을 줄여 고객에게 더 자주 배포하고 피드백 받음
- TO-DO의 행에 이슈를 우선순위에 따라 나열하고 작업자는 우선 순위대로 이슈를 처리
- 한번 이슈에 처리를 시작하면 해당 이슈를 끝낸 후 다음 이슈를 확인 하고 업무에 들어감
- 흐름 관리
- 완성 제품이 생산될 때까지 리드 타임 측정 및 최소화, 지속적 관리
- 전체 업무 흐름 파악 및 개선
- 정책 명시화
- 정책을 명시화하여 모든 구성원이 숙지 및 동일한 방식으로 일하는 것이 중요
- 효용가치 없는 경우 수정/변경
- 정책(WIP제한, WIP제한 개수, 완료, 정의 등)을 팀에 맞춰서 수정할 수 있는 유연성
- 피드백 루프 실행
- 칸반 시스템이 제대로 활용될 수 있도록 리뷰 진행
- 7가지 리뷰 : 전략, 운영, 위험, 서비스제공, 재보충, 칸반, 제공 계획 리뷰
- 전략 리뷰 : 지속적으로 내/외부 상황, 경쟁자 상황 등을 파악해서 움은 프로덕트 만들 수 있게끔 전략 (분기별로 진행)
- 위험 리뷰 : 흐름을 막고 있는 특정 프로세스에 대한 이유 파악 및 개신 진행 회의 (월 1회 진행)
- 제보충 회의 : 신규 업무 TO-DO에 넣어 칸반 보드에 넣을 것인지 팀원들과 고민하여 진행 (스프린트 플래닝 미팅 동일 / 주 1회)
- 칸반 리뷰 : 매일 완료된 업무와 함께 병목 현상 파악 및 문제점 개선 방향 회의 (데일리 스크럼과 동일 / 매일 15-.30분)
- 함께 개선하고 실험을 통해 발전
- 규범에 얽매이지 않고, 조직의 상황에 적응하며 발전
- 지속적이고 점진적인 개선 추구
- 경험을 통해 조직에 맞는 최선 찾는 것 중
🤔 칸반의 장점과 단점
장점
1. 규범이 많지 않아 조직에 도입하기 용이
⇨ 미숙함 등 단점 커버, 시간 단축
2. 데드라인 없어서 속도에 대한 압박감, 부담감 적음
⇨ PO가 연속적인 흐름 지속적으로 파악하여 문제없도록 진행
3. 시간 리소스 낭비 막을 수 있음 ⇨ 유연하게 대처
4. 병목 지점 쉽게 파악 가능 / 저품질 상태 배포 최소화
단점
1. 규범이 없어 Anomy 상태 될 수 있음 (무규범상태)
2. 압박감이 없어 자발적 실천 문화가 약하거나 프리라이더가 많을 경우
긴장감 떨어지고 전체적인 생산성에 영향을 미칠 수 있음🤐 칸반_스크럼과의 차이점
- 역할을 지정 하지 않음
- 제품책임자 / 개발팀 / 스크럼 마스터 등의 역할이 따로 존재하지 않고 유연하게 진행 가능- 이터레이션(스프린트) 진행되지 않음
- 기간이 정해진 스프린트를 반복하는 스크럼과 달리, 칸반은 기간을 따로 고정하지 않음
- 배포 가능한 기능이 완성될때마다 배포하고, 새로운 기능 개발이 가능한 시점에서 끌어와 개발을 시작하는 방식으로 진행하여 맺고 끊음 없이 지속적으로 흐름이 유지됨- WIP 제한
- 스크럼은 스프린트 백로그의 양을 조정하며 팀의 제품 개발 속도를 측정하지만, 칸반은 이터레이션을 사용하지 않기 때문에 워크플로우 상태에 WIP 를 지정하여 일의 속도를 조절 및 파악- 스프린트 백로그 변경 가능 여부
- 스크럼에서는 일단 스프린트가 시작되면 스프린트 백로그를 변경하지 않는 것이 원칙이지만 칸반은 언제든지 작업을 추가, 수정할수있음- 보드 초기화 여부
- 스크럼에서는 매 스프린트마다 보드가 생성되고, 해당 스프린트에 진행합 사항들을 보드에 넣어두고, 그전에 끝내지 못한 사항들은 다시 백로그로 보내는 작업을 하지만, 칸반은 지속적으로 보드가 유지됨
🐣 오늘자 일기
요새 몸이 너무 너무 좋지 않다,, 컨디션이 진짜 내 마음같지않다,,,🤕🤕
자취하지만 그래도 최대한 집밥을 먹을려고 노력하고, 배달 음식을 자주 먹는다거나 음주를 즐긴다거나 하지 않는다. 그런데도 왜 몸이 안좋은 지 모르겠다. 일교차 차이일지도 모르겠다. 오늘 현혈을 하러 갔는 데 또 몸이 좋지 못하다고 해서 하지 못했다.
저번에도 실패했는 데 이번에도 실패하다니,, 나 진짜 몸이 좋지 않나 보다.
이런 상황이 지속되다보니 공부도 잘 손에 안잡히고 뭔가를 다 하기 싫어진다,,😓
이러면 안되겠지,, 하 그래도 과제가 있으니 그것만이라도 열심히 해보자!! 화이팅
같이 보면 좋은 블로그
