在一个项目的实施过程中，工作进度反馈，这是站在员工角度的一种描述。如果站在管理者的角度，是工作进度跟踪，它的目标是为了让项目进度可控，从而降低项目风险。

　　它的表现形式是日报、周报，工具可能是在线填报、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)，而提交时，正好用到