의뢰 준비

소프트웨어 개발을 맡기기 전에 정리할 6가지

기획서가 없어도 괜찮습니다. 개발을 처음 맡기는 분이 문의 전에 정리해 두면 상담과 견적이 빨라지는 6가지를 예시와 함께 쉬운 말로 정리했습니다.

글 온정랩읽는 데 4분

한눈에 보기

  • 기획서나 화면 설계도는 없어도 됩니다. 지금 일하는 방식과 불편한 점을 알려 주는 것이 먼저입니다.
  • 정리할 것은 여섯 가지입니다. 지금 일하는 순서, 불편한 장면, 쓰는 사람, 꼭 필요한 것, 일정과 예산의 범위, 다 만든 뒤의 관리.
  • 일정과 예산은 정확한 숫자가 아니어도 됩니다. 범위만 알려 주셔도 그 안에서 할 수 있는 방법을 고르기 쉬워집니다.
  • 계약 전에는 소스 코드와 서버 · 도메인 계정을 누구 이름으로 둘지 꼭 정해 두세요.

기획서가 없어도 의뢰할 수 있나요?

네. 처음 개발을 맡기는 분 대부분은 기획서가 없습니다. 개발사가 먼저 알아야 하는 것은 '어떤 화면을 만들지'가 아니라 지금 일이 어떻게 돌아가고, 어디서 막히는지입니다. 화면과 기능은 그 이야기를 듣고 함께 정하면 됩니다.

다만 아래 여섯 가지를 미리 정리해 두면 첫 상담이 짧아지고 견적도 정확해집니다. 모두 채우지 않아도 됩니다. 아는 만큼만 적어 주세요.

1. 지금 일하는 순서를 적어 보세요

새 프로그램은 지금 하는 일을 대신하거나 줄이는 도구입니다. 그래서 지금 일이 어떤 순서로 흘러가는지가 가장 중요한 자료입니다.

  • 일이 시작되는 곳: 주문 전화, 메일, 거래처 발주서 등
  • 거쳐 가는 사람과 도구: 누가 받아서, 어디에 적고, 누구에게 넘기는지
  • 끝나는 곳: 출고, 정산, 보고서 등

지금 쓰는 엑셀 파일, 종이 양식, 화면 사진이 있다면 그대로 보내 주세요. 길게 설명하는 것보다 실제 파일 한 장이 더 많은 것을 알려 줍니다.

2. 불편한 점을 '장면'으로 적어 보세요

"관리가 불편하다"보다 "월말마다 창고 수량과 엑셀 수량이 달라서 두 사람이 반나절씩 맞춘다"가 훨씬 좋은 설명입니다. 언제, 누가, 무엇 때문에, 얼마나 시간을 쓰는지가 모두 들어 있기 때문입니다.

장면으로 적으면 무엇부터 고쳐야 하는지가 드러납니다. 위 예시라면 재고 화면을 보기 좋게 바꾸는 것보다, 입고와 출고를 그 자리에서 바로 기록하게 만드는 것이 먼저입니다.

3. 누가, 어디서, 무엇으로 쓰는지 알려 주세요

같은 기능이라도 쓰는 사람과 장소에 따라 만드는 방식이 달라집니다.

이런 경우라면 이런 방식이 잘 맞습니다
현장에서 휴대폰으로 바로 기록 모바일 앱, 또는 휴대폰에 맞춘 웹
사무실 여러 명이 함께 사용 웹 서비스
인터넷이 불안하거나 장비와 연결 PC에 설치하는 Windows · Linux 프로그램
고객이 직접 보고 신청 홈페이지, 예약 · 결제 화면

쓰는 사람의 사정도 함께 적어 주세요. 장갑을 끼고 화면을 누르는지, 글씨가 커야 하는지, 컴퓨터에 익숙하지 않은 분이 많은지 같은 것들입니다. 이런 내용이 화면의 글씨 크기와 버튼 크기, 화면에 쓰는 말을 정합니다. 어떤 방식으로 만들 수 있는지는 만드는 것에서 화면으로 보실 수 있습니다.

4. 꼭 있어야 하는 것과 나중에 해도 되는 것을 나눠 보세요

원하는 기능을 모두 첫 버전에 넣으면 기간과 비용이 함께 늘고, 정작 중요한 기능을 써 보는 때가 늦어집니다. 기능을 세 칸으로 나눠 보세요.

  • 꼭 있어야 하는 것: 이것이 없으면 쓸 이유가 없는 기능
  • 있으면 좋은 것: 처음에는 손으로 해도 버틸 수 있는 기능
  • 나중에 생각할 것: 써 보고 나서 정해도 되는 기능

