[경험담] 성공적인 프로젝트 수행을 위해 요구사항 정의가 중요한 이유(야근을 하게 되는 이유)

오늘은 프로젝트를 수행하기 전 요구사항 분석과 정의가 얼마나 중요한지 경험담을 통해 알려드리겠습니다. 

 

프로젝트를 고객이 발주할 때는 RFP라는 제안요청서를 작성하게 됩니다. 

즉, 고객입장에서 고객이 원하는 요구사항을 정의한 문서인거죠. 

이 문서를 업체들이 확인하고 수행할 수 있는지 여부를 판단하고 제안서를 작성해서 입찰을 하고 사업을 수주하고 프로젝트를 진행하게 되는거죠. 

(프로젝트 전반적인 진행 프로세스는 다음에 알아보도록 하겠습니다. )

 

 

제안요청서에 적힌 한 줄의 요구사항

얼마전에 제안요청서에 이런 요구사항이 적혀있었습니다. 

 

요구사항 : 물품 인수인계 관리

 

여러분은 어떠신가요? 저 문구를 보고 어떻게 구현할지 머리에 그려지시나요?

저 요구사항에는 얼마의 금액(FP)가 산정되어 있을가요? 

저 문구를 구현하는데 일정은 얼마나 산정해야 할지? 난이도가 얼마나 될지? 위험요소는 뭐가 있는지?

감이 오시나요?  

인수자가 물품목록에서 인수할 물품을 선택하고 저장

인수자가 인목록에서 인수할 물품을 최종 확인 후 저장

아마 이정도 선에서 생각하시고 별거 아니네 하실 수 있을 겁니다. (제 생각은 뒤에서 말씀드리겠습니다.)

 

보통, 업체에서는 제안서를 작성할 때에는, 즉 입찰을 준비할 때에는 일일이 자세한 사항을 확인하기 힘들기 때문에 일단 제안서를 작성하고 사업을 수주한 후에 생각해보자 하는 경우가 많습니다. 

그런데 이렇게 사업을 시작하게 되면 실제 개발 시작해보니 난이도와 개발해야할 범위 등이 너무 넓어서 개고생을 하게 됩니다. 

 

 

요구사항 정의에 따른 영향도

요구사항을 어떻게 정의하느냐에 따라 많은 부분이 영향을 받습니다. 

1. 일정 : 화면을 2개만 만들면 되는줄 알았는데 4개를 만들어야 하거나...

2. 돈 : 초급이 만들 수 있을 줄 알았는데 중급이 투입되어야 한다거나.. (무리하게 초급을 시키면 일정에 또 영향)

3. DB설계 : 엔티티(테이블)나 속성(컬럼) 개수가 늘어나야 하거나...

 

실제 개발을 할 때 모든 요소는 시간(사람)이 투입된다는 걸 명심해야 합니다. 아무리 사소한거라 할지라도 프로젝트는 사람이 수행하는거고, 그 사람의 시간을 투입해야하는 건 일정에 반드시 영향을 미치게 됩니다. 

(그래서 실제 SI 프로젝트의 경우 야근을 많이 하게 되는거 같습니다 )

 

 

제가 요구사항을 봤을 때 들었던 생각

1. 물품을 인수인계할 수 있는 주체는 누구인지? 기관 대 업체? 기관 대 기관? 업체 대 업체? 
2. 어떤 권한을 가진 사용자가 인수인계를 등록할 수 있는지? 업체에 속한 사람 아무나 가능한지? 특정권한을 가진 사용자만 가능한지? (사용자 권한관리에까지 영향을 미칠 수 있음)
3. 인계자가 인수자를 지정할 때 기관(업체)만 정하면 되는지? 아니면 실제 인수할 사용자까지 정해야 하는지?
4. 인수할 사용자를 지정할 경우 인수할 기관(업체)의 사용자 정보는 준비되어 있는지? (즉, 인수할 기관(업체)의 인수담당자가 시스템에 회원가입을 하고 권한을 획득해야 인수인계 프로세스가 진행되어야 할 수 있음). 
   그리고 동명이인이 있을 수 있으므로 사용자명 이외에 식별할 수 있는 항목(부서, 연락처 등)이 따로 저장하고 있는지?
5. 인수할 사용자를 지정하지 않을 경우 인수 최종 확인은 누가 하는지? 권한없는 사람, 아무나 인수를 한 경우 어떻게 되는지? 
6. 혹시 인수 확정 또는 반려를 인수자가 잘못 선택한 경우 다시 되돌리는 프로세스가 필요한지? 다시 되돌리는 프로세스가 필요하다면 이력으로 남겨야 하는지? 
7. 인계 등록, 인수 확정(반려), 인수 확정(반려) 취소 등의 행위가 일어났을 때 대상자들에게 알림(메일, 문자 등)이 가야하는지? 알림이 갔는지 또는 확인했는지 여부도 조회가능 해야하는지?

 

저는 제안요청서에 명시된 저 요구사항을 봤을 때 위와 같이 요구사항을 좀 더 디테일하게 정의하는데 필요한 질문들이 주르르륵 생각이 들었습니다. 다시 보니 어떠신가요? 초급 혼자서 개발할 수 있을가요? 화면은 몇개를 만들어야하고, 일정은 얼마로 잡아야할지 감이 오시나요? 물론 저 질문에 대한 답변을 고객이 어떻게 하느냐에 따라 차이가 많이 발생합니다. 

 

진짜 문제는....

그런데 저 요구사항 정의가 프로젝트를 수주하고 이미 발을 담근 이후에 즉, 납기일과 인력이 결정된 후에 이루어진다는게 문제입니다.

'고객이랑 잘 협의하면 되지..' 라고 생각하고 들어갔는데 협의가 잘 안되면요? (보통 안됩니다. ㅎㅎ) 야근 시작인거죠.

 

 

그럼 어떻게 해야하나?

제안요청서가 나오고 나서 입찰할 때까지 보통 한달 이상의 시간이 주어집니다. 사전규격공개 기간까지 고려하면 좀 더 긴 시간이 주어지는 거죠. 이 기간에 제안요청서에 애매한 요구사항은 고객에게 확인을 받는게 좋습니다. 이 말이 이런 의미인지.. 물론 앞에서 본 것처럼 디테일한 요구사항 정의(확인)까지는 안될겁니다. 하지만 일정 및 난이도에 영향을 미칠거 같은 부분은 미리 고객에게 확인하는게 좋습니다. 

 

그리고 실제 사업에 투입해서 요구사항 분석하고 정의할 때 앞에서 살펴본것처럼 디테일한 부분까지 고객과 협의를 하는게 좋습니다. 그렇지 않으면 나중에 통합테스트를 할 때 고객이 실제 사용해보니 불편한 점들이 발견되어서 개발을 요청하는 경우가 많습니다. (예를 들어 인수자는 특정 권한(재무 담당 같은)을 가진 사용자만 가능하도록 하자. 알림이 없으니까 인수인계를 위해서는 전화통화를 반드시 해야하거나 처리가 늦어지는 경우가 많으니 알림 기능을 넣어달라 등)

 

 

 

이상으로 요구사항 정의가 중요한 이유와 영향도 등을 살펴봤습니다. 

한줄짜리 요구사항도 가볍게 보지 말고 제안서를 작성하는 시점부터 깊게 분석하는 자세가 필요한거 같습니다.