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

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

 袁光东 原创

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

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

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

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

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

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

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

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

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

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

    六、没有银弹

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

评论

75 楼 klyuan 2009-08-16  

zhanglubing927 写道

忍不住点了个精华。

呵呵，谢谢啊

74 楼 klyuan 2009-08-16  

butterluo 写道

lovejuan1314 写道

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

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

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

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

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

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

感悟:

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

有点像功能点的计算工作量的方法。只是功能点是按照功能的难易赋予不同的分数，而不仅仅是计算完成功能的数量。
但感觉功能点这种方法比较难实施，原因如下：

一，不一定是完成功能多，所付出的劳动就越多，因为有些功能是很难的，而且这个功能到底怎么算功能点，也就是完成一个功能可以拿到多少积分，很难有一个公允的估算。如果像书上所说，大家开会决定某个功能所应该占用的分数的话，这样的成本也太大了吧。

二，即使可以做到合理的定义每个功能的分数，会不会造成程序员挑功能做的问题呢(就像项目经理有时为了自己的业绩好看而挑项目做一样)。即使不让程序员挑，而是通过经理分配任务，那如何保证任务分配的公平呢，毕竟涉及到自己的薪酬，如果某些程序员老被分配到项目低的任务，肯定会有不满。

三，有一些功能一开始定义的分数很低，但后来做了之后发觉很难，于是又要重新定义分数。这样会不会花了太多时间在定义功能的分数上了。

四，如果一些功能一开始定义的分数很高，但后来做了之后发觉其实很简单，那么负责哪个功能的程序员有可能就不会反映实情，毕竟大部分人都是希望花少力气，拿多分数的。

这些既涉及到绩效考核的问题，也涉及到做计划时公平(不是平均哦)分配任务的问题，
不知道大家是如何解决的呢

1.事先估算，及时发现问题，及时调整

73 楼 lucky16 2009-08-12  

好帖子，
学习了

72 楼 zhanglubing927 2009-08-10  

忍不住点了个精华。

71 楼 butterluo 2009-08-08  

lovejuan1314 写道

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

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

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

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

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

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

感悟:

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

有点像功能点的计算工作量的方法。只是功能点是按照功能的难易赋予不同的分数，而不仅仅是计算完成功能的数量。
但感觉功能点这种方法比较难实施，原因如下：

一，不一定是完成功能多，所付出的劳动就越多，因为有些功能是很难的，而且这个功能到底怎么算功能点，也就是完成一个功能可以拿到多少积分，很难有一个公允的估算。如果像书上所说，大家开会决定某个功能所应该占用的分数的话，这样的成本也太大了吧。

二，即使可以做到合理的定义每个功能的分数，会不会造成程序员挑功能做的问题呢(就像项目经理有时为了自己的业绩好看而挑项目做一样)。即使不让程序员挑，而是通过经理分配任务，那如何保证任务分配的公平呢，毕竟涉及到自己的薪酬，如果某些程序员老被分配到项目低的任务，肯定会有不满。

三，有一些功能一开始定义的分数很低，但后来做了之后发觉很难，于是又要重新定义分数。这样会不会花了太多时间在定义功能的分数上了。

四，如果一些功能一开始定义的分数很高，但后来做了之后发觉其实很简单，那么负责哪个功能的程序员有可能就不会反映实情，毕竟大部分人都是希望花少力气，拿多分数的。

这些既涉及到绩效考核的问题，也涉及到做计划时公平(不是平均哦)分配任务的问题，
不知道大家是如何解决的呢

70 楼 tuti 2009-08-03  

klyuan 写道

（首先这种方法没有问题，在我的项目组执行得非常好）
他项目组有一个工作年限比较长的程序员K，这个程序员的工作年限比项目经理Q的工作年限长。
项目经理Q在检查工作时，几乎是一种命令的方式和责骂的方式。结果程序员K要不就是不理他，要不就是直接顶撞。
一段时间后，程序员K离职走人。
后来，我们聊起这个问题。他说为什么会这样？是不是这个方法不行。
我跟他说，不是方法的问题。而是在执行的时候出了问题。
第一、尊重。（管理人员的责任之一就是要让员工获得尊重）
第二、找出问题的原因
第三、不要上升到人格问题，不追究历史旧帐
第四、给予指导，一起制定解决方法

具体实践的执行效果，是和执行者的价值观（Values）相联系在一起的。
问题出在Q的价值观上。

