工作进度反馈，有一种更优雅的方式吗？

工作进度反馈，这是站在员工角度的一种描述。如果站在管理者的角度，是工作进度跟踪，它的目标是为了让项目进度可控，从而降低项目风险。
它的表现形式是日报、周报，工具可能是在线填报、excel表格、甘特图进度更新、每日邮件、纸质表格等等。
本来，这个目标的动机无可厚非，但进度跟踪只是让项目进度可控的一种手段，而绝非目标。但给员工的感觉是，领导在监视他，甚至是季度发奖金的依据。所以，出于一种本能的自我保护，员工会虚报或谎报。
以我几年的经历，以及对其它公司的了解，我基本上没有发现有一个团队时积极主动地配合。

对于管理者，填日报或周报的动机，一般有以下几种：
1、了解项目进度，以便及时调整
2、根据工作日志，了解员工的工作负载及效率，以便改进绩效
3、观察团队各成员，看有没有偷懒的，做绩效考核时的依据
4、根据日志记录的工时，决定本月的薪水
5、根据日志记录的工时，以便部门向总公司要人月开支

以上几种我都经历过，虽然1和2是比较积极的，但员工的配合意愿还是很弱。
我觉得，最核心的原因是，管理者和下属之间，并没有真正建立信任。
对于1，难道只有工作日志这种手段吗？软件开发，不像建筑业，每天的工作进度，是可以用眼睛来观察的，并且进度几乎是线性递增。软件开发，特别是设计和核心模块的开发，一周的工作，很可能是前四天只完成功能进度的40%，后一天完成60%。如果项目经理不懂这些规律，他看到那40%，肯定是心急如焚。
怎么解决经理的焦虑呢？也许最好的办法是，每日及时沟通和下属主动反馈。但前提是，彼此间的信任。否则，下属感觉经理在催工，或者下属也没有反馈的勇气，因为自己四天才完成40%。
对于2，即使员工每天坦诚反馈，但对于项目经理，查看这么多人的日志，工作量很大，加上自己一忙，就忘了，反正也没人监督。但几周后，员工发现他写的日志只是一个摆设，于是也没有记录的热情了，一两句话了事。
对于3、4、5，就不用说了，员工会徘徊在职业道德的边缘。

对于工作进度反馈，在敏捷过程Scrum里，有每日15分钟的站立晨会，这是不用填工作日志的，呵呵。它的目标是团队间工作进度的沟通和协调。当然，它有敏捷宣言做前提。我觉得，如果生搬硬套也不太靠谱，理由有两点：
团队中可能存在一些技术新手，他们每天完成Scrum Master的期望进度不太现实，所以压力会非常大，导致工作时焦虑，而不是Scrum Master期望的强烈目标感。
有些工作是无法每天汇报进度的，特别是偏研发、技术攻关型任务，同样也会让某些成员焦虑、浮躁。
大家知道，软件开发最好的状态是relaxed、relaxed、relaxed。

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

对于我们小团队，在经历了各种进度反馈方法后，比如Jira工作日志、每日邮件通知、甘特图更新，我还是回到探寻问题的本源：不就是想了解项目进度和团队状态吗？而了解项目进度和团队状态，不就是为了项目进度可控和提升团队绩效吗？如果团队齐心协力、自动自发做事情，那还需要狠抓进度跟踪吗？
所以，我采取走动式沟通。当然这只是一种辅助，因为当团队超过六人，加上自己也承担具体开发任务，很容易拖延。
最重要的方法是，培养团队凝聚力+强化目标感，而在团队凝聚力(责任感+主动性)培养中，最重要是形成一种开放、信任、分享的氛围。
这东西有点虚，但效果实实在在。因为，你会发现，员工在一个任务阶段后，会主动口头给你反馈。不过，我们目前还是没有达到理想的状态。

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

评论

14 楼 jnoee 2010-08-28  

wwccss 写道

引用

做项目，肯定是要将目标和计划明确化，然后将目标分解成任务，将任务分配给人。

