企业跨职能优先级排序框架

一家零售巨头将软件开发规划时间缩短了 9 倍（从 18 周缩短到 2 周），并在不增加开发团队规模的情况下交付了 5 倍更具影响力的功能。

关键在于？采用跨职能优先级排序。

这种显著的效率提升带来了超越速度和影响力的意外收益。

意外收获

"我们终于有了单一决策流程，"一位开发人员说。"就像按下电灯开关——优先事项清晰，不再有无休止的争论。"

"每个优先事项都经过了所有人 100% 的评估和认可，不仅仅是直觉或权力博弈。现在，我们信任这个系统。"

"这是透明的——我们都知道优先级评分是如何计算的，并且每个利益相关者、守门人和潜在阻碍者在任何事情进入开发队列之前都有发言权。不再拖延任务——我们知道什么才是真正重要的。"

"我们现在彼此交流了。软件和业务团队。这是一个全新层次的理解和减少冲突。"

"我在 Jira 待办事项中发现了一个被埋没的任务，它帮助将订单兑换率提升了 X 个百分点；在我们的业务量下，这相当于数百万额外收入。如果我没有通过新的优先级排序流程评估任务，这个宝藏就会一直被隐藏。"

关于这家公司

想象一下，为一家拥有数百家门店、数百万客户、核心业务建立在实体店基础上的零售巨头管理数十个软件产品。这就是该零售商面临的挑战（出于隐私考虑，隐去名称）。他们拥有数百名工程师的软件部门需要一种方法来应对复杂性并快速交付具有影响力的功能。接下来发生的事情非常了不起。

优先事项错位导致开发资源紧张

该零售商的软件部门面临着严峻的现实：

• **过载：**每六个月，他们就会被 2,000 多个请求淹没，远超产能，凸显了对极度专注的需求。

• **增长 vs 效率：**扩大软件团队规模并非万能良药。资本效率为王，尤其是在动荡时期。

• **谈判黑洞：**每年花费 18 周（4.5 个月）讨论和协调优先事项，意味着要在什么是关键的、简单的、复杂的或仍然相关的问题上摸索前行。

• **不断变化的环境：**到发布时，快速变化的业务环境往往使任务过时。利益相关者经常发现最终产品不再满足他们的需求，这突显了建立实时适应的优先级排序流程的紧迫性。

• **未开发的潜力：**宝贵的开发资源没有用在业务关键任务上。

优先级排序目标：

1. 最小化规划开销。

2. 确保开发火力集中在真正对业务产生影响的事项上。

从电子表格到僵局：WSJF 为何跟不上步伐

在数字化转型初期，该零售商最初选择了 加权最短作业优先（WSJF）框架，使用电子表格进行优先级排序。然而，这种方法存在不足：

• 三个月过去了，仍未确定优先事项。

• 宽泛、主观的标准：WSJF 依赖于 "风险"、"作业规模" 和 "关键性" 等一般概念，这些概念可能被不同角色和部门以不同方式解读。这种主观性导致了错位和挫败感，有价值的复杂任务被忽视，而看似"更简单"的任务被优先考虑。

• 速赢 vs 真正价值：WSJF 在成长型企业中的不足。公式，比如除以工作量，可能会优先考虑较小的、不重要的任务，而不是战略上关键的任务。这造成了一个由速赢主导的待办事项列表，忽略了必要但复杂的项目，如法律和合规任务。

• 电子表格泥潭：电子表格很快变成了噩梦——缓慢、容易出错，并且需要不断手动更新。保持与 Jira 数据的一致性变成了一项繁琐的复制粘贴工作，阻碍了效率和透明度。

WSJF 局限性的主要经验：

1. WSJF 及类似框架不适合较大组织的复杂性。

2. 避免将工作量优先于价值的公式（除以工作量），以确保专注于有影响力的项目。

第一阶段：统一优先级排序取代孤立决策

在 WSJF 的最初挫折之后，这家零售巨头知道它需要一种根本不同的方法。

