서비스가 망할 것 같아서 급하게 쓰는 메이커로그(1편)
기획 회의 후 4개월 째 정체된 <두렁두렁> 심폐소생 과정을 기록합니다.
[목차]
- (배경) 온보딩 2주, 기획 1개월, 그리고 정체된 3개월
- 프로젝트 시작 4개월차, 뒤늦은 점검 시작
- 그래서, 이것을 어떻게 해결했냐?
- 결론
(배경) 온보딩 2주, 기획 1개월, 그리고 정체된 3개월
‘시골살이’를 주제로 웹서비스를 만들어보기로 했다. 내가 기획을 맡고, 두 개발자 동료들이 각각 프론트엔드와 서버를 맡았다. 어떤 서비스를 만들어보고 싶은지 이야기를 나눈 후, 나는 배운대로 잠재 유저를 대상으로 인터뷰를 했다. 대상은 시골살이 프로그램 참여 경험자였다.
수 주에 걸쳐 피그마에 화면을 그리고, 화면별 설명을 붙였다. 서비스에 <두렁두렁>이라는 이름도 붙여줬다.
그런데, 우리의 개발은 두 달 이상 늘어지고 말았다. 초기에 일치 시켜두었던 서비스 기획 목적은 이미 모두의 머릿속에서 사라진 지 오래였다. 솔직히 기획을 한 나 조차도, 이 서비스를 통해 어떤 문제를 해결하고 싶은 것인지 반쯤 잊고 지냈다. 아무리 사이드 프로젝트로 스트레스 받지 말자고 이야기하곤 했지만, 생각보다 너무 더딘 개발을 어떻게 해결해야 하나 고민이었다.
프로젝트 시작 4개월차, 뒤늦은 점검 시작
진행 현황을 되짚으며, 지체되기 시작할 때부터 ‘사실은 실감하고 있었던’ 몇 가지 문제점들을 나열해보았다.
1. PRD의 부재
IA나 정식 PRD 없이 피그마를 화면 플로우 겸 정의서 겸 사용하고 있었다. 서비스의 정체성에 대해 두고두고 꺼내 읽을 명확한 문서가 없었다.
컴포넌트, 화면 플로우, 기능 정의가 중구난방으로 섞여 있는 현재 피그마 문서2. 노션 칸반 활용의 어려움
프로젝트 진행 상황을 눈으로 확인할 수 있는 칸반 활용도가 떨어졌다. 내 계정으로 만든 노션 무료 워크스페이스를 활용하고 있었는데, 콘텐츠를 삭제하거나 편집할 수 있는 권한이 제한적이어서 활용도가 떨어졌다.
2023년에 머물러 있는 칸반...3. 논리가 약한 문제정의
무엇보다, 해결하고자 하는 문제가 명확하지 않았다! 이건 나부터 설득이 안 되고 있었다. 만약 프로토타입이 배포가 된다면, 시골살이 프로그램을 운영하는 운영팀이 유용하게 활용해줘야 콘텐츠도 쌓이는 법. 그런데, 나는 시골살이 ‘참여자’만 인터뷰했지 정작 프로그램을 운영하고 기획하는 과정에서 어떤 점이 어려운지 파악하지 않은 채 화면만 그리고 있었다. ’초보 기획자가 흔히 저지르는 실수’ 같은 콘텐츠에서 꼭 나오는 방식의 기획을 내가 하고 있었던 것이다.
그래서 이것을 어떻게 해결했냐?
사실 아직 해결하지 못했다.
다만, 해결 과정을 앞으로 기록하려고 한다.
우선 이번 주 내가 시도해 본 것은 다음과 같다.
1. Linear(리니어) 서비스를 도입해봤다.
나는 아직 PM으로서의 실무 경험이 전혀 없다. 프로젝트 관리 방법론이나 툴은 아주 생소하다. 그래서 유용하게 함께 쓸 수 있는 협업툴에 대한 감도 없었다. PM 직무에 대한 뉴스레터를 받아보고 있었는데, 거기서 리니어를 알게 되었다.
리니어는 피그마 플러그인으로 연동해서 활용할 수 있다.
리니어에 기능별로 이슈를 만들고, 각 기능별 설명을 적으면 피그마에서 미리보기가 가능했다.
기존에는 피그마에 그린 화면마다 설명을 함께 적느라 화면 간 거리가 멀어지고, 그렇다 보니 플로우가 한 눈에 들어오지 않았었는데 리니어를 활용하면 더 깔끔하게 정리할 수 있었다.
아, 아직 정리가 완벽하지는 않은데,,. 리니어의 ‘이슈’를 어떤 것을 기준으로 나누는 것이 개발자들이 보기 편할지 조금 더 고민이 필요하다. 이것은 기록을 거듭하며 차차 개선해보기로 했다.
2. 칸반 관리 문제 역시 리니어 기능을 활용해보려고 한다.
리니어의 프로젝트 관리 기능아직 활용해보기 전인데, 이슈들을 묶어서 프로젝트로 관리할 수 있고, ETA를 등록해두면 시각화도 가능하겠더라…!
이 역시 나의 숙제다.
3. 그리고 문제의 문제정의…
사전 조사 단계에서 누락되었던 로컬기획자의 목소리를 수집해보기로 했다.
의견을 모을 수 있는 구글폼을 만들었다.
통계를 낼 수 있는 정량 문항 위주로 조사해볼까? 하다가, 아무래도 선택지로는 알 수 없는 진짜 어려움을 한 건이라고 수집해보고자 세 개의 주관식 문항으로 구성했다.
그리고 셋 중 하나에만 답해줘도 괜찮다는 문구를 덧붙였다.
여기서 또 하나의 숙제가 생긴다.
당연히 이메일로 요청을 보내려고 했었는데, 생각보다 많은 마을에서 이메일을 공개하지 않고 있었다.
대부분 인스타그램을 운영 중이었으며, 문의 역시 DM으로 받고 있었다.
그런데, 아직 <두렁두렁>은 인스타그램이 없었다.
한 시간 정도 인터넷을 뒤져서, 이메일을 공개한 10개 마을에 우선 메일을 보내두었다.
그리고, <두렁두렁> 인스타그램을 개설하기 위해 비주얼 아이덴티티를 다시 정의하기로 했다.
결론
아무리 실무 경험 없는 PM 지망생이라고 하더라도, 기본 적인 것들인데 심하게 놓치고 있었던 것들이 이 글에서 다 드러났다. 솔직히 창피하지만, 앞으로 하나씩 고쳐나가기 위해서 모두에게 공개하기로 했다.
위에서 언급한 내 숙제들을 마지막으로 요약하며, 망해가는 서비스의 첫번째 메이커로그를 마친다.
개선을 위한 숙제!
리니어 이슈 정리 기준을 정하고, 그에 따라 요구사항들을 정리한 후 피그마에 연동한다.
각 이슈별 ETA를 정해서 리니어에 프로젝트를 생성한다.
<두렁두렁>의 비주얼 컨셉을 정의한다.
<두렁두렁>의 인스타그램을 개설하고 피드를 꾸민다
로컬 기획자 인스타그램 계정 DM을 통해 보이스를 수집한다.
수집된 의견을 반영해 서비스를 피보팅하거나 보완한다.
