[목 차]

1부. 기록과 정리 그리고 회고

1. 시간 관리 - 일의 순서를 통제하는 법
: 할 일을 구분하고 구체적인 시간 할당까지 미리 해두는 이유는?

2. 배움 노트 - 배움을 구체화하는 법
: 실패를 배움으로 만드는 데 필요한 자세는?

3. 데이터 분석 - 기획자의 데이터 분석 루틴
: 데이터가 의사결정의 전부가 될 수 없는 이유는?

4. 인터뷰와 대화 - 기획자로서 신뢰를 얻는 소통법
: 프로젝트 성공을 위해 가장 신경 써야 할 것은?

5. 업무 리스트 - 필요한 일을 주도적으로 찾는 법
: 왜 내가 아니라 팀에게 필요한 일을 찾아야 하는가?

6. 스펙 노트 - 프로젝트 시작을 잘하는 법
: 동료의 공감을 이끌어 내는 방법은?

7. 운영 매뉴얼 - 나 없이도 서비스가 돌아가는 법
: 서비스 론칭 전 반드시 해야 할 일은?

8. 기능 가이드 - 서비스 기능 변경이나 업데이트를 잘하는 법
: 기능 업데이트 라이브 전 반드시 챙겨야 할 것은?

9. 변수 통제 - 실수를 줄이는 법
: 기획자의 작은 실수가 개발자나 디자이너의 실수보다 더 치명적인 이유는?

10. 공유 - 해야 할 일을 정하고, 정보와 지식을 관리하는 법
: 같이 성장하고자 할 때 잊지 않고 해야 할 일은?

11. 회고 - 더 나아짐에 목표를 둔 회고
: 우리에게 잘 맞는 회고 방법은?

12. 제안서 - 제안서 작성이 쉬워지는 법
: 제안서 작성을 시작할 때 빈 문서부터 생성하면 안 되는 이유는?

13. 커뮤니케이션 - 혼란을 초래하지 않는 커뮤니케이션
: 1:1 커뮤니케이션을 지양해야 하는 이유는?

2부. 기획자의 성장 도구

14. 사이드 프로젝트 - 성장의 갈증을 없애는 방법
: 사이드 프로젝트를 할 때 주의해야 할 점은?

15. 리뷰 노트 - 유사/경쟁 서비스 분석 방법
: 앱 리뷰를 할 때 반드시 해야 하는 질문은?

16. 동기부여 - 슬럼프와 번아웃을 이겨내는 법
: 나에게 온전히 집중하는 것이 중요한 이유는?

17. 글쓰기 - 글쓰기를 꾸준히 하는 법
: 왜 글쓰기가 기획 업무에 도움을 줄까?

18. 피드백 노트 - 피드백을 잘 활용하는 법
: 피드백을 무조건 받아들이면 안 되는 이유는?

19. 거절 - 기분 나쁘지 않게 거절하는 법
: 거절이 상대에게 오히려 도움이 되는 이유는?

20. 질문 - 좋은 질문을 하는 법
: 기획자라면 반드시 해야 하는 질문은?

[본 문]

이 책은 IT 분야의 기획자와 PM으로 일해온 나의 솔직한 기록으로 나와 유사한 업무를 하는 사람들이 일의 흐름을 익히고 그 과정에서 무슨 기록과 정리를 남길 수 있으며, 실제로 어떤 도움을 얻을 수 있는지 설명하는 책이다. 한마디로 IT 기획자로 일 잘하는 방법과 IT 기획자로 성장하는 방법을 담았다. (6쪽)

사무실을 정리하며 팀원들과 틈틈이 작성한 《배움 노트》를 다시 펼쳤다. 빼곡히 적힌 우리의 배움이 꽤 많다는 생각이 들었다. 새로운 페이지에 ‘만약에’로 시작하는 가정들을 하나씩 적고, 다른 색으로 ‘다음에는’이라는 말을 이어 붙였다. 뒤늦은 성찰 같기도 했지만, 그렇게 마무리하는 것이 스스로를 향한 최선과 위안이었다. (51쪽)