关键洞察

最大的罪魁祸首不是框架本身，而是传统的孤立决策流程。

想象一下，在各个团队（产品、增长、软件）内部进行优先级排序，而其他关键利益相关者（如法律、安全、支持、风险等）的输入有限。这导致了孤立的视角、错位的优先事项，以及由于后期反馈循环而不断变化的交付估算。

他们的激进解决方案：采用 "Summitinals" 流程。他们没有孤立决策，而是邀请所有人参与优先级排序。从设计师到工程师、营销人员到法律、支持、物流，甚至一些零售店经理，所有声音都被听到。这创造了一个更短的反馈循环，确保每个人都保持一致，潜在的障碍能够及早识别。

统一优先级排序的好处

转向整体优先级排序流程不仅简化了决策，还带来了显著优势：

• **相关性验证：**确保工单的持续相关性，确认所解决的问题仍然是业务的优先事项。

• **解决方案对齐：**通过让所有利益相关者保持在循环中，该流程保证了建议的解决方案有效解决当前挑战，避免问题和解决方案之间的错位。

• **无发布后意外：**涉及各种视角，包括架构师、法律团队、风险管理和安全，确保潜在问题在发布前得到解决，防止出现意外问题。

这种方法培养了一种透明和协作的文化，每个声音都被听到，每个解决方案都经过影响和相关性审查。

"业务和软件部门的任何人都不怀疑，被选中进行开发的任务是业务中最优先和最重要的。" 产品方法论能力中心负责人

第二阶段：打造定制跨职能优先级排序框架

在开发其独特优先级排序框架的过程中，该零售商采用了一个允许真正跨职能协作的原则。使用模板的链接在文章末尾。

一个专有跨职能框架应运而生。每个角色都收到了特定的评估标准来权衡任务，确保每个人都有有意义的发言权。这直接解决了"黄金法则"：

黄金法则

最佳优先级排序框架反映公司的流程，并且每个决策者都能理解。

因此，该公司创建了一个与其独特需求和动态产生共鸣的专有框架。

**专业提示：**始终清晰定义和重命名优先级排序标准，以消除歧义。这确保每个人都在同一页面上，并对优先级排序流程做出有意义的贡献。

"成功地兼顾了众多利益相关者的不同利益，并在合理的时间内获得了优先级排序的请求队列。" 数据分析负责人

业务标准

**关键结果（KR）：**对产品/流程/功能/公司 KPI 的直接影响。

**权重：**3

该标准必须重命名为特定于产品的结果或指标。**目标：**识别在同一季度或最多下一季度内改进特定数字业务指标的任务。**评估基础：**考虑任务是否直接影响 BI/KPI 导向的结果。即使任务不会立即改变绩效指标，如果它对 KPI 相关目标有贡献，也会根据这种战略对齐获得更高分数。该标准确保优先级排序与战略目标保持一致，专注于为关键业务指标提供切实改进的任务。

量表：

• **1：**对任何指标没有直接影响。

• **2：**影响微不足道，不太可能在指标中看到。

• **3：**轻微影响，可能在指标中注意到。

• **5：**中等影响，有一定的信心水平。

• **8：**预期有显著影响，有计算支持。

• **13：**对公司/功能有重大预期影响，有效率计算和 KPI 确认。

• **21：**实质性预期影响，有试点数据、基准和参考的有力支持。

任务示例：

• **1：**跟踪产品选择规则的查看次数。

• **2：**改进 iPhone 4s 上的产品布局。

• **3：**增强所有移动设备上产品选择规则的显示质量。

• **5：**添加产品选择规则。

• **8：**按尺寸显示产品可用性。

• **13：**订购多个尺寸以供配送。

• **21：**实施全站产品订购。

**客户满意度（CSAT）：**衡量用户满意度和受变更影响的用户数量。

**权重：**1

**目标：**评估用户对变更的期待程度、哪些用户将受到影响以及用户/客户影响的程度。包括外部客户和从任务完成中受益的公司员工，提高工作效率。

