团队协作设计：跨职能协作的产品开发实用指南

在产品开发过程中，跨职能协作能够帮助团队更快地理解用户需求，并持续交付更有价值的产品成果。然而，跨职能协作究竟应该如何开展，并不总是显而易见。一个团队要想真正协作成功，需要哪些具体实践？又应该秉持哪些共同价值观？

我们是开发人员 Valerie 和设计师 Christopher，都热衷于跨职能结对协作。我们曾在分布式团队中，在高压、紧迫的交付环境下，实践过本文提出的所有建议。当时，客户公司内部设计资源有限。即便交付期限非常紧张，我们依然找到了优先学习、持续实验的方法。在这篇《团队设计指南》中，我们将与你分享这些做法。

本文将介绍跨职能协作在产品开发中的具体案例，也会分享支撑这些实践的价值观和原则。我们希望这些内容能为你的团队带来启发，并拓展你对设计如何在业务流程中创造更大价值的理解。

如果你符合以下情况，本文会很适合你阅读：

• 你是一名设计师，正在尝试定义设计敏捷性如何贯穿从战略到执行的全过程。
• 你是一名产品经理，需要厘清自己的角色与设计师之间的边界和协作方式。
• 你是交付团队成员，例如开发人员、质量分析师或项目经理，正在思考：“设计到底是什么？我为什么要参与设计？又该如何参与？”
• 你是一位团队负责人，正在思考如何打造正确的产品，以及如何正确地打造产品。
• 你正在寻找具体示例，帮助团队打破产品开发中的信息孤岛，并更快地向用户交付新功能。

跨职能协作为何重要：脱节的工作流程

克服组织惯性并不容易。设计、业务和技术部门之间的信息孤岛，会拉长从发现问题到交付方案的反馈周期。如果缺乏跨职能协作文化，团队就很难跟上业务与用户需求的快速变化。

如今，将以人为本的方法引入技术开发的路径有很多，例如精益用户体验、敏捷体验设计、平衡团队、以人为本的设计、设计运营和设计思维等。除了强调以人为中心，这些方法还共同关注一点：衡量成功的关键，不应只是交付了多少功能，而应是创造了怎样的结果；而跨职能或跨学科协作，正是实现这些结果的重要驱动力。

如果你在面对这些方法论时感到不知所措，你并不孤单。如果缺少把战略转化为战术的模型，你可能会不断怀疑：我们现在的做法到底对不对？

也许，你所在团队目前的设计实践是这样的：

• 产品经理从业务专家那里收集需求清单，然后转交给设计师。
• 设计师独自绘制高保真原型，却没有获得任何真实用户反馈。原型上传到故事卡片后，就再也没有被更新过。
• 开发人员把设计稿视为像素级精确的规范，却不了解底层交互设计，也不知道这项工作如何融入整体用户体验流程，因此很难提出真正关键的问题。
• 质量分析师在不了解预期结果的情况下测试应用行为，例如不知道这些功能将如何解决用户问题、支持业务需求。
• 没有人衡量最终交付的服务是否真正为用户创造了价值。

在上述情境中，不同角色之间的互动非常有限，而且通常并不在同一个团队内进行。即便如此，他们可能仍会说自己身处一个“协作环境”。这种说法并非完全错误，因为最终成果确实来自多方共同努力。但这并不是我们所说的跨职能结对协作。这种各自独立的工作流程，本质上仍然以交接为中心。而交接，恰恰与真正的协作背道而驰。

创新与同理心：团队协作设计的基础

打造以人为本的优秀产品，首先需要我们与用户建立同理心，也需要团队成员彼此之间建立同理心，并能够快速响应我们发现的用户需求。我们可以从创新的三个视角来理解这一点：

• 我们试图满足哪些需求？也就是说，我们的解决方案是否有价值、是否令人向往？
• 我们如何实现它？也就是说，我们的方案在技术上是否可行？
• 我们能否持续推动它？也就是说，我们的方案在业务上是否可持续？

同理心贯穿我们研究和理解问题的三个维度。我们通过同理心理解用户，从而更深入地判断产品的价值性与可用性。我们也通过同理心建立团队内部的信任，促进更有效的协作。借助协作所建立的信任，我们进一步理解产品在目标市场中的价值性和可持续性。所有这些，都属于设计的范畴。我们能够从用户和彼此身上学到很多，因此我们坚信团队协作设计的力量。

创新的三个视角提醒我们：我们的目标是创造有价值、可行且可持续的事物。要实现这一目标，我们需要在团队内部，以及与我们所服务的用户和社区之间，倡导同理心和信任。

在我们的方法中，设计是一项共同责任。这意味着团队需要对用户旅程形成共识，并肩协作，充分发挥每个人带来的不同技能和视角。我们所交付的成果，本质上代表了关于价值性、可行性和可持续性的假设，而这些假设还需要在真实生产环境中接受进一步验证。否则，产品经理只能凭空猜测用户需求，设计师只能提交缺乏解释的 UI 规范，开发人员也只能在不理解背景的情况下编写代码。

均衡的团队构成，对于高效的跨职能协作至关重要，因为它能帮助我们发现原本可能被忽略的学习机会。设计师与开发人员的组合，例如我们两个人，往往能推动这种协作模式的发展，因为这种组合带来的价值非常明显。但其实还有更多可能性值得探索：质量分析师和设计师搭档时，我们能学到什么？产品经理和开发人员搭档时呢？设计师和站点可靠性工程师搭档时呢？开发人员和客户支持人员搭档时呢？

当设计成为一种团队实践时，我们也会开始重新审视各自的职责，并思考每个人的工作如何帮助团队更好地理解用户旅程。

跨职能团队如何落地：最小可行实践

