설탕빵의 설탕공방진짜루,
아이디어만 일주일 생각해내고 나온거?
응 시장조사로 바사삭
우리 개발자는 보통 기술적 욕구로 프로젝트를 시작한다.
하지만 좋은 기획은 기술이 아닌 문제에서 나온다
내가 바로 겪고 있는 문제에서부터 해결을 하고자 하는게 바로 아이디어다.
다들 알고있는 내용이고,
아무튼 기획에 대한 부족함을 느껴서 요즘 책을 읽어보고 있다.
현재 읽어보는건 "10년 차 IT 기획자의 노트"이다
챕터가 노트의 종류로 구분이 되어있으며
오늘 소개하고자 하는 노트는 '스펙 노트'와 '리뷰 노트'이다.
스펙 노트: 프로젝트의 시작
시장을 보고, 고객을 보다 보면 가능성이 보인다.
이 가능성을 우리는 아이디어라고 한다.
아이디어가 오는 순간에는 다음의 내용을 담은 제안서를 작성한다.
우리가 이 서비스를 구축해야 하는 이유
서비스를 통해 달성할 수 있는 목표
기존 서비스와의 연관성과 기회 등
개발자가 부족한 부분이 위 기본적인 사항에 대한 디테일이다.
하지만 아쉽게도 이번에는 해당 내용이 아닌 다른 내용을 다루고자 한다.
바로 팀원 설득이다.
프로젝트는 혼자 하는 것이 아니기 떄문에 팀원들에 대한 설득이 진행되어야 한다.
즉 제안서란 타인의 관점으로 평가 되는 것이고,
집단이라는 구조 속에서 현실적으로 소화 가능한 기획안이 되어야 한다.
이 순간 바로 스펙 노트가 등장한다.
스펙 노트는 프로젝트 단위로 목표, 주요 기능, 개발 범위, 담당 인원 등이 담긴 일종의 가이드 문서다.
스펙으로는 필요한 기능이 들어가고, 필요한 이유와 담당자를 지정한다.
우리 단계에서는 담당자를 좀 더 쉽게 지정해도 되지만,
실무에서는 담당자가 해당 일만 하는게 아니기 때문에 공수에 대해서 좀 더 세밀한 측정이 필요하기 떄문이다.
핵심 기능, 필요 이유, 담당자를 묶음으로 기능들을 정리하면,
각 기능들에 대해서 론칭 기준으로 현실적인 공수를 계산하고
각 담당자들을 통해 우려 되는 문제나 이슈에 대해서 공유 받는다.
예를 들어 '자주 묻는 질문'이 구체적으로 제공되지 않으면,
1:1 문의 증가로 운영팀의 업무 과부화로 이어지는데,
이를 방지하고자 관리자 페이지 내 FAQ 관리 메뉴가 필요한 등...
서비스 운영까지 고려해 아이디어 구현의 현실성을 올리기 위해서다.
저자는 이러한 과정을 통해 다음의 인사이트를 얻었다.
새로운 일에 대한 설득은 '왜'보다 '어떻게'가 동료의 부담을 줄인다.
신규 프로젝트 논의에 동료들이 자발적 참여하도록 하는 방법을 갖고 있어야 한다.
팀의 상황을 고려해 업무 분배와 일정 산정이 이뤄져야한다.
먼저 우리 상황을 따지자면, 초반에 아이디어에 대한 확정이 어려웠던 이유 중 하나는 아이디어는 제시하지만 어떻게가 없었기 때문이다.
듣는 입장에서는 아이디어가 그려지지 않으면서 평가가 안되는 것이다.
또한 동료들의 자발적 참여 유도도 어려웠기 때문에 소수의 의견에 휩쓸리며 건실한 교환이 어려웠다.
결국 프로젝트란 팀이 전부기 때문에,
동료로부터 왜?가 아닌 어떻게를 통해 우리의 방향성을 통일하는 것이 중요한 것 같다.
다시 저자의 스펙 노트를 정리하면 다음과 같다.
우리가 만들고자 하는 기능
해결하고자 하는 문제
해결을 위해 꼭 필요한 기능
기능에 대한 간략한 소개
세부 실행 방안
담당 인원과 예상 일정
규모와 상관없이 기획자에게 주어진 중요한 역할 중 하나는 일이 진행되도록 하는 것이며 핵심은 내부 동료를 설득하는 것이다.
기획자이자 PM으로 상황에 맞게, 업무를 잘 할당하는 것도 중요하지만, 더 중요했던 것은 프로젝트에 참여하는 멤버들이 자신의 상황에 맞춰 그 다음을 예측할 수 있도록 충분한 시간을 주는 것이다.
리뷰 노트: 유사/경쟁 서비스 분석 방법
아마 우리가 가장 대충하면서 가장 희망회로를 돌리는 부분이 아닐까
저자가 기획자로써의 성장을 위해 사용하는 방식은
서비스의 시작과 끝, 그 사이의 변화를 오랫동안 목격하면서 이를 기록에 남기는 것이다.
저자는 앱 리뷰를 할 때, 기존 앱에서 기능 개선 등의 이유로 업데이트 되는 앱, 처음 출시되는 앱 두 가지로 구분 지어 분석을 한다.
기능 업데이트 경우 화면과 기능이 어떻게 보완되었는지부터 확인한다.
이때 업데이트 의도를 생각하는 것 자체가 공부가 된다.
또한 동일 기능을 우리 서비스에 적용하면 어떻게 될지 미리 고민해 보는 것도 중요하다.
정리하자면 다음과 같다.
해당 기능을 업데이트/개선한 이유는?
동일한 기능을 우리 서비스에 적용한다면?
유사한 기능과 서비스가 있다면?
새로 론칭되는 앱의 경우 사용자의 어떤 불편함을 해결하려는 것인지 살핀다.
문제 해결의 핵심을 어떻게 잡고 있는지도 중요하게 본다.
그래서 해결하고자 하는 문제와 핵심 기능 그리고 실제 첫 사용시 느낀 사용성을 묻고 답하기를 해본다.
정리하자면 다음과 같다.
서비스가 해결하고자 하는 문제는?
문제 해결을 위한 핵심 기능은?
실제 써본 느낌은?
이제 리뷰 노트 작성법을 소개하겠다.
앱 리뷰가 쌓이다는 것은 앞으로 우리가 만들 서비스에 디테일한 레퍼런스가 쌓이다는 것이다.
저자는 서비스 이름과 버전 그리고 기능 이름 등을 태그로 달아 관리했는데,
나중에 회원가입 기능을 개선해야 할 일이 있을 때, 해당 태그를 달았던 사례만 살펴볼 수 있어 최신 사례나 타사 사례를 빠르게 확인 할 수 있다.
또한 동일 기능을 두고서 겪은 시행착오도 중요하다.
명확한 의도와 근거를 바탕으로 진행되었는지,
해당 기능을 개선하면서 부족하다고 생각한 점은 없는지,
배포 후 어떤 지표 변화(중요함, 피드백 시스템)가 있었는지 등을 작성한다.
이런 식으로 정리된 노트는 특정 기능을 기획할 때 아주 중요하다.
중요한 골자는 성공한 서비스의 기획 의도를 역추적 하고,
추후 내 레퍼런스로 사용한다는 것이다.
정해진 포멧이 없기에 자신만의 리뷰 노트를 만들기를 추천한다.