7장. 애자일팀의 탄생#5

#7-5 P사와의협업(기획자+디자이너)

#7-5 P사와의 협업(기획자+디자이너)

치열한 협상을 거쳐 결국 P사와의 협업이 시작되었다. 협업은 총 4개월 동안 이루어졌다. 당시 실제 솔루션의 새 버전 기획안을 가지고 협업을 수행했다. 협업 후 회사에 전달할 성과 및 영향을 극대화하기 위해서는 결국 실제 제품이어야 한다는 생각에서였다. 

[린스타트업  + 애자일 + 디자인 싱킹] 

당시 수행했던 전체적인 프로세스는 린스타트업 + 디자인 싱킹 + 애자일 방식을 섞은 프로세스이었다. 이 과정이 세명의 역할자인 기획자, 디자이너, 개발자와 함께 엮여 함께 진행되었다. 이 프로세스를 진행하는데, 가장 인상적인 부분은 사용자 검증이었다. 프로젝트를 시작하기 전부터 사용자들과의 인터뷰를 먼저 잡았다. 그리고 적어도 1주일에 2~3명의 사용자를 평균적으로 만났다. 이를 통해 가정(Assumption)을 가장 빠른 시기에 검증하는 형태로 일했다. 

모든 일은 역할자들끼리의 페어로 이루어졌다. 페어 기획, 페어 디자인, 페어 개발을 수행했다. (훗날 이때 배운 것들은 S사의 자산과 어우러져 S사만의 애자일 방식으로 정착된다.) 당시 느낀 점과 배운 것들을 남기기 위해 6명의 멤버들은 매일 각 역할자의 관점에서 일기를 쓰고 회고했다. 이번 절의 내용은 첫 2주는 디자인 단계를 담고 있다. 개발자들이 없이 기획자와 디자이너만으로 디자인 단계를 수행했다. 

첫 2주간 기획자와 디자이너는 퍼소나의 가장 중요한 사용자 시나리오를 찾고 이 내용을 디자인한 뒤 실제 사용자 검증까지를 마치는 것을 수행한다. 그리고 나머지 2주는 개발단계로 개발자들이 투입되고 개발자들이 개발환경을 만들고, 그 검증된 내용을 개발하는 과정을 볼 수 있다. 그동안 기획자와 디자이너는 또 다른 사용자 시나리오에 집중하여 분석하고, 개발자들에게 일을 공급해주는 역할을 한다. 

아래 글에는 '해피 패스' 라는 용어가 많이 나온다. '해피 패스'는 우리가 정한 주요 퍼소나에게 가장 중요한 시나리오를 말한다. 그리고 이 시나리오가 잘 진행됐을때 퍼소나는 행복해 한다는 뜻에서 '해피 패스'라고 부른다. '해피 패스'는 유스케이스 정의서를 기준으로 설명하면, 메인 흐름이다. 부가적인 대안 흐름이나 예외 흐름을 고민하지 않는다. 가장 많은 확률로 선택되는 시나리오를 잡아 그 시나리오에 집중한다. 

일기의 내용이 본래 방대하여, 이 글을 읽는 분들을 위해 편집을 했다. 디자인 단계에는 기획자와 디자이너의 일에 집중하여 쓰고, 개발 단계에는 개발자들이 느끼는 점에 대해 작성했다. 

-------------------------------------------------------------------------------------

* 1주 차 (15년 7월 13일) 인셉션 1/2   

기획자: P사와의 협업 첫날 기획자와 디자이너만 참여하여 인셉션을 수행했다. 인셉션은 이틀에 걸쳐 하루에 8시간씩 총 16시간 동안 수행했는데, 오늘이 바로 첫날이었다. 외부에서 퍼실리테이터 한 명이 함께 참여해 전체 진행을 도왔다.  인셉션은 프로젝트 비전 →  사용자 맵 → 퍼소나 → 사용자 시나리오의 기법 순서대로 시스템을 활용할 가장 중요한 사용자를 찾고 그 사용자에게 가장 중요한 시나리오를 찾아냈다.  우리는 이것을 해피 패스(Happy path)라 불렀다. 해피 패스는 선정한 시나리오에 대해 대안 흐름이나 예외 흐름을 고민하지 않고, 가장 빠르게 검증할 수 있는 시나리오를 선택했다.   