가설은 우리가 어디에 초점을 맞춰 데이터를 확인해야 하는지, 그리고 잘했는지 아니면 개선이 필요한지 등을 판단하 중요한 기준이 된다. 즉, 가설을 확인하기 위한 데이터 수집과 무턱대고 데이터를 열어보는 것 사이에는 확연한 차이가 발생한다. - 중략 - 같은 지표를 두고서도 디자이너는 이건 정말 중요한 역할을 할 거야! 라고 말하는가 하면, 개발자는 그건 의미가 없고 시간 낭비다, 라고 말하기도 했다. 서로 다른 가설을 조율할 방법은 그렇게 생각한 ‘이유’를 가지고서 상대를 설득하는 수밖에 없었다. (58쪽)

스타트업에서 일하는 주니어(부사수)들이 입사 초반에 늘 는 질문 중 하나가 “뭘 하면 좋을까요?”이다. 무언가 하고 싶고, 보여주고 싶은데 어디서부터 어떻게 시작해야 하는지 모를 때 나오는 마음의 소리이다. 그럴 때면 나는 위의 경험을 들려주고, 일정 기간 이상 근무했다면 팀이 지금 무엇을 하고 있고 무엇을 예정하고 있는지부터 살펴보라고 말한다. 그리고 일의 방향성과 기획 방법을 점검하는 것도 좋다고 말해준다. 주도적으로 일을 찾아 진행한다는 것은 결국 팀과 나를 잘 이해하는 것에서부터 출발하기 때문이다. (75쪽)

프로젝트 진행을 통해 내가 배운 것들을 정리해 보면 다음과 같다. 1)새로운 일에 대한 설득은 ‘왜’보다 ‘어떻게’가 동료의 부담을 줄일 수 있는 방법이다. 2)신규 프로젝트 논의에 동료들이 자발적으로 참여하도록 하는 방법을 갖고 있어야 한다. 3)팀과 회사의 상황을 고려해 업무 분배와 일정 산정이 이뤄져야 한다. 이중에서도 프로젝트 진행 시 ‘왜?’에 머물지 않고 동료의 현재 상황을 고려, ‘어떻게?’에 맞춰 이야기를 진행할 때 동료로부터 지지를 얻을 수 있다는 것이 가장 크게 배운 점이었다. (80쪽)

정리해보면 이렇다. 3단 콤보 같은 건데, 먼저 프로젝트 시작에 맞춰 《스펙 노트》(1단)를 작성한다. 여기에는 기획 배경과 필요한 기능, 담당자 등을 포함한다. 기술적 문의가 필요한 경우 담당자를 빠르게 찾고, 배경 등을 확인하는 역할을 한다. 프로젝트가 론칭 되면 《운영 매뉴얼》(2단)을 통해 사용자 문의 등 운영에 필요한 정보를 확인하고 빠르게 대응하는 데 활용한다. 초기 발생하는 이슈 등도 주기적으로 업데이트 되도록 관리한다. 이후 기능 단위의 개선이 이뤄지면 《기능 가이드》(3단)를 통해 언제 어떤 기능이 적용되며 업무별 참고해야 할 내용은 무엇인지 등을 전체 인원이 확인할 있도록 한다. (92쪽)

가장 먼저, 수많은 백로그들 사이에서 긴급한 것과 그렇지 않은 것을 구분하는 우리만의 방법이 필요했다. 검색을 통해 몇 가지 방법론을 찾았다.
MoSCoW 방법은 1)Must have(이 기능을 빼고는 서비스 운영을 생각하기 어려운) 2)Should have(우선순위는 높지만 당장 서비스에 영향은 없는) 3)Could have(여유가 있을 때 시도해볼 수 있는, 적용하면 서비스를 더 좋게 만드는) 4)Will not have(중요도가 낮고, 효과가 미미한) 이렇게 네가지 기준으로 우선순위를 결정하는 방식이다. 중요한 일과 긴급한 일을 빨리 구분할 수 있다는 점에서 유용하다. (106쪽)

