Pluralsight的固定时间/固定范围工程工作

作者：Margarita Dekoli-2022年4月6日

10分钟 - 1926字

可以说，工程师最常问的问题是："这东西什么时候能完成？"而在我们的工程原则文件中，我们却规定 "我们不做固定时间/固定范围的工作"。难怪，这是我们组织中不同部门最常问到的问题之一。"如果我们没有一个固定的时间点，我们都能同意一些东西将为我们的客户准备好，我们怎么能达成协议或签署合同？"

为了回答这个问题，我们首先需要把它与我们的一些原则和实践联系起来。

"我们为价值交付而优化"

我们优化流程效率的方法之一（精益框架）是去除次要工作。例如：我们不保留详细的积压工作，也不举行 "积压工作梳理 "会议。我们不会花很多时间去安排那些没有积极开展工作的工作。当然，在产品路线图层面上会有功能的规划和协调。不过对于开发来说，作为我们精益方法论框架的一部分，我们实行**"及时 "**发现和设计一个功能或卡片。

与 "及时 "工作相反，估算（我们可以同意时间表的主要过程）需要提前完成一定程度的技术发现。花在技术发现上的时间越多，我们对我们的估计就越有信心，尽管只能达到一定的程度；有些功能只有在团队开始工作时才会显示出其复杂性。此外，还有发现工作在实际工作准备开始时变得过时的风险。

使功能评估复杂化的因素之一是功能或项目所涉及的代码库的成熟度。旧的代码库在试图做一个看似简单的更新时可能会有很多陷阱。我把老的代码库比作 "这个老房子"（一个与建筑有关的电视连续剧，剧组对老房子进行更新）中的一集，根据墙后发现的问题（火灾隐患、系统故障等），移动一个插座一英尺就可能导致一半的房子被重建（！）。另一方面，一个新的代码库可能会给团队带来不可预见的问题或挑战。一个新的代码库，就像新的建筑一样，相当于同时在设计和建造。有些设计可以提前进行，但很多东西是在建设的时候决定的。通常这个过程有一百万个小而重要的决定要做，有时是在一天的时间里。对于这些决定，我们需要整个团队都在场，并在权衡中做出选择。这是我们工作方式的一部分，也是我们的配对和聚餐实践中烘托出来的过程，目的是让每个人都了解决策，并获得每个人的意见和想法。在这样的情况下，过程（和进展）有时会很慢，因为我们优先考虑的是团队和代码库的弹性，我们利用它来对抗开发的速度。

"我们有权力和责任"

通常情况下，一个功能或项目不可能完全在一个团队的范围内完成。在这种情况下，遵循围绕团队如何工作的一系列原则，会带来新的复杂性。让我们以一个新项目或用户旅程为例，它需要由至少两个不同的团队来实施。这两个团队需要选择如何解决这个问题，但也需要确定合作的方式；也许分享一个页面的所有权和功能，或者制定一个解决方案，在跨BC通信失败或错误的情况下，尽量减少对彼此的Bounded Context（BC）的依赖。

在这种情况下架构一个解决方案是一个创造性的过程，可能需要自己的头脑风暴、成本效益分析、替代设计制作、综合和协议。大多数情况下，更安全的解决方案需要投入最大量的时间和精力，但也会在我们系统的稳定性和可维护性方面得到回报。

这种努力的副作用可能包括重新确定每个团队工作的优先次序，甚至可能重新制定与其他团队的协议或商业承诺。OKRs和产品路线图也会通过这个过程受到影响。

"我们创造并维护心理安全 "和 "我们创造出让我们感到自豪的高质量产品"

对于我们这些在客户服务、咨询和/或作为承包商工作过的人来说，我们可以告诉你，估算的艺术（为了满足商定的时间表）会引起强烈的负面情绪，尤其是焦虑，因为估算的准确性。

为什么？

在一些企业中，对时间和精力的估计是计算成本、价格和客户账单的主要方式。因此，它们必须尽可能地准确。然而，估算是一个不准确的过程，可能会出现偏差，造成不利的后果。

通常情况下，个人加班需要尽快完成，否则就会有倦怠的危险。
企业将不得不投入时间和精力来控制损失。
没有人因为额外的时间和努力而得到补偿。
对延迟负责的人或团队可能会觉得自己是个被抛弃的人。

Pluralsight的工程是我们努力将上述常见做法转变为非常不同的叙述方式的一部分。团队使用OKRs，以及产品和技术路线图，以支持公司的战略目标，并承诺时间表（颗粒度为季度级别）。影响这些目标的额外工作和/或时间敏感的工作，在被添加到团队的工作量之前，会仔细审查其有效性和成本效益。所有参与这项工作的团队都同意时间表和范围。协议是（重新）达成的，参与该过程的每个人都了解高风险点。灵活性，以及对步骤的明确所有权和对决策框架的良好使用，如RAPID，有助于支持所有的努力。

