软件项目管理实践之日计划

软件项目管理实践之日计划

 袁光东 原创

如何提高项目的生产率，保证项目按期交付是每个软件开发项目经理都需要面对的难题。关于这方面的研究，在《人月神话》、《人件》等书籍都有很详细的论述。研究表明，不同程序员之间的生产率最高差别在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.工作无积极性：被动式工作，就算工作做完也不提交，一定要等到最后期限才提交。如果比承诺时间提前提交工作，马上就会带来新的工作，多干和少干一个样，谁愿意多干呢？

    我们可以提出一个概念叫做“工作成熟度”。工作成熟度高的程序员通常会有计划性、工作有重点、有目的性、工作做到位。而成熟度低的程序员通常是无计划的，工作不分轻重，很容易被突发事件打断当前工作，工作要通过多次修改才能够完成。所以，我发现，工作成熟度对程序员生产率造成最直接的影响。

    笔者在监控项目的过程中也发现造成项目组效率低下、进度落后的一些因素：

    1.项目经理不了解项目当日状态。是的，有些项目经理根本不知道今天每个程序员会干些什么？该干些什么？

    2.项目经理不了解项目实情。没错，项目经理根本就不知道每个程序员当天干了多少活，干到什么程度，还要干多久？也就不知道项目到了什么程序，还有多少工作量要做？

    3.项目经理不知道每个人是否能够按期交货。项目经理只能是望天收成，期望程序员凭良心、凭职业道德做事。但是，至于程序是否能够按期交货，只有鬼才知道。

    4.项目经理不知道工作的重点是什么？哪些工作是本阶段必须要完成的？哪些是可以拖后的？

    5.不良沟通。项目组的沟通不良，产生大量重复代码。甚至会有两个程序同时开发一个功能，但是彼此间却不知道。

    6.信息不能共享。程序员彼此之间不知道别人干得怎么样？也不知道项目整体情况到底怎么样？这也难为程序员了，因为项目经理也不知道。

    糟糕的项目都存在着一个黑洞。通常会是在编码阶段，整个项目组就像在黑洞中穿行一样，谁也看不清对方，不知道黑洞的尽头在哪里，谁也不知道走过多少地方，还要多久才能走出黑洞。总之，项目经理只能拼命的喊：“快点，快点，兄弟们，我们的时间不多了。”所以，项目经理只能让所有的人每天加班，星期六不能休息，到最后，星期天也不能休息。

    这就是我们可以提出的另一个概念——“团队成熟度”。

    “噢，伙计，我已经听烦了。好像是有那么回事！可是又能怎么样呢？所有的项目不都是这样过来的吗？”

四、日计划做什么？

    程序员的工作成熟度直接影响了程序员的生产率；项目的团队成熟度直接影响了项目的生产率。如果我们能够提高程序员工作成熟度和团队成熟度，就一定可以提高项目的生产率。

    而程序员工作成熟度和项目团队成熟度的共同核心点就是计划。在笔者的研究和实践过程中，可以通过在项目中实施日计划来提高程序员的工作成熟度和项目的团队成熟度，从而提高程序员的生产率和项目的生产率。

    实施日计划的流程：

    1.每天8:30-8:35，项目组召开晨会。由项目经理列出每个开发人员的工作清单，并对每个工作任务标注优先级别，设定任务完成的标准，指明当日必须要完成的任务，并得到责任人的承诺。

    2.每天下班前20分钟，由项目经理依次检查开发人员的工作。评定工作是否完成。如果有开发人员未能完成任务，一起分析任务未能完成的原因。然后召开一个简单的会议，介绍当天工作的完成情况及当前阶段的项目状态，未完成任务的开发人员需要加班完成。

    每天早晨的会议我们称之为晨会，下午的会议称之为夕会。

    日计划的实施环节：设定目标，制定计划，检查，反馈。

    日计划的特点：

    1．开发人员每天在晨会承诺完成的任务必须当天完成，提倡日清日结。

    2．提交可交付的成果。（事先制定任务完成的标准，并由项目经理进行检查，评定任务是否完成。）

    3．做最重要的事情

    4．保证把工作做完

