6장 ) 수주를 돕는 SI 제안서 쓰기

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

SI 개발 업체에서 일을 한다면 공공 입찰 제안서를 반드시 작성하게 된다.

제안서에서 개발자는 주로 기술 부문을 쓴다.

제안서의 기술 부분은 대부분 그림과 표로 구성된다. 개발자가 제안서에 쓰기 어려운 것은 전략적 제안에 관한 것이다.

제안 요청서 분석

제안 PM은 거의 모든 요구를 제안 요청서를 기반으로 한다.

• 제안 요청서는 고객이 제안을 요청하는 문서

제안 요청서는 제안서 작성의 시작이다. 제안 요청서 안에 목표 시스템, 하드웨어 구성도, 소프트웨어 구성 등등이 모두 포함되어 있으며 이유와 배경, 상황과 답 모두 포함되어 있다. 따라서 잘 분석하고 작성해야 한다.

논리적 완결성

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

해당하는 항목 안에 포함되는 내용을 작성해야 한다.

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

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

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

고객이 문제를 중대하게 생각하고 제안사가 그 문제를 해결할 능력이 탁월하다면 경쟁사와 세부 기능이나 스펙을 비교해서 제안해야 한다.

동시에 강점을 강조해야한다.

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

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

경쟁사와 다른 접근법을 찾아야 한다.

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

고객이 사소하게 생각하는 문제를 제안사가 탁월하게 해결 가능한 경우, 제안사의 강점이 하나인 경우 고객이 그 문제를 중대하게 인식하도록 만들어야 한다.

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

고객이 문제를 사소하게 생각하고 제안사도 내세울 만한 솔루션이 없는 경우, 보통 제안서에서 다루지 않거나 평이하게 쓰고 넘어간다.

3. 고객의 요구사항은 변할 수 밖에 없다

개발자는 고객의 요구사항을 받아서 분석해서 개발하는 것이 아니라, 고객에게 요구사항을 제시해서 고객이 선택하게 만들어야 하고 그 선택에 따라 개발해야 한다.

또한 고객의 요구사항이 끊임없이 변한다는 것을 이해해야 개발자가 대응 할 수 있다. 가장 좋은 방법은 요구사항 정의와 구현, 고객의 점수 사이의 시간 차이를 줄이는 것이다.

개발 전에 고객과 요구사항을 다시 한번 구체적으로 점검해야 한다.

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

요구사항은 개발자 관점과 고객 관점이 다르다.

⇒ 가장 좋은 것은 개발자의 시간을 적게 쓰면서도 고객의 만족도가 높은 기능을 잘 개발하는 것이다. 즉, 고객의 총 만족도를 높인다.

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

또한 특별한 기능을 하나쯤 만들어야 한다.