项目经理实践-怎样进行项目计划跟踪？

[zhishao]

关于项目计划的跟踪，您是怎么做的呢？不管好坏，大家一起探讨一下而已。


先说说我个人的经历。

在项目开始的前期阶段，我总是能列出很详细的项目计划。但随着项目的进行，新任务不断出现，任务的状态也需要不断跟踪。只要一两天忘记跟踪计划，这个计划基本上就已经残废了，不再有实用价值。

在六年里，我试过三种计划跟踪的方法。第一种是主动地向项目团队获得项目进展的信息。方法是每天上班后花10分钟开个早会，明确一下每个人当天的工作任务，然后我更新并发布项目计划。每天下班前花15分钟，了解每个人的工作进度，记录遇到的问题，并把进度同步到项目计划中。

——这种方式，在某种程度上扼杀了团队的主观能动性，可能管得太死，项目团队有抵触情绪。

问题：因为大家并没有及时地记录下处理任务的时间，收集到的任务的实际工期的精度比较低。另外，早会还好，但下班前的会经常由于打断开发人员的工作或思路，召集的时间甚至长过汇报时间。大家抱怨每天浪费时间这半个小时常常导致大家被迫加班。我个人稍微估算了一下，0.5小时 X 10人 X 200天 = 4.2人·月，浪费的时间还真是很可观。


第二种，由项目团队主动用EMAIL、电话或口头向我汇报每天的工作进展。方法是每个人在接受到团队其他人转出的任务，（比如测试、文档等），遇到问题，以及完成某项任务时，及时以各种方式通知我。

——集中汇报给我一个人的方式，造成我是监工的事实。对于天生爱自由和害羞的项目团队而言，无异于暴露个人隐私。

问题：很快，我就发现并不是每个人都能很主动的汇报。我经常会不知道项目团队在处理什么样的事情。有时候直到问题积累到一定程度，爆发出来的时候，我才了解到。


第三种，白板方式。在项目团队的视线范围之内放置一块白板，分左右两栏。左栏列举整个项目的概况，比如关键的几个里程碑或者阶段，并标出当前阶段的位置。右栏标明当前（当天、本周或者本月）的努力方向作为标题。然后在下面列出当前正在进行的任务项、问题。大家随时更新相关的任务和问题。

——由于将个人监督扩展为群众监督，执行起来阻力很小。甚至，白板也逐渐成为团队文化培养的基地，大家会在白板的空白处抒发个人的感想，或者感激他人的言辞。所以，这也是我目前一直在使用的方式。

问题：白板的容量有限，所以，我们不得不定期清除已经完成的任务，已经解决的问题等。没有很好地将这些宝贵的财富留给后人以及我们自己未来的项目开发及管理。很浪费呀！（感叹……）

附：
我用过一段时间的MS Project + Project Server + SharePoint Server。从计划跟踪的角度上来讲，效果很好。这套系统并不能实现任务的流转和上下文环境的保留。所以，个人认为效果上与我上面说的白板方式差别不太大。但是，我还是希望有一种更好但价格适中的信息系统出现，以减轻目前项目经理的做这种比较繁琐且附加值并不高的事务性工作。


最后，别忘了分享一下您的做法，三块石头擦出来的火花会比两块石头大吧。:)

[小斧头2]

我们在做项目过程中，每个项目成员都会写工作日志，记录每天的工作情况。我则每天早上CHECKOUT出来，就可以知道他们前一天的工作进展，非常有效！这是我们公司的基本要求哦！

[zhishao]

我们公司还没有把项目管理上升到制度的层次，遗憾！

[appow]

这个可以学习一下我们伟大的党.


看看群众怎样过组织生活,党对群众如何管制,如何教育,如何....

[8225511asdf]

我个人的做法是通过立项，并在做项目计划时，会预留时间，便于大家对于突发事件的处理.对于项目定义而言一个好的建议是：
尽量把项目的周期缩短，比如一个月的项目
明确立项结项，让所有成员明确项目的目标与规模
定义清楚每个成员的角色与任何项
任何项一定要细，最好不要超过3个工作日，否则无法执行
项目一定要杜绝变更，否则带来的代价会更高