五、我们是怎么实施日计划的？

    日计划看起来非常简单，下面我们将对日计划的实践进行讨论。

    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.如果程序员不能完成日计划怎么办？如何才能够使程序员能够完成日计划？

    程序员不能完成日计划时，也就是进度出现了偏差。项目经理一定要与程序员一起分析偏差的原因，并记录下来。进度发生偏差最有可能的两个原因：计划不合理和计划执行不力。

    计划不合理包括：对任务的难度和工作量估算失误，对程序员能力的估算失误，或者程序员的工作方法存在问题，需要支持和协助等。

    如果是对任务估算发生失误，就需要重新进行估算。这正是日计划和检查带来的好处。项目经理需要重新调整计划。

    如果是对程序员能力估计失误，项目经理也需要重新进行调整，如换人，或延长时间。

    如果是程序员工作方法存在问题，就一定要进行指导，或者安排其它人员进行协助。

    如果是计划执行不力，也要找到最核心的原因是什么？是意愿不高？中间去做其它事情？工作习惯如此？都需要找到核心原因，方可对症下药。

    在我的团队中，绩效考核的几个核心指标：工作效率*工作效果*工作量

    不能完成日计划，会直接影响到月底的绩效和奖金。

    如何才能够使程序员完成日计划？首先是计划一定要合理，要考虑到个体差异,分配任务在其能力范围之内。日计划一定要获得当事人的承诺。检查和跟踪一定要到位。要与考核挂勾，做到会得到什么？做不到会有什么后果？

    六、没有银弹

    是的，没有银弹。没有任何一种方法可以保证项目一定能够成功。日计划也一样。目标、计划、执行、控制构成管理的核心。所谓工作成熟度和团队成熟度其实都可以归纳为“执行力”。日计划只是一种管理实践，在不同的环境可能会有不同的实践方法，并不是一层不变的。

评论

55 楼 雁行 2009-07-30  

只能是以任务为计划项，定时跟踪任务执行情况。
比如一个3天的开发模块，安排下去后，你不可能要求张三今天完成33%，明天完成33%，后天完成34%。
可以在任务下派时候，通过合理分析计算，得到一个正常的用时参考。
也许开头用时长，后面用时短。
所以，每天去考核完成进度，个人以为有些矫枉过正了。

另外，这些都是要投入相当的管理成本的。
单单是项目经理肯定不成，需要一干人等配合检查，来确定任务的进展是否正常。

54 楼 issppt 2009-07-30  

klyuan 写道

issppt 写道

管理成本过高，这个问题比较明显。在有些一个管理人员成本比4，5个技术人员还高的地方，加大管理人员投入的性价比也是需要参考的一个方面。毕竟项目是以收益算的，并不是项目越成功越完美，项目收益就越大。
日计划依赖于整体项目计划，需要严格的项目整体计划，项目日计划才能比较明确到细节，这样也有两个问题，第一，如果项目需求变更频繁，那么在更大程度上会更加依赖于管理人员的能力，需要更加灵活的分解任务，变更项目计划制定日计划，管理成本进一步拉大。第二，客户的信任度问题，客户给定的时间内极大部分看不到项目成果，只是一大堆的计划，文档，在项目需求变更时可能需要等待的时间更长，如果项目失败，对客户信任的打击会更大。
然后日计划跟流水线同样需要预防的副作用，对项目整体的认识度差，可能出现的情况就是项目开发人员对项目的认识就只是一堆task而已，每天只需要等待发来一本任务，然后做完完事，很多日本的外包公司都是这样，需要谨慎预防。

如果一过连计划都不想做的项目而取得成功几乎是碰运气的。
如果一个项目连整体计划都没有，阶段计划又没有细化。那这样的项目只是望天收成。
什么叫管理成本过高？
计划就是叫做管理成本过高？
当一个项目能够比普通团队提高一倍的生产率，也就是说普通团队要6个月。而有良好管理的团队只需要3个月。这是管理成本过高还是过低呢？
可能大家还是习惯于想到什么就做什么吧，缺乏规划。

