作者：姚安峰

姚安峰，ThoughtWorks咨询师，08年起开始致力于敏捷的践行和推广，理论与实践跨越敏捷、精益、持续交付和DevOps全流程各领域，帮助各行业客户采纳优秀且与企业环境相适应的管理和技术实践交付高价值、高质量产品，提升创新能力，推动持续改进。主导翻译了著作《精益企业》。

实时战略与动态投资决策

姚安峰 评论

[摘要]

新的机会是不断浮现出来的，任何解决方案都有失败的可能。过度的投资本身就是创新的敌人。企业必须要建立一种更加动态、灵活的投资组合管理方法，来支持进行实验性、快速迭代式的创新过程，以此应对不确定性，成就“以客户为中心、高响应力”的数字化企业。

在今天科技快速发展、每个企业都在畅谈创新的时代，发现机会和产生想法并不太难。我们看到很多雄心勃勃的创新投资计划，包括那些曾经也是从0开始、摸爬滚打一路成长起来的新兴企业，制定了激动人心的目标，投入巨大人力物力，但最后收效甚微，甚至彻底失败。分析其失败原因，往往归结到环境、时机不佳，或人与团队问题。但换个角度思考，这些影响投资成效的问题任何时候都可能存在。对成败有着实质影响的归因，只有在复盘时才得以总结；回归到当时，其实很难对进退取舍做出准确判断。

企业是由一群人构成，并且存在于既定环境当中，任何创新最后的成果是通过人和人之间、企业和环境之间的相互作用产生的，是一个典型的复杂适应系统。霍兰的著作《隐秩序—适应性造就复杂性》系统性地论述了一个观点：

不确定性是任何复杂适应系统的固有特征。

不确定性意味着新的机会是以浮现而非计划的方式出现，同时任何解决方案都有失败的可能，这不是靠巨额投入和仔细的前期计划能够避免的。那些成熟的投资者和领导者深知这一点，他们明白过度的投资本身就是创新的敌人，并不是投入越大创新成功的机会就越大，过多投资会让团队失去对不确定性的警惕。孤注一掷意味着高风险，创新型企业需要一种更加动态、灵活的投资组合管理方法，来支持进行实验性、快速迭代式的创新过程，以此应对不确定性，替代企业传统集中式、基于各部门博弈与长周期预测的投资方式。

按投资类别建立投资分配的经济模型

历史上有很多成功的企业，在面对技术更新换代、新商业模式兴起时，没能及时发展起接替自己原有业务的新业务，因而被新兴企业所颠覆，著名的比如诺基亚、柯达等。企业要适应一波波变革的浪潮，不仅要将当前的成熟业务经营好、持续提升竞争力，还必须对未来可能但不确定的新业务进行探索。然而，企业的资源是有限的；在业绩压力下，显而易见，那些能够给企业带来更快更高回报、更加确定收益的机会将容易得到更多资源；而对未来不确定机会的探索想法，投入大却回报低，失败几率高，很难争取到足够投资。这很危险，当单一优化胜过了新陈代谢，组织就会变得脆弱。

麦肯锡提出的“三条地平线”理论，将企业的投资按照其所处的创新生命周期阶段，划分为第一、第二和第三地平线，每个地平线业务的区别如图1所示。企业必须要能并行不悖地管理好对成熟期、增长期和探索期不同阶段业务的投资，才能可持续发展、具备足够的适应力。要做到这一点，首先就是要保证对各个阶段业务相对平衡的投资。

图1：创新的三条地平线

谷歌已经是一家三、四万人规模的大型企业，但也是当代公认的极具规模化创新活力的企业，在“快公司”发布的2016年全球最具创新力公司榜单中，谷歌位列第八；而在2017年则跃居第二。为了持续推动创新，谷歌将未来探索的投资和其它现有业务区分开，保证其投入不受影响，建立了70%、20%、10%的投资分配模型：每年70%的投资会用于对现有成熟产品和业务进行运营和改善，如搜索引擎、Android操作系统、谷歌地图和Youtube视频等；将20%的投资用于发展有较确定潜力的新产品，比如智能家庭设备Nest、宽带业务Fiber等；而10%的投资用于探索未来黑科技，比如Google X实验室、DeepMind和生命科学领域的Calico等。

根据创新的三条地平线建立经济模型来指导投资分配，谷歌的案例很好地诠释了这一实践。这样，就保证了不同生命周期的业务、创新型业务的合理投资比例，也避免为了争抢资源而产生不必要的内耗。采用这种策略的企业还有很多。不仅仅是在整个企业层面，我们也推荐企业在某些特定的业务单位或事业部范围内应用该策略，从发展战略的角度制定合适的比例，自顶向下分配投资。模型中的投资比例不是固定的，例如也可能是60%、30%、10%，并随着战略改变而调整。但这种调整不应该频繁发生，否则是不正常的。

如果将三条地平线模型作为对投资分类的方法之一，那么再泛化一点，还有很多的投资分类方法能够帮助企业进行投资分配，比如：

具体采用哪种分类法来指导投资，需要考虑组织所处的行业、领域、商业模式，以及投资决策发生在组织中的层级。举个例子，一家银行可能在企业战略层先按业务的三个地平线进行分配；然后在对成熟业务的第一地平线中按零售、对公和同业等不同客群方向进行分配；再进一步，在零售方向的成熟业务中，将举措按IT投资目的分类，达到业务、市场和技术演进的相对平衡投入。

以经济模型指导投资分配，需要遵循以下几条原则：

  • 粗颗粒度：类别应当是粗粒度的，上面表格中的分类在大多数场景下都满足这个条件。粒度越细，机会和投资的动态变化越不确定；在外部环境改变时，过细粒度的投资比例模型会约束团队对新机会的响应速度；
  • 相对独立：用于指导投资分配的类别，彼此之间应相对独立。在某一个特定的投资决策层级上，应尽量避免问题类别归属含混模糊，给决策造成困难；
  • 关注比例：赋予不同类别以投资比例，比为每个类别分配绝对投资额上限更有意义。对总额上限的控制只有在实际投资超过其额度时才有意义，而投资比例更能传递出组织的投资策略，可以随时对各个方向的投入情况进行比较。相对于给出每个方向上一个“合理”的绝对数额，从战略出发决定不同方向上的投资权重这种方式，因为不需要前期对未来投资具体要做的工作进行过多预测，要容易得多，从而也减少了组织浪费在前期计划上的精力；
  • 实时反馈：按类别分配投资的意义不仅仅是约束，更是提供实时反馈。企业需要有技术手段对每个类别上的投资进行持续、实时的统计，将实际发生与期望比例进行比较，将投入与实际成效进行比较，触发决策层进行原因分析并做出调整：哪些方向上投资过多？哪些过少？是市场发生了新的变化？是否应该干预后续投资节奏？

投资举措的优先级排序

接下来，对每个方向或类别中的一系列机会和举措，需要一种轻量级的管理机制使得组织保持对新机会的快速响应能力，且能够以更加科学地方式、让更高价值的举措尽早获得投资。最有效的机制是建立一个清单，动态地管理和调整优先级，并以优先级的顺序开展实施和验证。我们将该清单称为“动态优先级列表”，以突出这个清单中内容的两个基本特征：动态浮现的，和按优先级排序的。它类似于敏捷开发中的产品待办列表，不过这里每一项内容对应着是一个机会、一个解决方案或者说一笔投资，投资涵盖的范围不仅仅包括软件研发，也包括相关设计、运营、市场投入，如下图。

图2：为各个投资方向或类别建立“动态优先级列表”

下面介绍三种常用的投资举措优先级排序方法。

1. 二象限矩阵法

关键二象限矩阵，就是以两个最重要的优先级考量因素，作为大家讨论优先级的共同语言，在两个不同维度方向上相对比较各项投资举措的优先级顺序，而暂时忽略掉其它次要因素。

图3：二象限矩阵优先级排序

选择哪两个维度绘制矩阵取决于具体的业务。例如“价值”与“竞争优势”，适用于企业所提供的产品或服务在市场中面临激烈竞争的场景；“成本”与“成功可能性”，适用于在高不确定性领域的探索创新投资；还有其他的比如“效率”与“质量”、“价值”与“风险”等。

2. 延迟成本法

如果我们以正向思考难以判断多种选择的相对优先级，经济学为我们提供了一种逆向思考的方法：如果今天决定推迟做这件事，会造成多少实际损失？即“延迟成本”。准确地说，延迟成本衡量的是一件事情被推迟带来的随时间变化的损失。所谓损失包括如下几类：

最严谨和理性的延迟成本分析是对损失随时间的变化趋势进行定量建模，绘制出曲线。不一样的变化趋势指引着企业做出不同的决策。限于篇幅，详细内容可以参考“黑天鹅”网站对此的分析。但定量延迟成本分析有其局限性：

  • 量化并不总是容易的，需要有足够的历史数据积累。比如，前面例子中的单笔交易平均金额、单客户平均收益等，投资产生的影响要能反映到这些可量化的损失，有时候这很困难，或者量化分析本身的成本过高；
  • 要求投资产生的影响有一定可预测性，这使得该方法比较适用于企业的成熟期或成长期业务。对于探索期业务，因为不确定性很高，量化预测非常困难，因而不太适合；
  • 延迟成本方法可能驱动决策者过度从财务角度做决策。以客户中心的原则，意味着从客户价值角度分析投资成效比从企业效益角度衡量更重要，包括客户体验和喜爱程度等非直接效益价值。但延迟成本方法更多是从可量化的企业效益角度考虑，容易驱动决策者过度思考短期财务收益。

即便不做定量分析，延迟成本的思维方式仍然可以帮助我们——可以采用一种定性的方法对举措进行粗略优先级排序，如下图：

图4：定性延迟成本优先级排序

它其实是一种以举措的“价值”和“紧迫性”两个维度建立的二象限矩阵。价值代表着对延迟成本高低的定性评估，而紧迫性代表延迟成本发生随时间变化的趋势。我们将两个维度各自分为三个优先级等级：

3. 关键价值要素权重公式法

“价值”是决定优先级的最重要因素，但价值这个概念不具体，什么是价值？带来收入是价值，降低成本也是价值，这是一个综合概念。为了理清思考价值的标准，我们尝试识别出了12个常见的价值要素：

图5：12个常见价值要素

这12个关键价值要素并不能覆盖所有的场景，这也不是我们的目的。目的是想给读者一个思路去思考自己的业务，然后回答“什么是价值？”这个问题。你可能会找到自己更加关心的但并不在以上列表中的要素。进行优先级排序时并不需要上面所有要素，而应针对企业自己的业务特点和当前阶段的发展策略，识别出最重要的3~4个要素，然后给每一个关键价值要素设置一个权重，就像下面这个示例：

图6：关键价值要素权重公式优先级排序