이렇게 나눠 두면 첫 버전을 빨리 써 볼 수 있고, 실제로 써 본 경험을 바탕으로 다음 기능을 정할 수 있습니다.

5. 일정과 예산은 '범위'로 알려 주세요

정확한 숫자가 아니어도 괜찮습니다.

  • 일정: 꼭 지켜야 하는 날짜가 있다면 그 이유도 함께 적어 주세요. 행사, 계약 만료, 시즌 시작처럼 이유를 알면 그 날짜에 맞출 수 있는 범위를 함께 고를 수 있습니다.
  • 예산: 대략의 범위를 알려 주시면 그 안에서 할 수 있는 방법을 제안받기 쉽습니다. 범위를 모르면 개발사는 가장 넓은 기준으로 견적을 낼 수밖에 없습니다.

6. 다 만든 뒤를 미리 생각해 두세요

프로그램은 만든 날부터 계속 써야 하는 도구입니다. 계약 전에 아래를 정해 두면 나중에 생기는 다툼과 비용을 줄일 수 있습니다.

  • 소스 코드: 다 만든 뒤 소스 코드를 받을 수 있는지, 받는다면 어떤 형태로 받는지
  • 계정: 서버, 도메인, 앱 스토어 계정을 누구 이름으로 만들지. 가능하면 맡기는 회사 이름으로 두는 것이 좋습니다.
  • 고정 비용: 서버와 도메인처럼 매달, 매년 드는 비용이 얼마인지
  • 관리: 오류가 생기면 누가 고치는지, 보안 업데이트와 백업은 누가 하는지

이렇게 적어 보내시면 됩니다

아래는 여섯 가지를 메일 한 통에 담은 예시입니다. 이 정도면 첫 상담을 바로 시작할 수 있습니다.

회사: 식품 제조사, 직원 20명
지금은: 입고 · 출고를 종이에 적고, 저녁에 사무실에서 엑셀로 옮깁니다. 엑셀 파일을 함께 보냅니다.
불편한 점: 월말마다 창고 수량과 엑셀 수량이 달라서 두 사람이 반나절씩 맞춥니다.
쓰는 사람: 창고 직원 4명(휴대폰), 사무실 직원 2명(PC)
꼭 필요한 것: 창고에서 휴대폰으로 입고 · 출고 기록, 사무실에서 지금 재고 바로 확인
나중에 해도 되는 것: 거래처별 매출 보고서
일정 · 예산: 내년 1월 재고 조사 전에 쓰고 싶습니다. 예산은 상담을 받아 보고 정하려 합니다.
다 만든 뒤: 회사에 개발자가 없어서 유지보수도 함께 맡기고 싶습니다.

없어도 되는 것

  • 기획서, 화면 설계도
  • 개발 용어나 기술 이름. 어떤 기술로 만들지는 개발사와 함께 정하면 됩니다.
  • 빈틈없이 정리된 요구 사항

모르는 부분은 "모르겠다"고 적어 주시면 됩니다. 함께 정리하는 것도 개발사가 하는 일입니다.

자주 묻는 질문

기획서나 화면 설계도가 없어도 개발을 의뢰할 수 있나요?

네. 지금 일하는 순서와 불편한 점, 쓰는 사람만 알려 주셔도 상담을 시작할 수 있습니다. 화면과 기능은 상담하면서 함께 정합니다.

예산을 먼저 알려 주면 견적이 높게 나오지 않나요?

범위를 알려 주시면 그 안에서 가능한 방법을 비교해 고를 수 있어 판단이 오히려 쉬워집니다. 범위를 모르면 개발사는 가장 넓은 기준으로 견적을 낼 수밖에 없습니다.

개발이 끝나면 소스 코드는 누가 갖나요?

계약서에 정한 대로입니다. 계약 전에 소스 코드를 받을 수 있는지, 서버 · 도메인 · 앱 스토어 계정을 누구 이름으로 둘지 꼭 확인하세요. 가능하면 맡기는 회사 이름으로 두는 것이 좋습니다.

다른 업체가 만든 프로그램의 유지보수만 맡길 수도 있나요?

가능한 경우가 많습니다. 온정랩도 다른 곳에서 만든 시스템의 인프라와 유지보수를 상담 후 맡을 수 있습니다. 소스 코드와 서버 접속 정보가 있으면 더 정확하게 살펴볼 수 있습니다.

가이드 목록