首先，项目不可能没有计划，这个不用说了。但是日计划和计划还是有区别的。
日计划并不简单的像你说的只是项目计划的计划，个人感觉他是在理想状况下对项目计划的极限细化。
管理成本过高首先是对于项目经理的管理成本。
以一个10人的项目为例吧。
从早间例会开始吧，分配当日任务，那么这个任务是什么时候由管理者确定的？那么我回溯到前一天。
前天下班前提前20分钟进行检查例会，那么只有当你检查完工作情况时，才能给出下一步的计划。
假设提前对工作做了计划，下午例会检查时发现任务因为各种情况没有完成，需要调整。
好，再假设你提前对工作做出的计划已经包含了各种各样的异常状况出现的应对办法了，那么这样一份计划的时间是多少？作为管理者你需要投入多少时间在一个每日计划上。
好，继续向下假设你可以很快的做出一份十分详尽的计划，这个计划包含了各种各样异常状况的解决办法，很详尽，那么这样一个管理者每月的工资会是多少，吧这样一个管理者放在一个项目中的成本又是多少？这样一个项目又能赚多少？这个是被习惯性忽略的一个问题。很多完美的项目不能按完美轨迹运行就是这个原因。
好，在继续，既然这个管理者成本很好，那么我们让多管理几个项目吧，那样平均成本不就低了，当一个管理者同时带几个项目的时候，他能像带一个项目那样那么了解需求那么容易的给每个项目做日计划吗？恐怕很难。
以上所以的假设还都是在项目计划可以确定的情况下的，但是事实呢，很多项目你接受的时候你就会发现，项目的需求根本确定不下来，项目的计划根本是随时在变的，这个是客观存在的。那么日计划的复杂程度会成几何级上升。

的确，日计划是一个很好的提高效率的方案，但是很多时候，我们需要考虑这个计划执行的环境，毕竟只有最适合的方案，没有最好的方案。这个在pmp中有两个元素是一只被提到的，企业环境因素和企业的资产。
所以对于日计划，个人的态度是，在特定条件下的项目，实施日计划是可以极大提高项目效率的。不过对于成本考虑比较重的项目，例如外包项目来说，还是感觉细化的功能点任务计划比较好点。

53 楼 fly_ever 2009-07-29  

klyuan 写道

fly_ever 写道

klyuan 写道

fly_ever 写道

我觉得根据当天的工作完成情况，计划第二天的工作任务，并分配给适合的开发人员，是一个比较耗时的过程。
这个工作是由项目经理来完成的吗？是不是项目经理就需要加班才能完成这些事情呢？

那你们的情况是怎么样呢？

我们目前不是这种开发方式，因此无从谈起。
我只是从你说的开发方式，感觉到项目经理(或者说是故事划分，分配的角色)的任务比较重，不知道你们是不是这样的？
或者是不是项目前期开发人员也参与故事划分？

你们目前是什么方式？效果如何？亮点在哪里？能否一起探讨？

我们是传统的开发方式，因此想着寻找一个好点的开发方式。
我觉得在项目的一个迭代开始的时候，项目经理应该召集相关人员把这次迭代的所有用户故事写好，并且对每个用户故事进行工作量评估。因此在开发过程中，项目经理只需要根据每天的完成情况，对用户故事进行调整，然后分配。这样的话，项目经理的工作量还是小一点。

52 楼 tuti 2009-07-29  

klyuan 写道

tuti 写道

klyuan 写道

跟考核挂勾。
1、如果不是因为任务分配问题导致的不能完成，则要求加班完成。
2、每天，每个人的工作完成情况记录在案（工作量，效率，质量），月底考核以此为据。具体的制度我就不说了。

工作量，效率，质量 都是以什么指标来度量呢？

每个团队或每个公司的衡量标准都不一样。
最好是结合实际的情况。
工作量和效率的度量就不需要说了吧。

