1、背景
上周因为项目的一个小需求变更跟Purchasing部门和Supplier进行工作量估算讨论，以确定这次需求变更的采购成本。最终大家接受的工作量估算结果如下(有进行数据脱敏):
| 类型 | 描述 | 角色 | 人天 |
|---|---|---|---|
| 产品设计 | 根据需求变更文档，输出产品需求说明书和产品原型图 | 产品经理 | 8 |
| UI设计 | 根据需求说明书和产品原型图，进行UI设计，包括UI标注图和切图 | UI设计师 | 5 |
| 前端开发 | 1、根据新的业务逻辑，进行架构调整 2、具体业务逻辑开发 3、兼容性调试和自测 | 初级前端工程师 | 11 |
| 后端开发 | 1、根据新的业务逻辑，进行架构调整 2、具体业务逻辑开发 3、兼容性调试和自测 | 初级后端工程师 | 11 |
| 测试 | 1、测试用例编写 2、功能性测试 3、非功能性测试 4、集成测试 | 初级测试工程师 | 7 |
| Bug修复 | 1、定位和联调 2、寻找Solution/Workaround并实施 3、复测 | 工程师配合 | 7 |
软件工作量估算是项目经理义不容辞的职责之一，如何做好工作量估算是门科学，也是门艺术。艺术的部分涉及到人情世故和利益分配，这里不做分析。这次博客仅想介绍一些工作量估算的相关概念、方法和实施流程，算是对知识的一种回顾和总结。
2、工作量估算
2.1 相关概念
- 计量单位 |单位|例子|解释|备注 |---|---|---|--- |人时|需要5人时完成需求|需要5个人1小时，或者1个人5小时完成需求|很少用到，太细没必要 |人天|需要5人天完成需求|需要5个人1天，或者1个人5天完成需求|通常1天工作时间为8小时 |人月|需要5人月完成需求|需要5个人1个月，或者1个人5个月完成需求|通常1个月按21或者22个工作日计算
- 工作量估算 估算软件项目所消耗的资源，包括人力和时间，一般用人天、人月的形式来衡量。
工作量估算的意义根据软件开发模式的不同而不同。对于企业自研的软件项目，工作量估算的主要意义是制定项目进度计划，例如, 确定迭代周期和各个版本的交付时间，总之，就是确定各类Milestone。对于外包的项目，工作量估算除了用于制定项目进度计划外，还用于确定采购价格。RFQ发出后，Supplier会依据RFQ进行报价，而评判报价合理性与否的标准则是工作量估算结果。
2.2 WBS估算法
化繁为简，化整为零是WBS工作分解法的精髓 工作量估算的方法蛮多，例如，WBS估算法、代码行估算法和功能点估算法，方法虽然很多，但大都只能束之高阁，很难应用到实践当中。本着学以致用的原则，这篇博客仅介绍最简单实用的WBS估算法。说实话，我也只用到过这种方法，这种方法不一定靠谱，但操作起来十分简单，其他的方法不光看起来不靠谱，而且实施起来也复杂，不用也罢。
工作量估算的依据是项目范围，只有划定好项目范围，才能估算项目时间、人力资源和成本。科普个小知识点，范围可以分为产品范围和项目范围：
- 产品范围指产品的需求范围、功能范围，例如，产品需求文档。
- 项目范围指为了完成需求、功能所需要完成的具体工作，如编码、测试等。
2.2.1 概念
项目是一个整体，如果想要分清项目范围，就要将项目按照一定的原则进行任务分解，再将任务分解成一项项工作，工作分解成日常活动。这就是WBS(Work Breakdown Structure)工作分解结构法。
创建WBS是把项目工作按阶段可交付成果分解成较小的，更易于管理的组成部分的过程。以可交付成果为导向对项目要素进行分组，归纳和定义项目的整个工作范围，每下降一层代表对项目工作的更详细定义。
2.2.2 分解方法
- 按照产品的物理结构
- 按照产品或项目的功能用途
- 按照项目的实施过程
- 按照项目的组织地域分布
2.2.3 分解原则
- 采用树状结构进行分解。
- 分解是从树根一直到树叶的逐级分解。
- 每个任务原则上要求分解到不能再细分为止。
- 对于小项目分解层级一般为4-6级，层级越多越不利于理解和管理。
- 上一节点为下一节点的总和。
- 整体拆解的任务，最终可以支撑总任务的完成。
- 节点最终分解到若干人天的工作量为宜。
- 相同任务只能在WBS的一个树节点上出现，不能出现内容重复的节点。
- 一个树稍节点只能由一个人来完成，一个任务节点也只能由一个人负责，其他人配合。
- 以团队为中心，充分沟通和讨论，相关干系人要参与具体的工作分解活动。
- 集成所有的关键因素，包括临时的里程碑和监控点。
- 所有活动全部定义清楚，能细化到人、时间和资金投入。
- WBS必须和实际工作中的执行方式一致。
3、案例应用
在日常项目管理过程中，要学会分解任务，只有将任务分解得足够细，足够具体，才能统筹全局，精准的安排人力和财力资源，把握项目的进度。针对本文中需求变更的实例进行WBS分解，示意图如下：
工作分解要细化到一定的粒度，保证每个活动可以由一个人若干天内能完成，比如，3个工作日。有了WBS分解结构图，就可以针对每个具体项进行人天估算，然后汇总出总的工作量。
4、结束语
无论是采用WBS分解法估算工作量，还是其他方法，都无法保证估算结果的严格准确。基于这个客观事实，我们在做工作量估算时要预留波动空间，除非项目有严格的时间节点限制，否则要尽量给项目交付留有足够的余地，毕竟需求变更和不可知风险都会随着项目的进程纷至沓来，只有未雨绸缪，才能从容应对。
另外，对于使用Supplier开发的项目，作为甲方项目经理，即要为公司节省开支，尽量降低采购成本，也要为未来的需求变更预留协商空间，如果工作量估算卡的过于严格，那么确实也会打击Supplier的合作积极性，毕竟赚到钱才是商业合作的最大驱动力。要努力在控制成本和维系良好供应商关系之间找到一个合适的平衡点。
学技术，就是学做事；学管理，就是学做人。工作量估算即需要做事的能力，也需要做人的技巧，慢慢体会，慢慢实践，终有所获。
