一、类比估算法：

根据类似的项目工作量进行预估，再对估计值根据具体情况进行调整。

二、参数估算法：

公司可能缺乏这方面的数据支持，比如通过估计某个项目可能会有的代码行数，配备的成员技能，来进行估计。举个例子，某个项目的代码行估计可能会有10000行，一个一般技能的开发工程师一天可以完成的代码行为500行，那么开发需要的时间可能就是20人日。

三、三点估算法：

目的是为了尽量降低估算的不确定性。估算时对一个功能点分别估算最悲观的估算值、最乐观的估算值、最可能的估算值，最后确定的估算值=（最悲观的估算值+最乐观的估算值+4*最可能的估算值)/6

四、delphi法

也称专家调查法，由一组专家对项目进行估算。

具体的步骤为：

组织者发给每位专家一份软件系统的规格说明合一张记录估算值的表格，请专家估算。
专家详细研究软件规格后，对该软件提出最乐观的估算值、最可能的估算值和最悲观的估算值。
组织者对专家表格中的答复进行整理，使用三点估算计算每位专家的平均值。
综合结束后，再组织专家无记名填表格，比较估算偏差，并查找原因。
上述过程重复多次，最终可以获得一个多数专家共识的软件规模。
五、团队估算法：
类似与Delphi法，但是形式比较松散，参与评估的团队成员包括项目组的各个角色，大家一起对某一个功能点提出自己的估计值，如果比较接近则计算一个平均值作为估算值；如果差别比较大，则由每个人发表意见说明自己的评估理由，然后进行第二轮评估， 直到评估值比较接近。

Other

1.如何在需求不明确情况下进行工作量的评估？

给量级的评估，由于需求不明确，所以估计不可能准确，误差很可能比较大。

储备：储备要留足，需求越不明确储备越要多。

先总后分：需求不明确也要有一个限度，项目的整体范围，整体框架还是要确定了才能接手项目的。

接受计划改变的必然性，既然需求不明确，那么计划的改变可能性是非常大的，需要提前和相关各位沟通到位。

2.如何在跨部门情况下进行工作量的评估？

各个部门负责给出自己部分的工作量评估。 有专门的接口人负责协调资源，给出评估结果。

信任，很多时候我们并不了解对方的工作和流程，所以信任很重要。

信任的同时，尽可能多的了解对方的工作内容，积累经验，对未来的判断做准备。

3.如何进行进度计划的安排？

善用网络图，排好关键路径法和关键链法，时间提前量和滞后量。

具体步骤：
首先细分项目的每个功能点，针对功能点制定出我们需要进行的工作。 整理每项工作之间的逻辑关系，形成一个网络图。 评估每项工作的工作量。 安排每项工作对应的负责人。

根据具体负责人以及工作量调整网络图。 安排储备工作时间。

4.排出具体的进度计划需求变更如何处理？

事前：
丑话当先，变更流程还是要有的。

变更流程可以分需求变更的规模，按大、中、小来区别对待，制定不同的流程。

事中：
执行过程中可能需要灵活应对了，对于需求的优先级和紧迫性需要有一个把握。不是不能变，但对流程还是要坚持的，否则乱了只能是自己。如果发布时间不能改变，需求又是一定要完成的，那我们就只能从其他方面来想办法了。这个可以参考六边形。

事后：
对人对事进行总结，未来对于类似的事情，相同的人，我们就需要更多的考虑需求变更的风险了。

5.对于前期需求不明确的项目如何控制需求范围？

前期需求的细节可以不清晰，但是整个项目的大范围需要确定。

项目的整体设计最好不要迭代，或者说不要做迭代的打算，一开始就对整体设计做一个统一的规划。

整体设计完成后，再对每个部分的功能分别来看。划分每个部分的系分功能点，各个功能点之间的优先级，是否需求已经明确，与其他功能点之间是否有关联等。

对已经比较清晰的功能点，并且与其他功能点之间的关联不是非常紧密的，先进行开发、测试。同时细化未清晰的功能点。 对于需求变更的控制重点把控。

这需要看项目经理的全局观，是否能对项目的整体设计，功能点间的关联关系有一个比较到位的把握

项目成本的构成

项目的成本结构从小到大进行逐级汇总，主要包括：活动成本、工作包成本、成本基准、项目总预算、合同总价。

什么是应急储备和管理储备？

应急储备是为应对项目实施时可能出现的估计误差、遗漏和不确定性而事先建立的储备。

一般又分为预算储备和管理储备。其规模取决于项目的“新颖性”、不精确的时间和成本估计、技术问题、范围变动的大小及意料之外的问题。

这种储备通常占项目总预算的1~10个百分点。

项目经理可动用应急储备，但不能动用管理储备，因为管理储备不在项目成本基准之内，若需要动用管理储备，需要走变更流程进行审批。管理储备一般需要高层管理员进行管理和审批。

不管是啥项目，项目在执行过程中都是会存在风险的。风险的分类，可以按照专业、内外、经营关系和已知程度进行分类。
按专业分类：技术风险、组织风险、管理风险、财务风险。
按内外分类：内部风险、外部风险。
按与经营者的关系分类：经营风险、纯风险（自然风险)。
按已知程度分类：已知的已知风险、已知的未知风险、已知的未知风险。

① 已知已知风险：是已经识别并分析过的风险，不仅知道风险类别，还知道其发生慨率和后果，通常根据其风险敞口计入项目直接成本。参考项目风险库

② 已知未知风险：属于已经识别出的风险，但不清楚其发生概率和后果，通常由应急储备来应对。

③ 未知风险：又称未知未知风险，是从未遇到过、完全未知的风险，因此也称作突发风险，只有在实际发生后才能识别、分析的风险。未知风险通常无法预防，只能通过提高项目的韧性来减轻发生的后果通常由管理储备来应对。

业务人员经常会说，在前期工作量也评估了，合同也签了，最后反而最终算利润的时候不赚钱反而赔钱。问题主要出在以下几个方面。

商机阶段的需求一般颗粒度比较粗，研发负责人也仅仅只是进行的需求研发的工作量粗评，常规下有时因为没有叫对应的测试部门，没有把测试阶段的工作量评估出来。

不能以商机阶段对接的需求，就所以然的认为这就是客户端最终需求。此时前期如果有意向进行签单，一定要拿到客户端详细需求。（如果客户提不出来，建议由产品经理进行现场需求调研落实清楚客户到底想要的功能）

没有在签单之前进行有效的风险评估和技术评估，工作量粗评后，业务人员会拿工作量换算成研发成本，在✖️系数对外报价。本以为是可以hold住，但因为没有预留充分的应急储备和管理储备，又在实际项目执行过程中的各种风险无形中把“利润”消磨掉。有可能还会形成赔本的情况。

项目执行过程中，也会因为项目并行执行会造成研发资源和测试资源的过度浪费。

未完待续……