思步网

标题: 项目估算与计划（二） [打印本页]

作者: delia2010 时间: 2013-10-9 13:15
标题: 项目估算与计划（二）
本帖最后由 delia2010 于 2013-10-9 13:19 编辑

估算与计划（二）

   估算如何做出来？

    这里开始所说的估算，全部都是指项目组对项目的估算，这个估算的目的是用来指导项目的具体工作。

    有很多种估算办法，大致可以分为两类：
    1.先得到软件规模，然后根据公司实际的生产率由软件规模导出工作量。
    2.直接得到工作量。

    第一类的常见方法有：功能点法、代码行法，第二类的常见方法有Delphi估算法、微软的由底而上估算法。

    什么是软件规模？我们先看看一个搬砖头的估算。
    假设有1000块砖头，它们的大小和重量一样，每名工人每天能搬100块砖头，于是我们可以估算到需要10人日来搬完。10人日的意思是1名工人需要10天完成，而10名工人只需要1天就搞定了。
    这个1000块代表了工作的规模，而生产率就是100块/日，这样就可以推算出工作量为10人日。建筑工程可以得到土石方量、混凝土量、钢筋量等代表工作规模的数据，这样就比较容易推算出完成这些工作需要的工作量。

    而软件工程估算也希望能做到类似的效果，但用什么来代表软件项目的工作规模呢？功能点和代码行是常见的两种软件规模表示方式。

    软件规模是与软件具体生产技术、项目管理办法、项目组人员水平等无关的东西，软件规模只和软件项目本身的性质相关，如果我们能找到合适的统一的标准来度量每个项目的规模，这样每个软件项目之间就可以进行横向比较了。功能点法和代码行法都希望能达致这样的效果。

    功能点法的基本思路是将复杂的软件分解为一个一个独立的粒度一致的功能点，附加一些调整系数，得到软件规模。
