UX BOOKS : SPRINT
LEAN하게 일하는 방법에 대한 완벽한 가이드북
평점 : ★★★★★
이 책은
SPRINT란 한 주간의 집중적인 협업을 통해 문제를 진단, 아이디어를 도출하고 사용자의 검증까지 받는 전체 과정을 의미한다. 이 책은 그 일주일간의 과정을 요일별 오전/오후로 세세하게 쪼개 어떤 작업들을 해야하는 지 설명해주고 있다. 챕터도 Set the stage → 월~금 → Lift off / Checklist로 구성되어 있기때문에 급하게 실행해보고 싶은 사람들은 요일별로 읽어가며 진행할 수 있는 완벽 가이드북이다.
누가 읽어야 하는가? - Lean Project의 PM, Designer
사실 LEAN UX와 Agile UX에 관한 이야기는 2012년부터 꾸준히 이쪽 분야에서는 이야기 되어왔던 소재이다. 몇권의 책과 Article로 개념정도는 이해하고 있었지만 실제로 기업 문화가 이렇게 바뀌기는 상당히 어렵기때문에 그 가치를 체득할 수 있는 기회란 적어도 내게는 아주 멀리 떨어진 다른 세계 이야기였다. (특히 대기업쪽은 프로세스를 바꾼다는 것 자체가 굉장히 어려운것이 사실이다.)
그런데 이전 글에도 언급했듯이, 지금 나는 Agile Core Team에서 UX 디자이너 역할을 맡고 있다. 쪼렙디자이너에게 한 편으로는 너무 큰 짐이 지워진 것 같아 불안하기도 하면서, 새로운 세계가 펼쳐지고있는걸 경이롭게 바라보고 있기도 하다. 그러나 이런 Cross-functional Team에서는 각 역할자 간의 밸런스가 퍼포먼스의 핵심 요소라고 할 수 있다고 생각하는데, 나의 경험과 지식부족은 몇 번의 팀 밸런스의 붕괴를 가져왔고 나는 그 간극을 해소하기위해 무엇인가 반드시 해야했다.
그 과정중에서 보석처럼 찾아낸 것이 바로 이 책 'SPRINT'이다.
그동안 LEAN UX관련 책들은 What에 대한 이야기는 아주 상세하게 다루고 있는 반면, How에 대한 내용은 상대적으로 가볍게 다루고 있다. 가령 Early Prototyping 후, User validation을 하는 것이 왜 좋은지, 무엇에 포커스 해야하는지는 Lean UX 책에서 알 수 있다. (더 자세하게는 UX for lean startups에서 찾을 수 있다.)
반면, 이 책에서는 Early Prototyping을 만드는 방법에 대해 설명하고 있다. Prototyping은 그냥 만들어지지 않는다. 그것은 디자이너와 개발자, PM, 그리고 stakeholders 사이에서 끊임없는 고민과 토론의 결과물로서 만들어진다. 그 과정을 어떻게 조금 더 효율적으로 할 수 있을것인가, 그러기 위해서 디자이너는 무엇을 준비해야하는가에 대한 A-Z 가이드가 이 책에 포함되어 있는 내용이다. 정말 내가 원했던 내용이며, 대부분의 UX 디자이너들도 공감할 것이라 생각한다.
이 책의 핵심 내용
너무 많은 내용이 책 안에 들어있지만 요약하면,
SPRINT 책에서 강조하는 것은 낭비를 제거하는 것이다. 또 가정을 배제하는 것이다. 때로는 너무 많은 생각이 전체 팀의 속도를 늦춰 'Getting Out of the Building'을 막는 허들로 작용한다. 그렇기에 SPRINT의 성공에는 퍼실리테이터의 역할이 중요한데, 퍼실리테이터는 막힘없는 프랙티스의 진행을 위하여 Time boxing rule을 준수하며 유연하게 과정을 진행해야한다. 또한 과도한 토론과 의견대립을 적절히 조율하는 능력도 요구된다. 이런 면에서 각 요일 챕터 마지막에 배치되어 있는 Facilitator Note의 내용은 GV에서 SPRINT를 진행하면서 느낀 Know-How가 농축되어 있기에 반드시 읽어봐야할 필요성이 있다.
결론 - 왜 우리는 SPRINT를 적용할 수 없을까?
읽으면서 들었던 생각은 현재 우리가 일하는 방식(Pivotal에서 배워 온)과 일맥상통한다는 것이다. 지속적인 Iteration으로 낭비를 제거하고 철저히 가정을 배제하고 제품을 만드는 방식이라는 측면에서 그러하다. 또한 이런 일주일간의 작업은 Agile에서 이야기하는 'Inception'작업과 굉장히 유사한 면이 있다. 그래서 나로서는 각각의 단계에서 어떻게 행동해야하는지 알려주는 든든한 매뉴얼을 얻은 기분이다.
그런데 우리는 왜 이런 'SPRINT' 방식으로 일 할 수 없을까?
첫째, 제품의 오너십이 분산되어 있다. 현재 우리 회사의 프로세스는 어떤 한 부서가 모든 제품을 처음부터 끝까지 책임지지 않는다. 기획 - 디자인 - 개발 - 검수까지 각각의 부서에서 담당하고 있다. 따라서 좋게 이야기 하면 각자의 전문분야에서 최선을 다하고 있고 나쁘게 이야기하면 책임과 위험부담이 분산되어 있어 어느 누구도 제품에 대해 책임 지려하지 않는다.
SPRINT에서 가장 중요한 역할은 퍼실리테이터와 의사결정자(The Decider)이다. 제품의 오너십을 가지고 있고 우리 제품이 어떤 문제를 해결해야하는지, 앞으로 어떤 제품이 되어야 하는지 명확한 비전을 가지고 있는 사람이 필요하다. 그래야 팀원들의 방향성이 갈피를 못잡을때, 아이디어의 우선 순위가 모호할 때 의사결정자가 그 허들을 넘게 해주는 SPRINT 부스터 역할을 해줄 수 있다. 그러나 이런 구조에서는 그런 사람(The Decider)을 찾기 힘들다. (솔직히, 서로 싸우지나 않으면 다행이다)
둘째, B2B UX의 특징에 대한 글에서도 언급했지만 단위 시스템 규모가 어마어마하다. 제품을 생산하는 공장을 관리하는 시스템, 물류 흐름을 모니터링 하는 시스템(둘 다 글로벌하게 쓰이고 있는 시스템이다)등 같은 커다란 시스템은 각 모듈별로 전문화되어 있고 소유 부서도 다르다. 그렇기에 단순한 변경도 복잡한 결재를 타야하는 경우가 있다. 그 모든 관계자를 모아, 일주일 안에 SPRINT를 진행하는 것은 어쩌면 꿈같은 이야기일지 모른다. (또 어렵게 그런 사람들을 모아놓으면 첫번째 이슈가 발생한다..시빌워같은...)
그럼에도 불구하고, 지금 Agile Core Team에서 일하는 동안 드는 확신은 프로세스는 Waterfall일지언정, 선행되는 UX 프로세스는 Agile하게 움직여야한다는 것이다. 또한 그렇게 일한다는 것의 의미는 Tool이나 프로세스의 의미가 아니라 UX담당자들의 태도와 가치의 변화를 통해 이뤄질 수 있을 것 같다.
마치며
사실 중요한것은 방법론이 아니다. 각 팀원들의 마인드셋이 사용자 중심 디자인과 개발의 가치를 이해하고 열린 마음으로 그 프랙티스를 지지하고 있느냐가 Agile 프로세스의 핵심이라고 생각한다. 그러나 일단 그런 상황이 성숙되어 있다고 하면, 이런 가이드북의 존재는 디자이너에게 너무나 고마운 존재이다. 마침 이번 달부터 시작하는 프로젝트가 있다. 나는 뭣모르는(혹은 겁없는) 쪼렙디자이너로서 이번 프로젝트를 SPRINT 방법으로 진행해보려고 한다. 딱 일주일동안만 프로젝트를 진행하는 것이 아니기때문에 연속성을 가지기는 힘들겠지만, 이 책에서 벤치마킹 할 수 있는 프랙티스는 그대로 적용해보려고 한다. 읽고 아는 것과 해보고 느낀 것의 차이는 어마어마하고, 더 나은 방법을 찾기 위해서는 반드시 실행해보아야 하기 때문이다.
혹시라도 프로젝트가 망하면? 할 수 없다. 다시 이야기하지만, 우리 회사는 쪼렙 디자이너에게 책임을 묻기(혹은 전가하기) 어려운 책임분산형 구조를 가지고 있다.
