2017. 3. 24. 07:50ㆍpxd talks
작년 11월 17일, 69회 pxd talk가 User Story라는 주제를 가지고 워크숍 형태로 진행이 되었습니다.
장장 4시간 동안, Agile Consulting(애자일컨설팅)의 대표이신 김창준 님을 모시고 User Story는 무엇이며, 어떻게 실제 업무 상황에 접목하여 활용할 수 있을지에 관해서 토론과 간단한 실습 통해 pxd talk를 진행하였습니다.
강의 시작은 4명이 한 개의 조가 되어 실제 업무 상황에서 고객사의 요구사항을 정의하는 과정에 발생했던 불편했던, 어려웠던 혹은 짜증 났었던 실질적인 상황들을 5개 이상 적어보고, 그중 지금 당장 꼭 해결하고 싶은 문제 한 가지를 선택하여 김창준 님께서 그 문제를 어떻게 해결하는 것이 좋을지 방향성을 제시해주는 방식으로 강의가 진행되었습니다.
아래는 각 조에서 제시한 고객사와 종종 발생되는 문제 사항들에 대한 내용입니다.
고객사와 발생되는 문제점은 무엇이 있는가?
[1조]
“고객사에서 이미 솔루션을 만들어 놓은 상태에서, 사용자가 어떤 문제가 발생했을 때 해당 솔루션을 필요로 할지 찾아달라고 하는 경우가 있다. 다시 말해, 현재 사용자에게 문제가 없는데 문제를 찾아달라는 것이다.”
[2조]
“고객사의 요구사항을 실질적으로 우리에게 전달해주는 고객 본인이 요구사항에 대한 이해 없이 전달되어, 결국 프로젝트 중간에 문제가 발생되는 경우가 있다. 고객 본인이 무엇을 원하는지 모르는 상황에서 요구사항을 요청하는 경우이다.”
[3조]
“고객과 프로젝트 업무 범위 및 방향성에 대해서 논의한 담당자와 그 업무를 진행하는 실무자가 달라 고객이 요청한 요구사항이 명확하게 전달되지 않는 경우가 있다. 결국, 프로젝트에 대한 Goal이 고객과 실무자 간 싱크가 맞지 않는 경우이다.”
[고객 --> 영업담당자 --> (실무자 <--> 고객)]
[4조]
“고객에게 전달받을 요구사항을 가지고 몇 가지 컨셉 혹은 방향성에 대해서 제안을 했을 경우 결정을 회피한다거나, 결정했던 내용을 중간에 다시 변경하거나 번복하는 상황들이 발생한다. 그리고 고객사 측에서 결정해줘야 하는 서비스 정책 같은 부분들도 결정하지 못하고 결정을 우리에게 요청하는 경우도 있다.”
이렇게 각 조에서 고객사와 프로젝트를 진행하면서 발생했던 문제들 중 다수결 의견을 통해 2조에서 이야기한 문제 상황에 대해서 김창준 님의 의견을 통해 좀 더 심도있게 논의해 보기로 하였습니다.
어떻게 하면 이 문제를 해결할 수 있을까?
‘고객이 정확하게 무엇을 원하는지 모르면서 요구사항을 요청하는 문제’를 문제라고 생각하는 이유는 결국, ‘고객은 무엇이 문제인지, 무엇을 원하는 것인지 알고 있어야 한다는 것’을 우리가 전제로 생각하고 있기 때문이다.
여기서 우리는 이러한 전제가 옳은 것일지를 다시 한번 생각해보는 것이 중요하다.
애자일 방법론에서는 이러한 관점을 옳다고 보지 않는다. 고객 본인들이 정확하게 무엇을 원하는지 모르는 상태에서 우리에게 요구하는 것이 정상에 가깝다고 보기 때문이다. 따라서, 우리는 고객들이 무엇을 원하는지도 모르는 것을 가지고 불평을 하기보다는, 고객 본인이 원하는 것이 무엇인지 잘 모르는 경우, 우리는 어떻게 해야 할지를 고민하는 것이 더 좋은 전략이라고 생각한다.
고객이 무엇을 원하는지 정확하게 알려면 아래와 같은 단계가 필요할 것이다.
원하는 것에 대해서 정확하게 생각하기 -> 정확하게 원하는 것을 전달하기 -> 그것을 정확하게 이해하기 -> 결과물을 제시
이때 정확하게 요구사항을 이해하고 결과물을 제시했음에도 불구하고, 고객이 필요로 했던 것과 원하는 것이 일치하지 않아 문제가 발생할 수도 있다. 하지만 이렇게 일치하지 않는 것도 일반적이라고 볼 수 있다.
이와 같이, 고객이 무엇을 원하는지 정확하게 알기 위해서는 많은 단계가 거쳐야 하기 때문에 결국 정확하게 알 수 없는 문제가 발생할 수 있는 가능성이 높은 것이다.
이런 경우, 우리는 어떻게 해야 할 것인가를 고민해 볼 필요가 있다.
예를 들어 행동심리학에서 수술 만족도에 대한 연구한 결과 수술 전반에 대한 만족도는 수술 말미의 경험이 좌우한다는 것을 알 수 있었다.
+ 시작과 진행 과정이 좋아도 마무리가 나쁜 경우 -> 나쁘다
+ 시작과 진행 과정이 별로였지만 결과가 좋은 경우 -> 좋다
따라서 우리는 고객에게 결과물을 제공했을 때 그 당시 만족을 하였는지, 또는 그 후에 결과물을 적용하여 비즈니스 결과에 대해서 만족을 하였는지 알 수 있어야 한다. 다시 말해, 현재 고객은 A라는 결과물을 원하지만, 3개월 후 A라는 결과물을 제시했을 때 고객이 만족해하지 않을 것이 예상될 경우에는 의도적으로 고객의 현재 요구사항을 만족시키기 보다는 3개월 후의 상황에 투자하는 것이 고객과의 비즈니스 관계를 오래 유지시킬 수 있는 방법이라고 생각한다.
만약 고객이 원하는 A라는 결과물을 제공하였지만, 몇 개월 후 그 결과물로 긍정적인 비즈니스 결과를 얻지 못한다면 고객과 비즈니스 관계를 오래 지속하는 것이 어려워질 것이다. 단, 고객을 어떻게 설득시켜 나갈 것인가는 고민이 되어야 한다.
이런 상황에서는 고객이 원하는 것을 제공해주면서, 그 고객이 미처 깨닫지 못하고 있지 부분에 대해서 깨우칠 수 있도록 유도하는 것이 필요하다. 쉽게 말해서 설득의 과정을 거쳐야 한다. 고객이 현재 결과물에 대해서 판단하는 초점을 몇 개월 후 혹은 몇 년 후 이 제품이 사회에서 인정받을 수 있을 것인가를 고민하는 쪽으로 초점을 변화시켜주어야 한다는 것이다.
이러한 것을 User Story와 애자일 방식을 통해 어느 정도 해결하는 데 도움이 될 수 있다.
먼저 User Story를 사용하면 고객이 요구한 것에 대해서 고객이 빠른 시일 내에 확인하고 학습할 수 있는 방향으로 요구사항들을 정리할 수 있다. 그리고 프로젝트 기간을 여러 개의 마디로 쪼갠 후 각 마디마다 고객이 가지고 있었던 가설 혹은 가정을 검증해서 가지고 있던 가설이 틀렸다는 것을 깨우치게 해주거나, 또는 확인시켜 주는 것이다.
이러한 것을 반복하다 보면 고객들은 단계별로 제시되는 결과를 확인하고 신뢰가 쌓이면서 자신들이 가지고 있던 생각의 틀을 깨고, 점점 더 원하는 것이 무엇인지 정확하게 알 수 있는 상태가 되어갈 수 있을 것이다.
User Story란 무엇인가?
먼저 User Story가 무엇인지 이해하려면 사용자(User)와 이야기(Story)에 대한 의미를 알아야 한다.
“User Story란, 사용자의 요구사항을 정의하고 그것을 관리해 나아가는 방법이다.”
여기서 사용자(User)는 End User 또는 Stakeholder와 같이 우리가 만들려고 하는 시스템을 원활하게 잘 돌아갈 수 있도록 참여하는 사람들을 의미한다. 이야기(Story)는 어떤 종류의 메시지를 왜곡되지 않고 잊어먹지 않게 잘 전달해야 한다는 것을 의미한다. 그리고 Story의 특징은 정해진 틀이 없고 허술하기 때문에 무언가에 관해서 이야기하는 것이 쉬우며, ‘더 이야기를 나누어라’라는 뜻을 내포하고 있기도 하다.
결국, User Story는 고객과의 커뮤니케이션 증가를 위한 것이라고 할 수 있다.
User Story는 보통 3”x5” 크기의 인덱스카드에 작성하여, 고객과 이야기를 하기 위한 일종의 토큰으로 활용된다. 그리고 작은 카드에 모든 요구사항을 다 적을 수 없기 때문에 더욱더 고객과의 커뮤니케이션이 증가할 수밖에 없는 것이다.
User Story를 작성하는 형식은 아래와 같다.
“As a <role>
User Story를 작성하는 경우 모든 요구조건을 작성하지 않는다. 우리가 만들려고 하는 시스템의 에센스만 추출하여 User Story를 만들어야 한다. 그리고 그것을 기반으로 만들어낸 산출물을 통해 피드백을 받고 추가하면서 점점 더 User Story를 늘려나가야 한다.
예를 들어 홈 오토메이션 시스템을 만든다고 가정하였을 경우 아래 이미지와 같이 홈 오토메이션이라면 꼭 가능해야 되는 에센스를 Activity 순으로 User Journey 또는 Path를 작성한다. 그리고 각 Activity 단계별로 여러 가지 Validation을 작성한 후 End to End가 가능하도록 Full path를 선택하여 이 Story에 대한 산출물을 구현하고, 피드백을 받을 수 있어야 한다. 만든다. 이러한 과정의 Iteration(반복)을 통해 고객은 어떠한 가치를 얻을 수 있을 것이며, 우리 자신도 빠르게 학습할 수 있게 될 것이다.
이는 그림을 그리는 것 혹은 엄마 뱃속에서 아이가 만들어져 가는 과정과 유사하다고 볼 수 있다.
부분을 완성해가며 전체를 완성하는 것이 아니라, Transformation(변형)과 Differentiation(갈래치기)을 통해 전체를 다듬어 나아가면서 점점 완성해 나가는 것과 유사하다. 그리고 이것은 복잡하고 모호한 것을 만들어 내야 할 때 매우 효과적이다. 만약 복잡한 것을 만들어야 할 때 부분부터 완성해 나간다면, 완성되었을 때 심각한 오류가 발생할 수 있다.
그리고 첫 번째 Iteration은 우리가 만들려고 하는 시스템을 사용하는 어떤 사용자든 사용할 것이라고 생각하는 가장 간단한 또는 논의할 필요도 없을 정도로 Common한 하나의 Full Path를 먼저 선정하여 모델링을 시작해야 한다.
하지만 이러한 과정을 모든 고객사와 함께 진행하는 것은 대부분 불가능할 것이다. 따라서 고객사와 함께 이러한 단계를 진행할 수 없더라도 내부적/자체적으로는 진행하여 우리 스스로가 학습을 통해 점점 더 똑똑해져야 한다.
실습을 통해 User Story 익히기
실습은 [뽀모도로 타이머 앱 UI설계]를 주제로 하여 아래와 같이 각 조별로 뽀모도로 타이머 앱을 사용하는 Activity 단계 및 단계별 Validation을 작성한 후 End to End가 가능하도록 Full Path를 선정하여 앱 UI를 설계해보는 과정을 진행하였다.
이 과정을 진행할 때 하나의 Iteration이 끝날 때마다 우리 스스로가 우리가 만든 것을 보고 이 제품의 핵심이 무엇인지 자문을 해봐야 한다.
뽀모도로 타이머는 알람 울리는 것이 중요한 것이 아니다. 뽀모도로 타이머는 이것을 사용하는 사람들이 집중해서 일하기 위해 사용하는 것이다. 따라서 시간을 설정하는 것보다 중요한 것은 얼마나 집중했었는지를 아는 것이 더 중요한 것일 수 있으며, 이러한 자문을 통해 서비스의 기본적인 기능들이 달라질 수도 있는 것이다. 그리고 이러한 과정을 거치면서 재미있는 부분은, 이야기를 통해 서로가 다르게 생각했었던 부분들이 표면적으로 드러나고, 점점 더 서로가 공통적인 기반을 마련해 나아갈 수 있다는 것이다.
강의에 대한 마무리 소감 및 질의응답
[pxd_1]
“과거 경험상 일반적으로는 어떤 서비스를 만들 때 클라이언트로부터 이미 만들어진 Feature list를 전달받아 프로젝트를 진행하다 보니, 위 과정을 모두 뛰어넘은 느낌이었는데, User Story는 무언가를 꺼내놓고 클라이언트와 보면서 이야기할 수 있는 장치가 될 수 있는 것 같아 의미 있는 것 같았어요.”
[pxd_2]
“실습과정에서 첫 번째 Iteration을 통해 산출물을 만들고 그다음 Iteration은 어떤 기준을 가지고 Validation을 선택하여 다음 Iteration을 진행해야 할지 쉽게 판단이 서질 않아 어려웠다.”
[김창준]
“첫 번째 Iteration을 거친 후 나온 산출물에 대한 피드백이 그다음 Iteration을 위한 Seed가 될 것이다. 그리고 이러한 Iteration 과정을 3번 정도 진행한 후 우리는 우리의 생각이 틀렸었다는 충격을 받아야 한다. 또는 어떻게 하면 지금 우리가 일하고 있는 방식(상황에 제약은 있겠지만)에 약간의 변화를 주어, 산출물이 나왔을 때 우리가 그것을 보고 서프라이즈를 경험할 수 있을까? 에 대한 고민도 해볼 필요가 있다. 왜냐하면, 서프라이즈를 경험하지 않고서는 현재보다 더 나아질 수 없을 것이기 때문이다.”
[pxd_3]
“우리의 업무 프로세스 중 전략 단계에서 도출된 소스들을 가지고 User Story를 만들 수 있을 것 같지만, 그것들을 어떻게 Iteration 해볼 수 있는가에 대해서는 한계점이 있는 것 같았다. 그것을 검증해 나가기 위해서는 우리에게 새로운 시도나 변화가 필요할 것으로 생각이 들었다.”
[pxd_4]
“Activity를 잘 도출하려면 어떻게 해야 하는가?”
[김창준]
“기본적으로 애자일은 처음부터 정답을 맞추기 위해 노력하기보다는 어떻게 하면 점점 더 정확성을 높일 수 있을 것인가로 생각을 변화시켜야 한다. 따라서 엉성하게 시작해서 중간중간 진행 과정을 통해 빠진 부분들을 찾아내면서 추가해 나아가면 된다. 처음부터 완벽한 Activity를 도출하려고 노력하지 말아라.”
[pxd_5]
“Iteration 단계를 언제까지 진행해야 되는 것인가?”
[김창준]
“원칙적으로 Iteration 단계는 프로젝트가 시작했을 때부터 끝날 때 까지 진행해야 된다. 하지만 현실적으로 불가능하다면, 최소한 프로젝트 시작 후 몇 주 혹은 몇 개월 동안만이라도 상황에 맞춰 변형해서 진행하는 것을 권장한다.”
마지막으로
User Story라는 방법은 꼭 클라이언트와의 프로젝트를 진행하며 산출물을 만드는 경우에만 활용이 가능한 것이 아니라, 개인적인 레벨에서도 얼마든지 활용 가능하다는 것을 알 수 있었습니다.
예를 들자면 공지 메일 쓰기, 프로젝트 일정 작성, 발표자료 작성 등 다양한 상황에 적용할 수 있다는 것입니다. 발표자료를 만드는 경우 각 장표마다 내가 전달하고자 하는 핵심 단어를 작성하고, 그것을 문장이나 Phrase로 성장시키며, 몇 번의 Iteration을 거쳐 완성을 해나간다면 전체적으로 일관성을 가진 잘 구성된 발표자료를 만들 수 있게 될 것입니다.
결론은 복잡한 무언가를 만들기 전에 전체를 단순화시킨 어설픈 상태부터 시작하여 거기에 조금씩 살을 붙이고 분화시켜 만들어 나아가면서 완성시키는 일련의 행위를 몸에 배는 것이 중요하다는 것입니다. User Story는 몸에 배게 되면 생각보다 다양한 상황에서 활용이 가능해질 것입니다.