[박유신의 PM 이야기 2] 프로젝트 지연
많은 사람들이 새해 목표를 세운다. 그러나 계획한 것이 그대로 진행된 경우는 그리 많지 않을 것이다. 나도 마찬가지다. 일부는 계획대로 실행했지만, 그렇지 않은 것도 꽤 있다. 바쁘다는 핑계, 돈이 없다는 핑계, 참으로 많은 핑곗거리가 있다.
프로젝트도 마찬가지이다. 여러 가지 이유에 의해 프로젝트가 지연된다. 펀딩이 늦게 될 수도 있고, 인력수급이 안되기도 하고, 예상치 못한 기술적인 문제에 부딪히기도 하고, 선행 프로젝트가 지연되어 덩달아 지연되기도 한다.
내 프로젝트가 왜 지연되었나?
작년에 진행했던 두 개의 프로젝트는 공히 한 명의 엔지니어에 의존하게 되어 상당한 지연이 발생했다. 회사 내에 딱 한 명만이 그 일을 담당하고 있었다. 프로젝트 A의 경우 그 직원을 제외하고, 다른 직원들은 관련 기술이나 경험이 별로 없기 때문에 프로젝트에 참여할 수 없었다. 또한 잘못될 경우 파급효과가 엄청 큰 시스템이므로 함부로 다른 직원들에게 맞길 수가 없었다. 프로젝트 B의 경우, 운영팀에 그 시스템을 담당하는 직원이 딱 한 명 있었는데, 최근 조직개편으로 인해 다른 팀으로부터 그 시스템의 운영을 이관받았기 때문에 제대로 된 지식과 경험이 부족했다. 그런데다 그 엔지니어는 다른 중요한 운영 관련 일들을 담당하고 있어서 업무부담이 과중한 상태였다.
프로젝트 초기에 담당 라인 매니저로부터 충분히 지원하겠다는 약속을 받고 프로젝트를 시작했다. 프로젝트 중반까지는 별 문제가 없었으나 중반 이후에 그 엔지니어들이 급한 문제를 해결하느라 시간을 뺏기면서 프로젝트 일정에 차질이 생기기 시작했다. CEO까지도 보고 된 중요한 Production System 이슈를 해결하느라 그 엔지니어들이 해당 프로젝트 관련 일을 할 수 없게 되어 일정은 계속 지연되어갔다. 프로젝트 초기에 컨틴전시 (contingency) 기간을 프로젝트 일정에 포함시켰기 때문에 어느 정도 여유는 있었지만 너무 많은 시간을 잃어버렸다.
뭐를 다르게 하면 좋았을까?
뒤돌아보아 한 달 전 두 달 전으로 간다고 했으면 뭐를 다르게 할 수 있었을까? 프로젝트 A의 경우 프로젝트 초기 또는 중기에 추가로 한 명의 엔지니어를 보강함으로써 메인 엔지니어의 업무부담을 덜어주는 방법이 효과적이었으리라. 프로젝트 B의 경우에는 담당 엔지니어에만 의존하지 말고 외부업체의 인력을 소싱하되 그 엔지니어의 도움을 받는 방법을 썼더라면 결과는 달라졌을 것이다.
프로세스 상에서 개선할 점은?
2주 또는 4주마다 뭐가 이슈인지, 뭐가 잘 작동하지 않는지를 고민해서 대안을 찾는 노력이 중요하다. 애초에 세운 계획대로 고집하다 보면 나중에 가서 망할 확률이 높아진다. 완벽한 계획은 없다. 계획을 세우고 재빨리 실행하고 잘 작동하는 것은 그대로 두고, 잘 작동하지 않는 것은 고민해서 개선해야 한다. 그리고 그 결과를 다시 분석한다. Plan - execute - check 의 사이클을 반복하는 것이다. 이게 바로 요즘 많이 채택하고 있고 애자일 방법론과 맥을 같이한다.
프로젝트마다 상황이 다르고 원인이 다르기 때문에 획일적인 해결책은 없다. 상황에 따른 1차 원인, 2차 원인을 분석한 후 해결 대안을 마련해서 가장 적절한 해결 대안을 실행하는 것이 뻔한 답이지만 옳은 방법이라 생각한다. 혼자서만 머리 빠지게 고민하지 말고 팀원들의 의견을 모으고 프로젝트 스테이크홀더 또는 그 밖의 사람에게도 조언을 구하는 것이 좋은 방법이다. 그리하여 이번 프로젝트에서 배운 것을 다음 프로젝트에서 써먹을 수 있기를 바란다. 나 자신에게 그리고 이 글을 읽는 분들께.