느낀 점: 우리가 개발할 내용에 대해서는 이미 아주 잘 알고 있다고 생각했지만, 프로젝트를 시작하자마자 사용자를 처음부터 만나는 것을 당연시하고 프로젝트 중간에 규칙적으로 수행하려고 하는 점이 달랐다. 어떠한 대화에서건 사용자를 가장 중요한 요소로 보고 일을 진행한다. 제품 기획 시에 보통 5~7회에 걸쳐 사용자를 만난다고 한다. 일단 프로젝트를 시작할 때부터 사용자와 연락하여 힘든 점이 무엇인지 알아내고 프로젝트 중간중간에도 사용자에게 확인을 받아야 한다.   

[UX 린스타트업이라는 로라 클래인에 책에 따르면 통계적으로 볼 때 한 시나리오에 대해 5명 정도의 적합한 사용자를 만나면 95% 정도의 확률로 시나리오에 대한 검증이 가능하다고 한다. ]

[P사의 인셉션]

* 1주 차 (15년 7월 14일) 인셉션 2/2   

기획자: 우리는 목표 설정(Goal & Anti goal) → 이해관계자 맵 → 리스크 도출 등의 기법을 통해 먼저, 프로젝트에 집중해야 할 것과 피해야 할 것을 찾고, 프로젝트와 관련된 어떠한 이해관계자들이 있는지 찾았다. 그리고 토론을 통해 이 프로젝트를 실패하지 않기 위해 누구와 지속적으로 커뮤니케이션해야 하는지 고민했다. 그리고 리스크를 도출하고 이를 해결할 담당자와 방법을 함께 토론했다.   

느낀 점: 첫째 날은 프로젝트를 성공하기 위해 무엇이 필요한 지를 주로 찾는 기법들을 수행했다면, 둘째 날은 실패하지 않으려면 무엇을 놓치면 안 되는지를 고민하는 시간이었다.  금일 수행한 기법들을 통해 사용자에게만 초점을 맞추지 않고 비즈니스 이해 관계자의 성공 또한 균형적으로 초점을 맞출 수 있었다.   

* 1주 차 (15년 7월 15일) 도메인 분석, 사용자 분석 

기획자: 인셉션이 끝나고 기획자는 기획자끼리, 디자이너는 디자이너끼리 페어가 되어 일하고 필요할 때는 언제나 함께 모여 토의했다. 인셉션에서 정의한 해피 패스를 기반으로 기능을 도출했다. 이 기능을 분할하여 정리했는데 이때 협업 툴인 트렐로(Trello)를 사용했다. 디자이너와 협업하여 기능 하나하나에 대해 이야기하고 모호한 것이 있으면 추후에 생각하기로 하고 이를 프로젝트 룸의 벽에 포스트잇으로 정리했다. 기획자는 해피 패스와 관련되어 딱 필요한 일만 고려하고 다른 고민은 하지 않기 위해 노력했다.     

디자이너: 디자이너는 해피 패스의 대표 퍼소나(Persona)의 시나리오 단계를 구체화했다. 그리고 시나리오 단계를 구체화한 후 이 시나리오를 담을 수 있는 와이어프레임을 A4지에 만들었다. A4지에 와이어프레임을 만들 때는 페어로 일하던 것을 잠시 멈추고 서로 디자인 한 뒤 이를 다시 합쳤다. 그리고 이 와이어프레임에 대해 디자이너끼리 동의가 이루어지자마자 스케치라는 툴을 활용해 작업을 시작했다.     