你这是传统的集权式的管理，你自己明确计划，分解任务，然后挑选合适的人，告诉他你要多长时间内完成。其实你真的一点也不懂敏捷。你这种管理方式，在决策阶段并没有大家的参与，基本上是你一个人在担当整个项目管理的责任。也就是说，项目的成功，是你自己的成功，不是团队的成功。试想一下，如果你换个项目经理，你自己不来带，我敢打赌，项目会乱成一锅粥。这是什么？还是作坊。

真正的敏捷实践和传统的项目管理非常重要的一点是团队的自我管理。在这里面，项目经理的角色不再是权力的象征，而是像教练一样，协调，服务，组织大家来去达到预期的目标。团队的任何一个人都可以提出自己的见解和看法，可以挑选自己喜欢做的任务。注意，是团队成员自己挑选自己喜欢做的事情，不是分配。

不知道你能不能体会到中间的区别。对于你这种性格的人来说，你太固执了。这也是你毕业求职，再三被人开除的原因吧。你总觉得自己太聪明，自我感觉太良好，放不下自己心里面的东西，自然也就接触不了其他的东西。

引用

那个每日晨会我觉得很可笑，因为这不是管理里面最基本的沟通方法吗？还搞得这么神圣？

如果你觉得这个东西可笑，那你才真的可笑。首先，这不叫晨会，是叫做站立会议。然后站立会议不是汇报工作，而是沟通，大家说下自己昨天做的事情，今天的计划，最重要的是有什么问题。

zwchen，真的建议你放下心里面的那份自傲，去好好研究下scrum，研究下敏捷开发。100%相信的去执行它，首先你要相信，然后才能怀疑。

你的发言表达的是一种偏执的态度，但实际上却不能帮助人解决问题。
所以我对你的发言是否来自于实际的项目运作表示怀疑。
或许你手头真有那么一个理想中的开发团队，你建立这么一个团队花了多长的时间？

楼主说到的问题即是我们团队也遇到的问题，我们也尝试了楼主提到的方法，但是结果目前还不是很满意。
目前我们觉得能起到作用的还是提高团队成员的积极性和鼓励团队成员主动反馈。
这方面效果比较显著，团队成员较最初建立团队时的表现已经好了很多，我们也已经由每日例会改为了每周总结会。
每天的工作日志我们并不看重，我们鼓励团队成员有问题及时面对面沟通，而不是通过提交文本的方式，或许某天我们会取消每天的工作日志。
但随之而来的是效率的问题，因为团队成员没有养成这样的工作习惯以及自身经验的限制，使得沟通的成本很高，但正在逐步的改善中，我们相信在一两个项目的磨合之后会取得良好的效果。

楼主前面一篇有关于习惯养成的文章也写得很好，一个成熟的团队自然也会有一套良好的习惯，而怎么快速的让团队新成员养成同样的习惯，怎么快速的让一个不成熟的团队成长为一个成熟的团队，是需要总结的。

或许我孤陋寡闻，但就我所知所见，国内大部分的软件公司连一套完整的项目管理流程都没有，有的软件公司名义上有管理流程但从来没有认真的实施过，更别说对管理流程的总结和改进了。
希望能看到国内优秀团队的经验总结、改进和讨论，将好的经验传播出来。随着互联网的发展，国内在软件技术上与国外的差距正逐步的缩小，但软件管理上还差得很远。

13 楼 sentryward 2010-08-28  

争论很大阿。不过感觉都说得有道理，呵呵。向各位学习了。

12 楼 brucewei777 2010-08-28  

讨论还是就事论事的好，这么讨论问题，着实不妥。

11 楼 lookdd1 2010-08-28  

每日的站立会议啊。。。scrum超级棒。

10 楼 wwccss 2010-08-28  

引用

做项目，肯定是要将目标和计划明确化，然后将目标分解成任务，将任务分配给人。

你这是传统的集权式的管理，你自己明确计划，分解任务，然后挑选合适的人，告诉他你要多长时间内完成。其实你真的一点也不懂敏捷。你这种管理方式，在决策阶段并没有大家的参与，基本上是你一个人在担当整个项目管理的责任。也就是说，项目的成功，是你自己的成功，不是团队的成功。试想一下，如果你换个项目经理，你自己不来带，我敢打赌，项目会乱成一锅粥。这是什么？还是作坊。

