Estimating and scheduling – the most exciting parts of the milestone

From http://blogs.msdn.com/gunnarku/archive/2004/06/23/164257.aspx
Project Manager가 프로젝트의 처음 단계에서 생각해야할 것들
– How much it’ll take
– Who’ll do it
– What are the priorities and risks associated with every tasks
– How the dependency graph looks etc.
Project Manager가 항상 답변할 수 있어야 하는 질문들
1. On what people in my team are currently working/worked/will be working?
2. How much time something takes/took/will takes?
3. How much the current schedule deviates from the original one?


상반기 동안의 Project Management 경험에서 2주 정도를 tool을 찾아다닌 적이 있는데, 결국 내가 원하는 완벽한 툴은 찾지못했다. Microsoft Project의 부분적인 기능만을 사용해서 Gantt Chart만 유지하고, 현재 상황은 구두로 물어서 파악했다. mook 형 말대로 ‘PM은 부지런해야하는 것’이었다. 어떤 분야에서도 적용되는 tool의 딜레마로, tool이란 어떤 일에 있어서의 효율성을 위해 사용하는 것이지만, 그것이 어떤 일을 항상 잘하도록 보장해주지 못한다는 것을 다시금 깨달은 것 같았다. tool을 사용하는 목적을 잊어버리고, tool을 사용하기 위해서 사용하는 것은 자주 범하는 오류중의 하나인 것 같다.
그 외에 몇가지 깨달은 것이 있다면, 위와 같은 질문에 대답하기는 어렵다는 것이다. 가장 힘들게 하는 요소는 프로젝트 진행중에 끼어드는 다른 일정, 바로 리스크였는데, 이러한 리스크가 발생했을 때 나는 전혀 어떻게 대처해야하는지 알 수 없었고, 단지 일정만 계속 연장했을 뿐이었다. 사실 지금도 어떻게 해야하는지 잘 모르겠다. 여기에 대해서 좀 더 생각해보아야할 것 같다.
그 외에도 팀원과의 커뮤니케이션 방법은 어려운 것 중의 하나였다. 매일 직접 팀원의 자리로 가서 진행상황을 물어보아야 하는 것인가. 일정을 독촉하는 같아서 꺼리게되는 경향이 나타났는데, 이것은 내 커뮤니케이션 스킬의 부족인가? 이러한 것은 프로세스나 툴의 도움을 받아서 얼마든지 개선할 여지가 있을 것 같다. 그 당시에도 일별 작업 리스트 (TODO) 보내기를 해보자고 생각했었는데, 결국 실행에 옮기지 못했던 것이 후회스럽다.
또 다른 한가지 발견점은, 위의 얘기와 비슷한 얘기일 수도 있겠지만, 어떤 일을 어떤 사람에게 할당하고 나서, 일정에 따라 그 작업이 마쳐지기로 한 날에 결과물을 달라고만 해서는 절대로 제대로 될 리가 없다는 것이다. 물론 사람에 따라 잘해내는 사람도 있겠지만, 대부분은 그렇지못하고, 내부/외부적인 벽에 부닥쳐서 제대로 수행하지 못하고 있는 경우가 많다. 더욱 주목할 점은 이러한 벽에 부닥쳤을 때, 팀원이 PM에게 피드백을 주는 경우는 매우 드물다는 것이다. 이러한 것을 해결하기 위해서는 역시 그러한 프로세스나 툴이 도움을 줄 수 있을 것이라고 생각한다. 여기서도 일별 작업 리스트가 유용하지 않을까 생각한다.
이 외에도 부족한 점은 많겠지만, 역시 능력상의 부족으로 앞으로의 경험에서 더욱 많은 것을 배워야하리라 생각한다.

댓글 남기기

이메일은 공개되지 않습니다. 필수 입력창은 * 로 표시되어 있습니다

이 사이트는 스팸을 줄이는 아키스밋을 사용합니다. 댓글이 어떻게 처리되는지 알아보십시오.