流程是目标：改善复杂企业环境中的交付，以影响变革并实现真正的持续改进。
译自 Agile, DevOps, Platform Engineering Confusion Stalls Devs，作者 Charles Humble。
作为一家大型全球咨询公司，UST 专注于帮助公司创新和改进技术交付，其大部分工作源自 DevOps 实践。在与客户合作时，该公司经常会遇到一些问题，例如如何在提高代码质量和工程师参与度的情况下缩短上市时间。
Eugene Sazhin，UST Global 的工程、数字敏捷平台和解决方案主管，经常发现自己在想，“应该有一套我们能够制定、遵守并建议我们的客户也遵守的总体原则，以便他们在转型之旅中取得更好的成果。”
这正是 UST 最近发布的交付改进框架的目标。
该框架结合了精益、敏捷和 DevOps 以及康威定律、团队拓扑、DORA 和 UST 自身经验中衍生的思想。它包含七项核心原则：
- 流动至上。
- 积极性推动流动。
- 团队拓扑 编排流动。
- 关键绩效指标 (KPI) 指导，而非管理。
- 精益原则推动优化。
- 有目的地遵循康威定律](https://thenewstack.io/context-reversing-conways-law-for-superior-service-management/)。
- 重视信任而非绩效，重视学习而非专业知识。
“流动”的概念是该框架的重要组成部分，UST 使用精益/组织意义上的流动，而不是指个人开发人员的流动状态（尽管这两个概念密切相关）。在定义“流动”时，UST 写道：
“从精益原则中汲取灵感，我们优先优化整个价值流，而不仅仅是孤立的部分。我们消除浪费，最大程度减少上下文切换，并构建一个系统，使开发工作从构思到交付无缝流动。”
整个框架以员工为中心。第二项原则“积极性推动流动”谈到了工作与生活的平衡、自主权、认可、个人成长和学习。敬业且快乐的员工更有生产力，但另一个因素是，成功的组织转型要求所有参与者都参与其中，从高级领导层到基层员工。我在其他地方描述了我参与的五次组织转型中有三次没有按预期进行。在每种情况下，缺乏领导层的支持或关注都是导致失败的主要因素。
UST 发布其交付改进框架的逻辑借鉴了 Simon Sinek 的观点，即如果你公开阐明你的核心原则，其他人会受到鼓励加入你。通过公开该框架，咨询集团也在邀请对话，这应该使他们能够迭代和改进该框架。快速反馈循环在任何学习型组织中都是必不可少的。
Sazhin 还表示，发布该框架有助于公司的咨询业务。他说，如果 UST 客户“在解决转型问题时了解我们的出发点，那么我们就可以联系并合作，并且我们有更大的成功机会。”相反，如果客户不同意这些原则，那么“我们存在核心分歧，这根本行不通。”
如果一家公司宣称了一套核心价值观，但没有人过多关注它们，那么它们就毫无意义。“如果你致力于框架中的核心价值观，”Sazhin 告诉 The New Stack，“这意味着你正在根据这些核心价值观评估你的所有行动和想法，并应该过滤掉那些不一致的行动和想法。例如，如果你致力于积极性的核心价值观，那么你与员工的沟通应该遵循这一原则。你不应该允许人力资源部发布带有威胁的沟通；这样做将违反你声称坚持的一项核心原则，并且你会失去信任。恢复失去的信任极其困难。”
在组织中，信任源自高层。失去信任也令人不安地容易；一种方式是不展示你所拥护的价值观，但其他方式包括在公司盈利时进行大规模裁员或将绩效评估与容易操纵的统计数据联系起来。
我怀疑几乎每个人都被要求实施一些他们坚信行不通的事情。作为负责任的合作伙伴，你有时不得不反击——即使你是一家依靠让客户满意的咨询公司。例如，UST 客户经常要求一种衡量开发人员生产力并将其纳入其流程的方法。然而，Sazhin 说，“在大多数公司中，开发人员的生产力被广泛误解和滥用。”
麦肯锡因其关于衡量开发人员生产力的文章而受到严厉批评。但其基本态度仍然盛行：编程可以简化为打字，因此生产力等同于 Git 提交、代码行数、修复的错误或其他无意义的统计数据。现实情况是，打字并不是编程的难点，而且，正如 Sazhin 指出的那样，“这些事情与团队的业务目标无关。”
例如，一位高级工程师花时间帮助团队中较初级的成员解决他们的问题，这可能是为提高团队绩效所做的最好的事情。但如果她的绩效评估基于她的 Git 提交统计数据，那么这一切都将不可见。
Sazhin 表示，以这种方式衡量开发人员的愿望源于对团队成员和个人的微观管理愿望。它源于对团队自我组织能力缺乏信任。但这种想法与 UST 的核心原则不符。相反，领导者应该让团队找出是否有任何人没有发挥作用，让团队安全地表达他们的担忧，并帮助这个人改进（或做出更彻底的改变）。
Sazhin 认为，与其进行微观管理，管理者需要“确保团队理解目标是什么，消除障碍，然后衡量团队交付的内容是否符合这些业务目标。”这反映在该框架中的第四个原则中，“KPI 指导，而非管理”。
这很重要，因为科技行业容易出现魔术思维。如果没有变更控制委员会的批准，任何内容都无法投入生产（该委员会每年仅开会两次），那么无论有多少微服务，IT 都无法更快地发展。但许多组织似乎认为会这样。
Sazhin 说：“同样地，‘公司说他们想要敏捷’，‘但随后他们采用了 SAFe [Scaled Agile Framework]，这让我感到困惑。这意味着他们完全误解了敏捷的含义。你可以实施 SAFe 多年而没有任何结果——你可以声称这是因为你没有正确实施 SAFe，但事实并非如此。”
正如敏捷顾问 Dan North 所说，“SAFe 声明的商业模式是‘框架、平台、专业培训内容和认证的提供商’。它没有关于客户成功的任何内容，没有关于责任的任何内容，也没有关于该框架是否有效的内容。”这一切都与敏捷宣言的“发现更好的软件开发方法”的使命相去甚远。
尽管如此，该行业还是取得了进展，尤其是在缩短价值实现时间或如何快速推进想法以在客户中进行测试方面。
包括亚马逊、Intuit 和 Netflix 在内的企业每年进行数千次实验。“我鼓励[亚马逊的]员工走入死胡同并进行实验，”杰夫·贝索斯说。“我们已经尝试创建工具来降低实验成本，以便我们可以进行更多实验。如果你可以将实验数量从一百个增加到一千个，你将大幅增加你产生的创新数量。”
您还需要让实验者可以安全地失败，因为大量的实验并不会达到您的预期。反过来，这意味着员工需要在核心拥有强大的信任和心理安全，才能拥有自主权。为了避免单一文化思维，公司需要多元化招聘，灵活的远程工作通过增加可用人才库的多样性发挥着重要作用。
特别是软件交付，需要小型、自主、跨职能团队构建可独立部署的软件单元。通常，这意味着微服务或功能即服务 (FaaS)，例如 AWS Lambda。需要根据需要尽可能频繁地发布到生产环境，且故障率低——并且从任何部署故障中快速恢复。我们已经了解这一点二十年或更长时间了：DORA 加速 研究，由 Nicole Forsgren 专家领导，甚至提供了基准。
Sazhin 强调了验证您的想法和您取得的进展的重要性，以便任何决策都是基于数据而不是直觉做出的。“您需要指定一个假设，尽可能地收集数据，然后使用科学方法进行改进，”他说。“有一种常见的思维模式，认为有些事情太难或不可能衡量，因此为科学分析收集数据太难或根本不可行。这与事实相去甚远。”他推荐这本书 如何衡量任何事物：寻找业务中无形资产的价值，作者是 Douglas W. Hubbard，展示了如何借助校准估计、统计分析和模拟来实现这一目标。
最后，Sazhin 建议拥有一个支持您工作的有影响力的人脉网络。“如果您没有他们，您将无法获得持续改进所需的文化变革，”他说。“您需要增加组织中变革推动者的数量，这些人正在积极帮助团队完成这一旅程。他们应该完全一致并做出承诺，但最重要的是，他们应该对这些变化充满热情。”
有关更多见解，请下载 UST 的白皮书释放开发人员流程：用于改进企业软件交付的框架。