**评估重点：**任务在产生用户满意度方面的内在价值。

• **1：**对用户愉悦度没有影响。

• **2：**少数人几乎注意不到的改进。

• **3：**一小部分用户会欣赏这一变化。

• **5：**四分之一的客户、一半的业务用户或部门负责人会注意到。

• **8：**一半的客户、所有业务用户或职能领导者会注意到改进。

• **13：**所有客户、业务用户和职能领导者都热切期待这一变化。

• **21：**该功能需求强烈，客户、业务用户甚至公众不断询问，提供未经请求的反馈。

任务示例：

• **1：**跟踪电子邮件发送情况。

• **2：**改进 Lotus Notes 的电子邮件布局。

• **3：**为电子邮件中的图像启用替代文本。

• **5：**调整 Gmail 的电子邮件布局。

• **8：**发送根据时区调整的通知。

• **13：**在移动应用中引入通知中心。

• **21：**在移动应用中管理通知订阅。

**机会：**战略投资的潜力和消除开发障碍。

**权重：**1

为开发铺平道路或为公司增长开辟新途径。这包括属于更广泛战略计划（BI/KPI 对齐）促进此类发展的任务。它可能不会在短期内影响收入。

• **1：**不开辟新机会。

• **2：**提供微不足道的机会。

• **3：**为业务流程/产品功能创造本地机会。

• **5：**为业务流程/产品功能开发提供实质性机会。

• **8：**释放具有未来对功能或业务流程潜在影响的机会，在未来指标中可见。

• **13：**开辟重要机会，对公司或功能有可预见的重大影响，反映在未来指标中。

• **21：**揭示满足公司长期战略计划的关键机会。

任务示例：

• **1：**在产品页面放置静态横幅。

• **2：**能够从管理面板更改网站产品页面上的横幅。

• **3：**从管理面板在所有前端产品页面上自定义横幅。

• **5：**从管理面板在所有前端产品页面上 A/B 测试两个横幅。

• **8：**在所有前端产品页面上测试两个或更多横幅。

• **13：**横幅测试，自动选择获胜者并最小化测试期间的收入损失。

• **21：**在所有前端自动选择通信、放置位置和用户，并测试最佳选择算法。

**法律：**与任务相关的潜在法律风险、声誉损害和罚款。

**权重：**2

**重点：**识别任务对法律立场的影响，包括用户诉讼、法律纠纷造成的声誉损害以及违反法律的处罚。

量表：

• **-10：**大大增加法律风险。

• **-6：**显著增加法律风险。

• **-2：**略微增加法律风险。

• **0：**对法律风险没有影响。

• **2：**略微减轻法律风险。

• **6：**大幅降低法律风险。

• **10：**大幅降低法律风险。

示例：

• **-10：**引入不合规的数据收集做法。

• **-6：**实施存在潜在隐私问题的功能。

• **-2：**需要法律审查的次要合同变更。

• **0：**对法律风险没有影响。

• **2：**改进无障碍合规性。

• **6：**增强数据安全措施。

• **10：**实施行业标准加密协议。

软件标准

**开发风险：**IT 风险，如团队吞吐量降低、维护增加或安全漏洞。

**权重：**2

解决诸如团队吞吐量降低、维护工作不必要增加、创建手动流程、系统脆弱性增加、性能降低、安全性降低以及其他相关 IT 风险等风险。

量表：

• **-10：**显著升级 IT 风险。

• **-6：**大幅增加 IT 风险。

• **-2：**略微提高 IT 风险。

• **0：**对 IT 风险没有影响。

• **2：**略微降低 IT 风险。

• **6：**显著降低 IT 风险。

• **10：**大幅降低 IT 风险。

示例：

• **-10：**引入复杂、不可维护的代码库。

• **-6：**实施具有已知安全漏洞的功能。

• **-2：**添加需要额外维护的新依赖项。

