Burn down chart
요즘 제가 맡은 프로젝트는, 솔루션을 업무에 적용하는 것이기 때문에, 맨땅에서 개발하지 않습니다. 즉, 고객에게 보여줄 꺼리가 완비되어 있기 상태이기에, 반복적인(iterative) 개발 방법을 사용해서, 최종 제품에 비슷한 프로토타입(Prototype)을 만들어 고객에게서 피드백을 받습니다
며칠 전에 첫 번째 프로토타입을 완성해서, 고객에게 첫선을 보였습니다. 업무를 온라인화하는 성격의 프로젝트여서 정작 시스템을 사용해야 하는 고객들은, 인터뷰와 프로세스를 잡는 과정 동안 시스템이 너무 복잡하지 않을까라는 걱정을 많이 했는데… 다행스럽게도 프로토타입을 직접 사용해 보더니, 의구심이 말 그대로 의구심 수준에서 끝났습니다. 그리고 프로토타입에 만족한 고객들이 양질의 피드백을 많이 주었습니다.
시스템 오픈까지, UI에 이쁜사용성이 좋은 디자인을 입히는 작업, 끝내지 못한 기능 몇 가지 완성하는 것, 그리고 프로토타입을 통해서 받은 추가사항을 반영하는 작업이 남았습니다. 물론 팀원들은 각자 맡은 역할의 뷰포인트에서 남은 작업을 바라보지만. 전체를 바라보는 PM 관점에서 남은 기간에 효과적으로 작업을 관리하고 시각화할 수 있을지 고민했습니다.
팀원과 함께 위에서 말한 세 가지 범주에 대해서, 구현을 어떻게 할지, 구현에 문제는 없는지, 일정에 영향을 줄 리스크는 없는지 등 관점에서 작업할 것을 나열하고, 정보 방열기에 작업 목록을 게시했습니다. 작업 진행방식으로써 팀원들이 자신이 처리하고 싶은 작업을, 아침에 실시하는 스탠드업 미팅에서 말하고 작업하는 방법을 사용했습니다.
사실, 지난 주부터 시스템이 오픈될 때까지, 예상하지 못한 리스크가 나타나지만 않으면… 제가 관리할 것은 그다지 없습니다. 다만, 스탠드업 미팅에서 소소한 이슈들이 나온다면, 적절하게 업무 조정할 작업이 제가 할 업무의 전부죠(물론 개발 관련 외 할 잡무업무가 많지만요).
깔끔하게 정리된 정보 방열기를 보면서, 팀원들이 적절한 속도로 작업을 하고 있는지 시각화할 수 있다면 좋겠다는 생각이 들었습니다. 그래서 생각난 것이 Burn down chart였습니다. 아래 그림처럼, burn down chart의 Y축에는 남은 기능, X축에는 날짜를 표시합니다. 즉, 팀의 개발 속도를 측정할 때 유용합니다. 기능을 비슷한 작업량으로 나누었다면 팀의 개발속도는 상수값이 되겠죠.
위의 그림은 팀의 burn down chart와 유사한 모양입니다. 초반에 속도가 빠른 이유는, 아마도 손쉬운 기능 위주로 팀원분들이 개발하셨기 때문일 것 같습니다. 
다른 이유를 찾자면, 작업 위주로 나누었기 때문에, 작업 당 일의 양이 균일하게 되지 않은 탓도 있습니다. 빨간색 선이 어떤 의미가 있는 것은 아니지만, 심리적으로 저 선을 넘어가면 왠지 불안할 것 같다는 의견을 팀원이 주셨는데… 이 이야기를 하면서 확실하게 관리하려는 PM의 불손한 의도가 숨겨진 것 아니냐는 예리한 질문에, 순간 당황스러웠습니다. 
팀원들이 모두 한 스마트하십니다!
About the Author
This is Hani! My job is consulting, system design and project management... Sometimes coding. I hope you have a great time on my blog.