我们的项目大部分是数据库四轮马车的操作（查询、增加、修改、删除），功能点法从比较高的层次对这些工作进行抽象，有一套严密的规则可以让你将需求分解成一个一个的功能点。代码行法思路也类似，不过分解的结果是代码行而已。但一般来说代码行与软件的实现技术相关度太大，大家会更加偏爱功能点法。

    功能点法和代码行法有比较长的历史，也有很多详细资料，大家可以去查阅一下。这方法理论上很理想，但实践效果很差，我还没有见到一家能成熟应用并且取得比较好效果的公司。功能点法和代码行法有这样的一些难以解决的问题：
    1.只适用于数据库四轮马车的操作的项目，高技术含量、创造性高的软件不适用，如游戏软件、计算机负责计算与决策软件等。
    2.我们绝大部分项目是需求不明确、设计不明确，并且工期很赶的，这两个方法都无法适应这样的现实条件。需求不明确基本上无法得到软件规模，建筑工程为什么能做到，是因为需求和设计都十分明确了。
    3.两个方法的规则都很详细，要花大量时间学习和实战才能掌握。
    4.由工作规模导出工作量这样的思考方式，难以适用于软件项目。项目组还是习惯列出具体的任务，逐条任务估计时间，而且只有这样的工作方式才能让项目组感觉更加踏实。

    Dephi估算法是比较符合大家实际工作习惯，也是比较容易掌握的估算办法。
    Delphi法的大致方法如下：
    1.找几名资深专家，一起对项目进行WBS，把项目的工作分解为十几条最多二三十条的工作项。
    2.全部专家各自估计每条工作项的工作量，并向其他专家阐述自己的理由。
    3.第一次各专家估出来的结果可能差异比较大，每位专家听取别人的意见后，重新估算。
    4.按照上述办法，各专家反复估算几次，一般次数就是2-4次，各专家估计的工作量会越来越趋近，这个时候取全部专家的平均值。

    普遍认为各专家的经验与知识水平会严重影响结果的准确性，而我的实践经验是：应该让项目组每个人自己来估算，也就是让大家来当专家，在这个基础上可以再增加一两名来自项目组外部的专家。

    有时候觉得估算这个问题搞得太复杂了，各式各样的方法是不是太夸张了？其实最简单的方法就是让负责该项工作的人自己来估计工作量，微软的由底而上的估算方法就是这样做的，可谓返璞归真啊！

    微软由底而上的估算方法大致是这样的：对项目各项工作进行分解后（即俗称的wbs：work breakdown structure，工作分解结构），每个任务落实负责人，由负责人对自己的任务进行估计。这个办法有以下好处：
    1.  最终该任务是由这个人来完成的，他估计多少时间才能做完，这个时间才是最接近实际的。
    2.  负责该任务的人进行估算的时候，肯定需要认真思考这个任务的风险，需要做哪些具体的工作，这样更容易在未开始工作之前就发现更多的潜在问题。相反如果由项目经理来分配时间，这个人就可能不会去思考这个任务了。
    3.  做这个任务的人会有被重视和尊重的感觉，他会很重视自己承诺的完成时间，并且想法设法按时间完成。这样会减少很多项目管理时间，因为每个任务负责人都会主动地跟踪好自己的工作。

    其实微软这个方法根本就没有什么特别，所有正常人都可以想到这个方法，但仍然有很多人去追求那些不太靠谱的估算方法。     这个方法还是有这样的一些问题的：
    1.有人会估算偏小，比方他说需要5天，但往往10天还完不成。
    2.有人估算过于保守。
    3.项目的进度要求就是很紧，基本上你必须在指定时间内完成，估算显得毫无价值。

    第一个问题是比较常见的，但我们要这样想：估不准也比不估算好，估算偏差哪怕超过100%，也比不估算好，至少有个谱。
    大家是会进步的，估不准往往是对任务和自己能力认识不到位，要让大家不害怕估算，只要敢于估算，问题才会暴露出来，才能持续进步。

    第二个问题分两种情况，有些人是确实是过分保守的对自己信心不太足，项目经理可以多多来指导他的工作，看看他具体的进展，让他更加充分地了解任务，更加充分了解自己的能力，增强他的信心，这样他就能持续进步了。而另外一种情况就比较恶劣，少数人会故意增大时间，这样他平时工作不必全力以赴，可以比较悠闲，甚至可以利用工作时间干私事。如果发现这样的情况，就应该严肃处理了，不要做烂好人，这样的人在团队中存在是对团队的极大伤害。

    第三个问题往往是各项目经理心中的痛楚，他们会觉得：实在无奈啊！做项目就是在有限时间有限资源内做不可能完成的任务，在这样的情况下，你就不要跟我扯估算了！
    我们的项目大部分情况都是非常大压力的，应对这样大的压力越需要冷静。实际上大部分项目尽管是有压力，但只要发挥团队的聪明才智，还是可以高效地做好工作的，不需要加班或者少加班。本文稍后会介绍这个问题的应对办法。

    介绍了这么多种估算方法，每种都有很多问题，那到底怎样才能做好项目估算呢？

    软件项目的特点就是项目签订时，价钱是死的，工期是死的，而需求和设计是不明确的。
我的经验告诉我，功能点法、代码行法这些方法基本上是不靠谱的，我在实际项目中会综合使用Dephi法和由底而上的估算方法，并予以改良，下面介绍一下我的一些心得体会。

    1.项目估算与其说是估出来，还不如说是做出来的。
    假设某项目是这样的情况：
    1）合同签署的金额是100万，工期是3个月。
    2）需求只是大致写了，并不明确。
    3）老板要赚50万，给你的预算只有50万。
    我们很多项目都是这样的情况，不是等你估算出比较靠谱的数字，然后才去报价签合同的，我们经常要在老板指定的预算下完成项目。
    你现在要负责这个项目，你会如何做估算呢？
    你需要做好两个事情，才能保证项目实际成本控制在预算内。
    第一个事情，控制好需求。需求不明确，这既是不利因素也是有利因素，应尽量往有利的方向控制。不明确的好处就是你有控制需求的空间，抓住客户的关键需求，简化不必要的花销的需求，能极大地降低项目工作量。
    第二个事情：想尽办法降低开发工作量。不要因为进度紧就不认真思考软件的设计，应尽量采用简单的成熟的设计方案，简化工作。

    2.估算应该持续进行，持续细化。
    项目初期很难对项目做完整估算，但能估计的部分应先估计出来，并且针对不明确的部分安排计划去搞清楚。

    3.估算是项目各种工作估算的总和。
    估算并不是只是得到一个项目估算的总体数字，项目的估算总数其实是由项目各种工作的估算组成的。
