为什么角色不是规则

产品开发日益协作。但作为一名工程师，协作意味着什么？它首先要跨越代码边界，超越我们的角色和职责的限制。以下是我们如何在 Figma 工程团队中找到自己的协作最佳点，以及帮助定义我们工作的原则和流程。

马库斯·奥克利绘制的插图

我于 2016 年作为承包商加入 Figma，当时我们有 12 名工程师。在加入之前，我承认我对我们能否在网络浏览器中构建协作的高性能工具持怀疑态度。现在，这感觉就像是上辈子的事了，但当时，人们重新重视应用程序和移动设备，并对其感到兴奋，并且在构建不辜负本地同行的网络体验方面进行了许多值得注意的失败尝试。在技术和文化变革的推动下，Figma 发生了重大转变，才成为可能。较低级别的浏览器 API（例如 WebGL 和 Web Assembly）的引入使我们能够重新构想网络上的可能性。伴随着 Google Docs 等工具成长起来的一代人，以及最近几年的混合和远程工作加速了这种情况，

如今，我们的期望是我们的工具默认越来越多地支持多人游戏。改变的不仅仅是我们对工具的期望，还有我们彼此之间的关系以及我们对彼此的期望。从早期作为承包商编写代码，到领导团队，我思考了很多这对工程师的独特意义。随着产品开发变得越来越非线性，我们的角色如何演变

？作为一名工程师，协作实际上应该是什么样子？这总是一件好事吗？

很容易陷入极端。如果密切合作会带来更好的结果，为什么我们不想不断获得反馈和迭代呢？从广义上讲，我发现利用他人的智慧与没有明确自己的方向而原地打转之间存在着微妙的界限。在实践中，有时我们需要更加独立地工作，有时我们应该不遗余力地让其他人参与进来。我从经验中了解到，发散和聚合之间的理想平衡对每个人来说都是不同的。关于您的文化、您正在构建的产品以及您正在优化的内容。当您找到正确的平衡点时，我想分享我们如何看待工程和产品开发中我们自己的协作最佳点。

产品开发不再是从设计开始到工程结束。尽管如此，在许多组织中，产品经理和设计师负责制定路线图，而工程师则按照该路线图执行。这是我和我的产品团队同事 Yuhki Yamashita 想要解决的问题。我们合作非常密切，这也影响到了我们组织的其他部门。工程师不仅定义如何制造东西，他们还通过与跨职能同事密切合作并听取客户的反馈来弄清楚要制造什么。

当谈到开始新的工作流时，我们总是鼓励团队尽早从多种角度汲取灵感，从而允许概念文档根据产品开发团队其他成员的输入不断发展。工程师应该写下早期的想法，目标是在合作者正在研究的过程中获得反馈，而不是在感觉“完善”时获得反馈。事实上，每个项目都有某种类型的文档来记录这种早期的想法；挑战在于，当团队冲刺自己的工作时，如何从团队那里获得快速反馈。

这就是为什么我们在设计和工程组织中定期举行工程“批评”：以确保始终有专门的时间和地点从其他团队获取反馈。工程临界点起着非常特殊的作用。这是一个尽早且经常征求反馈的地方。这是一个获得技术设计专家支持的论坛。这不是一个批准过程。工程师批判会议中没有决定或解决任何事情，这是设计使然的。目标是帮助将设计提升到不需要批准的程度。我们使用figma.net.cn/lm2/3383.html">FigJam来举办这些会议，以便每个人都可以实时参与——会议非常有趣！

工程关键不是批准过程，而是尽早并经常从其他团队获取反馈的时间。我们鼓励批评参与者接受 WIP 工作并富有成效地指出问题，而无需急于做出决定。这是我们在Figma 使用的模板。

但是，当输入太多或反馈相互冲突时会发生什么？我见过一些项目因为没有正确地结合生成性和探索性以及推动事情向前发展而脱轨。当存在困难的权衡和很多模糊性时，这尤其困难，比如定义你的第一个定价模型；太多相互竞争的观点和新想法很容易陷入困境。

这就是为什么我们将项目分解为里程碑。这听起来可能很简单，但明确定义和沟通里程碑有助于我们管理与其他利益相关者的期望，并提醒我们何时需要为了进步和动力而汇聚在一起。动力是一个非常重要的东西。当我们有动力时，我们感觉离目标总是只有几步之遥。当我们失去动力时，我们就会开始旋转并质疑我们正在做的事情。

在Figma，里程碑不仅可以帮助我们在团队内集中精力，还可以让我们发现事情何时无法跟踪跨团队的计划。通过在事情面临风险时尽早进行沟通，我们可以互相借用专业知识或资源并重建动力。这正是更多输入有用的时候。有时，如果我发现一个项目陷入停滞，我会投入其中。当我仅仅因为我的头衔而深入特定领域时，人们仍然会感到惊讶，但重要的是我们要互相帮助解除障碍，而且我们中没有人会过度关注。远离让我们脚踏实地的细节。

在基础层面上，我喜欢将 Figma 的工作视为一棵依赖树。叶子可以迅速变化，对树的其他部分几乎没有风险，但根必须坚固。当您在根级别确定项目范围时，考虑因素与叶级别的考虑因素有很大不同。如果您正在构建数据库，您当然不想独立进行并“快速行动并打破常规”——与在较低级别的系统上工作时相比，您必须更加考虑如何获取正确的输入技术堆栈中更高层的东西。如果您正在开发的功能会更改界面但不影响底层数据模型，则更独立地进行实验通常风险较低，但您仍然不应该为用户“破坏东西”。

产品变更通常也是根节点。例如，当我们考虑新的设计基元（例如自动布局）时，我们必须确保我们对公开的新属性确实有信心，因为事后更改它们可能会破坏现有的工作流程和设计。我们许多最重要的发布和技术成就都要求我们从整个分支到根部进行思考，超越单一框架、语言或抽象边界。