📝 김철수님의 '개발자의 글쓰기'를 읽고 정리한 글입니다. 문제가 될 경우 삭제 조치하도록 하겠습니다.

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

1.1 개발자와 제안 PM의 차이

SI만 제안서를 쓰는 게 아니라, 솔루션 업체, 서비스 기업도 다 제안서를 쓴다.

PM이 개발자가 아니라면 기술 부문을 온전히 책임져야 한다.

제안서의 시스템 구성도, 시스템 기능, 사양, 구성 장치, 규격 등은 그림과 표로 구성되어서 이전 거를 재활용하거나 참고가 가능한데 반해

목적, 목표, 전략, 방안, 기대효과와 같은 것들은 서술해야 하며 서비스마다 다르기에 작성하기 어렵다.

1.2 시스템 구성도의 본질은 그림이 아니다

제안요청서에 있는 시스템 구성도 그림을 넣고 시스템의 성능, 안전성, 확장성을 위해 다음과 같이 시스템을 구상함. 이라고 적혀있는 걸 보자

이 내용은 시스템이 응당 갖춰야 할 것인데 이렇게 그냥 적은 것이다. 이는 배고픔을 없애기 위해 밥을 먹는다와 같다.

이렇게 당연한 말을 적지 말고, 목적, 목표, 전략, 방안, 효과, 특징, 장점, 강점을 기술해야 한다.

1.3 첫째, 제안요청서 분석

제안요청서에는 고객이 제안을 요청하는 문서이기에 제안을 요청하는 배경, 사업의 목적, 요구 사항, 목표 시스템, 현재 시스템 등을 적어야 한다. 그렇기에 모든 문제와 답은 제안요청서에 있어 답안지라고 보면 된다. 그래서 개발자는 그림만 떡하니 올리면 안 된다. 제안요청서 곳곳에는 기술 부문을 어떻게 작성해야 하는지 힌트가 있어 그걸 참고로 기술 부문을 전략적으로 작성하면 된다.

1.4 둘째, 논리적 완결성

제안서는 1쪽부터 100쪽까지 차례대로 읽는 것이 아니기에 기승전결이 있는 소설이 아니다. 그래서 항목 작성을 잘해야 한다. 해당 항목에 필요한 구성이 다 들어가야 한다.

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

2.1 문제 인식과 문제 해결 능력

제안서의 시작은 고객의 문제 인식이 중요하다 비용 대비 문제 해결 효과가 낮으면 문제를 그냥 놔두거나 한다. 반대로 해당 문제를 중요하게 생각하는 고객도 있다.

이처럼 고객의 문제 인식 정도가 제안서에 영향을 주는 것처럼 제안사의 문제 해결 능력도 영향을 끼친다. 고객이 생각하기에 해결 불가능할 것을 제안사의 솔루션으로 해결할 수 있으면 된다.

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

경쟁사와 비교하여 더 편하다, 안정성이 있다, 새로운 AI 도입과 같이 강점을 강조해야 한다.

무엇보다 타사와 비교해서 설명하면 한눈에 들어오고 본 서비스를 부각시킬 수 있을 것이다.

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

경쟁사 A가 운전자 특성을 반영한 인공지능 경로 추천 솔루션을 가졌다고 보자. 이를 보고 우리 회사도 한번 AI 적용을 해보겠다 라는 등이라고 하면 안 된다. 다른 접근법을 가져서 우리 회사는 설문을 하기에 AI가 학습할 시간도 적고 정확하며 개발 기간도 빠르다고 제시해야 한다.

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

인공지능 기반 맞춤 경로 서비스 기능이 있는데 고객이 해당 기능이 필요 없다고 생각해 보자 이런 경우에는 기존의 맞춤 경로와 인공지능 맞춤 경로 서비스의 차이를 부각해야 한다.

