[美] 加里·奥布莱恩 ThoughtWorks创始人 Roy著
本质问题的反思：如何超越绩效
之前工作时有一种感觉一年更比一年强，我们财务规划的能力与业务的期望是不匹配的，财务规划的水平对业务结果有着决定性的力量。ThoughtWorks老板的思考非常的有启发意义，并且给出了几个概括。
第一种是运营支出与资本性支出没有对齐，具体的体现就是研发投入不够、销售激励没钱等等
“运营支出（OPEX）预算和资本性支出（CAPEX）预算由不同的团队决定，没有相关性。换句话说，想做的工作与相关运营成本之间没有联系，导致无法支付那些业务承诺要做的工作所对应的人员薪水。”
第二种是滞后，因为平衡预算比高价值的工作更重要
我们很容易将所有阻碍敏捷性的问题归咎于财务人员。财务度量出结果的时间通常很滞后，也就是说，发生在工作完成之后很长时间，以至于不能准确地将工作归因于财务度量中的变动。财务度量的影响包括：使工作变慢或延迟；预算很快就花完了；组织这时对低价值的工作做出了“糟糕的”决定，因为预算平衡比高价值的工作更重要。以一家大型电信公司为例，我们见证了一些常见的财务行为模式：
上半财年的过度支出使得财务预算在财年中期被削减。这通常会对进行中的工作范围造成压力，延误新工作，降低当年交付的价值。可预见的下个月招聘冻结（下半财年的第一个月）。这导致职能部门倍感压力，填补大量职位空缺，基于运气而不是工作价值来决定。第四季度息税折旧摊销前利润（EBITDA）目标上升。这导致不可避免的争先恐后地调整支出目标和优先级。财务目标是减少支出，财年结束时工作放慢了速度。在接下来几年的第一个月出现了巨大的“曲棍球棒式”的工作，又回到了上面的第一点。
理论上来讲，财务度量是度量企业业绩的指标。只是它不能成为唯一的度量标准，不应被用于确定工作优先级或决定工作内容。但是实际上迫于生存、资本的压力财务度量有着非常强的指导能力。
几乎可以预测的是：上半年超支，招聘冻结，EBITDA（息税折旧摊销前利润）增长，临近本财年结束时工作放缓以降低支出。为了使预算获得批准，通常会采用局部优化的思维方式。与“战略”的松耦合。具有模糊性的数字化时代，科学管理理论已过时，变革的步伐使预测周期大大缩短，准确性比确定性更有价值。财务周期带来的压力已经把预算花不完变成了一个需要管理的“风险”。由于资本性支出（CAPEX）预算很低，因此“能否将其作为运营支出（OPEX）？
IT部门需要使用自动化测试，但是该工作对应的业务部门不想为此买单，因为这部分工作受益于所有人，而不仅仅是这个业务部门，在IT部门通常有一个“IT4IT”的预算。IT部门对所有业务部门一视同仁，围绕可提供给它们的最低公共服务进行优化。业务部门的特殊需求被忽视了，也意味着忽视了客户的需求，与此同时，业务部门将IT部门视为成本中心，而预算被分别分配给业务部门和IT部门。
这里给的一种解法是海盗指标
组织可以使用这些度量标准制订关于业务增长的决策。首先度量网站上的浏览量作为先见性指标，然后通过海盗指标漏斗跟踪浏览量的转换。例如，获取用户阶段浏览量总额的X%转换为活跃度，Y%转换为收入等。使用这种类型的先见性指标，还可以获得可能存在问题的信号，设置策略在漏斗顶部放入更多内容，从而在相同的转化次数下获得更多的浏览量，或者着重于提高一个或多个元素的转化率
后见性指标固然不错，但它是一种随时间变化的指标，根据过去的所有活动来度量当时的表现。很难确定哪些活动对这类度量标准有什么影响。这些度量标准本身往往需要数月的分析才能建立起来，等到以可读的形式展现时，就已经“过时”了。比如财务报告通常代表至少一个月前的数据。
这里举了一个麦当劳自定义汉堡的反例。
尽早试验和识别适当的先见性指标，可以帮助找到正确的方法来交付客户价值，并产生更多业务收益。在“自制汉堡”的例子中，潜在的先见性指标可能是：
· 知道餐厅中有定制汉堡的客户的百分比。
· 在自助点餐机前驻足的客户的百分比。
· 使用自助点餐机定制汉堡但在付款环节取消的客户的百分比。
· 研究购买定制汉堡后下一次光临时却购买常规汉堡的客户的百分比：
◆由于等待时间放弃的客户的百分比。
◆由于价格放弃的客户的百分比。
其中一些潜在的先见性指标可能很难度量，但数字技术正在使捕捉这些微弱的信号成为可能，而且使其变得更容易。在投入大量资金之前，一些指标可能会帮助发现“星厨系列”比“自制汉堡”更好。
配套还需要组织调整
随着协调成本超过某个点的价值，大多数组织都达到了收益递减的地步，降低了协调成本就能提升组织收益。角色执念是一种制度上的症状，不只是由人力资源政策引起的。比如基于项目的投资导致了巨大的隐性成本，并在中层管理中形成了一个金融权衡的黑市。这种现象是个普遍现象，大厂中会很常见，需要练习的是怎么在黑市中完成交易。这就是所谓的协调资源的能力还不够强，本质是不愿意去黑市交易。
一个循环：
1、一个项目获得了投资
2、投资基于员工人数而不是项目实际成本，意味着团队不能以较低的成本获得更多的资源。
3、可扩展性、维护工作、自动化测试、基础设施等成本，要么被忽略，要么被低估，人们寄希望于这些成本来自其他的预算。
4、该项目随着时间和预算的推移而完成。
5、维护成本被计入下一年的运营预算中，但运营预算又是每年都要削减的。
6、难以为继的预算将导致走捷径并牺牲质量，直到出现问题。
7、创建一个新项目来修复相关工作。
8、开始下一个循环
在现代IT中，存在一个“产品，而非项目”的概念，项目有一个确定的完成日期，工期有限。产品只要有价值，就会一直存在。项目通常是通过估算工作量，再添加一个大的余量，然后将投资控制在整个预算范围内来获得投资的。产品通常是通过估算你需要构建一个有用的、有价值的产品所需的团队规模来获得投资的，而且是长期投资这个团队。大部分资金都花在了改进产品上，而不是在最初的开发上。
首先是环境，通过建立“安全地失败”的环境，把先见性指标变为强大且有洞察力的指标。寻找透明与可视化的举措，将是一家企业经历的最有成效的文化变革之一。这样，企业就能够理解期望的成效、花费的资金和交付的价值之间的关系。有了轻量级的治理过程，就应该能够每两个月或每个季度审查和重新调整客户价值交付与财务责任。
所谓的“组织”很大程度上是落在团队组织，考核标准上的，比如考核到底考核的是价值还是工作的度量。瀑布式软件开发方法是度量完成的工作而不是交付的价值的典型例子。将产品周期分解为多个步骤：需求收集、特性和架构设计、编码和实现、测试、投产使用。如果需求没有不确定性，开发过程中没有战略或市场条件的变化，技术平台和集成没有意外发生，生产环境和开发环境之间没有差异，那么这就是一个完美的模型。需求收集、设计、编码——这些阶段客户还不能使用系统，因此没有向客户交付任何价值。然而，从工作完成的角度来看，项目团队进展顺利，庆祝了一个又一个里程碑——整洁的文档和信息板在整个流程中被完美地生成和呈现。通常，项目预警在编码和测试的后期才会响起。“如果很痛苦，那就尽早并且频繁地去做”的原则应用到软件产品的编译和测试中之后，我们开始将其进一步推广，而不仅仅是集成代码。软件交付生命周期（SDLC）中另一个高风险和令人痛苦的步骤是实际部署和上线阶段
解决这个问题听起来很容易，但实际上非常困难——架构标准、API设计和代码质量如何？度量、流程跟踪和支出控制呢？落实到具体的管理动作，文化倡导落地到管理动作，包括架构（分工）、责任定义、支出（利益分配）
顶层规划如何敏捷实现？
围绕交付价值，明确投资回报：关键项目持续展示成本与交付价值的关系图。
常见的脱节示例：可以看到工作是与战略保持一致的，并试图与组织的重点领域保持一致。在这个阶段，领导者会感到舒适和满足，认为工作紧随战略，他们可能会转身离开，将剩下的工作留给中层管理人员去执行。但是可以看到在该图的右侧会发生什么：工作被沿着职能线分解，并与战略失去联系。组织中的职能划分造就了里程碑和工作交接，但组织的价值流需要所有这些职能团队的共同参与。许多得到圆点的工作仍然没有开始进行，因为很难停止进行中的工作。继续做团队已经在做的事情更容易，对于无论如何都要做的工作来说更是如此。这也是一个非常具有对抗性的过程，对参与者来说是充满争论和不愉快的。
分工模型：级联模型
以下是级联模型中的关键步骤摘要：
· 将客户成效目标进一步分解为二层、三层或四层工作，以及与之对应的成功的度量标准。每一项相互关联的工作保持紧密联系，每一次分解都是自主的，度量标准都是独立的。
· 围绕已确定的工作建立跨职能团队，在团队级别采用敏捷方法以及其他迭代的持续交付方法。
· 以全新的眼光审视进行中的工作，看看它是否与刚刚确认的目标与度量标准相符。如果是，应用前文提到的四个问题将当前工作带入新的工作方式。
· 采用轻量级的优先级排序和治理模型，以确保所有工作（新工作或正在进行的工作）都得到定期审查，为最有价值的交付优化资源和能力。
级联工作为团队提供了成效的清晰视野。它可以帮助识别用于实时决策的先见性指标，并更快地反馈在成效上的进展。工作的级联和相关分解将简化度量、工作依赖关系和团队组成。级联模型是消除摩擦、确保所有工作都对齐并聚焦实现预期成效（而不仅仅是完成）的好方法。
级联模型与价值链分解思路非常接近，是把核心指标进行层次分解，逐层拆解到细致的一层指标，每一层指标都是自主独立的。
现状与未来
在墙上复制组织架构。这是一个很常见的错误，我们可以默认当前组织肯定存在问题。反模式中的一个共同点是希望证明现状是正确的，并抵制任何实际的更改。最危险的一句话是：“我们一直都是这么做的。”
从大处讲就是组织架构与客户价值交付不一致。
· 投资组合不关注产生最大价值的事情，而是与现有商业模式一致。
· 优先级排序重视确定性和完整性，胜过价值和准确性。
· 人力资源政策和流程不利于团队稳定性和跨职能协作。
· 个人的目标不一致或没有与成效成就对齐，奖金和KPI更加激励个人贡献而不是团队协作，没有鼓励每个人都朝着同一个方向工作，即共赢。
组织的规章制度阻碍和减缓客户价值交付，而不是参与其中并推动交付。所有组织都或多或少地受到以上所列的影响，有些很僵化，有些很灵活。组织就像“发动机”中一个巨大而沉重的齿轮，不断转动，无论试图做出什么改变，这个大齿轮都会在下一个循环中又转回来，并把自己调整回原来的模式。把一根棍子插到齿轮间不是解决问题的办法。
展示预算负责人与交付团队之间的关系的Circos图，请注意图中右侧圈出的两个区域。在上面的圈中，一条粗线表明这一组工作在两个领域之间有着紧密的联系，大部分工作都是为彼此完成的，并强烈表明它们应该成为一个团队。在下面的圈中，从一个领域飞出许多细线贯彻整个组织，在这种情况下，团队几乎看不到其领导者，他们正在整个组织中四处奔波，通过谈判和管理关系来完成工作。
自己在去年数据治理中歪打正着的画了类似的一个图，估计还被不少人拿去讲了，以后自己有类似想法的点，需要把他做成一个立体全面的材料，而不只是一个idea，向上需要的是现状、目标和预算，不讲需要什么支持，要讲具体的预算，与收益。
尝试新人
我们会定期有意地雇用没有技术背景的人员进入一家技术公司，并且使他们成为出色的技术专家。我们注重学习的意愿、适应的能力，让那些寻求新的挑战、能克服自己的缺点与局限性的人为团队做出贡献。
什么叫技术债
即使是最好的团队也会欠下技术债。无论是如何构建起来的，从长远来看，没有一个团队能够承担得起技术债。对技术卓越的承诺需要一种平衡的观点——紧急角度是日常要交付需求，长期角度是对内部质量投资。
边试边做 学名叫TDD
测试驱动开发（TDD）是在编写实现特性的代码之前编写单元测试或功能测试的实践。
外包也没那么省事
如内部员工与供应商员工的数量比值1:6，那么管理2.4万名外包人员需要4000名内部员工。难怪IT被认为是昂贵、低效、缓慢和复杂的。
文中也建议试试内包，值得一提的是，并非所有的内包都是由要在内部建立数字化竞争优势的需求所驱动。随着供应商和承包商的成本持续上升，一些COO或CFO得出结论：从长远来看，从内部雇用员工可能比从供应商雇用员工成本更低。但这种心态仍然是成本驱动，而不是价值驱动。一个更便宜的内部成本中心仍然是一个成本中心。内包应该是建立一种竞争优势，而不是一种实用性能力，它建立的是营收中心而不是成本中心。然每个以卓越的软件工程能力著称的组织背后都有挖人的目标，那么在建立了这种能力之后，应该如何处理人员流失呢？组织能承担得起这种损失吗？
组织成功的关键
管理者的日常任务不应该以“告诉别人做什么和怎么做”为主。
第一个是让员工明白自己做的事情的价值，在整体业务中的地位
第一个挑战是保持归属感。这意味着通过工作和度量一致性、明确性和可视化，将其与更大范畴的企业目标和意义联系起来。还要确保人们对自己的“家人团队”——一个他们在情感上和工作上都可以依靠的支持网络有清晰的认识。在某种程度上，这是人们如何看待个人品牌与组织品牌的关系。“我如何看待自己，别人就如何看待我所在的企业。”
第二点更难，明白事情的基础上跳出团队的限制（所谓的矩阵式？）
第二个挑战是，帮助人们将其所属的更大范畴的组织与其所属的小团体联系起来。在变化的时代，人们可能倾向于团结一致，变得过于依赖当前团队。它变成了关于“我的”价值体系而不是“我们的”价值体系，关于“我的”活动而不是目的。在为生存而战的过程中，行为可能会变得很有竞争性，甚至与其他团队有对抗性。保护现状比支持变革更重要。未能保持广泛的归属感可能会导致孤立员工的意外后果。团队构成变化即使符合逻辑且与客户结果相一致，也会消除员工对组织的任何归属感，你可能会失去优秀人才。
用用户故事来写需求
与正式、详细的系统需求或用例不同，“用户故事”是对特性的简单、非正式的描述。其格式通常是“作为（一种类型的用户），我想（做某事），以便（实现某种价值）”。用户故事并不是针对系统需求的精确文档，而是业务用户与开发故事的技术团队之间的口头交流工具。一个抽象的用户故事可以被分解成许多更小、更具体的故事。用户故事列表是待排序、待挑选和待处理的待办事项列表。
架构师经常花费数月时间来分析需求，力求构建可以支持未来可能状态中某个版本的系统，但最后却猜错了，或者外部环境（如业务战略的变化）使他们的假设无效。
数据自助访问方面都对团队的效率至关重要
当谈到“自助访问”数据时，并不是指为一群用户提供一个大型数据库和Tableau的副本，以便他们可以建立自己的查询（尽管这可能是整体数据战略的有效部分），而是实际上在讨论跨组织的不同团队的自助访问。通常，访问数据涉及大量官僚主义、繁文缛节和摩擦。数据被锁定在另一个系统中或由另一个团队控制。在这种情况下，“自助访问”意味着跨组织的团队可以轻松地访问适当的数据，而且摩擦很小。
内部提效应该怎么做
一个REA Colab产品包含：
· 一位产品经理，负责产品愿景、路线图、受众、度量标准、商业案例、用户采用战略和沟通计划。
· 一位管理员，通过精简待办事项列表、改进技术、为用户提供支持、维护文档和高举服务水平协议（SLA）大旗来保证质量。
· 一个据点，团队可以了解产品、阅读文档、做出贡献、查看示例、学习、请求新功能并提供反馈。
确保有足够的能力来继续改进产品，将改进变成“日常工作”。
开始整合，建立一个集中式团队，包含一个产品经理和一个产品开发团队。
企业网站可以被视为产品，各种各样的读者是客户；与合作伙伴企业共享的数据集可以被视为产品；团队使用的内部基础架构平台可以被视为产品；安全团队的脆弱性和风险评估可以被视为产品；内部API或数据提要也可以被视为产品；等等。
待办事项列表耦合
业务分析师擅长将业务需求分解为可开发的待办事项，即当一个团队向其待办事项列表添加一个PBI（Product Backlog Item，产品待办事项列表项）时，另一个团队必须向其待办事项列表添加一个对应的PBI。第一个团队通常依赖于第二个团队先完成这个PBI。这显然会带来很大的影响：团队在等待下游团队完成工作时放慢了速度，并且生产力急剧下降。如果遇到这种问题，首先要问的是为什么会出现这种耦合。是因为两个看似独立的团队实际上在某种程度上是交织在一起的吗？是否缺少一个抽象层或平台，使团队能够避免耦合？这些团队是否得到了充分的授权，可以自助访问基础设施和相关数据？
业务部门会直接与SaaS提供商接洽特定的服务，因为采购和实现流程似乎更简单、更快。在业务部门中，经常可以看到一个“数字化”部门，其任务是使用该部门自己的技术人员和合作伙伴构建客户参与的解决方案
附：推荐阅读
数字化时代预算相关的文章多到可以占满整本书的篇幅。实际上，杰里米·霍普（Jeremy Hope）和罗宾·弗雷泽（Robin Fraser）已经撰写了一本相关的书《超越预算：管理者如何跳出年度绩效评估的陷阱》（HBR Press）。而在本书中，我们重点强调的是导致了以上症状的传统预算模型的关键约束，以及你需要为此准备好的应对方法
文章来源：有虔秉钺