质量是比较难以衡量的，在我的项目组是提倡可交付成果。根据返工的情况来进行量化。
当然也可以根据缺陷率等量化，通过缺陷率最麻烦的是只有到QC或测试阶段后才能够确定质量。
对于不同的任务可能会有不同的质量度量标准。
比如设计文档类的，一般我会要求由设计者当众讲评来取代评委评审。
当众讲评的效果要比评委评审要好。
可以根据需要修改点的多少和修改的级别来衡量任务的质量。
传统的做法是以文档的页数等来进行度量。
但是个人的经验是，召开评审会议，由设计者当众向项目组讲解，任何人都可以提出疑问。
这样的效果明显要优于由专家单独进行评审然后给出评审意见的方式。

那按照和月底考核的制度， 修改点多级别大就得分低，就可能被扣钱？
那如果当事人说，他的设计模块难度大，修改点自然比较多，别人设计模块难度低，修改点自然比较少。
那这个制度又怎么执行呢？

至于工作量和效率的度量标准问题。
你们能以什么来测算呢？代码行数，User Story的个数，Task的个数，功能点数？
方便的话，望能解答的一下。

51 楼 klyuan 2009-07-29  

fly_ever 写道

klyuan 写道

fly_ever 写道

我觉得根据当天的工作完成情况，计划第二天的工作任务，并分配给适合的开发人员，是一个比较耗时的过程。
这个工作是由项目经理来完成的吗？是不是项目经理就需要加班才能完成这些事情呢？

那你们的情况是怎么样呢？

我们目前不是这种开发方式，因此无从谈起。
我只是从你说的开发方式，感觉到项目经理(或者说是故事划分，分配的角色)的任务比较重，不知道你们是不是这样的？
或者是不是项目前期开发人员也参与故事划分？

你们目前是什么方式？效果如何？亮点在哪里？能否一起探讨？

50 楼 klyuan 2009-07-29  

tuti 写道

klyuan 写道

跟考核挂勾。
1、如果不是因为任务分配问题导致的不能完成，则要求加班完成。
2、每天，每个人的工作完成情况记录在案（工作量，效率，质量），月底考核以此为据。具体的制度我就不说了。

工作量，效率，质量 都是以什么指标来度量呢？

每个团队或每个公司的衡量标准都不一样。
最好是结合实际的情况。
工作量和效率的度量就不需要说了吧。

质量是比较难以衡量的，在我的项目组是提倡可交付成果。根据返工的情况来进行量化。
当然也可以根据缺陷率等量化，通过缺陷率最麻烦的是只有到QC或测试阶段后才能够确定质量。
对于不同的任务可能会有不同的质量度量标准。
比如设计文档类的，一般我会要求由设计者当众讲评来取代评委评审。
当众讲评的效果要比评委评审要好。
可以根据需要修改点的多少和修改的级别来衡量任务的质量。
传统的做法是以文档的页数等来进行度量。
但是个人的经验是，召开评审会议，由设计者当众向项目组讲解，任何人都可以提出疑问。
这样的效果明显要优于由专家单独进行评审然后给出评审意见的方式。

49 楼 fly_ever 2009-07-29  

klyuan 写道

fly_ever 写道

我觉得根据当天的工作完成情况，计划第二天的工作任务，并分配给适合的开发人员，是一个比较耗时的过程。
这个工作是由项目经理来完成的吗？是不是项目经理就需要加班才能完成这些事情呢？

那你们的情况是怎么样呢？

我们目前不是这种开发方式，因此无从谈起。
我只是从你说的开发方式，感觉到项目经理(或者说是故事划分，分配的角色)的任务比较重，不知道你们是不是这样的？
或者是不是项目前期开发人员也参与故事划分？

48 楼 lovejuan1314 2009-07-29  

记得以前的公司,曾经实施过一种工单制,项目经理把每项任务量化成一张张的工单.在填写工单前,会和开发人员进行详细的沟通,以确认工单派发的合理.然后签字画押...