느낀 점: 일을 할 때 낭비를 최소화한다. 모호한 점이 있으면 사용자를 통해 검증받을 수 있다는 생각으로 상상력을 통해 억지로 시나리오를 정의하지 않는다. 현재 확인할 수 있는 범위에서 작성하고, 추후 구체화하기로 한다. 시나리오를 화면으로 만들 때 많은 화면을 만들지 않는다 가장 중요한 6~7장 정도만 만들고, 이를 검증 한 뒤 추가적인 화면을 만든다.     

[기획자, 디자이너의 미팅]

* 1주 차 (15년 7월 16일) 이해관계자 미팅, 사용자 리서치 수행  

기획자: 사업적 고객을 찾아 프로젝트를 성공하기 위해 필수적인 요소가 무엇인지 인터뷰했다. 그들에게 고객 생각하는 우선순위에 대해 질문했다. 남은 시간에는 업무 매뉴얼을 확인하며 업무 분석을 수행했다.     

디자이너: 사용자 리서치를 진행했다. 프로젝트 시작 전부터 미팅을 잡았던 퍼소나와 유사한 인물을 찾아 인터뷰하고 가정으로 만든 해피 패스가 실제로 그러한 지 확인했다. 또한 사용자의 힘든 점에 대해 이야기를 충분히 듣고 스케치의 디자인에 반영했다.     

느낀 점: 기획자는 도메인에 충실하고 디자이너는 사용자에 충실하게 업무 분석을 수행한다. 시나리오에 집중하여 역할과 책임을 적절히 나누어 업무와 사용자에 대해 두 가지 다른 관점으로 분석한다.   

[페어 디자인]

* 1주 차 (15년 7월 17일) 사용자 리서치 수행, 첫 회고  

기획자: 해피 패스와 관련된 기능의 우선순위를 잡았다. 자연스레 우선순위가 높은 것은 더 많이 고민했기 때문에 기능에 대한 상세화가 보다 잘 되어 있는 상태였고, 우선순위가 낮은 것은 러프한 기능이 정의되어 있었다.     

디자이너: 또 다른 사용자 리서치를 진행했다. 또 다른 퍼소나와 비슷한 사용자를 만나 해피 패스에 대해 검증했다. 어제와 같은 과정을 진행했다.     

느낀 점: 일주일 이상의 일은 큰 콘텍스트만 정해놓고 세부 계획은 세우지 않는다. 이렇게 해서 그날 해야 할 일은 당일 업무 진행 중 상황 변화에 따라 수시로 바뀔 수 있다. 당일이 되어서야 오늘 뭘 해야 할지 알 수 있을 정도이다. 과거에 작성하던 WBS(Work breakdown structure)는 최근 실리콘 밸리의 린스타트업을 하는 회사들에서는 거의 사용하지 않는다. WBS의 가장 작은 단위가 보통 2주인데 자신들은 매일매일 계획을 변경해야 하는 일이 많기 때문에, 언젠가부터 쓰지 않기 시작했다고 한다. 금요일 오후 늦게까지 집에 가지 않고, 다들 사무실에서 맥주를 마신다. 문화적인 충격이다. 사람들이 사무실을 떠나지 않는다. 맥주를 마시며, 서로 이야기하며 사무실에 있는 것을 즐긴다. 이 시간을 통해 자연스레 타 팀과 네트워킹을 한다. 맥주를 마시지만, 아무도 취할 만큼은 마시지 않는다. 왜냐하면 이 시간은 미래의 협업을 위해 자신의 좋은 이미지를 보여줘야 할 시간이기 때문이다.   

* 2주 차 (15년 7월 20일) 가치제안 캔버스 작성, 사용자 리서치 결과 정리    

기획자: 가치 제안 캔버스(Value Proposition Canvas)를 통해 제품의 가치를 명시한다. 오른편에 먼저 고객이 시스템을 통해 하려고 하는 필요(Customer Job)와 이 태스크를 수행할 때 시스템을 활용하여 얻을 수 있는 가치(Gains)와 시스템이 없을 때 겪고 있는 힘든 점(Pains)을 적는다. 다음으로 왼편에 사용자가 가치를 얻기 위해 수행해야 하는 방법(Gain Creator)과 힘든 점을 덜기 위한 방법(Pain Reliever)을 적고 마지막으로 무엇을 만들지(Products & Services)를 넣는다.     

