第一篇 延迟成本（Cost of Delay）决策 - I介绍了延迟成本概念以及与EDGE的关系，这篇详细介绍一下如何估算延迟成本以及如何用于产品决策。
一、产品的生命周期与利润
在估算CoD之前我们需要认识一下一个完整生命周期中与产品相关的几个关键经济指标。
图1. 产品生命周期经济指标 - 简化模型 （图片来自于网络）
如图1所示，先看上半部分（X轴 - 时间；Y轴 - 收入）：
- 时间轴之上的绿色部分是收入（Revenue）
- 时间轴之下红色部分为成本，包括： Development expense(开发费用) + COGS (Cost of Goods Sold - 销售成本，由公司出售的货物生产所产生的直接成本)
- Time to Manufacturing: 制造时间，对应软件产品，从有一个idea到开发测试完成，但是没有上线
- Time to Market：上市时间，制造时间+最后发布到产品环境时间，直到用户能够使用
- Break-even Time: 收支平衡时间
- Time to Volume：达到一定销售量的时间（每个企业对于这个Volume的定义不尽相同）
再看下半部分（X轴 - 时间；Y轴 - 利润）：
- Time to Profit：开始产生利润时间
- Total return（Profit）：绿色部分面积是整个产品回报
关键点：
- 产品的销售收入随着时间的推移，会逐渐上升，然后趋于平稳一段时间，最后下降（如图1上半部分绿色曲线）
- CoD其实是在预测周期内潜在Profit损失（Revenue - Cost）
二、估算CoD
需要说明的是，你也许已经注意到了，CoD的值只能算作估算。我们采用月为单位来演示如何估算CoD，一个简单的公式如下：
延迟成本（CoD） = 错失月成本（ Lost Month Cost） + 峰值降低成本（ Peak Reduction Cost）
继续简化上述模型，将一个产品的完整生命周期随着月份的收入简化如下。
图2. 产品完整生命周期 - 延迟一个月带来的延迟成本示例（图片来自于网络）
绿色表示按时发布；红色代表推迟一个月，销售量峰值降低；橙色代表推迟一个月，销售峰值相同。那么绿色与红色，或者绿色与橙色曲线之间的面积差就是产品的延迟成本。
第一步：计算错失月成本（Lost Month Cost）- LMC
图3. Lost Month Cost - 错失月成本 （图片来自网络）
试想一下，产品推迟一个月上线，那么左边的橙色部分向右推移一个月，黄色部分（产品收入开始下降）保持基本不变，也就是说产品的生命周期还是48个月（这部分的假设可以参考Donald Reinertsen的“The Principles of Product Development Flow: Second Generation Lean Product”一书）。延迟成本其中一部分就是延迟发布一个月，销售峰值这个月带来的利润损失，也就是我们要计算的错失月成本-LMC。
这部分的计算就变得很容易了：
错失月成本（LMC） = 峰值月销售量（peak month of volume） * 单位产品利润（profit margin per unit）。
举例：
如果销售峰值月可以售出200单位产品，单位产品利润是
2000 = $400K。
第二步：计算峰值降低成本（Peak Reduction Cost） - PRC
图4. Peak Reduction Cost - 峰值降低成本（图片来自网络）
可以合理的假设，因为推迟一个月，我们的销售峰值会相比于绿色的按时发布线有所降低。那么就会有一部分因为峰值降低带来的成本，面积变小，这就是峰值降低成本，如上图紫色背景文字所指。
一个粗略的计算公式为：
PRC = X%（平均销售量降低率） * 平均每月利润（average monthly profit） *预测月份数（ number ofmonths forecasted）
举例：
比如2%的平均销售降低率，每个月平均销售150个单位产品，那么每个月损失的产品销售量为150 * 2%=3。在未来4年，48个月范围内，我们将售出约3*48 = 144个单位产品。每单位产品的利润率
2000 = $288K。
在计算PRC时，有一个很大的挑战在于人们不太容易对于X%这个值达成一致。显然，产品真正上线之前去预测因为推迟一个月而导致的平均销售降低率的确不太靠谱。所以常见的情况是，这部分成本被忽略了。所幸的是，仅仅计算LMC已经可以作为一个非常有用的决策变量了。
三、CoD如何用于做决策
回到第一篇提出的几个问题，我们尝试用CoD来做一下分析。假设我们每个月的CoD是5K来加速开发从而可以节省1天时间。拍脑袋，你可能觉得是值得的，实际分析情况如何呢？ （在继续阅读之前大家可以自己推算一下）
分析过程：
每月CoD是20K（每月平均工作日算20天，为了计算方便）。如果你愿意花
20K的收入，实际净利润就是
5K的钱你用于投入更多人手，或者用于加速另外一个项目，带来的ROI也许比这个还高，那么你的决策结果显然不同。这意味着，当我们在采用CoD和ROI做决策时，应该是放眼所有项目机会，而不是紧盯单个项目机会。
例2. 是否应该为增加一个新的feature而推迟项目上线？假设我们的新feature能够带来5%的销售量增加，而且推迟一个月上线，并不会带来单位产品成本增加。如何决策？（假设每增加一个百分点带来的利润是$150K）
分析过程：
5个百分点的增加，意味着利润增加400K，如果我们开发这个功能意味着我们得到
100/H * 160H =
750K -
16K =
334K / $16K ~= 21：1 ROI。
问题在于，我们如何确定因为这个feature可以带来5%的销售增加？谁也没法保证。但是有一个点可以考虑，而且可以降低我们的压力，那就是我们能否做到收支平衡。反推一下，这个销售收入提升比率为 $400K/150K = 2.7，也就是说我们能否有信心因为这个feature推迟上线，但是能带来2.7个百分点的销售量增加。这其实就是一场赌博，如果没有信心的话，还是尽早上线吧。
四、可能仍然存在的疑问
即使做了以上分析，我想大家可能还有如下问题：
- 如果不是一个完整的新产品，而是一个项目，我们如何计算CoD？
- 销售收入峰值，单位产品销售利润如何估算？
- 以上举例中，其实有很多假设点，比如例2中，如何预测是5%的销售量增加，以及我们怎么知道因为这个feature的开发，一定是一个月的延迟，而不是更多？
在回答我对于以上3个问题的思考之前，想表达如下几个关键点：
- CoD是一种经济模型，与之相关预测值的获得完全取决于组织里面做决策的人的经验以及能力，比如销售预测，成本预测。如果持续在组织内部去做分析，在得到这些数值的过程中，促使我们更多思考，更利于决策过程中达成一致。既然是预测，的确存在不准确的可能性。关键在于在此模型上，去尽可能寻找可用的数据来做决策，而不是仅仅依靠直觉或者无休无止的讨论。数据驱动决策，这是我们努力的方向。
- 大家可以参考一下另外一个场景，在做Story Estimation过程中，特别是当刚开始的几个迭代，预测误差可能会非常大。如果坚持做，不断调整，那么预测就会更加准确。
- CoD分析，有另外一个促进作用，那就是为了降低CoD的影响，人们会倾向于将大片的工作细分，从而降低风险和影响，促使决策人员考虑产品尽快上线，降低CoD。
回到具体问题：
问题1和2一起考虑，我认为对于机会点的管理，对于产品，还是项目没有本质的区别。重点在于找出针对这个机会点延迟成本计算的关键值。根据上面的描述，关键是计算LMC，针对一款完整的产品就是峰值销售量以及单位产品利润。那么对于一个项目，它可能是基于一款已经上线的产品。
举个例子：
现在基于一款产品要做项目A，它的主要功能是帮助用户记住在产品支付里面使用过的信用卡信息，从而节省用户未来支付时间。那如何计算这样一个项目的CoD呢？
考虑的出发点是如果不做这个项目，带来的潜在收入损失，比如我们以周为单位，可以做如下假设：
每周因为信用卡信息输入和验证带来的时间成本5分钟；（这个数据可以统计）
平均每个活跃用户在产品上每周停留时间是50分钟；（这个数值可以从历史数据中计算）
每100分钟有效停留带来的平均购买值是：$30（这个数值可以从历史数据中计算）
现在每周用户平均支付次数是2次，那么因为这个项目可以节省10分钟有效时间；（这个数值可以从历史数据中计算）
当前活跃用户是10K；
那么每周的CoD是10K*10（节省的10分钟）/100（分钟） * $30 = 30K。
我想说的是，以上的分析是一种思考模式。任何一个机会点的投入，肯定会从某个角度贡献到产品收入上。产品人员可以根据现有数据来合理假设，从而计算出CoD。这里面没有严格按照LMC的计算方式，去假设峰值销售量和单位产品带来的利润。这是产品决策人员可以尝试的思考模式，用数据说话。当然，如果某些数据假设不出来，说明我们在运营产品的时候对这些数据缺失了统计，应该考虑如何获得它们。
问题3，其实关键在于如何提升我们估算的准确性。
请参考这篇文章（Cost of Delay: 8 ways to increase certainty in new product development decisions），作者提出了八种方式用于提高预测的确定性。最终结论是，数据驱动越多，预测模型就越好，其决策就越能带来价值。简而言之，基于数据说话，多尝试，模型也就越来越准确。
五、后续话题
- 产品研发过程中需要考虑的相关其他经济因素
参考文章：