每张工单的完成情况会由技术总监派发给测试组进行考核,然后综合评定.

每月工资 =  基本工资+(实际完成工单数*日工资*老总定的一个百分比的基数) 

(该公式在后来本公司的OA中进行了更详细的算法,也会根据员工最近的表现以及工作态度等等指标进行综合评定)

想实现多劳多得,而且如果能在10-15天时间完成本月工作量,你可以选择继续完成工单多拿钱,或者选择休假.

PS:该制度最后由于大量人员因为工资拖欠的问题的流失而最终流产.. 

感悟:

一个好的制度需要有一个良好的环境和boss的全力支持!

47 楼 tuti 2009-07-29  

klyuan 写道

跟考核挂勾。
1、如果不是因为任务分配问题导致的不能完成，则要求加班完成。
2、每天，每个人的工作完成情况记录在案（工作量，效率，质量），月底考核以此为据。具体的制度我就不说了。

工作量，效率，质量 都是以什么指标来度量呢？

46 楼 klyuan 2009-07-28  

tuti 写道

klyuan 写道

三、放纵
  我们一定要相信个人差异。有些人能力强些，有些人能力差些。有些人做事快些，有些人做事慢些。
每个人的生产率并不相同。
  在项目A中，程序员Y做事比较慢，习惯了慢速度。而且别人不能打扰他。一旦受到打扰，当天的工作很难完成。
项目经理J向我反映说程序员Y总是不能完成日计划的任务。
  我：“任务是否过重？”
  项目经理J：“不是,大部份人都能完成”
  我：“任务难度大，相关技术Y没有掌握？”
  项目经理J：“不是，技术没有难度”
  我：“原因是什么？”
  项目经理J：“主要是程序员Y不能受到打扰，如果遇到突发事件或别人打扰，任务就不能完成？”
  我：“你是怎么处理的？”
  项目经理J：“ 我也没有办法，他还是很努力的。”

  这个案例没说完啊，后来怎么处理的，效果如何？

klyuan 写道

这才是真正的执行力差，所以日计划是要与考核挂勾的。如果做完和不做完一个样，那大家都选择不做完好了。
所以项目组一定要有制度，制度不是用来压人的。但是是一个底线，任何人都不可以越过底线。否则就绝不手软

能否说具体是什么样的制度？实施效果如何？

跟考核挂勾。
1、如果不是因为任务分配问题导致的不能完成，则要求加班完成。
2、每天，每个人的工作完成情况记录在案（工作量，效率，质量），月底考核以此为据。具体的制度我就不说了。

45 楼 tuti 2009-07-28  

klyuan 写道

三、放纵
  我们一定要相信个人差异。有些人能力强些，有些人能力差些。有些人做事快些，有些人做事慢些。
每个人的生产率并不相同。
  在项目A中，程序员Y做事比较慢，习惯了慢速度。而且别人不能打扰他。一旦受到打扰，当天的工作很难完成。
项目经理J向我反映说程序员Y总是不能完成日计划的任务。
  我：“任务是否过重？”
  项目经理J：“不是,大部份人都能完成”
  我：“任务难度大，相关技术Y没有掌握？”
  项目经理J：“不是，技术没有难度”
  我：“原因是什么？”
  项目经理J：“主要是程序员Y不能受到打扰，如果遇到突发事件或别人打扰，任务就不能完成？”
  我：“你是怎么处理的？”
  项目经理J：“ 我也没有办法，他还是很努力的。”

  这个案例没说完啊，后来怎么处理的，效果如何？

klyuan 写道

这才是真正的执行力差，所以日计划是要与考核挂勾的。如果做完和不做完一个样，那大家都选择不做完好了。
所以项目组一定要有制度，制度不是用来压人的。但是是一个底线，任何人都不可以越过底线。否则就绝不手软

能否说具体是什么样的制度？实施效果如何？

44 楼 klyuan 2009-07-28  

fly_ever 写道