前文介绍了项目的各种工作，每一种工作都需要认真估算。如果估算发生偏差，要能定位到具体是哪部分的估算出问题了，否则估算没有指导项目工作的价值。功能点法、代码行法的估算办法，只能得到一个项目估算的总数，而不能定位到具体的哪一部分工作，这样得到的估算结果难以用来指导项目工作。

    4.估算依赖项目组的整体实力。
    如果你没有软件开发相关经验，只懂理论上的估算，你是不可能做好估算工作的。
项目组由项目管理、软件设计、编码、测试、实施等各类专业人才组成，每个人在自己方面都是专家，每个人都是整个项目组中最有资格对自己专业方面的工作进行估算。前文列出了的项目各方面的工作，应该由相应的项目成员为主进行估算。

    5.项目组应该不断学习、总结、进步，提高整体水平。
    需求不明确、设计不确定这是项目的特点，我们需要不断地学习来提高水平，将这些不明确的因素逐步明确。
    没有什么妙方能解决这些不明确的因素，靠的还是我们的知识和能力。项目组每个人都应该通过持续估算来发现自己的不足并提高水平。

    6.公司应该定期组织项目资深人士制定估算指南并持续更新。
    我们公司有一份估算模板，里面汇集了以前的估算经验，列出了所有需要考虑的估算内容以及详细的说明。
    我们以前没有估算模板时，估算偏差会达到50%以上，总结经验发现偏差的主要原因是估漏！使用估算模板会帮助我们发现遗漏，后来我们的估算偏差基本可以控制在20%以内。
    前文的“估算要估啥”小节，我列出了项目通常要考虑的各种工作，也列出了容易估漏和估计不足的地方，大家可在此基础上根据自己公司实际情况，修改和扩充这些内容，写出自己公司的估算模板或估算指南。

    先得到项目规模，再由规模导出工作量，这是一个很美好的想法，问题就是和我们的实际情况相去甚远了。
将工作分解，直到分解到可以估计工作量的程度，这个可能是最土最有效的方法了。但你可能会问，这样的估算方法，项目之间就无法横向比较了？

    项目估算第一目标是用来指导项目工作，如果这个目标都达不到，那么就不需要考虑项目之间的横向比较了。
另外我要反问：为什么非要用这样的方式来作项目之间的横向比较？有什么好处？国外优秀的软件开发工作室就不会做这样无聊的事情，软件开发可能是人类最厉害的智力活动，你觉得一定能量化度量吗？

    要从本质上提升估算水平，你不太可能用几天时间去突击学习某种估算办法就能胜任项目实际的估算工作。
提高估算能力靠你长期的积累，你的实力、你的项目团队的综合实力，还有你们公司的综合实力，决定了估算的水平！

    估算是为项目服务的，后文你会看到如何利用估算来管理项目，又如何因应项目实际情况来更新估算。
下面开始，我们将讲述估算与计划的关系、计划及计划跟踪。

   计划有什么内容？

      关于项目计划，我们要先讨论什么是正确的事情，然后再讨论如何做正确的事情，我们先来看看项目计划应该有什么内容？

      让大家做项目计划，很多人以为用Project做一份开发进度计划就完事了。而项目的开发工作只是占了项目工作的其中一部分而已，跟项目所有相关的工作，我们都需要计划。诸如开发计划、测试计划、培训计划、沟通计划、采购计划等等，这些计划的集合，我们称之为项目计划。一般来说项目计划有一个主计划，多个子计划。主计划总体描述项目的背景、管理目标、任务概述等总体信息，而子计划则有测试计划、实施计划、培训计划、配置管理计划等。

      下图是主计划目录示例：

下面是进度计划示例：

      该进度计划按版本来组织任务，而每个版本则按照项目管理、需求、设计、开发、测试、发布、实施来组织任务。

      也会有些公司会将所有计划集成一个大计划，计划的组织和表达方式并没有固定方式，上述示例图也只是仅供参考。

      上面讲了很多项目计划的内容，其实我们只是需要想清楚为什么要做计划，你就会知道项目计划应该有什么内容。
