作为产品经理，对于工作量评估的工作内容也是要了解的，下面文章中笔者分享了关于工作量评估的四种方法的相关内容，大家一起来看看，学一学叭！
原本，工作量评估更多是项目经理或技术经理需要做的工作，但随着产品经理在团队内的成长，越来越多的产品经理需要参与到售前，或者项目管理的工作中，自然而然会遇到工作量（工期、费用预估、合同报价、产品定价）相关工作。
另外，最近大家都在做产品的年度规划，如果做完规划后，领导问我们大概投入多少钱，需要多少人，做多长时间？类似于这样的问题，我们应该如何回答？这也用到了工作量评估的方法。
所以本文结合我过去几年的工作经验总结常见的四种工作量评估方法，希望对你有帮助。
功能拆解法，顾名思义，先将要做的系统功能拆解为可评估的颗粒度，一般我习惯拆到三级或四级功能，这样更有迹可循。
比如很多人会问，做一个XX系统需要多少钱？这个问题没办法回答，因为没有功能边界。
所以我们可以先试着拆第一级功能，即这个平台分为几个应用？
以HRSaaS平台为例，假设我们需要完成四个应用，分别是PC端、微信小程序端、微信公众号端（或APP端）、平台的运营管理端。然后再为每个应用拆分二级功能。
比如pc端是功能最多的，包含了登录注册、人事管理、岗位职级管理、薪酬管理、绩效管理、流程管理、可视化报表等功能。
然后再拆三级功能，如人事管理包含了入职、转正、调岗、离职，每个功能都包含查询、单笔添加、批量导入、批量导出、数据权限控制这几个简单的页面。
这样人事管理这个模块被我们拆成了四级功能，而且每个功能包含前端开发、后端开发、测试三个维度的工作量。
当然，有些功能是纯后台的开发逻辑，这些很容易被工作量评估者遗漏，比如一些批量处理的定时任务。
之后按照经验，或者很多评估公司会使用一些计算公式来罗列各个功能所需时间。
“按照经验”说简单也简单，对于有经验的人来说，大致可以估出来一个功能需要几天，但对于没有经验的同学，就需要找开发请教，或者查看之前类似功能的开发周期。
按照公式一般会将每个功能区分不同的级别，比如难、中、易。或者很多公司会使用难度系数，不同的级别/系数，对应不同的工作时间。
最后逐一列完所有三级或四级功能的难易程度之后，把天数加总起来。
这个过程就是最简单的功能拆解法，但里面会涉及到两个问题：
所以说，工作量评估最终的结果，并非仅仅按照功能拆分法的结果而来，更多是多种方法的结合，因此，关于这两个问题，文末会详细说明。
功能拆分法的关键，就在于功能拆解的颗粒度是否足够细致。
这个“足够”很难量化，不同规模、不同复杂度的系统会有很多差异，核心要素是既能让自己可以明确做这个功能所涉及的大体功能清单，又不能过于细致（比如具体到按钮级别、字段级别，那样就太繁琐且低效了）。
人月法，顾名思义，就是评估几个人做几个月，然后根据人月单价换算成最终的费用。
但是预估人月时，其实更多也是靠经验，虽然人月单价都会区分人员级别（如初级、中级、高级、资深等），但作为“事前”评估时，张三做这件事大致花几个月，就需要“拍脑袋”了。
市场上很多人月法都是在人力外包的场景下使用的，而且是先用人，后付钱。这样相当于“按实际使用情况”付费。
但也有很多时候需要在使用前大致估算，甲方说：你们派几个人来，工期多久？假设是派遣3个人，做3个月，那就可以初步评估成本为9人月。
如果甲乙双方的合作方式为人力外包，那么这9个人月就基本包含了甲方需要支付的所有费用。
如果甲乙双方的合作方式为项目合作，那么这9个人月可能只是“实施成本”或者叫做“交付成本”，整个项目报价中，还会包含产品费、其他增值服务费等。
这就是简单的人月法评估价格，但具体操作的时候，又会基于不同的客户关系、合作模式、业务预期等因素，对人月进行调整。
实际上，在真实的乙方向甲方进行项目报价时，乙方基本都会问一句：咱们这个项目的预算大概多少？预算是多少，那报价就不能超过这个数，这是最简单的工作量估算方法，也可以叫“倒推法”。
如果是单一来源，或者乙方能够控住招标局势，那么比预算价格略低一点，即可作为成交价，之后再根据成交金额通过人月法、功能拆解法来评估投入多少人，做多少事。
如果是正常投标，可能中标额会在预算的85%左右，如果是多家公司激烈厮杀，最终成交价就不好猜了。
假设一款产品正常做完需要300万，但甲方预算只有150万，最终成交价格是120万，那对于乙方来说，这个项目能做吗？
大多数答案是，咬着后槽牙说：太能了！
因为一些辅助类功能可以不做，一些复杂功能可以简单化，一款产品的定制化交付过程，几个月甚至几年的时间，里面可辗转腾挪的内容还是蛮多的。
（所以说，很多大企业的外包项目做完之后用不起来，上线即结束，原因之一也就猜出来了）
除非，甲方很清楚自己要什么，就是要花一半的钱买全量的产品，这时要不要做，就要斟酌一下了。但据我了解，大部分企业依然会一咬牙一跺脚，把工作接下来。
因为，如果你不做，竞对就做了，自己少了一个案例，竞对多了一个案例。而且，自己的人员成本支出是固定的，却少了一个项目的营收。
所以，紧贴预算法，也体现了乙方公司的困境。
最后则是一个更加简单粗暴的方式，此方式适合“垄断竞争市场”（在某产品市场中，许多厂商在市场中销售有差别的同种产品）。
就像几年前我们想做HRSaaS平台，但是不知道定价多少钱，于是就去看了很多类似的SaaS公司的定价规则，之后根据定价来倒推自己的营收。
比如一家100人以内的企业每个月收费30元，一年就是360元。一家100-500人的企业每月收费50元，一年是600元。
假设团队有15人，平均月薪1.5万，每年的人员成本（不包含管理成本和其他社保、福利、差旅等支出）就需要270万元，按照上述两类企业规模1:1计算，则各需要将近3000家客户付费。
再算上营销优惠之类的，每年需要至少6000家企业客户，才能保证自己不亏钱。为什么很多企业需要融资，为什么要推出各种优惠套餐？现金流是真的扛不住！
所以，我们参考同业一方面是参考他们的对外价格，另一方面也要评估这个价格对自己意味着什么，也能发掘整个团队整体需要提升的方向在哪里。
是友商的管理效率更高？人员成本更低？用户量更大？还是说有其他的生财之道？
公司与公司之间的差距，从定价上有时也能体现背后的一些隐藏逻辑。
上述四种方法，适用于不同的场景和报价模式。
实际运用中，这些方式更多是相互牵扯、相互影响。
当然，所有的工作量预估，都会涉及“投入产出比”的问题，如何评估本次投入的收益，又是一件难题，本文不再展开。
归根结底，“经验法”也是基于多种方式融合而来，只不过没经验的人缺少很多可量化的决策支撑。
说一下上文提到的那两个问题：
原本我对这个问题只有一个粗浅的观点，并不能达到输出成文的认知，刚巧上个月学数据建模，其中提到了三个词，我发现可以应用到这个问题上。
我们可以将不同水平的开发者大体分为三类分别评估，再通过实际交付过程中的人员水平进行微调。
或者选取一个平均（折中）的水平进行初评估，之后按照不同的系数分为：悲观时间、乐观时间、最可能时间三类，如果我们的计算方法和计算过程偏差不大，最终结果应该以最可能时间为准。
这里多出来的空间，才是交付过程中可辗转腾挪的“底牌”，也是为了为不可控因素留下一些余地，因为但凡需要人参与的事情，都无法完全量化。
我觉得，如果连这部分冗余都没了，那乙方真的很难赚钱了。
最后，还要谈一下复盘和经验积累的重要性。
无论你是否拥有决策权，都可以通过自己的方法评估完工作量之后，和最终这件事做完之后的实际工作量进行对比，从而寻找自己在预估时存在的思维偏差。
这样多做几次之后，随着经验的积累，你可能会知道不同的项目，不同的合作模式，甚至不同的客户，不同的研发团队，在做类似的产品时，工作量应该怎么预估，甚至知道为什么同样的产品和功能范围，在A客户和B客户的交付成本能相差一倍。
只可惜，大部分企业在评估工作量时，更多是“拍脑袋”，并没有一些相对标准或者有迹可循的量化思路。
我觉得，这反而体现了管理上的不完备性，即“靠人管”还是“靠流程和体系”管，这也是不同发展周期下的争论点、变革点。
专栏作家
不想延期，公众号：不想延期，人人都是产品经理专栏作家。半路转行的B端泛金融产品，坚持“以实践验证理论，以输出倒逼成长”的目标。点滴珍贵，重在积累
本文原创发布于人人都是产品经理，未经许可，禁止转载。
题图来自 Unsplash，基于CC0协议。
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。