[Lean] 린 기획 문서 작성법
린 개발 환경에서 과제 문서는 어떻게 작성해야할까?
백그라운드
린 스타트업, 린 분석, 린 UX.. "Lean" 방법론은 불확실한 환경에서 빠르고 성공적인 제품 개발을 위한 지침서로 널리 유행하고 있다. 실리콘밸리 뿐만아니라 국내에서도 스타트업부터 대기업을 막론하고 "Lean하게 가자!"라고 외치지 않는 곳을 찾아보기가 어려운 상황이다.
어설프게나마 Lean에 대해 이해하고 가설, 지표기반으로 과제를 수행해왔지만, 최근에 린한 개발환경에서 본격적으로 업무하게 되면서 아래와 같은 의문이 들었다.
"가설-실험-분석, MVP 등 린의 중요한 철학들과 프로세스는 대략 이해하겠는데, Lean하게 진행해야하는 과제 기획은 어떻게 문서화해야하는가?"
Lean 환경에서 과제 정의서 / 제안서는 어떻게..마침 사내에 Reference도 없고 해서 직접 Lean한 환경에서의 과제진행시에 적용해 볼만한 가이드/탬플릿을 찾아보았고 Customize를 거치며 실제 업무에 적용해보고 있다.
먼저, High level Proposal 문서
Lean과 관련된 가이드, 탬플릿을 찾다보면 가장 우선적으로 나오는 것은 "Running Lean" 책에서 다루고 있는 Lean Canvas이다. (최근 몇년동안 유행을 탔던 Business Model Canvas에 Lean을 응용한 버전이다.)
Lean CanvasBusiness Model Canvas의 장점을 그대로 이어받았기 때문에, 진행 하고자하는 제품/서비스에 대해 한장의 표로 설득력있게 구성할 수 있다.
하지만 아래와 같은 이유로 때로는 유용하지 않다.
1) Level: New Product를 하거나 전혀 새로운 신규사업을 진행할때 High Level의 컨셉을 설명하기에 적합하나, 실제로 과제단위로 What과 How를 간단히 정의하기에는 항목이 그다지 맞지 않다.
2) 가설과 실험에 대한 얘기는 전혀 없다. Concept Proposal에 가깝고, 실제 과제기획서/Charter에는 적합하지 않다.
3) 경쟁우위, 비용구조, 채널 등 (대체로) 무의미하게 느껴지는 항목들까지 억지로 채워넣어야 할 것만 같다.
여튼 상황에 따라 잘 활용하면 되며, 책에서 비교적 잘 설명하고 있으니 부가 설명은 따로 없어도 될 것 같다.
참고로 Value Proposition만을 강조한 "Value Proposition Canvas"란 것도 있다. 정말 Canvas가 유행인것인지.
Lean 실험 설계를 위한 가이드
만일 불확실성이 높지 않고 해야 할 일이 명확한 과제라면, 굳이 Lean의 방법론을 따르거나 "실험"이라는 지향점을 가지지 않아도 된다. 그냥 기존 기획서대로 쓰고, "문제", "솔루션", "KPI", "MVP"등을 잘 제시하면 될것이다.
하지만, 아래와 같은 성격을 지난 과제라면 "실험 설계"라는 컨셉으로 과제를 정의할 필요가 있다.
1. 고객 반응에 대해 지표기반으로 Validation을 체크하고, Go / No-go 의사결정을 하거나 Pivoting을 할 수 있는 과제
2. 모든면에서 불확실성이 높아 의사결정 Frame을 만들고 실험해야하는 신규 서비스/상품
3. 빠르게 최소화하여 검증해보고 싶은 과제
이러한 성격의 과제들을 Lean 방법론에 따라 정의한다는 것은, Face와 논리로 무장해서 Why-What을 뽑아내는 기획서라기보다는 "실험설계서"라는 표현이 더 적합할 것 같다.
이러한 니즈를 충족시켜 줄만한 세 개의 레퍼런스를 찾았고 Customize하여 업무에 적용하고 있다.
1) HOW TO IMPLEMENT HYPOTHESIS-DRIVEN DEVELOPMENT
(가설 기반의 제품 개발을 실행하는 방법)
https://barryoreilly.com/2013/10/21/how-to-implement-hypothesis-driven-development/Lean의 핵심인 "가설"을 어떻게 세워야하는지를 잘 설명하고 있다.
2) The Lean Analytics Cycle: Metrics > Hypothesis > Experiment > Act
(린분석의 사이클: 지표설정 > 가설 > 실험 > 행동)
실제 위 도식을 보면 목표로 하는 KPI를 정하고, 가설을 세우고 실험하는 Lean의 Flow에 따라 과제정의를 어떻게 해야하는지 흐름을 따라 한눈에 파악해볼 수 있다.
3) Introducing the Rapid Experiment Map(빠른 실험 맵)
세로축을 보면 Lean Cycle에 따라 정의해야할 항목들이 잘 정리되어있다. 그리고 이를 Print하고 함께 볼 수 있도록 탬플릿으로 만들어놓았다.
4) 개인적으로 쓰고 있는 탬플릿
위 레퍼런스와 담당 서비스의 속성을 고려하여 개인적으로는 아래와 같은 구성으로 1Page 과제정의서를 만들어 업무를 진행하고 있다. 아래 내용을 통해 과제의 목적과 해야할일을 어느정도 명확하게 그려볼 수 있다.
<실험의 정의>
1. Customer Value Proposition: 어느 타겟 유저에게 어떤 가치가 있는 것인가?(Target User / Offering / Jobs to be done)
2. Profit Formula: 해당 과제의 수익모델은 무엇인가?
3. 가설: 누가 어떻게 행동해서 어떤 결과를 얻는다고 믿고 있는가?
4. Target KPI: 어떤 KPI로 측정하는가?
5. 성공기준: 실험 측정 후 성공 기준은 무엇인가?
6. Decision: 측정 결과를 통해 어떤 action을 취할 것인가?
<실행 방안>
7.MVP Development: 실험하는데 필요한 최소한의 Feature는?
8.고려사항: 과제 진행시 사용자에게 부정적인 영향은 어떤 것이 있을까? 진행시 고려하여 하는 이슈는 무엇인지?
그 외 탬플릿들
Experiment Report라는 이름의 탬플릿. 비교적 간단하다.
https://leanstack.com/experiment-report/
http://leanstack.com/wp-content/uploads/2012/09/Screen-Shot-2012-09-11-at-4.42.16-PM.png
Validation Board: 실험과제의 진행상황을 칸반 형식의 보드와 포스트잇으로 가시화할때 유용할 것 같다.
https://www.leanstartupmachine.com/validationboard/
"구슬이 서말이라도 꿰어야 보배"라고, 아무리 좋은 가이드가 있어도 실전 적용이 중요하겠다. 회사의 개발방법론, 문서화 및 커뮤니케이션 방식 등에 따라 내재화되는 형태는 모두 다를 것이다. 그럼에도 불구하고 Lean하게 과제를 진행하고 싶다면, "실험"에 포커스된 새로운 형태의 과제정의서가 필요하다고 생각된다. 이러한 업무 문서도 레퍼런스가 있으면 적용해보고 빠르게 검증해볼 수 있다. Lean하게.
