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

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

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

评论

34 楼 frostred 2010-08-29  

lookdd1 写道

frostred 写道

Agile强调交流的重要性，Scrum就整出个站立会议来。
当然，如果它是一个团队唯一可行的交流方式，它也无可厚非，毕竟它只用５到１５分钟。但在每天固定的某一个时间打断每一个成员的工作，毕竟不是一个好的方法。
而且，　因为它只用５到１５分钟，所以交流的信息量是很有限的。还有它是在每天固定一个时间进行，所以有些时候，对于某些问题也是不够及时的。
其实，站立会议违背了交流的最基本的特征的。交流的需要往往是非常随机的，你往往不知道什么时间需要交流，有时候你只需要一分钟来交流，有时候你需要几个小时。
所以对于交流来说氛围的创造比某种固定的实践更重要。如果，小组中每一个成员都愿意分享他们工作中的成功和挫折，都愿意帮助别人和愿意被别人帮助，那么交流自然就有了。如果小组中每一个成员基本上都知道别人昨天干了什么，今天在干了什么，项目中有什么棘手的困难，那么，站立会议自然是完全没有必要了。

偶只是略微实践过传说中的scrum。完完全全的伪敏捷啊。。。
交流不是时时刻刻的，而且交流同样是成本很高的（占用时间，打断别人的思路）。同样，团队成员不可能交流到“基本上都知道别人昨天干了什么，今天干了什么，遇到什么困难”这种程度，我开发自己的，管别人干嘛，只有老大关注这些。但老大又不可能一天老是问团队成员这些东西。所以每日早的站立会议偶实践感觉非常棒。同时，我也认为每天都要有几个小时的时间是完全无交流的时间，禁止一切打扰开发思路的事情。

所以说，如果它是一个团队唯一可行得交流方式，站立会议也没什么大问题。毕竟，用５到１５分钟了解一下大伙都在干什么，有什么问题，也是不错的。问题是它跟敏捷开发扯不上什么关系，更不是敏捷开发的充分必要条件。

团队成员交流到“基本上都知道别人昨天干了什么，今天干了什么，遇到什么困难”这种程度,　是可以做到的。尤其是真正敏捷开发的团队，更不是什么难事。
首先，敏捷开发一般尽量保持团队规模小。敏捷开发中有“ｔｗｏ ｐｉｚｚａ ｔｅａｍ”　的说法。意思是，如果两张比萨饼喂不饱你的团队的话，证明你的团队太大了。换句话说，一个团队不应该超过３个人。
３个人的团队，做到大伙都基本上都知道别人都在干什么，有很难吗？更不要说团队成员经常的做一些pair programming.

33 楼 xfly_t 2010-08-29  

lookdd1 写道

frostred 写道

Agile强调交流的重要性，Scrum就整出个站立会议来。
当然，如果它是一个团队唯一可行的交流方式，它也无可厚非，毕竟它只用５到１５分钟。但在每天固定的某一个时间打断每一个成员的工作，毕竟不是一个好的方法。
而且，　因为它只用５到１５分钟，所以交流的信息量是很有限的。还有它是在每天固定一个时间进行，所以有些时候，对于某些问题也是不够及时的。
其实，站立会议违背了交流的最基本的特征的。交流的需要往往是非常随机的，你往往不知道什么时间需要交流，有时候你只需要一分钟来交流，有时候你需要几个小时。
所以对于交流来说氛围的创造比某种固定的实践更重要。如果，小组中每一个成员都愿意分享他们工作中的成功和挫折，都愿意帮助别人和愿意被别人帮助，那么交流自然就有了。如果小组中每一个成员基本上都知道别人昨天干了什么，今天在干了什么，项目中有什么棘手的困难，那么，站立会议自然是完全没有必要了。

偶只是略微实践过传说中的scrum。完完全全的伪敏捷啊。。。
交流不是时时刻刻的，而且交流同样是成本很高的（占用时间，打断别人的思路）。同样，团队成员不可能交流到“基本上都知道别人昨天干了什么，今天干了什么，遇到什么困难”这种程度，我开发自己的，管别人干嘛，只有老大关注这些。但老大又不可能一天老是问团队成员这些东西。所以每日早的站立会议偶实践感觉非常棒。同时，我也认为每天都要有几个小时的时间是完全无交流的时间，禁止一切打扰开发思路的事情。

大多数人都只需管好自己，少数人需要了解别人在做什么，遇到什么困难，怎么解决
同样只有少数人去才有机会管大多数人

32 楼 lookdd1 2010-08-29  

frostred 写道

