每个企业都想在项目完成后盈利，但很多企业直到年底才意识到自己做了很多项目，公司却达不到预期，甚至亏损。那么钱去哪了？很多公司不知道为什么，有很多乱账，会造成很严重的后果，特别是在疫情的影响下，环境很恶劣，如果大公司的业务部门亏损，可能会导致业务部门解散；小公司亏损，容易导致公司倒闭；我们能做些什么来确保我们完成的所有项目都是盈利的？
从财务角度来说，为了保证利润，需要合理的估算成本。这样才能在对外签约时合理报价，在内部启动项目前充分评估投入成本，同时在实施过程中适当控制成本，才有可能在项目结束时盈利。
那如何才能准确判断软件项目价值是否值得做呢？这要花多少钱？合同需要多少成本才能盈利？你能清楚的知道钱花在哪里吗？怎么才能控制成本？如何保证项目不仅完成，还能盈利？一系列问题将是本文的主要内容。
固定的、表现良好的硬件项目和工程项目比软件项目更容易预算，因为硬件项目和工程项目是真正可见的对象，BOM结构非常清晰，可以直接转换。比如涉及哪些硬件设备，安装时间多长，调试时间多长，可以用公式计算；而软件项目的评估预算相对复杂，因为软件项目的研发对象是二进制代码产品，其难度和周期不易评估，导致成本评估不佳。不容易评估的成本恰恰占了软件项目成本的最大比例，所以我们把重点放在如何合理评估软件开发的难度和周期上。
研究一个事物，首先要搞清楚研究对象是什么，它的特点是什么，然后再进行分析讨论。因此，在讨论软件项目的预算评估之前，我们还应该了解软件项目的特点。软件R&D一般分为两类，一类是自主研发的新产品；另一类是企业从外部获取订单，完成订单交付项目。本文主要针对订单交付型的软件项目，不讨论自主研发范畴。
图1
1。项目值不值得做？
在讨论项目能不能盈利之前，首先要识别项目靠不靠谱，不靠谱的项目就是一个大坑，成功概率极低，几乎没有盈利。然而，一些企业在没有任何风险评估的情况下就接管了所有项目。这样的企业往往亏多赚少。如果有办法提前预测每个项目能否顺利交付，他们就能尽早规避风险。企业可以根据考核结果调整对项目的资金投入，少投入或不投入，把资金用在刀刃上，更有利于获取利润。
要做到这一点，必须做好风险评估。在这里，我们推荐一个风险评估工具——风险画像工具，它有五个维度，分别是唯一性、不确定性、临时性、跨职能性和转化性。每个维度的得分分别为1、3、5和8。如果项目特征和维度匹配度高，那么，如果匹配度低，那么得分就低。最后，总结五个维度的得分。分数越高，风险越高，越不值得做。分数越低，风险越低，越安全，越值得。如下图
图2
l唯一性是指公司是否做过类似项目？
你有相关经验吗？如果之前没有做过这类项目，最高8分。如果经常做这类项目，可以打1分。如果你有一些相关的经验，但没有全部的经验，你可以打3或5分。可以根据具体项目的匹配度给出具体分数。
l不确定性是指项目需求是否明确？
比如银行委托你的企业开发一个银行APP。该应用程序的主要功能是让最终用户在手机上使用常规的移动支付、查询等功能。如果客户只给出简单的几个字，还有很多功能有待确定，这个项目的不确定性很高，可以给8分。如果客户对同样的需求给出了详细的设计方案和验收标准，这个项目的不确定性很低，可以给一分。
L 临时是指从项目时间的角度来看项目风险。项目期越长，风险越高，项目期越短，风险越低
比如项目周期3年，风险可以打8分，项目持续3个月可以打1分；另外，如果项目刚好过了除夕，风险也高；比如项目虽然持续三个月，但刚好是大年三十。比如一个项目，12月份开工，交付时间在3月底，风险就比较大，因为大年三十会进行组织架构的调整，大年三十之前可能会更换项目接口人和负责人，很有可能因为人员变动而重新开发项目。
l跨职能是指需要协调哪些部门来完成项目，谁来一起完成事情？
如果只有部门内部小组能协调完成工作，跨职能绩效很低，可以打1分。如果全集团或全公司所有部门都参与，跨职能绩效很高，可以打8分。
l转型是指项目的影响范围
如果项目实施后只有一个群体受到影响，那么创新很低，可以打1分；如果项目实施后整个集团都受到影响，创新性很高，可以打8分。
把最后五个维度的分数加起来，看分数。分数低风险就低，分数高风险就高。比如5分的话，风险最低。这样的项目基本无风险，成功概率大，项目几乎是稳赚不赔。如果分数是40，风险很大。基本上这样的项目风险很大，失败概率很大。这样的项目做不出来，就尽量不做。
二。如何做好预算？
当我们评估风险，筛选出优质项目后，接下来要做的就是做好项目预算。一般订单配送软件项目的资金流是投入资金，然后消耗资金，项目结束会产生盈亏。如下图3所示，我们可以看到，要想获得盈余，必须做好前两个环节。第一个环节是准确评估预算，确定做项目要花多少钱，是否有足够的成本做项目。如果评估乐观，申请成本过低，很可能因资金不足导致后续工作无法按项目计划进行，导致项目延期，最终项目无法盈利；如果评估太悲观，申请的预算太大，项目可能还没开始就被公司高层叫停，本来可以盈利的项目就夭折了。第二步，控制成本。只有成本控制好了，成本才不会增加，在最终客户按时付款，没有返工，项目才有盈利的预期效果。
图3
当要求在签订合同前较短的时间内给出预算费用时，项目预算通常有三种方法。一是参考历史项目做预算，二是参考同行报价做预算，三是自行组织专家审核预算。
图4
1。参考历史项目做预算，就是看自己公司有没有做过类似的项目，或者能不能通过一些渠道获得类似的项目经验。如果做过类似的项目，可以用历史项目的预算作为参考基准。当项目难度偏差不大时，预算应该差不多。如果差别很大，那么就要加一定比例。这是为了参考项目的历史经验来制定预算。
图5
2。参考同行报价做预算，就是要求同行给我们报价，我们参考同行报价做预算。通常情况下，我们可以通过打电话来询问同行。一般我们假装是客户就可以给同行打电话，他们会给你报价。
图6
3.专家评审和预算是指找到一些资深同事，问他们需要为这个项目做些什么。这要花多少钱？让专家给建议。
图7
我们通过以上三种方法中的一种或混合方法得到一些预算数据，然后用三点估计法得到最可靠的预算值。
什么是三分估计？这是项目管理中常用的方法。三点预估为(最乐观预算+4倍最可能预算+最后一次悲观预算)/6。比如做一个项目，最乐观的预算是300万，最可能的预算是600万，悲观的预算是1000万。那么三点估算就是(300+4*600+1000)/6大概是617万，把这个值作为预算成本。
图8
以上是预算值紧迫时常用的粗粒度评估方法。当我们有足够的时间时，除了以上三种方法，还有更靠谱的方法——基于项目功能点评估预算的方法。在了解基于功能点的评估和预算方法之前，我们先来了解一下软件项目成本的基本构成，主要由直接成本和间接成本构成。
图9
直接成本主要由人工成本+非人工成本构成，主要是人员投入的成本。非人工成本主要包括差旅费、通讯费、招待费、场地费、采购服务费、分包费、软硬件费用等。具体哪些费用要根据项目的实际情况来确定。
图10
间接费用，主要包括分摊水电费、R&D设备折旧、分摊前后的运营费用、其他费用。
图11
在所有费用中，人工成本往往占到80%以上，因此如何准确评估人工成本就显得非常重要。评估人工成本的主要方法是从高级方案入手，然后用WBS对高级方案进行拆分得到具体的功能点，再根据功能量的基线评估功能点的工作量，最后结合项目路标的交付情况得到预计工作量。
举个例子
[项目背景]
制造商接受了一个海外大客户的订单，该客户对产品质量有很高的要求，包括两个要求。
1.记录产品生产过程中每道工序的负责时间和负责人，通过那条流水线记录当时的测试数据。
2.扫描或输入条形码，可以直观地显示整个生产过程的数据信息(包括测试数据)。
现在是2月，希望11月能部分测试，12月能全面测试。做这样一个项目，我们需要预算成本。
[预算评估流程]
1。首先，要求分析师/产品经理/架构师根据项目客户给出的项目信息，撰写一份高层方案。
图12
高层项目方案从用户的角度将客户需求实例化，图形化展示，模块化。
图13
2。根据高层方案再次分解函数。例如，高层方案的一个功能是支持站数据采集，可以分解为站基础设置和设备设置。将所有高层方案功能拆分成详细功能后，可以通过工作量基线库计算出开发所需的工作量，然后根据工作量换算成相应的人力成本预算。
图14
3。工作量评估
很多企业会对工作量评估感到困惑。通常情况下，估计的工作量和实际工作之间的差异太大。有什么好的方法可以更准确的评估工作量？
在这里，我给大家分享一下华为的做法。我的部门根据工作量基线库评估工作量。什么是工作负载基线库？工作负载基础可以是系统或excel表。我们的架构师将工作任务分解后，会对照工作量基线库，找到对应工作任务的对应计算方法，来计算工作量。基线库列出了可以开发的所有类型任务的标准工作量。不同的复杂度工作量计算方法不同，复杂度一般分为简单难度、中等难度和复杂难度。
l简单的难度，比如一个javascript或者几个简单的逻辑代码；
l中等难度:如果需要查询数据库，对数据进行处理和转换；
l如果复杂难度需要调用第三方接口，获取数据后，对数据进行处理，然后将数据写回接口。
简单、中等、复杂都有明确的定义，具体描述会在复杂一栏注明，如下图所示。具体计算方法也在工作量一栏中注明。比如简单工作量是1乘以N，中等难度是7乘以N，复杂难度是12乘以N，N是指有多少个这样类似的功能接口。比如实现两个接口，第一个接口是上报文件的数量，第二个接口是上报文件的下载数量。简单难度1*2计算的工作量等于2人日，中等难度7*4计算的工作量等于14人日。根据复杂程度，12*2的工作量等于24人日。
架构师计算新功能开发的工作量，然后计算安全检查的工作量。检查工作量等于新专项开发工作量乘以20%作为本次安全检查工作量，最后增加一个人月版本发布工作量。所谓版本工作量，是指出版时要做的工作的工作量。一般来说，出版包括准备出版材料和走出版申请流程。
工作负载基线库如下:
图15
基线数据库的标准工作量来自实施部门和业务部门的专家评审和历史经验数据。一般每个季度会复习刷新一次。一旦确定，就按照基线数据库的计算方法进行计算。如果有任何歧义，它将等待下一次迭代更新。开发银行主要负责组织、维护和更新。
评估基线库工作量的流程是，首先由业务部门或市场部将外部需求转化为项目需求，然后分配给R&D部门。R&D部门收到需求后，根据基线库进行方案设计和工作量评估，然后参加RAT会议。RAT会议主要评估方案的可行性和工作量是否能被业务部门、实施部门和资金部门接受。建筑师、R&D专家、业务需求者和评估需求工作量的R&D经理参加了这次RAT会议。审核通过后，将正式上报预算。如果没有通过，还会重新审核。下图是需求工作量基线评估的工作流程。
图16
三。如何控制预算？
如果要控制预算，主要是团队控制项目过程，让项目结果与预期一致，这样就不会出现返工，不会出现延误，投入成本也不会超支。项目的控制过程主要集中在控制工期、范围、质量、人员进场和人员流动。要想办法保证项目在工期内完成，就要按质交付，合理安排人员，尽可能保持项目人员的稳定和不流动。
首先，控制工期可以保证成本。因为每天都需要支付员工工资，每拖延一天就会超支一天的成本，所以不要超过期限；
其次，确定范围可以保证工期。控制项目不超出范围。如果超出范围，必然会增加人员投入或延迟交付以满足新增加的交付范围，导致成本增加；
第三，质量保证可以控制成本。交付的内容不符合质量要求，交付不合格，必然返工，严重超支，降低信誉度，损害声誉，应尽量避免质量不达标；
第二，合理的人员可以减少浪费。人员的进入也要注意。如果所有人同时进入项目，可能会有部分人员闲置。比如前期做需求分析的开发人员和测试人员可能不会进场，因为当时方案还没有确定，进场会让开发人员和测试人员无所事事，浪费资源，增加成本。按照R&D计划的节奏合理安排人员进场，如下图所示。
图17
最后，减少人员流动可以降低成本。注意人员的流动，进入项目后尽量避免人员的流动，因为所有的岗位都需要学习成本，需要花时间去了解岗位和项目的任务。人员的流动会增加成本，关键人员岗位的流动也会导致项目的延期和失败，所以人员流动的管理也是一项至关重要的工作。
图18
以上是内部团队的控制。有时候，一个项目的成败，不仅仅是管理好内部的事情，还需要管理好项目的外部人员，才能达到预期的目标。通常项目中要考虑三类人，即用户代表、供应商代表和业务代表。
图19
l用户代表是指提出需求的一方，可以是一个人，也可以是几个人。他代表投资者的利益，他关注产品成本。在固定成本之后，很难再向他们多要一分钱。他关注的是产品的质量，产品能不能用，能不能解决问题。如果问题解决不了或者解决不了，他可能不买单或者对实施者提出更高的要求。他也关心产品什么时候能用。如果过了时间不用，他会不满。
面对用户代表的需求，项目经理应该控制自己对产品质量和交付时间的期望。在质量期望方面，在项目开始前，项目经理应降低用户代表对产品的质量要求。什么功能可以交付，什么不能交付，什么硬件需要客户自己解决，这些都要在项目开始前讨论清楚。在时间预期上，争取多讲R&D时间，给内部团队足够的R&D时间。并且在项目的每个阶段，都要和用户代表确认正在开发的产品是否正确，避免后续返工。
图20
l商务代表他关注的是他代表的是企业方，他关注的是做这个项目的意义，希望通过这个项目获得一定的利润。也许项目是为了赚钱，也许项目是为了占领某个细分市场，也许是为了配合企业的战略目标提升品牌知名度。业务代表往往是一个不关注实现难度或用户想法的人。对他们来说，花钱越少，送货越快越好。
l最后一个代表是供应商代表。供应商代表是指为项目做实事的团队代表。他代表实施者。通常，供应商代表是内部供应商和外部供应商。内部供应商是我们内部的R&D团队，通常是R&D职能团队的部门主管，外部供应商是外部团队。外部团队一般是外包的形式，通常是外包公司的接口人，他们关心的是有没有外部供应商。
用户、业务代表、供应商代表的立场不同，导致关注点不同。如果在项目的考虑中遗漏了一方，整个项目都有可能返工而不满意。比如我们只照顾了这个用户代表和这个业务代表，没有照顾到供应商这边。也许这个项目不能交付。
比如研发一个能登陆月球，并能源源不断地把稀土送回地球的机器人，就能让公司赚得盆满钵满。投资方希望投入1000万元和一年的研发时间来实现这一目标。因为没有经过内部和外部专家的讨论，所以这是一个非常不靠谱的项目，因为实施团队无法登月，也无法把稀土送回去，这显然是一个失败的项目。这个例子有点夸张，但是往往我们的销售同事都是先接了所有的订单，以为可以赚钱，客户也认为可以接受销售开出的价格，就签了项目合同，结果项目失败，就像登月一样，没有和内部实施团队达成一致。因此，三个代表的共识是项目成功的关键。
除了要达成三个代表对项目的共识，还要让整个团队高效运转，减少内耗，这就需要团队的运作阶段。只有健康的阶段才能让项目更高效的运行。应该有强有力的团队执行、基于团队的流程规则和立法以及基于团队的执法监督。下图中的绿框是立法决定项目生死的顶层。黄框是监督和执法。基本上，责任在于监督、协调，以使过程更加严肃和顺利。粉色方框是执行层；
图21
以上简单介绍了如何排兵布阵，如何组建队伍，如何搭建舞台。接下来继续介绍如何打通线程，从流程开始。华为能充分发挥每个人的能力，是因为有完善的流程IPD体系，执行流程很认真，很多企业也有流程，但是流程再好，执行不认真，也是空架子。华为的流程执行过程中有一套认真的审核机制。软件研发的过程从业务部门把项目需求交给R&D部门开始，R&D部门经历了产品分析、架构分析、开发、测试、交付等环节，每一个环节都涉及到交接和评审。如果审核不通过，可以退回到上游环节，如果审核通过，可以继续下一步。每一份报告和结论都是基于共识。下面是软件详细的端到端工作。
图23
图25
图26
图27
环境和流程系统已经完成，项目需求的来源需要控制好。很多问题其实在需求端没有很好的控制。在做项目需求之前，我们应该知道需求的背景是什么。为什么要做这个要求？痛点是什么？与其在我们得到需求的时候直接当搬运工，不如直接去做。而是要多问问题，问为什么要做这个需求，我们做这个需求是为了解决什么问题，有没有替代方案？只有了解了问题的背景，才能给出比较合适的方案。
当你得到需求的时候，你要倾听客户的声音，问为什么。通常，当前客户会给我们带来解决方案和问题。我们应该用专业的角度来鉴别这个解决方案是否是最好的。如果不是最佳方案，就应该提出最佳方案。如果是目前最好的方案，但是我们发现有风险，也要提出风险。
我们不能只是需求的搬运工。对于需求计划，这里是华为的检查表内容，如图28所示。看看需求有没有写清楚背景和好处。如果没有利益，需求背景没有写清楚，可以直接拒绝需求。如果有效益，效益如何衡量，这个也要写清楚。如果利益没有写清楚，这个需求的意义是什么？当需求的背景和好处明确后，我们再来看看需求中涉及的流程。正常流程是怎样的？例外的过程是怎样的？边界范围是什么？最新的特色是什么？你把所有的事情都列出来了吗？该软件的易用性如何？是需要很长的学习成本，还是需要一个一眼就能用的产品？需求计划是否考虑了安全设计？清单的内容就不一一解释了。详情请参考图28。此外，在填写检查表时，必须填写所有必填项。当需求不涉及必选项时，我们只需注明原因。比如一个需求不涉及保存数据到数据库，但是公司要求数据库项是必须的，那么就要写清楚这个需求只是界面操作，不是数据库操作。
图28
要控制好需求，除了以上需求覆盖点外，还要使用核对表，还要注意需求计划不能添加超范围内容、减少内容或镀金，业务流程要合理正确，明确列出需求的受理标准，做好可行性分析，规避风险。
图29
四。钱都去哪了？
前面介绍了准确评估预算和控制成本的方法，这里要介绍的是项目资金的使用。项目进行中，领导想知道每个项目的投资情况或者项目完成后能不能清楚的知道项目的成本是多少？作为项目负责人，你清楚吗？财务不仅要和职能部门挂钩，还要和项目挂钩，甚至要和项目明细挂钩，这样才能清楚地知道项目花了多少钱，花在哪里，项目的哪些方面，怎么做。填制凭证时，需要填写项目及项目明细。如果没有IT系统，可以使用excel进行管理。如果有IT支持，效果会更好。盘点时可以按照核算项目进行盘点，核算项目的粒度可以根据实际控制粒度来确定。比如下面这个例子是按项目粒度控制的，统计时可以按核算项目过滤冠龙科技项目。
图30
最后，回顾过去，本文主要分享了软件预算成本的估算方法、成本控制方法，并介绍了如何将财务与项目联系起来，以方便实时监督和决策。希望能给你一些启发和帮助。内容仅基于个人经验总结，希望大家多多理解不足之处。最后，祝大家做每个项目都能赚大钱。
一、掌握软件项目成本预算、估算方法和成本控制秘籍【干货】
作者简介:
潘吉平先生是IT项目管理资深人士。在IT领域从业17年，获得PMP、ACP、Prince2、NPDP等国际认证，理论功底扎实。曾金蝶是总部R&D人员，军品企业IT总监，环新集团华南区项目总监，华为外部顾问专家，现在还在华为领导海外团队；参与过亿级项目，亲自接手过500万级项目和2000多万级项目，专注于软件产品开发和交付管理，对敏捷管理、受控管理、IPD管理有着深刻独到的理解，从一线到团队负责人有着丰富的实践经验。
校对介绍:
魏颜佳，汉语言文学专业大四学生，现就读于广州华商学院。在校期间，她在文学系勤工俭学中心担任志愿者干部。她策划过多次志愿服务活动，有丰富的活动组织和报告撰写经验。我取得了大学英语四级证书和普通话证书，并通过了初中语文教师资格证的笔试和面试。