我觉得根据当天的工作完成情况，计划第二天的工作任务，并分配给适合的开发人员，是一个比较耗时的过程。
这个工作是由项目经理来完成的吗？是不是项目经理就需要加班才能完成这些事情呢？

那你们的情况是怎么样呢？

43 楼 fly_ever 2009-07-28  

我觉得根据当天的工作完成情况，计划第二天的工作任务，并分配给适合的开发人员，是一个比较耗时的过程。
这个工作是由项目经理来完成的吗？是不是项目经理就需要加班才能完成这些事情呢？

42 楼 klyuan 2009-07-28  

lovejuan1314 写道

tuti 写道

lovejuan1314 写道

感谢楼主的原创以及分享这么宝贵的经验. 我们以前也执行过类似楼主的日计划方法,不知道什么地方出问题了,日计划模式趋于了形式化. 看完楼主的文章,我想是执行力和任务的追踪程度上出问题了...

动不动就说什么执行力，多找找靠谱的原因

恩,tuti 所言即是. 我为止付出了整整一年多的时间在反思这些东西.其实我所说的是,一个项目经理的执行力. (作为项目成员大家都想能圆满顺利的完成,尤其是在项目工期比较紧张的情况下. )

正如楼主所说,

klyuan 写道

执行力。其实项目的执行力与项目经理有非常大的关系。项目经理需要识别风险，还要在把任务分配给程序员时要有预见性。在分配之前就要知道他会有什么问题。把任务分配给最佳人选。预见出现的问题和困难。并马上给予支持。但是很多PM做不到这一点。

从任务分配以及项目进度的控制上,如果项目经理的执行力不够,或者工作重点放错了位置,这无疑是致命的.这也是为什么有的时候楼主亲自实施这个计划的时候,效果就显而易见,而一旦换人就恢复原样的原因.

而我们当时日计划方案之所以会趋于形式化,其实当时情况特别复杂,但,当时的我远没有深刻体会到楼主写这篇文章的深度.认知度的不够就会导致执行力的偏差.而且当时根本没有从全局去考虑问题,只是习惯性的从技术思维来看待管理.所以当时的晨会和夕会成了大家交流出现的bug和技术难题上了(也确实当时在工期紧的情况冒险使用了新技术,这又验证着楼主所谓的项目经理需要识别风险的道理). 从而根本没有从整体来追踪和控制项目的进度. 虽然最终项目还是完成了,但,那次失败的惨烈让我如今仍不寒而栗!

首先谢谢你参与此贴讨论。

关于日计划流于形势，笔者也深有体会。主要是在我监控的项目中出现。
我们可以分析日计划流于形势的原因（以我本人遇到的情况来看，当然希望大家提出更多的案例）：
1.每天分配的任务都不能完成，使日计划无效
  也就是项目经理每天晨会分配的任务，在下午检查时，发现很少有程序员能够完成当日计划的工作。
  这种情况一般发现在新组件的项目组。项目经理对程序员的能力还没有完全了解。
  我们一定要相信“个体差异”。所以项目经理需要充分的了解每个程序员的能力，特点。分配给他最合适的工作。
  其次就是在分配任务之前，要与程序员讨论。提供思路。也就是对程序员的指导和帮助。但并不是我们帮他去做。
  这就是一个项目经理的预见性和教练能力。
  当分配了一个任务给程序员甲时，我们要充分的识别出这个任务程序员甲是否能够完成，他会遇到什么困难。

  在我监控的一个项目B，项目经理X要求程序员T写一份方案。正好那天我在现场。
  项目经理X：“程序员T来完成这个方案吧？你看要多长时间”
  程序员T：“大约需要3天时间吧!”
  我：“你需要3天时间的理由是什么？”(因为我了解到程序员T只有一年工作经验，属于初级程序员)
  程序员T：“因为我对该方案的逻辑还不清楚，很多东西得请教别人。”
  我：“3天你能保证做完吗？”
  程序员T：“不能，我尽力”
  我：“你写这个方案的最大难点是什么？”
  程序员T：“只有一部份业务逻辑我是清楚，但是另外两部份业务逻辑其它同事做的，我不清楚。需要有人支持我”
  我：“项目经理X，项目组有谁对这些业务逻辑是最清楚的？”
  项目经理X：“程序员G最清楚，而且他已经有一些成型的想法”
  我：“项目经理X，你清不清楚所有的逻辑？”
  项目经理X：“清楚”
  我：“OK，去把程序员G叫过来，再搬一块白板过来！相关的人员也过来，我们一起来讨论整个方案的逻辑”
  .........大家花了20分钟讨论，把方案定了下来。
  我：“程序员T，编写这个方案还需要多少时间？”
  程序员T：“依这样看，一天吧”
  我：“需要一天的理由是什么？”
  程序员T：“这个嘛。。。。。，以前没有写过”
  我：“方案已经定了，现在我们把内容定一下，把模板找来。”
  我：“现在这个方案还需要多少时间？”
  程序员T：“半天吧”
  我：“OK，给你一天时间。因为还有返工的内部评审,在明天中午下班前提交给项目经理X，如果需要修改就在下午完成”
