7. 수많은 백로그들 사이에서 긴급한 것과 그렇지 않은 것을 구분하는 우리만의 방법이 필요했다.
MoSCoW 방법은 이렇게 네가지 기준으로 우선순위를 결정해서 백로그를 관리하는 방식이다. 중요한 일과 긴급한 일을 빨리 구분할 수 있다는 점에서 유용하다.
1)Must have(이 기능을 빼고는 서비스 운영을 생각하기 어려운)
2)Should have(우선순위는 높지만 당장 서비스에 영향은 없는)
3)Could have(여유가 있을 때 시도해볼 수 있는, 적용하면 서비스를 더 좋게 만드는)
4)Will not have(중요도가 낮고, 효과가 미미한)
(p.106)
8. 인턴 시절, 나에게 일을 가르쳐준 사수는 제안서 작성을 할 때 문서부터 생성 하지 말라고 했다. 문서가 열리는 순간, 무언가 작성하고 채워야 한다는 강박감이 생길 수 있다는 이유에서였다.
문서를 생성하게 되면 순간 무언가 형식에 맞춰 써야 한다는 생각이 앞서게 되고 디자인 작업을 하는 등 당장 필요 없는 일에 시간을 뺏기게 된다. 문서의 핵심은 포멧이나 디자인이 아니라 나와 우리가 하고자 하는 이야기를 최종적으로 써내려 가는 공간임을 잊어서는 안 된다. (p.120)
9. 주니어 멘토링 프로그램에 참여하면서 가장 많이 듣게 되는 질문 역시 커뮤니케이션 관련이다. 그중에서도 동시다발적으로 이뤄지는 개인 간 커뮤니케이션에 관한 내용이 많다.
1:1 대화 자체를 피해야 한다는 이야기는 아니다. 하지만 1:1 커뮤니케이션에도 일정한 기준이 필요하며, 그 기준은 철저히 ‘팀과 프로젝트의 관점에서’ 생성되어야 한다.
공유되지 않은 상황에서 누군가 “지난번 논의 때 이렇게 결정하지 않았어요?”라고 말하게 되면, 그 순간 모든 책임은 기획자 한 명에게 쏠리게 된다. 기획자는 이런 일이 발생하지 않도록 조정하는 것도 주요 업무라는 것을 잊어서는 안 된다. (p.134)
10. 기능 업데이트를 한 앱의 경우, 알림을 받자마자 화면과 기능이 어떻게 보완되었는지부터 확인한다. 이때 업데이트 의도를 생각하는 것 자체가 공부가 된다.
동일 기능을 우리 서비스에 적용하면 어떻게 될지 미리 고민해 보는 것도 빼놓지 말아야 한다.
다음과 같은 질문도 중요하다.
1)해당 기능을 업데이트/개선한 이유는?(어떤 맥락과 의도에 따라 기능이 개선되었는지 파악)
2)동일한 기능을 우리 서비스에 적용한다면?(우리에게 맞는 방법은 무엇인지 파악)
3)유사한 기능과 서비스가 있다면?(같은 맥락에서 살펴볼 수 있는 서비스와 기능 파악)
(p.152)
11. 글 쓰는 이유를 너무 거창하게 잡거나 혹은 너무 많은 의미 부여를 할 필요는 없다. 오히려 무슨 주제로 할 때 가장 오래 쓸 수 있는지 고민하는 것이 더 중요하다.
어떤 소재로 써야 할지 모르겠다면 두 가지 방법을 추천하고 싶다. 하나는 나의 취미나 관심사를 써보는 것이고, 또 하나는 일에서 경험하고 배운 점을 써보는 것이다. (p.170)
12. 업무 요청에 대해 거절을 하지 못하는 이유 중 하나는 ‘경험’이라는 유혹 때문이다(경험이 도움이 될 거야, 라며 자기 일을 떠 넘기는 선배들 혹은 타 부서 사람들이 꼭 있다). 내가 생각하지 못한 것을 누군가 제안해준다면 이 일로 인해 나의 경험치는 일정 정도 쌓이겠지만 경험이 될거야, 라는 말만 믿고 덥석 일을 받아서는 안 된다. 몇가지 조건이 추가되어야 한다. (p.182)
13. 질문을 할 때는 매우 구체적으로 하는 것이 중요하다. 너무 두리뭉실하게 질문하면, 질문의 의도가 무엇이냐고 물어올 때도 있다. 질문이 질문으로 이어지는 상황은 불필요한 커뮤니케이션을 만들고, 본질에서 벗어나는 상황을 만든다.
“회원가입 전환율을 늘릴 방법은 무엇일까요?”라고 묻는 것보다 “우리가 지난 분기 진행했던 가입 전환과 리텐션에 좋은 결과를 얻은 이벤트와 유사한 다른 건 또 없을까요?” 이렇게 질문하는 것이 더 낫다. (p.192)
14. 일을 잘하는 사람들의 공통적인 특징은 이 일을 왜 해야 하는지 명확한 근거를 갖고 있다는 점이다.
그런데 주관적인 근거로는 다른 사람을 설득하기 어렵다. 공통의 기준이라 할 수 있는 자료나 데이터 등으로 ‘왜?’라는 질문에 답해야 한다. 그리고 이를 공유해야 한다. 그래야 동료들 역시 같은 기준에서 반박하거나 다른 의견을 제시할 수 있다.
팀의 문화에 따라 다를 수 있지만, 나는 가급적 ‘공통의 기준’을 만들어 그 범위 내에서 의견을 내도록 한다. 기준은 우리가 나아가고자 하는 방향이고, 어떤 데이터와 지표에 초점을 맞춰 커뮤니케이션할 지에 관한 내용이다. (p.198)
15. 종종 기획자는 어떤 일을 하느냐는 질문을 받을 때, 계주의 첫 번째 주자와 같다고 말한다.
그런데 내차례의 달리기가 끝났다고 해서 모든 일이 끝난 것처럼 행동하는 기획자가 있다. 나도 처음에는 그랬다. 다음 주자, 또 그다음 주자가 어떻게 달리는지는 신경 쓰지 않았다.
기획은 프로젝트의 끝이 될 수 없기 때문에 함께 일하는 사람(개발자, 운영자, 디자이너 등)이 어떻게 다음 단계로 진입하는지, 무슨 어려움을 겪고 있는지 등을 알고 있어야 한다.
함께 일하는 사람에게 집중하며 미리 준비해야 할 것은 무엇인지, 나로 시작한 출발이 잘못되지 않으려면 어떤 도움을 주어야 하는지 계속 챙겨야 하는 것이 기획자다. (p.201)
* 이 글을 쓴 한성규 작가는 “지금 써보러 갑니다” 미디어 블로그와 “팁스터” 메일링 서비스를 운영하고 있으며, 10년 차 IT 기획자로 활동하고 있다. 여러 스타트업을 거쳐 현재는 키노라이츠의 프로덕트 매니저로 일하고 있다.
좋은습관연구소 