由投资组合管理的干系人或委员会，就每项举措对每一个关键价值要素的影响进行评分，得分为0~3分。0分代表没有任何贡献或影响，3分则有巨大的贡献或影响，1分和2分则介于之间。另外，为了创造价值而付出的机会成本也必须要考虑的因素之一，这里机会成本包括数字化产品的研发投入，也包括其它资源、市场和运营相关投入。如果简化一点，只考虑研发投入，则可以使用估算的人力和时间。将各个关键价值要素的得分乘以其权重求和，再除以实施成本，则得到一个粗略的优先级分数。这个方法符合精益原则，它驱动解决方案的设计者采用更简单的解决方案创造更大价值，以小批量方式投入。

该过程由业务与技术多人共同参与，需要花一些时间。企业对举措的投资决策是在一个较粗粒度的层面进行，每一笔投资都有较高的机会成本。投入一定精力对投资进行审慎的判断，让企业把有限的投资尽可能聚焦到最有价值的工作上，是值得的。

实时动态决策

从明确企业发展的愿景和目标，确定投资方向和投资比例，随时为了抓住浮现出的新机会而采取行动，以及根据行动后的实际效果决定下一步行动，甚至重新调整愿景和目标——这一系列规划和决策动作必须要持续动态地进行。传统以年为周期的年度规划和预算显然无法满足这一要求。建立一个清晰的动态决策体系是方法落地的关键。数字化企业要激活规模化创新应尽量简化决策层级，以一种扁平化的治理结构赋予团队自主行动的能力。

1. 高层管理团队（Executive Team）

在企业层面，这个团队是CEO、CIO及其核心高管团队；在业务领域或事业部层面，这个团队则是业务总经理与其带领的管理团队，以及需要汇报的上级。高层管理团队的职责是明确业务愿景，制定战略和目标，设定投资方向及投资分配模型。这个团队可能为实现目标提出一些重要的想法，但尽量避免直接参与设计和指挥行动；而是通过建立合理的成效指标、并持续审视数据来了解实际情况，在成效进展偏离或不理想时介入，与下一级分析根因并支持其寻找解决方案。

2. 价值实现办公室（Value Realization Office)

在整个公司，每一个业务领域或独立平台产品，相应地都需要有一个团队来承担对数字化投资进行动态组合管理的职责——即“价值实现办公室”。这有别于传统以流程和资源导向的项目群管理，这个团队是以价值与实际成效数据为导向，进行持续评估与决策，致力于从全局实现价值最大化。其具体职责包括：

  • 建立和维护完整的投资组合视图，协商举措合理的成功衡量标准；
  • 实时或定期对包括新浮现出机会在内的所有举措，进行优先级排序；
  • 持续跟踪所有进展中举措的进度和风险；
  • 定期审视举措实施后的实际成效，以数据驱动决策后续行动，包括继续扩大优化、调整方向或终止投资；
  • 以数据方式将进展反馈给高层管理团队

该机构除了日常的跨团队协调沟通，确保成效衡量的数据落地，会定期召集相关干系人进行会议，完成以下三件事：

  • 回顾近期交付完成举措的反馈，审视运营数据，从而决策后续行动；
  • 评审新提出的想法与举措，与其它现有队列中的举措进行优先级排序，或调整；
  • 审视当前及近期的版本规划，根据上一步的结论对后续计划做恰当调整；

这个会议我们称之为“定期价值评审会议”，类似一些互联网公司定期进行的运营决策会议：

  • 以近期运营数据、新想法及举措分析为输入；
  • 参与者包括价值实现办公室组织者、举措负责人、产品经理、市场和运营负责人以及技术专家，可能也会邀请高层管理代表或投资人参加；
  • 以一个合适的频率进行，从两周一次到一个季度一次，越是动态不确定性的环境下越需要频繁地进行。

3. 交付团队（Delivery Team）及可视化投资组合

交付团队即实际负责将举措实施的虚拟或实体团队。交付团队以最有效地达成可衡量的成效目标为原则，采用设计思维的方法，在产品或解决方案的具体设计和实现上自主进行决策和实验，而不是被动地接收命令和需求。同时，确保将反应成效和进展的数据统计和呈现出来。

有效进行投资组合管理，需要可视化管理：要让每个提出想法和解决方案的负责人，不仅仅只了解自己的工作，也了解其他人在做什么以及和自己有什么关系；理解全局优化而非局部博弈；并让管理者实时了解各项举措的计划和进展，从而能够实时进行协调决策并提供支持。一个良好的实践是，采用看板方法将整个投资组合可视化出来，提高管理透明度。如下图所示，选择一个众人容易看到的地方，在一堵平整的墙面上，将整个领域或产品内投资组合的全貌展示出来，持续更新内容和状态。

图7：可视化的动态投资组合管理看板

看板左侧是愿景、业务目标与各投资方向的举措动态优先级列表，而右侧是举措从分析到获得反馈的端到端价值流。遵循“精益看板”的原则，有必要对举措设置在制品数量限制从而让投资更聚焦到高价值举措，让想法快速流动，尽早获得成效反馈。

总结

综上所述，企业的业务发展与创新要能快速响应市场变化，并最大化投资成效。这需要建立一种轻量级的、以价值和成效衡量为基础的持续动态投资决策过程，致力于缩小每一笔投资的规模，基于快速反馈、持续小批量增加投资或停止投资。企业必须以这种方式来替代传统以年度预算为代表的长周期、大投资的创新方式，从而成就“以客户为中心、高响应力”的数字化企业。

更多精彩商业洞见，请关注微信公众号：ThoughtWorks商业洞见

Share

以愿景与目标驱动，让创新无处不在

姚安峰 评论

[摘要]

在一个有高度不确定性的复杂环境中，有效指挥所有成员以对组织最有利的方式行动、并可能做出最正确决定的首要原则，是“使命原则（The Principle of Mission）”。这也是企业实现规模化创新的原则之一。为此，我们需要一种可操作的新“体制”来规划和落地业务战略，使得组织各层级在一致的目标下有自主性可立即行动。

区块链、生物识别、深度学习、虚拟现实等新技术快速发展，无人超市、小微金融、智能家居等新商业形态层出不穷，自媒体、社交网络、人种平等、全球一体化等社会变革在深层次影响着每一个人。当今这个时代，每一家企业都在热切地谈论着一件事：如何创新？

创新既包括创造全新的产品、新的服务、新的应用场景，也包括在现有的产品和服务上做出渐进式改善，运用更好的解决方案创造更好的体验。不管哪种类型的创新，都有一个基本属性，即不确定性。新的机会何时出现，提供的方案能否有效解决问题并赢得市场，实际结果难以预测。对于大型企业，当新机会浮现出来，资源申请、冗长的层层审批导致错失时机；或者机会不明确、不成熟，失败可能性很大，没有人愿意承担风险去尝试；或者企业缺乏活力，团队和个人只习惯听从命令，没有意愿也没有能力创新；又或者企业迟迟看不到创新投资的效果，在错误的方向上过度投资产生巨大浪费……

要打破这样的“体制”约束，创新往往不得不由企业的最高层领导者来推动。高层领导者要么亲自牵头发起创新，并以命令方式指挥各级部门行动；要么成立独立于体制外的团队和资源池来进行创新，比如成立研究所、创新实验室，将创新团队从原有的组织中剥离。这些创新模式有其意义，使得组织能够在旧有“体制”不变的情况下保障创新投入，让企业的创新方向与领导者战略保持一致，易于指挥和管理，尤其对于在特定方向上做出创新突破能够起到积极作用。

然而，很多历史事实证明，这种象牙塔式的创新模式难以持续地取得成功：一容易脱离客户和市场，转化为成功业务的概率低；二是创新所关注的范围有限；三是创新举措和投入受推动创新的领导者人事更迭影响。这种模式下那些企业已有部门、直接面对客户对结果负责的前线团队，依然遵循着老旧的工作方式，在创新上低效而迟缓。大型企业要持续创新和发展，除了上面这些模式，更需要“规模化”地创新，即企业要能够激活每一个部门、每一个团队的创造力，赋予组织每个单元以自主性，面对机会能够立刻行动。

在唐纳德·奈纳特森的著作《产品开发过程的原则》中，他提出，在一个有高度不确定性的复杂环境中，有效指挥所有成员以对组织最有利的方式行动、并做出最正确决定的首要原则，是“使命原则（The Principle of Mission）”：要建立目标一致且充满创新活力的组织，由领导者传达使命和目的，制定明确的目标（而不是制定如何实现目标的详细计划），允许成员自主行动，并为组织成员达成目标所做的努力随时提供支持。这是企业实现规模化创新的原则之一。为此，我们需要一种可操作的新“体制”来规划和落地业务战略。

精益价值树

精益价值树是一种以价值成效为导向，用于分析和沟通业务愿景、战略与投资的工具，并且简单和可视化。其核心是建立从愿景、目标到投资举措的自上而下对齐，因此采用一种逐层分解的树形结构，如下示意图：

图1：精益价值树

愿景

展望未来，组织所担负的使命是什么？这个未来可能长达10年、20年或甚至更久。就像著作《基业长青》中所讲的，一个有持续生命力的组织，无论战略和战术如何应时而变，总需要有一些不变的东西，不能缺少了这样的根基。这种东西往往指向一个组织所存在的目的，指向其期望为客户或社会所创造的核心价值，这就是愿景。

企业的盈利能力本质上不是企业经营的目的，只是企业持续发展不可或缺的需要，是检验经营结果好坏的标准之一。企业的目的与核心价值不在自身内部，必须存在于企业自身以外，也就是客户和社会。就像马云提出阿里巴巴的愿景是“要让天下没有难做的生意”；又比如无印良品的愿景和价值观，“用简单的生活、更少的资源过得更好”。好的愿景通常隐含了企业最稳固的、不希望轻易改变的特征或经营模式，比如某时尚快销品牌的愿景是“以最快的新品周转速度为客户提供独一无二的选择”。好的愿景要能够驱动企业在方向上做出选择，不会随着时间快速过时的；应当是能够激励人心的，能够为组织的每一个人之所以在这里忙碌奋斗提供意义，而不是一句空洞的口号。

目标

要达成长远愿景，企业需要有可执行的业务战略来引导行动方向，需要通过达成一个个更加现实的阶段性目标来确保组织真地是在向着正确方向上前进，而非原地踏步。

制定目标常见的错误之一，是将达成目标的措施或解决方案当成其追求的目标本身。比如某部门2018年的目标是“建立一个智能客户服务平台”，其背后真实的目标可能是“消费者品牌形象改善”，而“建立智能客户服务平台”则是所采取的措施之一。这种目标表述的错误很可能导致组织对是否达成目标的衡量标准也发生偏差。在这个例子中，只要新的智能客户服务平台系统上线运行，该部门就算达成年度目标了，但这真的是组织期望的结果吗？目标应是对企业未来状态的描述，而不是关于如何达到该状态的行动。

第二个常见问题，是不加思量使用企业的财务运营指标作为目标。比如“提高营业收入”或“降低经营成本”。财务运营是每个企业时刻都会关注的话题，几乎所有举措直接或间接都会影响最终的运营结果，这样的目标并不能有效传递和帮助企业聚焦创新的方向，达不到自上而下战略对齐的目的。我们期望更加有行动力的业务战略目标，建议重点考虑企业竞争战略和发展战略。

