요구사항

지난번 내용 중 제안서를 위한 일반적인 프로세스 6단계에 대해서 대략 정리하였는데 이를 좀 더 자세히 알아보자. 우선 제안서는 설득의 글이다. 다시 말해 단편적 지식의 나열이나 하나에 집중하기보다는 전체적인 맥락을 이해하고 하나의 이미지로 접근해야 한다. 그 중심엔 고객이 있다. 고객이 결정되고 나면 그 고객의 모든 것에 대해 알아야 한다. 

 

모든 것을 알기 위해선 먼저 기준이 필요하다. 그 기준의 부합 여부에 따라 전략, 전술이 달라진다. 기준은 가설에 따라 설정된다. 가설을 세우고 가설을 검증하는 과정을 반복하면서 우리는 고객에 좀 더 가깝게 접근할 수 있다. 물론 준비된 고객들도 있지만 대부분은 강한 니즈와 문제의식을 가지고 있으면서도 그래서 무엇을 하고 싶은지를 명확히 표현하지 못하는 경우가 많다. 

 

이 부분은 문제에 대해서는 잘 알지만, 문제점, 즉 원인을 파악하지 못하는 경우다. 문제와 문제점은 다르다. 가설을 세우고 검증하는 과정은 문제에서 문제점으로 접근하는 최단의 경로이다. 이를 통해 고객은 문제점을 인식하고 제대로 원하는 것이 무엇인지 표현할 수 있다. 제안서는 이를 도와주는 설득의 도구이다.

 

 

가설을 세울 때 필요한 것이 무엇인가? 그것은 정보이다. 많은 정보를 획득할수록 제대된 가설 또한 수립할 수 있다. 물론 고객에 대한 정보가 아주 완벽하게 수집되었다 해도 이런 정보들을 친절히 알려주고 가르쳐 주는 고객은 거의 없다. 따라서 한정된 정보 속에서 우리는 실마리를 찾아내야 하는 것이다.

 

여기서 제대로 된 가설은 없을 수 있다. 가설이 맞고 틀리고가 아니고 당연히 잘못되어 있을 수도 있다. 하지만 가설을 통해 고객이 정말 중요하게 생각하는 점을 그려보는 것이 진짜 중요한 일이다. 가설이 없다면 중구난방 횡설수설할 수 있으며 정보의 중요도도 알아내지 못할 수 있다. 요구사항 아래 잠재적 요구사항을 끄집어내는 일 또한 우리의 일이다.

 

정보는 관점이 중요하다. 수집하되 하나의 단면만 보면 안 된다. 즉 고객, 경쟁사, 고객의 고객 및 거래처의 관점이 필요하다. 이를 통해 제대로 된 요구사항을 확인해 볼 수 있다. 또한 정보는 숨어있는 부분도 많다. 그래서 일반적인 정보와 더불어 고객에게서 입수해야 할 정보도 꼼꼼하게 챙겨야 한다.

 

수집, 획득된 정보는 면밀한 분석이 필요하다. 그와 동시에 가설을 준비한다. 가설은 정보수집의 관점들을 토대로 고객의 장단점 및 기회와 위기를 참작한다. 또한 제약조건은 두지 않고 고객의 눈높이 맞춰 설정해야 한다. 가설은 검증(사실임을 증명할 가능성, 거짓임을 증명할 가능성, 결과에 대해서는 재현 가능성)할 수 있어야 하며 더 간단하거나 정확한 방법을 설명할 수 있다면 다시 설정해야 한다.

 

 

요구사항 정리는 가설의 정리라고도 할 수 있으며 일종의 사전 제안서 형태로 할 수 있다. 여기에는 설정한 가설을 구체적으로 기술하고 고객 요구사항과의 일치성, 또한 어느 부분이 잘못되었는가를 확인하고자 함이다. 이를 통해 수집된 정보를 제대로 분석했고 이해했는지, 잠재적 요구사항들이 도출되었는지도 가려낼 수 있다.

 

이러한 사전 제안서는 가설검증의 도구라고 보면 된다. 그렇기 때문에 세밀하고 구체적인 내용으로 정리해야 한다. 명확하지 않으면 안 된다. 그래서 정성적인 부분도 정량화하는 노력이 필요하다. 또한 하나의 사실에 대한 주변 인터페이스를 살펴야 한다. 누구에 의해서, 누가 작성했고 어디에 쓰이는지, 그 결과는 무엇인지를 명확히 알아야 한다. 정보의 객관화가 여기서 필요하다. 정보의 논리 근거가 필요하다.

 

 

