실패하는 Project에서 그 원인을 찾아보라.

  소프트웨어 공학은 대규모의 프로젝트에서 저비용 고효율을 창출하고 소프트웨어의 위험요소를 줄이기 위한 접근 방법이다.

  하지만 모든 소프트웨어 프로젝트가 성공하는 것은 아니다. 우리의 프로젝트 역시 성공할 것이라는 보장은 없다. 그렇다면 우리의 프로젝트를 성공으로 이끌려면 어떻게 해야 할까?

  정답은 실패한 프로젝트에서 그 원인을 찾는 것이다. 다양한 원인이 있을 수 있다. 하지만 오늘은 몇가지에 대해서 살펴보고자 한다.

• 초기 Requirement를 정확히 분석하지 못한경우
• 무리한 일정
• 정치적 압력

1. 초기 Requirement를 정확히 분석하지 못한경우
  최고의 설계 전문가, 최고의 개발자, 최고의 프로젝트 리더, 최고의 문서 전문가, 최고의 테스터가 한팀을 이뤄 소프트웨어 프로젝트를 진행하려고 한다. 고객을 만나 Requirement를 수집하고 이를 정리했다. 일정 계획을 수립하고 정리된 요구사항을 바탕으로 설계를 하고 구현을 하고 문서화까지 모두 착착 진행했다. 최종적으로 산출물을 고객에게 전달했을때 고객의 반응은 "이건 제가 원하던 그것이 아닙니다" 였다.

  왜 그랬을까? 이들은 최초에 고객이 전해준 요구사항을 명확하게 정리하지 못했고, 한번도 요구사항에 대해서 의심하지 않았을 것이다. 그들은 각 분야에 대해 최고의 전문가였고 요구사항에 만족할 만한 결과를 냈지만 그들이 정리한 요구사항과 고객의 생각이 다른 부분이 있었던 것이다.

  이론은 항상 말한다. 요구사항이 완벽하게 정리되기전에 디자인에 들어가지 말아라. 하지만 현실은 다르다. 빠르게 돌아가는 현실에 맞추기 위해서는 때론 설계가 되기 전에 요구사항이 정리되기도 전에 구현에 들어가는 경우가 많기 때문이다. 이는 그 만큼의 위험을 감수하고 서라도 프로젝트를 끝내야 하기 때문이다. 여기서 일정문제를 한번 생각해보자.

2. 무리한 일정
  지난번 실수를 만회하기 위해 요구사항을 모호함 없이 빠짐없이 기술한 후 프로젝트 리더가 설계 및 구현 일정 계획을 수립했다. 최대한 빨리 끝낼 수 있도록 한치의 오차도 없이 시간 안배를 했고 이를 프로젝트 팀원과 고객에게 설명하며 "우리는 이 프로젝트를 수행하는데 있어 5개월이  필요합니다." 라고 말하자 설계 담당자는 설계하는데 3개월이, 개발자는 2개월, 테스터는 3개월이 필요하다고 말했다. 옆에서 듣고 있던 고객은 "저희는 3개월의 시간밖에는 없습니다. 이 제품이 3개월 후에는 출시가 되어야 합니다."라고 말했다. 당신이 프로젝트 리더라면 어떻게 하겠는가? 이대로 진행 할 것인가? 아니면 포기하겠는가? 설계자, 개발자, 테스터는 어쩌란 말인가? 밤샘을 하라는 말인가? 인원을 더 투입하라는 말인가?

무리한 일정은 모든 단계에서 품질의 저하를 가져오고 결과적으로 산출물이 나왔더라도 완성도가 떨어지는 반쪽짜리가 될 가능성이 크다. 또한 팀원의 사기 저하를 불러올 수도 있고, 새로 인원을 더 투입한다면 비용이 그만큼 더 들어가고 숙련되지 않은 인원을 투입한다면 안쓰는 것만 못할 수도 있다.

3. 정치적 압력
프로젝트 리더는 한참을 고심한 후에 일단 사장에게 보고하여 조치를 취해야 겠다고 생각했다. 사장은 모든 이야기를 듣고 프로젝트 리더에게 이 프로젝트는 말도 안되는 일정임에 틀림없지만 고객사는 우리 회사의 가장 큰 고객입니다. "3개월안에 끝내도록 하세요."라고 결정을 해버린다. 이후 사장은 수시로 프로젝트 팀을 방문하여 일정은 잘 지켜지고 있는지, 고객의 기분을 상하게 한적은 없는지 끊임없이 물어본다.

어떤가? 당신이 그 프로젝트를 지금 하고 있다고 생각한다면, 3개월 안에 끝낼 수 있겠는가?
그렇다고 생각한다면 프로젝트를 끝마쳤을 때 품질에 대해 고려 해보았는가?

물론 프로젝트를 실패로 이끄는 이유에는 여러가지가 있겠다. 하지만 현재 본인이 처해있는 상황과 비슷한 실패의 이유를 예로 들어 소개하였다. 당신의 고객이라면, 회사의 사장이라면, 프로젝트의 리더라면, 혹은 팀원이라면 한번쯤 생각해 보길 바란다.

* 프로젝트를 성공으로 이끌기 위해서는 실패한 이유에 대해서 분석하여 동일한 실수를 하지 않아야 한다.