竞争战略理论中的波特五力模型，以及成本领先、差异化、细分市场三大战略，可以指引企业领导者去思考如何为提升竞争力制定业务战略，比如树立行业壁垒、追求卓越客户体验、别具一格的服务模式，或专注特定客户群或垂直细分市场等。企业发展战略理论中，关于如何实现增长的策略也可以作为参考，比如国际化扩展、细分市场拓展、产业链上下游整合、新营销策略，以及多品牌多产品线策略等。

业务竞争与发展往往与商业模式紧密相关，因此商业模式画布的各个要素也可以帮助决策者思考如何制定有行动力的目标。从目标客群的角度，业务战略可能是专注特定客群的深入挖掘，或向新客群拓展等，比如前述的时尚品牌，其战略是“成为中国年轻人市场的第一品牌”；从客户关系的角度，业务战略可能是提升客户品牌认知、提高忠诚度，或转变客户关系等，比如银行的经营模式要“从金融产品销售向客群经营转变”；从合作伙伴的角度，业务战略可能是改善伙伴关系，引入战略合作伙伴，或上下游供应链整合提效等，比如电商企业致力于“以开放服务构建合作生态圈”。这些实际的例子都可作为参考。

目标需要有明确且恰当的时间跨度，通常是从一年到三年。采用精益价值树方法进行战略规划的组织规模约小、组织层级越低，目标的跨度周期就越短，反之则越长；且在同一时间目标不应太多，通常一到三个，最多不要超过五个，因为战略需要聚焦。目标的另一个关键特征是必须要可量化、可衡量。组织需要定期获得反馈评估，以判断是否朝着目标方向取得了真正的进展。长时间没有反馈，极易让创新迷失方向，造成巨大浪费。精益价值树要求给每个目标设计一到三个可量化的数据指标，我们将这样的指标称为“成功的衡量标准（Measure of Success）”。

投资方向与举措

投资方向是达成目标的路径。针对每一个目标，企业往往会选择一个或数个投资方向。投资方向应该是持续的、长期的，会一直持续到目标已达成，或目标本身己发生变化。举措则是某个投资方向上的具体行动和措施。每一项举措对应着企业能够为客户或自身创造价值的一个机会点，它应当有明确要解决的问题，必然对应着一个如何解决该问题的想法和解决方案。例如某电商企业认为人工智能是实现其“技术领先”战略目标的一个重要投资方向，那么在某客户营销系统中，采纳深度学习技术提高精准性，可能就是具体举措之一。

沿着精益价值树的路径回溯，从举措到投资方向，再到目标和愿景，每一层都比上一层更加具体，投资的反馈周期更短，同时始终在方向上与上一层保持对齐。通过这样一种方式进行战略规划，有助于帮助企业进行聚焦和澄清，让所有的创新投资都紧紧围绕着企业的战略方向，也剔除掉那些与方向不一致的投资。下面这个图能够更清晰地展示举措、投资方向、目标和愿景之间的关系。

图2：精益价值树中举措、投资方向、目标与愿景的关系

成功的衡量标准（Measure of Success）

不仅仅是衡量目标进展，精益价值树要求也为每一个投资方向和每一项举措设计“成功的衡量标准”，以数据反馈来衡量投资产生的实际效果。既然企业需要为每一项举措进行投资，且投资的结果是不确定性的，但能够用于投资的资源却有限，那么及时、持续的效果反馈就是企业以最经济的方式达成目标的关键。缺少真实效果反馈，没有基于数据的决策机制，或者数据反馈周期太长，都会导致决策主要依赖人的主观判断和权力，很可能在错误的方向上过度投资，在正确的方向上却投入不足。这样企业创新就会陷入投资大回报低、对机会响应缓慢的窘境。

制定“成功的衡量标准”的首要原则是：衡量成效（Outcome）胜过衡量产出（Output）。如果用“智能客户服务平台正式投产运行”或者“团队完成1000个功能点”作为成功的衡量标准，虽然结果好坏很容易评判，但它们只能说明团队完成了该项工作，并不能说明实现了工作真正要达到的目的——既不能反映售后服务效率是否真的提高，也不能反映客户对售后服务的认可度是否提高，因为它们代表的是产出，而不是成效。成效衡量的是工作真实产生的效果，创造的实际价值，比如“客户服务请求的人工处理比例下降20%”。

关于如何设计成效指标，有很多可以参考的资料。阿利斯泰尔·克罗尔等人所著的《精益数据分析》一书我们经常推荐阅读，它比较系统性地从商业模式角度讲解了如何以数据来衡量创新成效，和设计数据指标时常见的误区。比如要设计可行动指标，而不是虚荣指标；要选择先见性指标，而非后见性指标。也可以参考肖恩·埃利斯等人所著的《增长黑客》中提出的AARRR海盗指标和增长引擎等。

综合过往观察和经验，我们提出价值衡量的“企业价值贡献”模型，从三个角度来分析创新和投资的成效，如下图所示，并且我们针对每一子类的指标，总结了大量具体的实例。

图3：企业价值贡献（EVC）

  1. 衡量客户价值。这里的“客户”泛指所有购买或使用企业所创造产品和服务的人群或组织，包括使用企业内部系统的用户。有效解决客户的问题，是企业的存在目的和能够长期生存与发展的根本。因此成功的衡量标准首先应该从客户价值的角度思考，包括带给客户的收益、客户服务体验以及客户是否喜爱使用我们的产品与服务。例如“请求处理周期”、“客户活跃度”等。
  2. 衡量企业效益。企业效益是指投资给企业自身带来的好处，这不能仅仅是当前的财务指标，也应包括对业务成长性和内部持续改进的衡量。相比客户价值，衡量企业效益往往更容易获得数据，能反映企业生存和发展的直接状况。但企业价值指标大多是比较滞后的结果指标，从短期来看，创新给客户带来的价值与为企业创造的收益并不总是一致，如果一味追求企业效益则会造成短视，对长远发展可能适得其反。
  3. 衡量社会使命。在为客户和自身创造价值的同时，还应当谨慎思考其带来的“外部效应”，即企业的经济活动对目标服务对象（客户）以外的的其他人或社会产生的有利或有害影响。外部效应很容易被企业有意或无意地忽略，这需要企业领导者具有社会使命感。例如税务局通过数字化手段，将线下的纸质发票全部改为电子发票，既能创造客户价值提高企业开具和处理发票的效率，同时还减少纸张使用，减少树木砍伐，产生正向的环境效应。

要设计合适有效的成效指标是有难度的，这需要创新者深刻理解想法和解决方案背后的目的和价值，并能客观面对其对习惯思维的挑战。在设置成功的衡量标准时，有时考虑在关键成效指标外再提供一两个不同角度的“保护指标”，避免对单一指标的片面追求导致偏离真实目的，产生不期望的后果。比如当一笔投资的期望成效是提高单客户收益率时，避免因此而不择手段地伤害用户体验，因此增加客户流失率或客户评价指标作为保护指标。

综上所述，精益价值树正是遵循了“使命原则”：由企业领导者清晰地描绘组织的经营目的、核心价值，即愿景；然后制定战略目标，并提出衡量目标是否取得进展的合理方法；接下来可以为每一个目标的实现指定一个责任人或团队，由该团队再进一步管理为了实现该目标需要关注的投资方向和举措、并作出决策。随着不断浮现的新机会，以及实施解决方案后真实成效的反馈，这些投资会动态调整。机会的识别和解决方案的设计，来自这个责任团队及其下属，只要团队在持续取得预期的进展，高层领导者完全不用控制每个决策和行动，而是由团队自主进行。同样，目标的责任团队也可以为每个投资方向指定一个责任人或团队，并提出该投资方向上是否取得实际成效的衡量标准，然后由投资方向的责任团队再自主管理，对该方向上动态浮现的一个个机会和具体举措进行决策。以愿景与目标驱动，以投资的实际成效衡量价值和进展，这样可以打破自上而下的强控制文化，能够良好地达到目标一致性与团队自主性的平衡统一，为企业的规模化创新提供制度条件，帮助企业实现持续发展。

以“接球”方式让战略落地。

精益价值树是站在企业的某一个业务层级来规划战略和投资。对大型企业来说，从整个企业到各个业务单位、事业部或子公司，再到产品团队，每一级即要为上一级更大范围的整体战略服务，同时也需要细化自己领域更加具体的目标，并发挥创造性产生更加丰富的投资组合。

在杰斯•亨布尔等人合著的《精益企业》最后一章，以在组织各个层级建立PDCA环的方式，阐述了一种隐喻为“接球”的战略部署机制，在企业的各个业务层级之间通过战略与目标对齐、并实现自主性的方式将组织战略有效落地，使得各个业务层级能够灵活、快速响应市场机会，从而做出规模化创新。精益价值树工具正是这样一种PDCA环的具体实现。当企业自上而下在各个业务层级应用精益价值树进行规划，就可以有效地实现“接球”式战略部署，替代传统控制型和集中式预算审批的战略落地方式。如下图所示：

图4：在各层级应用精益价值树以“接球”方式进行战略部署

这个过程之所以被隐喻为“接球”，是为了唤起上下组织层级之间一种协作式的活动。自上而下的愿景、目标和投资方向对齐不是个简单的照搬过程，而需要理解和转化。每一级需要解读来自上一级的战略对自己意味着什么，站在自身组织所担负的愿景角度，思考如何为实现更大范围或整个企业的战略作出贡献。同时，每一级通过战略规划和持续的成效衡量会给上一级的战略规划提供反馈，有时这种反馈甚至可能引起更大范围组织战略上的调整。上一级组织，则通过与其下级协商目标、投资方向与成功的衡量标准，并定期获得成效反馈来判断和影响其下级的方向，而不是通过直接左右其行动。这样，下级组织就具有了战略和行动上的自主性。

基于精益价值树的“接球”式战略规划和部署过程，与业界不少创新型企业推崇的OKR目标管理有相似之处。两者同样强调以目标对齐和关键成效的持续衡量来激活创新；但精益价值树不仅仅对齐目标，而且强调从客户价值角度衡量结果，强调成效胜过产出；通过更加清晰地传递经营目的与核心价值，并与组织的动态投资组合管理紧密衔接，为下一级制定战略规划和决策投资提供更具指导性的信息。但也正因为此，精益价值树并不适用于组织的每一个细分层级，如太小的团队和个人。实践中可以将两者相结合，在组织顶层和每个大的业务层级，比如相互独立的业务领域、事业部和业务产品上运用精益价值树进行规划，包括愿景、目标与投资组合；而在各部门或产品内部的小团队和个人层面，采用OKR的方式制定目标和关键结果。同样遵循“接球”的原则，小团队和个人需要充分理解和转化上一级制定的目标和投资方向，思考自身如何作出贡献，提出自己的想法并与上一级沟通协商来制定自己的目标，而不是照搬。OKR也要求对目标和结果进行较频繁定期的评审，比如每个季度，以此来动态调整方向，这与精益价值树的原则完全一致。