준비된 자료를 바탕으로 가설이 맞는지 검증하는 단계이다. 이때 주된 방법은 인터뷰이다. 다만 목적을 명확하게 하는 인터뷰를 준비하여야 한다. 경청을 기본으로 알고 싶은 내용을 관계자에게 질의응답 방식을 통해 정보를 확인하고 알아내기 위함이다.

 

우리가 대화 속에서 정보를 획득하는 것이 쉬워 보일 수도 있지만 이는 대단히 어려운 일 중 하나다. 그래서 관련한 여러 기술들을 참고해 볼 수도 있는데 그래서 많은 경험 또한 필요한 부분이다. 특히 인터뷰의 목적을 명확히 하는 것은 여러 인터뷰 방식 중 우리는 정보수집을 위한 인터뷰를 하려 하기 때문이다. 이를 중심으로 설득 또한 같이 진행하게 된다.

 

인터뷰는 인터뷰 대상자를 선별한다. 대상자가 누구냐에 따라 그 결과는 천차만별이다. 그러므로 아무나 대상자로 하면 시간과 비용만 낭비된다. 실무자인지 관리자인지 혹은 경영자층인지에 따라 정보의 양과 질이 다르다. 그래서 수집된 정보의 분석이 필요한 것이다. 대상자가 선별되었다면 질문을 준비해야 한다. 질문의 목적을 통해 다양하게 준비하고 리스트를 만들어 관리한다. 

 

 

인터뷰가 진행된다. 앞서 언급했듯이 그 목적이 중요한 만큼 인터뷰 대상자에게 목적을 알리고 최대한 협조할 수 있는 분위기를 조성한다. 이 부분은 의사소통의 스킬을 기반으로 대상자에게 어떠한 부분에 관심이 있는지, 그들의 입장이 무엇인지, 그리고 대답하기 곤란하지 않은지 면밀히 살펴야 한다.

 

인터뷰가 끝나면 그 내용을 제안에 반영하기 위해 가설을 검증하고 수정을 진행한다. 만약 가설이 고객의 요구사항과 일치하면 상관이 없지만 그렇지 않다면 계속 반복, 피드백하여야 한다. 그러기 위해선 인터뷰 내용을 잘 정리한다. 별도 회의록을 만들어 작성하고 필요시 녹취 등을 통해 정보의 유실을 막는다. 

 

인터뷰 내용을 기술할 때 가장 중요한 점은 인터뷰에 참석하지 않은 인력이 그 내용을 보더라도 당시의 내용은 물론 상황까지도 알 수 있도록 쉽게 써야 하는 것이다. 그러기 때문에 답변의 뉘앙스까지도 잡아내야 한다. 그러한 미묘한 차이점이 중요한 의미를 지니고 궁극엔 결과도 다르게 나타날 수 있기 때문이다.

 

정리된 회의록을 통해 가설 검증을 수행하고 문제가 있다면 수정작업을 진행한다. 이는 why, what, where를 명확히 하는 작업이다. why와 what이 명확해질 때까지 계속 확인을 하며 이를 통해 제안범위가 최종적으로 확정된다. 이 세 부분이 스스로 납득이 간다면 이제 최종적인 제안서 작성에 들어갈 준비가 된 것이다.

 

 

제안서는 템플릿이 많다. 하지만 고객사가 제공하는 경우도 있을 수 있기 때문에 큰 제약이 되지는 않는다. 형식도 중요하지만, 내용이 더 중요하기 때문이다. 그래서 작성에 많은 신경을 써야 한다. 다른 것도 마찬가지지만 제안의 제목은 확정이 되었기 때문에 제일 어려운 장애물은 제거되었다.

 

그다음 할 일은 목차를 작성하는 것이다. 사실 제목과 목차가 전부이다. 대부분은 제안서에서 제목과 목차가 차지하는 비중은 80%이다. 나머진 사전 제안서를 바탕으로 내용을 채워 넣는 일이기 때문이다. 목차를 통해 스토리를 구성하고 조립한다. 소설처럼 극적인 장치도 마련할 수 있다. 이런 부분은 물론 충분한 논의와 사유가 있어야 하지만 목차 구성만으로도 우린 상대를 설득할 수 있어야 한다.

 

