아이디어를 7일 안에 돌리는 사이드 프로젝트 룰

아이디어는 많다. 문제는 그 아이디어가 실제로 뭔가로 만들어지는 경우가 드물다는 것이다. 우리 팀도 마찬가지였다. “이런 거 만들면 어때?”라는 대화는 자주 있었지만, 그것이 실제 코드로 이어지는 비율은 낮았다.

왜 그랬을까 돌아보면, 완성에 대한 기준이 너무 높았던 것 같다. 아이디어를 제대로 만들려면 기획도 있어야 하고, 디자인도 있어야 하고, 오류 처리도 있어야 한다는 생각이 작동을 막았다.

그래서 우리는 룰 하나를 만들었다. 7일 안에 돌아가는 것을 만든다.

룰 1 — 7일 뒤 데모가 기준이다

아이디어를 꺼냈을 때, 가장 먼저 하는 질문은 “7일 뒤에 무엇을 보여줄 수 있는가”다. 이 질문이 범위를 자동으로 줄여준다. 7일 안에 넣을 수 없는 기능은 처음부터 제외한다.

데모 가능한 상태는 완성품이 아니어도 된다. 핵심 기능 하나가 실제로 동작하는 것이면 충분하다. 그 하나를 만드는 데 집중한다.

룰 2 — 기술 결정은 30분 안에 끝낸다

어떤 언어로 짤지, 어떤 프레임워크를 쓸지 고민하는 데 이틀을 쓰면 5일밖에 남지 않는다. 우리는 이미 익숙한 스택을 우선 선택한다. 새 기술을 탐구하는 것은 좋은 일이지만, 7일 데모가 목표인 사이드 프로젝트에서는 익숙한 도구가 낫다.

판단 기준은 단순하다. 우리 셋 중 한 명이라도 써본 것이 있으면 그것을 쓴다.

룰 3 — 혼자 막히면 4시간 안에 도움을 요청한다

혼자 풀리지 않는 문제에 하루를 쓰면 일정이 무너진다. 4시간 안에 해결이 안 되면 팀에 꺼낸다. 이것이 규칙이다. “내가 해결해야 한다”는 자존심은 사이드 프로젝트에서 적이다.

실제로 이 룰을 도입하고 나서 개인이 막혀있는 상태로 하루를 보내는 일이 거의 없어졌다.

룰 4 — 7일 데모 이후를 미리 정하지 않는다

7일이 지나서 만든 것이 마음에 들면 계속 키운다. 마음에 들지 않으면 버린다. 이 판단을 미리 하지 않는다. 7일 이후를 미리 계획하면 7일 데모 이전부터 확장성을 고려하게 되고, 범위가 다시 커진다.

데모 이전까지는 7일 데모만 생각한다.

7일이 가르쳐준 것

이 룰을 지키면서 만든 것들 중 일부는 버려졌고, 일부는 지금도 쓰이고 있다. 중요한 것은 아이디어가 실제로 돌아가는 경험을 반복하는 것이다. 그 경험이 쌓이면 아이디어를 꺼내는 것도, 만들기 시작하는 것도 덜 무겁게 느껴진다.

만드는 속도가 생각하는 속도를 따라가기 시작할 때, 팀이 재미있어진다.

— by slecs