69 楼 klyuan 2009-08-02  

issppt 写道

通过讨论学习日计划，有一些收获：
在公司环境和项目类型适合的前提下，对项目计划尽量的细化，使得工作执行情况相应的细化，可以更加方便的监控项目，提高组员工作效率和项目进行效率。
通过任务分配时的会议形式，可以提高任务分配的效率，强化沟通，同时可以相应的以对比竞争的形式提高组员工作的积极性，也有助于所有组员对目前项目整体情况的了解，以后对自己工作的紧迫感认识。
日事日清的态度，可以理解为对于项目任务每天进行清查，即使任务是3天或者4天的，在时间允许的情况下，项目经理尽量多去检查，了解任务的进行。

我非常喜欢“敏捷软件开发”。
但我始终不认为它是一个方法，而是一种思想。
如果你在实践敏捷时完全按照敏捷去做，反而就不“敏捷”了。

去实践一个方法是都会遇到一些困难，包括失败。很多情况不是方法有问题。而是执行的时候犯了错误。
比如有一个项目经理Q在实践日清日结时，他要求每个人每天都要把任务做完。
（首先这种方法没有问题，在我的项目组执行得非常好）
他项目组有一个工作年限比较长的程序员K，这个程序员的工作年限比项目经理Q的工作年限长。
项目经理Q在检查工作时，几乎是一种命令的方式和责骂的方式。结果程序员K要不就是不理他，要不就是直接顶撞。
一段时间后，程序员K离职走人。
后来，我们聊起这个问题。他说为什么会这样？是不是这个方法不行。
我跟他说，不是方法的问题。而是在执行的时候出了问题。
第一、尊重。（管理人员的责任之一就是要让员工获得尊重）
第二、找出问题的原因
第三、不要上升到人格问题，不追究历史旧帐
第四、给予指导，一起制定解决方法

这是一个很常见的案例。

还有就是要灵活运用，不能生搬硬套。不同的环境，不同的阶段会有不同的方法。

比如我监管的几个项目组。有一个项目组，几乎天天跟他们在一起。有些项目组却是一个星期去几次。
这个跟他们的成熟度有关系。成熟度高的项目组，因为他们已经形成习惯了，每天知道该做什么，并且不会拖延。
这样的项目组我并不需要天天监管。
相对于成熟度较低的，程序员工作都没有重点的，还没有形成良好习惯的就需要把他们的能力培养起来

68 楼 klyuan 2009-08-02  

issppt 写道

感觉还是和实际有一些差距，讨论了这么长时间，有几个地方仍然感觉和目前自己管理的项目有一定差距，可能还是由于项目类型不同的原因。
第一，即使在前一天已经了解项目目前情况的前提下，进行日计划得到任务分配的时间远远高于5-10分钟这个理想状况，如果说提前准备好了任务分配，用5-10分钟告诉组员今天的任务，并达到共识，6个人的项目大致需要15-30分钟的例会。但是从夕会结束，打好腹稿根据跟中情况得出任务分配大致需要30-60分钟时间。感觉根据目前状态给出明天一个员工的任务，不是简单的通过这个员工应有的效率，一霎那就可以得出任务量应该是多少，需要考虑的问题还应该有，这个任务完成对某个功能点时间的影响，推迟完成可能出现的问题，如果提前完成应该增加的任务，等等。另外有些特殊情况也是考虑的范围，比如某个任务对项目很重要，而执行任务的人员突然需要假期的问题。
第二，如果说晨会中只是通知下任务，而不与执行任务的员工达成共识而是另外确定时间来讨论的话，改任务的分配其实并不能算是成功的任务分配。额外的讨论时间仍然应该算是日计划任务分配的时间消耗。只有在达成共识后任务的分配才能基本算是有效的。
第三，其实在外包行当里，大多数情况下客户就真的是上帝，所以客户最紧急的事情就是最重要的事情，欧美的客户还好说点，通融度和态度比较好，应为欧美客户的概念就是，无论如何，最后结果是好的就好，所以如果他们的请求错了，你做了对了，结果没有问题。但是如果碰到日本客户，尤其比较变态的，他们的态度就是，无论项目成功与否，你给的服务我满意了就好，也就是说，他们说什么你们做什么就好，如果他们给出的错误的请求，你不执行而进行了正确的任务，他们反而会很生气，甚至直接用严厉的批评语气找你上级主管，你为什么不按我说的做，这种事以前公司遇到过几次了，血淋淋的例子。

