오늘부터 입찰 제안서를 써보라고요?
서비스를 분석하고, 고객들에게 안전한 길을 알려주기
내가 다니는 회사는 규모가 크지않다. 그렇다보니 장기적인 관점을 갖기가 쉽지않다. 생존하기 위해 얼마나 많은 일을 해야하는지. 또 어느정도 수준의 기술기반이 필요한지. 생각해야할 지점이 많다. 그럼에도 불구하고 요 몇달간 생각보다 많은 서비스들을 제안하고, 입찰에 성공했다. 오늘 이야기할 내용은 입찰 제안서를 쓰는 과정에서 알게된 기획자의 역할, 서비스 분석방식에 대한 내용이다.
오늘부터 입찰 제안서를 써야한다고?
1.
회사에서 입찰제안서를 써야하는 상황이 왔을 때, 나는 일단 '어떤 일들'을 골라야할지에 대해 고민했다. 회사 내부에 있는 개발자들은 내부 서비스를 만들고있었고, 나는 그 보조역할을 해야했다. 내가 제안서에 대해 고민하기 시작한건, 당장 급한 기반작업을 끝낸 이후의 이야기였다. 제안서를 써야한다는거, 생각보다 쉽지않다. 무슨 서비스를 만들지도 모르는 사람들의 이야기를 듣고, 거기에 맞는 '적절한 제안'을 써야한다. 심지어 금액조차 그들의 예상범위에서 넘어버리면 안된다. 제안작업은 내게 있어서도 쉽지 않은 작업이었다.
나는 대부분의 경우 '설계' 에 대한 지점과 화면작업을 혼자서 다루곤했다. 그래서 대부분의 서비스들을 혼자서 설계할 수 있다고 생각했다. 다만 내가 알고있던 범위는 실제 고객들이 원하는 범위와는 차이가 있었다. 심지어 쓰는 개발언어나 플랫폼 조차 달라서, 새로운 내용을 배워야했다. 우리 팀에 있는건 웹개발자 1명과 백엔드 1명, 안드로이드 1명 뿐인데, 갑자기 C언어 기반의 커스텀 OS를 만든다거나. 전철 선로의 가속도 센서를 파이썬으로 저장해달라거나. 기업용 ERP를 만든다거나 하는 수준의 '제안서'를 써야하는 상황에 놓인 것이다.
대체 제안서를 어떻게쓰라는건지 답답해서 찾아봤던 글들
https://asana.com/ko/resources/project-proposal
https://dbr.donga.com/article/view/1202/article_no/1707/ac/magazine
제안서를 많이 써본것도 아닌 입장에서, 일단 막막함이 앞서왔다. 다만 서비스를 '분석'하고 그 안에 들어가는 'API'들의 목록을 정리해보면서, 점차 문제가 해결됐다. 기존에 해왔던 서비스 분석작업이나, 기능적 분석같은 것들을 적용해보니 - 나름대로 답이 보이기 시작했던 거다. 이 서비스를 만들려면 무슨 정보를 연결해야하나. 어떤 API를 가져와야하나. 스스로 질문을 해보면서 실제 구성요소를 찾아냈다. 나중에 가서는 각각의 서비스 제안서가 일종의 퍼즐풀기처럼 느껴졌다. 이 시점부터 내가 갖고있던 '기획에 대한 공부'라는 지점이 해답을 얻게되었던 것 같다.
그 당시 서비스를 분석하며 API를 분석한 경험을 바탕으로 작성했던 내용들
https://brunch.co.kr/@clay1987/291
기획자가 내부 구조를 모르면
개발자만 고생하는 거야
2.
과거에 ERP나 그룹웨어 등의 작업을 일부 해본적이 있었다. 하지만 '처음부터 끝까지' 해본적은 없었다. 그렇기에 난이도가 높은 서비스에 제안을 넣는 것에 대해, 고민을 하게되는 경우가 많았다. 만약 '운이 좋아서' 낙찰을 받아버리면, 내가 그걸 책임져야하니까, 더욱더 신중해질 수 밖에 없었던 것 같다. 하지만 실제로 제안서를 쓴 내용들이 1차, 2차 미팅으로 이어지고, 계약서를 쓰게되는 과정이 이어지면서 생각이 많이 달라졌다. '나중에 책임지기 어려운 상황'을 만들지 않기 위해, 제안서를 쓸 때부터 미리 설계 난이도를 알아두면 되는거잖아?
물론 이 방식에도 몇가지 문제는 있었다. 내가 전혀 다뤄보지 않은 서비스의 경우, 구성요소가 무엇인지. 그들이 사용하는 API가 뭔지. 대체 이 기능을 '어떻게 만들어낸 것인지' 알기가 힘든 것들이 많았기 때문이다. 이런 경우 개별 서비스 메뉴얼을 찾아보거나, 관리자용 문서를 찾아보면서 내부 화면이나 기능을 확인해야했다. 그래도 해결이 안되는 경우는 chat GPT를 사용해서라도 '비슷한 답'을 찾아다녔다. 그러다보니 나중에는 내가 잘 알지 못했던 서비스들마저 분석하는 방법을 알게됐다.
난이도가 높은 서비스들. 설계가 복잡한 서비스들을 들여다봐야할 때. 이제는 '내용이 많아서 복잡한건지', 아니면 '내부 로직이 많아서 복잡한 건지'를 구분할 수 있게 됐다. 단순히 정리할 정보가 많은 것들은 '시간과 인력'으로 해결하면 된다. 하지만 내부로직이 많은 서비스들은 '그 안에 사용된 정보의 출처, 가공방식'에 대해서 알아야한다. 그리고 이걸 다시 '어떻게 재현할수있을지, 규모는 어떻게 줄여야할지'를 고민해야했다. 정해진 틀 안에서 '이 서비스의 핵심이 무엇인지' 확인하고, 그 내용을 그대로 제안서에 넣기 시작했다.
이 시점에 쓰게된 내용들이 이런 내용이었다.
https://brunch.co.kr/@clay1987/299
3.
내가 제안작업을 하면서 가장 자주하게되는 것들 중 하나가, '기능별 FLOW'를 정리하는 방식이다. 각각의 고객들은 자신이 익숙한 그 내용에 대해서는 알지만, 그것이 어떻게 개발되어야할지는 알지못한다. 그러니 그들이 보기 편하게 내용을 정리해서 알려줘야했다. 그걸 위해서 각각의 사용자타입별로, 중요한 기능들을 시각화하거나. 단계별로 FLOW를 만들어 전달하기 시작했다. 결국 제안서와 미팅 PT는 각각의 기능이 개발 과정에 들어가게된다는 걸 알려주는 과정만으로도 충분했다.
- 서비스에 들어가는 주요 기능
- 서비스를 사용하는 주요 사용자타입
- 각 기능이 이뤄지는 단계별 과정
이런 일련의 과정은 강의자료를 만드는 것과도 거의 비슷했다. 어떤 기능이, 누구를 통해서, 어떤 단계를 통해 이뤄지는지. 그 내용을 정리하기만 해도 대부분의 설명에는 문제가 없었던 것 같다. 대부분의 고객들은 자신이 얻게될 내용이 무엇인지. 그게 어떤 단계를 통해 이뤄지는지를 알고싶어한다. 자신이 알고있는것 만큼, 서비스를 만드는 사람이 알고있는지를 궁금해한다. 어쩌면 그런 '단순한 정리과정'이야말로 '이 사람은 이 서비스를 제대로 이해하고있구나' 하는 안도감을 전달해주는 것인지도 모르겠다.
서비스별로 다양한 사용자 타입에 대해 체험하고 정리하게된 글
https://brunch.co.kr/@clay1987/296
ERP급 서비스들을 분석하고나서 정리하게된 '상태값'에 대한 글
https://brunch.co.kr/@clay1987/292
다양한 서비스에 대한 경험이
계획에 대한 예측으로 이어진다
4.
사람은 원래 자신이 경험한 것들을 기반으로 상상할 수 있는 능력이 있다. 새로운 서비스를 만들어야하는 상황. 주어진 인력이나 기간은 제한되어있고, 기능을 잘라내야할 때. 무엇을 우선적으로 처리해야할지. 그리고 그것을 실제로 만들게 되었을 때, 어떤 방식으로 운영하게 될지. 실제로 보지 않아도 예상할 수 있는 지점들이 생긴다. 그렇게되면 자연스럽게 '위험한 선택'을 피할 수 있고, 그걸 바탕으로 더 안전한 방식을 선택할 수 있다. 어쩌면 제안서 작성이란 것도, 내가 경험한 것을 바탕으로 하는 '안전한 방법에 대한 소개' 일수도 있다.
대부분의 고객들은 자신의 분야 외에는 잘 알지 못하는 사장님들이다. 그런 사장님들을 안심하게 하려면 어떻게 해야할까? 그 지점에서 생각해보면 제안서를 쓴다는건, 여행 가이드 역할을 하는것과 비슷하다. 처음 가보는 길을 소개해주면서, 어디에 무엇이있는지. 뭘 주의해야하는지를 알려주는 역할 말이다. 그들이 원하는 것은 '안전하게 목적지에 도착하는 일'이다. 그렇다면 그 여행지를 가장 잘 아는 사람의 역할을 해야하는데. 어떻게 하면 그런 역할을 할 수 있을까? 그것도 다양한 분야에서, 나자신도 처음 가보는 곳이라면?
어찌보면 이 지점은 '상상'과 '경험'의 중간정도에 있는 '예측'이란 지점이 필요한것 같다. 대부분의 IT 서비스는 다루는 정보는 다르지만, 그 정보를 입력받아 변형하는 방식은 대부분이 비슷하다. 그러니 공통적으로 쓰이는 지점을 이해하고 나면, 나머지는 '새로운 지점'이 무엇으로 이뤄져있는지. 그 내부를 파헤쳐보면 된다. 그러니 자신이 알고있는 것들과 가장 '비슷한 형식'을 찾아서 부족한 지식을 대체하면 된다. 그건 단순한 상상이 아니라 '예측'의 영역이다. 그러니 처음 만들어보는 서비스라도, '머리로 이해하게되는 지점'이 생기는 것이다. 그 이치를 한번 파악하고나면 나머지는 그저 순서에 맞는 문서작업이 남아있을 뿐이다.
-
최근들어 느끼는 거지만, 기획자가 글 못쓰면 제안서도 못쓴다. 결국엔 모든게 정보정리고, 내가 이걸 얼마나 알고있는지에 대한 증명이니까. 포트폴리오가 기업에 대한 자신의 실력증명이듯이, 제안서도 마찬가지다. 단지 그걸 '고객'에게 해내야한다. 개발자도, IT 전문가도 아닌 고객들에게 설명하려면 - 결국엔 내용을 풀어서 말해줘야한다. 그 과정에서 그들의 신뢰를 얻는 것이고, 좋은 서비스가 만들어질거라는 확신을 과정이다. 영업적인 측면에서의 '이미지'가 아니라, '논리적인 측면에서의 설득'이 필요한 것이다.
- 그렇다면 이걸 '어떻게 풀어줘야 더 잘 쓸수있는가'에 대해서는 나중에 좀 더 정리를 해봐야겠다.
