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

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

 袁光东 原创

如何提高项目的生产率，保证项目按期交付是每个软件开发项目经理都需要面对的难题。关于这方面的研究，在《人月神话》、《人件》等书籍都有很详细的论述。研究表明，不同程序员之间的生产率最高差别在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.如果程序员不能完成日计划怎么办？如何才能够使程序员能够完成日计划？

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

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

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

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

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

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

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

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

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

    六、没有银弹

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

评论

35 楼 klyuan 2009-07-28  

issppt 写道

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

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

34 楼 InnocentBoy 2009-07-27  

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

33 楼 issppt 2009-07-27  

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

32 楼 bevis.cn 2009-07-26  

赞同此观点，身有体会

31 楼 klyuan 2009-07-25  

skyxk 写道

看得出LZ写的这篇文章是通过自己很好的实践过，得出的一套经验办法
很值得学习，先谢谢LZ了

不过就像LZ说的，这些东西都还是要看执行力，及项目经理的能力，就像每个的日计划，想做好也是一件不容易的事情，很期待LZ对如何分配日计划的讨论

关于执行力，就是习惯成自然的事。关键还是在于坚持。只有长期做才会有效果。
关于如何分配日计划，最简单的就是在每天晨会中项目经理把每个人当天必须要完成的任务列出来。在下班前检查任务完成情况。并且与考核持勾。当某个程序员的任务不能完成时就需要查明不能完成的原因是什么？

当然，当在日计划的“任务”分解可能与传统的项目管理不同。但是可以参考SCRUM是怎么分解任务的。
SCRUM的“任务”都是依据于每一个“故事的”。这样可能有些临时性的，不属于故事的任务就不能纳入计划。
而日计划更灵活，任务事情，只要是属于项目开发的任务都可以纳入日计划的“任务中”。

30 楼 klyuan 2009-07-25  

matt.u 写道

不可能在项目初期就形成那么详细的日计划吧？

我现在做的就是把项目分成1-2天的工作模块，然后制定进计划里。
但是针对于每天的详细计划，感觉还是比较困难。

计划是一个逐渐由粗到细的过程。
即然是日计划就是可能是在项目初期就把每天的计划都做完。这正好犯了大忌。
日计划应该是前一天下班前有一个大体的思路。在晨会中与开发人员达成一致。
但千万要记住日计划一定要为周计划服务。
每个小阶段的计划都是为大阶段计划服务的。

29 楼 klyuan 2009-07-24  

xo_tobacoo 写道

程序员个人管理和经理的管理相结合，要程序员听话，有安全感对经理素质要求很高

项目的执行力，项目经理占了很大的原因。
同一个项目，相同的人，换了项目经理后产生了完全不同的执行效率。
这就是管理的作用。
如果大家都认为这不可能，也就没有管理这门学科了。

管理最核心的几点就是目标，计划，实施和监控。
项目管理也是一样。
如果所有的项目都依赖天程序员听话，那是很难的。
程序员听话与话还是看项目经理的手段。看你对他的支持度有多大，看你对工作的追踪力度有多大。
无限度的加班也是因为追踪和检查的力度有很大的关系。

如果要想把项目做好，就需要把追踪做到位。时时了解项目的真实情况，不致于使项目失控。

28 楼 skyxk 2009-07-24  

看得出LZ写的这篇文章是通过自己很好的实践过，得出的一套经验办法
很值得学习，先谢谢LZ了

不过就像LZ说的，这些东西都还是要看执行力，及项目经理的能力，就像每个的日计划，想做好也是一件不容易的事情，很期待LZ对如何分配日计划的讨论

27 楼 matt.u 2009-07-23  

不可能在项目初期就形成那么详细的日计划吧？

我现在做的就是把项目分成1-2天的工作模块，然后制定进计划里。
但是针对于每天的详细计划，感觉还是比较困难。

26 楼 xo_tobacoo 2009-07-23  

程序员个人管理和经理的管理相结合，要程序员听话，有安全感对经理素质要求很高

25 楼 klyuan 2009-07-23  

jerry.zhong 写道

楼主提到的 “工作成熟度”很有道理。
日计划初期实施对项目经理要求比较高，一旦形成惯性，对项目管控非常有帮助。
赞同楼主

是的。项目的成败与项目经理的关系非常大。
很多人初次管理项目时，就陷入编码去了。没有划出时间去进行管理。
日计划就是要求项目经理每天抽出时间进行项目的管理。
这样占用的时间其实非常少。
晨会10分钟，夕会20分钟。
很多项目经理都说没有时间，以项目进度很紧，人手不够等理由来为自己推脱。
其实一天抽出30分钟是很容易的事情。少两次则所，小抽两次烟。

24 楼 jerry.zhong 2009-07-22  

楼主提到的 “工作成熟度”很有道理。
日计划初期实施对项目经理要求比较高，一旦形成惯性，对项目管控非常有帮助。
赞同楼主

23 楼 klyuan 2009-07-21  

aws 写道

代码行数跟技术没啥关系

同样功能或者业务逻辑，实现同样的效果，技术好的同学可能会用更少的行数完成，也会更注重复用性和扩展性。

实际上我见过有些人一个action里一个方法写几百几千行代码，那是一层一层的if else
但实际上每个方法里面80%的代码是可以抽象出另一些方法的

