GEAR框架: Tractian的敏捷工程文化

GEAR(齿轮)框架是工业初创公司TRACTIAN提出的敏捷开发框架，强调一切以人为中心，客户需求为最高优先级，互动胜于流程的开发文化。原文: The GEAR Framework — Tractian’s Agile Engineering Culture

怎样打造专注于人的卓越性和敏捷流程的良好开发文化？本文将介绍使TRACTIAN成为世界上发展最快的工业创业公司的独特开发框架。

0. 目录

1. 宣言
2. 原则
3. 团队
4. 实践

1. 宣言

为什么提出GEAR?

Scrum已经过时了: Scrum在20世纪90年代早期由Jeff Sutherland和Ken Schwaber推广开来，是敏捷文化的良好开始。最初被认为是"用一半时间做两倍工作的艺术"，今天，应该被重新表述为"做两倍计划和一半可交付成果的艺术"。

Scrum原则试图通过建立对经验过程的控制，并将所有内容限定在相同长度的"sprint"中，从而使开发变得可预测。但与此同时，很快就出现了裂痕，因为并不是每个特性都能被分解成相同长度的子任务。在一些sprint中，开发人员很快就完成了任务，无所事事的等待仪式结束，而在另一些sprint中，时间却不够用。

随着时间推移，Scrum创造了一种以过程为中心的开发文化，忽略了创造力，把客户期望放在了一边，不鼓励/忽视修复随机出现的错误，敏捷文化的最大特色——响应变化而不是遵循计划——被忽视了。

遵循套路可能会让人感觉舒服，但如果涉及到设计，我们认为围绕当前环境进行设计比满足先前的一致性更好。在看了其他方法以后，我们发现最终都会陷入类似的问题，即方法过于关注计划和过程，而忽略了适应性、创造力和敏捷性，从而破坏了敏捷原则。

由于没有找到可用的方法，因此有必要基于我们自己的价值观和做事方式来定义自己的技术。GEAR框架使我们摆脱了痛苦，并完全准备好取代传统框架，帮助我们得到想要的结果。

2. 原则

我们相信什么?

原则#1: 始终坚持"优秀"而不仅仅"够好"

这听起来可能不言而喻，但在现实中，有各种各样的压力可能会导致你交出平庸甚至可疑的工作。我们承诺过这个功能！我们花了很多时间！这并不那么差劲！从用户角度来看，其实没什么问题吧？

开发这个功能的时候，假设在产品发布之后，不能改变产品中的任何内容。这带来了一种感觉，即每个特性都是最终产品中最重要的部分，如果在交付后不能更改，那么显然需要尽最大努力测试每个用例，即使这需要比计划的时间长一点。请注意，并不是说一定要完美，而是说要"打造到最后"。

原则#2: 对客户的痴迷超过对工程的痴迷

人们很容易高估想法的价值，特别是当这些想法来自工程团队的时候。避免为了自己学习而陷入好奇心，而忽略了在特定时刻什么才是对客户有价值的东西。

专注于编码会夸大寻找"正确"方法解决问题的重要性，而不是理解问题的重要性。

在着手解决编码问题之前，必须确定问题是什么，以及是否真的是一个问题。如果让自己专注于如何通过代码解决问题，而不管这是否是编程问题，看不到"为什么"，最终什么也得不到。

在被过度设计的浪漫迷住时，不要忽视现实，必须花时间建立对问题领域的理解，必须适应这一事实: 你是问题解决者，而不仅仅是"填充框架"的开发人员。

原则3: 优先级高于方法

真正重要的想法会在脑海里回荡。最后一次忘记那个伟大而鼓舞人心的想法是在什么时候？如果不是那么有趣(也许是客户不时遇到的bug)，当客户再次抱怨或新客户也遇到这个问题时，就会重新引起你的注意。如果只听过一次，也许并不是什么真正的问题。如果一直听到这个问题，就会有动力制定解决方案，并在下个周期争取时间解决这个问题。

这种方法分散了优先级和跟踪任务的责任，并使其易于管理。来自不同部门的人可以提出他们认为重要的事情，并使用任何对他们有效的方法来跟踪。

我们不必选择是不断添加繁重的待办事项列表还是把发生过的事给忘掉，每个人都可以在没有待办事项列表的情况下独立跟踪询问、bug、请求或任何自己想做的事。

每次讨论总是新鲜的，任何带来的东西都有其相关背景，和某人及其目的相关，每件事都有目的、及时有效、适合当下。

原则4: 调整截止日期而不是限定时间

要知道哪些特性重要，哪些特性可有可无，并据此制定计划。计划就是猜测，计划越长远，猜测就越糟糕。考虑用周计划代替年度计划。定了三年计划？改为制定3周计划吧。定了10年的计划吗？先定10周计划吧。经常做计划，而不是很少做，计划越近，就越准确。