这个需要去实践，实践了才会知道。
为什么我说8个人以内的项目晨会时间只需要5-10分钟呢。这是长时间的实践得出的结果。
而你说要15-30分钟，我就不知道了，最好是把你的实践说出来。
关于分配任务，并不只是简单的下达命令。如果真是这样，管理就太粗暴了。
对于成熟度比较低的项目，日计划是由项目经理来主导的。对于成熟度比较高的项目，项目经理来引导，程序员则占主导。
首先项目组要有统一的开发方式。也就是把任务分解为任务有一个套方法，大家都认可的。
因为分解为任务了，都是细粒度的工作，所以程序员很容易估算工作量。加上日计划进行多了之后，每个人的生产率已经有一定的数据了。
所以任务分配一般就是与程序员达成一致的过程。这个过程很简单。
当然也有“故事”不明确的，或者程序员对分解有不同意见，或者说程序员对这一块的需求还不明确，就不能够在晨会中来讨论。因为这会浪费大家的时间。可以先放下，先把其它人的任务分配完。
然后定时间与程序员讨论。让程序员明白要干什么。这是非常关键的。
对于需求变更，不管是什么客户，项目组都需要有一个变更流程。客户也是人，蛮不讲理的还是少数。主要还是在于沟通的方式。注意沟通的细节。如果没有流程，轻易承诺，其实对客户和项目组都是一种伤害。
但是要注意方式和方法。目的就是要双赢，站在对方的立场考虑，弄清楚他想要什么。

67 楼 issppt 2009-08-02  

通过讨论学习日计划，有一些收获：
在公司环境和项目类型适合的前提下，对项目计划尽量的细化，使得工作执行情况相应的细化，可以更加方便的监控项目，提高组员工作效率和项目进行效率。
通过任务分配时的会议形式，可以提高任务分配的效率，强化沟通，同时可以相应的以对比竞争的形式提高组员工作的积极性，也有助于所有组员对目前项目整体情况的了解，以后对自己工作的紧迫感认识。
日事日清的态度，可以理解为对于项目任务每天进行清查，即使任务是3天或者4天的，在时间允许的情况下，项目经理尽量多去检查，了解任务的进行。

66 楼 issppt 2009-08-01  

klyuan 写道

issppt 写道

引用

之所以日计划就是在每天晨会时制定当天每个人的工作任务，并且要求每个人都完成当天的工作任务。
并不会在项目的计划阶段就把整个后续项目生命周期的工作日的详细计划都列出来。
如果这样做是非常不敏捷的。
项目的计划阶段，只能是制定一个大的计划，阶段性的计划。具体有那些阶段由你采用的开发模型而决定。
如果没有特殊的原因，阶段性的计划一定确定就很少会更改。
但是这个计划太粗了，所以我们在实际的执行过程中需要根据大计划来指导制定不同周期的小计划。
每周要制定周计划，周计划是为阶段计划服务的。
每天的日计划就是为周计划服务的。
粗粒度计划的调整是比较少的
而细粒度计划的调整可以非常频繁。
计划可以贯穿于项目的整个生命周期，并不仅仅是项目的计划阶段

恩，这个我觉得很对，所以才想问一下时间的花费情况。
对于日计划，你的描述中只有早上例会的5-10分钟，下午例会的20分钟。
而日计划的任务分配又是在上午5-10分钟的例会就完成了，所以我才会想要知道需要多长时间来对计划进行细化，任务的分配需要考虑的因素有几个，项目的计划，项目目前的执行情况，每个项目成员的负荷情况，项目组成员目前工作的进度，已经突然从客户那获取的高优先级的变更等等。
5-10分钟的早例会时间仅仅够将准备好的计划告诉给组员的，那么前面综合各种因素，而得到日计划以及任务划分的时间大致回事多少，想具体了解下。