真正的敏捷实践和传统的项目管理非常重要的一点是团队的自我管理。在这里面，项目经理的角色不再是权力的象征，而是像教练一样，协调，服务，组织大家来去达到预期的目标。团队的任何一个人都可以提出自己的见解和看法，可以挑选自己喜欢做的任务。注意，是团队成员自己挑选自己喜欢做的事情，不是分配。

不知道你能不能体会到中间的区别。对于你这种性格的人来说，你太固执了。这也是你毕业求职，再三被人开除的原因吧。你总觉得自己太聪明，自我感觉太良好，放不下自己心里面的东西，自然也就接触不了其他的东西。

引用

那个每日晨会我觉得很可笑，因为这不是管理里面最基本的沟通方法吗？还搞得这么神圣？

如果你觉得这个东西可笑，那你才真的可笑。首先，这不叫晨会，是叫做站立会议。然后站立会议不是汇报工作，而是沟通，大家说下自己昨天做的事情，今天的计划，最重要的是有什么问题。

zwchen，真的建议你放下心里面的那份自傲，去好好研究下scrum，研究下敏捷开发。100%相信的去执行它，首先你要相信，然后才能怀疑。

9 楼 xiao0556 2010-08-28  

我之前的公司一直至力于效率软件的开发和研究提高效率的方法，我们公司也自己实践，然后总结于软件中，效果很好 FLEX实现的 大家上班就打开。
说一下我们一天的工作流程，每周一早上大家都开个小会 确定下这周的目标 和下面几周的打算，然后就打开页面，展开工作日志的界面，好点时间想想先干什么，然后建好今天的任务列表，如果是项目经理的角色就会分配一些任务给别人，别人完成的时候自己会收到通知。这个工作日志有相关的报表，每周，每天，每月都有统计，包括创建任务和完成任务的比例等等。还有一个便签就像冰箱上的贴的一张纸，大家都可以在上面写东西，有问题就可以写上面，还可以把问题转成任务分配下去，也是大家讨论的地方，每个项目都有自己的便签板，上面写贴满了项目相关便签，很随意但很有用。还有一些相关工具帮助我们管理项目进度，工作分解（有时会给能力高的人分配一个比较粗粒度的任务，他自己会分解。或是项目经理自己做分析分解），里程碑（给各个版本建好目标，根据项目的时间和任务完成度，给出一个比例）等等。
我们的平时的工作完全依靠自己的工作日志 很好用可以很清晰的知道自己要干什么有多少任务，那是紧急的重要的，那些是不紧急的，所以我们的工作进度反馈和工作日志很好的结合起来了。

8 楼 flashing 2010-08-28  

所谓管理，没有什么特效的办法，不然大家也不会如此头疼了。其实我的看法是得因人而异，因势而已。
比如刚进入团队的新人，你再信任他，也必须每天至少两次严格监督，不然非得乱套不可；对于老手，比较有经验的，这个时间则可以几天甚至每周。再比如时间紧的项目不允许你有任何偏差，必须紧跟；时间平缓的项目则不用跟那么紧，你有犯小错误的机会。
很多中层经理都犯想当然的毛病，自己当初是个很强的开发人员，就认为其他人也该这样，任务安排缺乏规划，简单粗暴分配，而且缺乏检查，出了问题又马上乱成一团。
我现在基本每天看一下fisheye的统计，每天代码量的增长曲线是否正常，不正常无论新手老手马上就可以发现问题；正常的话重点检查新手的功能和代码，直到他的代码和对业务的理解能赢得你的信任为止。
想靠团队自发的努力，实在是不靠谱的，不是团队不努力，而是即使努力，做的事情就是对的吗？经理不只是象征性的填写甘特图就得了。
其实主动回馈的确很重要，回馈不是回馈成绩，而是回馈问题；我现在的做法是每天写工作日志，mail发，对每个人都是个监督。
其实最后你会发现，失败的项目或者失败的管理，总结的时候你会发现遇到了各种问题，哪个都可能导致了失败；其实成功的项目或者管理呢，这些问题基本也都遇到了，困难一样存在，但是都没有成为阻碍。所以我经常说的就是撞一百次南墙也不知道路该怎么走，项目管理这个领域，成功经验和套路，比失败经验有意义一万倍。

