由Alexander Fanden（链接）
Agoda的设计系统从2018年开始，最初是一个由开发者主导的小项目，后来发展成为一个拥有近20人的跨职能团队。我们遇到的最大挑战之一是让领导层了解良好设计系统的价值和影响。
随着阿果设计系统（ADS）的成长，新的挑战也随之而来，特别是在应对日益增多的需求上。
我们现在支持超过60个产品团队和1,600多名设计师和工程师，每周在四个平台上推出超过100个A/B测试。随着我们消费者团队中ADS的月活跃采用率接近100%，一个新的挑战出现——管理所有这些工作！
找出根本原因随着工作量的增加，我们意识到我们需要更好的方法来处理请求的优先级。来自不同团队的相互矛盾的需求导致我们难以解释为什么先处理某个请求。
当我们接近20人的时候，内部协调变得非常困难，导致优先级不一致并且一些请求被忽略，这让团队成员以及相关方感到非常沮丧。
我们面临的一个常见挑战是管理来自依赖我们交付的快速响应型团队的时间安排预期。正如乔希·克拉克在他的精彩文章《通过构建更慢的设计系统来更快地交付》Ship Faster by Building Design Systems Slower中所说，"当设计系统团队无法像产品团队那样快速提供新功能、组件或模式时，该团队认为自己成了瓶颈所在。"
我们也遇到了类似的问题，而且由于许多团队并不清楚我们正在处理多少请求，导致了期望的不一致。此外，缺乏透明度也侵蚀了信任，因为团队难以跟踪进度或理解我们是如何做决策的。
为应对这些问题，我们开发了新的流程，建立了优先级框架，并改善了沟通方式。在接下来的部分里，我们将带您了解这些解决方案，并分享一些有助于您团队的资源。
我们新流程的简要说明
这是我们新请求流程图的样子。它从请求开始，任何人在Agoda都能提交请求。
然后，我们的团队将梳理并审核请求，给它分配优先级。一旦完成，它就可以被我们的团队或其他需要该变更的贡献团队接过来处理。到目前为止，流程非常简单直接。
让我们更深入地探索这段旅程的每个部分，以了解更多。
我们是如何处理新请求的
我们通过设置一个专门用于请求的Jira看板，简化了新请求的管理流程。这个看板按照状态整理所有请求，并根据优先级高低顺序排列请求。
你可以很容易地看到请求类型和总数量，并且有筛选器可以按状态或平台排序，以便更具体地查看。
我们的团队支持几种不同的请求类型：
- 功能需求 — 这包括新组件或现有组件、实用程序或设计模式中添加的功能。
- 视觉资产 — 图标、插图、国家旗帜、标志等。
- 设计标记值 — 新的设计标记值或对现有标记值的更新或重做。
- 工具和工具链 — 对我们提供的文档平台、Figma 插件或其他技术工具的改进。
任何人都可以提交新的请求，我们根据请求类型定制了表单字段，以便收集关键信息，比如问题描述和提议的解决方案。我们还提供了Figma模板来帮助我们更好地理解请求，其中包含了设计规范、使用案例和其他重要信息。
虽然这个过程看起来很繁琐，但它有助于确保我们充分理解请求人的需求，并且请求确实很重要。我们还提供了许多其他反馈渠道，比如想法和错误报告。比如我们每个组件的 Slack 群组，这些群组是很好的讨论和灵感交流的地方。
我们怎么给这些请求排个优先级呢？接下来，我们将解释我们如何确保公平和透明的优先级设定，并重点强调业务需求。
为此，我们依据四个关键标准为请求评分。
- 产品类别
2. 可重复使用性
- 其他解决方案
4.: 付出
每个标准的评分范围是从“高”到“不修复”，总分决定了最终的优先级。我们将这些标准的权重设定得有所不同——比如，可重用性（15分）比低努力（10分）更重要，由于其长远的影响。
我们选择根据我们具体的需求来定制框架。不过，它与更成熟的框架有许多相似之处，例如斯图尔特·史密斯所推荐的RICE评分法。通过这种方式，我们给设计系统治理注入了活力。这篇文章值得一读：我们已经给设计系统治理注入了活力。
为了说明这个过程是如何进行的，让我们来看一个例子——一个团队请求增强我们现有的日期选择器组件，希望可以选择远在过去的或未来的年份。
首先，我们评估产品领域或产品线。这个请求是否满足了关键业务项目和产品的需求？
假设今年的选择者被要求为一个即将到来的重要发布——在这种情况下，它会得到最高评分。
2. 可再利用性其次，我们看看这个解决方法是否可以在多个平台、功能或团队之间共享，以再利用。
为了公平地评估所有的请求，我们不得不明确一下“可重用性”对我们来说具体是什么意思。
- 平台与漏斗： 对于年份选择功能，它在所有平台（酒店、航班和活动）上都适用。它也可以用于诸如出生日期或护照过期日期等场景，因此它的可重用性很高。
- 对最终用户的影响： 虽然许多用户可以从中受益，但并非所有用例都适用。因此，我们评估对最终用户的影响为中等，因为大多数用户可能会受益，但并非所有用户。
- 对我们的支持团队的影响： 我们已经记录了我们组织中几个支持产品团队的用例，因此这也评为中等。
- 变更频率： 由于其复杂性，预计未来会有不少调整和变更请求，这可能使其成为高维护功能。我们一般希望避免这种情况，因此给它打低分。
总的来说，可重复使用性会达到中等程度：
第三点，我们已经有了能解决这个问题的办法了吗？
对于例如年份选择器，一个简单的下拉菜单或输入字段在某些情况下可能适用，但。在其他情况下，将年份选择保持在日期选择器内更为重要，因此我们将其评价为中等重要性。
4 — 实施的简便需要多少工作来做？我们优先处理那些容易解决的问题，因为即使是很小的修复也能很快帮助团队解决问题。我们更倾向于解决十个较小的问题，而不是专注于解决一个大的问题。
日期选择器非常复杂，并且不同实现对用户体验的要求各不相同，所以修改这个功能会需要很多工作。因此，这个功能的得分不高。
最终分数把分数加起来，总共30分，满分为50分，所以这个请求属于中等优先级。
这可能意味着我们不会立即采取行动，提出请求的团队可能需要为改动做出贡献。
值班小组所以我们是如何评估请求的，但谁来处理这一切呢？鉴于我们需要为团队提供支持，我们从DevOps中汲取灵感，并实施了一个轮班待命小组，该小组由一名设计师、一名工程师、一名项目经理和我们的质量保证专员组成。
这个小队的一个职责是审核新的请求。如果请求缺少细节或者不符合系统要求，小队会退回给请求者，让他们有机会在下周改进后再审核。
我们的框架和流程已经详细记录下来，方便所有团队在我们的内部知识库中学习并给出反馈。
虽然这可能让一些人感觉过于复杂，但它为决策提供了坚实的基础，并与利益相关者沟通优先级。当然，它也可以根据您团队的具体需求进行调整。
3 — 处理请求
一旦请求被优先处理，下一步就是梳理。每两周，我们的团队会聚在一起梳理这些请求，为设计和实现跨平台的功能创建任务。这些任务存储在每个Scrum团队的单独看板中，并链接回原始请求，这使得追踪依赖关系和接收其他团队的贡献变得更容易。
从这里起，团队可以继续按照现有的流程来完成工作。一旦有任何团队开始处理这个请求，我们就会把请求标记为“进行中”。
相关人员可以通过查看所有相关工单的状态轻松跟进进度。他们还可以关注自己的请求，以自动收到任何更改或评论内容的更新。
我们很快发现仅依赖Jira的通知不够有效，因为许多相关人员错过了更新。因此，我们在Slack上增加了公告以确保信息的透明度。
例如，我们的设计师 Parn 最近分享了关于我们底部组件的改进，并附上了一段快速的 Figma 视频教程。这种主动沟通真的让团队感到非常高兴！
我们过程和仪式的简述这是我们请求过程的简述：
• 提交请求很简单：任何人都可以通过使用Jira和Figma模板来提交请求。
• 审查过程：我们每周在例会上审查新请求。
• 处理：我们团队处理请求，并提交工单，然后由 scrum 团队管理。
• 目前状态：请求通过Jira和Slack来跟踪，利益相关者会通过电子邮件和Slack收到更新。
• 完成：当工作完成后，如果有任何变更，我们会在整个过程中通知请求者。
有了一个清晰的从头到尾的工作流程，考虑周到的优先级框架以及经过验证的仪式，我们能够让利益相关者了解情况，管理期望，并从而更有效地管理我们的工作量。
关键收获在结束前，我们想分享一些我们学到的一些经验以及一些实用的建议，帮助您开始自己的旅程。
清晰的过程就是包容的过程有了一个既定的流程，团队可以轮流承担执行仪式的责任，从而让负责人可以专注于战略性的工作，同时为每个人提供成长的机会。这样一来，团队成员可以有更多成长的机会。
少一些详细的讨论这个过程已经改变了讨论的方向，从讨论个别请求的争论转变为完善整体框架的过程，优化决策过程，并促进持续的改进。
加强与利益相关者的沟通这个过程明确了对我们的设计系统的需求，并改善了与管理层和其他团队的沟通。季度调查显示，自从这个流程被引入以来，沟通和透明度有了显著改善。
权衡和优先事项在与领导层的持续讨论中，平衡更好的设计与更快的交付之间的权衡是一个持续的话题。我们的需求看板提供了见解，突显了系统中的不足，表明我们的设计系统一直在不断改进。
带宽与贡献我们目前收到的请求比我们能够处理的数量多五倍，增加贡献仍然是一项挑战。尽管我们的优先级系统让我们能优先处理最重要的任务，但问题来了——剩下的怎么办？
我们正在积极地探索大规模引入贡献的方法，同时在保持系统完整性的基础上，但还未完全达到目标。
相互矛盾的时间表作为平台团队，我们常常面临与快速迭代的产品团队保持同步的挑战。我们不希望成为创新的阻碍或拖累，但保持正确的平衡依然是我们持续面对的难题。
开始的小贴士：如果你的团队也遇到了类似的问题，这里有一些建议可以帮到你，就像我们做的一样。
1. 设定你的优先事项框架尽早让相关方参与进来，建立关于权衡和公司整体优先事项的共同理解，而不仅仅是你团队的优先。这将使你的旅程更加顺畅。你可以参考我们提供的模板作为起点，然后以此为基础继续。
2. 集中处理请求将所有请求集中在一个地方，以便全面了解系统的需求。这也有助于向团队展示进一步投资的必要性，即说服团队增加投资。
我们学到的一点是，bug和其他“日常维护任务”占用了我们很多的工作时间——有时甚至高达50%。但是这些任务没有在我们的请求板上列出，因此其他团队并不知道我们在处理这些问题。考虑把这些任务添加到请求板上，以实现完全透明。
3. 建立常规作息创建常规并标准化工作流程，以高效推动进展；找出需要反馈回路的地方，并将这些反馈回路嵌入到过程中。
- 与相关方沟通
规划如何定期通知利益相关者。定期沟通是管理期望和建立信任的重要因素。
5.\n### 5. 学习并不断迭代关注关键数据点，利用这些数据为团队争取所需，并不断调整和优化流程以适应团队的具体情况。
本文基于我们首席产品设计师Alexander Fanden在Into设计系统大会上的演讲。（观看视频链接）https://www.youtube.com/watch?v=fpSa8zG1X0o。
更多阅读和参考资料- 访问 Notion 页面，了解与本文相关的更多社区资源，包括请求框架、Figma 请求模板和有见地的文章。
- 更慢构建设计系统，更快交付 由 Josh Clark，Big Medium。
- 让设计系统治理变得轻松，而不是瓶颈
- 我们让设计系统治理充满活力的三个方法 由 Stuart Smith。
- 高效且快乐地管理待命团队的权威指南 由 Atlassian。
- RICE：产品管理中的简单优先级工具 由 Intercom。
共同学习，写下你的评论
评论加载中...
作者其他优质文章
