转载自http://www.iteye.com/topic/422908
袁光东 原创
怎样提高项目的生产率。保证项目按期交付是每一个软件开发项目经理都须要面对的难题。
关于这方面的研究，在《人月神话》、《人件》等书籍都有非常具体的论述。研究表明，不同程序猿之间的生产率最高区别在40倍以上。尽管笔者没有亲睹这样的例子，可是笔者的开发和管理生涯中所发现的同样技术水平程序猿之间的生产率最大差距可达4倍。这个数据就发生在笔者的一个项目中。这让笔者感到非常的震惊。假设说40倍的生产率差距可能会有技术能力、工作经验、熟悉程度诸多因素的影响。那么，笔者所发现的4倍生产率差距却更让笔者感到不可思议。
案例
程序猿J：四年开发经验
程序猿L：三年开发经验
程序猿Y：五年开发经验
技术能力：Y > J > L
J，L。Y同一时候进入一个项目组，开发时间为30个工作日，即6周，包含需求分析、设计、编码和集成。
当中编码和单元測试时间为10个工作日(2周)。产生的工作绩效为：
| 程序猿 | 规模(代码行) |
| J | 1500 |
| L | 3600 |
| Y | 6000 |
可见。当程序猿的技能达到一定水平后。技能与生产率并不成正比。并非技术水平越高的程序的生产率越高。
一、最后期限
非常多程序猿都会有类似的经历：
1月1日，项目经理说：“小张。在1月5日之前把这项工作做完。具体的需求文档我已经发到你的邮箱中。
”
1月1日。小张对需求文档瞥了几眼，预计2天就能够完毕，嘀咕：“如今才是1月1日嘛。这项任务要1月5日才提交。我还有时间。不用管它。还是先看我的小说吧。”
1月2日，小张继续看他那心爱的小说......
1月3日，小张继续看他那心爱的小说......
1月4日 9:00，小张開始看需求文档。2小时后中断。由于他须要修复系统的一个Bug。
1月4日 18:00，小张正在埋头苦干，由于明天就要提交工作，但是一个代码还没有写呢。
1月4日 23:00。小张完毕大部分工作。下班走人。
1月5日 9:00，项目经理问：“小张。那个功能做完了吧？”小张答道：“就快了，今天提交没有问题。”
1月5日 14:00。小张发现有一部份代码须要重写。
用户的要求是须要一个可配置的功能，而小张却写成了硬代码。
1月5日 17:00。项目经理来到小张面前：“小张，你中午不是说今天提交没有问题吗？怎么如今还没有看你提交代码？”小张委屈地答道：“经理，遇到一点小麻烦。只是相信我。下班之前一定完毕。”
1月5日 18:00。项目经理急匆匆赶到小张的座位旁：“小张。请立即提交代码，不然就来不及了。”小张这时也急了：“你不要催我。
这个功能麻烦大了，没有想象得那么简单。我今天晚上得加班。”项目经理无可奈何地走了。小张加班到凌晨1点。
但程序还是有一些问题。
1月6日，小张仍然在改动程序......
1月7日，小张仍然在改动程序......
1月8日，总算是改动完毕。已经拖了三天，来不及測试，仅仅能匆匆把代码提交。
后来，又经过5次改动。直到1月20日。这个功能总算是彻底完毕。
小张向项目经理请了一周假。由于这两周来差点儿每天晚上都是加班解决这个问题。
很多的程序猿还会有这种经历：
4月1日。项目经理：“小王，这个功能交给你，需求你看了吗？你看须要多长时间完毕？”
小王：“哦，经理。这个功能我刚看过，大约须要1周时间。”
项目经理：“那就是4月5日能够提交啦？”
小王：“是的。经理。这个功能内容非常多，还要实现一个邮件功能，4月5日能提交已经是我的极限了。
”
项目经理：“那就4月5日吧。”
4月2日，小王发现：系统中已经有一个类似的邮件功能，直接使用就能够。
4月2日 18:00，小王已经把功能都完毕了。
4月3日 9:00，小王把功能都測试通过。而且还私下请用户帮他进行測试通过。
4月3日 11:30，项目经理：“小王。那个功能做完了吗？”
小王：“经理。正在做呢。你看。昨天你又叫我改动另外一个Bug。只是。经理你放心吧。4月5日一定能够提交。”(小王已经做完工作。但声称没有做完。)
4月4日，小王专注的看着一本电子书，名字叫《The Deadline》。
4月5日 15:00，小王把代码提交。并向经理发邮件。主题是：XXX功能已经完毕。
4月6日 9:00，项目组开会。项目经理表扬了小王。要求大家向小王学习。
由于这次公布仅仅有小王按时完毕了工作。
简直不可思议，我们的程序猿就是这样工作的。
是的，我也觉得不可思议！但是哪个程序猿敢保证自己没有这么干过呢？这就是所谓的最后期限：人们总是在最后期限才開始工作
二、热衷于加班
在全部的软件项目组中，加班已经成了天经地义的事。甚至有些管理层觉得，假设一个项目组不加班。说明项目组没有尽全力的去做事。我至今不明确这是什么道理，工作是否尽力与加班究竟有何关系？工作的绩效又与加班有何种关系?
在笔者的项目组中，笔者的客户方也曾对笔者要求项目组必须加班，遭到了笔者的拒绝。
在保证每一个阶段在不加班的情况下按期完毕，客户方才勉强允许。事实证明，不加班也是能够把项目做完的，并且能够做得更好。
在我的程序猿生涯中。以前两次长达4个月的封闭开发期。被要求每天从19:00－22:00集体加班。
但实际情况是，每天都可能要在23:00之后才干够下班。由于项目经理没有走。所以其他开发者也仅仅能留下。痛苦的是，我在那段加班时间里除了看技术电子书外，找不到不论什么可做的事情。我相信。当时项目组有太多的人跟我一样。当我每天23:00回到宾馆时，已经全然麻木了。
我无时不想那该死的项目早一天结束。在那段时间里，我最大的收获时进行了大量技术积累。项目结束时，我的加班记录累计长达30人天。
甚至有些程序猿在正常的工作时间里也是不做事的，下班前開始忙碌，加班干活。
想想这种加班又有什么效果呢？
三、工作成熟度与团队成熟度
因此，我一直致力于研究提高个人工作绩效的方法和提高项目组工作绩效的方法。
在长期的学习、摸索、实践中。我发现全心的投入工作，干好4个小时就足以把工作做好。这样的全心投入产生的绩效要比曾经一周所干的还要多。假设每天努力干好8个小时，你会比周围的人产生2倍以上的绩效，当然也会很疲惫。
在管理一个40人规模的团队时，我每天投入只4个小时就足够。为什么会有这么高的工作效率？主要是长期坚持以下的方法:
1.日计划，列出工作清单(列出当天须要做的事情)
2.为任务划优先级(标出当天必须完毕的事情)
3.仅仅做最重要的事情，而不是最紧急的事情
4.绝不迟延。计划当天必须完毕的事情就一定要做完才走。
笔者长期以来在思考。这种方法是否能帮助团队提高工作绩效？是否能让项目组提高生产率？是否能使项目按期交付和提前交付？是否能帮助程序猿在不加班的情况下把项目做好？
在笔者带项目和监控项目的过程中发现，程序猿工作效率不高的原因除了技能因素外。还有几个重要的因素在影响着程序猿的工作绩效：
1.工作无计划：非常多程序猿根本不知道每天要做哪些事情。每天必须做完哪些事情。非常少有程序猿对当天的工作进行计划。
2.工作无重点：非常多程序猿通常按事情发生的先后顺序来做事。有时，有些程序猿忙碌了一天下来却发现当天事实上没有做什么实用的事情。
3.工作无目的：程序猿不知道当天要把事情做到什么程度，全然是凭心情做事。凭良心做事。
事情没有做完。别人下班自己也跟着下班，觉得反正明天还有时间。还没有到最后期限。
4.工作不到位：工作起来总是认为几乎相同即可。把代码写完和功能可以执行当作两回事情。工作到位就是一次就把工作做好。达到可交付。
5.工作无积极性：被动式工作。就算工作做完也不提交，一定要等到最后期限才提交。
假设比承诺时间提前提交工作，立即就会带来新的工作，多干和少干一个样。谁愿意多干呢？
我们可以提出一个概念叫做“工作成熟度”。
工作成熟度高的程序猿一般会有计划性、工作有重点、有目的性、工作做到位。而成熟度低的程序猿一般是无计划的，工作不分轻重。非常easy被突发事件打断当前工作，工作要通过多次改动才可以完毕。
所以。我发现，工作成熟度对程序猿生产率造成最直接的影响。
笔者在监控项目的过程中也发现造成项目组效率低下、进度落后的一些因素：
1.项目经理不了解项目当日状态。
是的，有些项目经理根本不知道今天每一个程序猿会干些什么？该干些什么？
2.项目经理不了解项目实情。没错。项目经理根本就不知道每一个程序猿当天干了多少活，干到什么程度，还要干多久？也就不知道项目到了什么程序，还有多少工作量要做？
3.项目经理不知道每一个人是否可以按期交货。项目经理仅仅能是望天收成，期望程序猿凭良心、凭职业道德做事。可是，至于程序是否可以按期交货，仅仅有鬼才知道。
4.项目经理不知道工作的重点是什么？哪些工作是本阶段必需要完毕的？哪些是能够拖后的？
5.不良沟通。项目组的沟通不良，产生大量反复代码。甚至会有两个程序同一时候开发一个功能，可是彼此间却不知道。
6.信息不能共享。程序猿彼此之间不知道别人干得怎么样？也不知道项目总体情况究竟怎么样？这也难为程序猿了，由于项目经理也不知道。
糟糕的项目都存在着一个黑洞。
一般会是在编码阶段，整个项目组就像在黑洞中穿行一样，谁也看不清对方，不知道黑洞的尽头在哪里，谁也不知道走过多少地方，还要多久才干走出黑洞。总之，项目经理仅仅能拼命的喊：“快点。快点，兄弟们，我们的时间不多了。”所以，项目经理仅仅能让全部的人每天加班，星期六不能歇息，到最后。星期天也不能歇息。
这就是我们能够提出的还有一个概念——“团队成熟度”。
“噢，伙计，我已经听烦了。
好像是有那么回事！但是又能怎么样呢？全部的项目不都是这样过来的吗？”
四、日计划做什么？
程序猿的工作成熟度直接影响了程序猿的生产率。项目的团队成熟度直接影响了项目的生产率。假设我们可以提高程序猿工作成熟度和团队成熟度，就一定可以提高项目的生产率。
而程序猿工作成熟度和项目团队成熟度的共同核心点就是计划。在笔者的研究和实践过程中。能够通过在项目中实施日计划来提高程序猿的工作成熟度和项目的团队成熟度，从而提高程序猿的生产率和项目的生产率。
实施日计划的流程：
1.每天8:30-8:35。项目组召开晨会。由项目经理列出每一个开发者的工作清单，并对每一个工作任务标注优先级别，设定任务完毕的标准，指明当日必需要完毕的任务，并得到责任人的承诺。
2.每天下班前20分钟，由项目经理依次检查开发者的工作。评定工作是否完毕。
假设有开发者未能完毕任务，一起分析任务未能完毕的原因。
然后召开一个简单的会议。介绍当天工作的完毕情况及当前阶段的项目状态，未完毕任务的开发者须要加班完毕。
每天早晨的会议我们称之为晨会，下午的会议称之为夕会。
日计划的实施环节：设定目标，制定计划，检查。反馈。
日计划的特点：
1．开发者每天在晨会承诺完毕的任务必须当天完毕。提倡日清日结。
2．提交可交付的成果。（事先制定任务完毕的标准，并由项目经理进行检查，评定任务是否完毕。）
3．做最重要的事情
4．保证把工作做完
五、我们是怎么实施日计划的？
日计划看起来很easy。以下我们将对日计划的实践进行讨论。
1.实施日计划对项目有什么作用？
· 实施日计划。使项目有良好的沟通机制。
每一个开发者都很清楚项目的当前情况：项目已经完毕了多少？还有多少工作没有完毕？
· 日计划提倡可交付的成果，也就是每天完毕的工作都一定是可交付的。
· 日计划提倡仅仅做最重要的事情，使项目抓住了重点。
· 项目经理通过实施日计划，很清楚每一个开发者每天须要完毕哪些任务，每天必须完毕哪些任务，以及每一个人的完毕情况怎么样？项目经理充分地掌握了项目的情况。能够及时调整计划，应对各种变化。
· 日计划实现了项目的良好沟通，每项任务都由开发者和项目经理达成一致。
· 日计划通过晨会和夕会实现了项目组的信息共享。
2.实施日计划对程序猿的作用
· 日计划列出了程序猿每天要做的任务清单，而且对任务确定优先级。
· 对程序猿的工作指明方向，而且要求程序猿优先做最重要的任务，使程序猿抓住了工作重点。
· 日计划要求提交可交付的成果。要求程序猿把工作一步要做到位，养成良好的习惯。
· 日计划提高了程序猿的工作绩效。程序猿能够回到正常的工作时间。降低无谓的加班。
· 程序猿比曾经完毕很多其它的工作而获得奖励。
3.在实施日计划时，与传统项目管理的工作分配有什么不同？怎样进行工作分配？
传统项目管理的工作分配中，工作项的粒度比較粗。每个工作项通常指一个功能。
一般是把一个功能分给某程序猿。甚至把一个模块分派给某个程序猿。
工作项的工时以周为单位。一般是一周或者两周。
传统项目管理任务分配表| 模块 | 功能 | 当前状态 | 计划開始 | 计划结束 | 实际開始 | 实际结束 | 责任人 |
| 订单管理 | 订单信息查询 | 已開始 | 2009-3-1 | 2009-3-7 | 2009-3-1 | L | |
| 新增订单 | 已開始 | 2009-3-1 | 2009-3-7 | 2009-3-1 | L | ||
| 订单管理 | 改动订单 | 未開始 | 2009-3-1 | 2009-3-7 | L | ||
| 删除订单 | 未開始 | 2009-3-1 | 2009-3-7 | L |
实施日计划的工作分配中，“工作项”的粒度更小。假设依照XP和Scrum的说法，功能就是指一个“故事”，完毕“功能”的步骤或事件叫“任务”。
传统项目管理的任务分配是以“故事”为最小粒度。
日计划的任务分配是以“任务”为最小粒度。“任务”是指完毕某一个“功能”的步骤或事件。每一个人当天的任务工时总合为1人天。
故事和任务的差别：
|
故事
|
任务
|
|
订单信息查询
|
DAO编码
|
|
DAO单元測试
|
|
|
业务层编码
|
|
|
JSP表示层编码
|
|
|
集成測试
|
要实现订单信息查询就由右边的那些任务组成。
開始，我不知道如何来描写叙述一个“功能”和实现一个功能细化的“任务”。后来，当我看到Scrum的书籍后，看到Sprint和任务板时，才知道自己的实践与Scrum的某些实践竟有如此相似之处。我困惑非常久。想不到用什么词来表示一个“功能”和实现一个功能所须要的“步骤”。
Scrum使用“故事”和“任务”来定义它们，我觉得非常的准确到位。
可是日计划的工作分配与Scrum的工作分配是不同的。实施日计划是由项目经理主导的。而Scrum强调由程序猿主导。
至于这两种方式，哪一种更好。我认为能够结合详细的情况进行不同的实践。
假设是程序猿成熟度比較高的项目，能够由程序猿来主导。
程序猿成熟度较低和工期非常紧的项目，能够由项目经理来主导。总之，这都须要程序猿和项目经理达成一致。程序猿须要向项目经理承诺。
Scrum会对每一个任务进行事先估算，而日计划分配工作任务前才会进行估算。而且仅仅为每一个人分配工作量为1人天的任务总和。
日计划例子：2009-3-22程序猿L工作计划| 开发者 | 今日计划工作及完毕情况 | ||||||||
| 序号 | 工作任务 | 优先级 | 完毕标准 | 是否完毕 | 完毕百分比 | 完毕情况 | 未完毕原因 | 检查人 | |
| L | 1 | 订单管理模块DAO实现 | 50 | 单元測试通过 | |||||
| 2 | 与用户确认页面原型 | 10 | 用户确认邮件 |
程序猿L任务1的优先级为50，任务2的优先级为10。这并不表示两个任务的重要程度相差40，而是表示L当天应该先做任务1，再做任务2。
笔者觉得这样的日计划更加灵活。由于项目经理能够灵活的设置任务。
Scrum的任务都是根据故事。日计划甚至能够把与开发根本不相干的事情包含进来。
当天要完毕哪些任务是由项目经理先计划的，可是程序猿能够提出不同的意见。两方达成一致。
而且任务是能够量化和检查的。因此，事先还要设置完毕标准。一旦程序猿与项目经理达成一致。就相当于程序猿向项目经理承诺，今天能够完毕这些任务。
对于成熟度比較高的程序猿，全然能够由程序猿先提出计划。然后。由项目经理进行评估和检查。
两方达成一致后，就把任务放入日计划的工作任务表中。
4.为什么要检查？怎么进行检查？
假设没有检查。计划就是无效的。
日计划强调提交可交付的成果。尽管事先制定了标准，可是程序猿和项目经理可能会对可交付成果的理解不同。项目经理假设要清楚地了解到项目状况就必需要亲自进行检查。
怎样进行检查？项目经理一定要在现场工作，最好的办法就是让他演示给你看。
对于不能演示的任务就进行抽查。
由于事先已经制定完毕标准，大家仅仅须要按规矩办事就可以。
而且一定要填写完毕情况，以便后期的跟踪。
5.假设程序猿不能完毕日计划怎么办？怎样才可以使程序猿可以完毕日计划？
程序猿不能完毕日计划时。也就是进度出现了偏差。项目经理一定要与程序猿一起分析偏差的原因。并记录下来。进度发生偏差最有可能的两个原因：计划不合理和计划运行不力。
计划不合理包含：对任务的难度和工作量估算失误，对程序猿能力的估算失误。或者程序猿的工作方法存在问题。须要支持和协助等。
假设是对任务估算发生失误。就须要又一次进行估算。这正是日计划和检查带来的优点。项目经理须要又一次调整计划。
假设是对程序猿能力预计失误，项目经理也须要又一次进行调整。如换人，或延长时间。
假设是程序猿工作方法存在问题。就一定要进行指导，或者安排其他人员进行协助。
假设是计划运行不力，也要找到最核心的原因是什么？是意愿不高？中间去做其他事情？工作习惯如此？都须要找到核心原因，方可对症下药。
在我的团队中，绩效考核的几个核心指标：工作效率*工作效果*工作量
不能完毕日计划。会直接影响到月底的绩效和奖金。
怎样才可以使程序猿完毕日计划？首先是计划一定要合理，要考虑到个体差异,分配任务在其能力范围之内。
日计划一定要获得当事人的承诺。
检查和跟踪一定要到位。要与考核挂勾。做到会得到什么？做不到会有什么后果？
六、没有银弹
是的，没有银弹。没有不论什么一种方法能够保证项目一定能够成功。日计划也一样。目标、计划、运行、控制构成管理的核心。所谓工作成熟度和团队成熟度事实上都能够归纳为“运行力”。日计划仅仅是一种管理实践。在不同的环境可能会有不同的实践方法，并非一层不变的。