最后，在应用这套方法时一定要谨记一点：同样是对结果进行衡量，精益价值树和成功的衡量标准不同于传统的关键绩效指标（KPI），不能将它等同于人员绩效考核。尤其在中国，多年以薪资和晋升等较单一手段进行员工激励的传统，使得很多管理人员认为任何事情只有与决定薪资和晋升的绩效考核挂钩才有效。这是一种错误认识。无论颠覆式创新，还是渐进式创新，结果都有不确定性。即便是抄袭其它竞争对手的想法，能否在自己公司成功也很难说。如果创新实验的结果直接决定了工资涨幅，那还有谁愿意去做创新，谁愿意设置有挑战性的目标呢？鼓励实验、接受失败、勇于挑战、和追求卓越的组织文化是现代企业实现规模化创新的文化基础。

更多精彩商业洞见，请关注微信公众号：ThoughtWorks商业洞见

Share

企业实施DevOps的七大挑战

姚安峰 评论

DevOps这个词在近年来可谓大火。从2014年底我开始给一些企业做持续交付/DevOps相关的评估和咨询，似乎每个企业都表示想要推行DevOps，或者说他们正在做DevOps。这把火蔓延的速度远远超过当年敏捷在IT行业的传播。然而有些企业管理者对DevOps的认知让我们意识到，由于各种有意或无意的因素，这个概念不幸地成为了一个让人困惑的buzz word……

什么是DevOps？

这里我想列出四种我们在市场上、企业咨询以及社区交流过程中接触到的认知：

  1. 一些企业的运维部门找我们，说要搞DevOps。我请他们约开发部门的同事一起来沟通，却得到类似于“不用管他们，我们自己搞……”的回复。再问那打算搞啥呢？答案可能是“我们想谈谈自动化运维……”。
  2. 另一种认知是，敏捷宣言提出了“业务和开发要紧密协作，拥抱变化，将变化视为提升价值的机会而非麻烦。”那么DevOps则是将敏捷思想向运维延伸，通过开发和运维的紧密协作，让交付的最后一公里也能拥抱变化，兼顾吞吐量和稳定性。
  3. 进一步，有些企业提出了自运维“No-Ops”理念，让运维的职能融入产品交付团队，由团队自主、自助地完成部署发布，同时自己承担线上问题支持等工作，完全让运维工作去中心化，实现“Who build it, who run it”。
  4. 我们还看到，一些咨询或解决方案厂商的宣传将DevOps刻画成了一个全新的、从设计、需求到发布运维端到端的研发体系，似乎有了DevOps这把榔头，软件研发的各种问题都解决了。有了DevOps，苦逼的程序员们就迎来解放了…

作为企业管理者，要在组织中引入DevOps并推动变革，首先要对DevOps的目标有清晰的认识，并明确DevOps在自己企业的上下文中意味着什么。我反对一些厂商将DevOps吹得太大，但这也绝不仅仅是运维单方面的目标。DevOps运动本质上是关于开发（含测试）和运维的协作，在“为用户创造最大化价值”的一致目标下，让软件交付给用户并获得反馈的过程更加敏捷。至于要不要将开发运维一体化，则取决于具体产品的特征，在不同场景下可以有不同的协作模式。

DevOps行业报告提出了两个顶层的用于衡量IT组织效能的指标：吞吐量和稳定性。在一些人看来，这两个目标就像鱼和熊掌不可兼得。追求交付吞吐量，就会带来更大的不稳定性和风险；而传统运维管理以稳定性为目标，就必然牺牲对变化的响应力。之所以会有这样的悲观认知，是因为仅仅站在当前的时空看待问题，而无法超越自己的能力局限。企业管理者需要理解，进行DevOps转型，就是要超越自己的能力局限，超出当前的时空看问题，通过组织设计、过程改进和工程技术的提升让组织能力上升到一个新的维度，我们完全可以做到同时提高IT交付的吞吐量和稳定性，而不是在两者之间取舍平衡。

然而，要突破自身的能力局限，这并非易事。下面谈到的实施DevOps过程中的七大挑战中的每一个都需要组织下决心投入，并耐心等待回报，没有足够的认知转变和卓越领导力难以实现。

挑战一：自动化测试投入不足，收益低

敏捷宣言自提出时，就已经将自动化测试作为敏捷、极限编程的核心实践来强调。然而这么多年过去了，在组织中真正有效进行自动化测试的并不多，各种问题都在影响着组织和团队对自动化测试的信心。

要想同时提升吞吐量和稳定性，以自动化替代手工方式快速、频繁的对软件质量进行验证是首要的手段。如果说在以往谈论敏捷开发的时候，自动化测试是对团队的较高要求，那么到了DevOps时代，这就是最基本的入门要求。毫不夸张的说，如果软件系统没有一套较完善的自动化测试体系，就请不要谈DevOps了。

最直接的问题是投入不足。很多管理者意识里是将自动化测试看做一项额外的、可有可无的任务。他们关注的是短期的项目管理目标，而不是长期的产品持续演进，往往只有进度压力不大的时候才投入人力来做一做，或者单独聘请一个团队来补充测试用例，然后离开，而不是作为开发团队交付软件产品的一部分。这样的模式很难产生一套长期有效的测试套件，反过来进一步削弱了管理者对其进行投入的信心。

另外常见的一些问题包括：

  1. 缺乏对自动化测试策略的正确认知，过多集中在界面上做测试，缺少单元测试和API测试。界面功能测试案例的开发和维护成本高，执行速度慢；想想上千个案例全部执行完可能需要跑上半天、一天，然后有几十个案例因为环境或网络问题而执行失败，却不是因为代码问题。结果是我们看到不少团队从来没有一次将所有案例全量执行过，只能每次手动挑选一部分案例来跑。
  2. 缺乏一套独立的自动化测试环境，而是和手动测试共用一套环境。这种做法一方面会导致自动化测试和手动测试在资源和测试数据上相互影响，使得测试不稳定；另一方面自动化测试过多依赖外部集成环境，缺少必要的依赖隔离，使得测试案例执行不稳定、执行效率低。
  3. 自动化测试、手动测试和生产等各环境不一致，使得自动化测试的结果不够可信。
  4. 由测试人员或单独的团队来写自动化测试，而不是让开发人员写。这首先导致开发人员在设计和编码时很少考虑为了更高效稳定的自动化测试进行优化，加大了测试开发的难度；其次测试人员必须等到开发基本编码完成了才能开始写测试案例，并且需要请开发人员讲解API或界面元素的设计，这是一个低效的过程，浪费时间。
  5. 没有将自动化测试纳入持续交付流水线自动化地频繁执行。我们看到不少团队是在完成手动测试后、上线之前选择性地执行自动化测试案例来进行回归；这样的用法没有最大化其价值，对质量的反馈速度太慢。

要解决以上问题，并产生一套有效的自动化测试套件是一个巨大挑战，需要管理者和团队转变质量意识；需要企业从项目化的管理转向产品化的管理，人们才能真正长远地去考虑对自动化测试的投资；需要影响业务人员在需求容量上的期望，为书写自动化测试提供时间。

挑战二：高度集中的IT基础设施服务

在传统模式下，像服务器申请、配置变更等IT服务是由高度集中的基础设施管理团队负责。产品交付团队需要向集中的IT服务团队提出申请；而该团队往往承接着来自很多交付团队的需求，于是只能将请求进行排队依次处理，并且主要依靠手动处理；结果是交付团队不得不长时间等待，才能得到所需资源。这个过程中的手动操作，使得经过一段时间后，基础设施的配置变成了一个黑洞，没人能够说得清各个服务器之间的状态差异，当问题出现时需要耗费很长时间来进行分析定位。我把这样的时代称之为IT基础设施服务的“农耕时代”。

IT基础设施的管理要更加敏捷，提高变更吞吐量并同时提高稳定性，首先需要在基础设施的管理上实现这四个目标：

  1. 标准化
  2. 脚本化
  3. 版本化
  4. 可视化

在此基础上，基础设施管理团队不再排队处理所有交付团队的请求，而是专注于提供一个基于标准化、脚本化、版本化和可视化方式管理基础设施的自助服务平台；组织授权给各产品交付团队利用平台的能力，以代码化的方式随时按需进行基础设施的准备和变更。缩短等待时间的同时，因为进入生产环境的基础设施变更已经以一致的方式在各个测试环境经过了验证，减少了人为手动操作可能引入的错误和遗漏，确保了各个环境的一致性；也让前期的自动化和手动测试更加可信，从而使得系统的稳定性也得到提高。这样一个模式我称之为IT基础设施服务的“云时代”。

对企业来说，从这种基础设施管理集中式控制向去中心化授权的转变也是一个巨大挑战。首先基础设施自助服务平台的建设需要投入；更重要的是，能够授权交付团队依赖自动化方式，而非人工来保障基础设施配置的质量，本身就需要管理者的思想转变。在我看来，一些管理者倾向于依靠人来控制，而不信赖经过反复验证的自动化过程，只有一个原因：人出了错可以追责和惩罚，而自动化过程出了错，不容易找到某个单一的人来担责，总不至于惩罚机器。

这里还有一个挑战不得不提，这种转变带来了传统运维模式下运维人员的技能要求转变，从以往手动的服务器操作，变成需要写DSL、需要会编程。这必然影响到一群人的职业发展，这会给变革带来阻力；企业应当给这群人提供足够的培训，提供新的职业发展机会。

挑战三：部署与发布未分离

在产品交付团队追求频繁变更、提升交付吞吐量的时候，即便进行了严格的同行评审、通过了完善的自动化测试、确保了基础设施环境的一致性，但由于周期短、频率高，要平衡投入产出的收益，在软件进入生产环境时，还是有风险存在。因此一些管理者无论如何不敢在部署发布流程上进行放权，减少审批控制。这种不安全感是来自传统的发布过程缺少一种安全性策略，也就是没有将“部署”与“发布”分离。

“部署”和“发布”是两个不同的词，然而很多年里当提到将软件最后发布给用户使用时，两个词通常是混用的。为什么呢？以往，我们将软件发布给用户的手段很单一，就是将软件部署到生产环境跑起来，用户就可以用了，这两个词所代表的动作是同时完成的。

要让发布环节变得更加安全，就需要将这两个动作分离。“部署”即是让新的或修改的软件安装到目标环境上运行起来。这应当是一个技术决策，即是否执行这个动作应当完全由技术团队依靠对变更进行的同行评审和测试来决定，随时可以执行。这个动作过程中，技术团队重点关注的是：

  • 部署过程自动化
  • 版本更新过程对用户无感知
  • 能够快速回滚。

而“发布”应当是一个业务决策，即允许业务和产品人员来控制新特性对用户的可见性。首先对受控的小范围用户开放，经过一段时间的反馈信息收集，包括对系统稳定性和用户行为、喜好的观察，然后决定是否将其开放给更大范围的用户。如果系统存在质量或设计问题，可以很快关闭新特性，或回退到旧的版本。在这个发布的过程中，交付团队和业务人员重点关注的是：

  • 系统稳定性
  • 用户实验反馈

