敏捷中的实用简化

我们人类喜欢简化复杂的东西。简单的事情比复杂的更容易理解。简单的问题比复杂的问题更容易解决。简单的目标比复杂的目标更容易实现。这是可以理解的。这是实用的。它很有用。

像其他事情一样，简化可以超越收益递减的范围。人们很容易陷入二元思维的陷阱。你听说过(或说过)这样的事情吗?

• 唯一重要的客户是“外部”客户。
• 只有一个指标是重要的。
• 我们的工作要么成功，要么失败;没有好坏参半的结果。
• 如果你只关注大局就会忽略细节，而且反之亦然。
• 一旦我们实施了X，我们就很敏捷。
• 要么全有，要么全无;要么你是完全敏捷的，要么你什么都不是

我相信你能看到掉进这个陷阱是多么容易。我做过，你做过，我们都做过。在你后面的那个家伙，为了避开这个话题，今天早上才溜出去。

我并不建议这种程度的简化是自动的或一直是坏事。当我们这样做时，这可能是一件好事，以帮助自己专注于目标，问题或学习机会。当我们忽视我们工作的更大背景时，它可能会成为一件坏事。

只有一个客户?

除了“外部”客户，真的没有其他客户了吗?显然，外部客户是体验我们提供的任何级别服务的人，他们是付账的人。顾客的需求驱动着一切。如果“外部”客户不满意，那么我们做得再好也没有用。所以，是的，那是最重要的客户。

而“外部”客户就是字面上的只要必须满足其需要的利益攸关方？当我们过度简化和忘记上下文时，我们可能不会适当地关注其他利益攸关方。最终，这可能导致“外部”客户的结果不佳，因为我们用来提供价值的底层系统和过程变得无效。

如果我们销售一种软件产品，或者我们销售一种由后台软件系统支持的服务，我们就有“内部”客户和“外部”客户，例如:

• 操作
• 技术支持
• 软件测试人员
• 软件开发人员和维护人员

如果我们忽视这些涉众，我们的系统能有效地支持我们的“外部”客户多久?

只有一个指标?

真的只有一个指标重要吗?如果你用心去做，并且有明确的意图，这样做是有价值的。例如，我们可能会有意地应用一个重要的度量(OMTM)模型作为一种方法，以专注于一个特定的改进领域，并公开下一个最重要的领域。但这并不意味着其他参数毫无价值，可以完全忽略;也不意味着我们今天关注的指标就是我们明天应该关注的指标。

的适合用途框架建议将参数分为四类，它们都很重要:

• 适应度标准(kpi)和阈值
• 具有正常范围的运行状况指标
• 具有目标的改进司机
• 虚荣度量让我们感觉良好

这些,健康的标准直接关系到客户的购买决策和客户满意度。我们必须识别我们的客户是谁，并准确地理解他们的需求，以便知道哪些kpi是重要的，以及它们的阈值应该是什么。

我们也可以应用类似的思想来确保我们满足了次级涉众或“内部”客户的需求。如果我们的系统提供了“外部”客户所关心的东西，但它们以一种不可管理的、可持续的或可支持的方式这样做，我们将无法让我们的客户高兴很长时间。

关注“外部”客户是件好事，这样我们就能正确地理解要交付什么。这是一件坏事，采取这种思路太远，我们忘记了其他利益相关者。

专注于单个选定的度量标准(可能是暂时的)是一件好事，可以帮助我们锁定问题区域并推动改进。把我们所有的努力都放在一个数字上，以牺牲业务的其他方面为代价，这是一件坏事。亚博vip9通道

成功只有一种滋味?

人们常说我们从失败中学习，而不是从成功中学习，我个人对此感到厌倦争论这种二元思维。所以，我不是在争辩;我只是发表声明。在2014年的一篇博客中，我写道:

实体法,

......我们所做的任何事情都有结果。从任何给定利益攸关方的角度来看，这种结果可能是

• 生活改变
• 非常积极的
• 有些积极的
• 混合
• 有点消极
• 非常消极
• 不相关的,无趣的

当我们考虑所有涉众的观点时，任何给定的结果都可能同时包含上述所有因素。利益相关者认为结果是“success”还是“failure”取决于结果如何影响他/她。

端-

我还建议我们对“成功”的定义仅仅是我们取得的结果发生在与我们的期望相对应，而我们对“失败”的定义仅仅是与我们的期望不同的结果。