인공지능 기술 발전으로 자율주행차와 운전자 맞춤형 서비스에 대한 운전자의 인식이 높아지면서.. 도입 시도가 많아지고 있다.. 제안사는 이미 기술을 개발해 국내에서 가장 앞서 있다….

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

고객과 제안사가 문제없다고 생각하는 문제를 다른 경쟁사가 들고나왔으며 심사위원이 이 회사는 이러한 문제를 이렇게 해결했는데 본 사도 확실한 솔루션이나 방안이 있냐고 물어보는 경우가 있다.

그렇기에 예상 질문과 답 정도는 준비해야 한다.

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

3.1 개발은 고객 요구 실현

개발은 고객의 요구사항을 실현하는 것이다 하지만 요구사항이 바뀌기도 하고 새로운 요구사항이 추가되기도 한다. 그렇기에 개발 도중에 갈아엎거나 마지막에 급하게 추가하는 경우가 있기에 이 이류를 잘 알고 대비해야 한다.

3.2 요구사항을 분석하지 말고 제시하라

고객은 자기가 원하는 제품이 정확히 뭔지 모른다. 제안요청서도 같다. 고객의 요구사항을 받고 분석해서 개발하는 게 아니라 다시 고객에게 요구사항을 제시해 고객이 선택하게 해야 하며 그에 따라 개발해야 한다.

디자인 요구 사항 : 1024:768 픽셀 해상도에 최적화된 화면으로 구현한다.

이 요구사항을 보면 스마트폰, PC에서 보이는게 다르기에 개발자는 요구사항을 다시 제시해줘야 한다.

요구사항 문제 : 1024x768 해상도는 기기에 따라 보여지는 페이지가 다름

대안 제시 : 해상도가 줄어 3페이지를 넘기는 경우에는 네비게이션 태그가 보이게 한다.

3.3 변화하는 요구사항에 대비하라

처음에 고객이 로그인 기능만 넣어달라고 해서 개발을 했다고 보자.

이후에 갑자기 본인인증 기능도 넣어달라고 하면 황당할 뿐이다.

그렇기에 개발하기 직전에 고객과 요구사항을 다시 한번 구체적으로 점검하고 본인인증과 같은 부가 기능들을 제시해서 검토해야 한다.

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

4.1 요구라고 다 같은 요구가 아니다

고객의 만족도가 높은 기능을 먼저 잘 개발하면 고객의 만족도가 올라가기에 개발자의 자원을 고객의 총 만족도를 높이는 쪽으로 설계해야 한다. 그렇기에 요구사항별로 개발 소요 시간과 고객 예상 만족도를 표로 만들면 무엇부터 개발해야 하고 무엇에 더 시간을 써야 하는지 알 수 있을 것이다.

4.2 카노 모델로 본 요구의 세 가지 종류

1. 기본 기능

기본 기능은 요구를 충족하지 못하면 고객이 불만족 하지만, 충족했다고 해서 고객 만족도가 크게 오르지 않는다. (로그인, 로그아웃..)

2. 기능의 성능

기능의 성능은 요구를 충족할수록 고객이 만족하고, 충족하지 않으면 고객이 불만족하는 유형이다. (페이지 로딩)

3. 특별한 기능

특별한 기능은 고객이 그다지 기대하지 않았던 것이어서 충족하지 못해도 불만족스럽지 않는데, 만약 충족하면 만족도가 크게 오른다. (홍채인식 로그인..)

5. 6장을 읽으며 느낀 점

• 시스템 구성도와 같이 그림이 들어가는 것들은 왜 이러한 것들을 썻는지 상세히 쓰는 게 좋다고 느꼈다.
• 제안서에도 항목이 중요하다.
• 항상 경쟁사와 비교하여 우리에게 유리하게 적자
• 항상 경장사를 조사하여 대비해야 한다.
• 고객이 문제를 중요하다고 느끼게끔 만들자
• 요구사항을 곧 대로 믿지 말고 다시 제시하자