要实现这样的分离也是一个很大挑战。首先技术上，需要引入蓝绿部署、金丝雀发布，以及特性开关等手段；但要让每个团队都自己去建立这样一套机制成本太高，企业需要从平台战略的角度提供这样一种便捷的能力来实现灵活可配置的在线受控实验；另一方面，这样的分离意味着重新定义了在软件部署发布过程中IT团队和业务人员的职责，需要IT和业务的紧密协作。

挑战四：缺少自助式的持续交付平台

DevOps不仅仅是关于运维的自动化，同时也是关于开发、测试到运维各个职能围绕着每一次软件变更的紧密协作。在这个过程中，开发关心的是代码库、编译、构建；测试关心的是测试验证和测试环境；运维关心的是部署与发布控制、监控及支持等，各个环节的任务涉及到一系列工具构成的工具链。然而在对很多客户的调研中，我们发现普遍存在的现状是：

  1. 开发、测试和运维各自有自己的一套工具来完成自己关心的任务，而这些工具既不相同，也不相互关联；软件包在不同工具之间的转移更多依靠人工来完成；
  2. 由于工具上的割裂，每个人并不清楚同一个变更在其它角色哪里到底发生了什么，也不关心；
  3. 由于从获取代码、编译、扫描、构建、测试、部署、发布到获得反馈的整个过程中涉及到很多工具的运用，很难有哪个团队能够靠自身力量在每一个环节都做得成熟。

要在企业中实现DevOps，有一定规模的IT企业非常需要给产品交付团队提供一个软件持续交付平台，让软件从代码提交构建到交付给用户的整个过程得以在这个平台上完成，包括所有自动化任务的配置和调度，支持信息可视化辐射，和內建一些必要的流程控制环节，例如操作权限和信息审计等。这样一个平台应纳入IT企业的战略性平台之一，其价值我认为有几点：

  1. 作为一个杠杆，在规模化的组织中撬动各个交付团队的持续交付/DevOps工程技术能力，将其快速拉到一个基线，大大降低各团队自己实施的成本；
  2. 通过统一的部署流水线将从代码提交到交付给用户的整个过程高度可视化出来，信息透明；让开发、测试和运维以高度一致的方式工作在同一个流水线上，真正建立起协作；
  3. 每一次的软件变更在这个完整的流水线中得到充分的验证，尽早发现有缺陷的变更；而经过了完整验证的变更可以随时部署出去；
  4. 在组织级能够将一些必不可少的控制环节內建到自动化过程中，比如质量保障过程、过程度量、权限控制及过程审计信息等，从而弱化很多传统依靠人为检查的管理流程，实现精益敏捷的轻流程目标。

我们已经明显看到有不少互联网公司，比如阿里、腾讯在组织级提供类似这样的交付平台，然而更多IT企业还没有跟上。

还有一个更重要的关键词必须强调：“自助式”，这是平台设计的前提。我们在有些组织看到确实有类似的持续集成、持续交付平台。然而对这个平台的使用就如同前面提到的集中式IT基础设施服务一样，当交付团队需要为新的应用或服务建立一套新的自动化构建任务，或需要修改现有配置时，必须向平台的负责部门提出申请，由集中式的团队来帮助建立或修改配置。这些配置任务在集中式团队排队和等待，成为新的瓶颈。而产品交付团队自身始终不具备自动化能力，每次变更配置都不得不等待，导致需要的自动化任务跟不上架构的变化，任务失败后定位和解决问题很低效。最严重的是，团队的开发、测试人员根本不关心持续集成的执行和结果。这种模式下，平台其实远远发挥不了它应有的作用。

正确的做法是，平台团队只需要专注于提供自动化、自助式的持续交付平台，将产品交付团队当做自己的用户，听取使用反馈，持续演进；平台的设计必须要兼顾过程的标准化和流水线配置的灵活性；该团队不负责为各产品配置构建任务和流水线。这个配置工作应完全由各交付团队自己来完成，必须要具备“在需要修改配置时随时自己就可以修改”的能力。若没有该能力，组织就要提供培训和赋能。

挑战五：IT架构耦合度高

上图左下方的这栋建筑，住着很多户。如果其中某一户对自己房子的布局和功能不满意，想要重新设计，这时一个房间的设计改动必然影响到其它住户，甚至可能危机整栋建筑。如果要想允许每一户人随时修改自己房子，不用太担心危及整个系统，缩短整个改动的周期，就需要像图中其它的小房子一样，彼此之间松耦合，靠简单、标准的道路来连接。

我们的IT系统也是一样，要实现DevOps的目标，更快地响应业务变化、提高交付吞吐量，每个子系统的粒度就要小，彼此之间松耦合，各自可以独立地进行测试和部署。很多企业多个系统因为耦合紧密不得不在同一时间点部署发布，为了确保每一次投产不出问题，需要投入大量人力来进行协调，投产部署过程要处理更大的复杂性，也更容易引入质量问题。

另一方面的影响是，若单一系统规模大、复杂性高、系统间耦合度高，就难以给予交付团队更大授权、实现开发团队自主运维。

DevOps转型过程中的这一挑战在于，企业必须对现有IT系统进行解耦，将目前很多代码级依赖、数据库级依赖、或业务上的紧密依赖进行解耦，走向围绕业务领域边界建立的、靠轻量级服务和消息集成的服务化架构，要从设计上使得相互依赖的服务之间在升级时做到前向兼容，这是一个困难且耗时的过程；在这个过程中如果没有恰当的架构演进策略，缺少正确的方法引导，导致在服务拆分不合理，或缺少与之配套的服务治理能力，结果可能适得其反。这方面我们有过很多经验教训。ThoughtWorks在实践DevOps的过程中，往往就伴随着大量的向微服务方向进行架构拆分和改造的工作，这一过程可能长达数年，逐步演进。但绝不能知难而退，投入必不可少。

挑战六：职能化组织中的开发运维部门墙

在多年以前，当传统企业的业务发展对数字化的依赖程度还不高，当管理者将IT系统的开发视为一种耗费人力但又价值并不高的非核心能力时，快速膨胀的软件研发队伍纷纷从原有的业务部门中拆分出来，成为了独立的部门或信息技术子公司；随着软件系统的复杂性越来越高，在专业化、流程化的考虑下，实现功能的开发、保障质量的测试和保障运行稳定的运维按职责和技能不同被拆分成了各自独立、相互制衡的部门。结果是各部门有了自己的目标，彼此不同甚至相互冲突，都着眼于各自内部优化；但很不幸地，在这个过程中企业的终极目标——最大化为用户/客户创造价值，这个必须要所有职能作为一个有机的整体运作才能实现的目标——却被弱化了。如下：

在这样的组织设计中，各部分在一致目标下的协作不足，而更加注重过程控制和相互制衡，要真正实现DevOps是不可能的。举几个例子：

在给一些企业评估其持续交付和DevOps能力时，普遍的情况是开发完成的工作进入生产环境要经过冗长的审批过程，审批基于一大堆文档；然而事实是（不要欺骗自己），那些并不了解产品细节和每一次变更细节的审批者，很少甚至从来没有在审批过程中发现过潜藏的问题，但这一过程却严重拉长了新版本上线获得用户反馈的周期；可以说，如果开发团队在提交文档时，某些文档忘了修改、还保持和上一次申请时一模一样，估计那些审批者也发现不了（或者根本就不会细看）；

另一个普遍的现实是前面提到过的，开发、测试和运维各自有一套工具来完成自己关心的任务，而这些工具相互割裂、重复建设，没有协作。不一致的工作方式和工具既降低了交付吞吐量，也给质量保障引入了更大风险。

让软件开发的最后一公里——运维环节变得更加敏捷和适应变化，开发和运维职能的紧密协作是DevOps运动的最核心思想。要达到该目标，企业如何为开发和运维建立一致的目标，通过协作而非制衡的方式来共同面对同时提升吞吐量和保障稳定性的挑战是企业实施DevOps最重要的命题！组织需要下面这样一种治理结构：

围绕着提供给用户的产品和服务，建立包括产品设计、开发、测试和运维在内的产品交付团队。这并不意味着组织一定要立即在汇报线的设置上做出改变，关键是如何设置目标和组织日常工作！除了各业务产品，同时集中的IT运维服务部门也应走向产品化，也就是从以往为各个业务产品提供运维支持，转向专注于为业务产品交付团队提供支撑其交付的平台，以及进行运维监控、运营分析的平台；可能也从用户支持统一体验的角度出发，给各业务产品提供面向最终用户统一的支持、服务热线和客户服务渠道。

这种转变对组织是很大的挑战，涉及到多年形成的治理结构的改变。首先需要各级管理者思想上的改变，从基于不信任前提的控制型、分化制衡型管理思想，转变为基于信任前提的服务型、协作型管理思想，这在ThoughtWorks提倡的适应性领导力中有深入探讨。这种转变从一开始，很难在组织大范围开展，建议的是先建立特区，再逐步试点扩大，最后实现突破；在转变的过程中必然会涉及到部门职责范围、绩效考评、人才能力模型等深层次的转变。这种转变需要组织管理者、转型推动者发挥领导力，展现出变革的魄力和执行力才能得以成功。

挑战七：缺少敏捷文化

前面谈到的强职能化组织结构也深刻地影响着一个组织的文化。在与曾经咨询过的一个客户探讨到如何进行DevOps转型时，开发和运维部门坐在一起探讨。大家就运维流程如何改变、自动化能力如何建设等都没有异议，然而自始至终无法突破的终极问题就是：无论我们如何改变，如果万一生产环境出了问题，谁承担责任？因为DevOps能力的建设需要一个过程，开发团队不敢承诺完全承担责任；而运维因为弱化审批和控制力，也认为不该为其承担责任。最终不了了之。

我认为，根本的问题出在文化，旧有的组织治理模式产生了各扫门前雪的官僚文化，没有责任共担，以及出现问题必然问责的文化。这种文化可能源自惯性的职能化思维，可能源自组织的绩效考评和激励制度。

现代关于“系统论”的研究已经在很多著作中强调，一个组织就是一个由人构成的复杂系统，组织中每一个人所能获得的信息是有限的（包括最高管理者也是），每个人或团队都只能基于自己有限的经验、有限的信息做出决策和行动。如果系统发生失败，例如生产环境出现问题，这必然是由于系统各个部分相互作用（从想法提出到软件投产各个环节的相互作用、系统与其它系统间的相互作用）产生的结果，对其中任何局部进行惩罚无非是寻找替罪羊，有害而无益。这时候组织真正应该做的，是相信每一个人都已经做出了最大努力，将相关干系人拉到一起对问题的根因进行分析，找到能够有效避免类似问题再次出现的解决方案，并确保该方案得到实施，对其效果进行验证。

再举一个例子，Petrik曾经在DevOpsDays上提到了一个DevOps的优秀实践：Chaos Monkey（混世魔猴）。这只自动化的猴子会每隔一段时间随机将生产环境服务器关闭，以此来测试生产环境的快速恢复能力，促使各团队提升系统的稳定性。我曾经和国内企业的开发、运维部门讨论过这个实践，有趣的是无论开发还是运维都跳出来反对该实践，认为无法落地。如果没有这只“猴子”，大家可以给领导讲自己的系统很稳定（只要没出问题）；然而这只“猴子”可能会随时暴露出自己的系统并不像自己所宣称的那样稳定，会降低自己在上级心目中的“有能力”印象，随之而来的可能就是问责、惩罚。这样的文化下，大家真正关心的是如何给领导“表现”，而不是在真正的系统稳定性上追求卓越。

