요구사항 변경에 대처하는 개발자의 자세

프로그램 개발에서 요구사항 변경은 피할 수 없는 운명과도 같다.

피한다고 피할 수도 없고, 그렇다고 당당하게 마냥 즐길 수도 없는 그런 존재이다.

 

프로젝트는 요구사항, 일정 그리고 인력 자원으로 시작한다.

최종 산출물은 당연히 훌륭하게 작동하는 소프트웨어다.

 

보통 일정과 인력 자원은 변경이 없으니, 흔들리는 요구사항에 따라서 흔들리는 것은 소프트웨어다.

보통의 클라이언트들은 요구사항을 계속 추가하고, 기존 요구사항을 자꾸 변경한다.

변경된 사항에 따른 일정 조절이나 추가 인력 자원 투입은 불가한 경우가 많으니 결국엔 요구사항에 충실하지 못한 소프트웨어가 나오고 만다.

 

예전에는 어떻게 요구사항을 고정할지에 대한 이야기를 했고, 요즘에는 어떻게 변경되는 요구사항에 맞출까를 많이 이야기한다.

 

처음 막연한 구상의 한계를 고려할때 점점 완성되어 가는 요구사항과 각종 문서와 UI, 프로그램들을 보면서 새로운 것이 추가되고, 기존의 요구를 변경하는 욕구는 당연하다.

클라이언트의 요구사항 뿐만 아니라, 기획자, 디자이너와 개발자도 구현 중에 앞서 결정하고 구현했던 내용에서 개선사항을 발견하고 변경을 한다.

 

결국 어느 누구의 문제, 어느 단계의 문제. 어느 방법의 문제라기보다는 프로젝트가 갖는 근본적인 한계이다.

무한정의 시간과 무한정의 자원이 있다면... 하늘에서 내리는 음식만큼이나 어리석은 생각이다.

 

한정된 시간과 자원의 한계를 극복하고 프로젝트를 성공시키는 방법은 요구사항과 소프트웨어 둘이, 경쾌한 음악에 맞춰 한쌍의 남녀가 추는 왈츠처럼, 춤을 추는 것이다.

점점 커져서 전체 그림도 그려지지 않는 요구사항과 점점 그런 요구사항과는 멀어져 가는 소프트웨어가 되면 안된다.

서로를 배려하면서, 리드하기도 하지만 이끌려가기도 하면서 그렇게 서로와 서로를 맞춰 조화를 만들어야 한다.

 

요구사항에 있어 핵심이 되는 욕구(desire)를 추려내고, 이 욕구를 충족하는 사용자의 이익(benefit)에 부합하는 소프트웨어를 개발해야 한다.

분명 핵심이 되는 키는 요구사항에 있어서도, 소프트웨어 기능에도 존재한다.

 

그 키를 찾아내는 것, 그것을 제한된 시간과 자원으로 구현해내는 것이 바로 프로젝트 관리이다.
시간과 자원의 소용돌이 속에서 과연 최적의 선택이 어떤 것인지를 찾아 내는 것이다.