我仍然认为这是真的。将每个结果简化为简单的通过/失败便是超越收益递减点的简化方法。结果要微妙得多。

我们可以说“非常积极”的结果是成功就这样吧，但如果我们这样做，我们可能会错过一个学习的机会。我们可以说一个“非常消极”的结果是失败，但如果我们这么做，我们可能会引发一种情绪反应，抑制人们从经验中学习的能力。

除此之外，我们如何归类为二元成功或者失败对干系人A来说是“非常积极的”，对干系人B来说是“非常消极的”，对干系人C来说是“混合的”，对干系人D来说是“无关的和无趣的”?

简单的及格/不及格评估有时可能有用。它可以帮助我们专注于我们如何达到一个特定的目标。但这种单一的视角并不能真正理解复杂的情况。

只有一个层次的细节?

每当有人讨论大局时，其他人会很快抱怨他们忽略了重要的细节和边缘情况。每当有人讨论一个特定的细节或边缘情况时，其他人就会很快抱怨他们忽视了大局。

我认为重要的是要培养放大细节和边缘情况的能力，并将我们的思维划分为适当的处理它们，以及缩小和背景这些细节在大的图景。当我们在某一特定时刻做其中一件事时，并不意味着我们完全忘记了另一件事。

关键是要学会辨别何时转移我们的注意力。如果我们被困在细节层面，我们就会做批评者担心的事情:我们会忽视更大的背景。如果我们不能专注于细节而不被与当前细节相关但与当前细节无关的关注所分心，我们就会不断流失并无法解决任何问题。

成为敏捷仅仅一步?

根据我的经验，许多客户组织认为他们正在做的事情已经“足够好了”，当他们“实现”、“安装”或“采用”某种“敏捷”框架或方法时，他们就打开了开关，成为了一个敏捷组织。

但事实并非如此。敏捷思维包括持续改进、频繁反省和反思，以及目标、资金和实践的动态调整，以保持与组织的使命和目标的一致性。

你不能“实现”敏捷，除非实现你的意思是改变你对业务的看法亚博vip9通道。如果“实施”仅仅意味着采用一些流行语，并通过一些仪式的动作，那你就错了。

考虑这种基于更大组织敏捷性的进展模型，基于一个探险的比喻:

当我们帮助客户从预测-紧急象限转向预测-聚合象限，根据我们的远征模型转向Basecamp 1时，他们通常会认为自己已经打开了开关，成为了一个敏捷的组织;他们已经从一个功能良好的传统模型过渡到一个功能良好的敏捷模型。

但我们经常发现的是，在预测 - 紧急象限中运作的组织不太了解

• 他们的产品是什么
• 他们的价值流是什么样的
• 他们的客户是谁以及他们想要的东西
• 他们的市场是什么，它是如何发展的
• 他们的首要任务是什么
• 他们的战略计划是什么
• 他们的哪些活动是任务关键型的
• 他们的实际软件交付能力是什么
• 业务和支助中节省成本措施的真实成本
• 哪些系统在它们的环境中运行，以及它们是如何关联的
• 大约有多少特定的倡议将成本或需要多长时间
• 是否应该停止工作以获得新的倡议，以获得充分的理由，或者只是因为不同的轮子开始吱吱作响
• 如何以敏捷方式管理资金
• 为什么要限制在制品或如何限制
• 最大化利用率和最大化吞吐量之间的区别
• 什么时候、为什么要改变优先级，以及如何让转变顺利进行
• 如何衡量他们在做什么或与此类信息有什么关系
• 他们应该前进，接下来需要措施

对于更大、更成熟的公司来说，从起点到Basecamp 1的过程不是一个从功能良好的传统环境到功能良好的敏捷环境的转换问题。这是一个控制混乱的问题，识别客户和他们的需求，理解市场和它是如何发展的，设定一些商业目标，学习如何评估机会和工作的优先级，可视化当前的过程，获得适当的度量，亚博vip9通道建立一个可预测的交付系统，并设置阶段使组织能够开始朝着更大的业务敏捷性发展。亚博vip9通道

庆祝达到这个里程碑可能是一件好事。当你假设你完成时，它只变得糟糕。你没有。你刚刚开始。

只有一个有效的运行状态?

当人们第一次了解敏捷的概念、方法、框架等时，他们会变得热情和兴奋。这是可以理解的。许多敏捷顾问、教练和培训师都非常热情，希望他们的客户能够获得尽可能好的结果。有时，他们会低估从这里到那里的难度。