真正能够实现DevOps的组织，我们认为需要具备下面这样一些文化：

总结

无论是组织治理结构、管理流程、工程技术能力还是文化特征，DevOps运动都和精益产品开发、敏捷宣言所倡导的理念一致。我认为一个组织如果没有充分经历过敏捷文化的熏陶，也很难实现DevOps的目标，充其量在自动化工具和技术能力上有所提升，收益很有限。

因此我们不应当将DevOps作为一个孤立的运动去看待，更不能仅仅从工具角度去实施，而是应当将DevOps作为企业在数字化进程中为追求创新和快速市场响应、为提升组织适应力所进行的精益敏捷组织转型的一部分，这是一项系统工程。 尽管挑战重重，只要管理者首先从自身的管理思想出发做出改变，从组织小范围开始，将各种职能的人员聚拢到一起，设置共同的愿景和目标，打破束缚，给予足够授权，以紧密协作、责任共担的方式共同面对挑战，就能取得成功。然后再将小范围的经验在更大的范围逐步扩散，并适时地对企业深层次治理模式做出调整，就能够在整个企业范围内产生积极影响力，带来组织效能的巨大提升。

更多精彩商业洞见，请关注微信公众号：ThoughtWorks商业洞见

Share

不要让预算出资成为创新的绊脚石

姚安峰 2 条评论

先讲两个故事。2014年，和某客户IT团队讨论如何对产品进行滚动规划，团队非常认同应当根据每次发布后的用户反馈来调整计划，我们详细辅导了相关方法。然而实行半年后团队抱怨这种持续规划意义不大，因为规划中能够调整的仅仅是一些小的优化工作，而对于主体业务需求，即便用户反馈对自己用处不大，团队依然不得不继续做下去，因为这是年度目标里已经提出来，给领导汇报了的。

另一件故事则发生在最近。我们帮一个小客户解决基于GoCD做持续集成中面临的技术问题，在辅导中我们让客户意识到，GoCD不仅仅是基本的开源CI工具，更可以端到端地自动化从代码提交到生产发布的整个流水线，实现持续交付。团队负责人认可这样的自动化流水线对当前提升整体效率和协作非常有意义，可以解决现在面临的很多痛点。然而当把这个诉求提交到上层领导时，被告知今年的预算里没有计划这方面的投入，需要放到明年的预算中……要知道当时才刚进入5月，距离明年还要过8个月，团队负责人非常沮丧。

传统的集中式年度预算

在如今社会和技术飞速发展的时代，一个组织要进行产品创新或过程改进面临着很多不确定性。新的想法、市场新的趋势以及组织需要尝试更好的工作方法、工具，这些机会随时都可能浮现出来，你无法预先准确知道。然而一个组织的目标和投资（如分配给某个产品一年的预算）若按年进行规划，那我们谈论的”敏捷”、“精益”，要想进行实验并根据实验反馈来持续设计产品的理念就无法产生其应有的效果，只能在一些细节上微调。

很多传统企业采用的是年度预算制度，由高度集中的部门来审核和批准自上而下各个层级部门的预算，这份预算里包含了对一年目标的设定，一年能够花多少钱，要怎么花，花到哪儿。中央的预算管理部门核心目标是驱动组织各个层级都有正确清晰的目标，准确地管好花好每一分钱。然而却忽略了一件事：组织所能掌握的信息是有限的，预测失误会时有发生，一旦外部环境发生了变化，组织能够多快地改变原有目标和出资？

各个部门因为一年只有一次主要的机会获得预算，而资源总是有限，不可避免都想方设法堆砌很多理由，编制数据，相互竞争尽可能拿到多的预算。即便拿到的预算超过了实际需要，每个部门也总会想方设法将它花完，不然明年的预算就可能减少。

image_0这种集中式的年度预算制度虽然在过去几十年来证明是一种成功的治理机制，促成了很多企业的成功。然而在今天，尤其是在创新研发领域，在面对激烈的市场竞争，需要持续创新的场景下，这样的制度越来越开始制约着组织的适应力、响应力，造成非常大的浪费，很不”精益”。

将预算出资与财政年度分离

这种机制主要的问题在于它将”设定目标”、“预测”和“资源分配”几件事情揉合到了一起。要建立更有适应力的预算制度，首先就是要分离这三个关注点，将预算出资与财政年度分离，如下图示：

image_1

设定目标

有些企业管理者将团队承诺的工作内容当做目标，比如年度目标是

“要建立一站式的智能化数字运营平台”

“要完成12个省份的门店系统推广”

“要完成80%产品的看板实施”

这样的年度指标并不是从组织发展的真正目的和关键绩效角度进行衡量，而只是个别人认为可以达成某个真实目的的解决方案；相反它锁定了组织达成真实目的可选择的解决方案，忽略了不确定性，形成一种强控制文化。如果中途发现这样的解决方案并不是最有效的途径，通常也会继续做下去，因为是否完成该任务决定了个人的年终绩效。

目标应当根据组织真正的目的和关键业绩来衡量，比如上面的例子可能想要达成的真实目的是

“提高投资回报率”

“扩大用户量”

“缩短IT交付周期，提升对市场的响应速度”

进一步要衡量组织是否在达成这些目的的道路上取得了进展可以设置量化的目标，并选择合理的度量手段，例如：

“单用户收益提升15%”

“用户量提升30%”

“平均交付周期（TTM）降低30%”

组织的目的是相对恒定的，而达成目的的解决方案可能有多种，衡量指标并非一成不变，各业务、产品或职能团队应当有足够的自主性通过实验来找到最有效的方案，必要时可以和上一级协商调整目标，只要是有利于更好地实现最终目的。

更重要的是，不能将指标达成作为绩效考核的依据，一旦度量成为影响薪资和晋升的考核指标，将激励人们为了达成短期指标而牺牲掉在长期对实现真正目的有帮助的投入，甚至数据造假。切记一句名言”你度量什么就会得到什么”，唯一破解度量悖论的解药就是将度量指标和绩效剥离。

滚动预测

预测是传统预算制度中要做的第二件事，中央的预算管理部门根据每个部门提交的计划工作内容、预期收益以及清单中每个工作项预计需要的成本统计来决定是否分配资源，分配多少。如果我们所处市场环境是完全可预测的、缺乏竞争的，这种方式可以让经营者更高效的进行管理；然而这个条件在现代商业环境中越来越不现实，年度预测带来的更多就只是假象了。而且要在年初编制出这种对工作内容及成本收益的预测总是让人伤透脑筋。

预测这项工作本身不会给用户和客户创造任何价值，从精益的角度讲在这上面花太多时间就是”浪费”！组织各层级要充分接受未来难以预测这一信条，努力摒弃掉用来做未来不切实际预测的大把时间，更不应遵照一份僵化的计划来开展工作，而是致力于将时间真正投入到为用户和客户创造价值的工作上。

那预测还要做吗？从提供可预见性和识别管理风险的角度，预测对于内部管理或外部投资者有一定帮助。但要减少浪费、提高组织适应力，预测的周期就必须缩短，而频率要提高。

有一种已被很多企业验证的有效方式是”滚动预测”。将对未来的预测分成几个周期，每个周期都较短，比如一周或一个月。当前近在眼前的预测周期确定性高，可以较详细地列出，而对越远的周期进行的预测就越模糊。当每一个预测周期要结束时，就在最远的周期之外追加一个相对模糊的周期目标和预测，这个活动应基于现有信息快速完成，不必追求高准确性。而且整个由近及远的预测数据会根据最新获得的信息持续调整。不确定性越高，要求适应力越高的环境下，这样的周期就越短；在极致的探索性工作中甚至没必要做任何预测。

比如在软件研发过程中我们推荐进行三个版本的滚动规划，可以采用类似用户故事地图这样的方法。版本周期根据产品特征而定，通常不超过1个月，只有最近一个版本团队需要确定每个工作项都已进行了清晰的定义，确定其工作量估算，确定团队可承诺的交付范围；而后一个版本只是暂列出已知可能要做的工作，也许还没有定义清楚，以识别和管理风险、展现产品演进方向为目的；再之后的第三个版本基本不做具体工作的计划，只是粗略地列出可能的机会，模糊的目标。

image_2

动态资源分配

最后，当目标设定对齐了组织目的，指标变得可变，不再做年度预测，那么基于预测的资源分配自然也不再是按年来审批。如果团队发现了新的机会想要开展一项原来规划中没有列出的项目，不得不提交一份详尽的报告，走一个冗长的流程来获得领导认可和预算部门的审批，结果可能要么团队会放弃，要么资源审批下来机会却已错失，要么申请被流程否决；这对于创新和实验是一种严重伤害，自然而然就产生了官僚型的文化。

资源的分配应当变得动态，在需要时就可获得，不需要冗长的流程，不需要预算部门的审批，立即就可以投入创新实验、持续改进和采纳新的方法和工具。要在机制上支持动态资源分配，组织需要做的是给团队明确的方向，正确的价值观，找到对是否取得进展可量化的衡量指标，同时给团队设置一个边界，比如不能违反的规则，在一定时间段内的出资上限。当团队要开展新的工作，只要有助于实现目标，出资总额没有超过上限，工作就可以立即开展。

出资决策权力下放

从另一个角度讲，这必然需要打破传统企业的集中式出资决策，必须将权力下放到真正最了解实际工作，最有创新激情的一线团队。团队有足够的自主权力在组织所设定的边界范围内将资源投入到当前最有价值、最有助于实现目标的地方。

工作不要求与事先的计划相符，有充分的自由和能力去执行，只要通过可衡量的指标体现出团队正在实现组织目标和愿景的道路上正不断取得进展。如果持续没有进展，那么后续的出资就将面临问题。这里上层组织对下层应当坚持一个”辅助性原则”，即上层组织只有在下属部门无法有效做出决策时提供辅助，否则就应当放权；同时上层组织要有能力对实际的支出和进展进行监控。

各级组织要有能力自主决策，整个组织就需要大力支持内部的信息透明和共享。越是信息封闭的系统就越不得不将所有的决策都由最上层来制定，而带来的就是整个组织的低效，僵化。

瑞典商业银行曾经举步维艰，在银行业变革和大量小银行的竞争冲击下客户纷纷流失。于是瑞典商业银行请一位小银行的创始人瓦兰德来担当CEO。瓦兰德上任后进行了一系列改革，其中最重要的就是实行了激进的分权化，并且完全摒弃了原有的预算编制流程。

各分行的经理有很大的决策权，一个客户公司的所有额度都由与其有客户关系的分行经理决定和控制。这给组织带来源自一线的快速适应力，使得各级领导者不再专注于详尽的预测和计划执行，而是关注客户服务和持续改进。对各级管理者的考核不再是预算的完成情况，而是对齐组织真正的目的和收益，比如总行、分行的权益回报率、成本收入比、人均利润率、全员利润率等成效指标。

