기획자는 프로덕트 소통의 중심에 있어야 한다.
서비스의 메인 주제가 무엇인지 명확하게 파악하고, 디자인, 개발 등의 리소스까지 고려하여 최소화하는 방안을 고민해야 하며, 정해진 일정 안에서 효율적으로 서비스를 런칭할 수 있도록 유도해야 한다.
본 글에서는 개발 일정을 어떻게 산출해야 하며, 지연되었을 때 어떤 마음가짐을 가져야 하는지 다뤄보고자 한다.
1월 3일 오후, 대표님, 마케터님과 공동 회의를 진행했다. 악명높은 개발 CORS 오류로 인해 예상된 일정보다 프로덕트 완성 일정이 계속 미뤄지고 있었고 이로 인해 대표님과 마케터분이 약간의 불안을 느끼고 계심을 눈치챘다.
개발 이슈는 항상 예상할 수 없고 불가피하며, 모두가 본업으로 보수를 받고 근무하는게 아니라 사이드 형태로 협력하고 있는 프로젝트인 만큼 넉넉한 마음으로 기다리며 다른 리소스 집중하면 어떨지 설득했다.
기존에 PM 톡방에서 얻은 인사이트가 떠올랐다.
개발 일정 산출하기 = 최소일정 * 3
개발일정을 산출하는 데에 개발자도 기획자의 가능성을 모르고, 기획자도 개발자가 하는 일을 명확히 모르기 때문에 기존보다 일정이 딜레이되는 일이 많다.
기획자: 너 이거 개발하는데 이것만 초 집중해서 하면 최소 얼마나걸려?
개발자: 이것만 하면 최소 2주 걸려.
기획자: ok 그럼 6주로 일정 잡을게.
개발 일정을 산출할 때 최소일정 * 3을 하는 이유는 예측할 수 없는 변수 때문이다. 개발 에이전시에서도 중간에 치고 들어오는 업무, 오류 등을 고려하여 3배로 잡을 시 딱 맞는 경우가 많다고 했다. 다만 이는 본업을 집중하는 경우에 대한 이야기이고 우리와 같이 사이드로 진행할 경우 개발자가 해당 프로덕트 개발에만 몰두할 수 없기에 더욱 넉넉하게 잡아야 할 것이다.
현재로써는 최대한 개발자분들의 불필요한 리소스를 최소화할 수 있도록 API 명세서 등에서 오류가 없는지, 기획 과정에서 헷갈릴만한 부분이 없는지 꾸준히 체크 및 점검하는게 최선이라고 생각한다.
1월 중순에는 MVP 작업이 완료되고, 본격적으로 마케팅을 진행하며 유저 데이터를 확보해가며 프로덕트를 새롭게 발전시키는 경험을 할 수 있기를 기대해본다.