如果我当时是项目经理的话，这种写法我肯定要他打回去重写

灌水充行数很容易做到的

josen 写道

用代码行来计算工作效率是有问题的

本文使用代码行作为工作量单位也是不得而为之。
当然还有功能点等，可能更复杂。但它都不是本文讨论的重点
欢迎一起讨论日计划。本文的主题是日计划。

22 楼 josen 2009-07-21  

用代码行来计算工作效率是有问题的

21 楼 cqllang 2009-07-21  

非常好的一篇文章。。

20 楼 aws 2009-07-21  

代码行数跟技术没啥关系

同样功能或者业务逻辑，实现同样的效果，技术好的同学可能会用更少的行数完成，也会更注重复用性和扩展性。

实际上我见过有些人一个action里一个方法写几百几千行代码，那是一层一层的if else
但实际上每个方法里面80%的代码是可以抽象出另一些方法的

如果我当时是项目经理的话，这种写法我肯定要他打回去重写

灌水充行数很容易做到的

19 楼 klyuan 2009-07-20  

muyangkm 写道

小项目确实没什么问题，有可行性。

不过，项目组100个人如何？日计划，谁来定，管理也是有成本的，管理也是有时间的，计划个人来定，总要汇报吧，100个人的汇报，你还要检查代码？确定完成没有？别想了，不要睡了。

当然啦，分20个小组，小组长给你汇报/日计划？ 你的工作轻松了，不过，最有效率的组织是扁平的，这样一天写一个报告，每天还有计划，实在是比较官僚的做法了，文档会很多的吧。

我在文章中说得比较清楚了。
晨会的开展人数要控制在十人之内。时间控制在5-10分钟。否则沟通的成本太大。
对于超过10人的团队，肯定是要分组的了。先要教会组长学会开展日计划。然后每天要组长提交日计划报告即可。
如果有多个组，PM也可以选择性的参加小组的晨会。
就像监管多个项目一样。我不可能把多个项目组召集在一起开晨会。这是不可能的。
而是训练项目负责人学会日计划，让其走上正规。所负责的项目组都走上正规了，可以有选择性的参加。
对于有100人的项目组，就不是分组了。肯定是分成小项目了。
所以团队的建设在项目管理中也非常重要。

18 楼 muyangkm 2009-07-19  

小项目确实没什么问题，有可行性。

不过，项目组100个人如何？日计划，谁来定，管理也是有成本的，管理也是有时间的，计划个人来定，总要汇报吧，100个人的汇报，你还要检查代码？确定完成没有？别想了，不要睡了。

当然啦，分20个小组，小组长给你汇报/日计划？ 你的工作轻松了，不过，最有效率的组织是扁平的，这样一天写一个报告，每天还有计划，实在是比较官僚的做法了，文档会很多的吧。

17 楼 klyuan 2009-07-17  

tuti 写道

klyuan 写道

tuti 写道

楼主实际照这你的说法实践过吗？
效果如何？

这些实践不是我想当然的，是在项目中亲自实践的。

效果嘛，关键是要执行。

在我亲自带的项目取得的效果是非常好的。项目没有加班，每天每个人都可以完成当天的工作。
项目的进度始终在控制之中。
在我监管的项目中90%的项目是成功的。主要还是要看项目经理的制行力。
也有失败的，失败的原因是项目经理不能够支持。
有一个项目是在已经陷入了泥潭时，我进行监管。把日计划开展了起来。项目按期交付。
当我走后，那个项目团队又回到了原点。这很无耐，因为需要项目经理要有很好的执行力。
如果项目经理陷入代码中不能自拔，那项目很难成功

项目结束后，有没有回顾总结的结论吗？
开发组的成员对这样做法有什么反馈意见？
再下一个项目里，开发组的成员愿不愿意继续采用这种方式？

这是一个必须的过程。
当在我的项目组的一个高级程序员去带项目后并主推这样的方法。就足以说明了这一切。
当然，我也给他提供了非常多的帮助。比如发现并帮助其解决程序员不能完成任务的问题等。

16 楼 klyuan 2009-07-17  

donitz 写道

klyuan 写道

ayor 写道

精僻,但要达到成熟很难

两个方法有难度：一是任务的分解。这方面我想专门写一篇文章来讨论。
其实大家也可以看看SCRUM的做法。关于故事和任务方面的。这与传统的工作分配有非常大的区别。
我是在写完这篇文章之后再看的SCRUM，发现我的作法与他们的几乎一样。
我在实施时的前期并没有考虑对任务进行具体的工时估算。但是SCRUM会对任务进行具体的工时估算。这一点，SCRUM更好一些。
后来我也采纳了SCRUM的方法，为每个任务进行工时估算。

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

这两个难度也是我现在遇到的，但是这两个难度有可以看成一个
问题就在于怎么能够保证程序员每天的计划和整体的计划匹配，也就是说PM怎么把握这个程序员当天的计划是足量，我以前遇到很多情况是要不太好了，要不太多，到后来发现根本1天做不完，这也就是说和PM的识别能力有关了

是的，项目经理需要是一个好的教练。即时发现程序员的问题，并总是能够及时的给予支持。这是非常的重要。
任务不能完成不能完成不是最害怕的。关键是要找到不能完成任务的原因。深层次的原因是什么？如何进行调整？