陈恭打算确认要测量哪些内容，他对马丁说：“我以往只会汇报项目的整体进度，但我们的测量肯定不能只为汇报而存在，在这个项目里，除了整体进度，我们还需要测量更多内容吧。”

马丁说：“是的，为了能够有助于让人了解项目及其绩效和成果的整体情况。我们需要统计多一些的内容，围绕这个目标，我们需要一组平衡的测量标准。通常需要测量的指标包含，可交付物度量指标、交付过程指标、基准绩效指标、资源指标、商业价值指标、干系人指标、预测指标。我依次简单介绍下。”

（一）可交付物与商业价值

“我们这个项目从大的规划上来说，要交付什么？我们的菜多多App怎么样才是成功呢？”马丁提了一个问题。

陈恭回答：“按照以往的项目，如果仅作为项目交付，无非就是三点，交付的东西是否符合计划范围的内容，交付的质量是否符合质量指标，从软件系统的角度来说，无非就是性能、容量等写通用的技术指标。还要参考行业标准，汇报各个阶段的BUG数，以证明交付的质量标准符合行业通常要求。”

“是的，通常会包含以下三点。”马丁继续介绍：

（1）有关错误或缺陷的信息。此测量指标包括缺陷的来源、识别的缺陷数量和已解决的缺陷数量；

（2）绩效测量指标：与系统运行相关的物理或功能属性。比如尺寸、重量、容量、准确度、可靠性、效率和类似的绩效测量指标。

（3）技术绩效测量指标。使用量化的技术绩效测量指标，确保系统组件符合技术要求。比如性能、并发个数、响应速度等。

但是我们的项目并不是来源于精准的设计，而是利用迭代的方式边摸索边实施，而一些技术和性能的指标，跟我们预设的用户数有关系，我们可以选择直接架设云服务器来保证相关的灵活性。所以，我们也没必要现在就考虑未来百万级、千万级甚至亿级访问量的并发指标，所以没必要用上面的绩效测量指标来度量我们的项目。

陈恭说：“我们不是向客户交付，花费的全部是公司的成本，属于公司的战略投资，老板非常关注我们的投入和产出，也希望早一点完成闭环，投入市场。”

马丁说：“作为项目，还是要确保项目可交付物与商业论证和收益实现计划保持一致。也就是说，我们的投入要有商业价值，商业价值也是能够度量的。比如在一些大的里程碑节点，我们要向领导汇报我们的这些商业价值指标，这个会贯穿未来1~2年，因为我们要项目投产后，就要计算商业价值。这些度量指标包括：

（1）成本效益比。用于确定项目的成本是否超过其收益。如果成本高于收益，结果将大于1.0。在这种情况下，除非有监管、社会利益或其他原因来做该项目，否则不应考虑该项目。

（2）与实际收益交付相比的计划收益交付。作为商业论证的一部分，组织可以把价值确定为做该项目将交付的收益。对于预期在项目生命周期内交付收益的项目，测量所交付的收益和这些收益的价值，然后将这些信息与商业论证进行比较，可以提供信息用以证明继续开展项目，或在某些情况下取消项目的合理性。

（3）投资回报率 (ROI)。ROI是一种将财务回报金额与成本相比较的测量指标，它通常是作为开展项目决策的一种输入而开发的。在整个项目生命周期中，可能会在不同时点对ROI进行估算。通过在整个项目期间测量ROI，项目团队可以确定继续投入组织资源是否有意义。

（4）净现值 (NPV)。NPV是一段时间内资本流入的现值与资本流出的现值之差，通常是在决定开展项目时开发的。通过在整个项目期间测量NPV，项目团队可以确定继续投入组织资源是否有意义。

陈恭说：“但是，我们这个App预计要过很久才能盈利，未来在推广的初期，不会首先考虑这些指标吧？”

马丁回答说：“的确是这样，其实互联网公司更多考虑的是运营指标，包括流量指标、转化指标、财务指标、会员指标。这些指标就能够代表我们的商业价值。”

（1）流量指标。对访客进行分析，有潜在需求的消费者产生的流量到达一定基数后，销量才有可能提高。

（2）转化指标。从注册到成交整个过程的数据，帮助提升商品转化率。