当然这样的分权管理体制需要有与之相适应的企业文化，减少约束，原则重于流程，以及严格的财务监管体系和中央信用体系。最终瑞典商业银行的改革成效卓著，极大提升了客户满意度，在同行业中权益回报率与花旗相当，而不良资产率非常低。

其它进行了类似预算制度改革的还有丰田汽车、西南航空等。现在很多互联网企业在激烈竞争和追求创新的激励下也在积极探索和采纳超越预算的方法，比如Facebook。根据CIMA的一份对英国企业的调查显示，有超过55%的企业在尝试对传统预算制度进行改革，尤其是让基层管理者更多参与到预算决策过程中，给予更多自主性。

持续小额出资有利创新

在和有些企业管理者交流时，听到他们抱怨，在新产品和服务上投入了巨额资金却还是失败了，而一些创业企业没有多少资金却做出了令人喜爱的产品；有些创业企业在取得一些积极进展后，投资方就开始注入百万、千万资金扩大团队，然而不少这样的团队和产品很快就死掉了，大量资金被浪费。

对于投资规模和创新的关系普遍存在一个误区，那就是创新必须依靠大量的投资，在企业组织中、在社会中普遍有这样的观点。不可否认，没有资金会让任何事都举步维艰；并且多少资金算多，多少算少也因产品特征而无法简单界定，需要投资者去思考；但资金越多和创新越能成功之间没有必然联系，甚至过多的资金会阻碍创新。

诞生于英国剑桥的ARM是一家芯片设计公司，自己不生产，只对外提供授权。其最初版本是上个世纪80年代两个英国人Sophie Wilson和Steve Furber设计的，相对Intel芯片其最大的特点就是低功耗、低成本和高性能，如今像高通、诺基亚乃至苹果的芯片都是基于ARM的架构，它所设计的芯片如今已经成为几乎所有移动设备的心脏。

当ARM的老板Herman Hauser在接受访问时被问到，为什么ARM能做到，而当年的Intel，摩托罗拉却做不到时，他说：”回过头来看，当时在我们决定做一款微处理器的时候，我认为我做了两个重要的决定。我信任我的团队，并且给了团队两件Intel和摩托罗拉永远不会提供给他们员工的东西：第一是缺钱，第二是缺人。他们不得不保持简单。”

我们必须清醒地认识到，创新的想法大多数都是错的。在创新的早期阶段，最重要的事情是通过实验降低不确定性，从技术、设计到商业模式的各种不确定性。有限的资金加上迫切想解决问题的创新者会将所有的精力聚焦在用户，而不是某领导或自己随意拍脑袋想出来的想法；对每一分钱的珍视才会让创业者用心去发现和投入到最有价值的工作上，让一切尽可能保持简单。这对于任何产品的研发都至关重要。而过多的资金很容易让团队开始脱离对用户、对价值的关注，开始挥霍资金为所欲为，开始不必要地过早走向规模化。

对于一个组织什么才是创新最需要的？它更需要的自由的环境、生机勃勃鼓励试错的文化，需要那些富有激情的，全力投入的的团队，需要和用户建立紧密的联系，而这些条件和大量的投资并不太相关。

支持创新和有适应力的出资决策应当是持续的、小额的。采用动态资源分配的方法，采用小步快跑、步步为营的策略，用心地培养和关注早期用户，基于真正与组织愿景、关键用户和业务成效相关的量化指标对创新探索所取得的成效进行衡量，随时准备修正解决方案，甚至停止投资。我可以给你一个有趣的办法来评价一个产品是不是真的创新，还是模仿，如果它的成功是在短时间内靠大量投资促成的，那它就是模仿。

围绕业务，而非按职能进行出资决策

最后，要支持组织的各层级能够自主灵活地进行有效的出资决策，进行动态资源分配，必不可少的是对成本和投资产生的收益进行实时的衡量。这在强职能化的组织结构中非常困难，按职能部门进行的预算和成本支出很难清楚地划分到各个业务线或产品。只有组织治理结构完全向业务、向产品看齐，才有可能清晰地计算出投入在每项业务或产品上的成本。

从全局来看，我们要将精益和敏捷的思想和方法在组织中规模化，仅仅在产品和团队层面进行改革是不够的，产生不了其应有的收益。组织最终目标是要能持续创新，具备灵活性和适应力，最大化创造的用户和业务收益。这需要企业经营者将精益思想运用到企业运营层面，其中最重要的因素之一就是财务预算和出资能够具有足够适应力，快速灵活调整，聚焦用户服务而非内部流程和考核，从而唤起组织创新活力。我一个同事开玩笑说”钱敏捷了，什么都敏捷了”，其实道理就这么简单。

Share

精益企业原则之：以产品为中心，而非交付项目

姚安峰 评论

如果要创造一个软件产品，我们现在是怎么做的？

很可能你会先组织进行可行性研究，包括分析市场环境，在纸上算算未来可能的成本和收益。如果技术上也可行，那么就写一份漂亮的商业计划书，编织出美好的数据来说服管理层和财务部门拿到一大笔预算，成立项目。项目启动后首先将需求详细写出来，在正式动工开发之前可能就已经过去了几个月甚至更久。之后负责方案设计的业务分析人员将详细方案文档交给公司的软件开发部门或外部供应商来实现，最后开发团队将软件包交接给一个专门的运维部门部署维护，并提供用户支持。

这就是现在在大多数企业的做法。不仅仅流程冗长，组织结构往往也是按业务，开发，和运维划分成不同的职能机构，大大拉长了一个想法从提出到交给用户的周期，常常错过投入市场的最佳时机；现实中业务人员对于用户到底需要什么、喜欢什么经常产生误判，在这种模式下提前数月制定的大计划就会导致大量浪费；以范围、成本和进度为中心的交付管理使得所有人都迷失了，似乎项目交付就是目的，而忽视了投资本身的初衷是要达到的用户和业务目标，更谈不上持续创新。图Figure 1 展示了这样一种传统结构：

01

Figure 1 阶段化的项目模式

这种项目化的传统模式带来的问题不仅于此。由于开发阶段和维护阶段往往由不同的职能部门负责，在成本上也是分开计算，开发人员往往不会很认真考虑运维因素，可能给系统增加不必要的复杂性，例如引入过度异构的设计或难以理解的数据结构，这导致运维成本增高，然而这些问题却反映到不到设计和开发阶段，组织很难看到围绕一个产品实际产生的所有成本；当生产环境出现问题，只有运维人员苦命地24小时待命，找到快速恢复的办法，而开发人员却可以心安理得地留下系统低质量和不稳定的风险。

以产品为中心的模式

现代科技企业所面对的竞争环境越加激烈，用户和市场的变化迅速，要能够快速适应变化，真正创造用户喜爱的，有竞争力的产品，并持续创新，需要告别以往多年以项目为中心的管理，建立一种以产品为中心的软件交付模式。也就是说，组织的投资决策与治理结构要支持团队解决问题，而不是交付项目，这是建立高适应力、持续创新的精益企业的核心原则之一。组织创造产品的目的就是要解决用户或组织自身（也就是内部用户）所面临的问题，因此以产品为中心，也就是以解决问题为中心；而相反，以项目为中心的则是以计划、预算和职能为中心。

那么要以产品为中心，组织需要在哪些方面做出改变呢？

首先，以产品为中心，要求管理的核心要素从项目的范围、时间和成本转向给用户带来的实际价值和质量。现在很多软件项目的管理者都有类似PMP这样的认证，对如何在范围、时间和成本这三个因素之间周旋很有经验。甚至一些项目管理者几乎全部的工作就是计算各种PV，EV，SPI，CPI值，通过加人减人、加班等方式来保持项目在计划和预算之内，却忽略了最最重要的事情：团队忙于添加的特性到底有没有价值？解不解决问题？

价值是产品的最核心要素，然而这在传统的项目管理指南中基本看不到对它的关注。由于人的本能，那些提出需求的人（如用户或业务部门）往往提出来的是他们认为的解决方案，而交付团队可能连真正要解决用户什么问题都没搞清楚，只将其视为需要完成的一项任务。管理工作围绕价值开展就需要管理者将最多的关注放到对用户的分析和对工作的优先级排序。

具体的方法包括与用户和各种干系人一起确立明确的愿景，对目标用户群进行识别和特征分析，找到评判一个想法优先级高低的标准，设计可以验证假设的实验；在交付过程中管理好团队的在制品数量，确保集中精力将最高优先级的特性快速交付并获得真实的反馈，从而更好地决策产品方向。

正因为围绕价值进行管理至关重要，在以产品为中心的组织中更加强调产品经理的角色，而非项目经理。产品经理或产品负责人是一个团队实际的决策者，决定产品的方向和策略，对价值负责。即便仍存在项目经理，也只能是一个辅助性角色。

另一方面，虽然每个人都口口声声质量很重要，但时间、范围和成本往往都在前期的承诺中被固定了，对任何一项预先计划进行调整都需要复杂流程，而且会被视为管理者工作做得不好。当管理者努力要保障一切按计划行事，那么很自然质量这个隐性因素就成为二等公民被牺牲了，团队加班加点，或临时增加人手，降低上线质量标准。而且软件有其特征，很多质量问题是无法通过功能验收测试来发现的，设计和代码的恶化很隐性。要以质量为核心，就需要管理者在团队内建立普遍的质量意识，提升团队的工程实践能力，提升自动化水平，形成持续改进的团队文化，而不仅仅是完成功能。

范围、时间和成本的管理并非不重要，但在以产品为中心的管理模式下这些因素只是我们交付产品的制约因素，相对于更重要的价值和质量，这些制约因素需要不同的处理方式。如图 Figure 2。

02

 Figure 2 价值、质量与约束

第二，组织要形成围绕产品，也就是围绕业务的组织结构。传统按职能划分的组织导致了不同职能不一致的目标，比如业务部门以市场效益为目标，而IT交付部门则以交付产能为目标，却忽略业务价值，运维部门以系统稳定性为目标，而阻碍快速频繁变更。我们需要打破这种职能化的筒仓式结构，建立由业务、设计、开发和运维等多种技能人员共同构成的跨学科跨职能团队，最好能够同一地点办公，紧密协作。为用户交付高价值、高质量的产品应该是所有成员共同的目标，基于共识来驱动所有人的工作步调一致。如图 Figture 3：

03

Figure 3 产品化的组织结构

有些较为成熟的组织建立了一种矩阵式的结构，即既有以职能为中心的纵向部门，也有以产品为目标的横向组织，但总得来说还是职能为实，产品为虚，员工的绩效考评掌握在职能部门领导手中。常常能看到职能部门在各产品间随意调动人员配置，破坏了产品团队的稳定性、凝聚力和业务知识积累；而且这种强矩阵式结构大大增加了组织的管理消耗，容易导致企业走向一种管理导向文化。而有适应力和持续创新的精益企业更需要一种技术导向的文化（或有些称为工程师文化）。在以产品为中心的组织中产品维度的管理应当为实，而职能方向更像是一种社区，以技能分享和发展，人员培养为主要目的。

