处理系统债务

序言/tl;博士： 我最近发表 主要是作为一个愚蠢但真实的观察，关于经典的 Seinfeld 线“现在平静，以后精神错乱”如何与敏捷联系起来。我以关于我们需要如何更好地为随后出现的“精神错乱”做准备的声明结束了那篇文章。考虑到这一点，我将介绍我建立高效团队的方法。这是关于 了劳埃德布劳恩敏捷原则， 偿还您的系统债务。 现代技术团队已经崩溃。 我们过于依赖老年人，而不是利用青少年。 去年我一直在思考这个问题，因为我已经让多个团队适应我们的“新常态”。几个月前，我开始写一篇文章来支持招聘经理应该雇佣初级员工的观点。为了提出有效的论点，我知道我必须解决一个共同的问题：“首先，我需要前辈来训练后辈……” 这篇文章很快就越来越多。 如果您是管理新手，这是我关于管理的“论文”。它是关于如何建立高效和高效的团队，并且基于十多年来成功管理多个大型团队的经验。 接下来是长篇阅读 - 所以 tl;dr 是： 我们经常谈论#TechnicalDebt，但技术债务是我称之为 系统债务的更大问题的症状。 食谱很简单： 1) 让您的老年人偿还您的系统债务，让工作更轻松。 2) 雇用。青少年。 3) 停止与减员作斗争。大三学生将平均停留 18-24 个月。他们想要不同的体验。他们会寻找其他工作。作为一个技术社区，我们希望 Juniors 在通往资历的道路上获得更多经验。这让他们变得更好，也让我们变得更好。所以，让我们接受减员。让我们开始专注于让他们充分利用这 18 个月，然后支持他们的下一步行动。 任何优秀的交付团队都强调可用性。驱动可用性的原则以许多不同 、 、 等等。他们都得到了一些非常人性化的东西： 的形式出现：帕累托原则 奶奶测试 足够好原则 这比它需要的更难吗？ 我们一直都 看到：极简主义设计优先考虑易用性，并高度关注清晰的愿景。其他一切都是分心的，它是臃肿的。 在 有很多人在谈论领导力、管理、工作/生活平衡以及远程/面对面工作。一切都在重新评估——几个月来一直萦绕在我脑海中的问题很简单：工作是否比需要的更努力？这绝不是一个新问题，但它是贯穿我职业生涯大部分时间的主线。我喜欢编写代码和构建产品，但整体视图可以揭示更多的代码并不总是答案。更多的代码意味着更多的培训和维护成本。 如果您是新经理，记住这个问题可能非常有价值。经理有很多责任：你在帮助每个人——完成他们的可交付成果和他们的个人目标。你负责团队的凝聚力和方向。您通常负责建立流程和政策。然后是资源分配和规划，以及围绕 PTO 时间表工作。但所有这一切的指路明灯是同一个问题： 这是否比它应该的更难？ 你最后一次评估你的内部机制是什么时候？将您的交付团队视为一种产品，您的消费者（业务/运营团队）实现目标的难易程度如何？将您的整个业务视为一种产品，客户实现他们的目标有多容易？ 关注人，同样的问题也适用：你的团队做他们的工作有多难？存在哪些结构、框架、人为的流程和层次结构，会让你的祖母对你让事情变得多么复杂而摇头？ 债务入门 事实上，批判性评估内部流程的整个思路是敏捷哲学的一部分，但经常被忽视。团队声称他们是完全敏捷的，或者说是“敏捷混合”，但仔细观察你就会意识到他们的意思是他们只是在偷工减料以更快地交付草率的产品。谈到软件，任何经验丰富的开发人员都会确切地知道这会成为不断增长的技术债务的秘诀。程序员们一直在开玩笑说，最后一个人做错了，如果你想要它 ，你就需要重建它。这不是因为懒惰或缺乏能力。绿地工作更容易，因为它消除了所有的技术债务 - 但是，如果留下同样的糟糕流程，它只会再次增长。 正确 技术债务是一种症状，即使你善于主动偿还——你仍然只是 。这种症状来自于错误地认为敏捷 软件交付。 在治疗症状 只是 技术债务的正确定义是“需要重构的工作的积累”。如前所述，它源于在专注于交付时走捷径。除非你积极付清，否则它会迅速增长。技术债务过多的结果是脆弱和不稳定。 在最好的情况下，技术债务是一个有意的决定：它把一些东西放在信用上，打算在以后还清。在这种情况下，技术债务还不错——只要你努力偿还债务。技术债务更邪恶的化身是当你无意中增加了债务，或者更糟 - 你不知道你已经增加了它。 技术债务涉及技术，但 有一个类似的概念——遗留流程变得陈旧、运作不佳、产生摩擦、影响跨团队动态，或者随着角色的变化可能不再适用。流程债务涵盖了我们的非技术运营缺陷。 流程债务 还有其他形式的债务会影响交付：设计债务、建筑债务。 当然， 本质上并不是邪恶的。就像您可以战略性地承担健康的金融债务一样，承担任何这些形式的债务都是一项战略决策。您无需一次性支付 20,000 美元购买汽车，而是申请汽车贷款并将还款分摊至 10 年。同样——您使用的技术堆栈、您构建团队技能的方式、这些角色的资历以及推动您的业务的流程承担了在一段时间内偿还的债务。 债务 只是——有时我们不付钱。或者，更糟糕的是：我们认为我们正在偿还债务，但实际上我们积累的更多。 介绍：系统债务 我想介绍一个我称之为 的概念 系统债务 （系统理论中的系统；有关系统理论的更多信息，请阅读 Donnella Meadow 的精彩 思考系统 ）。 是阻碍或负面影响交付的下游债务形式的首要和根本原因——无论是通过业务决策，还是通过技术、架构或流程决策。它是在业务中采取有计划的捷径，将工作放在 系统债务 信用上的产物。系统债务通过其结构设计阻碍了系统的运作。 在系统思考中，梅多斯提供了一个简单的系统示例：浴缸。系统的输入是水龙头，输出是排水管。 Meadows 解释了不同因素如何导致浴缸永远无法装满、保持水平或溢出。最佳系统是水的剩余水平 - 输入（水龙头）和输出（排水）以相同的速率流动。系统债务将是在构建系统时走捷径的结果。用浴缸的比喻来说，也许水龙头安装不当，最终会漏水。也许排水管的位置会导致水在某些区域积聚，因此浴缸永远无法完全排水。也许我们的水需要软化并导致石灰堆积。 在这些情况下，不会立即产生影响，并且仍然可以创建一个最佳系统 - 但隐藏的是债务的积累正在使系统紧张：水龙头必须更快地流动以补偿泄漏，或者水龙头流动得更慢并且浴缸需要更长的时间才能装满。 如果您熟悉 Meadows 的书 - 她的许多示例都植根于现实，模型通常提供静态视觉；系统不会随着时间而改变。这对她的目的来说是完美的，但是当涉及到个人、团队、运营和企业时，我们今天的样子并不是明天的样子。 以稍微不同的方式定义系统债务： 系统债务 = 系统理论 + 成熟度模型 对于软件团队，您可以通过以下几种方式看到系统债务： 随着时间的推移，如果不加以管理，团队会发展出越来越多的“部落知识”。这些表现为善意的习惯、捷径和变通方法。因为它们产生短期效率，它们导致长期缺陷被忽视。如果不付清，就会有明显的知识流失风险。这会导致生产力损失，因为团队必须调整和提升。 或者由于不熟悉而积累的技术债务。 （“乔知道这一点，但现在他离开了——我们将不得不花时间弄清楚。”） （“我们无法更新该组件。Sally 构建了它，但只要我们触摸它，它就会损坏......”） 团队将依赖定制设计模式、非官方开发规则或最大化本地流量的协议，但这些模式很难改变。当某些事情与既定模式不一致时，这会阻碍交付，从而使业务团队成为技术决策的人质。 （“我们不能启动自定义实例——我们从来没有这样设计过。”） 变得自满的团队优先考虑维持现状而不是破坏性回顾。他们可能仍会进行回顾，但如果他们对解决实际问题的能力失去信心，他们只会专注于解决琐碎的事情。 （“我们的事件请求超负荷了，但无论如何 - 我猜我们只需要继续解决它们......”） 尽管存在可解决的摩擦，但达到可持续速度所带来的不适或冷漠。可持续的速度创造了一种错误的效率感。 （“我们真的需要改变流程吗？我们已经大踏步前进了——为什么要破坏它？”） 对于产品和运营团队，您会以类似的方式查看系统债务： 捷径，是让开发团队快速解决小问题，延迟发布，降低速度等 “每个客户的电话都是火警”的 （“我需要团队查看一个愤怒的客户提出的问题，它会只需 20 分钟...") 混乱迫使团队不断切换上下文，并且不能专注于一个问题直到完成。 我说话的最后一个人是我的最高优先级的 当优先级是通过使用误导性指标的捷径时。例如，不再符合业务目标的高额客户。它们在您早期的创业时期是有道理的，但随着业务的成熟，同一个客户变得更加成问题。 （“我们不知道我们是否想留住这个客户，但他们付给我们很多钱，所以我们需要这样做......”） 重申一下：所有形式的债务都是我们现在选择走捷径并打算稍后解决的时候。技术债务是我们用代码来做这件事的时候。流程债务是我们使用正式流程执行此操作的时候。系统债务是我们在组织层面这样做的时候。我更喜欢将其视为“系统债务”而不是“组织债务”，因为将组织视为一个系统，这意味着技术、流程、设计债务都是由系统债务直接引起的。导致我们承担技术债务的因素最终与系统债务有关。 （“在你开始向上游看以确定他们为什么不断落入河中之前，你只能救这么多人免于溺水。”） 开发团队正在发布一个经过适当计划和成本核算的新功能。团队一直走上正轨，但在最后阶段遇到了一个问题，这引发了一个可怕的问题：通过正确解决问题来延迟发布，还是进行最低限度的修复，然后在下一次迭代中正确解决？他们选择承担技术债务： 例如： “我们将在下一次迭代中得到它。” 这就是系统债务开始进入等式的地方。团队真的能够解决这个问题吗？团队是否具备足够的重构技能？企业是否会回应 未来的成本计算是否会显示它现在变得 而无法以正确的方式进行？优先事项的转变或紧急问题的激增是否会突然延迟另一次迭代的修复？ “已经足够好，我们需要继续前进”？ 太昂贵 然后另一个迭代，然后另一个...... 此外，向上游看：为什么遇到问题需要这么长时间？做了哪些糟糕的假设？他们是错误的假设吗？总是有问题直到游戏后期才能确定——但为什么它变成了 发布的问题？承诺是否过早？应该有更大的缓冲区吗？如果 A 人（上游业务销售人员）与 F 人（下游开发人员）在 后更多地交谈，这个问题会得到解决吗？ 延迟 最短的链条 另一个非常熟悉的例子是我们早期锁定的基础设施、架构和托管模型，基于对业务将如何在 3-5 年内扩展的假设。一个小团队可能会选择尽早承担基础设施和架构债务，以支持更快的交付，而不是遵守最佳 DevOps 原则。 当然，很容易在没有细节的情况下描绘这样的场景——但不管这些细节的细节和借口如何：系统债务会累积。这是不可避免的。没关系 - 它只需要持续关注并专注于将其降低到可维护的水平。 补偿捷径 我们承担债务——系统或其他方式——作为捷径。在深入研究系统债务以及如何偿还之前，让我们先退后一步，问我们为什么要走捷径？捷径，就像债务一样，本质上并不坏——但应该仔细分析它们。 考虑物理捷径是一个很好的开始。如果您曾经是行人或骑自行车的人，那么您肯定会注意到事物是如何 当你走路时，你最终会走许多 ，而不是沿着道路走——当然，这些都不是捷径。这些捷径是 最佳路径，他们可以去汽车不能去的地方。事实上，主要为行人密集地区的汽车建设路线是系统债务的[另一种形式]（另一种形式）。 首先为车辆设计的，然后是行人。 “捷径” 行人的 在商业世界中，我们会走捷径来弥补——缺乏时间、缺乏预算、缺乏资源、缺乏责任感或缺乏更广阔的视野。时间、预算和资源都成为人们关注的焦点——但问责制和广阔的视野正是我开头问题的核心： 当你拯救溺水的人时，它是把目光放在上游 并指向不断推动人们进入的人 。 这是否比应该的更难？ （广阔的视野） （问责制） 换句话说：如果你要认真讨论系统债务，每个人都需要参与讨论。 本地化的努力只能到此为止。 那么如何偿还系统债务呢？ 让我们回到之前的问题： 如果您从未考虑过这个问题，那么是时候获取一些指标了！这些指标不一定会给你答案，但它们是一个重要的起点。谈到 KPI，我收到的最好的建议是单个 KPI 既不好也不好。客观上只是一个数字，一个价值。这是您的一切照旧 - 由您决定是否要向上或向下调整该数字。如果您是 OKR 系统或 SMART 目标的粉丝，这很好，因为了解您的 KPI 可以让您制定更容易量化的更好的 OKR。 您的交付团队交付有多容易？ 因此，让我们从一些基础知识开始，然后深入了解。以下内容不是一个完整的列表，可能有更适合您的小组的问题。将此列表视为提出更好问题的起点。 送货： 高优先级/紧急项目的交货期和周期时间是多少？ 低优先级项目的交货期和周期时间是多少？ 您为偿还债务分配了多少资金？ 你的债务增加了多少？ 这些问题对于跟踪团队绩效的任何人来说似乎都很熟悉——但请记住在组织层面提出这些问题。开发人员的提前期可能从创建工单时开始 - 但它在某人的脑海中存在了多长时间？ 资源： 您当前的团队细分是什么（高级与初级）？ 您在高年级和低年级之间流失的风险是什么？ 失去一个资深人士的代价是什么？ 失去一个小辈的代价是什么？ 招聘的成本和期限是多少？ 您的面试/入职时长是多少？ 您的培训/加速期有多长（以及需要涉及哪些资源，因此会失去生产力？） 业务积压： 假设定义了产品经理的战略框架，有多少例外？ 有多少史诗/功能不植根于与财务和时间框架相关的客观定义的业务案例？ 销售/业务开发管道最终如何输入到您的软件积压中，这些的领导和周期时间是多少？ 高层业务目标的变化频率如何？这种混乱对下游工作的影响有多大？ 企业的长期增长目标是什么，团队的技能和资源计划如何协调？ 操作积压 每天提出多少客户问题？ 有多少客户问题需要转到第 1、2、3 级支持？ 解决问题的平均时间是多少？ 客户问题的提前期是多少，从最初的呼叫到创建开发票的时间是多少？ 简单地了解从开始到可用需要多长时间可能非常有启发性 - 当它是客户问题时。 特别是 有许多资源可以帮助改进上述指标 - 但所有这些背后的关键理念是：1）衡量，2）分析，3）解决，4）迭代。第 3 层可以卸载到第 2 层的问题越多，第 2 层到第 1 层的问题越多，第 1 层可以让客户独立解决的问题越多，每个人的工作效率就越高。 开发商： 他们获取源代码并构建需要多长时间？ 您为新开发人员提供凭据的速度有多快？ 他们能以多快的速度站起来并与较低的工作环境互动？ 开发人员将代码发布到生产环境需要多长时间（从雇用日期开始计算）？ 升级您的 SDLC 和流程需要多长时间？ 如果他们在 Sprint 中期开始，他们会在场边坐多久？ 总的来说，你目前的学习曲线是什么？ Etsy 确保开发人员 。 作为比较：Etsy 是效率的一个很好的例子，并且是一个很好的基准。 在第一天就 部署到生产环境 整体看来： 从开始到可用的交付过程是怎样的？制定工作流程——可以优化吗？ 从销售到收入（及以后）的客户旅程是什么？ 什么是 RPO 和 RTO？ 与 所述的高交付绩效相比，业务绩效如何？ Accelerate：精益软件和 DevOps 的科学中 是什么？ 十大噩梦灾难场景 这是联邦快递为改善他们的运营并建立内部“剧本”所做的事情，以使他们成为今天的公司。 鉴于上述所有数字和指标，我将重申，这些数字中的任何一个都代表您的业务照常。虽然它们本质上没有好坏之分，但系统债务使得长期维持这些数字变得更加困难。一些数字可能令人惊讶，并揭示了此类债务可能已经产生影响的领域。 下一步是考虑这些指标如何随着时间的推移而变化——随着你的成熟和继续成熟。举个例子——构建核心产品的工程师将你锁定在一个接近其可扩展性极限的架构中。在这些情况下，团队会考虑如何偿还技术债务——但系统债务呢？鉴于有限的资源、 和成熟的业务 - 您如何在偿还技术债务的同时保持交付 KPI？ 不断增加的损耗风险 “杀死你的宝贝”，解雇你的“摇滚明星”，摧毁你的“隐藏工厂”，停止提供帮助 这些是一个标题中的一堆粗体陈述。这一切的重点是：“有助于”缩短流程可能是危险的。如果我们赞同“衡量什么，就做什么”的想法，那么乐于助人的问题是它往往 。 没有得到衡量 想象一个客户打电话，因为他们移动得太快时不小心删除了门户中的一条记录。他们时间紧迫，无法完成恢复记录的过程。他们打电话给您的客户支持员工，想要提供帮助，立即升级给想要提供帮助的数据库工程师，立即恢复记录。客户很兴奋，NPS 分数上升。一切都很棒，对吧？ 暂时忽略某人更新生产数据库的明显风险，有很多有价值的信息在提供帮助时丢失了： 为什么做如此戏剧性的动作如此容易，以至于客户一开始就犯了错误？ 为什么撤消戏剧性的动作如此困难以至于他们不得不打电话？ 为什么客户支持不能处理它？ 提供帮助和 对生产力有何影响？ 上下文切换 （一个看似简单的 20 分钟任务最终会超过 35 分钟，因为它需要时间才能回到高效的流程中。） 让我们明确一点：我的标题是粗体的。但是，我并不主张反对帮助客户——但是，我认为应该对这些行为进行一些根本原因分析。没有什么过于正式的 - 但可以避免将来出现类似问题。 在一个组织中，我仅仅通过实施一个剧本就将我们开发团队的生产力提高了 50%。客户打来电话，客户支持代表礼貌地迎接他们，他们遵循明确的工作流程来解决问题。如果他们不能解决它，那么我们就有一个反馈循环，这样他们就只会升级一次问题。结果是一个更有能力和熟练的客户支持团队，一个中断更少，整体压力更低的开发团队 - 重要的是，让客户满意。 关键是，当有用的工作发生在阴影中时，您无法解决根本原因。 我们看到 Rock Star 开发人员也面临同样的问题，他们承担了太多的工作和责任来弥补一个低技能的团队 - 只会让他们变得沮丧、精疲力竭并离开（这可能是毁灭性的成本）。威尔·拉森 (Will Larson) 的好书—— ——在如何处理你的“摇滚明星”方面做得很好。 优雅的拼图 少年的力量... 老年人对组织和产品的成功至关重要——但他们同样是最大的风险之一。 例如，高级开发人员将彻底了解代码库。他们知道什么记录在案，什么没有记录。他们会知道它在哪里可以很好地扩展以及它在哪里分崩离析。他们会知道骷髅埋在哪里。我们经常求助于他们——依靠他们来构建和设计功能、架构解决方案，并帮助解决最棘手的错误。他们是可以回答任何问题的知识大师。他们培训和指导初级员工，并在开发解决方案时进行咨询。 可以说，对高级职员的要求很多。考虑到他们的经验以及对组织成功的既得利益，这是一个显而易见的声明。但是，我认为这是我们承担最多系统债务的地方。 任何推进可交付成果的高级职员都是累积系统债务的捷径。 我会重申，因为它很容易被误解。您可以让高级团队成员处理可交付成果，但您必须计划偿还由此产生的债务。 依靠老年人来交付成果是一种失败的模式—— 在当今世界，那里有许多初级和熟练的入门级候选人，中级到高级人员流失的风险既 。 尤其是 高又昂贵 远程虚拟劳动力使任何组织在提升初级/中级团队的同时减少高级员工流失的影响变得更加重要。这并不意味着减少高级职员，但确实意味着方法上的结构性差异。 概括地说，今天的高级团队主要负责系统背后的复杂性：他们的经验和专业知识产生了成熟的系统，而较小的基于任务的组件由更多的初级团队成员实施。 这正是高级团队成员离开时证明有问题的模型，也是累积系统债务的结构。在这种情况下，高级团队负责复杂性，并且可以在初级团队无法交付时提供帮助（以“摇滚明星”开发人员为例）。 当前的员工流失率进一步加剧了这个问题：例如，全国的初级开发人员将在一个职位上工作 （在大公司会更长）。换句话说，当一个初级学生达到可以开始做出更重要贡献的地步时，他们就已经出局了。 18-24 个月 组织将努力留住高级员工，（在某种程度上）努力留住初级员工 - 并且不断遭受知识流失的困扰。最终，这是一场失败的战斗——即使保留了员工，或者有新的团队成员加入，他们现在也不得不偿还大量的系统债务。 让工作更轻松，拥抱不可避免的事情 想象一下一家小型的米其林星级餐厅。主厨非常参与制作盘子，菜肴过于复杂，无法在一组厨师中分发。在这种情况下，厨师 。 是餐厅 将此与更广泛的特许经营餐厅进行对比。您在 Corporate 有一位主厨，他的职责是不生产供顾客食用的菜肴。相反，他们的目标是生产可重复的菜肴。易于复制的菜肴（同时仍然美味）。优化的菜肴使得学习曲线最小化——新厨师可以很容易地被训练来制作菜肴，并且他们最终离开的损失影响较小。主厨还与效率专家合作，研究如何优化特许经营厨房的交付。 这是我们在考虑现代团队时应该使用的模型。高级团队的职责不应该是产品的复杂性。它应该完全专注于简化交付：简化培训和启动、设置时间、构建时间、简化交付周期和周期时间（全面，从销售/产品解决方案，到迭代计划，再到发布）。 如果你知道你只能留住员工 18 个月，你会如何安排事情？事实上，如果你把它们放在一份 18 个月的合同上，最后硬终止，你会如何安排这些事情？你会希望加速尽可能快和短。您希望您的专家团队确保您的新员工可以在几周内增加，以便他们能够最大限度地发挥影响。您需要确保您的专家团队可以保持旋转门，最大限度地提高效率，并且永远不会介入协助（因为有建立债务的风险）。 在建立一个适应性更强、可以接受和利用短期就业的系统时，如果您失去一名高级团队成员，您将随后减少影响，因为知识在过程中而不是在人中变得不朽。 标签，你就是它 谁教你打牌的？无论您身在何处，您都可能从其他孩子那里学会了玩这个游戏。大人不需要教孩子玩标签。 我们认为 是有趣的图像，但模因的最初定义 模因 是一种文化或行为系统的元素，通过模仿或其他非遗传方式从一个人传递给另一个人。 标签是模因。没有人拥有规则。没有人负责改进游戏。事实上，规则很简单，同时仍然支持冻结标签等变体。此外，它可以适应不同的环境。它是为最终变成太酷的青少年的孩子设计的。 像Tag这样的游戏几乎没有系统债务。将 Tag 与其他需要更多玩家或更多设备的游乐场游戏进行比较... British Bulldog、Dodgeball、Duck Duck Goose、Cops 'n Robbers、Red Rover。也许你玩过这些游戏，也许你没有。这些游戏的系统债务略多一些。更多的规则、更多的设备或更多的玩家意味着需要更多的引导者。 那么我们如何才能像Tag一样操作呢？ 利用老年人来 。老年人不在那里玩标签或提供规格。他们的目标是降低标准：人们如何才能更快地训练并更快地交付价值？如何以低影响风险频繁、增量和定期发布？ 降低门槛 （*咳咳* DevOps，敏捷） 绘制流程，绘制流程，并确定阻塞点：也许问题不在于软件团队。也许这并不缺乏专门的测试团队。也许问题出在上游：业务因优先级冲突而使交付管道超载？ 人们休息的动力是什么？休息绝对没有错——但它们通常是对挫折暗流的惊人暗示。跟踪某人离开的时间和原因可以提供非常丰富的信息：也许他们已经离开是因为代码需要一段时间来编译和部署。也许他们已经离开，因为他们需要更深入地思考他们面临的挑战。 也许他们已经离开，因为客户的需求让他们感到沮丧。也许他们需要播出，因为一个新功能正在迫使重新设计或揭示一个错误的假设。 （这不是一件坏事，但问题是否可以被分解以降低复杂性？） 观察缺乏休息：同样说明当某人过于低头时。他们不能走开——需要他们的注意。这要么意味着对某人的依赖太大，要么工作和范围定义得太宽泛，或者底层系统比应有的复杂得多。 建立简化文化。也就是说，你的经理、你的上级、你的中级——每个人都应该有权说：“这比它应该的更复杂——我们怎样才能让这更容易？”收集反馈——尤其是来自低年级的反馈。小学生的价值不够。不要错误地认为他们缺乏经验意味着他们很天真。大三学生可能并不总是知道有更好的方法，但他们非常坦率地知道他们在哪里花费（和浪费）他们的精力。 每当一位资深人士为交付做出贡献时，请找出原因。 prod 中的一个 P0 错误需要紧急修复。低级代码需要更改。客户需要讨论。高管们需要一份演示文稿来更新。 每一个。时间。 涨潮掀起所有船只。老年人应该是潮流，而不是船。 证据就在布丁里 在我的整个职业生涯中，一个指导原则是了解问题如何影响生产力。不是要打造更高效的团队，而是打造更有影响力的团队。产品经理的口号是衡量结果，而不是输出。当您知道自己在做什么时，效率很重要，您只需要更快地完成它。这种影响是一个无定形的、定义不清的、移动的目标。它需要适应。这就是为什么敏捷原则、OKR、精益和看板在正确使用时会如此强大的原因。 专注于系统范围的成果并偿还系统债务让我有机会以各种方式产生影响。 对于 SaaS 业务，从早期的预售阶段到代码部署到生产中，绘制从简单到具体的流程。从每个阶段的角度测量 Lead 和 Cycle Time 以识别瓶颈。将其视为一个系统，然后我们可以确定如何更好地获得资格，更好地取消资格，以及如何以及何时根据客户类型重组销售和实施流程。应用看板方法来拉动工作而不是推动工作，设置严格的 WIP 限制（同时仍然考虑松弛 - 参见 类比），以及形式化完成的定义使我们能够不断改进工作流程本身。最后，在这种情况下，另一个原则是 。在创建加速轨道时，事情可以在可能的情况下更快地进行（即“捷径”），但它总是伴随着对基线流程失败的地方的分析（即偿还系统债务）。这将实施从 6 多周缩短到 2 周并成为一个自我管理的系统。 Goldratt 的 Drum-Buffer-Rope 不允许该过程妨碍生产力 配备 的人员让我在 6 个月内将团队规模扩大了四倍。通过减少启动时间，并让高级团队专注于初级团队的生产力，意味着我们可以 。这种方法让任何初中学生达到 2 年大关时都有两个有吸引力的选择：毕业到一个更中间的角色，当他们继续提高技能时，他们的重点转移到帮助初中生上，或者与团队合作以友好退出。这种透明性有助于消除青少年在面临职业不确定性时所遇到的 2 年之痒。 青少年第一理念 接受不可避免的情况并预测人员流失 将运营和开发团队置于一个流程保护之下。这使团队保持一致，因此它不是平行的工作流，而是循环的：运营团队的输出是开发团队的输入。开发团队的输出变成了运营团队的输入。通过实施具有战略反馈循环的 剧本，团队变得越来越自给自足。这将高级团队从参与运营中解放出来，并将交货时间从 7 个多月减少到 3 周。 “活” 将 SaaS 开发团队的观点从软件开发阶段（定义、实施、验证、发布）转向以客户为中心，强调影响，同时仍然优先考虑最接近完成的工作。这使交付团队能够更好地了解影响和优先级，并使业务能够更加了解和批评低影响的工作/客户。 通过减少构建和部署时间来简化迭代开发过程的投资。这是那些 时刻之一，由于漫长的构建/部署过程的无助，团队经常会离开。重要的是， 并不完全是技术性的，而是基于过程的。通过建立新流程，交付团队的生产力提高了 200%。 “观察休息”的 修复 不为流程效率低下而构建软件。尽管我喜欢编写代码来解决有趣的问题，但新代码应该是最后的手段。即使代码没有捷径，也没有自己的技术债务，代码也需要维护。你引入了更多的系统债务——并没有解决问题的根源。这些案例很猖獗，很容易被忽视——但它们相当于通过在地板上放置一个桶来解决屋顶泄漏。通过解决根本问题来消除这些修复会产生不可估量的效率，并使团队能够处理重要的事情。 但我只是一名中层经理，我该如何实施组织范围内的变革？ 我之前写过，本地化的努力只能到此为止，我坚持这一点。当整个组织对如何提高效率进行批判性研究时，您就会看到真正的改进。本地化的努力只能做到这一点——但他们确实做到了，当他们做到时，他们带来了影响力的资本。 外卖 我将总结这些最终原则： 任何业务捷径（软件、设计、流程或其他）都会产生系统债务。就其本身而言，这是可以的。 太多的债务是一件坏事，需要持续和有意识地偿还。 这笔付款应由高级团队完成。高级团队还应该关注如何降低承担未来债务的风险（首先寻找当地的低效率，然后是系统范围的低效率）。老年人不应该为可交付成果工作，但当他们这样做时应该只做一次。建立反馈循环，询问 “为什么这是必要的，我们将来如何防止它？” 衡量系统债务健康状况的一个好方法是查看初级团队入职人员的健康状况。计划让您的初级团队在 18 个月后离开。没关系。让高级团队尽早提高效率。 鼓励初级团队发现问题的声音。即使是幼稚的问题也预示着更严重的问题 （“我什么时候可以得到我的电子邮件地址？”；“我怎样才能获得测试数据？”；“我们的团队是做什么的？”；“我刚刚拿到了源代码，然后我遇到了构建错误。”） 计划让任何角色的任何人在 18 个月后离职。这也可以。高级团队应该在那里致力于构建流程和管道，以 情况下实现持续交付。他们应该建立自给自足的流程、自管理和自组织的团队。初级团队最终应该对工作感到厌烦，因为它变得重复了。团队成员应该不断地、积极地让自己变得多余和不必要。 在中断的 为那些将停留超过 18 个月的人制定计划。尽管努力使自己变得多余，但您永远不会用完可以提高效率的工作。定义一个 ，将初级到中级，中级到高级，与以结果为中心的效率相一致。 职业框架 把第一天当作最后一天对待：工作的第一天，员工对入职工作有最好的了解。他们应该想：如果我离开后还有其他人加入，这将如何改进？ 定期举行仅限愚蠢问题的会议。允许人们（匿名）提交他们最愚蠢的问题。通过这种方式，您会发现最大的知识差距（和问题）。这些应该得到解决。 安排定期的“偿还”会议：将高级团队聚集在一起，寻找效率低下的地方。付出他们的影响。花费他们的分辨率。 （此列表是您的高级团队永远不会用完工作的原因。） 敏捷最重要的部分是它的适应性。经常调整。有反馈回路。以前有效的东西并不总是有效。这不是问题——这是常态。任何抵制持续变化和实验的人都比他们意识到的问题更大。 最后，也许最重要的是：这不是“团队”练习。这应该是全公司范围的活动。虽然您可以在团队中提高本地效率，但它们只能做到这一点。话虽如此，如果您无法影响整个组织的方法，请获得经理的支持，然后围绕您的团队创建章程，使您的团队免受外部因素的影响。与您的经理一起定义较小系统的范围、输入和输出，并让他们批准您计划如何评估、增加和偿还系统债务。 就这样！ （他写道，承认写了他最长的文章完全具有讽刺意味。）