日计划是一个过程，产出就是任务分配。
也可以说任务分配是晨会中的一个重要活动。
任务分配的时间<=晨会时间
任务分配为什么会花这么少的时间？
通过每天下班前的夕会，你已经完全的了解了项目的状况，每个人的工作完成情况。
其实很多时间在夕会结束后你的心里已经有了一个草稿，第二天谁该做些什么？都基本清楚了。
为什么不在夕会中分配第二天的任务呢？因为日计划提倡日清日结。如果有人没有完成任务是要求加班完成的。完成任务的可以按时下班。
在晨会时可以把前一天的工作简单回顾一下。
另外有些任务相对没有那么明确，需要更细的分解。这时就需要由具体负责的程序员来提供一个分解。
所以晨会的时间非常短！
如果在晨会中引发了其它问题，通常是不去深入，记录下来，另外确定时间来讨论。
而不要在晨会中处理所有问题。
晨会的作用：1。明确当前状态
            2.当天工作任务分配清单（任务，优先级，责任人）

对于客户突然的需求变更？
这是一个需求变更的问题，如果项目组有一个良好的开发习惯就会避免这些问题。
比如变更流程，任何变更都不是马上答应用户的，需要有评估，分析。
另外，对于突发事情，也是经常有的。
但是记住一条，"只做最重要的事情。而不是做最紧急的事情"。

感觉还是和实际有一些差距，讨论了这么长时间，有几个地方仍然感觉和目前自己管理的项目有一定差距，可能还是由于项目类型不同的原因。
第一，即使在前一天已经了解项目目前情况的前提下，进行日计划得到任务分配的时间远远高于5-10分钟这个理想状况，如果说提前准备好了任务分配，用5-10分钟告诉组员今天的任务，并达到共识，6个人的项目大致需要15-30分钟的例会。但是从夕会结束，打好腹稿根据跟中情况得出任务分配大致需要30-60分钟时间。感觉根据目前状态给出明天一个员工的任务，不是简单的通过这个员工应有的效率，一霎那就可以得出任务量应该是多少，需要考虑的问题还应该有，这个任务完成对某个功能点时间的影响，推迟完成可能出现的问题，如果提前完成应该增加的任务，等等。另外有些特殊情况也是考虑的范围，比如某个任务对项目很重要，而执行任务的人员突然需要假期的问题。
第二，如果说晨会中只是通知下任务，而不与执行任务的员工达成共识而是另外确定时间来讨论的话，改任务的分配其实并不能算是成功的任务分配。额外的讨论时间仍然应该算是日计划任务分配的时间消耗。只有在达成共识后任务的分配才能基本算是有效的。
第三，其实在外包行当里，大多数情况下客户就真的是上帝，所以客户最紧急的事情就是最重要的事情，欧美的客户还好说点，通融度和态度比较好，应为欧美客户的概念就是，无论如何，最后结果是好的就好，所以如果他们的请求错了，你做了对了，结果没有问题。但是如果碰到日本客户，尤其比较变态的，他们的态度就是，无论项目成功与否，你给的服务我满意了就好，也就是说，他们说什么你们做什么就好，如果他们给出的错误的请求，你不执行而进行了正确的任务，他们反而会很生气，甚至直接用严厉的批评语气找你上级主管，你为什么不按我说的做，这种事以前公司遇到过几次了，血淋淋的例子。

65 楼 klyuan 2009-08-01  

issppt 写道

引用

之所以日计划就是在每天晨会时制定当天每个人的工作任务，并且要求每个人都完成当天的工作任务。
并不会在项目的计划阶段就把整个后续项目生命周期的工作日的详细计划都列出来。
如果这样做是非常不敏捷的。
项目的计划阶段，只能是制定一个大的计划，阶段性的计划。具体有那些阶段由你采用的开发模型而决定。
如果没有特殊的原因，阶段性的计划一定确定就很少会更改。
但是这个计划太粗了，所以我们在实际的执行过程中需要根据大计划来指导制定不同周期的小计划。
每周要制定周计划，周计划是为阶段计划服务的。
每天的日计划就是为周计划服务的。
粗粒度计划的调整是比较少的
而细粒度计划的调整可以非常频繁。
计划可以贯穿于项目的整个生命周期，并不仅仅是项目的计划阶段

恩，这个我觉得很对，所以才想问一下时间的花费情况。
对于日计划，你的描述中只有早上例会的5-10分钟，下午例会的20分钟。
而日计划的任务分配又是在上午5-10分钟的例会就完成了，所以我才会想要知道需要多长时间来对计划进行细化，任务的分配需要考虑的因素有几个，项目的计划，项目目前的执行情况，每个项目成员的负荷情况，项目组成员目前工作的进度，已经突然从客户那获取的高优先级的变更等等。
5-10分钟的早例会时间仅仅够将准备好的计划告诉给组员的，那么前面综合各种因素，而得到日计划以及任务划分的时间大致回事多少，想具体了解下。