인턴 시절, 나에게 일을 가르쳐준 사수는 문서부터 생성 하지 말라고 했다. 문서가 열리는 순간, 무언가 작성하고 채워야 한다는 강박감이 생길 수 있다는 이유에서였다.
문서를 생성하게 되면 순간 무언가 형식에 맞춰 써야 한다는 생각이 앞서게 되고 디자인 작업을 하는 등 당장 필요 없는 일에 시간을 뺏기게 된다. 문서의 핵심은 포멧이나 디자인이 아니라 나와 우리가 하고자 하는 이야기를 최종적으로 써내려 가는 공간임을 잊어서는 안 된다. (120쪽)

주니어 멘토링 프로그램에 참여하면서 가장 많이 듣게 되는 질문 역시 커뮤니케이션 관련이다. 그중에서도 동시다발적으로 이뤄지는 개인 간 커뮤니케이션에 관한 내용이 많다. 1:1 대화 자체를 피해야 한다는 이야기는 아니다. 하지만 1:1 커뮤니케이션에도 일정한 기준이 필요하며, 그 기준은 철저히 ‘팀과 프로젝트의 관점에서’ 생성되어야 한다. - 중략 - 공유되지 않은 상황에서 누군가 “지난번 논의 때 이렇게 결정하지 않았어요?”라고 말하게 되면, 그 순간 모든 책임은 기획자 한 명에게 쏠리게 된다. 기획자는 이런 일이 발생하지 않도록 조정하는 것도 주요 업무라는 것을 잊어서는 안 된다. (134쪽)

먼저 기능 업데이트를 한 앱의 경우, 알림을 받자마자 화면과 기능이 어떻게 보완되었는지부터 확인한다. 이때 업데이트 의도를 생각하는 것 자체가 공부가 된다. 동일 기능을 우리 서비스에 적용하면 어떻게 될지 미리 고민해 보는 것도 빼놓지 말아야 한다. 그리고 다음과 같은 질문도 중요하다. 1)해당 기능을 업데이트/개선한 이유는?(어떤 맥락과 의도에 따라 기능이 개선되었는지 파악) 2)동일한 기능을 우리 서비스에 적용한다면?(우리에게 맞는 방법은 무엇인지 파악) 3)유사한 기능과 서비스가 있다면?(같은 맥락에서 살펴볼 수 있는 서비스와 기능 파악) (152쪽)

글 쓰는 이유를 너무 거창하게 잡거나 혹은 너무 많은 의미 부여를 할 필요는 없다(욕심은 이른 포기를 낳는다). 그런 것이 많아지면 오히려 금방 지치게 된다. 오히려 무슨 주제로 할 때 가장 오래 쓸 수 있는지 고민하는 것이 더 중요하다.
어떤 소재로 써야 할지 모르겠다면 두 가지 방법을 추천하고 싶다. 하나는 나의 취미나 관심사를 써보는 것이고, 또 하나는 일에서 경험하고 배운 점을 써보는 것이다. (170쪽)

업무 요청에 대해 거절을 하지 못하는 이유 중 하나는 ‘경험’이라는 유혹 때문이다(경험이 도움이 될 거야, 라며 자기 일을 떠 넘기는 선배들 혹은 타 부서 사람들이 꼭 있다). 내가 생각하지 못한 것을 누군가 제안해준다면 이 일로 인해 나의 경험치는 일정 정도 쌓이겠지만 경험이 될거야, 라는 말만 믿고 덥석 일을 받아서는 안 된다. 몇가지 조건이 추가되어야 한다. (182쪽)