• **0：**对 IT 风险没有影响。

• **2：**重构代码以提高可维护性。

• **6：**实施安全最佳实践。

• **10：**迁移到安全的云基础设施。

**架构：**确定任务是否符合目标架构或解决技术债务。

**权重：**2

**评估重点：**任务在架构贡献或减少债务方面的优点。

• **-10：**大幅增加债务（重大变通方法）。

• **-6：**显著增加债务（重大变通方法）。

• **-2：**略微增加技术债务（次要变通方法）。

• **0：**对架构的中性影响；既不推进也不偏离目标解决方案。

• **2：**略微减少债务。

• **6：**大幅朝着目标架构迈进，包括解决自动化方面的差距。

• **10：**直接实现目标架构。

示例：

• **-10：**使用自定义代码和点对点连接将遗留系统与核心平台集成。

• **-6：**使用与目标架构不兼容的"死胡同"技术，未来需要额外工作才能迁移。

• **-2：**由于代码重复进行的小型代码重构。可以在不久的将来快速解决的短期技术债务。

• **0：**更新文档或次要错误修复。

• **2：**将数据源整合到单一统一平台中，有助于更清洁、更可维护的架构。

• **6：**符合微服务架构并减少长期技术债务。

• **10：**完成向基于云的平台即服务（PaaS）解决方案的大规模迁移。

**细化：**任务完成的进度，最小化放弃正在进行的任务。

**权重：**1

**目标：**确定任务完成了多少，以优先考虑已经开始的工作的继续和完成，确保资源的有效使用并最小化因放弃任务而造成的浪费。

• **55：**接近完成，剩余工作不到 10%。完成所需的工作量最小。

• **35：**已完成大量工作，超过 40% 已完成。完成比放弃更有效率。

• **5：**取得了一些进展，未具体量化，但足以使放弃它会导致工作浪费。

• **0：**准备阶段，任务描述和验收标准（AC）已由团队初步验证。

• **-10：**任务描述和 AC 已准备好但未验证，表明准备好开始工作但存在一些不确定性。

• **-15：**除了标题之外缺乏清晰的描述，对任务要求和执行有很大的歧义，需要额外的澄清和规划工作。

示例：

• **55：**为已实施的功能编写单元测试。

• **35：**为移动应用更新采购订单的用户界面元素。

• **5：**取得了一些进展，未具体量化，但足以使放弃会导致工作浪费。

• **0：**使用最新更改更新项目文档。

• **-10：**提高"购物车中"页面加载速度。

• **-15：**修复网站问题。

置信度标准

**研究：**使用支持数据衡量任务置信度。

**权重：**20

对于利用用户交互数据为营销和全渠道策略提供信息至关重要。

• 0 — 没有新见解；纯粹基于假设。

• 21 — 收集了新的用户行为数据，表明基于证据的任务具有新见解的潜力。

**紧迫性：**确保框架内的灵活性，以优先考虑并快速处理具有紧急、高风险影响的任务。

此标准专门分配给团队负责人或经理，并在紧急情况下启用。

**权重：**20

**量表：**0 或 1。

**评分示例（1 分）：**分配给具有即时、重大风险的任务，例如：

• 检测到可能导致数据泄露的漏洞。

• App Store 或 Meta 等平台暂停应用的风险威胁。

• 监管机构的法律禁令。

• 招致巨额罚款的高风险。

工作量标准

**前端、后端、移动、UX 标准：**Web 和移动产品开发所需时间。

这是四个标准的示例：添加/编辑/删除所有不必要的开发团队结构镜像。

**权重：**1

• 1 — 毫不费力：不需要工作量。

• 2 — 半天或更少。

• 3 — 一天。

• 5 — 两天（半个迭代）。

• 8 — 四到五天（一个迭代）。

• 13 — 超过一个迭代但少于两个迭代。

• 21 — 两个迭代及以上。

专业提示

每个标准都使用非线性评估量表，如 1、2、3、5、8、13 和 21——斐波那契数列。