（3）财务指标。包含新客成本、单人成本、单笔订单成本、费销比等。

（4）会员指标。包含注册会员数、活跃会员数、活跃会员比率、会员复购率、平均购买次数、会员回购率、会员留存率、会员流失率等。

经过菜多多App的初期建设，时间到了2023年年初，App已经正式推广到市场一个月了，运营团队不断在统计收集这些指标，根据这些指标分析业务经营情况。仅仅上线一个月，他们的注册用户数达到了100万，交易用户数达到了15万，客单价超过了50元，这是一个不错的开局。

（二）基准绩效指标及预测

马丁说：“我知道你说的这套指标。这肯定是你最熟悉的指标，最常见的基准是成本和进度。大多数进度测量指标会根据以下相关的计划绩效来跟踪实际绩效的。”他拿出一张图，为陈恭讲解。

图4-7 基准绩效指标

1.开始日期和完成日期

将实际开始日期与计划开始日期进行比较，并将实际完成日期与计划完成日期进行比较，可以测量工作按计划完成的程度。即使工作不在项目的最长路径（关键路径）上，延迟的开始日期和完成日期也表明项目未按计划执行。

2.人力投入和持续时间

实际人力投入和持续时间与计划人力投入和持续时间相比较，可表明工作量估算和工作所需时间估算是否有效。

3.进度偏差 (SV)

通过查看关键路径上的绩效来确定简单的进度偏差。使用挣值管理时，进度偏差表示为挣值与计划价值之差。

4.进度绩效指数 (SPI)

进度绩效指数是一种挣值管理测量指标，可表明计划工作的执行效率。

常见的成本测量指标包括：

（1）与计划成本相比的实际成本。

此成本测量指标将实际人工或资源的成本与估算成本进行比较。此术语也可称为燃烧率。

（2）成本偏差(CV)。通过比较可交付物的实际成本和估算成本来确定简单的成本偏差。使用挣值管理时，成本偏差表示为挣值与实际成本之差。图4-8显示了一张说明成本偏差的挣值图。

（3）成本绩效指数 (CPI)。一种挣值管理测量指标，可表明相对于工作的预算成本，执行工作的效率。

陈恭疑惑地说：“这些指标在以前的交付项目中，也是偶尔才会具体统计。我们在这个项目中也需要统计这些吗？”

马丁回答说：“我理解你的疑惑，刚才所说的SV、CV、SPI、CPI，这些都是挣值管理方法常用的数据指标。挣值管理通过比较项目计划和项目实际的执行情况，客观地反映项目的现状，并对项目的未来作出预测。项目团队通过预测来考虑未来可能发生的情况，以便他们可以考虑并讨论是否相应地调整计划和项目工作。”

马丁继续解释定量预测定量预测包括：

（1）完工尚需估算 (ETC)：可预测完成所有剩余项目工作的预期成本。一个常见的测量方法是：完工预算减去挣值，然后除以成本绩效指数。

