프로젝트를 진행하면서(요구사항 추적)

어느새 1년짜리 프로젝트를 진행한지도 4개월이 지났다.

기존의 생각과 계획과는 1개월의 차이를 보이면서 조금씩 진행되고 있다.

 

역시나 하는 문제들이 조금씩 나타나기 시작했다.

현재 하는 프로젝트는 새로운 창고관리 시스템을 개발하는 것인데,

운영적인 부분이 전혀 없는, 즉 새로운 창고를 짓고 그곳에 시스템을 도입하는 것이다.

그러다 보니 고객의 요구사항은 자꾸만 바뀌고 고객 또한 이러한 대규모 시스템을

전혀 운영해 본 경험이 없다보니 이러한 문제들이 생겨나기 시작했다.

 

리스크 관리를 통해서 자주 변경되는 요구사항에 대해서 감시를 해가고 있지만,

현장의 사람과 대화를 나누는 역할을 하는 사람이 요구사항에 대해서

너무 둔감한 상태에 다가 그냥 바꾸면 되지 하는 생각이 너무 큰 것 같다.

첨부터 고객과 대화를 나눌 때 정형화된 포맷을 통해서 자주 대화를 나누고

그 내요을 체계적으로 정리를 해야하는데 그 때 그 때 생각나는 대로

포맷을 변경시켜 나간다. 문서 포맷을 결정해서 그 곳에 기록을 해나가면서

요구사항을 적절하게 관리할 수 있는데 이러한 부분이 없이

생각나는 대로 정리를 하다가 보니 결국 전체의 개발 프로세스에 커다란

영향을 끼치고 있다.

 

책에서만 보는 요구정리 및 요구사항 추적은 실제 개발환경에서는

생각만큼 적용하는 것이 쉽지가 않다. 많은 부분에서 견해차이가 발생하기 때문이다.

물론 하기 싫다는 그런 의미보다는 이러한 부분을 전혀 해 본 경험이 없는 것이

가장 큰 원인인 것 같다.

 

개발자들도 마찬가지이다. 실제 문서를 만들기 보다는 프로그램부터 만들고

거기에서 전체적인 이미지를 도출해 낸다. 결국 자기가 지금까지 해 온 경험을

바탕으로 진행시키려고 하고 있다.

 

변화는 많은 부분에서 필요하다. 특히 개발 프로세스의 정립에서는

현재 프로젝트에 참여하는 많은 사람들이 같은 생각과 같은 의견과 견해를 가지고

행동을 하지 않으면 단계마다 많은 차이를 만들어 내고 결국 코딩에서

모든 부분을 해결하려고 생각을 한다. 하지만 코딩에서 문제 해결을 하려는 순간

이미 프로젝트는 죽음의 행진을 시작을 암시하고 있다.

 

문서를 만들기 싫다. 코딩부터 하고 싶다. 이런 개발자들에게는 

변하는 요구사항에 대응하는 코드를 작성하면서 자신의 코드가 점점

스파게티가 되어가는 것을 느끼는 순간까지 깨닫지 못한다.

밤 늦게까지 고생을 하면서 결국은 자신의 문제라기 보다는

변하는 요구사항 탓하게 된다.

 

프로젝트에서 요구사항의 변경은 필수사항이다. 이러한 요구사항 변경에

원할하게 대처하기 위해서는 현재 프로젝트에 참여하는 모든 사람들이

적절한 프로세스로 관리를 해 나가야 한다.

 

현장의 사람들과 대화를 나누는 사람의 경우는 더욱더 중요한 역할이다.

 

지금도 늦지 않았다고 생각한다. 현재의 프로젝트에서 변하는 요구사항에 대한

추적을 현장 대응자에게 요구할 생각이다. 일정한 포맷으로 적절하게

사람의 머리속에서 만 대응을 하거나 머리에 남겨진 설계서보다

문서로 남겨서 모두가 공유할 수 있는 프로세스와 조직이

결국 프로젝트를 성공적으로 이끌 수 있다.

 

이것이 고객과 내가 성공하는 Win-Win전략이라고 생각한다.