在这样一个数字化的时代，决策的实时程度是决定企业响应力高低的关键。因为争吵不休、决策过程过于拖沓而错失良机的案例屡见不鲜。在IT组织中，随着交付团队敏捷与精益化的深入，对于业务决策效率的诟病与日俱增。
一、业务决策中的常见场景
场景1： 众多项目难以开始、决策周期长、讨论范围大（V记）
团队相当长一段时间没有项目可做，开发团队之间因为寥寥无几可以开始的项目而相互争抢。几次客户的产品负责人来武汉出差，给团队展示的一个项目机会Spread Sheet，里面堆满了项目，花花绿绿的颜色代表着优先级、时间表、估算等等，然而客户走后还是没有可以开始的项目。在此期间充斥着包括业务、技术、市场部门的人反复长时间的讨论。团队因为没有真正可以做的项目而士气低落，客户的管理人员为了提升交付团队的工作饱和度而安排一些并非有价值的工作，导致双方信任度大幅降低。最后：
- 有的项目真的开始了，一定是最有价值的项目吗？
- 有的项目开始了，但是没多久又终止了
- 有的项目没有开始，还是堆积在那张满满的Spreadsheet里，过一段时间又被拿出来长时间讨论
场景2：项目源源不断、交错并行、交付不断推迟（H记）
与场景1情况不同的是，H记风控部门，当前交付团队忙的不可开交。
每个Component“团队”有好几个成员，好几个项目在并行开发，每个项目上少则一个人，多则几个人。一个团队成员同时承担多个项目，一会儿做A，一会儿做B，一会儿做C，每天在好几个项目之间的切换，开各种会。每个项目要真正给终端用户带来价值，需要好几个component集成，但是这个项目在不同component团队之间的优先级各不相同。产品负责人员每天开会就是跟踪进度，发现进度慢，就在项目立项之初增加项目个数，意在保证最后能有几个项目可以按时交付。结果可想而知，交付团队疲于奔命，业务团队也不满意产品的质量和进度。交付抱怨资源不足，需要增加人员，业务觉得钱花得不值。曾经一个团队负责人展示给我一个Spread sheet，里面有70多个项目已经排定优先级等待交付团队完成。
二、问题在哪里？
此刻，读者的脑子里可能已经闪现出了很多问题，其中一个非常值得讨论的是，在进入交付之前，产品负责人到底如何做业务决策？采用什么样的决策模型？
传统的方式是，产品（业务）部门通过主动或者被动方式收集到来自于各个渠道的需求后，将所有机会点集合起来，然后组织业务提出方、交付团队以及财务等决策人员放在一起讨论，有些公司甚至在项目交付开始之前都没有邀请交付团队代表出席业务决策。他们讨论的内容涵盖大家熟知的传统项目管理铁三角- “Scope-Cost-Time”，具体讨论可能如下：
- Scope - 只有确定项目大致范围，才能做决策。比如V记的做法是，对于机会点设计几个Gate，在到达每个Gate之前采用T-Shirt Size的方式+一定百分比的误差。当然这个过程中还需要考虑的因素很多，比如技术风险，哪些地方需要第三方来做，哪些地方自己集成。在H记，面临的挑战是业务团队每个人负责一堆项目，大家各自为战，对接不同交付团队，项目独立又相互依赖，迟迟不能就Scope达成一致。
- Cost - 这是非常复杂的部分，因为成本涉及到好些因素，特别是项目大小，比如V记的做法是将项目估计出来的故事点对应一定量的产品开发cost；然后来跟掌握投资的部门以及财务部门argue；比如一个story point交付成本是$6000 AUD，来初步估计cost。
- Time - 这是争论无休止的地方，也是交付团队跟业务之间的关键矛盾点，因为涉及到交付团队对于时间的承诺。
根据Black Swan Farming的案例，在以上决策过程中，一个Feature从有想法到最终交付上线的平均时间是46周，而其中的等待时间是38周。
诚然，在产品机会点管理与决策过程中要考虑的因素还远远不止于此，但结果是文章一开头出现的两个典型场景。除此之外，在日常工作中，产品负责人需要不断回答类似如下的问题：
- 是否应该花额外的钱来加速某个项目？
- 是否应该增加新的功能来推迟项目上线？
- 是否应该在这个项目上增加人手？
- 是否应该将项目X的优先级提升到项目Y之上？
三、常见的业务决策工具
所谓的业务决策，落实到最后是在不同机会点之间（或者呈现为项目）对比然后做出选择。常见的业务决策人员决策雷达上的工具有：
- MoSCoW（Must, Should, Could, Won't）
- HiPPO（Highest Paid Person’s Opinion）
- ROI（投资回报率）
- Benefit-Cost Ratio（收益成本率）
- Kanban Class of Service（看板方法的服务等级）
大家可以尝试对如下场景做出选择，有如下两个供应商可以完成一个项目：
供应商A：Cost - 100K，Time - 10W
供应商B：Cost - 50K, Time - 20W
- 场景1. 项目功能都是“Must Haves“，选择A或者B？
- 场景2. 项目的ROI是300%，选择A还是B？
- 场景3. 项目的Benefit of Cost Ratio是4.6，选择A还是B？
- 场景4. 项目的Class of Service是Expedite，选择A还是B？
你会发现，基于以上的示例决策过程中有两个问题：
- 难以做出选择。比如场景1，都是Must Have则选谁都可以？到底是选总成本少的呢？还是选时间短的？场景2，投资回报率高，那是不是应该选B？因为B的成本低，可以通过低成本获得高回报，但问题在于没有考虑时间成本，也就是机会成本。其本质在于，没有考虑紧迫性以及价值随着时间的变化带来的成本。
- 有些模式太过于靠直觉。比如MoSCoW法则，在讨论过程中很容易跟HiPPO结合到一起，无论之前的分析考虑了多少因素，最终很有可能落到公司内部位高权重的人拍板，靠直觉和经验做了决定。
四、延迟成本（Cost of Delay）
延迟成本是如果一个产品（机会点、项目）因为延迟而给组织带来的成本（金钱）。它是衡量的是推迟做一件事情的损失随着时间的变化，从而可以衡量这件事情的紧迫性，它是一个可以量化的经济学概念。
图1. CoD兼顾了价值和紧迫性的度量（图片来自于网络）
例1：一个项目在时间点X发布，或者推迟到时间点Y发布，因为这个推迟的时间段而带来的利益损失就是延迟成本。最终的表示方式会基于一定的时间单位，比如月，周，天。比如CoD是$1000/Day，其中金钱描述价值损失，时间单位用于描述紧迫性。
例2：一个相对具体的例子（如下图2，图3所示），模拟的是一个完整的产品生命周期中的成本与收益。
图2. 按时发布产品，成本与利润（图片来自于网络）
图3. 推迟一个季度发布，成本与利润（图片来自于网络）
图2展示的是一款产品的完整生命周期，红色部分代表成本，绿色部分代表的是利润。产品在Q2（Product to Luanch）结束上线，Q3结束开始带来利润，最终Cost是8M，Profit是35M。
图3展示的是如果因为种种原因不得不延迟一个季度发布。成本是一样的，只不多一个月来分摊，但是因为上线晚，导致销售量受到而影响（错失了销售机会），最终Cost是8M，Profit是24M，所以CoD是35-24=11M。当然这个11M可以分摊计算到某个时间单位上，比如季度、月或者天。
值得一提的是，CoD被“The Principles of Product Development Flow: Second Generation Lean Product”一书作者Donald Reinertsen认为它是产品决策的金钥匙，如下所述：
Cost of Delay is a metric you must know to make decisions based on economic loss or gain.
五、延迟成本（Cost of Delay）与EDGE
EDGE（ThoughtWorks提出的“聚焦价值的投资组合管理”）里面提到了基于三条水平线的机会点管理方式，基于价值度量来做业务决策。在业务专题优先级排定的时，通过延迟成本这样一个可以量化的经济模型来帮助提升业务决策的效率，最终让产品的交付聚焦在高价值机会点上，从而尽量避免以上两种场景中的问题。或者换一个角度说，在聚焦价值的精益交付模式下，我们需要一个有效的业务决策模型，让决策参与者能够快速依据这个模型达成一致，快速试错、及时反馈、不断学习并调整方向，从而在这样一个充满不确定性的环境中保证产品能够成功，CoD分析是值得尝试的方式。
图4. EDGE里面第3步，使用CoD来决定专题优先级
量化延迟成本其价值在于：
- 一个可以量化的经济学模型，本身是中立的，容易被多方接受
- 聚焦到具体的经济损失或者收益上，考虑的是价值和紧迫性两个维度
- 用数据决策，而不是依靠直觉决策
- 特别是对于传统企业中的决策人员，他们对于一个具有经济意义的5. 数字更加敏感，更容易达成一致
- 基于数学的计算，便于及时更新，可视化
后续话题
- 如何估算一个项目的延迟成本
- 延迟成本如何在决策中起作用
- 产品研发过程中需要考虑的相关其他经济因素有哪些
