[개발자의 글쓰기] 6장. 수주를 돕는 SI 제안서 쓰기

이 글은 "개발자의 글쓰기"를 읽고 좋은 구절들을 기록하거나 느낀 점을 기록하는 글입니다.

개발자의 글쓰기

 

1. 개발자가 알아야 할 제안서 작성 원칙

개발자라고 개발만 하지 않는다. SI에서 일을 한다면 공공 입찰 제안서를 작성해야 하는 경우가 생긴다.

 

첫째, 제안요청서 분석

제안요청서에서 거의 모든 문제와 답이 들어있다. 일부분만 보지 말고 전체를 잘 보아야 한다.

 

둘째, 논리적 완결성

항목을 논리적으로 완결해야 한다.

대부분 제안서를 소설 읽듯이 순서대로 읽지 않는다. 자기와 관련 있거나 관심 있는 항목을 골라 읽기 때문이다.

 

2. 고객의 문제 인식과 제안사의 문제 해결 능력

제안서의 시작은 문제가 아니라 고객의 문제 인식이다.

문제를 문제 삼지 않으면 문제가 되지 않는다.

 

고객이 문제를 어떻게 인식하는지에 따라 제안서의 내용이 달라진다.

제안서의 문제 해결 능력도 제안서에 영향을 끼친다.

 

1. 경쟁사와 비교하여 제안하라

고객이 문제를 중대하게 생각하고 제안사가 해결할 능력이 탁원 하면 경쟁사와 비교한다.

 

2. 일단 동감하고 다른 방안을 제시하라

고객이 문제를 중대하게 생각하지만 제안사가 해결 능력이 미흡하다면 일단 동감한 뒤 다른 방안을 제시해야 한다.

 

3. 고객이 문제를 중대하게 인식하게 만들어라

고객이 사소하게 생각하는 문제를 해결할 수 있고 제안사가 내세울 만한 것이 이거뿐이라면 고객이 그 문제를

중대하게 인식하도록 만들어야 한다.

 

4. 경쟁사의 전략을 확인해서 대처하라

고객이 문제를 사소하게 생각하고 제안사도 딱히 내세울 만한 솔루션이 없다면 굳이 문제를 꺼낼 필요가 없다.

근데 경쟁사가 그 문제를 들고 나올 수 있으니 사소한 문제에 대해 예상 질문과 답 정도는 준비해야 한다.

 

3. 고객의 총만족도를 높이자.

요구사항마다 개발자와 고객의 관점이 다르다. 개발자가 열심히 만든 기능이 고객의 관점에서 마음에 들지 않는다면

노력한 만큼 만족도를 높일 수 없다.

 

가장 좋은 것은 개발자의 시간을 적게 쓰면서 고객의 만족도가 높은 기능을 먼저 잘 개발하는 것이다.

 

개발자는 기본적으로 기본 기능 요구는 모두 수영하되 기능의 성능 요구의 한계를 정해야 한다.

제안요청서나 계약서에 없는 특별한 기능 하나를 개발한다면 개발자의 다른 문제(버그, 해결하지 못한 문제)를 해결해 줄 수도 있다.