该框架旨在平衡战略目标与实际考虑，确保通过尊重所有部门独特贡献的全面视角评估每项任务。

第三阶段：简化评估流程

所有权的力量：分配专门的评估人员

这家零售巨头首先为每个优先级排序标准分配负责人。想象一下：评估规划扑克和战略远见的无缝融合，每个关键领域——业务、IT、研究和紧迫性——都有专门的指挥者。最初是四重奏，但乐团发展到每个团队 16-20 人，所有人和谐演奏。

与 Jira 同步的魔力

另一个流程助推器是 实时双向 Jira Server 集成。每个团队的 Jira 待办事项都会动态同步，在 Ducalis 中实时更新。在 Jira 中出现新工单。立即，它就会出现在 Ducalis 中。对待办事项进行最后一刻的更新？它会实时刷新——告别评估过时的任务。

想象一下：手动任务调整的终结。这不仅仅是升级；它彻底改变了团队的效率，前所未有地简化了工作流程。

小块聚焦

面对 Jira 待办事项的庞大规模，任务的绝对数量曾经似乎不可能完成。解决方案？战略性分段。他们将庞大的待办事项切成了易于消化的小块，这种心理整理将庞大的任务山转变为整齐组织的、可管理的小山丘。每个部分现在包含 25-50 个任务，定义清晰，准备好进行评估。

这种方法导致为每个团队创建了 150 个不同的、小块的 Ducalis 项目，最终形成了一个展示端到端优先事项的聚合主项目。这是一个改变游戏规则的方法，简化了流程并为集体工作带来了新的清晰度。

拥抱不同的观点

在团队优先级排序中，承认和讨论不同的观点是非常宝贵的。借助 团队一致性报告，他们可以快速发现这一点。任务价值评估的差异可能突显误解或对任务重要性的不同看法，表明需要澄清。每个项目有 20 位评估人员，只有 5% 到 10% 的功能需要进一步讨论。然后在电话会议中解决这个问题，导致由促进者（如团队负责人或产品负责人）直接影响的最终评分。

相关性的艺术

在优先级排序的世界中，思想的多样性不仅受欢迎——它至关重要。当意见分歧时——比如说，一个人看到黄金，而另一个人看到碎石——这是一个暂停和思考的提示。借助团队一致性报告，差异会自动被发现。

大约 5-10% 的任务引发了争论，这是深入探讨和更丰富理解的黄金机会，最终形成了那个至关重要的最终评分。

认识到优先事项可能很快过时，该公司采用了每三个月重置评分的做法。这种定期"剥离"确保过时的任务被逐步淘汰和关闭，只关注相关工单。

第四阶段：跨职能优先级排序——业务影响增长 500%

是的，你没看错。交付了具有 5 倍更大业务影响 的任务。如此惊人的转变是如何发生的？这一切都归结为使用 Ducalis 进行战略任务优先级排序，客户的 CTO 呼应了这一观点：

"通过简单地在 Ducalis 中对任务进行优先级排序，我们解锁了新的生产力水平。真正的魔力在于将正确的工具与我们设想的流程配对。"

规划速度提高 9 倍

跨职能优先级排序将决策时间从每年耗时 18 周（四个半月）压缩到 2 周。这一巨大飞跃是通过以下方式实现的：

• **专业工具：**利用 Jira 和优先级排序工具之间的实时同步简化了流程。

• **动态标准更新：**根据不断变化的业务环境调整优先级排序标准，确保持续对齐。

• **自动错位检测：**立即识别差异，保持专注力和相关性。

• **简化流程：**直接的方法意味着更少的故障和瓶颈。

消除低影响任务

优先级排序后，他们观察到：

• 30% 的正在进行的开发任务因优先级低而被删除，将资源重新分配给更高价值的项目。

• 50% 的首要任务未准备好立即开发，允许进行先发制人的问题解决或任务整合。

• 60% 排队等待生产的任务被降低优先级，由于业务环境变化而失去相关性。