（2）完工估算(EAC）：此挣值管理测量指标可预测完成所有工作的预期总成本。假设过去的绩效可反映未来的绩效，那么一个常见的测量方法是：完工预算除以成本绩效指数。

图4-8 成本偏差的挣值图

挣值管理为组织提供了对项目范围、进度和成本进行集约化管理的方法。在决定项目成败至关重要的问题解决中，它起到了非常关键的作用。这些问题归结如下:

进度是提前还是滞后了、时间的利用率如何、项目可能何时完工、当前的成本是否超支、是否还有结余、资源(人、机、料、环)的利用率如何、未完成的工作预计还需要多少费用和工时、整个项目的生命周期中的总成本等。

在软件外包行业，有时会使用到挣值管理方法。但我们的项目其实不用这么测量，因为从整体来说，我们项目研发范围会根据市场反馈进行调整，难以提前给出非常精准的范围，你可以看图4-9的两个三角形。

图4-9 项目范围

当项目范围是固定的，我们根据范围去测算成本和制订计划时，更适合利用挣值管理方法。而我们的项目的范围是变化的，希望利用现有的项目团队，能够在固定的时间内，制作出能够供市场使用的Demo产品，不适合用挣值管理方法来进行比较频繁的测量和检视。

我们按照迭代来交付项目成果物，每个迭代都会慎重评估当前最优先的需求工作，然后通过不停的迭代交付，持续提高我们团队的综合能力，从而实现项目交付和团队及个人成长的共赢，这是一种良性循环，我们也会按照这个思路来制定绩效测量指标。

而每个迭代的需求就绪与积压情况，也可以用来统计评估团队的绩效、评估需求完成和积压的情况。如表4-8所示。

表4-8 评估指标

（二）交付测量指标与相对估算

马丁继续介绍，我们的团队成员固定，时间又固定，其实项目成本就是固定的，变量就是需求范围了。如果能够提升我们的过程效率，提高项目团队的交付能力，就会提高项目的绩效。所以，我们可以统计以下交付测量指标。

（1）在制品。此测量指标可表明任何特定时间正在处理的工作事项的数量。它用于帮助项目团队将正在进行的工作事项的数量限制到可管理的规模。

（2）提前期。此测量指标可表明从故事或工作块进入待办事项列表到迭代或发布结束的实际消耗时间量。提前期越短，过程越有效，项目团队越富有成效。

（3）周期时间。周期时间与提前期相关，表明项目团队完成任务所需的时间量。周期时间越短，项目团队越富有成效。如果工作用时相对稳定，那么就可以更好地预测未来的工作速度。

（4）队列大小。此测量指标用于跟踪队列中事项的数量，可以将此度量指标与在制品限值进行比较。

利特尔法则 (Little’s Law) 说明，队列大小与事项进入队列的比率和队列中工作事项的完成率成正比。我们可以通过测量在制品，并预测未来的工作完成情况来深入了解完成时间。

（5）批量大小。批量大小可测量预期在一次迭代中完成工作的估算量（人力投入量、故事点等）。

（6）过程效率。过程效率是精益系统中使用的一种优化工作流程的比率。此测量指标可计算增值时间和非增值活动二者的比率。正在等待的任务会增加非增值时间。正在开发或正在核实的任务代表着增值时间。这一比率越高，过程效率越高。

陈恭在不停地消化回顾马丁讲解，他对马丁描述了他的理解：“只要能够确保我们总是做价值最高的需求，我们的交付能力越好，交付速度越快，就说明我们的交付绩效越好。”

马丁回答：“这是一个伴随着项目交付，大家共同持续改进的过程。所以我们要确定我们的基本速率。”

“我们有十几个人，按照人月来说，就是十几个人月。这是最简单粗暴的方法。”陈恭回答。

马丁说：“但是人月有非常不合理的地方，首先人的能力是不同的，资深人员的人月产量，可能是小白的几倍，而且人的能力是会变化提升的。基于人月的估算方式很可能会导致两个极端情况，由于估时太乐观导致项目延期或者估算太保守导致团队空闲，资源利用率降低。”

由于传统估算的弊端很显见，马丁建议陈恭和项目团队引入了另一种实践——相对估算。

“相对估算”是使用“比较”的原则，通过用户故事（story）之间的大小对比进行估算，估算后的结果没有时间单位。

大家可以拿一个大家都了解的以往成绩作为基准，拿新的任务的规模，去和这个成绩作比较，无论是谁来估算，差别不应该很大。

陈恭决定召集大家建立起来团队自己的速度基准。

他找团队沟通，以一个以往做过的页面逻辑作为基准，比较了所有已知任务与这个页面逻辑的工作量倍数，作为估算结果，整理成表4-9。

经过团队共同评估，他们觉得一个迭代周期可以完成40点的需求，就选择了40点的需求作为迭代1的内容。

表4-9 估算结果

在迭代1的过程中，他们发现40点的工作量超过了团队负荷，不但工作日的晚上需要加班，其中的一个周末他们也共同加了1天班，不过还好完成了这些工作。在回顾的时候，大家共同觉得这个规模的任务负荷不具备持续性，而且搜索部分的完成质量并不好，后续还要安排优化，否则会累积质量风险。经过大家一起讨论，大家认为32点的工作负荷比较合适，个于是他们决定为迭代2安排32点的工作。经过迭代2的验证，这个规模刚刚好，于是他们把32点作为团队的迭代速度，并打算逐步改进绩效，逐步升团队的迭代速度。