프로젝트를 진행하고 있는 개발자나 PM도 이 프로젝트가 언제 끝날지 전혀 감이 안잡히는 경우가 많다.
하지만 분명한 것은 이 프로젝트가 예정된 종료일까지는 끝나지 않을 것이라는 것은 아주 잘 알고 있다.
이것을 알고 있다면 일정을 연기해야 하는데 언제로 연기를 해야 하는지 알 수 없으니 일정 연기를 요청하기도 어렵다. 일정을 연기 했으면 그 일정은 지켜야 하는데 연기된 일정도 전혀 근거가 없이 그냥 감으로 생각한 일정이기 때문이다. 이런 일정은 또 연기되기 마련이다.
그래서 Due date이 되어서어 끝나지 않음을 알고 일정 연기를 요청하고 한다. 이렇게 촉박하게 일정이 자주 연기가 되면 영업이나 마케팅 부서에서는 도저히 개발팀의 일정을 믿을 수 없어서 자신있게 비즈니스를 하기 어려워진다.
그럼에도 일정이 늦어지고 있는 것을 늦게 알려주는 이유는 미리 얘기를 해봤자 일찍 혼나기 밖에 더하겠냐는 생각때문이기도 하다. 일정이 촉박해지면서 매일 야근을 하면서 열심히 하는 모습을 보여주면 일정을 연기해도 큰게 혼나지 않을 것이라고 생각하곤한다.
하지만, 경영자 입장에서는 밤새면서 일정 못지키는 프로젝트보다는 6시에 퇴근하고 약속한 일정을 지키는 프로젝트가 훨씬 낫다. 그렇다고 주먹구구로 개발하면서도 일정을 터무니없게 길게 잡으면 곤란할 것이다.
제대로된 조직, 프로세스, 시스템을 갖추고 있는 회사에서 SRS를 적절하게 썼다면 1년짜리 프로젝트에서 1주일 지연이 되는 것을 6개월전에도 알 수 있다. PM은 이런 일정 지연이 생기면 이를 복구하기 위한 다양한 기법들을 사용하게 된다. 따라서 일정에 맞춰서 프로젝트를 마칠 수 있는 가능성은 대단히 높아지게 된다.
더 이상 개발팀에게 "내일은 끝나나?"라고 물어볼 필요가 없다. 개발팀도 신뢰를 회복할 수 있을 것이다.
또한, 더 중요한 것은 6시에 퇴근을 하면서도 프로젝트를 더 일찍 끝낼 수 있다는 것이다.
심정적으로 경험적으로 이것이 믿어지지 않는 분들도 많겠지만, 필요한 만큼 적절히 체계화 된 개발을 하고 SRS와 설계를 적절하게 하면 프로젝트 일정도 지키고 개발자도 행복해진다.
여기서 중요한 것은 적절하게 하는 것이다. 적절하다는 것이 가장 어려운 것 중 하나다.
* 이 포스트는 blogkorea [블코채널 : 꿈꾸는 소프트웨어 개발자 세상] 에 링크 되어있습니다.