在以上组织结构的调整中，最重要的一点就是要让协作的跨职能团队具有一致的目标，以相同的标准来衡量工作表现。不能是以各个职能各自的产出来衡量，比如以需求说明书书写的质量来衡量业务分析人员表现，以完成的需求量来衡量开发人员表现，以发现的缺陷数来衡量测试人员。而应当以产品团队整体交付的价值和质量来衡量，比如用户满意度，用户问题数，业务目标达成等，整个团队责任共担。

运维在很多企业都是一个集中式的部门，负责所有IT系统的运行，很多人对运维工作的印象就是繁琐而无趣，大量人工操作，复杂的发布流程。然而随着技术进步，这些都在发生变化，可以通过自动化的部署，监控和基础设施配置以及采纳云计算来大大降低运维难度，使得产品团队可以自助地完成大多数运维工作，将传统集中式的运维人员解放出来，专注于建设数据中心和自动化运维平台，比如组织级的IaaS/PaaS平台。

第三，应以产品的实际用户和业务成效来衡量进展和表现，而不能基于计划和预算的达成情况来衡量。计划只是一种预测，在不确定和追求创新的场景下计划随时都会改变；预算支出也不能说明我们在达成愿景的道路上已经取得了多少进展。用户成效是指产品确实解决了用户的问题，被用户所认可和喜爱；而业务指标是指产品在商业上取得了成功，为组织带来了预期的收益，这些指标才是我们对产品进行投资的目的，也只能以这些指标来衡量团队工作的进展。换句话说，如果团队在既定的成本内完成了计划的所有工作，然而上线的产品没有人愿意使用，等于没有任何进展，完全浪费。

这里以成效而非产出进行衡量是关键，有悖于一些人的认识。比如输出的文档，书写的代码行，交付的故事点数这些都是产出，产出量再高，如果没有用户、不解决问题则只会无谓地增加系统复杂度，提高运行和维护成本，有百害而无一利。如果所有人的工作都围绕能给用户带来最大价值的特性，以最短的周期发布出去，其带来的成效会远远大于一味地堆砌需求。只有所有成员（不仅仅是业务人员）都理解如何衡量成效，并以此进行考核，才能最大限度地激励每个人去思考最佳方案，而不仅仅是完成任务；而且以产品的成效衡量可以激励团队尽早和频繁地交付，尽早兑现价值。

要能够以成效来衡量进展，就需要我们在提出任何解决方案的同时也要明确如何来衡量该方案的实际价值。典型的例子比如互联网企业常用的用户活跃度，点击率，转化率，推荐率，以及在线反馈等；对业务系统也可以采用像日均处理量，处理成功率，处理周期，业务替代率，以及成本节省等指标。我们随时要牢记于心，任何方案在没有得到真实用户反馈之前都只是一个有待验证的假说。在新方案上线之前，我们还需要采用像A/B测试，金丝雀发布，特性开关等技术手段在安全受控的范围内收集线上运营数据，通过数据来验证假说，以数据为依据进行决策才是科学的，才能避免在决策过程中掺入过多职权或政治因素。

决策不仅仅关乎投资，也关乎停止投资。在有了数据为参考时，如果数据证明产品并不能达到预期的成效，团队可以随时停止在某个产品上的投入，转向其它更有价值的工作。而项目化模式下，往往都会执行到预期计划的项目结束时间点。

第四，以产品为中心意味着团队要对产品的全生命周期负责，而不是只对某一个项目阶段负责。既然各种技能人员都有了共同的目标，那么开发、运维等成员就需要尽早参与到需求分析与方案设计过程中，而不是仅仅接受前面阶段的产出；业务分析和设计人员也需要关心开发、运维的每个环节，确保自己的设计被正确地实现，并且第一时间收集到用户的反馈。每个人从自己的技能角度进行分析，提前发现问题和风险，产生尽可能最佳最简的方案，减少浪费，并跟进自己的工作产生的后续影响。

产品运营的工作直接和用户打交道，通过线上和线下的方式培养用户群，倾听用户反馈。但不少企业的运营由单独的运营部门执行，用户声音不能立刻传递给产品的设计人员，最多采用日报、周报的方式提供报表，而且这些报表里的数据既不聚焦，也不直观可视化。因此产品的业务和设计人员应该全生命周期负责，既要融入整个交付过程，也需要直接领导或参与运营工作，每天直接接触用户，才有可能产生移情，站在用户的角度对产品进行持续改善。

另一方面，团队成员要直接对产品的运维负责。由产品团队自主决策是否可以发布，并通过自助方式将新版本发布上线。然后团队需要随时解决线上出现的问题，比如分析师、架构师和开发人员采取轮流值守，一旦生产环境出现问题必须立刻响应，谁写的代码谁维护，保障系统运行的稳定性。这样的职责体系使得分析人员避免添加一些价值不高，甚至带来用户困扰的功能，提升用户体验；开发人员在写代码时会考虑是否带来运维问题，努力提高质量，主动简化系统，毕竟谁也不愿意周末因为一通电话跑到公司去解决紧急问题。

全生命周期负责的模式下，对团队成员的能力成长也更有利。每个人根据自己的兴趣和擅长可以较容易地接触到不同类型的工作，发掘自己潜力。这种模式下组织需要更多的T型人才，即在某一方面专精的同时也能承担多种职能的工作。越是在高不确定环境下工作的团队，越是创新的团队就越需要这种多技能的T型人才。（参考：http://wiki.mbalib.com/zh-tw/T型人才）

第五，建立一种以产品，或者说业务活动为中心的成本核算体系。在项目模式下，可能业务分析阶段的投入计入市场、业务部门的成本；开发团队的支出计入开发项目成本，可能是企业的资产或费用；而运维由于集中管理，往往一个人员同时支持很多产品，其成本很难对应到产品，只能通通计入运维成本，往往计入企业的运营费用。在这种模式下，很难看清楚围绕某个业务机会究竟付出了多少成本。

在以产品为中心的模式下，要将所有的成本尽可能归属到具体的产品，也就是业务活动。如果已经建立了跨职能的产品团队，并且对全生命周期负责，我们就能很容易地通过计算这个产品团队的成本来得到组织在某项业务上的投入。甚至各种公共资源的投入，比如数据中心一类的基础设施，也可以通过计算资源占用量等手段将其成本分配到各个业务产品。从而，产品团队的领导者和组织管理层就能够更加清晰地看到各项业务活动与成本的直接关系，看到真实的投资收益，从而更加科学地做出投资决策。

这种成本会计法就是80年代库伯和卡普兰教授所提出的“作业成本会计”方法（Activity Based Costing，参考：https://en.wikipedia.org/wiki/Activity-based_costing），其被证明是一种能够在不确定环境下支持创新的成本核算体系。然而尽管提出很多年，真正将其运用到实际的企业并不多，根本原因就在于大多数企业的职能划分过细，很难将业务活动的支出从各个细化分工的职能中合理地识别出来。要运用到IT行业的软件产品开发，就需要组织找到一种方法将市场、产品、开发、运维各环节的支出按业务活动区分开来，可能需要一些会计工具的支持。

最后，产品团队需要有足够的自主权力，根据实际的用户喜好和市场环境快速做出决策。在美国空军上将博伊德谈论关于在不确定环境下竞争的决策机制时（参考：https://en.wikipedia.org/wiki/OODA_loop），他强调“隐式指引”胜过“显式指引”。在企业里，“显式指引”就是所有的决策都由集中的决策机构自上而下以正式指令或遵循流程的方式来下达，而“隐式指引”则是身处竞争中的产品或业务团队根据事先明确的目标和当时的环境条件自主做出决策，而没有来自中央的正式指令。只要产品团队具备适当的能力，尤其是以用户为中心进行设计和进行安全的实验的能力，完全有可能找到比中央集中决策更加优化的解决方案，并且决策速度要快很多。

相反，在项目化的模式下，当面对突发的情况和环境变化时冗长的流程和分散的职能让进行实验和获得反馈的周期更长，会让决策束手束脚，进而错过机会。

具体来说，产品团队所需要的自主权力包括：

  • 选用人的自主性，产品负责人能够雇佣具有必要胜任力并能融入协作的人
  • 出资决策的自主性，在一定的范围内，要为新发现的机会能够随时获得额外的预算，或停止投资，而不需要集中式的财务审批
  • 决定做什么不做什么的权力，在几个月之前作出的大的计划往往在团队获得更新的信息时，原来计划的范围或方案需要作出调整，这样的调整可以随时进行，不需要流程
  • 决定何时发布产品或特性的权力，团队可以频繁地随时自主策略将实验或特性发布给用户，这样的实验发布不需要冗长的审批流程

在越是追求创新和适应力的企业里，这样的权力下放会做得越彻底。像Netflix，Etsy这样的企业甚至开发人员都可以自己决定随时将代码变更推向生产环境。

在这个过程中，上层组织需要做的就是保证产品的所有决策符合组织的战略，与组织所要实现的目的和愿景是一致的，确保存在一种机制使得团队在决策出现错误时也是安全的，并在产品团队自身无法获得足够信息做出有有效决策时提供协助。

讨论团队自主性，除了治理结构上提供的授权外，不得不提到另一个限制因素，那就是系统架构。如果产品与产品之间，产品内的各个业务领域之间架构上耦合过高，我们就不得不在各团队之上建立一层额外的机构来协调彼此的进展，就必然会限制产品团队各方面的自主性。要消除这一层剥夺自主性的额外集中控制，就要求整个企业在软件产品的架构设计上合理地围绕业务建立系统，并在应用、数据和环境层面做到高度松耦合（关于系统架构与组织结构的关系更多论述参考“康威定律”，https://en.wikipedia.org/wiki/Conway’s_law）。要做到这一点，正确的SOA和微服务架构模式是需要考虑的策略。

总结下来，以产品为中心具体体现在以下六个方面：

04

Figure 4 以产品为中心的六个方面

产品化模式的根本目的是要“最大化产品价值”。这里所指的价值体现在真正解决用户的问题，提供优秀的用户体验，并为企业带来持续客观的收益。

无论你的产品还处在需要通过实验来验证商业模式的阶段，还是需要通过丰富有价值的特性来规模化的阶段，都需要多种学科多种职能的人在高度一致的目标下紧密协作，让实验和特性能够持续频繁的交付并立即得到用户反馈。若真实的价值与预期不符，就立即做出调整，甚至放弃投资。这一目标的达成只有在组织的投资决策与治理结构以产品为中心的模式下才能做到最大化。

以上所描述的产品化模式不仅仅适用于为外部用户/客户提供的产品，也应当用于内部IT系统的开发。以往大量的内部IT系统都依靠长周期大笔的投资，并通过行政命令推行，这是造成这些系统普遍不受欢迎、不易用，却成本极高的根本原因。只有同样采用围绕业务、围绕产品为中心，通过实际的用户成效为衡量标准，提供给内部用户可选择使用或不用的权力，才有可能改变内部IT系统各种被人诟病的问题，最大化IT系统给组织带来的真实收益。

Share