程序员T，项目经理X：“OK”
这是一个真实的场景。
  项目经理X分配任务时犯了一些错误。
  首先人选不适合，但是他当时也没有办法。结合项目当时的实际情况，一定要把项目精干力量都放到最重要的事情上去。
  他把方案编写这个任务给了一个没有相关经验的初级程序员。又没有识别风险。程序员在接受这个任务时承诺的时间是自己瞎猜的。自己根本就没有底。项目经理在分配任务之前根本就没有去做相关的分析。
如果我们没有花20分钟去帮程序员T做分析，把方案的草稿确定下来。程序员T承诺的时间根本就是一个不可靠的时间。
如果这样的事情出现过多，日计划也就失去了作用。因为他总是不能完成嘛。

二、事务性的任务没有列日计划。
 
在日计划中，项目经理X给程序员T，C，D和自己分配了当天的开发任务。
但是我在抽查中，发现所有的程序员都没有做当天的任务。
项目经理X突然接到客户方的要求，要为项目上线做一些准备工作。
程序员T说昨天还有一些工作没有处理完，要继续处理。
程序员C在修改昨天的BUG
程序员D自己在写一个DEMO程序（后期会要用到这个技术）

这是一个什么情况？
首先，当日的待处理任务清单里面有遗漏。
可能项目经理X认为：“为项目上线的准备工作”不熟于开发任务。所以不列进日计划。
这也正是SCRUM的一些不足之处。
但是这的确是今天想要做的事情之一。
每个人都有自己想要做的事情，肯定没有充分的反馈给项目经理，项目经理也没有了解到这些情况。

我们该怎么办？
首先要明确本周或本阶段的目标是什么？
其次就要把今天需要做的任务统统列出来，陈芝麻烂谷子的事都可以列出来。
然后为每个任务设计优先级。
然后确定今天必须要做哪些事情，哪些可以放在一边。

这样就避免了，做事没有主次，轻重。
特别是在有突发性任务时，项目经理一定要清楚。然后再进行取舍


三、放纵
  我们一定要相信个人差异。有些人能力强些，有些人能力差些。有些人做事快些，有些人做事慢些。
每个人的生产率并不相同。
  在项目A中，程序员Y做事比较慢，习惯了慢速度。而且别人不能打扰他。一旦受到打扰，当天的工作很难完成。
项目经理J向我反映说程序员Y总是不能完成日计划的任务。
  我：“任务是否过重？”
  项目经理J：“不是,大部份人都能完成”
  我：“任务难度大，相关技术Y没有掌握？”
  项目经理J：“不是，技术没有难度”
  我：“原因是什么？”
  项目经理J：“主要是程序员Y不能受到打扰，如果遇到突发事件或别人打扰，任务就不能完成？”
  我：“你是怎么处理的？”
  项目经理J：“ 我也没有办法，他还是很努力的。”

