화면만 잘 그린다고, 서비스 기획을 잘하는 게 아니다
도그냥 서비스 기획 스쿨에서 뽑은 핵심 파트 109개 (2) 실전편
이번 글은 이론 편에 이은 도그냥 서비스 기획 요약 글 실전 편이다. 흔히 서비스 기획 하면 유저 플로우를 그리고 페르소나를 만들고, 유저 여정 지도를 그리는 등의 작업이 중요하다는 생각을 많이 한다. 그러나 이 책에서는 이러한 통념들을 완전히 깨버린다. 보면서 UI 화면을 잘 그리고, IA를 잘 설계하는 게 핵심이 아니란 걸 명확히 깨달을 수 있었다.
누군가 실전을 거치며 얻은 노하우를 읽는다고, 그를 완전히 체화할 수는 없다. 실전에서 얻을 수 있는 노하우는 절대 실전을 경험하지 않으면 체득할 수 없다. 한 번의 실전으로도 체득하기 힘들다. 실전에서 수없이 깨지고, 고민하고, 이를 꽉 깨물 정도로 노력하고, 실패도 해보고 성공도 해봐야 진짜 내 지식으로, 내 것으로 만들 수 있다. 물론 실전은 두렵다. 그럼에도 불구하고 적극적으로 실전에 몰입해야 한다.
책을 읽으며 이 책을 쓰기까지 도그냥 님이 얼마나 많은 고민을 했을까, 또 얼마나 숱한 밤을 새웠을까 하는 생각이 들었다. 물론 이게 내 미래라는 생각도 들었고. 이 책을 읽고 나니 서비스 기획자, PM으로 나아가는 새로운 출발선에 다시 선 기분이다.
오늘 밤에도 분명 요구 사항 정의서를 써내려 가며, 기획을 수정하며, 또 끝나지 않을 것만 같이 많은 테스트 케이스를 작성하며 밤을 새우는 주니어 기획자, PM들이 많을 것이다. 같은 길을 걷는 주니어 PM이자 기획자로서 이들에게도 멀리서나마 심심한 응원을 보낸다.
프로젝트 실무에 돌입하다
마인드맵을 활용한 시스템 기획법
1. 보통 처음 기획하는 사람들의 머릿속에는 UI 그림밖에 떠오르지 않는다. 하지만 막상 그려보라고 하면 구체적이지 못하다. 데이터 항목이 하나도 정의되어 있지 않기 때문이다. 내가 가지고 있는 데이터와 필요한 데이터를 목록화해야 하는데, 이를 ‘데이터 항목을 정한다'라고 한다. 우리가 구현하고 싶은 기능별로 보유하고 있는 데이터와 새로 수집해야 되는 데이터를 떠올려 정리한다.
2. 프로그래밍 덩어리는 세 가지 차원에서 움직인다. 첫째 이용자에 따라 바뀌는 변수인 데이터, 둘째 그 변수를 받아서 특정한 목표에 맞춰 작동시켜주는 기능, 셋째 기능이 연결되어 만들어지는 서비스이다.
3. 서비스 목표와 이에 필요한 기능과 데이터를 차례로 정리했으면 이제 정책을 정리할 때다. ‘정책'이라고 하니 어렵게 느껴질 수 있는데 ‘데이터 활용 기준'이라고 생각하면 된다. 개발을 하는 사람이 알고리즘을 짤 때 핵심적으로 고려할 기준을 정리해주는 것이다. 정책의 난이도는 고민의 깊이에 따라 달라진다. 케이스에 따라 정책은 세분화된다.
4. 어차피 프로젝트를 진행하다 보면 서비스 완성도를 위해 지속적으로 정책이 추가된다. 다만 숙련된 기획자는 이런 것을 떠올리는 속도가 상대적으로 빠를 뿐이다.
5. 내부와 외부의 모든 사용자를 정의하고 서비스가 굴러갈 수 있는 업무 프로세스를 설계해야 한다. ‘굴러간다'는 것은 선후 관계를 의미하는데 기존에 정리했던 필요 데이터를 기준으로 입력과 출력의 순서를 구분하는 것이다.
6. 데이터 입력과 출력의 선후 관계가 파악되었다면 그다음 파악해야 할 것은 ‘사용자'다. 사용자를 파악한다는 것은 사용자의 문화인류학적 정보인 연령이나 가족관계가 아니라 사용자가 서비스에서 이루려는 목적이나 상황을 인지하여 적절한 프로세스를 설계해주는 것이다.
7. 서비스 기획의 가장 큰 부분은 사용자의 목적과 기획자의 서비스 전략을 맞추고 정책을 통해 데이터와 프로세스가 어떻게 흘러가는지를 정의하는 것이다. 화면이 아니라 데이터가 왔다 갔다 하면서 양면적 사용자의 목적을 이루게 해주는 완결성이 필요하다.
8. 시각적으로 보이는 화면 목록을 정리한 것을 보통 IA라고 부르는데 트리 방식으로 정리되는 ‘정보 구조 체계'를 의미한다.
9. 플로우 차트는 사용자별 입력과 출력 데이터, 로직의 흐름, 눈에 보이지 않는 데이터 저장 방식이나 연동 방식의 개념도 포함될 수 있다. 반면 유저 플로우는 같은 페이지 내에서도 이용 순서에 따라 화면이 어떻게 바뀌는지 정의한다.
10. 온라인 서비스의 시스템적 구조를 생각하며 프로세스를 기획하는 것은 화면만 생각하며 기획하는 것보다 훨씬 많은 연습이 필요하다.
목적에 맞는 범위로 좁힌 것이 맞나?
11. 서비스 운영 기획에서 가장 많이 하는 실수가 ‘범위 설정'이다. 전략 설정까지는 적절하게 했는데 기능과 플로우 차트를 정리하는 과정에서 비대하게 커지는 경우가 생기는 것이다.
12. 범위란 프로젝트에 포함되는 범주를 의미한다. 현재 운영 중인 서비스에 새로운 서비스를 만드는 일은 이미 다 만들어진 시스템에서 기능의 일부를 바꾸거나 추가하는 것을 의미한다. 그래서 서비스 운영 중에 진행되는 개선 프로젝트는 개발해야 하는 양을 정하는 것이 굉장히 중요하다.
한 가지 케이스로만 만들지 않았나?
13. 서비스의 모든 기능은 어떤 데이터가 들어와도 동일한 기준으로 문제없이 작동할 수 있어야 한다.
14. 우리가 만들어내려는 서비스는 UI 구성이 아니라, 어떠한 데이터가 들어오더라도 동일한 기준으로 화면과 기능을 제공하는 것을 의미한다. 그러니까 서비스 기획에서 중요한 것은 들어올 가능성이 있는 모든 데이터에 대해 케이스별로 적절한 처리 방식을 예상해주는 것이며 예상하지 못한 데이터가 들어오더라도 서비스가 문제 되지 않게끔 미리 해결하는 것이다.
15. 첫 기획 과정에서 최적화된 플로우를 만들지 못했다 하더라도 프로젝트를 진행해 나가면서 수정하면 된다. 필수적인 기능이나 데이터를 생각하지 못했다면 협업자들과 일해 나가면서 채우면 된다. 오히려 완벽하게 기획해야 된다고 생각하는 강박이 문제다. 해보면 알겠지만 처음부터 만족할 만큼 완벽한 기획은 불가능하다. 스스로 할 수 있는 데까지 해보고 얼른 협업자와 논의하는 것이 중요하다.
16. 온라인 서비스 개발 프로젝트에서 사용되는 요구사항 정의서란 소프트웨어에 포함되어야 할 기능과 데이터 등 완성될 서비스의 완성 조건을 정의하는 것을 의미한다.
왜 벌써 개발자를 만나야 할까?
17. 개발자를 만날 때 추천하는 방법은 요구사항 정의서를 작성해 리뷰하는 것이다. 요구사항 정의서는 개발자가 프로젝트를 마주하는 첫 문서다. 이 문서에는 큰 프로세스를 위한 데이터의 흐름이나 UI에 대한 요건, 서비스 이용자들의 케이스도 들어간다. 그리고 만들고 싶은 서비스의 내용이 아니라 개발자들이 판단하기 쉬운 형태로 개발 내용이 정리되어 있기 때문에 대화를 나누기에 용이하다.
18. 어떤 양식으로 요구사항 정의서를 쓰느냐는 사실 중요한 것이 아니다. 이 요청사항을 하루라도 빠르게 전달해서 협업자들이 앞으로 해나가야 할 일의 중요성이나 방향성, 스펙에 대한 감을 잡고 파악할 수 있도록 하는 것이 중요하다.
19. IT 서비스와 관련된 무언가를 진행하고 있다면, 비공식적으로라도 오픈하고 개발부서에 수시로 물어보는 것이 중요하다. 법무도, 개발도, 재무도 우린 그 무엇도 정확하게 예상할 수 없다. 심지어 해당 기간에 개발자의 일정이 비어있지 않으면 어쩔 텐가? ‘기획안만 잘 준비하면 개발은 착착 진행되겠지'라고 생각하는 건 지금 똥을 만들고 있다는 뜻이다. 온라인 서비스는 눈에 보이지 않는 부분이 훨씬 많다. 일을 혼자 하려고 해서는 안 된다.
20. 기획은 여전히 초안이기 때문에 기획 내용을 설명할 때 ‘이렇게 하고 싶다'라고 해야지 ‘이렇게 정했다'라고 해서는 안 된다. 이 작은 차이가 협업을 하는 태도와 분위기를 결정짓는다. 기획한 바를 설명하되 개발 가능성에 대해서는 개발 담당자가 더 고민하고 찾아볼 수 있도록 여지를 주는 것이 필요하다. (p.176)
21. 요구사항 정의서를 리뷰할 때는 원하는 기능뿐만이 아니라 프로젝트의 방향과 목표, 히스토리 등을 폭넓게 설명해서 공감대와 관계를 형성하도록 하자. 서비스를 구현하는 것은 기획자가 아니다. 기획자는 마에스트로가 되어야지 수석 연주자가 되어서는 안 된다.
개발부서와 공감대를 형성해야 하는 이유
22. 개발부서의 태도는 무조건 배척하는 것이 아니라 수정으로 인한 시스템 오류 가능성을 최소화하고 싶은 것이다.
23. 일단 UI를 그리게 되면, 생각의 틀이 굳어져 더 이상 서비스의 정책과 본질에 관해 집중하기가 어려워진다. 그려놓은 그림에 사로잡혀 중요하지 않은 내용으로 생각이 흘러가게 된다.
24. 좋은 디자인은 심미성보다는 합리적이고 논리적이어야 한다. 왜 이 위치에 이 버튼이 있어야 하는지를 설명하기 위해 기획자의 관점이 들어가 있어야 하고, 그런 관점은 기획자가 UI 설계를 하기 전까지 천천히 쌓아 올린 서비스 방향성과 전략에 대한 구체화 과정에서 만들어진다.
25. 서비스 전략과 프로세스를 고민하고 UI를 그리기 시작했다면 이제 세부적인 내용에 대해 정리를 해야 한다. 워터폴 방법론에서는 화면 설계서 또는 스토리보드라고 불리는 문서가 나오고, 애자일 방법론에서는 사용자 스토리 또는 백로그라는 리스트가 산출물이 된다.
화면 설계서 작성법
26. 화면 설계서 주요 내용
1) 수정 이력 관리: 표 형태로 수정된 날짜와 버전명, 수정 내용, 수정자를 기록한다.
2) 기획의도/KPI: 기획한 서비스의 의도와, 목표, 그리고 이를 측정할 수 있는 과업 목표를 작성한다.
3) 프로세스 플로우 차트: 서비스의 사용자별 혹은 케이스별 프로세스 플로우. 화면적인 구분뿐 아니라 기능이나 데이터적인 로직도 함께 볼 수 있으면 더 좋다.
4) 수정 및 신규 화면 목록(IA), 화면 외 개발 대상: 해당 프로젝트에 포함되어 수정되거나 신규로 개발되는 화면 목록과 API 등 화면이 없는 형태로 개발되는 대상을 적는다.
5) 와이어프레임 또는 목업 인터랙션(케이스별로 별도 노출): 앞 과정에서 그려놓은 와이어프레임을 상황에 따른 노출 케이스별로 상세하게 세분화하여 작성한다.
6) 디스크립션(기능 명세서): 와이어프레임에 숫자를 표시하여 해당 숫자에 해당하는 설명이나 노출 로직, 디자인, 솔루션 사용 등 설명할 수 있는 모든 것을 기입한다.
27. 화면 설계서에서는 우리가 이 문서를 쓰기까지 기획을 하면서 고민하고 결정한 ‘모든 것'을 담아낸다.
28. 프론트 화면에서는 고객의 특징과 상황에 따라 UI가 완전히 바뀌는 경우가 많다. 그래서 한 페이지에서 전체 케이스를 다 설명하기보다는 케이스별로 화면을 그리고 설명하는 것이 바람직하다. 기준이 되는 하나의 케이스를 작성한 다음, 케이스별로 시나리오에 따라 UI가 차이나는 부분을 명확하게 표시해주면 디자인 부서와 개발 부서 모두 그 흐름을 이해할 수 있을 것이다.
29. 화면 설계서는 전방위로 사용되는 커뮤니케이션 문서다. 프로젝트 기간 동안 아마 수십 번은 화면 설계서를 리뷰해야 할 것이다. 만약 지금 작성한 문서에 빠뜨린 부분이 있더라도 리뷰 과정에서 피드백을 받으면서 업데이트해 나갈 수 있다. 처음부터 완벽한 문서를 만들 수는 없다.
사용자 스토리 작성법
30. 애자일 방법론에서 기획자는 PO의 역할을 수행한다. PO란 서비스에 대한 서비스 기준을 마련하는 사람이라는 점에서 기존의 서비스 기획자와 비슷하지만 프로젝트 참여도에서는 한 발 물러서 있는 사람이라고 볼 수 있다.
31. 기존 워터폴 방법론에서는 기획자가 화면 설계서를 작성하면서 세세히 케이스를 나누어 IT 개발자들과 논의를 해가며 개발에서 적용할 로직까지 디스크립션에 녹이지만, PO는 사용자 스토리를 통해 개발자와 디자이너에게 서비스의 대상이 되는 고객이나 UX에 대한 사상, 비즈니스 모델 등 서비스가 가야 할 방향을 숙지시키고 나면 프로젝트가 올바른 방향으로 가는지에 대한 관리와 이슈에 대한 의사결정을 하는 역할에만 집중한다.
32. 기능 정의와 요구사항이 명확한 화면 설계서 방식에 비해 사용자 스토리는 방향성을 더 중시한다.
33. 서비스 기획자가 서비스 콘셉트를 확인시키기 위해 작성해온 프로토타입을 보며 모든 협업자가 규칙에 맞게 사용자 스토리를 작성한다.
34. 사용자 스토리 주요 내용
1) 제목: 10개 어휘 이하
2) 실제 내용
- 사용자: As a (who)
- 사용자의 목적: I want to (Goal)
- 서비스 목표: So that / In order to (Reason)
3) 완성 기준 (Acceptance Criteria)
35. ‘실제 내용'은 가능하면 하나의 문장으로 구성하되 3가지를 포함해야 한다. 사용자는 누구이며, 무엇을 목표로 하고, 이렇게 하도록 하는 비즈니스 이유가 무엇인지가 그것이다.
36. 완성 기준은 나중에 서비스 테스트 시점에서 테스트 케이스를 대체하기도 한다. 완성 기준은 이 서비스를 이용하여 다소 다른 결과가 나오는 케이스를 구분하고, 케이스 구분의 기준에 대한 정책 등을 정의하고 그에 따른 결과를 명시한다.
37. 사용자 스토리는 요구사항 정의서와 비슷해 보이지만 본질적으로는 다르다. 사용자에 대한 페르소나 개념이 포함되고, 서비스의 목표가 그 사용자의 과업이 되며, 마지막으로 비즈니스 모델에서의 목표나 중요성이 포함된다. 주의할 점은 절대로 어떠한 로직으로 그렇게 만들 것인지 UI적인 부분을 고정하여 작성하지 않아야 한다는 것이다.
38. 좋은 사용자 스토리 조건 6가지
1) Independent: 독립적이다.
2) Negotiable: 협상 가능하다.
3) Valuable: 사용자와 비즈니스에 가치가 있다.
4) Estimate: 예측과 측정이 가능하다.
5) Small: 사이즈가 작아야 한다. (2~3주 내 개발 가능)
6) Testable: 테스트가 가능해야 한다.
39. 특정 사용자 스토리가 너무 많은 기능을 포함하고 있을 때는 이를 가장 상위에 놓고 그 하위에 들어갈 사용자 스토리를 모으거나 새로 작성하여 체계를 잡을 수 있다. 사용자 스토리에서 최상단에 놓이는 사용자 스토리를 에픽이라 부르고 하위의 가장 작은 기능 단위로 정의된 항목을 백로그라고 부른다.
40. 사용자 스토리 맵은 지금껏 작성한 사용자 스토리 간의 계층과 관계를 정리하여 실제 스프린트에서 나눌 업무 단위를 산출해내는 방법이다.
41. 팀원들과 함께 다양한 사용자 스토리 맵을 이용하여 사용자 스토리 간 체계를 정리했다면, 이제 기획자는 스프린트 하나에 포함될 사용자 스토리 또는 백로그를 선정해야 한다. 애자일 방법론은 워터폴 방법론과 다르게 여러 개의 스프린트 기간을 거쳐서 개발한다. 이때 PO로서 기획자의 중요한 역할은 여러 개의 스프린트에 적절한 양의 백로그를 배분하는 것이다.
42. 화면 설계서의 디스크립션은 정밀하고 순서를 확실하게 해야 한다. 동작도 쓰고 로직도 써야 한다. 목표도 쓰고 정책도 쓰고 예외조항도 적어줘야 한다. 그래야 개발하는 사람이 정확하게 코딩할 수 있다. 디스크립션이 잘 쓰여 있을 때 우리는 ‘디스크립션 수준이 높다'라고 한다.
협업자에게 리뷰하여 질문을 받기
43. 기획자가 모든 질문을 예상할 수 있다면 좋겠지만, 모르겠다면 빨리 리뷰를 진행해서 이런 질문을 받아내고 답을 찾는 것이 더 명확하게 기획할 수 있는 길이다. 기획자가 생각한 로직이 구현 불가능한 수준이라면 개발자가 다시 이슈를 제기할 것이고, 그때서야 비로소 커뮤니케이션을 통해 더 나은 서비스를 만들 기회와 빠르게 성장할 수 있는 기회도 찾아온다.
44. 기획자가 최대한 머리를 짜내는 것은 예의이고, 이슈가 발견될 때마다 빠르게 정리해서 디스크립션을 업데이트해주고 협업자의 업무를 정리해주는 것은 센스다.
디스크립션의 완성도를 더욱 올리는 방법
45. 정상적이지 않은 예외적인 상황에 대해서 대응할 수 있도록 처리하는 것을 예외처리라고 한다. 기획에서 개발적 예외처리가 필요한 경우 함께 고민하여 화면 설계서에 추가할 수 있다.
46. 분기 처리는 애초에 유형이 여러 가지가 있어서 한 개의 페이지가 유형에 따라 다르게 나와야 하는 경우를 의미한다.
47. 정합성 체크란 데이터 처리에서 규칙에 맞는지를 보는 것을 의미한다. 보통 입력하는 폼이 있는 경우, 숫자가 들어가는 항목에 글자를 넣는다거나 필수적으로 입력해야 하는 항목을 입력하지 않았을 때 이에 대해 체크하여 다음 프로세스로 넘어가지 않도록 확인하는 절차인데, 꼭 막아야 하는 실수에 대해서는 아예 정합성 체크에 대한 기준을 정하여 디자인 요소로 포함시키고 개발에서도 거를 수 있도록 해주는 것이 중요하다.
비주얼 디자인(UI 디자인)의 역할
48. 비주얼 디자인은 상세 서비스의 UI를 서비스에 반영할 수준으로 올리는 작업이다. UI 구성 요소 및 기능은 기획자가 정하지만 실제 서비스에서의 상세한 위치나 움직임 등은 이 작업에서 결정된다.
49. 기획자의 말이 가치 있는 의견이 되려면 세 가지 규칙을 지켜야 한다. 첫째, 주류 사용자의 관점에서 의견을 제시한다. 둘째, 디자인이 아니더라도 기획자가 시안에서 체크해야 할 것은 많다. 셋째, 아직은 성급할 필요가 없다.
50. 서비스 기획자가 디자이너와 발전적인 협업 관계를 유지하려면 디자인보다 서비스를 잘 알아야 한다. 하나의 UI라도 전체 서비스 맥락에서 잘 흘러가는지 봐야 한다. 때문에 포토샵 기술이나 인터랙션 모음집보다 다양한 서비스를 써보면서 그 UI가 전체 서비스 프로세스에서 적절한 역할을 하는지를 보는 것이 더 중요하다. 어설프게 디자인에 대해 아는 척한다면 디자이너 입장에서는 기획자 또한 ‘개나 소나'가 되어버린다.
협업자에 맞춘 기획 리뷰하기
51. 기획 내용을 말했다고 해도 전달되지 않았으면 그것은 말하지 않은 것과 같다. 협업이란 참여하고 싶은 마음이 들도록 해야 하는 것이고, 그들이 나와 같은 생각을 갖도록 계속 확인하고 노력하는 것도 협업에 있어서는 굉장히 중요한 부분이다.
52. 협업자들에게 처음으로 리뷰를 할 때 두 가지만 명심하자. 첫째, 디자이너와 개발자는 지금 처음으로 기획안을 듣는다는 사실이다. 둘째, 디자이너와 개발자의 관심사는 다르다는 점이다.
53. 기획자는 협업자들과의 회의에서 MC가 되어야 한다. 리뷰는 결국 계속 듣고 싶은 즐거운 회의가 되어야 한다. 나는 이것이 프로젝트 리더십의 시작이라고 생각한다.
54. 협업자에게 리뷰를 할 때는 두 단계로 나누어하는 것이 좋다. 먼저 개발, 디자인을 포함한 모든 협업자가 이 프로젝트에 대한 집중력이 낮은 상태라면 일단 단합할 수 있도록 해당 프로젝트의 중요성을 설명하는 자리를 만들어서 함께 참여하는 시간을 갖는다.
55. 두 번째로 화면 설계서든 요구사항 정의서든 개발자 혹은 디자이너가 알고 싶어 하는 내용들만 쏙쏙 뽑아 각각의 버전을 만들어 업무별로 따로 리뷰를 진행하고 관심사에 대한 논의를 깊이 진행하는 것이다.
코딩 책 들여다보지 말고 내 옆의 개발자에게 묻자
56. 개발 구현을 고려하지 않은 기획은 밑그림에 지나지 않는다. 즉 자사 시스템에 어떤 데이터가 들어있고 어떤 로직으로 움직이는지를 알 수록 더 좋은 기획이 나온다.
배우고자 하는 태도가 최고의 역량
57. 모르는 건 죄가 아니다. 하지만 모르는 용어를 듣고도 왜 사용됐는지 고민해보지 않는다면 그건 잘못이다. 기획자는 누구보다 프로젝트 대상에 관심이 있어야 하고, 항상 신경을 써야 하는 직무임을 잊지 말자. 진짜 기획자에 필요한 역량은 ‘이슈 상황을 이해하고 해결책을 고민하는 방법을 아는 것'이다. 그걸 누군가는 ‘문제 해결력'이라고 하고 누군가는 ‘일 센스가 있다'고도 한다. 그러니까 개발 기술보다 기획자 본연의 근본적 질문에 더 많은 고민의 시간을 갖는 것이 기획자로서의 성장에 더 도움이 되는 것이다.
58. 테스트의 목적은 오류를 찾아내는 것이 아니라 오류를 해결하는 것이다. 그리고 서비스 기획자로서 개발자에게 오류를 해결토록 하려면 두 가지 절차가 필요하다.
1) 오류가 발생하는 케이스가 재현될 수 있도록 정확하게 개발자에게 공유하기.
2) 오류 상황에 대한 원인을 함께 이해하고 적절한 산출물을 정의하거나 한계가 있다면 대안을 빠르게 제공하기.
위 두 가지 절차 중에서 기획자는 두 번째에 더 많은 신경을 써야 한다. 개발을 해보니 구조적으로 불가능한 부분이나 예상했던 것보다 불편한 점, 혹은 생각조차 못해본 케이스의 출현 등등 갑자기 등장하는 예측 불가능한 사건들에 대해 기획을 추가하거나 제외하면서 서비스의 완성도를 높여가야 하는 것이다.
테스트로 키워지는 기획력
59. 시스템은 정책 문서로만 이해하기는 어렵다. 시스템을 파악하려면 많이 사용해볼 수밖에 없는데, 이때 테스트 기간이 있으면 인위적으로 시스템을 사용해봄으로써 시스템에 대한 이해도를 높일 수 있다. 게다가 신규 서비스에 대한 테스트라면 누구보다도 신규 시스템을 잘 이해할 수 있는 계기가 될 수 있다.
60. 서비스 기획을 잘하는 가장 좋은 학습 방법은 스토리보드 연습이 아니라 테스트를 하나하나 해보고 이해하는 것이다. 모든 테스트를 신경 써서 집중한다면 어떤 교육보다 빠르게 배울 수 있다.
61. 테스트 케이스는 의도한 동작이 여러 조건에서 어떻게 나타나는지 세세하게 정의된 것들을 확인하는 작업이 되고, 만약 부족하면 추가로 기획 작업이 이루어지기도 한다. 테스트하다 보면 평소 인지하지 못한 케이스에 대해 경험이 쌓이고 그 경험이 다음 기획이나 테스트를 할 때 디테일을 챙길 수 있는 능력으로 나타난다.
아무리 테스트를 잘해도 빠지는 부분은 있다
62. 최대한 스트레스를 안 받는 테스트가 되려면 어떤 마음가짐을 가져야 할까? 첫째, 테스트가 기획을 보강할 기회임을 인정하되 오픈에 대한 최소 기준을 정의한다. 테스터 케이스를 유사한 것끼리 묶어 저장해 두고 다음 기획 시 참고 자료로 사용하기 위한 과정으로 생각한다.
63. 테스트는 지겹다. 그런데 그 기간이 지루하게 길다는 건 그만큼 시스템을 디테일하게 경험할 기회가 많다는 뜻이기도 하다.
서비스의 탄생
서비스 이용 교육 또한 기획자의 일
64. 사용 매뉴얼을 작성할 때는 몇 가지 원칙을 지켜서 만든다.
1) 매뉴얼 대상을 파악한다: 팀이나 직무, 역할에 따라 매뉴얼이 구분될 수 있다.
2) 이용 순서와 설명 순서를 일치시킨다: 번호만으로 따라 할 수 있도록 구성한다.
3) FAQ를 만들어 마지막에 넣어라: 오픈 후 예민한 시기에 전화를 피하려면 최대한 모든 질문을 예상하여 넣어둔다.
4) 오픈 콘텐츠 등록 일정을 확인시켜라: 오픈 일자 전에 정상적으로 콘텐츠를 수급하고 채워 넣을 수 있게 일정을 관리한다.
65. 오픈하고 나면 끝인 듯싶지만 기획자 관점에서는 시작에 가깝다. 우리가 적용한 가설이 맞는지 검토하고 새로운 교훈을 얻어야 한다. 즉 ‘성찰'이 필요하다.
66. 정말 필요한 데이터는 1차 데이터가 아니라 특정한 생각을 가지고 추론하여 만들어진 2차, 3차 가공 데이터이다. 그런 데이터를 얻으려면 일정기간 동일한 기준의 데이터를 수집해두는 것이 필요하다. 그래야 오픈 전후의 차이를 확인하는 등 여러 방면으로 활용할 수 있다. 이런 성찰 과정은 서비스 방향성을 판단하는 데도 중요하고 앞으로의 서비스 개선을 위해서도 중요하다.
서비스 개선에 대한 의견을 제시할 때
67. 비난과 의견은 한 끗 차이다. 기획자가 서비스 개선에 대한 의견을 제시할 때는 절차가 필요하다. 특히 주니어 기획자라면 어딘가 있을 해당 서비스를 최초로 기획한 ‘엄마 기획자'들의 이유부터 들어볼 필요가 있다.
68. 제대로 된 서비스 개선 의견은 어떻게 내야 할까? 첫째, 먼저 기준을 설정해야 한다. 둘째, 히스토리 파악도 중요하다.
69. 히스토리를 알면 진짜 대안을 고민해볼 수 있다. 조건 없는 문제 해결은 존재하지 않기 때문이다. 사실 운영 기획에서는 개인의 능력보다 서비스의 히스토리를 얼마나 알고 있는가가 더 중요하다. 히스토리란 정책과 배경, 시스템적 한계, 사내 입장 차이로 인한 논쟁까지 포함된다. 비합리적으로 보이는 서비스도 탄생 과정을 알고 나면 오히려 그것이 합리적인 선택이었음을 알게 될 수도 있다. 히스토리를 고려하지 않은 의견이 인정받기 어려운 이유는 바로 여기에 있다.