生产力的巨大提升

这不仅仅是消除不必要的任务，还包括在团队规模相同的情况下优化整个工作流程。

• 交付周期缩短 40%（节省了数周时间）

• 交付周期时间减少 50%

• 开发者速度提高 2 倍

从混乱的待办事项到精简的、以影响为重点的开发流程的旅程不仅是可能的——它是现实。如果你正在寻求团队任务优先级排序方式的革命，请将这种方法视为成功的蓝图。努力是值得的，它能放大生产力并确保每项任务都让你更接近业务目标。

实施跨职能优先级排序方法：分步指南

借助现成的模板和详细指南，在你的组织内采用这种方法很简单。虽然以下步骤基于设置 Ducalis，但核心原则可以在电子表格中进行实验。

1. **从模板开始：**使用框架模板创建优先级排序项目。这作为你的基础。

2. **导入你的待办事项：**从你的任务管理工具（例如 Jira Cloud/Server、Asana、Linear、ClickUp、GitHub、Trello、YouTrack）中导入待办事项的一部分（30-50 个任务）。可选地，设置将优先级排序结果同步回你的任务管理工具，以实现无缝工作流程。

3. **自定义标准：**彻底审查所有标准。这些标准在讨论过程中会引起你的团队共鸣吗？这些术语是否熟悉，还是需要调整？调整描述以与你的团队语言保持一致，删除不需要的内容，并添加可能缺失的任何标准。

4. **分配责任：**为每个标准指定一个或多个负责人。这些可以是团队成员的任何组合，确保广泛的代表性和专业知识。

5. **让你的团队参与：**邀请所有参与者评估任务。这种集体努力对于全面评估至关重要。

6. **通过一致性改进：**利用一致性部分根据需要调整评分，确保共识并解决差异。

7. **评估结果：**审查优先级排序的任务列表。根据需要微调权重和标准数量，以进一步完善优先事项。

---

采用这种方法不仅简化了你的优先级排序流程，还促进了协作环境，在这种环境中，每项任务都通过多方面的视角进行评估。深入研究、实验，看着你团队的生产力和专注度飙升。

下载 PDF 格式的案例研究。

试用带有企业框架的 Ducalis——免费注册，包含所有预设。

常见问题

这个流程是否太耗时而不值得？

采用这个框架会改变项目优先级排序。团队经常发现，看似"有前途"的东西可能经不起跨职能审查，而被忽视的"锦上添花"功能则成为高投资回报率的机会。真正的胜利？在待办事项中发现可能被错过的隐藏宝藏。

不深入参与项目的人如何有效评估任务？

跨团队优先级排序的优势在于包容性——汇集可能影响任务执行的每个人，而不仅仅是狭窄的产品/增长/技术圈子。我们遇到了其他角色的人任务描述不清晰的挑战。"无法评估"选项导致许多任务被其作者拉回重新描述。最初遭到抵制，这种做法最终对任务作者形成了"积极压力"，以改进、整合或删除任务，自然地增强了待办事项细化，并有明确的动机。

优先级排序流程的理想参与人数是多少？

• 4 人提供了一个良好的开端，每个中央单位（业务、软件、分析、紧迫性）至少有一名代表。

• 10 人实现更全面的覆盖，确保每个标准至少有一名评估人员。

• 20+ 人是最佳的，允许每个标准有多名评估人员进行交叉验证估算并识别错位。

如果某些角色（如法律）无法评估特定任务怎么办？

这是完全正常的，可以通过几种方法来管理：

• 他们可以跳过该任务以便稍后重新评估，特别是如果在审查时认为有必要。

• 提出问题以澄清任务。

• 调整项目的待办事项同步，以改进评估任务的选择。

你如何解决"所有任务都紧急且首要"的困境？

利用评估扑克功能向他人隐藏估算。这鼓励公正的评估，有助于优先考虑真正关键的任务，减轻将所有内容标记为紧急和高优先级的倾向。