스토리 매핑: 제시간에 끝내기 위해 계획하라
User Story Mapping
이 글은 Jeff Patton의 User Story Mapping: Discover the Whole Story, Build the Right Product 내용을 번역, 의역 및 재구성한 글입니다.
제품 사업은 증분적(incremental) 사고와 반복적(iterative) 사고가 필요하다.
그림은 어떻게 그릴까?
머리에 완벽한 이미지의 형상이 있어서 이걸 정확한 구획으로 나뉘어 점진적으로 그려나가는 걸까? 어릴 때에는 이러한 방법을 많이 쓰는 경우가 많다. 일단 냅다 머리부터 완성하고 그 다음 몸통을 그리는 것처럼 말이다. 많은 성인들은 이게 거의 불가능하다는 것을 알기에 지금은 하지 않을 것이다. 이러한 방식을 ‘증분적(incremental)’ 방법이라고 부른다.
일반적으로는 먼저 스케치를 하고, 스케치가 완성되면 색칠을 시작한 후, 잘못된 부분이라고 생각하면 덧칠하여 전체적인 모습에 수정을 가하기도 한다. 이러한 것을 ‘반복적(iterative)’ 방법이라 부른다.
제품 사업에 빗대면, ‘어떤 것을 만들어야겠다.’라는 목표를 하고, 기초적인 기능을 가진 프로토타입을 만들고 여러 기능을 검증해나가면서 기존 기능을 고도화시키기도 하며, 기존 기능에 시너지를 더하기 위해 기능을 추가하기도 한다.
즉, 제품에서는 ‘이미 만들어진 것에 대해 평가하는 것’에 반복적 사고가 필요하며, 새로운 것을 만드는 데에 ‘증분적 사고’가 필요하다.
개발 조직은 부분 부분을 단계적으로 만들기 위해 계획한다.
효과적으로 개발하기 위해서는 어떤 기반이 필요한지 파악하고, 그 기반을 쌓고 위에 의도하려던 기능을 차곡차곡 넓혀나가는 과정이 필요하다. 그렇기 때문에 많은 제품 조직들은 이러한 기술적 제반사항으로 인해 실질적 개발의 첫 단계를 전체 기능을 관통하는 전반적인 구조를 만드는 것으로 시작한다.
개발의 첫 단계: 동작 확인하기(See it work)
이 첫 단계를 흔히 ‘*기능적 워킹 스켈레톤(functional walking skeleton)’이라고 부른다. 시스템적으로 제품의 전체 흐름을 사용할 수 있도록 엔드-투-엔드(end-to-end) 동작을 구현하여, 가장 기초적인 수준으로 만들어진 상태를 의미한다. 즉, ‘작동이 되긴 하는지(see it work)’를 확인하기 위해서다.
*기능적 워킹 스켈레톤(functional walking skeleton)은 스틸 스레드(steel thread), 트레이서 불릿(tracer bullet)이라고도 부른다.
개발의 두 번째 단계: 개선하기(Make it better)
제품의 첫 개발 단계의 부분을 작동의 여부를 위해 만들었다면, 그 다음은 기초만 만들어져 있는 제품을 더 낫게 만드는 작업인 정교화 작업을 수행하게 된다. 동작 확인을 위한 개발 단계에서는 정말 기초적인 수준인 기능만 구현되어있기 때문에, 부족한 부분 혹은 더 나은 방향으로 만드는 작업이 필요하다.
더 나은 방향으로 만드는 방법은 두 가지가 존재한다. 첫 번째로, 사전에 스토리매핑을 하면서 이미 계획해두었던 기능적 추가다. 좀 더 고도화가 필요하거나 우선순위가 살짝 밀렸었던 기능들을 구현하는 것이다.
두 번째는 ‘예측할 수 없다고 예측할 수 있는 것(predictably unpredictables)’ 혹은 ‘알 수가 없는 알 수 없는 것들(unknown unknowns)들에 대한 개선이다. 실제로 시스템을 개발했을 때, 의도된 대로 작동하지 않거나, 미처 생각하지 못했던 부분들이 발견되곤 한다. 아이러니하겠지만, 사전에 미리 포착하고 경험을 기반으로 어느 정도 대비는 할수야 있겠지만, 실제 개발물이 계획대로 완전하게 작동하는 경우는 드물다.
개발의 세 번째 단계: 출시 가능한 상태로 만들기 (Make it releasable)
앞의 두 단계에서 명심해야할 것은, 앞의 두 단계는 ‘출시 가능한 상태’가 아니란 점이다. 저 두 단계는 팀이 개발의 상태를 알기 위한 조직적 마일스톤이지, 제품의 상태가 아니다. 앞의 두 단계의 수준에서 사용자에게 배포해버리는 것은 욕 먹기 위해 배포하는 것과 다름 없다.
사용자에게 실질적인 배포를 하기 위해서는 앞선 단계와 다른 관점과 기준을 세워, 사용자의 맥락에서 완전한 작업 수행이 될 수 있는 제품인지 최종적으로 확신할 수 있는 개발 마무리 과정이 필요하다.
제품 세계에서 가장 많이 쓰는 모순어법: 정확한 추정(accurate estimate)
정확히 계산할 수 있다면, ‘추정(estimate)’이라는 단어는 왜 있을까? 다시 말해, ‘추정(estimate)’과 ‘측정(measurement)’의 차이는 뭘까?
‘추정’은 보통 정확한 정보나 계산이 정확히 계산할 수 없고 불확실성을 많이 내포하는 개념이다. 그렇기 때문에 ‘추정’에서는 경험, 직관, 불완전한 데이터를 기반으로 어림잡게 될 수 밖에 없으며, ‘측정’과 같이 계산적인 형태로 나오기 위해서는 많은 시간과 비용이 소요된다.
‘측정’은 객관적이고 정략적인 방법을 사용하여 확립된 기준으로 정확하게 평가하는 것을 의미한다. 사물의 길이나 크기를 재듯이 이견이 존재하기 어려운 계산을 의미한다. 그렇기 때문에 측정 결과는 정확하고 신뢰할 수 있는 데이터가 존재해야 가능한 것이다.
새로운 것을 만드는 제품 조직, 특히 데이터가 부족한 초기 단계의 스타트업은 추정에 의존할 수 밖에 없다. 그렇기 때문에 제품 개발 과정의 효율화를 위해 소요되는 시간의 ‘측정’을 위해서는 수많은 추정에 기반한 실행을 수반할 수밖에 없다. 그렇기 때문에 제품을 만드는 초기 단계에서는 직관과 논리에 근거하며 빠르게 계획하고, 많이 실행하는 것이 오히려 효율화에 더 빨리 다가갈 수 있는 방법이 된다.
개발 리스크 줄이기 1: 소요 시간 추정값을 조직의 예산으로 여겨라
추정이 부정확하다고 해서 무작정 무한한 시간을 보낼 수는 없다. 특히 돈과 시간이 부족한 스타트업에게 소요 시간의 확장은 치명적이다. 그렇기 때문에 논리와 직관으로 가장 합리적인 개발 소요 시간 추정값을 도출하되, 이 추정값이 정해진 예산 안에서 실행가능한 것인지를 기준으로 잡는 것이 큰 도움이 될 수 있다.
단, 다시 ‘정확한 추정’을 찾기 위해 주객전도 되는 상황은 막아야한다. 주어진 시간 안에서 가장 합리적인 방법으로 제품의 사업성을 검증하고 고도화할 수 있는 방법을 찾는 것이 우리의 목적이다.
개발 리스크 줄이기 2: 리스크를 시각화하기
스토리맵의 각 스토리에서 개발적으로 리스크를 지닌 부분에 대해 시각화 하는 것도 좋은 방법이다. 각 스토리맵에 새로운 색상의 포스트잇을 붙여 작업 시에 고려해야 할 점을 상기시하며 업무를 진행하는 것이다. 더 나아가, ‘리스크 번다운 차트(risk burndown chart)’를 만들어 제품의 안정성을 좀 더 염두해두는 것도 좋은 방법이다.