项目计划的几个重要目的：
      1.明确项目人员、各人职责。（当然这可能会在立项通知书中明确。）
      2.明确完成项目所需要的各种资源。
      3.确定项目在成本、进度、质量方面的管理目标。
      4.明确项目的各种工作产品。
      5.落实各项工作安排，保证项目成功。

      计划是如何做出来的？

      一、要站在战略的高度。

      有时候我会问项目经理这样的问题：
      1.项目预算是多少？（注意前文提到的预算与估算的差别哦，预算是指公司打算花多少钱做这个项目。）
      2.合同要求在什么时候验收？
      3.验收一次进行还是分初验、终验？
      有些项目经理答不出了，他们没有去关注合同中的要点，也没有向高层取得项目的战略指示。

      一般情况下，在项目初期，你应该搞清楚这些战略层面的内容：
      1.合同价钱是多少，公司打算赚多少钱？
      2.公司为什么要做这个项目？想赚钱？想维持客户关系？想积累业务和技术？本项目是公司战略的其中一步？
      3.项目的工期要求。
      4.项目的验收办法、验收标准。
      5.项目是如何收款的，客户每次的付款条件是什么？
      你可以通过看合同，向公司高层请示，了解到这些关键信息。当然很多公司合同是保密的，你可能无法直接看到合同，但你可以直接问高层领导嘛，尽量获取上述关键信息。做项目就像打仗，秦国名将白起没有一次败仗，主要是因为他每次打仗之前，都会处在战略高度来审视国与国之间的大势。你要做好项目，先要把握项目的大势！

      二、明确计划的“输入”。

      要做好计划，你还需要了解清楚以下内容：
      1.系统的需求。通常需求是不明确的，能明确多少算多少，同时你需要有计划地去搞清楚。
      2.系统的设计。通常设计也是不明确的，你需要安排很多前期技术研究。
      3.项目组当前的能力情况。
      4.为成功完成项目，项目组还需提升哪些知识和技能。

      以上这些内容，是项目计划的“输入”，良好的输入是优质计划的基本保证。

      三、用估算来控制计划，由计划来调整估算。

      估算如果做得好，其实计划就完成大部分了，你需要利用估算来指导计划。为了说明“估算指导计划”，下面我会虚拟一个例子。某项目估计完工需要1000人日的工作量，其估算明细如下：
      1.项目管理150人日。
      2.需求150人日。
      3.设计150人日。
      4.编码250人日
      5.测试100人日。
      6.实施200人日。

      根据估算，你安排了详细的进度计划，进度计划中的各任务可以分为六类：项目管理、需求、设计、编码、测试、实施。请注意每一类工作量的总和，不能超过对应的估算，你需要用各子估算来控制这六类子任务。不少项目在安排具体进度计划时，忘记做这个检查，有时候进度计划的总工时没有超出预算，但可能编码方面的任务已经超出了编码的预算了。在具体计划时，往往会发现估算时遗漏考虑的内容，这时很有可能实际计划的总工时会超出估算，或者是某类别的工时超出相应的子估算。这是很正常的事情，项目组对项目的认识是逐步深入的，不太可能在估算时就100%考虑周到。遇到这样的情况，我们通常这样处理：如果仅是某类别工时超出相应的子估算，如果能从别的子估算挪一点过来“补数”，而总估算不受影响，则不需要申请估算调整；但如果总估算受到影响，则需要申请变更估算。前文讲述估算时提到，会因为需求不能全部明确、设计也不能全部明确，估算往往不能一次完成，这时只需要估算能估算的部分就可以了。但我们需要随着项目的开展，认识的加深，持续更新估算。估算与计划的关系是：估算指导计划，计划反过来促进估算更新。

      四、制定可执行可检查的进度计划。

      具体工作任务的制定是很讲技巧的，如何做到“可执行可检查”是关键，下面是制定进度计划的一些技巧：
      1.每个任务的时长不要超过5天。
      我们公司的项目，任务时长往往是在两三天内。
      2.任务只有完成与未完成两种状态。
      所谓任务完成90%之类的说法是不靠谱，任务应该足够细分，不要安排周期长的任务，这样能更好控制项目进展。
      3.每个任务都有可供检查的工作产物。
      不要笼统安排“研究什么什么技术点”之类的任务，必须明确工作产物，如：研究某某技术点，编写研究报告，提交演示程序。而任务完成标准就是：这些工作产物能达到期望的要求。
      4.一个任务一个人负责。
      一般不要安排类似“小甲与小乙共同完成某设计文档”之类的工作，多人同时负责一个事情，效率会很低，效果也不太好。
      尽管实际工作中有可能需要多人同时做一个事情，你可以：
      1）再次将任务分解，落实到具体的人头上，如上述任务可以分解为两个任务：小甲完成设计文档的章节1、2、3，小乙完成章节4、5、6。
      2）如果任务实在不好再分解，就只安排一个人去做。
      在我们公司，一般只有评审任务是多人参与的，别的任务都会落实到具体的人头上。

      五、细化近期计划，定下远期计划大节点。

      我曾经负责一个房地产公司的成本管理系统，当时需求还没有全部明确、技术也很不成熟，就被要求做出该项目的全部详细计划。我当时很郁闷，一个月后某一天谁干什么的事情也要计划出来吗？我只能明确近期一两周的具体工作，而远期的工作我只能定出大概，以后的事情可变因素太多，现在写出所谓具体工作，其实是毫无价值的，浪费时间。

      近期两周内的工作能明确的工作，必须按照上述第四点的要求制定详细的明确的可执行的可检查的任务，而对于将来的工作，则需要定出关键节点，如什么时候发布什么版本，什么时候验收。

      六、让项目组各成员详细计划自己的工作。

      在项目经理主持下，项目组全体共同来制定进度计划框架，明确任务的先后关系。而对于每个人的具体任务，则可以在项目经理的指导下，由每个人自己来确定。