日计划是一个过程，产出就是任务分配。
也可以说任务分配是晨会中的一个重要活动。
任务分配的时间<=晨会时间
任务分配为什么会花这么少的时间？
通过每天下班前的夕会，你已经完全的了解了项目的状况，每个人的工作完成情况。
其实很多时间在夕会结束后你的心里已经有了一个草稿，第二天谁该做些什么？都基本清楚了。
为什么不在夕会中分配第二天的任务呢？因为日计划提倡日清日结。如果有人没有完成任务是要求加班完成的。完成任务的可以按时下班。
在晨会时可以把前一天的工作简单回顾一下。
另外有些任务相对没有那么明确，需要更细的分解。这时就需要由具体负责的程序员来提供一个分解。
所以晨会的时间非常短！
如果在晨会中引发了其它问题，通常是不去深入，记录下来，另外确定时间来讨论。
而不要在晨会中处理所有问题。
晨会的作用：1。明确当前状态
            2.当天工作任务分配清单（任务，优先级，责任人）

对于客户突然的需求变更？
这是一个需求变更的问题，如果项目组有一个良好的开发习惯就会避免这些问题。
比如变更流程，任何变更都不是马上答应用户的，需要有评估，分析。
另外，对于突发事情，也是经常有的。
但是记住一条，"只做最重要的事情。而不是做最紧急的事情"。

64 楼 issppt 2009-08-01  

引用

之所以日计划就是在每天晨会时制定当天每个人的工作任务，并且要求每个人都完成当天的工作任务。
并不会在项目的计划阶段就把整个后续项目生命周期的工作日的详细计划都列出来。
如果这样做是非常不敏捷的。
项目的计划阶段，只能是制定一个大的计划，阶段性的计划。具体有那些阶段由你采用的开发模型而决定。
如果没有特殊的原因，阶段性的计划一定确定就很少会更改。
但是这个计划太粗了，所以我们在实际的执行过程中需要根据大计划来指导制定不同周期的小计划。
每周要制定周计划，周计划是为阶段计划服务的。
每天的日计划就是为周计划服务的。
粗粒度计划的调整是比较少的
而细粒度计划的调整可以非常频繁。
计划可以贯穿于项目的整个生命周期，并不仅仅是项目的计划阶段

恩，这个我觉得很对，所以才想问一下时间的花费情况。
对于日计划，你的描述中只有早上例会的5-10分钟，下午例会的20分钟。
而日计划的任务分配又是在上午5-10分钟的例会就完成了，所以我才会想要知道需要多长时间来对计划进行细化，任务的分配需要考虑的因素有几个，项目的计划，项目目前的执行情况，每个项目成员的负荷情况，项目组成员目前工作的进度，已经突然从客户那获取的高优先级的变更等等。
5-10分钟的早例会时间仅仅够将准备好的计划告诉给组员的，那么前面综合各种因素，而得到日计划以及任务划分的时间大致回事多少，想具体了解下。

63 楼 klyuan 2009-07-31  

issppt 写道

klyuan 写道

issppt 写道

引用

关于管理多个项目，首先你要能够管理好一个项目，才有说服力去管理多个项目。
笔者同时管理多个项目，而且日计划执行得非常好，项目的效果也非常好。
当你在管理多个项目时，你需要去做每一个细节？那是不需要的。
关键是要把整个方法传授给你的团队，指导他们怎么去实施。
同时需要控制关键点,比如范围
会不定期的参与不同项目组的晨会
每天查看他们的日计划执行情况等，识别项目的风险。并不需要你什么都去做。你能力再强，也不可能什么都去做。
关于需求变更与日计划。越是变更越频繁的项目，日计划起到的作用就越大。
因为调整的频率高了，也就是应变及时了。不是吗？

理论的东西总不如实际的来的清晰，用一个例子来解释下吧.
以一个7人项目为例，简单的介绍下这个7人项目进行日计划的时间吧，按正常外包项目的成本估计，这个项目是一个10人月的项目，工期是两个月。公司一般会指派6名项目组成员，2名se，2名senior pg，还两名刚毕业不到半年的junior pg。包括项目经理1人，一共是7个人。
简单给下这个项目日计划项目经理的所需要的时间吧。

