예전에 소개했던 동영상 내용을 좀 더 풀어서 포스팅 해보려고 한다. 이제부터 제품 planning 을 시작해야 하는데, 적절한 scenario 를 세팅해 놓는 것이 필요하다고 느끼기 때문이다.

Sound Familiar?

• 이 프로젝트 목적이 뭔지 잘 모르겠다. 실컷 고생해서 일 했는데, 별 사업 가치도 없는데다 고객들 까지 실망시키면 어떡하지?
• 잘 이해는 못했다만, 어찌됐든 requirement 에 맞는 솔루션을 만들어냈다. 처음 넘겨 받을 때부터 뜬구름 잡는 이야기들 뿐이었어. 이 정도면 잘 했지 뭐.
• 날 속였구나 이 개발자 놈아! 분명 스펙에 sign off 를 했는데 완전 다른 걸 만들어 가지고 왔잖아!
• IT 녀석들은 느려 터진데다 몸값도 더럽게 비싸. 내 비즈니스의 핵심을 이해하질 못해!

이런 얘기 들어본 경험 있거나 비슷한 상황을 목격한 사람들이 꽤 있을 것이다. 소프트웨어 업계에서는 일상처럼 벌어지는 일들 아닌가.

…and in the MS product hallways

• 팀 사람들이 전부 제 각각의 생각을 가지고 있다. 뭐가 제일 중요한지, 우리가 지금 뭘 만들고 있는지, 도대체 누굴 위한 걸 만드는지 합의점이 없다.
• Usability 테스팅도 하고 Beta 테스팅도 한다. 하지만 고객 피드백을 받을 때 쯤이면 이미 개발이 마무리 단계라 알면서도 뭘 어떻게 해주도 못한다.
• 개발 막판에 대박 디자인 변경을 해야 했다. 수많은 코드들을 버려야 했다. 완전 삽질했다.
• 우리 제품이 기능은 훨씬 많았는데, 경쟁사 제품이 시장을 압도했다. 그 회사 제품은 전체적으로 훨씬 좋은 experience 를 제공했다.

Microsoft 에서도 위와 같은 의견들이 있었다고 한다. 문제점을 인식하고, 위의 장벽들을 뛰어넘은 케이스들을 살펴보기 시작한다.

How’d they do that?

도대체 어떻게 이런 걸 만들어 냈을까? 라는 질문부터 시작해서 여러 파트너들과의 협조 끝에 User Scenario 기반의 Engineering 방법을 만들게 됐고, 그것의 이름은 Scenario focused Engineering 이라고 붙이게 됐다고 한다.

Scenario-focused Engineering

Scenario-focused Engineering : inspires teams to level up their game by infusing customer-focused, interative design pratices into theiry daily work

즉 SFE 의 핵심은 고객의 관점과 가치를 개발의 모든 활동들에 스며들게 만드는 것이다.

개발을 Plan-Design-Implement&Stabilize 라고 본다면, 이 각각의 단계에서 scenario 를 지향하도록 활동하는 것을 말하는데,

• Plan : 고객들의 유형을 나누고, 우선순위를 부여하여 중요도가 높은 고객을 설정한다. 그리고 그 고객의 시나리오를 선택한다.
• Design : End-to-End scenario 를 위한 개발을 하고,
• Implement & stabilize : 목표한 scenario 가 손상되지 않고 제대로 구현됐는지, 다시금 확인하고 안정화 시킨다.

Get to know your customer

SFE 의 핵심은 고객의 목소리에서 출발한다. 반드시 현장으로 나가 고객의 목소리를 듣는다. 어느 정도 케이스가 쌓이면, 고객의 유형을 나눠 우선순위를 주게 된다.

Document their pain & insights

현장 기록에서 가장 중요한 것은 고객들의 pain point 를 확인하는 것인데, 고객이 담당하고 있는 역할은 무엇이며, 무엇이 그들을 괴롭게 하고 있는지 기술한다. 그 문제가 고객의 가치를 어떻게 훼손하고 있는지 확인하고, 고객이 바라는 문제에 대한 dream state 가 어떤 것인지 알아온다. 즉, Pain point, Value, Hope 이다.

Write a scenario

A scenario is a narrative story told from the customer’s point of view that explains their situation and what they want to achieve

여기에서 한가지 주의할 점은 Scenario 작성 시에 문제를 어떻게 해결할지에 대해서는 기술하지 않는다는 것이다. 한편으론 고객의 dream state 를 기술하여 문제가 해결되면 고객이 어떤 가치를 얻게 되는지 설명한다.

