나는 개인적으로 프로젝트에 대해 연구를 많이 한다. 목표를 가지고 살아간다는 것은 결국 프로젝트를 진행한다는 것이며, 모든 것은 작던 크건 프로젝트로 분류할 수 있다. 사람이 나아가는 길에는 항상 프로젝트와 결부되어 진행할 수 있으며, 개인이든 조직이든 프로젝트의 마일스톤대로 나아가며 성취를 할 수 있다고 생각한다.
때문에 일정관리나 시간관리, 자기계발 등은 20대 들어 나의 가장 주된 관심사중 하나였는데, 이는 내가 벤처를 운영하면서 PM을 도맡게 되어서 더욱 더 크게 와닿던 부분이다. 사람을 관리하는 데 있어서 특히 PM에게는 더 없이 프로젝트를 관리하는 것이 중요하게 여겨지기 때문에, 이 부분이 살짝이라도 Miss나거나 하면 프로젝트는 금방 산으로 가기 일수였기 때문이다.
당시에 나는 처음에는 개발 기획을 토대로 각 팀별 주간보고를 취합하여 이를 가지고 나의 기준에 맞춰서 진척도를 환산하곤 하였다. 허나, 이 부분에서는 많은 부분의 공백이 생긴다. 자원, 재정, 기술적인 결함, 그리고 당장 다음주에 있을 각종 휴일이나 연휴 및 근무시간, 팀 분위기에 따른 업무 집중 시간 및 단위 테스트 및 빌드시간 등등. 이 부분을 단순 주간보고 형태의 취합으로는 도저히 내가 예측할 수 있는 부분의 한계가 정해져 있었다.
결국 나는 고심끝에 MS Project의 WBS(Work Breakdown Structure) 즉, Gantt Chart를 통해 각 팀장들이 자기 팀의 스케줄을 정하고 이에 따라 나는 최종적으로 각각의 간트 차트들을 통합하여 하나의 WBS로 만들고 MS Project의 다양한 보고서를 통해 관리를 할 수 있게 되었다. 예를 들어 각 팀원별 시간분포표 라든가, 업무 진척 Gantt Chart 등은 내가 프로젝트를 한눈에 알아보기 더 편하게 설계되어 있었다.
허나 문제점은 MS Project는 “제조업”을 위해 설계되었다는 점이다. 소프트웨어 개발에서 가장 중요한 것은 사람이다. 개개인의 사람들이 저마다 생각이 다르고, 디자인이든 프로그래밍이든 정해진 것은 없다. 디자이너는 나름대로의 Creative를 발휘하여 결과물을 내놓고, 프로그래머는 자기만의 Logic을 구상하여 결과물을 내놓는다. 그래서 이런 WBS만으로 단순히 프로젝트에 대한 평가가 힘들다는 것이다.
서론이 길어졌는데, 어쨌든 나는 나 개인에 대한 프로젝트(아이젝트라고 통칭한다.)에 대해 이러한 WBS를 적용하기로 하였다. “할일”을 관리하는데 있어서 아웃룩도 좋고 GTD방식의 툴도 좋고 Franklin Covey방식도 좋지만, 어떤 툴도 약간씩은 허점이 존재하였다. 간단한 일정 관리야 구글 캘린더가 최고이지만, 디테일하게 나의 스케줄을 정리하고 마일스톤을 관리하는 데에는 어떠한 툴도 나를 만족시키지 못했다.
거창하게 WBS로 할 것인가? 에 대해 상당히 망설여 졌는데, 어차피 툴이라는 것은 내가 만족할 만한 기능이 있으면 되는 것이고, 무엇보다 어떤 툴이든 간에 내가 자주 보고 반성할 수 있고 관리할 수 있어야 한다는 것이다.
때문에 나는 이번에 이렇게 WBS로 나의 개인 프로젝트를 설계한 만큼, 이를 자주 보고 자주 반성하고 자주 관리할 수 있도록 매진할 수 있도록 해야겠다.
