它的表现形式是日报、周报，工具可能是在线填报、excel表格、甘特图进度更新、每日邮件、纸质表格等等。本来，这个目标的动机无可厚非，但进度跟踪只是让项目进度可控的一种手段，而绝非目标。

　　但给员工的感觉是，领导在监视他，甚至是季度发奖金的依据。所以，出于一种本能的自我保护，员工会虚报或谎报。以我几年的经历，以及对其它公司的了解，我基本上没有发现有一个团队时积极主动地配合。

　　对于管理者，填日报或周报的动机，一般有以下几种：

　　1、了解项目进度，以便及时调整。

　　2、根据日志记录的工时，决定本月的薪水。

　　3、观察项目团队各成员，看有没有偷懒的，做绩效考核时的依据。

　　4、根据工作日志，了解员工的工作负载及效率，以便改进绩效。

　　5、根据日志记录的工时，以便部门向总公司要人月开支。

　　以上几种我都经历过，虽然1和2是比较积极的，但员工的配合意愿还是很弱。

　　我觉得，最核心的原因是，管理者和下属之间，并没有真正建立信任。

　　对于1，难道只有工作日志这种手段吗?软件开发，不像建筑业，每天的工作进度，是可以用眼睛来观察的，并且进度几乎是线性递增。软件开发，特别是设计和核心模块的开发，一周的工作，很可能是前四天只完成功能进度的40%，后一天完成60%。如果项目经理不懂这些规律，他看到那40%，肯定是心急如焚。

　　怎么解决经理的焦虑呢?也许最好的办法是，每日及时沟通和下属主动反馈。但前提是，彼此间的信任。否则，下属感觉经理在催工，或者下属也没有反馈的勇气，因为自己四天才完成40%。

　　对于2，即使员工每天坦诚反馈，但对于项目经理，查看这么多人的日志，工作量很大，加上自己一忙，就忘了，反正也没人监督。但几周后，员工发现他写的日志只是一个摆设，于是也没有记录的热情了，一两句话了。

　　对于3、4、5，就不用说了，员工会徘徊在职业道德的边缘。对于工作进度反馈，在敏捷过程Scrum里，有每日15分钟的站立晨会，这是不用填工作日志的，呵呵。它的目标是团队间工作进度的沟通和协调。当然，它有敏捷宣言做前提。我觉得，如果生搬硬套也不太靠谱，理由有两点：

　　团队中可能存在一些技术新手，他们每天完成Scrum M aster的期望进度不太现实，所以压力会非常大，导致工作时焦虑，而不是Scrum M aster期望的强烈目标感。有些工作是无法每天汇报进度的，特别是偏研发、技术攻关型任务，同样也会让某些成员焦虑、浮躁。

　　大家知道，软件开发最好的状态是relaxed、relaxed、relaxed。

　　还有一种方法，就是IBM Rational里面的ClearCase和ClearQuest集成，开发人员每天的工作成果，就是commit自己的代码，也就是ClearCase的提交操作(类似于CVS/SVN)，而提交时，正好用到ClearQuest这个任务日志记录工具，也就是说，提交时，一定要选择当初项目经理给安排的一个任务。这也就避开了任务日志要在任务执行后记录的烦恼。总之，下班后最后一件事情，是commit自己的成果物(代码或文档)，而不是打开公司的任务系统。 但IBM这套工具，特别是ClearCase太昂贵，另外学习和部署成本太高，对于小团队太重了点。

　　对于我们小团队，在经历了各种进度反馈方法后，比如Jira工作日志、每日邮件通知、甘特图更新，我还是回到探寻问题的本源：不就是想了解项目进度和团队状态吗?而了解项目进度和团队状态，不就是为了项目进度可控和提升团队绩效吗?如果团队齐心协力、自动自发做事情，那还需要狠抓进度跟踪吗?

　　所以，我采取走动式沟通。当然这只是一种辅助，因为当团队超过六人，加上自己也承担具体开发任务，很容易拖延。

　　最重要的方法是，培养团队凝聚力+强化目标感，而在团队凝聚力(责任感+主动性)培养中，最重要是形成一种开放、信任、分享的氛围。

　　这东西有点虚，但效果实实在在。因为，你会发现，员工在一个任务阶段后，会主动口头给你反馈。不过，我们目前还是没有达到理想的状态。

　　但我这种方式，并不适合大公司，特别是大型团队，因为它们更倾向于制度化管理。它们的日常管理工作，不应该依赖于管理者的个人英雄主义。如果有一个项目立项，临时组建一个团队，要培养彼此间的高度信任，何其难。因为信任的建立，是一条漫漫长路。

　　总的来说，在项目管理过程中，处理好团队之间的沟通时很重要的。