[liusen770501]

看来这个话题感兴趣的人多啊，大家都有很多共同的感知。偶也来谈谈。我是这样管理的。
我把项目管理分为三大块：机会跟踪、配置管理、质量管理。
一、计划跟踪。每年制定年度计划，由各开发小组（可以按软件工程的模型来分也可以按功能来分）提交各组计划，管理小组来负责评审和整合。
每季度根据年度计划制定季度计划，方法同上。
每周根据季度计划制定各小组周任务计划，由各组自行制定。

[liusen770501]

跟踪控制方法：通过每周一要求提交各组周任务计划和每周五召开例会确认任务完成情况，解决协调问题。ＳＱＡ介入，总结和汇报本周出现的问题，包括内部问题，客户反馈问题，系统ｂｕｇ等。

[jerryxuyu]

您控制的过细了
项目经理需要控制的是 里程碑计划
而不是每天的工作

[SoftnShare]

软件的项目管理无法避免以下事务:
需求制定与确认、工作追踪、缺陷确认追踪与修正、变更确认与追踪、Source Codes版本控制和质量监督, 且必须监督开发时程和资源是否掌握于预算内

从需求阶段开始则必须和客户或产品经理沟通沟通. 做多次的功能规格讨论和确认, 达成双方一致认可的规格和价格后,才可开始进行项目. 此阶段需求书将经常修改且双方将就每项需求做详细的讨论与追踪. 故此时若有工具帮助规格书版本管理和需求讨论和追踪，将有很大的帮助. 需求确认后,需求将转为功能,再从功能转为开发工作分发, 此时MS Project这类型的工具可帮上忙, 不过工作已花了多少时间, 工作目前的status, 是否遇到问题, 工作的产出在哪里, 相对的source codes在哪里, 这些都不是MS Project可以管理的, 如果有和source codes version control system整合的工作追踪软件帮忙,将有很大的帮助. 此外, 搞清楚哪些工作可完成哪些需求也是很重要的, 如此才可掌控工作的priority, 了解应完成哪些工作才可完成哪些需求,做阶段性的版本release. 每版release后, 经测试发现的bug, 则需要一一确认和追踪, 解决可reproduce且具经济效益的bug. 此方面采用缺陷追踪工具将很有帮助, 在开发的过程,或客户看过阶段性release的版本, 提出任何需求变动或功能修改, 在软件项目上也是无可避免的, 所以这些变动也需要受到严格的控管,此方面若有变更管理工具将很有帮助.

以上所提的bug或变更的追踪管理工具, 若与version control的工具整合, 将可帮助项目管理者更清楚地掌控所有的bug fix和变更事项的进度与质量, 且对于未来的系统维护和source codes重复运用将有很大的帮助.

不妨参考美国政府USDA软件开发项目的计划说明, 他们采用的是CodeBeamer+Subversion的组合　http://www.iscmem.org/Documents/Public_Meeting_2006_08_24/WG1%20Status%20Report%202006.pdf　　

[sg552]

楼上， 项目经理需要控制的是 里程碑计划，

但是如果下面团队中的程序员水平不够的话，是很难带的。
哎。。。

我认为，如果手头的程序员能力差，
项目经理再强也没用。

巧夫难为无米之炊啊。

[老班长1982]

我也遇到一些项目上的烦恼，谢谢，学习一下。

[xiongliang2003]

我觉得这个完全是个设计粒度的问题。

你的计划订的不必要那么详细，很多时候只要定义到某个层次就行，其他的有公司的实施人员来做。你只要主要的，主体的，层次稍高的框架。至于最低层次的，你可以授权给团队成员来完成，或者检测。
LZ还没有完全从技术转型过来，还是个完全技术人员的思想，这个用什么技术都是解决不了根本问题的。你把时间都放在技术实现上了，你还有时间去做项目经理该做的事情 上吗，