项目经理花在日计划的时间：
每天早上晨会5-10分钟
下午检查工作20分钟
PM花在项目日计划的时候是30分钟。
不要跟我说，项目组每个人每天都是满负荷8小时的。
30分钟的时候是非常容易抠出来的

项目组最好有一块白板，日计划真接写到白板上。晨会结束后再形成正式的文档。
把白板的草图转为正式的文档，可以你自己做，也可以交给一个初级程序员做。
更多的时候可以选择由一个初级程序员来做。（需要细心和责任心的程序员）
如果你的白板够大，完全可以把一周的日计划都放在白板上。

比如8:30上班，但是8:30所有人到齐的项目组很少。可能9:00才开始正式工作。
（打水，上洗手间，抽烟，吃早餐等等）

所以我的项目组都是要求所有人8:30准时到。
项目组的人养成了一个良好的工作习惯，工作效率也随之提升

按这个意思也就是在项目计划阶段，抽出时间来在完成项目计划的同时，日计划的方案要同时做出来，包括实际各种未知问题出现对日计划的影响以及相应的调整。
这个时间大致需要多久，按上述的规模来说，普通的以任务玩检查方式，一般项目的KT和计划阶段会在两周。如果同时把日计划制定出来大致会用长时间。

之所以日计划就是在每天晨会时制定当天每个人的工作任务，并且要求每个人都完成当天的工作任务。
并不会在项目的计划阶段就把整个后续项目生命周期的工作日的详细计划都列出来。
如果这样做是非常不敏捷的。
项目的计划阶段，只能是制定一个大的计划，阶段性的计划。具体有那些阶段由你采用的开发模型而决定。
如果没有特殊的原因，阶段性的计划一定确定就很少会更改。
但是这个计划太粗了，所以我们在实际的执行过程中需要根据大计划来指导制定不同周期的小计划。
每周要制定周计划，周计划是为阶段计划服务的。
每天的日计划就是为周计划服务的。
粗粒度计划的调整是比较少的
而细粒度计划的调整可以非常频繁。
计划可以贯穿于项目的整个生命周期，并不仅仅是项目的计划阶段

62 楼 issppt 2009-07-31  

klyuan 写道

issppt 写道

引用

关于管理多个项目，首先你要能够管理好一个项目，才有说服力去管理多个项目。
笔者同时管理多个项目，而且日计划执行得非常好，项目的效果也非常好。
当你在管理多个项目时，你需要去做每一个细节？那是不需要的。
关键是要把整个方法传授给你的团队，指导他们怎么去实施。
同时需要控制关键点,比如范围
会不定期的参与不同项目组的晨会
每天查看他们的日计划执行情况等，识别项目的风险。并不需要你什么都去做。你能力再强，也不可能什么都去做。
关于需求变更与日计划。越是变更越频繁的项目，日计划起到的作用就越大。
因为调整的频率高了，也就是应变及时了。不是吗？

理论的东西总不如实际的来的清晰，用一个例子来解释下吧.
以一个7人项目为例，简单的介绍下这个7人项目进行日计划的时间吧，按正常外包项目的成本估计，这个项目是一个10人月的项目，工期是两个月。公司一般会指派6名项目组成员，2名se，2名senior pg，还两名刚毕业不到半年的junior pg。包括项目经理1人，一共是7个人。
简单给下这个项目日计划项目经理的所需要的时间吧。

项目经理花在日计划的时间：
每天早上晨会5-10分钟
下午检查工作20分钟
PM花在项目日计划的时候是30分钟。
不要跟我说，项目组每个人每天都是满负荷8小时的。
30分钟的时候是非常容易抠出来的

项目组最好有一块白板，日计划真接写到白板上。晨会结束后再形成正式的文档。
把白板的草图转为正式的文档，可以你自己做，也可以交给一个初级程序员做。
更多的时候可以选择由一个初级程序员来做。（需要细心和责任心的程序员）
如果你的白板够大，完全可以把一周的日计划都放在白板上。

比如8:30上班，但是8:30所有人到齐的项目组很少。可能9:00才开始正式工作。
（打水，上洗手间，抽烟，吃早餐等等）

所以我的项目组都是要求所有人8:30准时到。
项目组的人养成了一个良好的工作习惯，工作效率也随之提升