디자이너: 두 번에 걸친 사용자 인터뷰 후 인상 깊었던 점에 대해 논의하고 향후 디자인 개선을 위한 액션 아이템을 도출했다. 이는 텍스트 형태로 구글 독스에 정리한다. 인비전(Invision) 툴에 와이어프레임 파일을 업로드하고 이 툴을 통해 프로토타입을 보았다. 디자인한 내용을 기반으로 기획자와 함께 사용성에 대해 내부 공유를 했다.     

느낀 점: 가치 제안 캔버스를 통해 제품의 비전에 대해 기획자는 명확히 할 수 있다. 하지만 여기에서 끝내는 게 아니라 2주에 한번 이를 지속적으로 다시 리뷰하며 변경 상황을 반영해야 한다.  예전에는 실리콘밸리의 사무실마다 탁구대가 있는 것에 대해 겉멋이 아닌가 생각했는데, 집중력이 떨어질 때 10분 정도 페어와 탁구를 치면, 다시 업무에 집중하는데 효과적인 것을 발견했다. 일하는데 더 생산성을 높일 수 있는 보조재라는 생각이 들었다.   

[가치 제안 캔버스 내용]

* 2주 차 (15년 7월 21일) 해피 패스 정제   

기획자: 프로젝트 관련 비즈니스 전문가와 1시간 통 안 콘퍼런스 콜을 통해 인터뷰했다. 해피 패스에서 달라질 수 있는 케이스에 대해 물어보고 업무 이해도를 높였다.     

디자이너: 사용자에 대한 정보를 기반으로 화면을 업그레이드했다. 해피 패스 안에서 중간에 조금이라도 매끄럽지 않을 것 같은 이슈들을 도출하여 서로 종이를 이용하여 각자 해결책을 고민하고 다시 페어로 만나는 것을 반복했다. 기획자에게 지금까지 만들어진 화면을 공유하고 개발 방향을 함께 논의했다. 퍼소나에 가장 가까운 사용자를 리크루팅 하기 위해 열심히 노력 중이다.     

느낀 점: 오늘 첫 디자인 프로토타입이 나왔다. 일주일만의 일이다. 단순하고, 빠르다. 가장 중요하고, 필요한 것에 초점을 맞춘다. 많은 사람을 한 번에 만족시키려고 하지 않는다. 그게 가장 큰 차이다. 억지로 여러 가지를 한 번에 하려고 하지 않는다. 마인드셋의 차이가 크다. 이 차이를 한국에 가서 어떻게 적용해야 할지가 고민이다. 사용자의 리크루팅이 정말 어려운 일이다. 이건 디자이너만의 일도 아니고 기획자만의 일도 아니다. 모두가 어떠한 방법으로든 사용자 미팅을 주선해야 한다.   

[사용자 검증: 대략적 상황을 설명해주고 사용해보도록 한다]

* 2주 차 (15년 7월 22일) 사용자 스토리 작성, 해피 패스 디자인 사용자 검증   

기획자: 트렐로에 정리된 기능에 우선순위화를 했다. 가장 먼저 차주부터 개발해야 할 해피 패스와 연관된 기능을 제외하고, 나머지 기능에 대해 ‘MUST: 반드시 해야 할 일'과 ‘GOOD TO HAVE: 하면 좋은 일'를 붙여두었다. 순서대로 당장 개발할 내용은 보다 구체적이었고, 그 외의 것들은 러프하게 정의했다. 차주부터 개발자들이 투입되어 개발해야 할 내용에 대해서는 사용자 스토리로 옮기기 시작했다. AS: 어떤 사용자로서, I WANT: 이 기능을 원한다, SO: 이 기능을 통해 얻는 사용자의 가치 형태로 기능을 쪼개 사용자 스토리로 만들었다. 그리고 작성된 사용자 스토리에 GIVEN / WHEN / THEN 형태로 인수조건을 작성했다. 이후 트렐로와 유사한 P사의 트래커에 작성된 사용자 스토리를 입력했다. 트렐로에는 기능 개발의 큰 그림을, P사의 트래커에는 디자이너 및 개발자와 협업할 단위인 사용자 스토리를 남겨두었다.     