在敏捷社区的某些地方有这样一句箴言:“改变并不难。这就像往咖啡里加牛奶一样!”

如果你说的是往咖啡里加一汤匙牛奶，而牛奶还没倒到咖啡边，那当然可以。如果你说的是向10万杯不同大小和形状的咖啡中加入牛奶，所有的咖啡都已经满了，有些破裂，以不同的速度泄漏，在不干扰喝咖啡的人的情况下，你在试图加入牛奶，每一杯牛奶都需要特定种类和特定温度的特定量，在整个过程中保持每一杯牛奶都在饮用者喜欢的温度，当你没有足够的设备或基础设施来满足这种规模或种类的需求时，你的组织没有关于处理大量咖啡和牛奶的既定程序或机构知识，那就没有。是很困难的。

这很难，而且不是一步就能完成的。这就是“远征”的比喻。需要采取一系列步骤，在合理的地方停下来、休息、补给和重新评估计划。

还有更多。同一企业内的不同业务亚博vip9通道运营可能需要以不同的方式与市场交互，并以不同的方式构建产品。有些领域可能需要类似于精益创业(大致相当于我们的Basecamp 5)。其他领域可能需要稳定更传统的交付速度，停在Basecamp 2。这取决于业务需要。亚博vip9通道没有一个简单的答案。

例如，在我们使用的大型银行中，面向客户的移动和Web应用程序的目标Basecamp是Basecamp 4;靠近精益启动模型，具有完全自动化的CI / CD管道，只需要管理“Go”释放。他们希望能够在几乎没有安全和合规性的时间内转动移动和网络应用程序中的变化。同一家公司旨在为Basecamp 2在其后端核心银行系统领域，因为这些应用程序稳定并且很少发生变化。他们希望能够在3-4个月内交易。

如果他们想从DENERY转换他们的主营企业数据库系统，如果程序员直接与在银行支票账户的人员互动，则会增加哪些值;“外部”客户？

当敏捷人员告诉你，你的开发团队必须与“外部”客户直接互动，而不是任何形式的代理或“内部”客户，他们考虑的是最终的、原始的敏捷模型。他们可能没有考虑到你公司的实际情况。

在Basecamp 1或2级运行的公司可能无法实现原始目标。想象一个制造网络交换机的大公司。我在想象一个特别的例子。其硬件和软件的每一个版本都必须与现场当前使用的所有设备向后兼容。我正在考虑的公司在7个国家的10个地点运营。他们的项目通常涉及750人，来自多个地点的多个团队。你认为一个网络交换机的“外部”客户，比如巴西，会直接与匈牙利345团队的工程师#7和中国764团队的程序员#13互动吗?这有什么帮助吗?

坚持开发人员直接与“外部”客户互动，使得组织结构的简化超出了收益递减的范围，这变得很愚蠢。

大多数Basecamp 1组织还没有完全过渡到跨职能团队。他们仍然有与产品或价值流不一致的功能竖井。编程团队的“客户”是测试团队。测试团队的“客户”是集成团队。集成团队的“客户”是部署团队。部署团队的“客户”是生产支持团队。它不会永远保持这种状态，但目前它是现实。当每个团队将下游团队视为真正意义上的“客户”时，他们的表现最好，即使从企业的角度来看，他们并不是实际的客户。在这类问题上，我们必须现实和灵活。当然，最终所有这些活动将由一个跨职能的开发团队来处理。 But not today.

你可能想知道它是否甚至是可能的为内部开发团队直接与外部客户工作。我看到过这种情况，但只有在一家年轻的公司处于初创阶段时才会看到。我知道的一家公司生产现场监测工业设备健康状况的物联网设备。在启动阶段，他们的工程/编程团队(20人)直接与两个早期采用者客户合作，准备产品的初始生产版本。现在他们已经超过了创业阶段，拥有超过20名工程师/程序员和超过2名客户。开发人员直接与“外部”客户合作的原始敏捷愿景不再可行。

在这一节中，我只讨论了敏捷信条的一个方面;与“外部”客户合作的需求。敏捷人士希望我们做的事情有一长串，每一件事情的可行性很大程度上取决于当前的情况。在所有环境中，对什么是敏捷或什么不是敏捷的教条主义是没有帮助的。这是一个持续改进的过程。只要你在自省和提高，你就在正确的轨道上。谨防二元思维。

结论

当简化可以帮助你实现一个目标时，就进行简化，但是要注意不要把简化后的模型当成真正的东西。它不是。