이번주는 뭔가 학습일지가 쓸 게 많은 것 같다.
린캔버스, 애자일방법론부터 A/B테스트랑 데이터 분석 지표/도구들까지...
공부해야할 게 너무나 많다...이직 할 수 있을까...😂
칸반(Kanban)
도요타 생산 시스템의 핵심인 칸반에서 이름을 따왔다고 한다.
전 단계의 작업을 계속 수행하여 다음 단계로 밀어 넘기는 (Push) 방식과 다르게, 칸반에서는 특정단계의 작업이 완료되었을때, 전 단계의 작업 수행을 지시하여 끌어 당기는 (Pull) 방식으로 진행하는 소프트웨어 개발 방법론이다.
칸반의 실천방법
1. 시각화 : 칸반보드는 시작점과 끝지점이 열로 나뉘어져 왼쪽부터 오른쪽으로 흘러가도록 구성되어 있다.
카드는 작업단위를 나타내고 유저 스토리, 테스크 등으로 이뤄진다.
2. WIP(Work In Process) 제한 : 칸반보드에서 하나의 열에 WIP제한 기준만큼의 카드가 있을 경우, 다음 단계로 보내기 전까지 새로운 카드를 당겨올 수 없다. Push방식이 아닌 Pull 방식으로 일이 진행되기 때문이다.
3. 흐름을 관리 : Done상태의 카드가 최대한 빠르게 많이 생성될 수 있도록 업무 흐름을 관리하는 것이 중요하다.
4. 정책 명시화 : 모든 구성원이 동일한 방식으로 일하는 것이 중요하다. 다만 정책은 토론을 통해 언제든 변경될 수 있다.
5. 피드백 루프 : 7가지 리뷰 (전략, 운영, 위험, 서비스제공, 재보충, 칸반, 제공계획) - 주기적인 리뷰 세션을 통해 더 나은 방향으로 개선한다.
6. 함께 개선하고 실험을 통해 발전 : 규범에 얽매이지 않고 조직의 상황에 적응하며 발전해 나간다.
칸반의 장단점
장점- 규범이 많지 않음 > 스타트업같은 조직에 도입하기 용이하다.
- 스프린트와 같은 데드라인은 없으나 속도에 대한 압박은 존재한다.
- 다양한 미팅으로 인한 시간 리소스 낭비를 막을 수 있다.
- 병목지점이 어디인지 명확하게 파악이 가능하다.
- 저품질 상태의 배포가 최소화 된다.
단점
- 규범이 없기 때문에 이는 곧 무규범상태가 될 수 있다.
- 압박감이 덜하여 자발적 실천 문화가 약하거나 긴장감이 떨어져 전체적인 생산량이 저하될 수 있다.
스크럼과의 차이점
- 역할을 지정하지 않는다.
- 이터레이션(스프린트)이 진행되지 않는다.
- WIP제한 > 일의 속도를 조절할 수 있다.
- 스프린트 백로그 변경에 용이하다.
- 보드 초기화 여부 > 지속적으로 보드가 유지된다.
A/B Test
A/B테스트란 임의로 나눠진 두 집단에게 서로 다른 UI/UX 등을 제시하고, 두 집단 중 어떤 집단이 더 높은 성과를 보이는지 정량적으로 평가하는 방식이다. 대부분의 IT기업에서 데이터 기반 의사 결정의 도구로 활용하고 있다.
A/B 테스트 진행 프로세스
- 목표 설정 - 실험 전체의 방향을 결정하는 중요한 프로세스이다.
목표를 구체화 해야하며, 명확한 목표가 있어야만 유의미한 지표 선정, 가설 설정이 가능해진다. 지표를 설정할 때 분모와 분자를 명확히 설정해야한다. - 가설 수립 - 가장 중요한 단계
가설을 기반으로 어떻게 실험을 진행할지, 무엇을 학습할지가 결정되므로 신중하게 가설을 설정해야한다.
> 가설이 목표와 얼라인 되는지 반드시 확인할 것
> 모든 A/B 테스트를 진행할 때마다 반드시 가설과 검증을 통한 결과를 기록해둬야한다. - 실험 설계
- 지표 설정
- 타겟 유저 - 어떤 유저를 대상으로 실험을 할 것인가?
- 실험군의 모수 설정 : 대조군 > 기존 상태 그대로인 기능
실험군 > 새로운 기능 / 개선된 기능 - Sample Size : 많으면 많을수록 신뢰도가 높아진다. 하지만 리소스는 항상 적기 때문에 각 베리에이션별로
적정 샘플 사이즈를 둬야한다.
- 실험군의 모수 설정 : 대조군 > 기존 상태 그대로인 기능
- Unit of Diversion (어떻게 나눌 것인가?) > 분기 단위
> A,B가 온전히 랜덤이어야(특성을 갖고 있지 않아야) 두 그룹의 차이점이 실험에 의한 변화라고 확신할 수 있다.
> 가장 많이 사용되는 단위로는 ID(DB의 유저들의 고유값으로 안정성이 높음)
> Event 당 분류 - 유저가 특정 행동을 했을 때 무작위로 A/B의 결과를 보여준다. but 서비스의 일관성이 떨어지기 때문에 눈치채지 못할 변화에만 사용한다. - Unit of Analysis > 분석 단위 - A/B 테스트를 통해 영향을 주고자 하는 최소 단위 - 지표의 분모가 된다.
ARPU (총 구매액 / 회원 수) Average, Revenue Per User 유저 한명 당 평균 수익(매출)
> 분기 단위와 분석단위를 일치시켜야함! - Duration (기간) : 특별한 기간이 아닐 때 실험이 진행되어야 함
- Variation 설정 : A/B 둘의 차이가 너무 복합적/복잡하면 결과 해석이 어려우며 최대한 실험 단위를 쪼개서 진행해야 한다.
- 실험 진행 : 테스트의 분기가 제대로 이뤄지고 있는지 파악해야한다. 기간이 너무 짧을 경우엔 유의미한 결과값이 나오지 못한다.
- 결과 분석 : 통계적 유의성 확인 > P value 계산 > 0.05보다 낮을 경우 의미있음.
불변지표 확인 > 실험과정에서 변하면 안되는 변수
| 합계 지표 (Sum) | 전체 값을 더한 지표. 비율을 알 수 없어서 잘 사용하지 않는다. |
| 평균 / 중앙값 (Mean, Median) |
말 그대로 두 값의 평균값이다. > 가장 자주 쓰이는 평균의 함정에 빠지지 않도록 주의한다. > Median, mode(최빈값) 등을 확인하여 아웃라이어 존재 여부 파악이 중요하다. |
| 비율 지표(0~1) | ex) 결제완료 횟수 / 결제페이지 진입 횟수 > 가장 많이 사용된다. |
A/B 테스트 시 주의해야 할 사항
1. A/B 테스트는 최적화 도구일 뿐 큰 그림을 보여주지는 못한다.
> 산을 잘 올라가고 있는지 말해주지만 어느 산에 올라가야 하는 지 말해주지 못한다.
2. 대부분의 가설은 틀린다는 것을 명심해야 한다.
> 잘못된 가설이었다는 것에 두려움을 갖는다면, 올바른 자료 해석이 불가능하다.
실험을 통해 잘못된 가설이었다는 것을 증명하는 것도 매우 큰 성과이므로 두려움 없이 결과를 직면해야한다.
3. 실험을 너무 빨리 끝내면 안된다.
> 통계적 유의미성이 낮은 상황에서 실험을 조기종료하면 정확하지 않은 결과값을 얻을 수 밖에 없다.
4. 너무 많은 변인을 한꺼번에 테스트하면 안된다.
> 한번에 여러가지 테스트를 진행하고자 욕심을 부릴 경우, 정작 실험 결과에 영향을 미친 핵심 변인이 무엇인지 해석할 수 없게된다.
매우매우 중요한 걸 배운 느낌이다. LMS과제도 A/B테스트 조사를 하는 것이기도 하고, 다른 모든 PM관련 책에서 무조건 나오는 내용이며 실무에서도 중요한 것 중 하나인 걸로 알고 있어서 집중해서 공부한 것 같다.
아직 LMS 못했는데 하기 전에 학습일지 쓰면서 한 번 더 공부한 것 같아서 바로 LMS 과제하면 될 듯!
'PM학습일지' 카테고리의 다른 글
| [제로베이스 PM스쿨 19기] 학습일지 Day 10 (0) | 2023.10.26 |
|---|---|
| [제로베이스 PM스쿨 19기] 학습일지 Day 9 (2) | 2023.10.24 |
| [제로베이스 PM스쿨 19기] 학습일지 Day 7 (0) | 2023.10.20 |
| [제로베이스 PM스쿨 19기] 학습일지 Day 6 (0) | 2023.10.18 |
| [제로베이스 PM스쿨 19기] 학습일지 Day 5 (0) | 2023.10.16 |