7 楼 daquan198163 2010-08-27  

工作日志这个东西，如果需要手动去填写，那么很容易就沦为走形式，因为它实际上是给所有人增加了额外的负担，而人是懒惰的、容易犯错的、不喜欢重复劳动的动物。
因此，工作日志必须是可以从某个地方导出、生成的，这样既不增加工作量，也避免了人工填写导致的信息流失和失真。
我们现在就采用JIRA“微博”来生成工作日志


工作日志如此，文档亦如此。

6 楼 zwchen 2010-08-27  

wwccss 写道

根本的原因还是在于管理方式。是管理者让大家作事情，而不是团队成员自发作事情。其实你的这些困惑，敏捷开发的相关理论和实践都可以解决你的问题。但感觉你对敏捷没有太深入了解，或者是你太自信了。

做项目，肯定是要将目标和计划明确化，然后将目标分解成任务，将任务分配给人。这在任何项目管理都是必须的。
将任务分下去后，开始执行时，我始终觉得引力比推力更强大，也就是让员工感觉任务很有价值，实现它有成就感，他愿意主动去完成任务，达成目标。
可以这么说吧，只要我将任务安排下去，过几天后，任务就自动完成了，不需要我监督，虽然有时候可能和需求有点出入。这就是为什么我废除日报周报还可以掌握进度，当然有时候进度会延期，但这和监督与否几乎没有关系。

何谓敏捷？按时、按质、按量达成指定的目标。敏捷无定论，那个每日晨会我觉得很可笑，因为这不是管理里面最基本的沟通方法吗？还搞得这么神圣？认真研究这套书《职业经理十项训练》，你会发现所谓的敏捷方法，只是它的一个小子集(附件是电子版)。

5 楼 orcl_zhang 2010-08-27  

wwccss 写道

根本的原因还是在于管理方式。是管理者让大家作事情，而不是团队成员自发作事情。其实你的这些困惑，敏捷开发的相关理论和实践都可以解决你的问题。但感觉你对敏捷没有太深入了解，或者是你太自信了。

推动者,团队的自发性.

4 楼 Pigwen 2010-08-27  

我们一般是在每天scrum meeting前更新一下rally，项目组也习惯这种方式了，而且每个user story的owner也可以自己调整task的预估时间。

3 楼 wwccss 2010-08-27  

根本的原因还是在于管理方式。是管理者让大家作事情，而不是团队成员自发作事情。其实你的这些困惑，敏捷开发的相关理论和实践都可以解决你的问题。但感觉你对敏捷没有太深入了解，或者是你太自信了。

2 楼 zwchen 2010-08-27  

我竟然忘了我探索过的进度反馈方法：
第一阶段：Jira工作任务日志
每周一在Jira里创建团队成员的工作任务，然后团队成员下班前在任务下填写：已完成+待完成+体会，再加上耗时+进度。我自己也填写。推广到整个公司。
我每周汇总一次任务日志，然后发现问题并且改进。
但执行了大概九个月后，放弃了，因为打开Jira比较慢，下班时大家心情比较急切，填写意愿不大。

第二阶段：邮件反馈
下班前，项目组成员给我发邮件，标题：任务名称，内容：已完成进度+待完成+体会，几句话即可。
然后，我每天在Project文件的甘特图里更新进度。
执行到项目结束，效果还行。
但后来总结项目成败因素时，我觉得任务进度反馈，对项目影响微乎其微，特别是我们这个灵活的小团队。
于是，下一个项目，我是每周一上午挨个沟通，然后在他们那儿更新甘特图进度。

第三阶段:走动式沟通
也就是文中记录的，不重复了。

1 楼 orcl_zhang 2010-08-27  

引用

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

9个人以下的话,直接沟通是比较高效的,而且可以增进团结之间彼此的信任.