编者按：这是一篇客座帖子，作者是DevOps Institute的产品所有者Helen Beal。海伦将在DevOps World | Jenkins World 2019的研讨会上发言并主持研讨会。我观察到我的客户在2017年称之为BizIT的一种模式，也就是说，这些关于工作方式的对话已经从技术团队渗透到"业务"中。正是数字颠覆推动着全球朝着这些工作方式的演进，这些方式的特点是：渐进式变革，以降低风险并创建快速反馈回路小型、专注、自主、跨职能、多功能团队，以产品为中心的思维方式，忘却以项目为中心的习惯能力，参与同侪审查打破依赖，消除障碍，简化流程，价值流思维和实验专注于客户的愉悦和价值成果的交付不断提高的吞吐量和稳定性作为平等的力量*工作方式是一个包罗万象的术语，我用它来避免"流行词宾果"，它包含了DevOps、agile（和敏捷服务管理）、lean等所倡导的原则和实践，学习型组织、安全文化、DevSecOps、Holacracy、SRE、约束理论、组织变革、系统思维等），而且由于技术和数字破坏推动了采用这些渐进式工作方式的欲望和行动，因此最初由组织中的技术团队推动。由于我所做的工作通常是从DevOps的谈话开始的，我通常是先帮助解决开发团队和IT运营团队之间的冲突和紧张关系，但是随着这些团队通过打破彼此之间的障碍来改进他们的协作方式，很快就会发现围绕技术团队的组织，"业务"提出了一整套必须解决的新约束条件，以充分实现这些替代运营方式的好处。我之所以说"业务"，是因为我根本不支持技术团队与业务分离的概念。我可以理解我们是如何做到这一点的：我知道技术是我工作的一些组织中相对较新的一部分，这些组织可能已经运作了250年之久。我可以看到技术是如何开始作为一个后台功能的，它需要作为一个成本中心来管理，并且按照我们当时所做的方式对它进行部门化是有意义的。但是，如果我们在数字化世界中的成功取决于我们有效和高效地提供技术服务的能力，那么这些团队就不能再是订单接受者；他们不应该仅仅与企业结盟或与企业整合，他们就是企业。这反映在一些组织如何回答这样一个问题："你是一个技术组织吗？"-看看多米诺公司，阿拉斯加航空公司和目标公司是如何看待自己的。每一家公司都是一家技术公司，我认为推动技术团队外部对话的关键制约因素就在这些方面领域：项目驱动资金扼杀我们真正创造长寿命产品和团队的能力产品所有者不可用使快速反馈成为不可能的客户和供应商合同使之成为可能难以协作的日常监管，这些法规被视为设定了最后期限，需要项目思考绩效评估、KPI和奖金，这些都会导致错误的行为改变代理人和领导者已经很难推动，阐明并分享一个愿景，让各级利益相关者踏上充满挑战、阻力和倒退的征程。另一个大问题是，他们需要向技术团队之外的全新团队成员宣传这些工作方式，每个人都有自己独特的方法、做法和文化。我看到了一些东西工作：与理财人士："项目驱动的资金正在扼杀我们真正创造长寿命产品和团队的能力。"几乎不可能通过短期（er）资金注入（即项目）来管理一个长期团队。我们无法创造出这些工作方式所要求的增强和实验的节奏，而且很难将改进置于功能之上，这会导致更多的技术债务脆弱。那里必须为每个团队提供持续的资金流，并围绕经常审查的小价值成果设定目标。我观察到一些企业中的一些团队设法将项目资金流到一个小型的、功能强大的团队和一个产品积压工作中，并以故事点的方式收回资金和时间来处理技术债务。但我们真正需要的是资金投入，以打破年度预算周期，与值得信赖的技术专家合作，持续提供可测量的数据值。带销售人员："产品负责人无法联系，无法进行快速反馈。"我向《商业价值的艺术》（the Art of Business Value）一书的作者马克·施瓦茨（Mark Schwartz）提问关于他对这个常见问题的看法，即技术团队正在采用敏捷的工作方式，并希望"业务"中的产品负责人能够支持快速流动/反馈和对需求的细致细化，作为用户故事，但他无法得到它，并在代理情况。马克说："简单地说，如果你不能投资你的人，那么你所说的你想做的事就不值得了。"我观察到，在一家律师事务所里，赚钱的律师是产品所有者，而在一家银行里，交易员是产品所有者，成功地提供了技术。在每一个案例中，变革领导者的工作都是艰难的，但是组织认识到，如果客户想要得到他们想要的东西，正如马克所说，他们必须确信投入时间对他们也很重要。看看Capital One的这个故事。对于采购人员来说："客户和供应商的合同使日常合作变得困难。"虽然很难告诉客户换一种方式工作，但毕竟客户总是对的，当我们的客户是消费者时，他们可能更喜欢对其web和移动服务进行持续的增量改进。当客户是另一个企业，他们还没有准备好以小增量交付工作，并且可能还没有考虑（或无法）与供应商/供应商密切合作时，这种情况变得更加棘手。敏捷宣言建议重视（客户）协作而不是合同谈判。我认为这对供应商有效也是。为了客户，关键词是福音主义和实验：如果你认为有一种工作方式可以为你的客户带来更多价值、更快、更可预测，那么问问他们是否愿意和你一起试验。对于供应商来说，你可以考虑减少寻找新合作伙伴的前置时间、降低风险和解决最重要的客户问题的方法第一，用法律界人士："被认为是设定最后期限的法规需要项目思考。"让我们从增量的、经常审查的过程减少的概念开始风险，不要增加。虽然新的或更新的法规可能会有一个死期（会产生非常严重和深远的后果），但这并不意味着它不能以迭代的方式解决。我的一个银行客户在2018年年底受到了新法规的冲击。利用他们在迭代交付方面新获得的能力，他们团结在一起应对挑战，在所需的时间范围内完成所需的所有任务，并在最终期限后使自己处于与竞争对手竞争的有利位置。他们从不忘记日期，而且频繁的反馈让每个人都专注于目标。更重要的是，迭代交付模型使他们能够灵活地进行交付，消除对法规和法规本身的理解造成的浪费进化的。有员工："绩效考核、关键绩效指标和奖金会导致错误的行为。"这又是一个：很少而且经常发生。年审周期是痛苦的，年终奖也是有毒的。我有一些客户平均地给每个人发年终奖，还有一些人完全摒弃了这个概念，提高了每个人的底薪。我也有其他人在尝试微操作和点对点信用，如果我们不能测量，我们就无法改进它。我们衡量的是先学习，然后再提高，但我们没有达到目标。如果你必须有目标，那么就把它们看作是基于价值结果的目标。个人目标在推动合作行为方面不如团队目标有效。如果你设定了一个目标，比如说部署频率，确保你有一个目标来确保这不仅仅是鼓励团队部署*任何东西*。如果我们谈论的是赋权，谁能比人们期望的更能设定目标呢？自主、精通和目标比现金收入结论是，我们都是人，人。这些新的工作方式要求我们加强游戏，了解端到端系统。"完成"的定义不是："我做了我的工作"，而是："我们的客户获得了价值"。随着这些对话的升温，这种人性化的一面正在发生，我看到自动化世界中出现了这种端到端、整体性思维的萌芽，这些新的市场类别包括价值流管理和软件交付管理。看这个空间。领先通过DevOps进化的人需要新的技能、工具、创新思维和变革型领导。一个组织的上下和跨组织的领导者必须团结协作，以打破筒仓并发展组织。如果你想了解这一点（并获得认证！），来旧金山参加我的DevOps Leader研讨会。DevOps Leader课程是一种独特的实践经验，适用于希望采取变革性领导方法并通过实施DevOps在组织内产生影响的参与者。