Agile强调交流的重要性，Scrum就整出个站立会议来。
当然，如果它是一个团队唯一可行的交流方式，它也无可厚非，毕竟它只用５到１５分钟。但在每天固定的某一个时间打断每一个成员的工作，毕竟不是一个好的方法。
而且，　因为它只用５到１５分钟，所以交流的信息量是很有限的。还有它是在每天固定一个时间进行，所以有些时候，对于某些问题也是不够及时的。
其实，站立会议违背了交流的最基本的特征的。交流的需要往往是非常随机的，你往往不知道什么时间需要交流，有时候你只需要一分钟来交流，有时候你需要几个小时。
所以对于交流来说氛围的创造比某种固定的实践更重要。如果，小组中每一个成员都愿意分享他们工作中的成功和挫折，都愿意帮助别人和愿意被别人帮助，那么交流自然就有了。如果小组中每一个成员基本上都知道别人昨天干了什么，今天在干了什么，项目中有什么棘手的困难，那么，站立会议自然是完全没有必要了。

偶只是略微实践过传说中的scrum。完完全全的伪敏捷啊。。。
交流不是时时刻刻的，而且交流同样是成本很高的（占用时间，打断别人的思路）。同样，团队成员不可能交流到“基本上都知道别人昨天干了什么，今天干了什么，遇到什么困难”这种程度，我开发自己的，管别人干嘛，只有老大关注这些。但老大又不可能一天老是问团队成员这些东西。所以每日早的站立会议偶实践感觉非常棒。同时，我也认为每天都要有几个小时的时间是完全无交流的时间，禁止一切打扰开发思路的事情。

31 楼 frostred 2010-08-29  

Agile强调交流的重要性，Scrum就整出个站立会议来。
当然，如果它是一个团队唯一可行的交流方式，它也无可厚非，毕竟它只用５到１５分钟。但在每天固定的某一个时间打断每一个成员的工作，毕竟不是一个好的方法。
而且，　因为它只用５到１５分钟，所以交流的信息量是很有限的。还有它是在每天固定一个时间进行，所以有些时候，对于某些问题也是不够及时的。
其实，站立会议违背了交流的最基本的特征的。交流的需要往往是非常随机的，你往往不知道什么时间需要交流，有时候你只需要一分钟来交流，有时候你需要几个小时。
所以对于交流来说氛围的创造比某种固定的实践更重要。如果，小组中每一个成员都愿意分享他们工作中的成功和挫折，都愿意帮助别人和愿意被别人帮助，那么交流自然就有了。如果小组中每一个成员基本上都知道别人昨天干了什么，今天在干了什么，项目中有什么棘手的困难，那么，站立会议自然是完全没有必要了。

30 楼 xfly_t 2010-08-29  

frostred 写道

Agile和Scrum不能混为一谈。
Agile提出的是一套开发的原则和理念，它并没有给出具体的实践方法。
Scrum原本是基于Agile理念的一些具体实践。它原本没有错，只是近几年被卖证书和卖产品的人搞的越来越面目全非，越来越远离Agile的核心理念 。
Agile 宣言的第一句就是：“Individuals and interactions over processes and tools.”。 而卖证书的或卖产品的人为了他们的生意，一定会强调process和tool的重要性的。

支持，工具过程只是辅助作用不能取代沟通交流

29 楼 xfly_t 2010-08-29  

wwccss 写道

引用

个人经验看，Scrum在团员成员能力都还不错的情况下才可能很好的执行scrum流程

如果团队内有好个新人，完整的Scrum流程就不那么好执行了，也没很多合适的新人任务

水平一般的人每天站立会议给你的反馈可能就只有还在开发写代码过程中，只有每周才可能形成一定的成果

LZ的团队主要在技术成长过程中，对敏捷有了一定的裁减

scrum团队成员未必要能力都很好，但有一个懂得scrum流程的scrum master是很重要的。他要负责训练大家，就像教练一样，把大家带出来。

站立会议的反馈，并不是要汇报工作结果。而是团队成员之间互相沟通，更新彼此的信息，还有就是及时发现风险。

比如站立会议中一半的以上的人一周的反馈基本是：我昨天在做A模块(xxx部分)，今天还做A模块(xxx部分)，没什么问题（还在写代码能有什么问题）。
如果是这样的交流，感觉意义不大。或有什么更好的交流方式？

基于上面这种情况，才要团队成员能力要比较好，交流效果会比较好

题外话：现在公司一般人员都是新人和次新人比较多，能把大家带出来，实施scrum真的很难得，也需要很强的能力

28 楼 frostred 2010-08-29  

Agile和Scrum不能混为一谈。
Agile提出的是一套开发的原则和理念，它并没有给出具体的实践方法。
Scrum原本是基于Agile理念的一些具体实践。它原本没有错，只是近几年被卖证书和卖产品的人搞的越来越面目全非，越来越远离Agile的核心理念 。
Agile 宣言的第一句就是：“Individuals and interactions over processes and tools.”。 而卖证书的或卖产品的人为了他们的生意，一定会强调process和tool的重要性的。

