Different Levels of Planning
실리콘밸리의 제품 계획/개발/수행 프로세스
멋진 제품을 출시하기 위해 어떻게 디자인하고 개발할 것인가에 대한 계획을 세우는 것은 아주 중요한 일이지만, '어떻게?' 라는 질문에는 안타깝게도 정답이 없다. 아마도 많은 디자인팀, 개발팀, PM팀(Product Manager, 한국 회사로 치면 아마도 상품기획팀?)들은 실제 제품을 만들어내는 과정 만큼이나, 그 과정을 효율적으로 발전시키기 위한 노력을 끊임없이 하고 있다. 그 때문에 정답을 말할 수는 없어도 '그래도 예전보다는 발전해나가고 있어요'라고는 말할 수 있을 듯 싶다.
이 글에서는 최고의 제품** 디자인 프로세스를 소개하려는 것이 아니라, 1) 내가 현재 회사에서 경험하고 있는 제품 디자인 프로세스를 공유하고 이를 바탕으로 혹시나 필요한 곳에 적게나마 영감을 주기 위함이며, 2) 이글을 읽은 여러 회사에서 일하시는 분들의 다양한 의견도 들을 수 있다면 금상첨화겠고, 3) 개인적으로는 지금의 프로세스를 문서화시켜서 이후에 좀 더 발전된 프로세스를 개선할때 레퍼런스로 사용하기 위함이다.
** 이 글에서 말하는 제품은 소프트웨어 제품을 의미한다. (eg. Web app, Mobile app, Desktop app 등)
관계, 그리고 예외없는 프로세스
프로세스를 상세하게 들여다보기 전에 그 프로세스를 굴러가게하는 각각의 구성원들의 역할과 관계를 먼저 보는 것이 좋겠다. 하나의 제품이 출시하기 위해서는 PM, 디자인, 개발이 세가지의 큰 축으로 함께 굴러간다. 어느 조직이 상위의 힘을 가지고 있어서 다른 조직을 힘으로 누르거나 따라오게 만드는 문화는 아니고, 기본적으로 동등한 파트너십(Partnership)을 가지고 일을 한다. 이들이 본성적으로 젠틀한 사람이라서가 아니라, 시스템을 그렇게 만들고 그 룰(Rule)대로 지키려고 노력하기 때문에 최소한의 파트너십이 유지가 된다.
시스템(혹은 프로세스)에 의해서 프로젝트를 진행하게되면 여러가지 장점들이 있는데, 그 중 하나가 일정 관리가 투명하게 되니 책임소재가 명확해지는 것이다. 그러다보니 '이거 진짜 급한건데 다음주까지 디자인좀 해줄수 있겠어?' 라는 식의 요청은 상식 밖의 일이 된다. 가장 중요한 것은 프로세스를 그럴듯하게 만드는 것이 아니라, 예외없이 지키는 것이다. 한두번의 급한일이라고(가령, 사장님 지시사항) 예외가 만들어지면, 그 시스템은 균열이 가게되고 결국에는 누구도 지키지 않게된다.
티켓(Ticket) 시스템
그리고 또하나 배경지식으로 꼭 알고 넘어가야 할 것이 있는데, 바로 티켓(Ticket)시스템이다. 콘서트장이나 미술관에 들어가기위해 구입하는 그런 티켓이 아니라, 문제 해결을 해달라고 요청하기 위해서 작성되는 가장 기본적인 문제해결 방식이자 관리하는 단위를 말한다. 이와 관련한 관리 시스템 소프트웨어도 여럿 있을정도로 이곳에서는 일상적인 업무의 방법이다. 한국에서는 아직 생소한 개념일수도 있는데, 한국의 은행에 가면 종이로 된 번호표(티켓)을 뽑고 본인의 용무를 볼 때까지 순서를 기다리는 것을 떠올리면 비슷하다. 단지 그 티켓이라는 것이 디지털화 되어있는 것이 다른부분이다. 그래서 이곳 실리콘밸리에서는 흔히 'XX프로젝트 관련해서 티켓 작성했어?', 'XX프로젝트 티켓들은 지난주에 다 마무리 되었어' 라는 식의 대화가 이루어진다.
오른쪽의 리스트들이 일해야 할 티켓들이다.계획을 구체적으로 쪼개다
가령 어떤 회사의 CEO가 사업의 큰 방향을 이야기하는 것이 신입 디자이너가 일하는 조그만 프로젝트와 어떻게 연결되는지 볼 수 있다면, 그 회사는 나름대로 제품 디자인 프로세스가 잘 굴러가는 조직이라고 말할 수 있겠다. 하지만 불행히도 많은 경우 회사의 리더십이 이야기하는 비젼과 실무를 담당하는 사람들과의 간극이 벌어져있다. 회사가 지향하는 목표의 절대적인 가치의 높고 낮음과는 관계없이, 리더십의 목표가 회사의 제일 끝단의 사람에게 구체적인 형태로 어떻게 전달되고 연결되느냐가 효과적인 프로세스의 성패를 좌우하는 부분이다. 다행히도 현재 일하고 있는 회사에서는 그런 부분들이 비교적 잘 작동할 수 있도록 프로세스가 잘 되어있는 편이다. 나보다 이 회사에서 오랫동안 일했던 동료의 이야기를 들어보면, 이렇게 프로세스가 틀이 잡혀진 것은 얼마 되지 않았다고 하니, 나로써는 다행스러운 일이다.
큰 계획을 실행하려면 그 계획을 구체적인 단계로 쪼개서 만들어야 하는데, 여기서는 4단계로 구체화되는 과정을 언급하고자 한다. 회사마다, 팀마다, 프로젝트마다 다를수 있으니 여기 있는 내용은 그저 참고용으로만 생각하면 좋을것 같다.
Vision
Vision은 말 그대로 회사의 리더십에서 논의하고 정하는 가장 큰 단위의 계획이다. 예를 들면 '2020년 상반기 Q2까지 인공지능비서 서비스 앱을 선보이겠다' 라는 식으로 구체적인 실행 계획은 빠져있지만, 최종적으로 실현해야하는 목표와 달성 시기가 언급되어있다. 사실 구체적인 일정이 없는 계획이라고는 했지만, 그 vision을 세우고 회사 구성원들에게 공유하기 위해서는 미리 시뮬레이션도 돌려보고, 경쟁사, 마켓 리서치 등을 통해서 어느정도 '실현 가능한' vision을 제시하기 마련이다.
Mission
위에서 말한 Vision을 조금 작은 단위로 나눈 것이 Mission이다. 보통은 하나의 Vision을 실현 시키기 위해서 달성해야하는 Mission이 여러개가 나온다. 그래서 현 직장에서는 M1, M2 이런식으로 분류하기도 한다. 계속해서 위에 언급한 vision의 예를 들자면, M1은 인공지능 개발 관련한 것, 최적의 UX디자인을 개발하는 일 등이 될 것이고, M2는 '음성 인식을 기반으로하는 사용자 인터페이스 디자인'과 같이 조금 더 구체적인 형태를 띠게 된다. Mission 티켓은 디렉터, 매니져급 이상이 결정하고 분류하는 것이 대부분이다.
Epic
Epic은 Mission를 달성하기 위해 조금 더 구체적인 단계로 진입한다. 특정한 타깃 유저가 언급되며 디자인팀과 개발팀에 요청되는 Use case나 User pain point, Stakeholder의 requirement 도 여기서 처음 나오게 된다. 마찬가지로 하나의 Mission에도 여러개의 Epic이 나오는 것이 보통이다. PM이 Epic의 내용을 티켓 안에 탄탄하게 제대로 작성을 해야만, 이후에 업무를 실제로 맡게될 디자이너, 개발자들이 명쾌하게 일을 시작할 수 있는 토대가 된다. 프로젝트의 성공을 어떻게 평가할 것인지에 대한 기준도 함께 표기되어있다.
User Story
가장 마지막 단계로 User story가 있다. 하나의 User story에는 해결해야 할 한두가지의 문제점이 구체적으로 명시가 되어있고, 하나의 스토리 안에는 몇가지의 Use case가 존재하기 때문에 디자이너로써는 다양한 상황들을 검토하고 해결책을 제시해야한다. 프로젝트는 스토리의 단위로 팀 안에서 구체적으로 관리가 되고, 어떤 디자이너나 개발자가 일을 맡게될지 모르므로 PM은 꼼꼼하게 해당내용을 User story 티켓 안에 담아야한다.
같은 이미지를 다시 보면- 위에 'As a~' 로 시작하는 것들이 전부 User Story 티켓이다.실행 계획을 세우다
큰 계획이 여러개의 실행 가능한 구체적인 계획으로 쪼개어졌으면, 이제는 그것들을 실행할 계획을 세울 차례이다. 실행 계획을 세우는 과정도 역시 단계적으로 이루어진다.
Backlog
백로그(Backlog)는 간단하게 말하면 각종 티켓들이 저장되어있는 임시 창고라고 생각하면 된다. 디자인팀, 개발팀에 부여된 여러 티켓들이 모여있는 곳이다. 아직 이 티켓이 실무자에게 전달된 상태는 아니다.
Grooming
백로그에 모여있는 티켓들이 대부분 해결되야 할 것들이긴 한데, 중요도 및 긴급성, 그리고 다른 티켓들과 중복되는 것들이 있는지, 혹은 다른 티켓과 합칠수 있는 것들은 없는지 확인해보는 단계를 그루밍이라고 한다. 그루밍 단계를 거친 티켓들만이 실무자에게 배정될 수 있다.
Sprint planning
디자이너와 개발자는 각 2주 단위로 프로젝트를 수행하는 계획을 세우는데, 이걸 스프린트라고 한다. 2주를 기본 단위로 하고 그 안에 몇 가지 티켓을 위한 일을 한다. 티켓에 따라 소요되는 시간이 달라지는데, 어떤 티켓은 반나절만에 끝나기도 하고, 어떤 티켓은 2주간의 스프린트 기간이 모자라 다음번 스프린트로 넘기기도 한다. 그렇기때문에 디자이너, 개발자 그리고 PM은 여러가지의 티켓들 중에 중요도와 긴급도를 비교하여 스프린트 기간안에 처리해야할 일의 우선순위를 제대로 부여하는 것이 중요하다.
'Sample Sprint 2'과 'Backlog'의 영역이 나뉘어져있는 것이 보인다. 'Sprint 2'에 해당하는 티켓들이 2주간 해결해야할 것들이다.복기(復棋)
바둑에서 대국을 마친 뒤에 그대로 한번 더 바둑을 두어보면서 어디서 잘했는지, 잘못했는지 되돌아보는 것을 복기라고 한다. 여기서도 그와 비슷한 단계가 있는데, 우리는 Retrospective(보통 줄여서 '레트로'라고 하기도 함)라고 부른다. 스프린트 과정에서 어떤 부분이 미흡했는지, 계획 단계에서 어떤 부분이 잘 되었고 잘못 되었는지 등을 되돌아보고 다음번 계획 및 업무 수행시에 되풀이되지 않도록 하기 위함이다. 레트로를 거쳤음에도 반복되는 잘못과 실수가 발견되면, 매니저로부터 엄청나게 혼난다 개인의 문제라고 생각하지 않고 조직, 시스템의 문제라고 판단하며 파트너들의 리더십끼리 더 나은 개선점을 찾기위해 노력한다.
마치며
모든 프로세스가 이론적으로는 모두가 완벽하지만, 실제로 적용하는데 있어서는 어렵고 복잡한 부분이 많이 발생한다. 그렇기 때문에 앞서 말했듯 회사마다 팀마다 적용하는 제품 디자인 프로세스가 다른 것이다. 어떤 프로세스도 아직 완벽한 것은 없으나, 어떤 프로세스도 늘 제자리에 정체되어있는 것도 없다. 저마다 계속해서 자기들의 프로세스 관리 시스템을 써달라고 진화해갈 따름이다. 그리고 앞서 말했듯 프로세스 자체가 중요한게 아니라, 그대로 지키는게 중요하다.
seh
