처음 정해졌던 Spec은 무참히 짓밟히고 여러 번 변경되기를 거듭하더니 누더기가 되었다.
하지만 변하지 않는 것이 있다.
최초에 정해졌던 개발 일정이다.
Spec 변경에 대한 티끌만큼의 가책도 없이 Deadline은 변함이 없다.
과제 개발에 참여한 멤버들의 사기는 갈수록 떨어지고 있다.
포기할 수 없는 PM은 절실한 심정으로 개발 일정을 준수하기 위한 방법들을 뒤적여본다.
PM의 이론에 있는 작업 병행(Fast Tracking)과 지원 추가(Crashing)가 생각난다.
Fast Tracking은 현 Activity가 완료된 이후에 진행할 Activity를 현 Activity가 끝나지 않은 상태에서 병행 수행하는 것을 의미한다.
이 방법은 현 Activity가 문제없이 끝날 경우, 시간 단축 효과가 있지만 문제가 발생할 경우, 재작업 진행 등으로 인해 오히려 개발 기간이 늘어날 위험이 있다.
Crashing은 Critical Path에 적용하며 작은 비용으로 많은 기간을 단축할 수 있는 Activity에 적용해야함을 이야기한다.
여기서 Critical Path는 플롯(프로젝트 납기에 영향을 주지 않고 해당 Activity가 가지는 여유시간)이 ‘0’인 Activity를 연결한 경로를 의미한다.
Critical Path의 시간을 줄여야 프로젝트 개발기간이 단축되므로,
Critical Path에 해당하는 Activity에서 시간 단축 효과가 큰 Activity를 골라서 인력을 투입함으로써 기간 단축 효과를 최대화하는 방법이다.
하지만 여기에 몇 가지 조건이 있다.
무조건적인 인력의 투입이 해당 Activity의 시간 단축을 가져오지 않기 때문이다.
전문적인 Skill 혹은 기술이 필요한 Activity인 경우, 그 Activity에 맞는 기술 인력이 투입되고, 그 Activity를 충분히 이해하고 있어야 한다는 것이다.
그렇지 않은 경우, Activity의 습득 및 이해에 시간이 소요되어 기대하는 효과를 얻을 수 없게 된다.
그리고 어떤 일은 장비 사용의 제한성 등으로 인력 투입의 제한이 있는 경우도 있다.
대부분의 과제는 인력이 부족한 상태에서 개발 기간도 Tight하게 진행된다.
이럴 때 사용할 수 있는 방법이 비상상황으로의 전환이다.
이 상황은 과제 멤버 모두가 집중된 형태로 과제를 진행하는 모드임을 모두가 인식하고 그에 준하여 Activity를 진행하는 것을 의미한다.
이 때 등장하는 것은 Daily Report 혹은 Daily Meeting이다.
과제에 참여하는 모든 사람이 이 커뮤니케이션이 참여한다.
이를 통해서 모든 Activity의 Visibility는 높아지고 정보는 실시간으로 공유되고 협의되어 효율적으로 일이 흘러간다.
단, 이 모드는 1개월 정도의 짧은 시간 적용을 유념해야 한다.
긴장 모드를 상시로 유지할 때 발생하는 문제점은 아래와 같다.
첫째, 긴장 모드의 기간이 길어지면 과제 참여자들은 체념하게 되고, 열심히 하겠다는 의지도 사라진다.
즉 되는대로 하고, 쉬고 싶으면 쉬게 된다.
사람은 생물이기에 항시 긴장모드를 유지할 수 없기 때문이다.
둘째, 임원이나 관리자들이 상시 긴장 모드를 유지할 경우, 사람들은 보여주기에 치중하며, 내부적으로는 빈둥거리기 시작한다.
이 상황에서 서로의 신뢰감이란 존재하지 않는다.
결론을 정리하자면, 비상 모드일 경우 제일 중요한 것은 과제 멤버들의 협조적인 태도이다.
자발적인 협력과 집중만이 과제가 어렵게 진행되는 비상 상황을 극복할 수 있는 중요한 요소이다.
이런 협력을 얻어내기 위해서는 관리자와 과제 참여자간의 단단한 신뢰가 바탕이되어야 한다.
