간트 차트의 문제 - 정확하지 않지만 정밀하다
SW프로젝트나 일반 프로젝트를 해 본 분들이라면, 누구나 간트 차트를 들어 보셨거나 만들어 보셨을 겁니다. SW프로젝트를 시작할 때, 프로젝트에서 할 일을 잘게 쪼갠 WBS를 작성하고, WBS에 있는 일들의 인과관계를 고려해서 대개 MS 프로젝트를 사용해서, 예쁜 멋진 간트 차트를 작성하죠. 이렇게 간트 차트를 작성하면 놀랍게도 프로젝트가 몇 월, 몇 일, 몇 시에 끝날지 알려 줍니다.
간트 차트가 몇 월, 몇 일, 몇 시에 끝날지 알려줄 있는 이유는, 핵심 경로(Critical Path)를 계산해 주기 때문이죠. 그런데 간트차트의 비극은 바로 이 핵심 경로에서 시작하죠. 사실, 간트 차트가 알려주는 완료일은, 현실 세계에서 수많은 완료일 가운데 하나일 뿐입니다. 대개 프로젝트와 멀리 떨어진 경영층이나 관리자들은 간트차트가 알려주는 완료일을 진짜 완료일이라고 생각하는 경향이 있습니다. 일정이 간트 차트를 따라서 진행되지 않으면, 관리자들은 프로젝트에 무슨 문제가 있다고 확신하고 PM에게 압박을 가하죠.
일정에 쪼들리지 않을려고, PM이나 팀원들은 일마다 버퍼를 두게 되고, 이 때문에 핵심 경로는 늘어나고 결국 프로젝트 전체 일정은 늘어나게 되죠.* 뭐 이렇게 일정이 늘어난다고 해서 경영층이 그것을 묵과하지 않습니다. 엄청난 노력을 들여서 99%의 정확성이 있는 일정을 작성해도(가능한 일인지 모르지만요), “일정 좀 줄여 봐!”라고 경영층 한 마디면 프로젝트는 침몰하게 되는 마당에, 버퍼가 잔뜩 들어 있는 일정을 경영층이 쉽게 봐주지도 않습니다. 뭐 이런 저런 이유로, 간트 차트를 두고 일정을 늘릴려는 팀원과 일정을 줄여 보려는 경영층 간의 힘겨루기가 일어납니다.
간트 차트를 사용할 때 마인드 - 모든 것을 예측하려고 한다
사람은 예측을 잘 하지 못합니다. 마트에 가서 1주일 먹을 것을 잔뜩 사오거나, 도서관에서 오늘 공부할 교재를 가방 가득히 넣어 가거나, 회사에서 오늘 할일 목록을 LCD 모니터만큼 채우는 것을 보면, 우리는 정말로 낙관적이거나 예측을 잘 하지 못하는 생명체라는 생각이 듭니다. 그런데 길게는 12개월 후나 짧게 6개월 후의 프로젝트 일정을 TV편성표처럼 작성한다는 게 정말로 올바른 일이거나 가능한 일일까요? 12개월 후에 테스트라는 업무를 할 것을 예측할 수 있지만, 하루 단위로 어떤 기능을 테스트한다는 계획을 세운다는 건, 신이 아닌 이상 불가능합니다. 그런데, 우리는 간트 차트를 사용하면, 전지전능한 신이 된 듯이 예측을 합니다.
간트 차트는 누구의 것?
프로젝트 계획을 세울 때, 일반적으로 팀원들은 프로젝트 계획을 프로젝트 관리자가 알아서 할 것이라고 생각합니다. 관리자들도 프로젝트 계획을 세우는 일은 자시만이 할 일이라고 생각하죠. 그리고 프로젝트 관리자는 이런 인식을 토대로 프로젝트 계획을 마이크로소프트의 프로젝트를 활용해서 멋진 간트 차트로 만들어 팀원들을 모아놓고 일정을 설명합니다.
스크린에는 관리자가 심혈을 기울려 만든 3레벨짜리 WBS가 흘러갑니다. 팀원들은 팔짱을 끼고 의자에 기대어 관리자가 만든 프로젝트 계획을 묵묵히 바라봅니다. 팀원들은 왠지 저대로 하면 프로젝트가 성공할 것 같다는 생각도 들고, 한편으로 참으로 빡빡하게 일정을 짜놓은 팀장의 세심함에 가슴이 답답해집니다. 그리고 원인 모를 좌절감 내지 죄책감을 느낍니다. 계획 과정에서 적어도 뭔가를 했어야 하지 않았을까 하는, 그런 느낌 말이죠.
From 겸손한 개발자가 만든 거만한 소프트웨어
간트 차트의 다른 문제점으로, 프로젝트 일정을 팀원들이 자신이 것이 아닌 PM의 것으로 생각하게 합니다. 회의실에 팀원들을 모아놓고 MS 프로젝트를 사용해서 일정을 작성하는 걸 생각해 보죠. 프로젝터에는 PM의 노트북 화면에 있는 PM 프로젝트가 보일 겁니다. 팀원들은 회의 탁자에 둘러 앉아서 팔짱을 끼거나, 업무 수첩에 낙서를 하거나, 동료와 잡담을 하면서, PM이 MS 프로젝트에 입력하는 걸 ‘구경’할 가능성이 높습니다.
PM은 팀원들의 이야기를 들어가면서 WBS를 만들고 작업 사이를 연결하는 걸 자신의 역할이라고 생각하겠죠. 그리고 팀원들도 프로젝트와 관련된 중요한 작업을 하는 것 같은데, 당장 자신이 타이핑을 하지 않기 때문에, 자신의 역할이 아니라고 생각합니다. 즉 회의실에 모여 앉아서, PM이 MS 프로젝트를 사용해서 일정을 작성할 때, 그 일정은 팀원의 것이 아닌 PM의 것이라는 인상을 심어줄 수 있습니다.
그래서? 어떻게 하라고?
전 앞에서 설명 드린 이유로, SW개발 프로젝트를 할 때, 특히 명확하지 않은 것을 개발할 때 간트차트를 활용하는 걸 좋아하지 않습니다. 하지만 할 일이 명확하고 몇 번 경험이 있는 프로젝트는 어느 시점에 어떤 인력이 무슨 일을 할지 예측할 수 있기 때문에, 간트 차트가 도움이 될 수 있습니다. 즉 처음부터 어떤 일을 할지 거의 대부분 알 때에만, 간트 차트를 활용합니다.
이런 경우를 제외한다면, 프로젝트에는 불확실하게 지나치게 많기 때문에, 불확실성과 변화를 포용하려고 연동 계획하기(Rolling wave planning)과 포스트잇을 활용한 일정잡기를 사용하죠. 이 두 가지 방법은, 매니지 잇에서 자세하게 설명되어 있습니다. 상세한 내용을 원하시는 분들은 책을 참조하세요.
연동 계획하기는 앞으로 4주간의 상세한 일정만을 작성하는 계획하기입니다. 4주 이상 넘어가는 일정은 불확실한 게 많기 때문에 정확도가 떨어집니다. 따라서 일단 4주간의 일정 계획을 세운 다음, 1주일이나 2주가 지난 뒤, 프로젝트가 진행되고 나서 경험이 쌓였을 때, 다시 4주간의 일정을 세우는 방법입니다. 이런 계획을 세울 때, PM 혼자서 타이핑을 하는 MS 프로젝트를 이용해서 일정을 수립하지 않고, 모든 팀원이 참여해서 계획을 세울 수 있는 포스트잇 일정잡기를 이용하죠.
연동 계획하기를 할 때, 팀원들을 모두 모이게 한 다음, 손바닥만한 포스트잇을 나눠 줍니다. 벽 한면에 A1 종이를 붙이거나 화이트보드를 계속 사용할 수 있다면 화이트 보드에, 중요한 마일스톤을 표시하죠. 그러고 나서, 팀원들에게 포스트잇 한장에 필요한 업무를 적어서 종이나 화이트보드에 붙이라고 부탁합니다. 그러고 나면 정말로 멋진 일이 일어나죠. 팀원들이 처음엔 어색해 하다가, 포스트잇에 일정을 써서 붙이면서 서로 작업 사이에 연관 관계는 어떤지, 어떤 위험이 있는지, 목표는 명확한지 토론을 합니다. 이렇게 일정을 세우면, 팀원들이 직접 참여했기 때문에 MS 프로젝트 간트 차트보다, 프로젝트를 자신의 일로서 여기게 됩니다.
짧은 글에서 제가 생각하는 간트 차트의 문제점과 대안을 이야기했는데, 제가 인지하지 못한 간트 차트의 장점이 있을 수도, 제가 말씀 드린 방법의 문제점이 있을 수도 있습니다. 다만, 우리가 더 나은 것을 꿈꾼다면, 지금의 사용하는 방법은 교리가 아닌 여러 갈랫길 중 하나일 뿐이라는 걸, 더 나은 길이 있을 수 있다는 걸 말씀 드리고 싶었습니다. 
* 이것을 해결하는 방법으로 TOC도 있습니다. 상세한 내용은 골(The Goal)을 읽어보세요.