제안서는 그 범위와 경중 등에 따라 혼자 쓸 수도 있고 팀으로 작성할 수도 있다. 최대한 간결한 표현으로 간단하게 이해할 수 있도록 작성해야 한다. 오해가 없어야 하며 사실에 근거하여 기술한다. 여기서 금물은 많이 써봐서 혹은 잘 쓰기 때문이라는 과신이나 선입견이다. 그래서 다양한 관점의 검토가 필요하다. 작성된 제안서는 반드시 객관적 입장에서 평가를 할 수 있는 사람에게 검토받아야 한다.

 

 

큰일이 모두 끝났다. 하지만 대미를 장식할 더 큰 일, 발표가 있다. 제안은 발표로 완결된다. 제아무리 훌륭하게 작성된 제안서도 어떻게 발표하느냐에 따라 그 결과는 달라진다. 다르게 이야기하면 미흡한 제안서라 할지라도 훌륭한 발표를 통해 제안 기회의 불씨를 살릴 수도 있다는 것이다. 

 

이렇게 중요한 발표는 제안서를 완전히 체화한 발표자를 중심으로 열의와 의욕을 불태워야 한다. 당연히 기술력을 기반으로 고객에게 신뢰를 주어야 하며 요구사항을 제대로 충족시켜 주어야 한다. 고객의 혼란을 야기할 정보들은 정리가 되어야 하며 누구에게 제안하는지, 왜 무엇을 하는지를 확실히 하고 넘어간다. 이를 통해 작성된 스토리에 고객이 동감하고 감동하며 진실한 태도에 고개를 끄덕일 수 있다.

 

 

 

 

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

 

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

 

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

 

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

 

 

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

 

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

 

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

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

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

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

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

 

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

 

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

 

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

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

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

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

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

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

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

 

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

 

 

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

 

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

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

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

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

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

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

 

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

 

 

 

 

소프트웨어 개발은 소프트웨어를 생성하고 유지하는 과정으로 다양한 방법과 기술이 사용되며 프로젝트의 특성에 따라 최적화된 방법과 기술을 선택하는 것이 매우 중요하다. Tailoring은 특정 프로젝트의 요구 사항에 대하여 소프트웨어 개발 프로세스나 방법론을 적절하게 조정하고 필요 활동을 가감하는 것이다. 다시 말해, 소프트웨어 개발 프로세스는 규모, 복잡성, 요구사항, 조직 문화 및 프로세스 등 여러 제약 조건에 따라 달라지는데 이러한 요소를 고려하여 프로젝트에 가장 적합한 프로세스를 선택, 조정하는 것을 의미한다.

 

이런 조정의 조치는 소프트웨어 개발 프로젝트의 성공에 핵심적인 요소이다. 모든 것이 목표를 지향하고 나아가지만 100% 수행될 수는 없다. 그래서 프로젝트 진행 중에 발생하는 각종 위험을 줄이고, 품질을 향상하며, 시간과 비용을 단축할 수 있는 방법으로 우리는 Tailoring을 한다. 그래서 Tailoring은 프로젝트 초기 단계에서 고려하고 실시하여야 한다. 프로젝트가 시작되면 진행 중 반드시 새로운 요구사항이 나올 수 때문에 Tailoring을 통해 이러한 요구사항을 미리 반영하는 것이다.

 

 

Tailoring에는 몇 가지 종류가 있으며 이를 통해 부분별로 최적화를 진행할 수 있다. 이는 프로젝트의 특성, 목적, 예산, 일정, 규모, 복잡성, 기술적/사업적 요구사항, 개발역량, 도구, 조직문화 및 각종 제약조건에 따라 고려되고 선택될 수 있다.

 

: 소프트웨어 개발 프로세스는 소프트웨어를 개발하기 위한 일련의 단계와 활동으로 구성되어 있는데 이 특성에 맞게 소프트웨어 개발 프로세스를 조정하여 프로젝트 규모에 따라 단계와 활동을 강화 또는 제거하여 효율적인 운영을 하는 것이다.

 

: 프로젝트 기술 또한 프로젝트의 특성에 맞춘다. 무조건 고급기술을 지향하는 것이 아니라 요구 성능에 적절한 기술을 도입하여 반영하고 운영하는 것이다. 이럼으로써 불요한 기술 비용 등을 줄일 수 있다.

 