按这个意思也就是在项目计划阶段，抽出时间来在完成项目计划的同时，日计划的方案要同时做出来，包括实际各种未知问题出现对日计划的影响以及相应的调整。
这个时间大致需要多久，按上述的规模来说，普通的以任务玩检查方式，一般项目的KT和计划阶段会在两周。如果同时把日计划制定出来大致会用长时间。

61 楼 klyuan 2009-07-31  

issppt 写道

引用

关于管理多个项目，首先你要能够管理好一个项目，才有说服力去管理多个项目。
笔者同时管理多个项目，而且日计划执行得非常好，项目的效果也非常好。
当你在管理多个项目时，你需要去做每一个细节？那是不需要的。
关键是要把整个方法传授给你的团队，指导他们怎么去实施。
同时需要控制关键点,比如范围
会不定期的参与不同项目组的晨会
每天查看他们的日计划执行情况等，识别项目的风险。并不需要你什么都去做。你能力再强，也不可能什么都去做。
关于需求变更与日计划。越是变更越频繁的项目，日计划起到的作用就越大。
因为调整的频率高了，也就是应变及时了。不是吗？

理论的东西总不如实际的来的清晰，用一个例子来解释下吧.
以一个7人项目为例，简单的介绍下这个7人项目进行日计划的时间吧，按正常外包项目的成本估计，这个项目是一个10人月的项目，工期是两个月。公司一般会指派6名项目组成员，2名se，2名senior pg，还两名刚毕业不到半年的junior pg。包括项目经理1人，一共是7个人。
简单给下这个项目日计划项目经理的所需要的时间吧。

项目经理花在日计划的时间：
每天早上晨会5-10分钟
下午检查工作20分钟
PM花在项目日计划的时候是30分钟。
不要跟我说，项目组每个人每天都是满负荷8小时的。
30分钟的时候是非常容易抠出来的

项目组最好有一块白板，日计划真接写到白板上。晨会结束后再形成正式的文档。
把白板的草图转为正式的文档，可以你自己做，也可以交给一个初级程序员做。
更多的时候可以选择由一个初级程序员来做。（需要细心和责任心的程序员）
如果你的白板够大，完全可以把一周的日计划都放在白板上。

比如8:30上班，但是8:30所有人到齐的项目组很少。可能9:00才开始正式工作。
（打水，上洗手间，抽烟，吃早餐等等）

所以我的项目组都是要求所有人8:30准时到。
项目组的人养成了一个良好的工作习惯，工作效率也随之提升

60 楼 issppt 2009-07-30  

引用

关于管理多个项目，首先你要能够管理好一个项目，才有说服力去管理多个项目。
笔者同时管理多个项目，而且日计划执行得非常好，项目的效果也非常好。
当你在管理多个项目时，你需要去做每一个细节？那是不需要的。
关键是要把整个方法传授给你的团队，指导他们怎么去实施。
同时需要控制关键点,比如范围
会不定期的参与不同项目组的晨会
每天查看他们的日计划执行情况等，识别项目的风险。并不需要你什么都去做。你能力再强，也不可能什么都去做。
关于需求变更与日计划。越是变更越频繁的项目，日计划起到的作用就越大。
因为调整的频率高了，也就是应变及时了。不是吗？

理论的东西总不如实际的来的清晰，用一个例子来解释下吧.
以一个7人项目为例，简单的介绍下这个7人项目进行日计划的时间吧，按正常外包项目的成本估计，这个项目是一个10人月的项目，工期是两个月。公司一般会指派6名项目组成员，2名se，2名senior pg，还两名刚毕业不到半年的junior pg。包括项目经理1人，一共是7个人。
简单给下这个项目日计划项目经理的所需要的时间吧。

59 楼 klyuan 2009-07-30  

雁行 写道

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

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

日计划强调的是可交付成果.
并不会是33%,33%,33%这个很难以量化的目标。

三天开发一个模块。这正是传统的项目管理的任务分配方式。
你是项目经理，你让一个人用三天去开发一个模块，你心里有没有底，这个结果是什么？
1、三天后能不能够完成？
2、三天后完成的质量是怎么样？（代码写完而已，没法调试？调试通过，但是问题较多？调试通过，但是业务理解错误）
这些你都是无法控制的。


如果你是程序员，项目经理让你三天后完成一个模块，你会怎么做？
1。第三天开始动工，什么时候完期还真难说
2.第一天就开始动工，一天完成工作，第三天提交
还有多种情况。

