개발사에 처음 보낼 요청서 한 장 쓰는 법

한 스타트업 대표님이 개발사 세 곳에 메일을 보냈습니다. 본문은 세 줄이었습니다. 「운동 기록 앱을 만들고 싶습니다. 견적 부탁드립니다. 참고 앱은 첨부합니다.」

답장은 제각각이었습니다. 한 곳은 미팅부터 하자고 했고, 한 곳은 질문 스무 개를 보냈고, 한 곳은 답이 없었습니다. 대표님은 개발사들이 성의가 없다고 느꼈습니다.

사실은 반대에 가깝습니다. 세 줄로는 개발사도 무엇을 계산해야 할지 모릅니다. 받는 쪽이 판단할 재료가 없으면 답도 흩어집니다.

핵심은 처음 보내는 요청서를 한 장으로, 대신 빠짐없이 쓰는 것입니다. 누가 쓰는 서비스인지, 사용자가 무엇을 하게 되는지, 이번에 어디까지 만드는지, 언제까지 필요한지를 적으면 됩니다. 이 네 가지가 있으면 개발사는 같은 그림을 보고 구체적인 질문과 대략의 범위를 돌려줍니다.

한 장에 들어갈 여섯 줄

요청서는 문장을 잘 쓰는 문서가 아닙니다. 항목을 채우는 문서입니다. 아래 순서대로 한두 줄씩 적어 보십시오.

예산을 적을지 고민하시는 분이 많습니다. 정해진 금액이 있다면 대략이라도 적는 편이 낫습니다. 개발사가 그 안에서 할 수 있는 범위를 먼저 말해 줄 수 있기 때문입니다.

빼도 되는 것, 빼면 안 되는 것

처음부터 기술 이야기를 쓸 필요는 없습니다. 어떤 언어로 만들지, 서버를 어디에 둘지는 개발사가 제안할 몫입니다. 반대로 빼면 안 되는 것이 있습니다.

• 이번에 하지 않을 것. 적지 않으면 개발사가 알아서 넣거나 빼서, 견적 기준이 서로 달라집니다.
• 관리자가 할 일. 회원 관리, 공지 등록, 정산 확인처럼 운영자가 하는 일을 한 줄이라도 적습니다.
• 이미 있는 것. 쓰고 있는 홈페이지, 회원 명단, 결제 계정이 있다면 적습니다. 연결 작업이 범위를 바꿉니다.

참고 앱은 「어떤 점」을 함께 적습니다

참고 앱 이름만 보내면 개발사는 그 앱 전체를 떠올립니다. 그 앱에는 수십 개의 화면과 오랜 운영이 쌓여 있습니다. 견적이 부풀거나, 반대로 엉뚱한 부분을 보고 낮게 나옵니다.

참고 앱을 보낼 때는 「이 앱의 예약 달력 화면처럼」, 「이 앱의 가입 과정처럼」 하고 범위를 좁혀 적습니다. 기획자들도 참고 사례를 정리할 때 화면 단위로 끊어서 적습니다.

보내기 전에 스스로 확인할 것

1. 처음 보는 사람이 읽고 서비스를 한 문장으로 다시 말할 수 있는가
2. 사용자 종류마다 하는 일이 한 줄씩 있는가
3. 이번 범위와 다음으로 미룬 것이 나뉘어 있는가
4. 모든 개발사에 같은 내용을 같은 날 보내는가

요청서 한 장은 출발점입니다. 개발사의 질문을 받고 나면 메뉴 구조와 화면 목록, 화면설계로 이어서 구체화하게 됩니다. 처음 한 장이 분명하면 그다음 단계의 기획서도 훨씬 빨리 정리됩니다. 개발은 그 문서를 들고 다른 곳에 맡기셔도, 직접 하셔도 됩니다.

자주 묻는 질문

개발 요청서는 몇 장 정도 써야 하나요?

처음 문의할 때는 한 장이면 충분합니다. 길게 쓰기보다 사용자 종류, 핵심 흐름, 이번 범위를 빠짐없이 적는 것이 중요합니다. 상세한 내용은 개발사의 질문을 받은 뒤 화면설계로 채웁니다.

요청서에 예산을 적으면 견적이 그만큼 나오지 않나요?

그럴 걱정보다 얻는 것이 더 큽니다. 예산을 알면 개발사가 그 안에서 할 수 있는 범위와 뺄 기능을 먼저 제안해 줍니다. 범위가 같은 문서를 기준으로 여러 곳에 받으면 금액도 비교할 수 있습니다.

아이디어만 있고 화면은 하나도 없는데 요청서를 쓸 수 있나요?

쓸 수 있습니다. 화면이 없어도 누가 쓰는지, 무엇을 하는지, 이번에 어디까지 하는지는 말로 적을 수 있습니다. 다만 정확한 견적이 필요하다면 그다음에는 화면 목록과 화면설계를 갖추는 것이 좋습니다.