이번 프로젝트 내일 끝나?
2011/01/31 13:28 by 전규현
All of Software 블로그를 RSS Feed에 등록을 해 놓으시면 편리하게 받아보실 수 있습니다.
RSS Feed
SW개발 프로젝트가 언제 끝날지 정확하게 모르는 경우가 허다하다.
RSS Feed
프로젝트를 진행하고 있는 개발자나 PM도 이 프로젝트가 언제 끝날지 전혀 감이 안잡히는 경우가 많다.
하지만 분명한 것은 이 프로젝트가 예정된 종료일까지는 끝나지 않을 것이라는 것은 아주 잘 알고 있다.
이것을 알고 있다면 일정을 연기해야 하는데 언제로 연기를 해야 하는지 알 수 없으니 일정 연기를 요청하기도 어렵다. 일정을 연기 했으면 그 일정은 지켜야 하는데 연기된 일정도 전혀 근거가 없이 그냥 감으로 생각한 일정이기 때문이다. 이런 일정은 또 연기되기 마련이다.
그래서 Due date이 되어서어 끝나지 않음을 알고 일정 연기를 요청하고 한다. 이렇게 촉박하게 일정이 자주 연기가 되면 영업이나 마케팅 부서에서는 도저히 개발팀의 일정을 믿을 수 없어서 자신있게 비즈니스를 하기 어려워진다.
그럼에도 일정이 늦어지고 있는 것을 늦게 알려주는 이유는 미리 얘기를 해봤자 일찍 혼나기 밖에 더하겠냐는 생각때문이기도 하다. 일정이 촉박해지면서 매일 야근을 하면서 열심히 하는 모습을 보여주면 일정을 연기해도 큰게 혼나지 않을 것이라고 생각하곤한다.
하지만, 경영자 입장에서는 밤새면서 일정 못지키는 프로젝트보다는 6시에 퇴근하고 약속한 일정을 지키는 프로젝트가 훨씬 낫다. 그렇다고 주먹구구로 개발하면서도 일정을 터무니없게 길게 잡으면 곤란할 것이다.
제대로된 조직, 프로세스, 시스템을 갖추고 있는 회사에서 SRS를 적절하게 썼다면 1년짜리 프로젝트에서 1주일 지연이 되는 것을 6개월전에도 알 수 있다. PM은 이런 일정 지연이 생기면 이를 복구하기 위한 다양한 기법들을 사용하게 된다. 따라서 일정에 맞춰서 프로젝트를 마칠 수 있는 가능성은 대단히 높아지게 된다.
더 이상 개발팀에게 "내일은 끝나나?"라고 물어볼 필요가 없다. 개발팀도 신뢰를 회복할 수 있을 것이다.
또한, 더 중요한 것은 6시에 퇴근을 하면서도 프로젝트를 더 일찍 끝낼 수 있다는 것이다.
심정적으로 경험적으로 이것이 믿어지지 않는 분들도 많겠지만, 필요한 만큼 적절히 체계화 된 개발을 하고 SRS와 설계를 적절하게 하면 프로젝트 일정도 지키고 개발자도 행복해진다.
여기서 중요한 것은 적절하게 하는 것이다. 적절하다는 것이 가장 어려운 것 중 하나다.
* 이 포스트는 blogkorea [블코채널 : 꿈꾸는 소프트웨어 개발자 세상] 에 링크 되어있습니다.
'개발프로세스' 카테고리의 다른 글
| 문서는 얼마나 적어야 할지? (2) | 2011/10/27 |
|---|---|
| 획일화된 프로세스의 함정 (6) | 2011/04/03 |
| 이번 프로젝트 내일 끝나? (10) | 2011/01/31 |
| 소프트웨어 관료화 (16) | 2009/08/31 |
| 프로세스가 창의성을 저해한다고? (8) | 2009/04/08 |
| 소프트웨어 개발의 극과 극 (0) | 2009/02/18 |
Trackback Address: http://allofsoftware.net/trackback/210
적절하게 하는것 이라는 말 적극 공감합니다.
저희도 제품 마무리 짓고 있는데 아직도 SRS 설계를 하긴 했는데 적절히 안해서 일정이 연기되는 상황을 몇번 겪고나니 참 가슴이 쓰라립니다 ^^
안녕하세요. 드럼캡님
SRS를 쓰셨다고 하셨는데, 부족한 것인지 과한 것인지 궁금하군요. 대기업에서는 부족하면서도 과하게 적곤 합니다.
즉, 필요한 것은 빠지고, 기능은 설명을 너무 과하게 적습니다.
SRS를 적절히 적는 것은 설계를 하고 구현할 개발자들이 설계를 구현을 무리없이 할 정도입니다. 전혀 물어보지 않고 개발할 수 있는 것은 과도하게 적은 것이고, 너무 많이 물어봐야 하면 부족하게 적은 것입니다. 또한 기능 위주로 적은 것은 빠진 부분이 너무 많아서 나중에 큰 문제가 됩니다.
항상 그렇지만 적절한것이 가장 중요하면서도 어려운것 같아요.
그리고 디버깅을 하다보면 다른것들까지 계속 손을 보게 되다보니 일정은 계속 늘어나게 되더라구요.
그럴때에는 확실하게 이것 까지만 이번 릴리즈에 버그를 잡고
알려진 버그로 남기는 것도 방법이긴 하지만 크리티컬이라면 이것까지만 잡고.. 이것까지만... 라는
개발자의 욕심으로 인해서 일정이 무제한으로 늘어나게 되죠 ^^;
이런걸 보면 저도 개발자이지만 적당하게 선을 긋는 법을 조금더 터득해야 할텐데 매번 아쉬움을 느끼게 됩니다.
구차니님 안녕하세요.
개발 일정에 테스트 기간까지 모두 포함해야 합니다. 프로젝트에 따라서 테스트 기간이 구현기간보다 더 긴 경우도 있습니다.
그런데 흔히 테스트 기간은 너무 짧게 잡아 놓고 마치 구현기간에 거의 출시 가능한 제품을 만들어 낼 수 있을 것 같은 생각을 하곤 합니다.
구현과 테스트 기간의 비율은 하나의 정답이 있는 것이 아니고 프로젝트의 성격과 난이도에 따라서 달라집니다. 이것을 판단하는데 경험도 필요합니다.
또한 출시를 할지 말지 결정하는 회의를 Go-live회의라고 합니다. 이 회의를 통해서 버그를 몇개 안고 출시를 할지 고쳐서 출시를 할지 결정하게 됩니다.
(문제제기에 대해 늘 공감하며 보고 있습니다. 감사합니다) 어떻게 하면 적절히 할 수 있을까요? 프로젝트 예측이라는 게 제겐 참 어려운 일인데. 어떻게 하면 요구사항으로 실제 완성이 되기 까지의 기간을 예측을 할 수 있나요?
안녕하세요. 탁..님
프로젝트 일정 예측에 가장 필요한 자료는 SRS입니다. SRS를 제대로 작성하게 되면 각 Task는 1~2일 단위로 쪼갤 수 있습니다. 이를 WBS라고 합니다. 일정이 이렇게 작게 쪼개지지 않고 몇주 또는 몇달 단위로 관리를 한다면 일정을 관리할 수도 없고 늦어지고 있는지 판단할 수 없습니다.
이러려면 SRS를 잘 적어야 하는데 이는 하루이틀에 가능한 일이 아닙니다. 제대로 방법을 배워야 하고 경험해야 하고 실제 프로젝트에서 수십번 해봐야 합니다. 제대로 적으려면 수년이 걸리고 10년을 적어봐도 계속 더 잘적을 것들이 남아 있는 분야입니다.
일단 개발해야 할 것을 꼼꼼히 적는 것에 서 출발해보세요. 물론 이것만으로는 스펙(SRS)의 20~30%만 커버한다고 생각하면 됩니다. 그래도 시작은 되죠.
예측이란 틀릴 수 있기 때문에 예측 아닐까요? 주식도 보면 주식 전문가라고 하는 사람들도 시장 예측을 하죠. 대부분 확인 과정이 없어서 그럴 수도 있지만 많은 경우 맡지 않는 것 같습니다. 그들의 예측이 맞지 않을때 왜 맞지 않는데 예측에 대한 책임을 지지 않는 거야 라고 생각한 것도 있습니다. 그러면 왜 그들에게 책임을 지라고 사람들은 묻지 않을까요? 사람들 다 틀릴 수 있다고 생각하기 때문인 것 같습니다. 프로젝트 기간 또한 비슷하지 않을까요? 다들 틀리 수 있다는 가정을 하지 않는데 어려움이 있는 것 같습니다. 무조건 기간을 맞춰야 한다는 문제가 상황을 힘들게 하는 것 같습니다. 선을 그어놓고 당사자들이 맞춰서 뛰어라 하는 상황이 많은 건 아닐까 생각해 봅니다.
또한 프로젝트에 대한 예측과 그에 따른 결과가 어떻게 됐는지. 어떤 부분이 예측을 힘들게 하는지. 어떤 이유 때문에 연기 되었는지에 대한 검증이 없고 또한 그 검증에 대한 소프트웨어 업체간의 정보 공유가 없는 것이 문제이지 않을까요? 그 부분에 대한 노하우가 쌓이지 않고 공유되지 않는 것이죠. 다들 닥친 프로젝트 마치고 유지보수 하는데 여력을 쏟지 그 과정에 대한 검증과 과정에 대한 리부가 없는 시간의 환경 또한 문제인 것 같습니다.
안녕하세요. bluemonk님
예측은 틀릴 수 밖에 없죠. 정확한 예측은 프로젝트가 끝날 때 하는 것이라고들 합니다. 하지만 프로젝트 일정과 비용을 전혀 예측할 수 없다면 비즈니스를 할 수가 없죠.
프로젝트를 시작할 때 하는 예측은 흔히 2배정도 차이가 난다고 합니다. 심지어 5배 이상 차이나는 경우도 있습니다. 하지만 SRS를 쓰고 설계를 하는 과정에서 상당히 정확한 일정을 예측할 수 있게 됩니다. 프로젝트는 우리의 통제하에 있는 것이라도 예측 가능하게 됩니다. 통제권을 잃어버리면 예측이 안되죠. 이렇게 프로젝트가 언제 끝날지 모르는 프로젝트도 허다합니다.
프로젝트 예측은 개발자들이 하는 것으로 위에서 일정이 고정되어서 내려오면 그냥 열심히 해는 것가지고는 안되고 스펙 기반하에 일정을 단축할 수 있는 다양한 방법을 동원해야 합니다. 이또한 일정이 상당히 정확하게 예측이 되어야 단축할 수 있는 방법도 동원할 수 있습니다.
스펙 기반하에 해야 하는 것이 맞는 것 같습니다. 그 스펙이 바뀐다면 어쩔 수 없는 거 같습니다. 그 스펙이라는게 SRS 를 쓰면서 다시 한번 범위가 검증되는 것도 맞는 것 같습니다.
사람들은 자연에서 법칙을 찾고 싶어합니다. 그리고 그것을 숫자화(수치화, 수식화) 합니다. 그래야 예측 가능하고 통제 가능하다고 생각하기 때문입니다.
그래서 앞에 이야기 한데로 숫자화 하는 노력이 필요한 것 같습니다. 법칙이나 조건 같은거라고 할 수도 있겠죠. 다만 이러한 상황 속이라도 예측이 빗나갈 수 있다는 전제는 반드시 존재해야 한다고 생각합니다. 인간도 자연의 일부이니까요. 그 예측이 틀린 것에 대한 책임이 너무 큰 것 같다는 생각이 듭니다. 그 책임이 주로 개발자에게 돌아오는 것 같아서 더욱 그렇습니다. 왜 그런 환경에 대한 부분에 대한 인프라에 대해서는 신경을 쓰지 않으면서 개발자에게만 그주로 그 책임을 묻는 것 같습니다. 프로젝트 예측이 가능하게끔 정보를 쌓고 이를 공유하는 것이 필요하다고 생각합니다.