这样的任务分配，对于是否能够按期，保质完成，这就要看程序员的素质了。
还有，风险没有办法控制和识别。

如果再进行细分：
模块XX，预估时间3人天(假设分析和设计已经完成)
  dao，service编写，并完成单元测试  1人天
   action,jsp编写 1人天
   集成测试，能够联调成功 1人天
我这里只是举例说明，具体的分解方法可以根据项目组的开发习惯而定。
发果进行了这样的分解，就可以进行更好的控制。
当第一天下班前，dao和service代码没有编写完，就要找原因。
如果只是代码写完了，但并没有单元测试通过，就说明这个任务没有完成。需要加班。

日计划就是每天每个人做的任务都是要可以交付的。

58 楼 klyuan 2009-07-30  

issppt 写道

klyuan 写道

issppt 写道

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

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

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

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

谢谢你参与讨论。
你说的这些是一些项目经理经常挂在嘴上的托词。
我经常叫一些项目经理做一些日常管理：（如及时变更计划，使计划反映项目最真实的情况），他们经常挂在嘴上的就是：“没有时间，我还要写代码，开会。”
反过来想想，如果一个项目经理把时间花在写代码(不是说项目经理不可以写代码，我也经常写，并且写得不比其它人少)，开会等，而无暇顾及了解项目的真实情况，不去及时调整计划。这真是一个让人哭笑不得的事情。那么我们还要一个项目经理干什么？我们的项目还需要管理？当项目失败了，他们总会找一些理由：“需求变更，人员水平，时间紧急等”。如果你是一个成功的项目经理，这些问题在产生的初期就要被你及时发现并处理了。要不然，你这个项目经理就没有价值，没有起到作用。
这有些本末倒置了。什么是管理成本？即然公司指定了项目经理这个角色，给了你这个位置，公司就已经承受了这个成本。公司是要你把项目做成功，而不是失败了之后找理由,你的工资并不会因为你多做一些管理工作或少做一些管理工作随之增加或减少？会吗？你所谓的管理成本是你自己想不想做事的成本，与公司无关。
可见，项目经理首先需要明白自己该做什么？而且还要明白自己最该做什么？
如果一个项目经理没有把需求范围，时间，成本，质量这几个方面控制好，写再多的代码又有何用？个人能力再强又有何用，只能说明他更适合去写程序，做技术，而不是管理。

好了，至于说管理多个项目。如果你连一个项目都管理不好，都不能做到利益最大化。老板又怎么相信你可以带多个项目,老板不会是傻瓜。如果真是这样让管理一个项目都管理不好的人去管理多个项目，那岂不会眉毛和胡子一把抓？最主要是当你身处一个环境和位置时，要能在瞬间知道自己该做什么？最该做的是什么？
日计划就是让你最真实的了解项目的情况，及时发现风险和对项目进行调整。
永远要记住：“计划的调整本身就是计划的一部份”
而不是，在项目启动时做了一个计划，到结束时也是这个计划。
很多项目在运作一段时间后，计划就已经没有用了，项目处理无计划运作中。

关于管理多个项目，首先你要能够管理好一个项目，才有说服力去管理多个项目。
笔者同时管理多个项目，而且日计划执行得非常好，项目的效果也非常好。
当你在管理多个项目时，你需要去做每一个细节？那是不需要的。
关键是要把整个方法传授给你的团队，指导他们怎么去实施。
同时需要控制关键点,比如范围
会不定期的参与不同项目组的晨会
每天查看他们的日计划执行情况等，识别项目的风险。并不需要你什么都去做。你能力再强，也不可能什么都去做。
关于需求变更与日计划。越是变更越频繁的项目，日计划起到的作用就越大。
因为调整的频率高了，也就是应变及时了。不是吗？

57 楼 klyuan 2009-07-30  

fly_ever 写道

klyuan 写道

fly_ever 写道

klyuan 写道

fly_ever 写道

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

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

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

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

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

如果只是根据故事分配工作，粒度太粗了。在成熟度比较高的团队可以这样做。
最好还是把故事再分解为任务。这样便于控制项目和追踪进度

56 楼 klyuan 2009-07-30  

tuti 写道

klyuan 写道

tuti 写道

klyuan 写道

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

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

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

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

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

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

我在项目中的规模的估算是以人天为单位的。