要将这一愿景转化为行动，就需要让团队成员的行为与团队的价值观和实际需求保持一致。在我们的团队中，我们通过集体头脑风暴、原则投票，以及起草团队章程，明确了这些价值观和需求。这让我们能够持续反思：为了实现愿景，我们需要增加或调整哪些实践？又该如何在设计阶段更主动地展开协作？

我们认识到，养成新习惯需要刻意努力。因此，我们始终把任何新的实践都视为一种“最小可行实践”。所谓最小可行实践，是指用尽可能简单的方式、让尽可能少的人参与，从而获得我们所需的学习成果。我们会通过实时反馈和回顾来改进这些实践，并确认它们的目的是否依然有效。最坏的情况，不过是我们花 30 分钟到 1 小时尝试了一种很快就被放弃的方法；最好的情况，则是我们从中获得宝贵经验，并为下一次改进提供依据。

通过采用旨在解决真实问题的最小可行实践，我们避免了把时间浪费在无效的新流程上。我们的团队也更愿意尝试不同实验，因为所有活动都有时间限制，并且都以结果为导向。

当然，跨职能协作不只依赖理念和会议，也需要合适的工具承载协作过程。对于研发团队而言，PingCode 这类智能化研发管理工具，可以帮助团队把目标制定、客户反馈收集、需求清理、评审排期、开发、测试、发布和知识沉淀串联起来，让研发管理更加自动化、数据化和智能化；而在更通用的项目协作场景中，Worktile 则可以承载任务、项目、文档、即时沟通、目标、日历、甘特图、工时和审批等协作需求，帮助不同角色在同一工作流中保持同步。

跨职能协作实践示例

《团队协作设计指南》中包含 20 多种跨职能协作实践，也包含我们所秉持的一些价值观和原则。我们希望这些案例能够启发你，把战略转化为解决实际问题的战术。

以下是几种我们曾采用的结对协作方式。

设计债务与技术债务审计

大多数团队都熟悉技术债务的概念，但很少有团队会同样关注设计债务。设计债务指的是与内容是否可感知、可操作、可理解、稳健且一致相关的可用性问题。轻则，它可能只是用户界面上一个略微令人烦恼的小问题；重则，它会严重阻碍用户完成自己的目标。设计债务不断累积，不仅会削弱用户对系统的信心，更糟糕的是，还可能削弱用户对自己的信心，因为他们会觉得自己找不到解决问题的方法。

我们团队中的开发人员凭借以往经验，已经非常熟悉技术债务管理。因此，在现有习惯的基础上引入设计债务这一新维度，并不需要花费太多额外成本。开发人员、质量分析师和设计师会在观察过程中记录技术债务和设计债务，随后团队定期审查这些条目，并基于工作量和影响范围对它们进行优先级排序。

结对式方案探索

和海外某些技术团队一样，我们早已熟悉“结对编程”的理念，并将它拓展到编程之外的角色和活动中。设计师和开发人员是常见的结对组合，但具体活动会根据由谁主导探索而有所不同。

例如，设计师和开发人员可以一起绘制草图，快速展开头脑风暴，探索不同设计方案，同时兼顾技术可行性。他们也可以共同编写代码，在实现过程中验证方案，并在发现限制条件时，有权灵活做出取舍。这类探索能够增强团队成员对技术和设计视角的理解，也能培养他们对用户体验的共同责任感。

你可以使用我们的“团队设计”索引表，为你的团队确定最合适的结对技术。

如何衡量跨职能协作的影响

持续对照团队价值观来评估我们的实践，并据此决定何时增加、调整甚至放弃某些做法，是一件非常有价值的事。但我们如何才能确定，我们的工作方式确实直接帮助用户获得了成功结果？

我们可以通过实时回顾来衡量某项具体实践的有效性。但如果要更全面地评估我们的技术实践和社会实践，就需要从创新的三个视角来审视它们。产品成功不仅取决于销售表现和业务价值，也取决于技术健康度、团队健康度和用户满意度。我们认为，必须衡量所有这些变量所产生的影响。

从根本上说，我们衡量影响的能力，与团队构成以及康威定律密切相关。我们无法将工作成果与工作方式割裂开来。关于创新视角的相关研究很好地阐释了这一原则：为了有效开展团队设计，我们必须重新想象组织内部既有的沟通模式，并解决那些阻碍快速反馈的社会技术功能障碍。

结语：让团队协作设计成为产品开发的一部分

没有战术支撑的战略，只是空想；没有战略指引的战术，则容易变得短视。首先关注实践，能够帮助我们更熟练地掌握跨职能团队的协作方法。

团队协作设计旨在减少摩擦和惯性，并进一步思考：如果敏捷软件开发不只发生在开发人员之间，它会呈现出怎样的样貌？它是持续交付的前端，也是提升产品开发效率和用户体验质量的重要方式。

也许令人意外的是，我们的一些活动本身也可以被视为一种设计行为。设计关乎愿景、意图和行动，关乎想象各种可能性，并携手共建更好的未来。当我们秉持以人为本的理念时，就会开始更深入地审视我们对用户、团队以及更广泛社区所产生的集体影响。简而言之，这正是团队协作设计的意义所在。将这些实践与原则和价值观联系起来，能够帮助我们理解它们为何有价值，也让我们能够把成功经验从一个团队迁移到另一个团队。

如果你的团队还没有准备好一次性接受所有这些做法，也没关系。成长需要时间，改变也从来不容易。我们的方法只是一个起点。例如，如果你发现自己身处一个对实验性工作充满恐惧和阻力的环境，不妨先从一些小而容易见效的尝试开始。我们鼓励你根据团队共同认可的价值观，以及你们正在努力解决的问题，灵活调整并创造属于自己的方法。最重要的是，勇于尝试，认真倾听和观察，持续学习，并不断改进。