고객만족

개발자라는 직업은 많은 능력과 역할이 필요하다. 이는 단순하게 개발에만 국한되어 있지 않다. 모든 것이 개발이지만 개발자가 생각하는 개발은 보통 코딩 또는 프로그래밍만을 생각한다. 하지만 개발이라는 수명주기를 놓고 본다면 프로그래밍은 전체에서 약 20% 정도밖에 차지하지 않는다. 나머지는 기획, 관리, 의사소통, 문서 등 프로젝트 전반의 모든 구성 요소들이 차지한다.

 

‘저는 개발만 하렵니다.’라고 생각한다면 그 넓은 운동장에서 구석 한 귀퉁이에 앉아 모래 장난을 하는 것과 다르지 않다. 특히나 문서로 의사소통하는 프로젝트에서 그 시작 지점의 제안은 누군가가 만들어 주는 것이 아니다. 개발자에게 계속 요구되는 능력 중의 하나로 IT에 관련한 모든 기업, 조직과 인력들에 주어진 과제이다.

 

고객에게 구두로만 내용을 전달할 수는 없다. 결국 손에 문서를 쥐여주어야 하고 그 내용을 그대로 만드는 제안서는 어떠한 방법을 써서라도 부가가치를 높이면서 고객에게 제안한 모든 가치를 인정받을 수 있게끔 작성이 되어야 한다. 그래서 준비 여하를 막론하고 이 과정에서 수많은 시행착오를 거치기 마련이다.

 

제안서는 누가 써주지 않는다. 그 기저에는 개발자가 있다. 그리고 그 개발자가 경력이 쌓이고 시간을 누적하면서 제안개발의 능력을 키우게 된다. 나 자신뿐만 아니라 고객에게 눈을 맞출 수 있으며 고객의 문제에 한 발짝 더 가까이 다가가고 모든 기회를 확대하면 제안에 성공할 수 있다.

 

 

제안은 영업활동이다. 영업은? 개발이 아니다. 그래서 개발자들은 대다수 제안을 남의 일이라고 생각한다. 사업 초기 영업맨들이 열심히 과제를 따와서 제안서를 쓰고 모든 것이 다 된 이후 전달이 되면 그때부터 내가 하는 일이 아니다. 물론 제안과 개발을 분담하는 것이 자연스럽다고 볼 수 있으나 시스템을 만드는 입장에서는 제안은 개발이다.

 

개발자가 제안하고자 한다면, 그 기저에는 다음과 같은 자세와 능력이 필요하다.

 

✔️ 충분한 기술력: 문제 해결력이다. 

✔️ 의사소통 능력: 고객의 요구사항을 제대로 확인할 수 있어야 한다.

✔️ 고객의 문제를 객관화: 명확하고 구체적인 사실에 입각한다.

✔️ 적극적 해결책 모색: 관망이 아니라 수행이다.

✔️ 고객 만족과 매출 확보: 이익 창출

 

즉, 풍부한 IT 지식과 경험을 토대로 한 다양한 문제 접근과 해결책을 강구하고 이에 따른 고객의 요구사항을 만족시킬 수 있는 능력은 개발자만이 할 수 있다. 그래서 단순하게 돌아다니는 템플릿을 하나 가져다 베끼듯 제안서를 만드는 것이 답일 수는 없다. 목적을 달성하기 위한 제안서는 체계적인 프로세스가 있고 도구들이 있다. 

 

또한 제안서는 의사소통의 결과이다. 의사소통을 원활히 하기 위해서 정보를 획득하여 분석하고 목표를 위한 동기를 부여하며 여기에 기반을 둔 최적의 실현 방법을 통한 설득에 있다. 원활한 의사소통은 고객과의 약속을 문서화하며 계약이 된다. 그럼 계약서에는 무엇을 담고 있어야 하는가? 무엇을 전달해야 하는가?

 

✔️ 배경, 현상, 이유: 왜 프로젝트를 하려 하는가?

✔️ 목적과 목표: 프로젝트의 성과는 무엇인가?

✔️ 제안 범위: 시스템화(견적 요건)의 대상은 무엇인가?

✔️ 수단과 방법: 어떻게 구현할 것인가?

✔️ 일정: 납기와 산출물은 무엇인가?

✔️ 체계: 프로젝트 추진은 어떻게 하는가?

✔️ 비용: 투자 판단의 근거는 명확한가?

 

위의 내용 중 가장 중요한 것은 무엇인가? Why와 What일 것이다. 이것이 명확해야지만 나머지 내용들이 의미를 갖는다. 고객이 처한 여러 현상과 문제들, 요구하는 배경과 프로젝트의 필요성, 그리고 문제들을 해소할 구체적인 프로젝트 성과들이 그것이다. 이 배경과 목적은 결국 비즈니스이다. 상호 간의 관계의 정확한 이해가 비즈니스를 알아내는 것이며 이후 제안의 본격적인 작업이 시작된다. 비즈니스를 이해하지 못하면 제안서는 오만가지 형태로 나온다. 이것도 답인 것 같고 저것도 답인 것 같다. 제안서가 달라지는 것은 그 원인을 파악하지 못함에 있다. 제안서는 절대 변화무쌍하지 않다.

 

 

제안서를 위한 일반적인 프로세스는 보통 6단계로 되어 있다. (물론 발주처와 공급처의 입장에 따라 다를 수는 있겠지만 큰 틀에서는 하나의 동일한 흐름이다.)

 

1️⃣ 정보 수집, 분석 및 가설 설정: 고객 정보를 토대로 과제나 요구사항에 대한 가설 수립

2️⃣ 요구사항 정리: 요구사항 도출을 위한 초기 제안

3️⃣ 인터뷰 및 가설 검증: 경청과 검증, 전략회의

4️⃣ 결과정리: 수정과 반복, 확인, 제안팀 구성

5️⃣ 제안서 작성: 명확한 배경과 목적에 대한 해결책 구성, 제안 요약, 제안서

6️⃣ 발표: 고객 설득과 제안 목적 달성

 

앞서도 이야기했듯이 배경과 목적을 알아내기 위한 작업이 우선이 되고 제안서 작성은 그 이후의 일이다. 제안서 작성 전까지 1️⃣에서 4️⃣는 지속, 반복된다. 이를 통해 제안서를 성공시키기 위한 키를 확인한다. 그것은 가설이다. 고객 요구사항을 명확하게 끌어내는 일은 가설을 세우고 그 가설을 검증하는 것이다. 가설은 막연하게 흩어져 있는 여러 사안을 구체화하여 고객과 함께 잠재적인 요구사항까지 명확하게 도출하여 형태를 갖추면 된다. 흔히 고객이 가장 잘 알 것 같지만 의외로 고객 스스로 요구사항을 명확하게 정의하는 일은 드물다. 그래서 개발자가 컨설팅하며 가설을 만들어 검증하는 것이다. 혹 가설에 문제가 있다면 다시 만들면 된다.