90%에서 끝나지 않는 프로젝트
2011/07/27 22:32 by 전규현
All of Software 블로그를 RSS Feed에 등록을 해 놓으시면 편리하게 받아보실 수 있습니다.
RSS Feed
Software 개발 프로젝트에서 일정이 늦어지는 경우는 흔하다. 초기 일정을 완벽하게 맞추어서 끝내는 프로젝트는 구경하기 힘들 정도이다.
그 중 대부분의 프로젝트는 90%까지는 진도가 착착 잘 나가는데 10%를 남기고 나서 일정이 계속 지연되곤 한다. 남은 10%를 끝내기 위해서 90% 끝내는데 걸리는 시간보다 더 오래 걸리는 프로젝트를 보는 것은 그리 쉬운 일이 아니다. 설령 일정에 밀려서 출시를 해도 버그가 많은 알파버전 수준의 제품을 출시해서 고객들의 원성을 사기 일쑤이다.
경영자는 매달 개발자들이 하는 다음달이면 끝난다는 얘기를 반복해서 듣게 된다.
이러한 상황을 개발자들은 그렇게 심각하게 보지 않는 경우가 많다. 하지만 비즈니스를 하는 사람은 이것이 비즈니스를 하는데 얼마나 심각한 문제가 되는지 잘 알고 있다.
소프트웨어 공학은 프로젝트 일정을 단축하고 계획대로 개발할 수 있도록 하기 위한 방법에 온 힘을 기울여 왔다. 소프트웨어 공학에서 다루는 거의 모든 분야는 일정 준수에 포커스를 하고 있다고 해도 과언이 아니다.
남은 10%의 일정이 그렇게 잘 안끝나는 주요 원인들은 다음과 같은 것들이 있다.
RSS Feed
Software 개발 프로젝트에서 일정이 늦어지는 경우는 흔하다. 초기 일정을 완벽하게 맞추어서 끝내는 프로젝트는 구경하기 힘들 정도이다.
그 중 대부분의 프로젝트는 90%까지는 진도가 착착 잘 나가는데 10%를 남기고 나서 일정이 계속 지연되곤 한다. 남은 10%를 끝내기 위해서 90% 끝내는데 걸리는 시간보다 더 오래 걸리는 프로젝트를 보는 것은 그리 쉬운 일이 아니다. 설령 일정에 밀려서 출시를 해도 버그가 많은 알파버전 수준의 제품을 출시해서 고객들의 원성을 사기 일쑤이다.
경영자는 매달 개발자들이 하는 다음달이면 끝난다는 얘기를 반복해서 듣게 된다.
이러한 상황을 개발자들은 그렇게 심각하게 보지 않는 경우가 많다. 하지만 비즈니스를 하는 사람은 이것이 비즈니스를 하는데 얼마나 심각한 문제가 되는지 잘 알고 있다.
소프트웨어 공학은 프로젝트 일정을 단축하고 계획대로 개발할 수 있도록 하기 위한 방법에 온 힘을 기울여 왔다. 소프트웨어 공학에서 다루는 거의 모든 분야는 일정 준수에 포커스를 하고 있다고 해도 과언이 아니다.
남은 10%의 일정이 그렇게 잘 안끝나는 주요 원인들은 다음과 같은 것들이 있다.
- 스펙을 충분히 제대로 작성하지 않았다. 단순한 요구사항을 가지고 개발자들이 알아서 개발을 한다.
- 설계가 허술해서 인터페이스가 자주 바뀐다. 통합이 잘 안되서 통합하는데 시간이 많이 소요된다.
- 상세 일정이 없이 큰 단위의 마일스톤만 가지고 있다. 일정관리는 거의 안한다.
- 리스크 관리는 해본적도 없다.
- 제품이 개발되기 전까지 스펙이 공유가 안되서 영업이나 경영층에서 프로젝트 막바지에 제품의 모습을 보고 요구사항을 계속 추가로 요청한다.
- 프로젝트 일정에 테스트 일정을 충분히 고려하지 않았다. 테스트 케이스를 제대로 만들지 않고 테스트 인력이 부족해서 테스트 할 때마다 계속 새로운 버그가 발견되서 끝나지를 않는다.
개발 방법론이 라이프 사이클들은 여러가지가 있고 최근에 유행을 타는 것들도 있지만 결국에는 스펙을 상세히 제대로 작성하는 것이 근본적인 프로젝트 일정을 지키는 방법이다. 스펙을 제대로 작성하지 않고 여러가지 기법으로 해결할 수는 없다. 스펙을 작성하는 방법이 어찌되었든 스펙이 정확하고 상세해야 정교한 일정 예측 및 관리가 가능해지게 된다. 이런 경험이 점점 쌓이면 일정을 지키는 프로젝트가 점점 늘어 갈 것이다. 그러기 때문에 스펙을 잘쓰는데는 10~20년의 경험이 필요한 것이다.
대충 개발자들이 알아서 개발해주고 일정은 하늘(개발자인가?)에 맡기는 방법에 익숙해진 개발자들은 이런 정교한 일정관리에 거부감을 가질 수는 있으나 결국에는 일정을 지키는 방법이 개발자의 역량을 향상시키는 방법과도 일치하기 때문에 개발자 손에 달린 프로젝트가 개발자에게 파워를 가져다 준다는 생각은 버리는 것이 좋다.
프로젝트 일정은 10%가 남았다면 진짜로 10%만 더 지나면 끝나야 한다.
* 이 포스트는 blogkorea [블코채널 : 꿈꾸는 소프트웨어 개발자 세상] 에 링크 되어있습니다.
image from http://dimland.blogspot.com/2010_08_01_archive.html
프로젝트 일정은 10%가 남았다면 진짜로 10%만 더 지나면 끝나야 한다.
* 이 포스트는 blogkorea [블코채널 : 꿈꾸는 소프트웨어 개발자 세상] 에 링크 되어있습니다.
image from http://dimland.blogspot.com/2010_08_01_archive.html
'프로젝트 > 일정' 카테고리의 다른 글
| 90%에서 끝나지 않는 프로젝트 (4) | 2011/07/27 |
|---|---|
| 경영진이 너무 촉박한 일정을 제시합니다. (36) | 2011/02/16 |
| 하루 8시간 일하시나요? (6) | 2008/12/16 |
| 오늘도 밤을 세워야 하는 개발자 (야근 탈출) (13) | 2008/12/08 |
Trackback Address: http://allofsoftware.net/trackback/229
프로젝트 일정 자체가 범위와는 무관하게 비즈니스 목표일정으로 정한 후 최대한 많은 기능을 넣는 프로젝트도 있고, 기획이 되지 않은 상황에서 일정추정을 강요하는 환경도 많이 있습니다. 이런 경우는 어떻게 대처해야 좋을지 혹시 좋은 의견이 있으신지요? ㅠㅠ
이런 프로젝트는 범위도 불투명한 상황에서 일정이 남는다 모자른다 아무리 싸워도 아무 의미가 없게 됩니다. 개발자들은 막연히 일정이 모자른다고 하지만 또한 대부분 늦어지지만, 초기에는 아무 근거도 없이 동대문시장에서 물건 깎듯이 아규를 하게 됩니다.
가장 좋은 방법은 최대한 빨리 스펙을 쓴 다음에 근거를 가지고 얘기를 하는 겁니다. 일정의 근거가 명확해지면 기획이나 영업에서 무조건 우기기에도 궁색해지게 됩니다.
또한 기획도 되지 않은 상황에서의 일정 추정은 무리지만 일단 대략의 일정을 주고 꼭 스펙을 써봐야 정확한 일정을 다시 산정할 수 있다고 강조를 해야 합니다. 이를 잘 이해 못하는 사람들도 많지만 이해를 시켜야 합니다.
기능을 무조건 많이 넣는 것은 키친씽크입니다. 쓸데 없는 기능을 잔뜩 넣는 겁니다. 스펙을 쓰고 WBS에 근거해서 상세 일정이 나와야 쓸데 없은 기능으로 얼마나 일정이 늦어지는지 근거를 제시할 수 있고 이런 기능은 빼고 출시 할 수 있습니다.
결국 근본적인 해결 방법이 가장 좋은 방법입니다. 문제는 스펙을 잘 작성하는 것이 소프트웨어 개발에서 가장 어렵다는 것입니다. 꾸준히 경험을 쌓아야 합니다.
의견 감사합니다. ^^ 고객이 무엇을 하고 싶은지도 모르는 상황에서 스펙을 이끌어낸다는 것은 무척이나 어렵군요 ㅠㅠ. 하지만 이게 바로 경험이고 능력이 아닐까 생각합니다. 말씀하신 부분을 명심해서 실천을 해보도록 하겠습니다.
한가지 더 말씀드리면 고객이 무엇을 하고 싶은지 모르는 상황은 매우 자연스러운 현상입니다. 특히 우리나라에서는 고객이 전문가도 아니고 노력도 안합니다. 우리나라가 좀 심하긴 하지만 외국이라고 고객들이 그렇게 잘 알지 못합니다.
그래서 스펙을 제대로 작성하는 것이 어렵고 그게 실력의 차이입니다.
고객이 잘 모르고 개발팀도 잘 모르면 산으로 갈 수 밖에 없습니다. 코딩하기 전에 스펙을 제대로 적고 개발해야 다 만들어 놓고 기능 추가 변경을 반복하지 않을 수 있고 기간과 비용이 절약됩니다.
아무튼 코딩은 늦게 할 수록 이익입니다. ^^ 이걸 이해하려면 한참 걸립니다.