《项目经理指导手册》估算篇
项目管理中估算通常用于成本估算与进度估算。但是我们最常见的还是单个任务的“工时估算”。本篇目的在讲清楚本人对项目中的估算技巧与工具。目的在于将通用的方法与经验进行分享。
一，通用方法:
1.1 Scrum：在我所推行的Scrum敏捷项目管理中，以任务工时举例，估算方式采用的是“斐波那契序数列”的故事点进行估算，简单来说就像衣服的尺码：
大家都知道买衣服的尺码就是如上图，xs，s，m。对应的是一个数列，不是一个线性增长的数字。
同理在估算任务工时的时候，项目组的成员会对任务 进行评估 这个任务的难度是XS号难度（估算点-story points），还是S号难度，还是M号难度？举例来说：是XS号难度，也就是难度较小，那就对应1个小时解决，如果是S难度，难度就是中等偏低那就是3小时完成，依次类推。
这里就会有个问题，那谁来决定他的任务难度是XS？还是S？在Scrum中 叫“扑克牌估算” 每位Scrum Master会有一副估算扑克牌：
扑克牌就是标准的“斐波那契序数列”（即：前两个数相加等于第三个数）
这种方法是为了防止，在项目团队 做工时评估的时候大家不说话，而采用，大家都从扑克牌中抽一张自己对这个需求或者这个任务评估需要的“故事点” （也可以认为是难度，也可以直接是工时。）
此时，先说明第一个问题，评估工时是一个 团队行为，不是一个个人行为。
至于后续的处理，有的人选择取中位数，有的人选择取评价数，也有人采取少数服从多数原则，甚至有的人觉得必须要超过80%的一致性而采取多轮抽牌。处理方法各有不同，我这里比较认可“中位数”。
1.2 PMP：在PMBOK中也详细记录了三种估算方式,即：类比估算、参数估算、三点估算。
1.2.1 类比估算： 即根据历史经验进行类比，比如以前做过一个“微信支付”功能，现在要求新增一个“支付宝支付”功能，这个就具备参考意义，微信支付用了8小时，支付宝支付的评估时间也可以评估8小时。
类比估算是一种粗略的估算方法，有时需根据项目复杂性方面的已知差异进行调整。
类比估算的缺点也很明显，需要历史数据做支撑，如果没有历史数据，则类比估算的可行性不高。
1.2.2 参数估算：其实本质是通过定义个参数模型来程序化的估算方法，利用参数直接的关系类估算，举例来说：一条路100米，5分钟走完。则没分钟要走20米。 如果是1000米，依然5分钟走完，那就需要每分钟走200米。
参数估算的准确性取决于参数模型的成熟度和基础数据的可靠性。
1.2.3 三点估算：也叫Pert法，简单的运用就是两个个公式：
（1）期望时间=（悲观时间+4倍可能的时间+乐观时间）/ 6
(2) 标准差=（悲观-乐观）/6
比如我们刚刚说的Scrum抽完牌之后，就可以使用三点估算来得到一个期望时间。三点估算的运用范围很广，比仅仅可以用来评估工时，还可以用来评估成本、范围、质量甚至是得到某个资源的可能性。这里就要说道三个西格玛数据：
每一个刻度即是一个标准差，在不同的标准差区间内，对应西格玛的值，
这里书面解释起来比较费劲，我们看一个案例题就知道了：
题目：某项目的悲观时间为36天，最可能时间为21天，乐观时间为6天，要求：
(1).计算在16到26天内完成该项目的概率
(2).计算11天到31天完成该项目的概率
(3).计算11到16天内完成该项目的概率
(4).计算11到26天完成该项目的概率
解题思路：
均值：Te=(P+4M+O)/6=(36+21*4+6)/6=21
标准差：b=(P-O)/6=(36-6)/6=5
所以在（21-5，21+5）也就是16天到26天完成的概率为68.3%
在（21-5*2，21+5*2）也就是11天到31天完成的概率为95.5%
由于（11，16）和（26，31）的概率相同，都为13.6%（95.5%-68.3%）/2
所以（11，26）的概率为68.3%+13.6%=81.9%
二、经验之谈。
通用方法中讲的方法是通过系统学习项目管理知识能够知晓的估算工具与方法，但是我们实际工作中的运用，其实没有那么可行。
在过往一年我的工作中，我总结了两种实际可行的估算方法，一种是短效的方法，一种是长效的方法，我称之为：协商法 与 标准法。
2.1 协商法，是短效的方法，非常简单就是协商。项目经理派任务给程序员，就程序员协商工时，整个过程跟买菜卖菜没什么区别，就是讨价还价。
协商是最简单，不过在协商的过程中可能会出现协商不下来的情况，这时可以使用“专家判断”的方式，找到团队中的大神（高工） 下结论，以起到裁判的效果。
过去一年中，协商方法是我们一直沿用的工时评估方式，时间一久，弊端也显现出来了。大致有三点：
（1）项目经理和开发人员一团和气，变成了开发人员说多久就是多久，没有博弈的过程。
（2）项目经理不懂技术，没有和开发人员谈判的能力。
（3）协商评估出来的实际比较粗糙，准确性不高。
目前，我们依然还是采用协商的方式居多，依靠的是各个项目经理自身的项目管理能力。 所以评估的的准确性有高有低。
2.2 标准法，是长效的方法，根据协商法的弊端，我们必须要去思考一种客观的，可量化的工时评估方式。
标准法的就是将功能模块标准化，我举两个案例：
案例一：我们中文在计算机网络的底层是如何传递的？计算机底层都是0和1，我们都知道是要编码。 比如中文的编码方式有GB2312、UTF-8等。 拿UTF-8来说， 用4个字节码来表示一个中文字。对应一下我们的软件系统本身也是用不同的控件来表示一个表单，不同的表单来表示一个流程，不同的流程来表示一个系统。
当然，我们不能简单的理解，做一个文本框需要5分钟，两个文本框就要10分钟。我们要提升一下高度去制定，比如：一个省市区三级联动菜单需要30分钟， 一个国省市区四级联动需要90分钟。 以此进行，将所有组成界面的可能性全部列举，如上面说的一个对接一个微信支付8小时。 将所有存在的可能全部以“编码”的方式建立一张对照表。
当然没有出现过的情况，自然就在对照表中找不到，但是做过了之后，对照表中就会有记录，有点类似1.21中说道的类比估算，只是这个更精细。自然这是一个长期维护与建设的过程。所以这是一个长效的方法。
案例二：我们所在的公司是一家非标离散装配制造。我经常在想一个问题，我们是一家非标企业，既然是非标准化的企业，那我们的对外接订单的时候，工期、成本、利润，是怎么计算的？ 销售在接订单做销售报价的时候是怎么做的？ 我去问过，答案是乱报。所以企业利润这一块往往是事后计算出来的。那么怎么解决这个问题？
我层问过一些有制造业经验的人，答案是建立“企标库” 虽然行业是非标的， 但是企业内部是可以将常见物料标准化，也就是我们所说的“标准件与非标件”。虽然不能将所有的物料都标准化，但是能标准化50%就有50%的准确性，能标准80%就有80%的准确性。 相比拍脑袋乱报，利润的规划能力，控制能力就大大提升了。
反过来想我们的软件开发，也是一个非标准化作业，我们是不是也要建立我们的“企标库”将能标准化的东西标准化，一样准确性则可以大幅度提高。
标准法的弊端也很明显，就是上面说的，是一个长期维护与建设的过程，同时也是一个逐步明细，渐渐清晰的过程。我认为一个软件工时评估的企标库，短则三年，长则五年。所以不见得组织成员、管理者有这样的决心去做这一件事情。