风险

你可能会问：**"当估算出错时，真正的问题是什么？为什么我们不能投入一些额外的工作时间，或多几个人（或一个团队）来处理？"**在一个过程中加入更多的人，主要的问题是这个过程首先要放慢速度，而人在上岗后才能加快速度（神话中的人月）。

作为工程师，我们的出发点是 "创造我们引以为豪的高质量产品"，但有时在紧缩模式下，时间的权衡太大，无法绕过。在紧缩模式下工作的结果，将不可避免地比其他代码库积累更多的技术债务（即更多的代码需要重构，代码注释可能揭示了对2.0版本的需求，或者我们的解决方案不会扩展到通用解决方案）。

缺乏可扩展性也可能是一个代码库在紧缩模式下工作的副作用。我们正在解决的用例是我们现在面前的用例，我们可能没有考虑到未来需要支持的更普遍的用户案例。我们需要理解其中的利弊得失，并且需要所有的利益相关者同意一个解决方案。

多个团队所拥有的功能之间的相互关系越复杂，一个团队就越容易在他们的业连上实施一个解决方案，而这个解决方案最好由另一个团队/业连来拥有。这样一来，一个BC可能最终**拥有的功能首先需要被转移，然后由适当的团队进行迭代。**这个过程违背了我们快速交付价值的价值观。

任何**"边飞边造飞机 "**的过程都包含了不断的对话或范围协商，因为新的或更明确的需求在新功能周围形成。每次对话都可能导致对部分代码库的重新评估或重写。

一个对时间敏感的交付物可能会危及企业的长期战略目标。**紧急 "与 "重要 "**可能会被混淆，错误的事情可能会被优先处理。这种情况时有发生。有时是因为人们处于客户或大合同的紧要关头，有时是因为恐惧和惊慌占据了上风。

最后但并非最不重要。有时范围的变化看起来无害，但对于每一个例外，都可能有一个未来，即例外没有被传达给每一个参与的人或团队，而沟通不畅和不一致是自然的后果。

缓解风险。我们每个人可以做什么来帮助？

我们承认，有时候，当被问到 "我们能做X吗？"这个问题时，答案不可能是 "不能"，但我们会尊重地挑战基本假设，以便我们能共同达成一个优雅的解决方案和协议。
在提出估计时，我们会留出足够的缓冲时间。
我们尽最大的努力来确定工作的优先次序，以便为其他有更关键或时间敏感的工作需要完成的团队解围。
我们为这种类型的工作记录功能或技术规格，并在任何转折或新的决定中保持更新。
我们让所有受协议影响的团队参与到协议的制定中。这似乎是不言而喻的，但参与的团队越多，就越难在关键时刻让所有人都参与进来。
我们提供所有部分所有权的明确性，我们提供RAPIDs，这需要一些时间来建立，但效果很好。
我们对外部客户有一个共同的立场，我们试图提供细节和错综复杂的文件，以便收入和领导层能够有效地解释和倡导基于细微差别和权衡的问题。
我们尽量减少额外的范围蠕变，我们尽量避免对任何与功能或产品有关的问题进行不断的 "即时 "发现，因为这干扰了团队的注意力和速度。
在这种工作完成后，我们允许团队有时间来处理可能已经积累的技术债务，我们反思哪些地方做得好，哪些地方做得不好，以便更新我们的做法。

尽管做出了最大的努力，或者即使所有的风险都得到了缓解，在固定时间/固定范围的工作中，我们可能会面临一个不可能的最后期限。在这种情况下，透明度、频繁的沟通和创造性的解决方案将被优先考虑，以减少对团队和业务的影响。向我们的客户解释制约因素和转折点有很大的作用。我们已经看到大客户同意将产品的全面发布推迟一个月或更长时间，因为在这一过程中遇到的问题。

总之，我们想邀请Pluralsight中所有参与签署交易的团体，在思考问题时多一点灵活性。我们能不能对时间表的进展有所创新？我们能否在合同中加入语言，以便在发生 "完美风暴 "的情况下保持灵活性？(想想一个假设的场景，即大流行病+重组+自然减员+招聘冻结同时发生）。我们可以在合同中加入什么内容来缓解一些最终的交付成果？我们可以重新制定一些协议吗？

注：这篇文章是与卓越中心合作创作的，特别是在Todd Fisher和Markus Neuhoff的帮助下。

分类：文化

标签。 Pluralsight的工程,规划,卓越技术