Software 개발 프로젝트에서 일정이 늦어지는 경우는 흔하다. 초기 일정을 완벽하게 맞추어서 끝내는 프로젝트는 구경하기 힘들 정도이다.
그 중 대부분의 프로젝트는 90%까지는 진도가 착착 잘 나가는데 10%를 남기고 나서 일정이 계속 지연되곤 한다. 남은 10%를 끝내기 위해서 90% 끝내는데 걸리는 시간보다 더 오래 걸리는 프로젝트를 보는 것은 그리 쉬운 일이 아니다. 설령 일정에 밀려서 출시를 해도 버그가 많은 알파버전 수준의 제품을 출시해서 고객들의 원성을 사기 일쑤이다.
경영자는 매달 개발자들이 하는 다음달이면 끝난다는 얘기를 반복해서 듣게 된다.
이러한 상황을 개발자들은 그렇게 심각하게 보지 않는 경우가 많다. 하지만 비즈니스를 하는 사람은 이것이 비즈니스를 하는데 얼마나 심각한 문제가 되는지 잘 알고 있다.
소프트웨어 공학은 프로젝트 일정을 단축하고 계획대로 개발할 수 있도록 하기 위한 방법에 온 힘을 기울여 왔다. 소프트웨어 공학에서 다루는 거의 모든 분야는 일정 준수에 포커스를 하고 있다고 해도 과언이 아니다.
남은 10%의 일정이 그렇게 잘 안끝나는 주요 원인들은 다음과 같은 것들이 있다.
그 중 대부분의 프로젝트는 90%까지는 진도가 착착 잘 나가는데 10%를 남기고 나서 일정이 계속 지연되곤 한다. 남은 10%를 끝내기 위해서 90% 끝내는데 걸리는 시간보다 더 오래 걸리는 프로젝트를 보는 것은 그리 쉬운 일이 아니다. 설령 일정에 밀려서 출시를 해도 버그가 많은 알파버전 수준의 제품을 출시해서 고객들의 원성을 사기 일쑤이다.
경영자는 매달 개발자들이 하는 다음달이면 끝난다는 얘기를 반복해서 듣게 된다.
이러한 상황을 개발자들은 그렇게 심각하게 보지 않는 경우가 많다. 하지만 비즈니스를 하는 사람은 이것이 비즈니스를 하는데 얼마나 심각한 문제가 되는지 잘 알고 있다.
소프트웨어 공학은 프로젝트 일정을 단축하고 계획대로 개발할 수 있도록 하기 위한 방법에 온 힘을 기울여 왔다. 소프트웨어 공학에서 다루는 거의 모든 분야는 일정 준수에 포커스를 하고 있다고 해도 과언이 아니다.
남은 10%의 일정이 그렇게 잘 안끝나는 주요 원인들은 다음과 같은 것들이 있다.
- 스펙을 충분히 제대로 작성하지 않았다. 단순한 요구사항을 가지고 개발자들이 알아서 개발을 한다.
- 설계가 허술해서 인터페이스가 자주 바뀐다. 통합이 잘 안되서 통합하는데 시간이 많이 소요된다.
- 상세 일정이 없이 큰 단위의 마일스톤만 가지고 있다. 일정관리는 거의 안한다.
- 리스크 관리는 해본적도 없다.
- 제품이 개발되기 전까지 스펙이 공유가 안되서 영업이나 경영층에서 프로젝트 막바지에 제품의 모습을 보고 요구사항을 계속 추가로 요청한다.
- 프로젝트 일정에 테스트 일정을 충분히 고려하지 않았다. 테스트 케이스를 제대로 만들지 않고 테스트 인력이 부족해서 테스트 할 때마다 계속 새로운 버그가 발견되서 끝나지를 않는다.
개발 방법론이 라이프 사이클들은 여러가지가 있고 최근에 유행을 타는 것들도 있지만 결국에는 스펙을 상세히 제대로 작성하는 것이 근본적인 프로젝트 일정을 지키는 방법이다. 스펙을 제대로 작성하지 않고 여러가지 기법으로 해결할 수는 없다. 스펙을 작성하는 방법이 어찌되었든 스펙이 정확하고 상세해야 정교한 일정 예측 및 관리가 가능해지게 된다. 이런 경험이 점점 쌓이면 일정을 지키는 프로젝트가 점점 늘어 갈 것이다. 그러기 때문에 스펙을 잘쓰는데는 10~20년의 경험이 필요한 것이다.
대충 개발자들이 알아서 개발해주고 일정은 하늘(개발자인가?)에 맡기는 방법에 익숙해진 개발자들은 이런 정교한 일정관리에 거부감을 가질 수는 있으나 결국에는 일정을 지키는 방법이 개발자의 역량을 향상시키는 방법과도 일치하기 때문에 개발자 손에 달린 프로젝트가 개발자에게 파워를 가져다 준다는 생각은 버리는 것이 좋다.
프로젝트 일정은 10%가 남았다면 진짜로 10%만 더 지나면 끝나야 한다.
프로젝트 일정은 10%가 남았다면 진짜로 10%만 더 지나면 끝나야 한다.