27 楼 wwccss 2010-08-29  

其实scrum里面非常重要的一点，就是大家每天要更新自己负责任务的预计剩余时间。然后画成燃尽图。这个图可以非常明显的看出项目的走势。太晚了，明天整理些东西出来。:)

26 楼 wwccss 2010-08-29  

引用

个人经验看，Scrum在团员成员能力都还不错的情况下才可能很好的执行scrum流程

如果团队内有好个新人，完整的Scrum流程就不那么好执行了，也没很多合适的新人任务

水平一般的人每天站立会议给你的反馈可能就只有还在开发写代码过程中，只有每周才可能形成一定的成果

LZ的团队主要在技术成长过程中，对敏捷有了一定的裁减

scrum团队成员未必要能力都很好，但有一个懂得scrum流程的scrum master是很重要的。他要负责训练大家，就像教练一样，把大家带出来。

站立会议的反馈，并不是要汇报工作结果。而是团队成员之间互相沟通，更新彼此的信息，还有就是及时发现风险。

25 楼 wwccss 2010-08-29  

引用

我一直不知道，如果出现如下情况，该如何解决：

1。 一个组10个人，能力不平均。其中只有2个人有能力分解任务。

2。 8个任务，没有一个是大家喜欢的。

3。假设任务已经成功分解并分配。但1周之后只有一个人按进度完成。

我对敏捷的体会是，责任以组为单位来分配，从而模糊了具体责任人。一旦出了问题，很难找到具体负责人。
找到责任人并不是说一定要找一个人来背黑锅，而是要在出现问题是能迅速找到合适的人来讨论。

1. 三个臭皮匠，顶个诸葛亮。每个人对任务都有自己的想法，只不过没有表达的机会而已。放手让大家去做，不去做，永远只有那两个人有能力。
2. 为什么任务不是大家喜欢的?我想还是指派的。8个任务，总是可以挑出自己喜欢的出来，即使不是那么喜欢。自己挑选的任务，自己要负责。因为这是你的选择，不是硬性的指派。
3. 一周以后只有一人完成，这种情况在真正的scrum中是不会出现的。因为有每天的站立会议，随时发现风险，解决问题。如果任务分解，只有一人按进度完成。还有一种原因是任务分解过粗。一般来讲，任务分解越细越好。

项目的成功，是团队共同的责任。但任务都是有owner负责的。这没有问题的。项目中的每一个任务都必须有一个作为负责人。也许具体做事的不是他，但由他来协调，组织。

24 楼 xfly_t 2010-08-28  

个人经验看，Scrum在团员成员能力都还不错的情况下才可能很好的执行scrum流程

如果团队内有好个新人，完整的Scrum流程就不那么好执行了，也没很多合适的新人任务

水平一般的人每天站立会议给你的反馈可能就只有还在开发写代码过程中，只有每周才可能形成一定的成果

LZ的团队主要在技术成长过程中，对敏捷有了一定的裁减

23 楼 sunday1207 2010-08-28  

个人认为反馈只是一个方面，关键还在于前期任务的合理分配，以及风险管理，对于存在风险的任务进行重点的跟踪。对于按照代码提交来评估任务，觉得不是很合理，一方面每个阶段的任务不一样，另一方面项目不仅仅是代码。同事需要充分相信团队，每周汇报一次工作就可以了

22 楼 seen 2010-08-28  

wwccss 写道

scrum其实不是理论，更多的是实践。:) 他的实践就只有那个几个：

产品经理维护需求列表。
大家坐在一起，商定本期要做的需求。
然后大家分解任务。不是一个人分解。
然后大家领取各自喜欢的任务。
然后大家去看自己的任务
然后每天早上的站立会议。
最后结束的演示会议和总结会议。就ok了。:)

我一直不知道，如果出现如下情况，该如何解决：

1。 一个组10个人，能力不平均。其中只有2个人有能力分解任务。

2。 8个任务，没有一个是大家喜欢的。

3。假设任务已经成功分解并分配。但1周之后只有一个人按进度完成。

我对敏捷的体会是，责任以组为单位来分配，从而模糊了具体责任人。一旦出了问题，很难找到具体负责人。
找到责任人并不是说一定要找一个人来背黑锅，而是要在出现问题是能迅速找到合适的人来讨论。

21 楼 wwccss 2010-08-28  

scrum其实不是理论，更多的是实践。:) 他的实践就只有那个几个：

产品经理维护需求列表。
大家坐在一起，商定本期要做的需求。
然后大家分解任务。不是一个人分解。
然后大家领取各自喜欢的任务。
然后大家去看自己的任务
然后每天早上的站立会议。
最后结束的演示会议和总结会议。就ok了。:)

20 楼 yuankai 2010-08-28  