项目组由项目管理、需求、设计、编码、测试、实施等各专业人才组成，每个人承担起自己专业方面的管理工作，项目管理其实是项目组成员每个人的事情，不是只由项目经理一个人来负责。

      七、持续更新计划。

      计划不是死的，是活的！项目计划不是一次成型就固定不变的，项目组需要持续更新计划细化计划，要随时保证近期的任务都已经明确，而远期的任务如果能明确也应当尽量明确。任何项目组成员都可以发起计划更新，项目经理要推动大家管理好自己工作，让大家主动更新计划。

      这里要谈谈计划变更问题，谈到计划变更很多人会“闻虎色变”，我们先要看看看什么叫“计划变更”？
      “计划变更”要与“计划调整和细化”区别开来，调整和细化是指根据实际情况，不断的适时地去修改计划。任务微调是很经常和很正常的时间，某某任务稍微延长一天，某某任务比计划提早一天完成，某项目组成员请假等影响因素，都需要我们去调整计划。与此同时，我们应当不断去细化中远期的任务，至少要一直保证近期的任务都是明细化的。
      而计划变更是指，项目关键节点受到影响的重大变化，关键节点一般有：需求规格说明书通过评审的时间点、版本发布时间点、验收时间点等。这些关键节点的变化，会影响合同条款的履行，会影响公司的战略规划。通常是因为内因或外因导致计划变更，内因一般有：遗漏重要需求、软件设计出现重大失误、代码质量不过关；而外因一般有：客户的需求变更，客户未能做好项目上线准备，第三方未能及时完成相关工作（如：硬件提供商未能及时发货）。
      在我们公司，计划调整和细化只需要项目组内达成一致便可，而计划变更则需要报高层审批。

作者: sunny 时间: 2013-10-10 07:48
估算的准确性依赖于数据的积累及经验的累积。好文章收藏！

作者: 会飞的鱼 时间: 2013-11-29 16:50
有收获，赞~

作者: 粑粑 时间: 2014-5-30 16:50
看了LZ的帖子，我只想说一句很好很强大！

作者: 年华似流水 时间: 2014-10-26 09:52
以我的经验来看，楼主的想法是可以执行的~

作者: 枫叶112 时间: 2016-9-1 21:05
好帖是需要鼓励的~

作者: 笑淡了就罢@ 时间: 2016-10-18 10:14
我了个去，顶了

作者: 霾忆 时间: 2017-7-19 22:21
very good.

作者: 樱花祭. 时间: 2018-2-21 21:14
顶不错支持下

作者: 纯如小白 时间: 2018-7-25 11:30
以我的经验来看，楼主的想法是可以执行的~

作者: 勇爱 时间: 2019-2-11 08:17
路过的帮顶

欢迎光临思步网 (http://www.step365.com/)