2006년 4월 11일

요구사항 관리의 함정

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

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

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

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

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

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

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

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

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

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

왜 그런가 하면,

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

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

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

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

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


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

댓글 6개:

익명 :

프로젝트를 앞둔 상황에서 불안감에 의해 문서, 프로세스, 도구를 좀더 챙기면 프로젝트가 좀 더 잘될까 하고 생각하는 시기에 이런글을 보니 기분이 묘합니다.
이해 관계자 관리가 우선이라는 말 다시한번 새기고 퍼다가 TFT에 공유시켜야 겠습니다. 간만에 팍 와닿는글 땡큐~

익명 :

이해당사자가 "관리"의 영역에 들어있다면 그나마도 해볼만 하겠지만, 많은 경우 관리 불가능한 일방적 주종관계에 처하게 되는 것이 "실무"의 현실이 아닌가 쓴웃음 짓게 됩니다. 갑을병정의 하청구조 상황에서 합리적인 생산성을 담보할 수 있는 합리적인 "실무" 프로젝트 관리라는 것이 당췌 가당키다 한것인지 회의가 듭니다.

익명 :

실제로 해보다 보니까 요구사항이 다 드러나 있지 않아서 그런지 오히려 반대로 하게 되고 그러다 보니까 문서는 제일 나중에 만들게 되더군요...

바비(Bobby) :

TO 익명님/ 가당하지 않습니다.

왜냐하면 고위직은 어떠한 경우에도 생각을 바꾸지 않을 것이기 때문입니다. 특히 사회적 지위가 낮은 사람의 말은 전혀 귀담아 듣지 않습니다.

한가지 유일한 솔루션은,

10~15년을 참아내어 '어떻게든' 전문가의 능력을 인정받고, 영향력을 행사할 수 있는 지위에 오르는 것만이 유일한 방법입니다.

익명 :

이번 포스트는 뻔한 문제와 실무의 고통과 교과서의 딱딱함, 능력 없는 매니저 얘기 뿐이라 딱히 코멘트할 말이 없네요. 많이 아쉽습니다. 다음으로 예고된 요구사항(과 능력 있는 매니저)에 대한 다음 글을 기대해봅니다.

익명 :

글쎄요,,프로젝트를 너무 결과 위주로만 생각 해서 그런거 아닐까요? 실재로 프로젝트 관리는 프로세스이고 어떤 특정한 방법이 있다기 보다는 효율적인 방법중 하나를 선택 하는 것입니다. 만일 말씀하신 사례를 외국계 기업과 일하면서 발생했다고생각 해 보세요...과연 추가비용 없이 요구할 수 있는지 ...그것은 프로젝트 관리의 문화 때문입니다. 국내도 건설/토목 부분은 어느정도 프로젝트관리가 엔지니어링으로서 자리 잡았지만 아직 SW쪽은 시작 단계라고 할 수 있을 것입니다. 요구사항관리가 필요 없는 것이라기 보다는 그러한 관리를 체계적으로 할 필요성이 더 커 보입니다. 힘들겠지만 이러한 관리기법이나 툴들을 통하여 그동안의 주먹구구식 방법을 바꿔야 할 듯 합니다....결론적으로 말하면 전 이렇게 대답할 것입니다..." 이사님이 말씀하신대로 하려면 약 @@@의 비용이 추가 되며 일정은 @@@이 연기가 됩니다. 그근거로는 @@@입니다. 반드시 필요한 요구사항이라면 초기 요구사항수립시 도출하지못 한 책임은 @@@에게 있습니다. 의사결정은 이사님이 사인하시기 바랍니다..." 물론 이렇게 이야기 해서 저는 찍혔습니다. 의사결정을 하지도 않으면서 책임을 떠 넘기는데는 근거 있는 내용을 가지고 거부 하시면 됩니다. 그렇지 않으면 오히려 실패에 대한 책음을 PM이 다 질 수 도 있기 때문 입니다. ...

댓글 쓰기

댓글을 환영합니다.

스팸으로 인해 모든 댓글은 운영자의 승인 후 등록됩니다. 스팸, 욕설은 등록이 거부됩니다. 구글의 블로그 시스템은 트랙백을 지원하지 않습니다.