工作日志这个东西只不过是管理团队各成员的一种工具，大多数情况下大家填写出来的日志都是为了完成任务一样敷衍了事！
项目经理一个项目做下来 ，那个项目组成员的能力和对工作的态度,偷不偷懒等问题是非常清楚，如果是为了考核去填工作日志意义不大。

19 楼 jnoee 2010-08-28  

daquan198163 写道

那么多开源项目的成功模式在哪儿摆着呢，
人家全世界范围的分布式团队、语言文化差异都搞定了，
有足够的说服力了吧

我们做得更多的是业务系统，是辅助于传统行业提升工作效率的软件，开源项目的情景并不适合。
而且“在哪儿摆着”的东西很多，自己能掌握的却很少。
就我所知，国内的软件管理经验积累得很少，同样的一套理论实施出来的结果却差异很大。有的甚至实施不下去，结果就不了了之了。我们也有一支团队尝试了敏捷，结果也是不尽人意的。
银弹固然好，但还是需要一把好枪和一个好的射手。
当有了一把好枪和一个好的射手，说不定能射出一颗金弹呢？
讨论还是应该就事论事，有理有据有事实有结论，不是吗？

18 楼 jnoee 2010-08-28  

wwccss 写道

我曾经和朋友们聊过一个玩笑。说，传统项目管理中的项目经理，就是一只猴子。手下的员工就是耍猴的。他要总管整个项目的进展，要做计划，要分解任务，要安排甘特图，还要跟踪每个人的进度，小心谨慎，或者强硬推行，哎，项目做完了。大家都很累。猴子也累，看猴子的也累。我之前就当过这样的猴子。红红的屁股被人看，羞死人。

这并不是玩笑，甚至有的项目经理比“猴子”还不堪，手下的员工比“耍猴”的更凄惨。他只做“监工”，而手下的员工就是“奴隶”。最可怕的是这些项目经理还不自知，还自以为干得很好，因为他们根本就不知道自己应该干些什么事情，他们习惯于发号施令和玩权。

我认同你的这些观点，但既然是讨论，实际上大家更多的是希望看到实际的解决办法和可行的操作方式，而不是因为各自管理理念差异的互相攻击。而且说实在的，我更看好遇见问题解决问题这种方法，也更看好这样的管理人员能够切实的提升团队实力。软件行业的理论派太多了，所以看到纯理论上的东西我更多的是带着怀疑的眼光。

17 楼 wwccss 2010-08-28  

引用

或许我孤陋寡闻，但就我所知所见，国内大部分的软件公司连一套完整的项目管理流程都没有，有的软件公司名义上有管理流程但从来没有认真的实施过，更别说对管理流程的总结和改进了。

不是打广告，建议你看下我们开发的项目管理软件-zentao，基于scrum管理方式，完整的涵盖了产品管理、项目管理、测试管理，以及事物管理，组织管理和文档管理等核心功能，为软件研发企业提供了完整的项目管理解决方案。

开源软件，同时提供了完整的扩展机制和api调用机制，可以非常方便的进行扩展和调用。

16 楼 wwccss 2010-08-28  

引用

你的发言表达的是一种偏执的态度，但实际上却不能帮助人解决问题。

引用

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

zwchen兄的很多观点很有迷惑性，只是想让大家知道另外的一种选择，让大家知道真正的敏捷是什么。不要把个人体验式的总结，奉为经典。

引用

所以我对你的发言是否来自于实际的项目运作表示怀疑。
或许你手头真有那么一个理想中的开发团队，你建立这么一个团队花了多长的时间？

当然是来自实际的项目经验。成功的也有，失败的也有。问题的关键不在于这儿，而在于你是否选择去改变？

看大家还在这儿苦苦挣扎，谈论什么项目管理。其实早已经有答案了，只是你不相信而已。

我曾经和朋友们聊过一个玩笑。说，传统项目管理中的项目经理，就是一只猴子。手下的员工就是耍猴的。他要总管整个项目的进展，要做计划，要分解任务，要安排甘特图，还要跟踪每个人的进度，小心谨慎，或者强硬推行，哎，项目做完了。大家都很累。猴子也累，看猴子的也累。我之前就当过这样的猴子。红红的屁股被人看，羞死人。

真正的敏捷团队没有猴子，没有集权，而是团队的自我管理和放权。

放权，是所有改变的开始，是原动力，关键点就在于坐在项目经理位置上面的你，有没有这个觉悟去改变。如果你开始行动，整个团队会跟着发生奇妙的变化！慢慢的，你会运筹帷幄，从容淡定……

15 楼 daquan198163 2010-08-28  

那么多开源项目的成功模式在哪儿摆着呢，
人家全世界范围的分布式团队、语言文化差异都搞定了，
有足够的说服力了吧