正如艾森豪威尔所说: 计划没用，但必不可少。

原则5: 互动胜于流程

GEAR模型侧重于围绕工作进行组织，而不一定是流程和仪式。当涉及到如何工作时，给组织更大的灵活性。GEAR不要求团队改变工作方式(例如"必须进行scrum")，而是专注于让团队成员彼此保持一致，并朝着单一结果前进。

部门之间定期但不频繁的一对一交流有助于交流下一步想法。例如，技术支持可以告诉产品他们所看到的最重要的问题，然后产品可以作为潜在的项目独立跟踪，也许只是挑了其中最重要的问题来解决。然后，在未来的一对一中，支持人员可以再次为尚未得到关注的事情进行游说。

3. 团队

人们如何互动?

组织职能

当我们谈论构建优秀的产品时，团队中的有两个明确的功能，远远超出了职位或角色，涉及到每个团队成员看待自己的任务和范围的方式，使某些人更专注于某些类型的任务。在这种类型的组织架构中，根据角色和技能将团队组织成更小的小组或部门，这些小组内部的职位，称为专家(Functional Experts) 和多面手(Product Generalists) 。

• 专家: 专家是那些对某个主题或产品有完整背景和/或深入了解的人。专家能够比其他人更快更容易打破复杂的技术障碍，因此他们在产品构建过程中必不可少，没有他们，任何复杂的功能都不可能开发出来，尖端产品只有专家才能制造出来。
• 多面手: 多面手是指拥有一套技能的人，能够在多种不同的环境中快速连接，能够识别范围之外的问题，甚至在多种情况下及时做出贡献。多面手根据需要从一个任务转移到另一个任务，解决各种各样的问题，让专家专注于更大更复杂的任务，这样产品就永远不会失去进展和支持。

当一群人在一起工作时，有必要划分职能，选择一些人来执行，另一些人来管理和组织，这就是我们所说的创造者(Makers)和管理者(Managers)。

• 创造者: 负责实际执行，专注于活动的建设和进展，打造新功能，并尽可能以最好方式修复有问题的功能。
• 管理者:　负责活动的管理、组织、优先级和分配，在某种程度上，避免带走制造者的注意力和焦点。

值得注意的是，领导者的概念不同于创造者和管理者的概念，创造者可以是领导者，就像管理者可以是领导者一样。从概念上讲，领导者能够通过实际行动或以身作则来指示方向，激励行为和决策。

领导者的角色与所做工作的质量和重要性联系得更紧密，而不是职位本身。所有人都应该以成为领导者为目标，以身作则，在任何时候都朝着正确的方向前进。与人们普遍认为的相反，绝大多数领导者都是创造者，而不是管理者。

沟通原则

• 快速沟通: 通过消息和对话等，尽可能快速直接分享信息和知识，不需要等到会议才来分享需要分享的东西。
• 拥抱冲突: 说出需要说的话，即使可能会引起争论，最好是明确你的观点，拒绝流言蜚语或谎言，但记住所有讨论都应该确保参与者之间的相互尊重。
• 不需要打招呼: 以明确、直接的方式表达需求和意图，谈论工作时，用尽可能少的信息表明意图和重要性非常重要。越快提出问题，就会越快得到解决方案。
• 陈述显而易见的事: 重复明显的信息比犯明显的错误要好，简单的事情需要经常被记住。当电梯门打开时，如果有明显的提醒标志，就会记得检查一下电梯是否在里面。
• 不同意但仍然给出承诺: 达成一致很舒服，但全体一致不是我们的目标，正确的决定才是。这就是为什么我们会花时间去思考、辩论、说服、倾听和重新考虑，然后做出决定。如果你不同意，没关系，但一旦做出决定，就应该做出承诺并完全支持。
• 不断提问: 如果有疑问，就去问！如果问题已经是某个已经被解决的问题，那解决这个问题的人可以与你分享理想的解决方案。
• 尊重高于一切: 意见不一致绝不是不尊重，任何沟通都必须尊重道德原则，不能导致任何形式的歧视、迫害或暴力，对待同事的方式必须尊重他们的个人需求和独特性。

4. 实践

平时应该怎么做?

如果有人想在实践中应用GEAR框架，就必须采用一套特定的日常行为，并且清楚知道，什么样的行动和策略可以与该框架成功合作。这些行为可以概括为:

首先打造发布产品的能力: 发布好产品需要纪律和牺牲。在担心对研发流程的改进之前，先建立发布产品的能力。也许你拥有世界上最好的客户洞察，但如果不能把它变成项目并发布，就没有任何意义。首先，让团队有节奏的完成任务。一旦有能力发布产品，就可以开始改进流程。