[cityyokel]

管理思想是很重要，但有好工具的辅助，往往很快达到事半功倍的效果。
推荐一个开源的工具trac，它把wiki、subversion、milestone、bug track等等功能都集成了。

[lichaoyongbj]

我做项目8年，基本使用Word、Excel觉得就够了。
个人认为一个团队人员结构要配置合理，2个测试人员、2个和客户进行业务交流、3－4个代码开发、2个人具有业务、代码都相通的人员，这样就可以业务将需求做好交给代码开发，开发好后交给测试人员，在这个过程中代码设计有问题，就推动业务人员去沟通客户；测试有问题，提交给代码开发人员进行修改，而项目经理就是推动大家各负其责，项目做起来就流程多了。
项目经理可以专注整体把握，每个业务分解到具体时间完成，各个人员都有整体时间表（其实这个时间表就是他们自己相互协商制定的，执行起来一般问题不大）。我一般是提前告诉一下相关人员，某某事情快要到期了，他们知道后，一般会按时完成的。不过话说回来，这个团队我带了2年多了，相互很熟悉。同时人来人往，但是每个新人都要求他们按照这个制度去做，到现在没有出现大的问题。
Excel将每件事情记录下来：内容、客户提出日期、客户要求完成日期、责任人、是否已经完成等。如果完成关闭此事情。所以大家看到都是统一的Excel版本文件，都是自己手头工作，并且很明了哪个人在最近做什么事情，哪个人员比较闲，哪个比较忙，在随时将任务调配。

[lhling]

除了进度还有很重要的就是质量，质量和进度都必须可控
强力推荐项目主管，研发组长使用
http://www.jesoft.cn 极易缺陷管理系统，我自己在用，进度明了。很多东西只要做了，就简单，需要我帮忙的可以问我 qq:8976032

[swordlqm]

各种方法都有利弊,重点是在项目组或者公司内形成共识,大家都想把事情做好,前提是要把做事的观念和意识上要统一,这样建立起来的制度就能很好的执行,否则推动起来非常困难,并且抵触的人会比较多。

[swordlqm]

“MS Project + Project Server + SharePoint Server”只是一个工具而已，而你的管理思路和方法要落实起来，重要的还是看团队当中的人是否有共识，这好比我们跟客户做一个系统，如果靠一个系统去约束用户的行为标准是不现实的，重点还是要先把用户的观念、意识转变过来。

[hoopp]

我的经验是：
1、用什么做工具软件不重要，其实word+execl应该足够了。
2、关键是用什么方式去沟通，不同的人喜欢不同的方式，必须对团队成员有较好的理解。
3、项目经理了解的都是成员反馈的，不同的成员对一个事情完成了多少的理解是不同的。
4、根据组织（公司）开发的惯例，对项目进行阶段划分，根据经验安排阶段的时间。跟踪一个阶段的进度相对容易。
5、项目经理（如果项目不配技术经理的话）要对项目组成员的工作量相对于成员的天数有大概的估计，然后以改估计和成员的反馈来评估。
6、一定要记住，跟踪进度是为了及时完成，不是评估成员的能力。
7、不同的性质（纯开发如外包/组织协调大型项目等）要对进度留出不同的富余时间。
8、项目经理的能力大致体现在：对业务需求的把握、工作量的估计、成员完成能力的把握、内外部客户的协调能力等方面。

[youngRoader]

楼主，你也去过mypm哦
ｍｓ　ｐｒｏｊｅｃｔ那一套，我配置上总有些问题
想请教你
msn:[e-mail]

[AIRFLYNET]

学习

[mycode]

我的做法：
一次性制定出项目计划，
每周进行一次项目计划的调整；
针对不同的人员，进行不同方式的跟踪；
项目计划的调整是根据实际情况来进行，进度的时间与实际执行任务的人员进行充分的沟通。
每天都要了解一下各个成员的进展情况；成员遇到问题时，一定要及时想办法解决。