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

在产品开发过程中跨职能协作能够帮助团队更快地理解用户需求并持续交付更有价值的产品成果。然而跨职能协作究竟应该如何开展并不总是显而易见。一个团队要想真正协作成功需要哪些具体实践又应该秉持哪些共同价值观我们是开发人员 Valerie 和设计师 Christopher都热衷于跨职能结对协作。我们曾在分布式团队中在高压、紧迫的交付环境下实践过本文提出的所有建议。当时客户公司内部设计资源有限。即便交付期限非常紧张我们依然找到了优先学习、持续实验的方法。在这篇《团队设计指南》中我们将与你分享这些做法。添加图片注释不超过 140 字可选本文将介绍跨职能协作在产品开发中的具体案例也会分享支撑这些实践的价值观和原则。我们希望这些内容能为你的团队带来启发并拓展你对设计如何在业务流程中创造更大价值的理解。如果你符合以下情况本文会很适合你阅读你是一名设计师正在尝试定义设计敏捷性如何贯穿从战略到执行的全过程。你是一名产品经理需要厘清自己的角色与设计师之间的边界和协作方式。你是交付团队成员例如开发人员、质量分析师或项目经理正在思考“设计到底是什么我为什么要参与设计又该如何参与”你是一位团队负责人正在思考如何打造正确的产品以及如何正确地打造产品。你正在寻找具体示例帮助团队打破产品开发中的信息孤岛并更快地向用户交付新功能。跨职能协作为何重要脱节的工作流程克服组织惯性并不容易。设计、业务和技术部门之间的信息孤岛会拉长从发现问题到交付方案的反馈周期。如果缺乏跨职能协作文化团队就很难跟上业务与用户需求的快速变化。如今将以人为本的方法引入技术开发的路径有很多例如精益用户体验、敏捷体验设计、平衡团队、以人为本的设计、设计运营和设计思维等。除了强调以人为中心这些方法还共同关注一点衡量成功的关键不应只是交付了多少功能而应是创造了怎样的结果而跨职能或跨学科协作正是实现这些结果的重要驱动力。如果你在面对这些方法论时感到不知所措你并不孤单。如果缺少把战略转化为战术的模型你可能会不断怀疑我们现在的做法到底对不对也许你所在团队目前的设计实践是这样的添加图片注释不超过 140 字可选产品经理从业务专家那里收集需求清单然后转交给设计师。设计师独自绘制高保真原型却没有获得任何真实用户反馈。原型上传到故事卡片后就再也没有被更新过。开发人员把设计稿视为像素级精确的规范却不了解底层交互设计也不知道这项工作如何融入整体用户体验流程因此很难提出真正关键的问题。质量分析师在不了解预期结果的情况下测试应用行为例如不知道这些功能将如何解决用户问题、支持业务需求。没有人衡量最终交付的服务是否真正为用户创造了价值。在上述情境中不同角色之间的互动非常有限而且通常并不在同一个团队内进行。即便如此他们可能仍会说自己身处一个“协作环境”。这种说法并非完全错误因为最终成果确实来自多方共同努力。但这并不是我们所说的跨职能结对协作。这种各自独立的工作流程本质上仍然以交接为中心。而交接恰恰与真正的协作背道而驰。创新与同理心团队协作设计的基础打造以人为本的优秀产品首先需要我们与用户建立同理心也需要团队成员彼此之间建立同理心并能够快速响应我们发现的用户需求。我们可以从创新的三个视角来理解这一点我们试图满足哪些需求也就是说我们的解决方案是否有价值、是否令人向往我们如何实现它也就是说我们的方案在技术上是否可行我们能否持续推动它也就是说我们的方案在业务上是否可持续同理心贯穿我们研究和理解问题的三个维度。我们通过同理心理解用户从而更深入地判断产品的价值性与可用性。我们也通过同理心建立团队内部的信任促进更有效的协作。借助协作所建立的信任我们进一步理解产品在目标市场中的价值性和可持续性。所有这些都属于设计的范畴。我们能够从用户和彼此身上学到很多因此我们坚信团队协作设计的力量。添加图片注释不超过 140 字可选创新的三个视角提醒我们我们的目标是创造有价值、可行且可持续的事物。要实现这一目标我们需要在团队内部以及与我们所服务的用户和社区之间倡导同理心和信任。在我们的方法中设计是一项共同责任。这意味着团队需要对用户旅程形成共识并肩协作充分发挥每个人带来的不同技能和视角。我们所交付的成果本质上代表了关于价值性、可行性和可持续性的假设而这些假设还需要在真实生产环境中接受进一步验证。否则产品经理只能凭空猜测用户需求设计师只能提交缺乏解释的 UI 规范开发人员也只能在不理解背景的情况下编写代码。均衡的团队构成对于高效的跨职能协作至关重要因为它能帮助我们发现原本可能被忽略的学习机会。设计师与开发人员的组合例如我们两个人往往能推动这种协作模式的发展因为这种组合带来的价值非常明显。但其实还有更多可能性值得探索质量分析师和设计师搭档时我们能学到什么产品经理和开发人员搭档时呢设计师和站点可靠性工程师搭档时呢开发人员和客户支持人员搭档时呢当设计成为一种团队实践时我们也会开始重新审视各自的职责并思考每个人的工作如何帮助团队更好地理解用户旅程。跨职能团队如何落地最小可行实践要将这一愿景转化为行动就需要让团队成员的行为与团队的价值观和实际需求保持一致。在我们的团队中我们通过集体头脑风暴、原则投票以及起草团队章程明确了这些价值观和需求。这让我们能够持续反思为了实现愿景我们需要增加或调整哪些实践又该如何在设计阶段更主动地展开协作我们认识到养成新习惯需要刻意努力。因此我们始终把任何新的实践都视为一种“最小可行实践”。所谓最小可行实践是指用尽可能简单的方式、让尽可能少的人参与从而获得我们所需的学习成果。我们会通过实时反馈和回顾来改进这些实践并确认它们的目的是否依然有效。最坏的情况不过是我们花 30 分钟到 1 小时尝试了一种很快就被放弃的方法最好的情况则是我们从中获得宝贵经验并为下一次改进提供依据。通过采用旨在解决真实问题的最小可行实践我们避免了把时间浪费在无效的新流程上。我们的团队也更愿意尝试不同实验因为所有活动都有时间限制并且都以结果为导向。当然跨职能协作不只依赖理念和会议也需要合适的工具承载协作过程。对于研发团队而言使用智能化研发管理工具可以帮助团队把目标制定、客户反馈收集、需求清理、评审排期、开发、测试、发布和知识沉淀串联起来让研发管理更加自动化、数据化和智能化而在更通用的项目协作场景中 通用管理系统则可以承载任务、项目、文档、即时沟通、目标、日历、甘特图、工时和审批等协作需求帮助不同角色在同一工作流中保持同步。跨职能协作实践示例《团队协作设计指南》中包含 20 多种跨职能协作实践也包含我们所秉持的一些价值观和原则。我们希望这些案例能够启发你把战略转化为解决实际问题的战术。以下是几种我们曾采用的结对协作方式。设计债务与技术债务审计大多数团队都熟悉技术债务的概念但很少有团队会同样关注设计债务。设计债务指的是与内容是否可感知、可操作、可理解、稳健且一致相关的可用性问题。轻则它可能只是用户界面上一个略微令人烦恼的小问题重则它会严重阻碍用户完成自己的目标。设计债务不断累积不仅会削弱用户对系统的信心更糟糕的是还可能削弱用户对自己的信心因为他们会觉得自己找不到解决问题的方法。我们团队中的开发人员凭借以往经验已经非常熟悉技术债务管理。因此在现有习惯的基础上引入设计债务这一新维度并不需要花费太多额外成本。开发人员、质量分析师和设计师会在观察过程中记录技术债务和设计债务随后团队定期审查这些条目并基于工作量和影响范围对它们进行优先级排序。结对式方案探索和海外某些技术团队一样我们早已熟悉“结对编程”的理念并将它拓展到编程之外的角色和活动中。设计师和开发人员是常见的结对组合但具体活动会根据由谁主导探索而有所不同。例如设计师和开发人员可以一起绘制草图快速展开头脑风暴探索不同设计方案同时兼顾技术可行性。他们也可以共同编写代码在实现过程中验证方案并在发现限制条件时有权灵活做出取舍。这类探索能够增强团队成员对技术和设计视角的理解也能培养他们对用户体验的共同责任感。你可以使用我们的“团队设计”索引表为你的团队确定最合适的结对技术。如何衡量跨职能协作的影响持续对照团队价值观来评估我们的实践并据此决定何时增加、调整甚至放弃某些做法是一件非常有价值的事。但我们如何才能确定我们的工作方式确实直接帮助用户获得了成功结果我们可以通过实时回顾来衡量某项具体实践的有效性。但如果要更全面地评估我们的技术实践和社会实践就需要从创新的三个视角来审视它们。产品成功不仅取决于销售表现和业务价值也取决于技术健康度、团队健康度和用户满意度。我们认为必须衡量所有这些变量所产生的影响。从根本上说我们衡量影响的能力与团队构成以及康威定律密切相关。我们无法将工作成果与工作方式割裂开来。关于创新视角的相关研究很好地阐释了这一原则为了有效开展团队设计我们必须重新想象组织内部既有的沟通模式并解决那些阻碍快速反馈的社会技术功能障碍。结语让团队协作设计成为产品开发的一部分没有战术支撑的战略只是空想没有战略指引的战术则容易变得短视。首先关注实践能够帮助我们更熟练地掌握跨职能团队的协作方法。团队协作设计旨在减少摩擦和惯性并进一步思考如果敏捷软件开发不只发生在开发人员之间它会呈现出怎样的样貌它是持续交付的前端也是提升产品开发效率和用户体验质量的重要方式。也许令人意外的是我们的一些活动本身也可以被视为一种设计行为。设计关乎愿景、意图和行动关乎想象各种可能性并携手共建更好的未来。当我们秉持以人为本的理念时就会开始更深入地审视我们对用户、团队以及更广泛社区所产生的集体影响。简而言之这正是团队协作设计的意义所在。将这些实践与原则和价值观联系起来能够帮助我们理解它们为何有价值也让我们能够把成功经验从一个团队迁移到另一个团队。如果你的团队还没有准备好一次性接受所有这些做法也没关系。成长需要时间改变也从来不容易。我们的方法只是一个起点。例如如果你发现自己身处一个对实验性工作充满恐惧和阻力的环境不妨先从一些小而容易见效的尝试开始。我们鼓励你根据团队共同认可的价值观以及你们正在努力解决的问题灵活调整并创造属于自己的方法。最重要的是勇于尝试认真倾听和观察持续学习并不断改进。