处理发布后的问题: 所有紧急问题都必须被修复，这需要一定的灵活性，能够停止正在做的事情，转而修复出现的问题。问题有时可能很简单，很难被人注意到，有时可能非常紧急，会给某个系统的用户带来巨大问题。总之，所有需要纠正或调整的东西都是bug fix，无论其复杂程度或影响如何。同时也必须注意"实质性"界限，因为几乎所有发布的东西都会收到一系列反馈，如果是实质性问题，那就实事求是的承认，把新开发暂时搁置，修复现有问题。

速战速决: 所有获得更大收获的特性或变化都是通过低成本的行动、低执行复杂度和高收益来实现的，通常来自于最意想不到的地方。

通过必要功能打造长期价值: 复杂的更改和新功能必须被划分成更小的部分，以提高敏捷性和构建的清晰度。这些变更可能源于创新，或用以弥补潜在的问题，并伴随着某些计划。与速战速决不同，必要特性具有较高的实现复杂度和/或高成本操作，但也具有较高的收益。

内置重构: 主要代码或产品重构总是在构建必要特性或快速修复的过程中完成，必要特性和快速修复永远不应该因为重构本身而停止，如果是新特性的一部分，只需要通过工程视角来寻找未来的用例。

避免边际思维陷阱: 如果你需要一台机器却不买，那么最终会发现已经为它付出了代价，却没有得到它。(亨利·福特)

完成意味着交付: 如果客户手中的产品没有处于最佳状态，那就还没有完成。你是否完成了你所负责的部分并不重要，产品只有在交付给客户后才成为一个整体！

坏的结果是好事，但坏的决定不是: 糟糕的结果是有创造力的公司的自然部分。当我们探索新想法时，总会有一定的失败的可能性。然而，我们需要对产生这些决定的过程持批评态度。如果决定是正确的，但导致了糟糕的结果，那仍然有值得庆祝的东西。我们基于拥有的数据做出了最好的决策，最终会在下一次做出更正确的决定！但是，如果忽视正确的过程，却意外得到了正确的结果，也没有什么好的，那只是运气而已，不能指望取得长期成功。

发布原则

当突然出现问题或新需求暂停了手头的工作时，确实令人沮丧。三个星期前你怎么不提？是的，尽早获得反馈确实更好，但通常是不可能的，因为问题或需求直到真正遇到才会表现出来。那是我们真正思考的时候，真相会随之喷涌而出。

但无论暂停工作是多么令人沮丧，更令人沮丧的是发布一些不适合所有人的东西。一旦作品发布出来，就很难再把它收回去了。

• 首先，让它工作: 确保基本功能、行为和属性证明该特性可以出色的实现。构建复杂内容的最简单方法是定义并划分小块任务，这些任务加起来可以构建更复杂的功能。
• 在发布之前，确保正确: 确保功能、行为和属性清晰，并符合质量和维护原则。更重要的是，保证发布的东西从根本上是正确的，而不只是因为简单就把东西发布出去，确保发布的东西不会惹恼任何人。如果能早点把事情做好就更好了，但当现实情况不允许时，如果情况不对，仍然要让事情停下来。
• 最后，越快越好: 确保功能、行为和属性满足财务、容量和质量要求，最小化成本和响应时间，最大化性能和可伸缩性。

由于良好构建的功能、产品的流程及细微之处实现的非常准确，因此可以被快速复制/改进，而不需要任何类型的文档或复杂的流程。

我们最深刻的信念是每个人都有兴趣改变世界

幸福就是你不希望结束的每一刻，就是当你意识到生命的神奇并觉得应该永远存在的那一刻，就是你希望感觉成为永恒的那一刻。

我们的意图和努力都集中在这一理念上，不仅仅是一起工作，而是想要你和我们一起享受每一刻，希望它是永恒的。

这是一份持续更新的文档，只有一个框架是不够的，必须提高批判性思维。以下是一些参考书目:

• 基业长青 - Jim Collins ^[1]
• 从优秀到卓越 - Jim Collins ^[2]
• Shape Up - Basecamp ^[3]
• Cultura de Excelência - David Cohen ^[4]
• 亚马逊逆向工作法 - Colin Bryar/Bill Carr ^[5]
• 零规则 - Netflix ^[6]
• Posthog Handbook ^[7]
• Spotify工程文化 ^[8]
• How Apple is Organized for Innovation ^[9]
• Brex Decision Making ^[10]
• Please Don't Learn to Code ^[11]

你好，我是俞凡，在Motorola做过研发，现在在Mavenir做技术工作，对通信、网络、后端架构、云原生、DevOps、CICD、区块链、AI等技术始终保持着浓厚的兴趣，平时喜欢阅读、思考，相信持续学习、终身成长，欢迎一起交流学习。
微信公众号：DeepNoMind

参考资料