서비스 구축 제안서 작성법
기획자, 팀장이 진행하는 실무용 구축 제안서 작성하기
IT 업계에서 서비스를 만드는 일을 하다보면, 팀장 업무를 맡거나 제안서를 써야하는 경우가 생긴다. 이 경우 어떻게 제안서를 써야하는지. 요청사항 분석은 어떻게 해야하는지. 고민해야할 지점이 상당히 많아진다. 심지어 본인이 한번도 만들어본 적 없는 서비스를 만들어야할 때, 이런 고민은 더욱더 커질 수 밖에 없다. 오늘은 이런 서비스 구축 제안서를 작성하는 방법과, 그 과정에 대해서 자세히 알아보도록 하자.
1. 클라이언트의 요청사항 분석하기
대부분의 클라이언트는 '자신이 무엇을 만들고싶은지'에 대해서' 대략적인 이미지를 갖고있다. 이후 그 형태가 문서로 정리가된 형태이건, PPT이건 간에 - 어떤식으로건 목표로하는 내용을 자료로 전달하게된다. 제안서의 시작점은 이 요청사항을 분석하고, 내용을 예상하는 지점에서부터다. 그들이 '어떤 서비스 플랫폼을 원하는지. 어떤 기능들이 들어가길 원하는지. 어떤 개발언어를 쓰길 원하는지. 와 같은 내용들이 담겨있다. 운이 좋다면 자세한 기획서나, 구조도같은 것을 얻을 수도 있겠지만, 대부분은 그런 자료를 기대하긴 어렵다. 그러니 기초적인 정보만으로도 타사 서비스 사례나, 기능요구사항을 '역으로 제안해야하는' 상황에 놓이게된다.
대부분의 클라이언트는 이렇게 자세한 기능정의서를 만들줄 모르는 사람들이다제안서를 작성할 때는, 주어진 참고자료나 정보들을 바탕으로 '이들이 무엇을 원하는지'를 체크해야한다. 또한 주어진 정보들을 바탕으로 이들이 IT 서비스에 대한 이해도가 얼마나 되는지. 개발인력이나, 기획 인력이 내부에 있는지 등의 여부도 체크해보게된다. 그런 지점들을 파악해야 '클라이언트가 이해할 수 있는 수준'을 어느정도로 잡아야할지를 알 수 있기 때문이다. 물론 대부분의 클라이언트들은 기획이나 설계, 개발에 대해서 이해도가 높지 않다. 그러니 알기쉽게 정리해서, 중요한 지점을 풀어서 말해주는 형식을 선택하는게 좋다.
체크포인트
- 클라이언트가 제공한 요청사항을 바탕으로, 서비스 제작목적을 파악하기
- 기존 서비스가 있는지 / 신규 서비스 구축이 필요한지 확인하기
- 내부 운영인력중 기획자나 개발자 그룹이 있는지 확인하기
- IT와 개발기술에 대한 이해도가 어느정도인지 확인하기
서비스 기능구현에 대한 조사내용대부분의 클라이언트들은 정확한 기능에 대한 요구보다, '이런 기능이 있는 서비스를 만들고싶어요' 정도의 내용을 전달하는게 대부분이다. 그러니 거기에 맞는 해석, 유추의 과정이 꼭 필요하다. 그러니 1차 미팅, 2차미팅 때 그 간격을 좁혀나가는 방식으로 구체화된 제안서를 작성하게된다. 하지만 만약 클라이언트 측에서 '굉장히 자세한 기능구현'에 대해 문서를 별도로 준비한 상황이라면 이야기가 달라진다. 클라이언트가 직접 기능에 대한 조사나, 자료제작을 진행한 경우, 그만큼 '디테일한 피드백'을 해줘야한다.
내 경우에는 요구받은 기능별로 어떻게 그 기능을 구현할 수 있는지, 그 기능을 구현할 때 예상되는 문제점이 무엇인지를 우선적으로 정리하는 편이다. 그리고 다음 단계에서 '주요 기능별로' FLOW 차트를 만들어서 공유하는 방식을 사용한다.
체크포인트
- 기능별 기능구현 방법
- 사용되는 외부 데이터 종류와 URL
- 기능구현시 예상되는 문제점 / 어려운 지점
주요 기능별로 여러 담당자들이 어떤 역할을 하는지 정리한다. 주요기능별 플로우차트의 가장 큰 장점은, 주요 프로세스를 쉽게 보여줄 수 있다는 점이다. 특히 첫 미팅에서 '내가 이 서비스를 이만큼 이해하고있다'는 사실을 즉각 보여줄 수 있어 상당히 유용하다. 대부분의 클라이언트들은 개발사가 얼마나 이 서비스의 핵심을 이해하고있는지. 기존에 유사한 프로젝트를 경험해본적이 있는지를 알고싶어한다. 그러니 이런 프로세스 정리만 하더라도, 상대에게 큰 신뢰감을 심어줄 수 있는 것이다. 물론 내가 접해본적 없는 서비스에 대해 이정도로 자세한 FLOW 차트를 만들려면 시간이 꽤 많이 소요된다. 게다가 개별로 필요한 API나, 외부 솔루션 등도 체크해야한다. 그래서 일반적으로 2~3 시간 정도는 서비스 조사 과정이 꼭 필요하다.
내가 평소에 기획자의 업무가 '정보정리'에 특화되어있어야 한다고 했던 것도 이런 이유에서다. 내가 잘하는 업무만 하는 것이 아니라, 새로운 정보를 파악하고 정리해야하는 경우가 많기 때문이다. 내가 잘 알지 못하는 지점이라도 각 정보의 연관관계를 파악하고, 알아낸 정보를 구조화하고, 시각화할 수 있어야한다. 그리고 그 내용을 바탕으로 '마치 기존에도 잘 알고있었다는 것처럼' 설명하고, 그것을 개발할 때 필요한 정보가 무엇인지. 클라이언트에게 설명해줄 수 있어야한다. 대부분의 경우 이런 기능별 FLOW 차트를 만들게되면, 클라이언트의 설득이 훨씬 쉬워진다.
2. 1차 미팅 후, 업체측 요구사항 정리하기
실제 미팅은 기능별 FLOW를 통해 진행하는 경우가 많다. 직접 찾아가거나, 화상미팅을 진행하기도하는데, 그 과정에서 이미 서비스에 대한 범위와, 주의점, 기능구현에 대한 이야기를 나누게된다. 그러면 이 내용을 바탕으로 실제 개발해야할 기능범위나, 클라이언트 측의 내부 자료 등을 전달받게된다. 이때 기획자나 팀장들은 업체측에서 요구한 사항을 정리한 회의록을 쓰게된다. 이때 쓰게되는 문서가 작업범위에 대한 정리와, 작업 견적에 대한 문서다.
업체가 요구한 사항을 정리한 작업범위 / 견적 문서작업범위는 '이런 내용을 작업하게될 것이다' 라는 우리쪽의 제안이다. 그리고 클라이언트에게 '이 범위가 맞느냐' 라고 질문하는 내용이기도하다. 그 지점이 맞다면 그대로 견적을 작성해 보내면 되는 것이고, 작업범위가 다르다면 일부 내용을 조절하면 된다. 이 지점부터는 개발자나, 기획자, 디자이너의 월 업무 투입량 (man / month) 기준으로 견적과 일정을 작성하게된다. 일반적으로 중급, 상급, 고급 같은 '급'을 나누어 금액을 조절하기도 하는데. 업체별로 견적 측정하는 방식은 모두 다르니, 잘 모르겠다면 대표님에게 물어보도록 하자.
대부분 기획 / 디자인 작업을 한 꼭지로 잡고, 이후 프론트엔드, 백엔드 작업을 개별로 나누게된다. 플랫폼 기준으로 앱, 웹 단위로 견적을 낼 수도 있고, 프론트 / 백엔드 형태로 묶어서 작성하는것도 가능하다. 이 부분은 얼마나 자세하게 작성하는지에 따라 상대가 우리 회사의 견적 기준을 파악할 수도 있으니. 적당한 수준으로만 정보를 공개하는 것을 추천한다. 너무 정확한 금액이 나와버리는 경우, 금액 역제시가 일어나거나, 금액 깎기에 대한 이야기가 나올수도 있기 때문이다.
체크포인트
- 작업 범위에 대한 제안을 클라이언트에게 확인하자
- 작업 범위가 확정되었다면, 실제 견적과 일정을 첨부해 제안하자
- 개별 투입 인원을 기준으로 맨먼스(man / month) 인원, 플랫폼별 작업견적을 작성하자.
- 앱이나 웹 같은 플랫폼 기준으로도 맨먼스(man / month) 견적을 작성할 수도 있다.
- 서비스 기획, 개발기간 말고도 서비스 QA 작업이 가능하도록 일정을 잘 조절하자.
3. 계약서 작성하기
실제 계약서를 작성하는 경우, 별도의 공증을 받거나, 에스크로 서비스를 이용하기도한다. 그만큼 '계약금액'을 받는 과정이 쉽지 않기 때문이다. 그래서 보통은 계약 후 착수금 (일을 시작하는 금액) 형태로 선금을 일부 퍼센티지 형태로 받고, 마무리 작업시 나머지를 받는 방법을 주로 사용하게된다. 혹은 착수금과 중간금액, 마무리금액 형태로 3단계로 나누어 계약금액을 받을 수도 있다. 이런 계약금액에 지급시점은 업체 입장에서 '사기를 칠 수도' 있기 때문에, 작성 및 공유시 주의를 기울여야한다. 서로가 서로를 신뢰하기 위해, 확실한 입금기록 확인 및 입금증명 기록이 될 수 있는 영수증을 제출하는것이 좋다.
계약서의 경우 내부에 회사에게 불리하게 적용될 수 있는 조항은 없는지. 기간이 무리하게 산정되지는 않았는지. 각 금액이 인건비 소비에 맞게 책정되었는지. 얻을 수 있는 영업이익 금액은 얼마나 되는지에 대해서 미리 체크를 해둬야한다. 그렇지 않을 경우 개발기간이 부족해져서 클라이언트와 싸우게되거나. 심하면 고소를 당하는 일까지 발생할 수 있다. 법적으로 계약기간은 서로 합의한 사항이기 때문에, 납품 기간을 제대로 지키지 않을 경우 문제가 커질 수 있다. 물론 실제로 고소를 하는 곳은 많지 않긴 한데, 원칙적으로는 '법적 책임'이 생기게된다는걸 기억하자.
체크포인트
- 계약서를 작성하기 전에 금액과 기간, 작업범위를 다시한번 확인하자
- 계약서 내에 불리하게 작용할 수 있는 내용은 없는지, 꼼꼼히 체크하자
- 계약금액 지급 시점과, 각 퍼센티지에 대해 확실하게 확인해두자
제안서를 쓰다보면, 공부하게되는 것들이 상당히 많다. 특히 본인이 경험해보지않은 새로운 서비스를 분석해야할 경우, 어떤 기술이 쓰이는지. 무슨 기술자가 필요한지. 어떤 API나 외부 솔루션을 사용해야하는지. 다양한 기술과 전략지점을 고려해야하는 상황이 된다. 물론 본인이 모든 정보를 확인할 수 있다면 좋겠지만, 보통 이사나 대표 급의 인원은 제안이나 계약서 작업을 경험해본 경우가 많다. 그러니 혼자서 고민하기보다, 모르는 내용은 상사의 의견을 듣고 파악해서 제안서를 작성해보자.
-
기획팀은 대부분 서비스 조사, 기술검증, 기능별 FLOW 제작, 서비스 핵심내용 정리 - 와 같은 내용에 집중하게된다. 여기에 추가로 본인이 미팅을 나가서, 조사한 내용들에 대해 설명할 수 있다면 더욱 좋다. 스스로 기획자가 되고싶은 사람이라면, 팀장급 인원이 되기 위해 이런 작업들을 미리미리 준비해두면 좋을거라고 본다. 팀장, 리더교육에 대해서 궁금한 사람이라면 다음 글도 읽어보길 추천한다.
https://brunch.co.kr/@clay1987/319
https://brunch.co.kr/@clay1987/317