: 소프트웨어 개발 프로젝트의 인력은 프로젝트의 특성에 맞게 조정해야 한다. 개발 프로젝트 난도가 높다면 고경력의 인력을 보다 많이 투입할 수 있는 것이다.

 

 

Tailoring은 개발 프로젝트의 특성을 고려하여 프로젝트의 목표, 범위, 일정, 예산, 인력 및 기술에 따라 어떤 방법과 기술이 필요한지를 판단해야 한다. 이를 위해 다음의 단계를 거친다.

 

: 프로젝트의 목표와 요구 사항을 분석하고 이해한다. 이를 위해 이해당사자들과의 의사소통, 현장 조사, 문서 검토 등을 수행하여 요구 사항을 명확히 이해하고 프로젝트의 고유한 요소를 파악한다.

✅ 방법론 선택
: 요구 사항 분석을 토대로 조정이 필요한 영역을 파악하고 이에 따른 방법론을 선택한다. 이는 기준이 되는 표준 방법론에서 일부 요소를 선택하거나 다른 방법론을 조합할 수도 있다. 

✅ 프로세스 조정

: 방법론을 조직과 프로젝트에 맞게 조정한다. 이 과정에는 수명주기 단계 추가 또는 제거, 프로세스 세부 조정, 가이드라인과 절차 수정 등이 포함될 수 있다.

✅ 도구와 기술 선택

: 조정된 방법론에 맞는 도구와 기술을 선택한다. 프로젝트에 필요한 특정 기능을 구현하기 위해 특정 개발 도구나 프레임워크를 도입할 수도 있다. 어느 하나를 끝까지 고수할 필요는 없다.

✅ 팀 구성원 역할 및 책임 조정

: 조정된 방법론에 따라 팀 구성원의 역할과 책임을 조정한다. 팀 구성원은 방법론에 맞게 업무를 수행해야 하고 원활한 의사소통과 협업을 진행해야 한다. 팀원들의 역량과 역할에 따라 재조정 또는 새로운 역할을 부여할 수 있다.

✅ 프로젝트 관리 및 모니터링

: Tailoring 된 방법론으로 프로젝트를 관리, 모니터링한다. 이는 일정 관리, 리스크 관리, 품질 관리, 의사소통 관리 등을 포함으로써 프로젝트 진척 상황을 주기적으로 검토하고 필요한 조정을 수행하여 프로젝트 목표 달성을 보장한다.

✅ 지속적 개선

: Tailoring은 프로젝트 진행 중에도 지속해서 개선되어야 한다. 이를 통해 방법론의 효과성과 프로세스의 개선점을 도출하고 반영한다. 

 

 

소프트웨어 개발은 정말 복잡한 과정이다. 이러한 개발 프로젝트를 성공적으로 수행하려면 다양한 요소를 고려해야 하는데 Tailoring이야말로 최상의 결과가 나오도록 모든 것을 잘 매만져 주는 일이다. 이를 통해 프로젝트는 프로젝트의 특성에 맞게 최적화될 수 있고 그 효과는 여러 가지로 나타난다.

 

✔️ 요구 사항 충족

: 프로젝트 특정 요구사항을 위해 방법론이 조정되면 큰 틀에서 매우 효과적인 방법론의 채택을 통해 프로젝트의 속도를 향상한다. 이때 방법론을 처음부터 끝까지 고집할 필요가 없으며 필요 부분에 대해서만 다른 방법론을 활용할 수도 있다.

✔️ 조직 맞춤화

: 고유한 사업적 요구 사항과 제약 조건을 가진 조직은 Tailoring으로 인하여 조직 내 체계를 활성화하고 조직에 맞는 색깔을 찾아 입힐 수 있다. 이에 따라 살아 움직이는 조직으로 보다 유연한 관리가 가능하다.

✔️ 자원 최적화

: 프로젝트 규모와 복잡성에 따라 초기 계획을 지속 관리하고 필요한 자원과 비용을 효과적으로 조절할 수 있다. 즉, 불필요한 자원의 집행을 사전에 확인, 관리할 수 있는 역량을 갖추어 비용과 시간을 절감할 수 있다.

✔️ 프로젝트 성공

: 프로젝트를 성공시킬 수 있는 확률이 높다. 방법론의 수정으로 조직과 프로젝트에 최적화되고 보다 더 적절한 접근 방식에 따라 위험을 완화하고 품질을 향상할 수 있다. 이는 궁극적으로 고객 만족도를 높인다.