这才是真正的执行力差，所以日计划是要与考核挂勾的。如果做完和不做完一个样，那大家都选择不做完好了。
所以项目组一定要有制度，制度不是用来压人的。但是是一个底线，任何人都不可以越过底线。否则就绝不手软


 

41 楼 tuti 2009-07-28  

多看看agile的资料，会有很多收益。
我觉得楼主的日计划也可以看作scrum的一种变例。

40 楼 lovejuan1314 2009-07-28  

tuti 写道

lovejuan1314 写道

感谢楼主的原创以及分享这么宝贵的经验. 我们以前也执行过类似楼主的日计划方法,不知道什么地方出问题了,日计划模式趋于了形式化. 看完楼主的文章,我想是执行力和任务的追踪程度上出问题了...

动不动就说什么执行力，多找找靠谱的原因

恩,tuti 所言即是. 我为止付出了整整一年多的时间在反思这些东西.其实我所说的是,一个项目经理的执行力. (作为项目成员大家都想能圆满顺利的完成,尤其是在项目工期比较紧张的情况下. )

正如楼主所说,

klyuan 写道

执行力。其实项目的执行力与项目经理有非常大的关系。项目经理需要识别风险，还要在把任务分配给程序员时要有预见性。在分配之前就要知道他会有什么问题。把任务分配给最佳人选。预见出现的问题和困难。并马上给予支持。但是很多PM做不到这一点。

从任务分配以及项目进度的控制上,如果项目经理的执行力不够,或者工作重点放错了位置,这无疑是致命的.这也是为什么有的时候楼主亲自实施这个计划的时候,效果就显而易见,而一旦换人就恢复原样的原因.

而我们当时日计划方案之所以会趋于形式化,其实当时情况特别复杂,但,当时的我远没有深刻体会到楼主写这篇文章的深度.认知度的不够就会导致执行力的偏差.而且当时根本没有从全局去考虑问题,只是习惯性的从技术思维来看待管理.所以当时的晨会和夕会成了大家交流出现的bug和技术难题上了(也确实当时在工期紧的情况冒险使用了新技术,这又验证着楼主所谓的项目经理需要识别风险的道理). 从而根本没有从整体来追踪和控制项目的进度. 虽然最终项目还是完成了,但,那次失败的惨烈让我如今仍不寒而栗!

39 楼 tuti 2009-07-28  

lovejuan1314 写道

感谢楼主的原创以及分享这么宝贵的经验. 我们以前也执行过类似楼主的日计划方法,不知道什么地方出问题了,日计划模式趋于了形式化. 看完楼主的文章,我想是执行力和任务的追踪程度上出问题了...

动不动就说什么执行力，多找找靠谱的原因

38 楼 香克斯 2009-07-28  

可以参考Scrum 的做法。
跟你这个的目标和做法还是比较类似的

37 楼 lovejuan1314 2009-07-28  

感谢楼主的原创以及分享这么宝贵的经验. 我们以前也执行过类似楼主的日计划方法,不知道什么地方出问题了,日计划模式趋于了形式化. 看完楼主的文章,我想是执行力和任务的追踪程度上出问题了...

36 楼 klyuan 2009-07-28  

InnocentBoy 写道

这就涉及到职业道德。这是个整体的素质，很多人都是这样。

其实不要担心。
比如防止程序员等任务做的情况发现。
但是不做日计划，程序员不就只是等任务做了。而是在那里拖延。
日计划是有目标的，有优先级。而且还要与周计划挂勾。
日计划是为周计划服务的，周计划是为阶段计划服务的。
每个阶段都要有非常明确的目标。
并且要可交付的成果。
日计划就是改变了以前项目经理期待程序员自觉完成。变为项目经理可以在了解程序员的每个过程。
这样项目经理就可以根据实际情况做出调整。
另外，日计划不是在项目一开始就把每天的工作分配完毕。这是不可能。
日计划是依赖于当前的项目情况和周目标或阶段目标。
让程序员做重要的事情。使整个项目团队都是在做最重要的事情。