질문을 할 때는 매우 구체적으로 하는 것이 중요하다. 너무 두리뭉실하게 질문하면, 질문의 의도가 무엇이냐고 물어올 때도 있다. 질문이 질문으로 이어지는 상황은 불필요한 커뮤니케이션을 만들고, 본질에서 벗어나는 상황을 만든다. 그래서 “회원가입 전환율을 늘릴 방법은 무엇일까요?”라고 묻는 것보다 “우리가 지난 분기 진행했던 가입 전환과 리텐션에 좋은 결과를 얻은 이벤트와 유사한 다른 건 또 없을까요?” 이렇게 질문하는 것이 더 낫다. (192쪽)

일을 잘하는 사람들의 공통적인 특징은 이 일을 왜 해야 하는지 명확한 근거를 갖고 있다는 점이다. 그런데 주관적인 근거로는 자신을 설득할 수는 있겠지만 다른 사람을 설득하기에는 어렵다.
공통의 기준이라 할 수 있는 자료나 데이터 등으로 ‘왜?’라는 질문에 답해야 한다. 그리고 이를 공유해야 한다. 그래야 료들 역시 같은 기준에서 반박하거나 다른 의견을 제시할 수 있다. 팀의 문화에 따라 다를 수 있지만, 나는 가급적 ‘공통의 기준’을 만들어 그 범위 내에서 의견을 내도록 한다. 기준은 우리가 나아가고자 하는 방향이고, 어떤 데이터와 지표에 초점을 맞춰 커뮤니케이션할 지에 관한 내용이다. (198쪽)

종종 기획자는 어떤 일을 하느냐는 질문을 받을 때, 계주의 첫 번째 주자와 같다고 말한다. 모두가 같이 뛰는 경기지만 기획자는 가장 먼저 뛰는 첫 주자에 해당한다. 그런데 내차례의 달리기가 끝났다고 해서 모든 일이 끝난 것처럼 행동하는 기획자가 있다. 나도 처음에는 그랬다. 다음 주자, 또 그다음 주자가 어떻게 달리는지는 신경 쓰지 않았다.
기획은 프로젝트의 끝이 될 수 없기 때문에 함께 일하는 사람(개발자, 운영자, 디자이너 등)이 어떻게 다음 단계로 진입하는지, 무슨 어려움을 겪고 있는지 등을 알고 있어야 한다. 함께 일하는 사람에게 집중하며 미리 준비해야 할 것은 무엇인지, 나로 시작한 출발이 잘못되지 않으려면 어떤 도움을 주어야 하는지 계속 챙겨야 하는 것이 기획자다. (201쪽)

백지에서 창조하는 ‘예술’이라고 생각했던 IT 기획이 정답에 가장 가까운 의사결정이 연속된 ‘챌린지’ 였음을 알게 되었다. 함께 길을 걷는 후배와 동료에게 쥐여줄 사례와 성장 경험으로 풀어낸 똑똑한 기획 방법론이다. 크고 작은 문제를 만나 잠시 성장이 멈췄을 때 작은 습관부터 바꿔 줄 가이드를 만났다.
- InBody 전 UX 리드, 현 상무이사 장원영

이 책은 노하우만 정리된 단순한 안내서가 아니다. IT 기획자로 시작한 순간부터 지금에 이르기까지, 치열한 고민과 시행착오가 고스란히 담긴 성장기다. IT 기획자의 역할이 궁금한 분, 그 경험을 간접 체험하며 성장하고 싶은 사람들에게 추천한다.
- 마이리얼트립 안드로이드 Contents & Platform 개발팀 팀장 한호

스타트업에서 혼란을 겪고 있을 주니어 기획자를 위한 필수 지침서! 도전으로 가득한 스타트업 환경에서 한 줄기 등불이 되어줄 책이다. 저자의 경험과 노하우가 이제 막 기획 업무를 시작한 분들에게 큰 도움을 줄 것이다.
- 오지큐 사업본부장 최장원