기획자 없이 개발할 때 생기는 일과 넘길 문서
기획자 없이 개발을 시작하면 정할 일이 전부 개발 중에 쏟아집니다. 그때 생기는 일과, 개발사에 넘기기 전에 준비할 문서를 정리했습니다.

개발이 시작되고 한 달쯤 지났을 때 연락을 주신 대표님이 계셨습니다. 매일 아침 개발사에서 메시지가 온다고 하셨습니다. 「이 버튼은 어디로 가나요」, 「탈퇴한 회원의 글은 어떻게 하나요」. 대표님은 본업을 하다 말고 답을 고민하고 계셨습니다.
그 회사에는 기획자가 없었습니다. 대표님 머릿속에 서비스가 있었고, 그걸 미팅에서 말로 전한 것이 전부였습니다. 개발사는 성실했지만, 정해지지 않은 것까지 대신 정할 수는 없었습니다.
기획자가 없어도 서비스는 만들 수 있습니다. 다만 기획자가 하던 일이 사라지는 것은 아닙니다. 그 일이 개발 기간 안으로 옮겨질 뿐입니다.
핵심은 기획자가 없어도 기획자가 하던 「정하는 일」은 사라지지 않는다는 점입니다. 개발 전에 정하지 않으면 그 일은 대표님의 하루, 개발자의 짐작, 오픈 뒤의 수정으로 흩어집니다. 메뉴 구조, 화면 목록, 화면설계, 정책 정리를 묶은 기획서를 개발사에 넘기기 전에 준비해 두는 것이 가장 확실한 대비입니다.
기획자가 없으면 정할 일이 어디로 가나요
기획자가 하는 일은 결국 정하는 일입니다. 어떤 메뉴를 둘지, 화면마다 무엇을 보여 줄지, 예외는 어떻게 할지입니다. 이 결정이 개발 전에 없으면 세 곳으로 흩어집니다.
- 대표님의 하루. 개발사 질문에 답하느라 본업 시간이 줄어듭니다.
- 개발자의 짐작. 답을 기다리기 어려우면 개발자가 그럴듯하게 정합니다.
- 나중의 수정. 짐작이 틀린 곳은 오픈 직전이나 오픈 뒤에 다시 고칩니다.
셋 다 비용입니다. 눈에 잘 보이지 않을 뿐입니다.
특히 두 번째가 위험합니다. 개발자의 짐작은 대개 만들기 쉬운 쪽으로 기웁니다. 나쁜 뜻이 있어서가 아닙니다. 사업의 사정을 모르니 기술적으로 간단한 답을 고르는 것입니다. 그 답이 고객에게 불편하거나 운영에 맞지 않으면, 오픈 뒤 고객 문의로 돌아옵니다.
개발사 안에 기획 담당이 있다면 조금 낫습니다. 다만 그 사람도 대표님의 사업을 처음 듣는 사람입니다. 결정을 대신해 줄 수는 없고, 결정할 질문을 정리해 줄 뿐입니다. 답은 결국 대표님께 돌아옵니다.
개발사에 넘길 문서
기획자를 따로 두지 않더라도, 개발사에 넘기기 전에 아래 문서는 준비해 두시기를 권합니다.
| 문서 | 담는 내용 | 없으면 생기는 일 |
|---|---|---|
| 메뉴 구조 | 메뉴와 화면이 어떻게 매달리는지 | 화면이 엉뚱한 곳에 붙고 길을 잃습니다 |
| 화면 목록 | 사용자 화면과 관리자 화면 전체 | 견적과 일정의 기준이 사라집니다 |
| 화면설계 | 화면마다 보이는 것과 누르면 일어나는 일 | 질문이 매일 쏟아집니다 |
| 정책 정리 | 가입, 탈퇴, 취소, 환불, 권한 규칙 | 개발자가 대신 정합니다 |
정책 정리는 자주 빠지는 문서입니다. 「탈퇴하면 남긴 글은 지우는가」, 「환불은 언제까지 되는가」 같은 질문은 화면 그림에 드러나지 않습니다. 그러나 개발자는 이 답이 있어야 저장 방식을 정할 수 있습니다.
이 넷을 묶은 것이 기획서입니다. 두꺼울 필요는 없습니다. 정해야 할 것이 빠짐없이 정해져 있으면 됩니다.
메뉴 구조가 가장 먼저입니다
넷 중 하나만 고르라면 메뉴 구조입니다. 메뉴 구조는 서비스의 지도입니다. 지도가 없으면 화면 목록은 흩어진 종이 더미가 되고, 화면설계는 서로 이어지지 않습니다.
메뉴 구조를 그리다 보면 큰 결정이 먼저 나옵니다. 회원과 비회원이 볼 수 있는 범위, 고객과 판매자의 화면을 나눌지 같은 것입니다. 이런 결정은 개발 중에 바뀌면 많은 화면을 함께 흔듭니다. 그래서 가장 먼저 정해야 합니다.
메뉴 구조는 한 장이면 충분합니다. 맨 위에 큰 메뉴를 적고, 그 아래에 화면을 매답니다. 관리자 메뉴는 따로 한 장을 둡니다. 이 두 장을 개발사와 함께 보며 이야기를 시작하면 첫 미팅부터 대화가 구체적입니다.
넘기는 순간 기획은 끝나지 않습니다
문서를 넘겼다고 질문이 사라지지는 않습니다. 다만 질문의 종류가 달라집니다. 「이건 어떻게 하나요」가 「문서에 이렇게 적혀 있는데 맞나요」로 바뀝니다. 확인하는 질문은 답하기 쉽고, 일정도 덜 흔들립니다.
개발은 다른 곳에 맡겨도, 직접 하셔도 됩니다. 중요한 것은 개발이 시작되기 전에 메뉴 구조와 화면설계, 그리고 정책이 정리된 기획서가 손에 있는지입니다. 그 문서가 대표님 대신 개발사의 질문에 답해 줍니다.
자주 묻는 질문
기획자 없이 개발사에 바로 맡겨도 되나요?
맡길 수는 있습니다. 다만 메뉴, 화면, 예외, 정책을 정하는 일이 개발 중으로 옮겨 와 대표님이 매일 질문에 답하게 됩니다. 넘기기 전에 최소한 메뉴 구조와 화면 목록은 준비하시기를 권합니다.
개발사에서 기획도 해 준다고 하면 따로 기획을 맡길 필요가 없나요?
개발사 안의 기획 담당도 도움이 됩니다. 다만 그 사람도 사업을 처음 듣는 입장이라 결정할 질문을 정리해 줄 뿐, 결정은 결국 대표님께 돌아옵니다. 기획 기간과 산출물이 견적에 어떻게 들어 있는지도 함께 확인해 보십시오.
정책 문서에는 무엇을 적어야 하나요?
가입, 탈퇴, 취소, 환불, 권한처럼 화면 그림에 드러나지 않는 규칙을 적습니다. 「탈퇴하면 남긴 글은 어떻게 하는가」 같은 질문에 대한 답입니다. 개발자는 이 답이 있어야 데이터를 어떻게 저장할지 정할 수 있습니다.