요구사항 관리의 함정

사람들은 얘기한다. 소프트웨어 프로젝트가 실패하는 가장 큰 이유는 요구사항 관리가 제대로 안되기 때문이라고.

글쎄, 딱히 틀린 말이라고 할 수는 없겠지만 그리 스마트한 말도 아니다.

요구사항 관리 서적에 나오는 내용처럼, 문서를 만들고 프로세스를 따르고 요구사항 관리 툴을 사용함으로써 과연 요구사항 관리가 잘 되고 그 결과로 프로젝트가 성공하는 것일까?

아마도 그렇다고 대답하는 사람은 실무 경험이 없는 초보자 내지는 이론가일 것이다. 실무에는 수많은 이해관계가 얽혀있다.

그러한 이해관계의 차이로 인해, 요구사항이 아예 초기부터 드러나지 않는 경우가 많고 또한 ‘비합리적인 이유로’ 변경되는 일도 빈번하게 발생하곤 하는 것이다.

가정해보자. 당신은 요구사항 관련 문서를 잘 작성하여 버전 관리를 하고 있고, 프로세스도 훌륭하고, 툴도 멋지게 사용하고 있다. 그러한 상황에서 고위직 임원이 갑자기 추가하거나 변경시킨 ‘비합리적인’ 요구사항을 어떻게 처리할 것인가? 관리할 수 있을까?

당신은 요구사항 변경의 효과를 측정한 결과, 일정과 비용에 심각한 영향을 미치는 것으로 판단했고 변경을 받아들일 수 없는 것으로 생각하고 있다. 그렇다면 합리적인 프로세스에 의해 구성된 ‘변경 관리 위원회’를 통해 고위직 임원의 요구를 거부할 수 있는가?

현실의 세계에서 그것은 거의 불가능한 일이다. 아마도 그렇게 행동한다면 미움을 사거나, 최악의 경우 해고될 수도 있을 것이다. 책임자인 당신이 고위직 임원의 지지를 잃거나, 또는 해고된다면 그런 프로젝트의 결과는 뻔하다.

실무에서 일해본 사람이라면 그러한 상황이 예외적인 것이 아니라, 책에서 얘기하는 이상적인 상황이 예외적이라는 것을 경험상 잘 알고 있을 것이다.

그래서 보다 정확히 말하면, 프로젝트가 실패하는 가장 큰 이유는 요구사항 관리가 제대로 안되기 때문이 아니라 이해관계자 관리가 제대로 안되기 때문인 것이다. 그것이 보다 통찰력 있는 표현이라고 할 수 있다.

왜 그런가 하면,

'요구사항 관리'라고 표현한 순간, 마치 요구사항 문서, 프로세스, 툴(도구)을 적극적으로 활용함으로써 요구사항 관리가 제대로 될 수 있다는 착각을 불러일으키기 때문이다.

프로젝트 매니저가 합리적인 판단력과 결정권, 그리고 이해관계자 관리 능력을 갖고 있지 않는 가운데, 모든 사람들이 열심히 문서를 만들고 프로세스를 따르고 도구를 사용하는 프로젝트만큼 우매한 것은 없다.

혹시 그러한 가운데에서 잘 된 프로젝트가 있다면 댓글을 통해 나의 짧은 경험과 우매함을 일깨워주기 바란다. 물론 신뢰할 수 있도록, 필자처럼 실명과 구체적 사례를 포함해주시면 감사하겠다.

결론: 주먹구구, 땜방, 맨 땅에 헤딩하기식의 프로젝트는 나쁘다. 하지만 문서, 프로세스, 도구로 가득할 뿐 실제로는 제대로 관리되고 있지 못한 프로젝트는 더 나쁘다.

왜냐하면 전자는 비체계적/비효율적이라서 나쁘지만, 후자는 거기에다 추가로 사람들로부터 미래에 대한 기대감을 앗아가고 또한 거짓 몸짓으로 인한 패배감마저 안겨주기 때문이다.

PS: 요구사항 관리에 대한 언급은 이후에 또 할 것이다.