디자이너: 사용자를 리크루팅 하여 해피 패스에 대한 디자인을 실 사용자와 검증했다. 2명의 사용자를 만났고, 사용자에게 대략적인 기능에 대해 설명하고, 인비전을 통해 모바일로 마치 동작하는 제품처럼 그들이 어떻게 사용하는지를 관찰했다. 그들의 행동을 관찰하여 조금이라도 주저하거나, 사용하기 어려워하는 모습이 보이면 기록했다. 이후 그들에게 현재 일할 때의 힘든 점고 현재 사용하는 제품에 대해 개선할 점이 어떤 것들이 필요한지 청취했다.     

느낀 점:  곧 올 개발자들을 위한 작업들이 준비되고 있으며, 여기 생활에 익숙해지고 있다. 하루하루가 정말 빨리 간다. 사용자들을 리크루팅 하는 것이 정말 어렵다. 사용자를 구해주는 에이전트를 사용하는 것을 고려중이다.   

[인수 조건의 예제]

* 2주 차 (15년 7월 23일) 프로젝트 리스크 리뷰, 개발자들을 투입 시 공유할 자료 정리  

기획자: 프로젝트의 리스크와 가정을 다시 한번 점검했다. 페어로 화이트보드에 프로젝트에서 리스크라고 생각되는 것을 최대한 많이 적고 이를 비슷한 내용끼리 모았다. 리스크가 실제 이슈가 되었을 때 프로젝트에 줄 충격과 긴급성 두 가지 기준으로 사용자 리스크를 구분했다. 남은 시간에는 차주부터 개발자들이 들어와 일할 내용에 대해 디자이너와 함께 구체화했다.     

디자이너: 해피 패스를 기준으로 실제 사용자 경험 측면에서 어떠한 일들이 일어날지 이야기하며 디자인에 대한 논리를 구체화한다. 또한 차주 만날 개발자들에게 공유할 내용에 대해 검토하고 상세 구현한다.     

느낀 점: 린스타트업 프로세스는 2-3일 이내의 일에 대한 일들만 고민하고, 더 먼 미래에 대해서는 관심을 덜 갖게 한다. 속은 편한데, 한국에 돌아가서 일할 때 앞으로 어떻게 될지 걱정이 된다.  

* 2주 차 (15년 7월 24일) 개발자 투입 전 점검   

기획자: 디자이너들과 함께 사용자 스토리를 점검했다. 사용자 스토리에 인비전으로 공유한 디자인 목업의 링크를 달고 현재 만들어진 디자인과 함께 엮여 있는 부분에 대해 조율했다. 사용자 스토리와 디자인이 불일치하지 않는 부분이 없도록 조정했다. 개발자들과 수행할 워크숍의 어젠다 및 개발자들과 사용자 스토리를 추정하기 위한 준비를 수행했다.     

디자이너: 1명의 사용자와 디자인 검증을 추가적으로 진행했다. 해피 패스 디자인에 대해 활용하기 편할 것 같다는 피드백을 들었다. 추가적으로 해피 패스 외에 해피 패스 다음에 집중할 시나리오에 대해서 질문을 시작했다. 다양한 의견들을 들을 수 있었다.     

느낀 점: 2주가 정말 빨리 지나갔다. 한국에서 하던 일과 많이 다른 방식으로 일이 진행되었다. 린스타트업은 낭비가 거의 없는 일로 느껴졌다.