Example

Gene is an IT generalist in a company whose policies require extensive logging, so he is always checking free disk space and that logging is working on all 200 web servers. Currently he does this manually several times a day. He wants to automate it, but he is not a programmer and he has always struggled to get scripts working.

  <magic happens>

Gene discovers a way to easily automate common IT tasks, and finds it straightforward despite his limited programming background. Within 5 minutes he is able to automate his first task on a local machine. When he tries to run it on multiple machines the task fails, but it helps him with troubleshooting, and he is soon able to run the task successfully across his entire cloud. Gene is pleasantly surprised at how easy it was to achieve such a time savings in hi day-to-day work.

시나리오의 예제이다. 문제점을 기술했는데 그 내용을 요약하면, 진 이라는 사람은 IT 회사를 다니는 보통의 사원이다. 그 회사는 운영하는 서버들에 대해서 꽤나 빡빡한 logging 을 남기는데, 프로그래머가 아닌 진이 200 개나 되는 웹 서버의 디스크 여유공간 확인과 로깅 작업을 손으로 일일이 하고 있다. 이걸 자동화하고 싶은데 프로그래머가 아니다 보니 스크립트를 돌리는 일조차도 버겁다.

<문제 해결!>

진은 일반적인 IT 작업들을 쉽게 자동화하는 방법을 찾았다. 프로그래밍 지식이 없어도 쉽게 할 수 있었다. 5 분도 안돼서 작업하는 컴퓨터에서 자동화를 완료할 수 있었다. 이제 이것을 여러 기계에서 실행하기 위해 시도했으나, 잘되지 않았다. 그렇지만 troubleshooting 을 이용해서 곧 문제를 해결할 수 있었고, cloud 전체의 기계에 쉽게 적용하게 되었다. 진은 일상 업무에서 시간을 엄청 절약하게 해주는 업무 자동화가 이렇게 쉽게 가능하다는 데에 놀라면서도 기뻤다.

Implementation Free

왜 시나리오에서 구현을 언급하면 안 되는지 알아보자. 결론부터 말하자면, 구현을 미리 언급하는 것은 사고의 범위를 좁게 만들기 때문이다.

만약 ‘존이라는 사람이 부모님께 손자들 사진을 공유하고 싶어한다.’ 라는 시나리오에 대한 방법들을 찾아보면 위와 같이 무수한 아이디어들이 나온다. 몇몇은 Flickr 나 Youtube 같은 새로운 사업의 영역이 될 수 도 있는 좋은 아이디어 들이다.

그런데 만약 이 시나리오를 쓸 대, ‘존이라는 사람이 부모님께 손자들 사진을 이 메일로 보내길 원한다.’ 라고 했다면,

위의 아이디어들 중 상당수가 처음부터 무시되고 관심을 받지 못했을 것이다. Scenario 를 작성할 때는 최대한 가능한 옵션의 수를 유지하여 고객에게 가장 좋은 해법을 찾도록 해주는 것이 중요하다. 그렇기 때문에 시나리오 작성시에는 Implemntation 을 언급하지 않도록 해야 한다.

SFE 의 핵심은 앞의 Scenario 를 완성하고 매 iteration 에서 그것을 다듬는 것이다. 그 다음 남은 작업은 위의 Scenario 를 어떻게 쪼개어 실제 코드로 변환하는 과정이나 동영상에서는 그것에 대해 잘 다루지 않는다. 여기에 대한 힌트는 User Stories Applied 등의 내용을 빌려 올 수 있다. Scenario 를 쪼개어 여러개의 스토리로 나누고, 각 스토리에 대한 구현으로 들어간다.

Storyboarding

스토리를 나눌 때, Storyboarding 이라는 작업을 하는데, 스토리가 담고 있는 문제 해결을 위해 고객의 의견을 참고하는 것이다. 먼저 위와 같이 몇 컷으로 나눠진 스토리보드를 여러 개 만들어 고객에게 제시한다. 그 다음 고객의 의견을 참고하여 빠른 프로토타이핑을 한다. 실제 써보는 것과 말만 듣는 것은 그 느낌이 다르기 때문이다.

SFE 동영상에서 다루는 내용은 여기까지다. 이제 Scenario 를 쪼개는 방법과 프로토타이핑에 대한 내용이 있어야 할 것 같은데, 몇 권의 책을 좀 읽은 뒤에 다시 요약해서 시리즈 포스팅으로 가져가야 겠다.