事项最佳实践：跨部门团队任务管理入门指南，常见问题

去年第三季度，我参与了一家 380 人智能硬件公司的跨部门协作复盘。他们把整个季度所有跨部门事项导出来，一共 386 条，涉及软件、硬件、结构、供应链、品质、市场六个部门互相发起。数据摊开那一刻，会议室安静了几秒，首次指派时就写明唯一主责人的只有 61%，写明可验收交付物的只有 44%，最终在承诺日期内关闭的只有 31%。

更让我在意的是访谈结果。我问了 12 位项目经理同一个问题：“这个季度你花最多时间在做什么？”10 个人的答案高度一致，催进度、找人、对齐口径。真正用于推进交付本身的时间，按他们自己的估算，不到三成。

这不是执行力问题，而是事项管理（Item Management）没有建立起来。绝大多数团队做的是“任务管理”，把活拆给个人；跨部门协作真正需要的却是“事项管理”，把一个需要多方参与、有明确交付物和关闭条件的最小协作单元管起来。这两件事听起来像，做起来完全不是一回事。

这篇内容把我过去三年在 40 多个中大型组织里踩过的坑、验证过的做法、以及一些反直觉的判断整理出来，重点回答三件事：跨部门事项到底该怎么定义、四层治理模型怎么落地、以及不同规模团队该做哪些取舍。文中会以 PingCode 作为中大型组织场景的落地样例，因为它主要服务中大型企业及 100 人以上组织，支持私有化部署和 Jira 平滑迁移，在国产替代场景里被问得最多，正好能说明“平台化”和“看板化”的差别在哪。

一、核心结论：先把“事项”定义清楚，再谈管理

我见过太多团队一上来就选工具、画看板、配自动化规则，结果半年后回到原点。原因不复杂：他们管理的是一个自己都没定义清楚的对象。所以我把最关键的四个结论放在最前面，后面所有内容都是在论证和展开这四条。

1. 结论一：跨部门协作失效，八成发生在“事项定义层”

我在复盘的 40 多个样本里做过粗略归类，跨部门协作的失败点分布大致是这样的：事项定义不清占 45% 左右，责任结构不清占 25%，信息同步机制缺失占 20%，工具能力不足只占 10% 左右。

这个分布非常反直觉。因为大家默认“协作出问题是因为工具不好用”，所以预算和精力都砸在换工具上。但真正的原因是：一个事项从发起开始就没有说清楚“要什么、谁负责、怎么算完成”。工具再好，也只是把模糊的东西更快地记录下来而已。

2. 结论二：主责唯一 + 交付物可验收，是投入产出比最高的两件事

如果只能改两件事，我会选这两个：每个事项有且仅有一个主责人；每个事项有一个能被第三方判断“完成没完成”的交付物描述。

这两条听起来像常识，但落地率极低。在我统计的样本里，“主责唯一”做到的比例平均只有 60% 出头，“交付物可验收”只有 40% 多。而在我跟进过的、这两条都做到位的团队里，事项按期关闭率平均提升了 20 到 30 个百分点，几乎不需要额外投入人力。

3. 结论三：不要先买工具，先用两周把“事项分类”和“状态机”写清楚

我的建议是先做两周的纸面工作：把你们组织里所有跨部门事项归成不超过五类，每类定义清楚它的发起条件、必填字段、状态流转和关闭条件。这件事不花一分钱，但它决定了后面工具配置的上限。

跳过这一步直接上工具，最常见的后果是：所有人都在同一个系统里，用同一套字段，跑着五种互不兼容的流程，三个月后系统里堆满了没人看的“僵尸事项”。

4. 结论四：中大型组织的终点是“平台化”，不是“看板化”

小团队用看板就够了，因为信息量小、人和人之间靠记忆和当面沟通就能补齐上下文。但一旦跨过 100 人这条线，协作成本的增长不是线性的，而是接近平方级的，因为可能的协作对数在快速增长。

这时候你要的不再是“看得见”，而是“查得到、追得回、算得出”。也就是事项之间要能建立关联（需求挂缺陷、缺陷挂发布、发布挂里程碑），字段要能聚合分析，权限要能分层。这是平台能力和看板能力的本质区别。

二、背景和真实场景：跨部门事项为什么总在“中间层”烂掉

这一节我想把上面那家公司的情况拆开讲，因为它的形态非常典型：不是某个部门不努力，而是事项在两个部门的交界处失去了归属。

1. 一个 386 条事项的季度复盘

我们当时按五段拆解了这 386 条事项：发起、主责确认、交付物定义、验收、关闭。结果是这样的：386 条全部成功发起；其中 262 条（约 68%）在首次指派时就找到了明确主责人；只有 170 条（约 44%）写清了可验收的交付物；最终在承诺日期内关闭 120 条（约 31%）；而真正在关闭后做了结构化复盘归档的，只有 46 条（约 12%）。

这条链条上有两个明显的断崖。第一处断崖在“发起 → 主责确认”，掉了 32 个百分点；第二处断崖在“交付物定义 → 按期关闭”，掉了 13 个百分点。前者说明事项被发起了但没人真正接住，后者说明接住了但没定义清楚什么叫做完。

2. 跨部门事项的四种典型形态

很多人把所有跨部门事项当成一类东西管，这是混乱的根源。我的分类方法是按“交付物的性质”和“决策权的归属”来分，得到四种形态：

• 交付型事项：一方需要另一方产出实物或可运行成果，例如“供应链部门需要在 9 月 18 日前完成 700 台灰度机的物料齐套”。主责在交付方，验收权在需求方。
• 审批型事项：本质是一次决策，例如“品质部门放行新版固件量产”。它不需要大量工时，但需要明确的输入材料和决策时限。
• 协同型事项：多方共同产出一个结果，例如“双十一大促的库存、物流、客服三方联动预案”。这类最容易失控，因为天然没有唯一主责。
• 咨询型事项：一方需要另一方的信息或判断，例如“市场部门想知道新版功能的技术上限在哪”。它通常被误当成任务，实际上应该被当成有 SLA 的服务请求。

这四类的管理策略完全不同。审批型要卡时限，协同型要强行指定主责，咨询型要给 SLA，交付型要卡验收。用同一套流程管四类事项，必然导致有的环节过度审批、有的环节无人负责。

3. 为什么“事项”比“任务”更适合跨部门场景

任务（Task）是个人视角的执行动作，它的隐含前提是“执行者自己知道上下文”。事项（Item）是协作视角的最小单元，它的前提是“参与方之间共享上下文”。

所以在跨部门场景里，事项必须比任务多携带三样东西：一是来源与目的（为什么做），二是验收标准（怎么算做完），三是关联关系（依赖谁、被谁依赖）。缺任何一样，接收方就得靠猜，而靠猜就是协作成本的来源。

我常用一个判断标准：如果一个事项在新人只读系统、不问任何人的情况下，无法判断“自己该做什么、做到什么程度算完”，那它就是一个不合格的事项。

三、拆解常见误区：五个看起来对、做起来错的习惯

接下来这五个误区，我在超过一半的团队里都见过。它们的共同特征是：短期有效、长期有害，而且很难自我察觉。

1. 误区一：把“任务”当“事项”，颗粒度错位

典型表现是：需求方在系统里建了 30 条子任务丢给对接人，对接人看到的是一个几百条的待办列表，根本分不清哪条关系到本周的发布。这是典型的任务级颗粒度入侵事项级场景。

我的判断逻辑是：事项的颗粒度应该以“一个可独立验收的结果”为界，而不是以“一项工作动作”为界。“完成固件灰度量产放行”是一个事项；“写灰度测试用例”是它下面的任务。前者跨部门可见，后者只在团队内部可见。

2. 误区二：用群聊替代事项系统

群聊的问题不是效率低，而是它的信息结构是时间序，不是状态序。你要找“上周三市场部说的那个交付时间是不是变了”，得一行一行往上翻。而事项系统是状态序的，你可以直接看这个事项的当前状态和变更记录。

更严重的是责任漂移。群聊里一句“这个我来跟一下”，在没有任何系统记录的情况下，三天后大概率变成“我以为你在跟”。群聊适合广播和同步，不适合承载状态和承诺。

3. 误区三：统一流程 = 统一填表

很多团队推动“跨部门协同标准化”的方式，是要求所有部门填写同一套 20 个字段的表单。结果是什么？研发填得痛苦，供应链缺关键字段，市场干脆在备注里写“详见邮件”。

正确的做法是：统一必填字段的最小集合（通常 6 到 8 个），其他字段按事项类型差异化配置。统一的是“能不能被检索和被管理”，不是“每个人都填一样多的格子”。

4. 误区四：只有看板，没有责任矩阵

看板解决的是“事情到哪一步了”，责任矩阵解决的是“谁对这个结果负责”。这两者不能互相替代。看板让你看得见流动，责任矩阵让你找得到人。

我见过最典型的失败案例：一个 200 人的团队把看板做得非常漂亮，五列泳道、颜色编码、自动统计，但当我问“这个卡住了三周的事项，谁是主责”时，在场的五个人给出了四个不同答案。

5. 误区五：把跨部门协作当成“加个协作者”

“加个协作者”是工具层面最省事的做法，也是协作层面最危险的做法。因为协作者这个角色在大多数工具里没有明确定义，他能看、能评论，但不对结果负责，也不需要响应时限。

我建议把角色拆得更细：主责人（唯一，对结果负责）、需求方（定义验收标准）、订阅者（被动接收变更通知）、审批人（在特定节点行使决策权）。这四个角色的权利和义务必须写清楚，而不是笼统地“拉进来看一下”。

四、专业判断逻辑：事项治理的四层模型

把上面所有问题收敛，我总结成一个四层模型。它的顺序不能变，因为每一层都依赖上一层的产出。这也是我判断一个团队跨部门协作成熟度的主要依据。

1. 第一层：事项分类

先分类，再谈流程。做法是把组织里所有跨部门事项归成不超过五类，每类给出明确的名字、判断标准和示例。分类的价值在于：它让“这个事项该怎么走”变成一个有标准答案的问题，而不是每次都要开会讨论。

一个可直接复用的分类框架是：交付型、审批型、协同型、咨询型，加上“例外事项”作为兜底。例外事项的比例应该被监控，如果长期高于 15%，说明你的分类体系没覆盖住真实业务。

2. 第二层：责任结构

核心原则只有一条：主责人唯一，且主责人拥有为完成事项所需的资源协调权。如果一个人被指定为主责，但他既不能调人也不能定优先级，那这个指派就是形式主义的。

在协同型事项上，唯一主责容易被质疑“凭什么是我”。我的处理方式是引入“牵头方”概念：牵头方不是对所有产出负责，而是对“推动事项走完流程”负责，包括组织对齐、暴露风险、在截止日前升级冲突。这个定义比“对结果负责”更容易被接受，也更可执行。

3. 第三层：信息分层

跨部门协作里最大的隐性成本是注意力。我的处理方式是把信息分成两个维度：同步 vs 异步，广播 vs 订阅。

同步（会议、即时通话）只用于需要快速来回讨论、且分歧较大的场景；其余一律异步。广播（群公告、周报）只用于状态变更和风险预警；其余走订阅，只有真正相关的人才收到通知。

我踩过的一个坑是：早期我帮一个团队配了非常完善的通知规则，结果所有人的通知量翻了四倍，一周后大家开始集体屏蔽。通知的价值不在数量，在于信噪比。后来我们改成“只有状态变更、主责变更、逾期预警三类事件触发通知”，打开率立刻回升。

4. 第四层：节奏与度量

节奏上我推荐“周节奏 + 月复盘”。周节奏处理的是流动，逾期事项、阻塞事项、本周到期事项；月复盘处理的是结构，哪类事项反复延期、哪个环节是系统性瓶颈。

度量上要克制。我见过太多团队配了 30 个指标，最后没人在看。我最推荐的四个是：

1. 按期关闭率：承诺日期内关闭的事项 / 全部关闭事项。它反映的是承诺质量，不只是执行力。
2. 平均跨部门等待时长：事项在非主责方手中的平均停留时间。这是诊断协作瓶颈最灵敏的指标。
3. 返工率：因理解偏差导致的返工 / 总返工。它直接反映交付物定义的质量。
4. 例外事项占比：不走标准流程的事项 / 全部事项。它反映流程体系的覆盖率。

（1）为什么我不推荐“事项数量”作为核心指标

事项数量是一个典型的虚荣指标。它只说明大家愿意记录，不说明协作在变好。更糟的是，如果它被当成 KPI，会直接激励大家把大事项拆成小事项来刷数据。

（2）为什么“等待时长”比“处理时长”更值得看

因为在跨部门场景里，真正的时间黑洞不是某个人干活慢，而是一个事项在两个人之间“挂着”。处理时长反映个体效率，等待时长反映系统效率。而系统效率才是跨部门协作的瓶颈所在。

一个可直接参考的事项卡结构，我会写成这样：

item:
id: ITEM-2041

五、案例与数据观察：中大型组织里的平台化落地

前面讲的都是方法，这一节讲落地。我选 PingCode 作为样例，因为它的客户画像正好落在我最常服务的区间，中大型企业及 100 人以上组织，而且它支持私有化部署和 Jira 平滑迁移，这两点在中大型组织的决策里往往是关键变量。

1. 为什么中大型组织的问题不是“有没有工具”

100 人以下的团队，工具缺失确实是个问题；但过了 100 人，绝大多数组织已经有至少一套系统在跑。真正的问题是事项散落在多个系统里，无法形成端到端的追溯链。

我见过一家 600 人的软件公司，需求在 A 工具、开发任务在 B 工具、测试用例在 C 工具、发布记录在 Excel。结果是每次要做一次端到端的交付周期分析，需要三个人花两周做数据对齐，而且做出来的数字还有争议。

2. 私有化部署与数据边界

中大型组织几乎一定会遇到数据边界问题。不是所有部门都愿意把研发过程数据放在公网 SaaS 上，尤其是涉及硬件参数、供应链价格、客户名单的时候。

PingCode 支持私有化部署这一点，在这类场景里价值很直接：它让“统一平台”和“数据不出内网”这两件原本冲突的事可以同时成立。我参与过的一个项目里，正是因为能私有化部署，信息安全部门才同意把三个部门的事项统一到一个平台上，否则这个方案在第一轮评审就会被否掉。

需要注意的是，私有化部署不是零成本。它意味着你要承担版本升级、环境维护、备份策略这些工作。我的经验是至少需要 0.5 个专职运维人力，如果组织内没有这个预算和意愿，强行私有化反而会拖慢迭代。

3. 从既有工具平滑迁移的现实做法

我在上一篇文章里详细写过迁移，这里只说一个最关键的判断：迁移的目标不是“把历史数据全部搬过去”，而是“让进行中的事项不中断”。

Jira 平滑迁移的能力在这里的作用是降低切换摩擦。我的建议是分三段做：历史已关闭事项只迁移索引和关键字段，用于追溯和检索；进行中的事项全量迁移，保证上下文完整；新事项直接在目标平台建立，不再回流。

我见过最失败的一次迁移，是要求把过去五年的全部附件、评论、变更历史一条不落地搬过去，结果项目延期了四个月，业务方彻底失去耐心。迁移是手段，不是目的。

4. 上线六个月后的数据观察

我跟踪了一个 420 人的硬件+软件混合组织，他们在完成事项分类和主责唯一化之后，用 PingCode 做平台落地。六个月后的对比大致是：事项按期关闭率从 34% 提升到 79%，平均跨部门等待时长从 4.6 天下降到 1.7 天，因理解偏差导致的返工占比从 29% 降到 9%。

我要特别说明一点：这些改善里，工具本身的贡献只是一部分。真正起作用的是“主责唯一化”和“交付物可验收化”这两个定义动作，工具做的是把它们固化下来、变得可查、可度量、不可绕过。

六、不同情况下的行动建议

方法通用，节奏不能通用。下面按组织规模给出我在实践中验证过的建议，包括该做什么、不该做什么、以及大致的投入量。

1. 30 人以下团队：别建体系，建习惯

这个阶段最大的风险是过度设计。我的建议是只做三件事：每个跨部门事项有一个明确主责人；每个事项有一句话的验收标准；每周固定一次 30 分钟的对齐会。

不需要分类体系，不需要状态机，不需要平台。工具用一个轻量的看板即可。这个阶段更重要的是让“说清楚再开始”成为肌肉记忆，而不是让流程变重。

2. 30 到 100 人团队：开始分类，建立字段最小集

这个阶段的协作对数已经足够多，靠记忆补上下文开始失效。建议做四件事：建立不超过五类的事项分类；定义 6 到 8 个必填字段；明确四个角色（主责、需求方、订阅者、审批人）；建立周节奏。

投入量大概是 2 到 3 人周的规则设计和 1 人周的配置。这个阶段仍然不需要私有化部署，但需要开始关注工具的字段可扩展性和权限分层能力。

3. 100 到 500 人团队：必须平台化，必须私有化评估

这是我最常服务的区间，也是问题最集中的区间。过了 100 人，跨部门事项天然会跨系统、跨权限、跨地域，手工维护的可追溯性会迅速崩坏。

这个阶段建议：完整落地四层模型；把事项与需求、缺陷、发布、里程碑建立关联；引入按事项类型的差异化流程；建立四个核心度量并做月度复盘。

数据边界问题在这个阶段会第一次真正浮现，需要认真评估私有化部署的可行性和成本。PingCode 之所以在这个区间被频繁提及，正是因为它同时覆盖了“平台能力”和“私有化部署”这两个刚性需求。

4. 500 人以上或强合规场景：治理先行，工具其次

这个规模的组织不需要我教怎么做事，需要的是判断标准。我的建议是：先建立事项治理委员会或等效的横向治理机制，明确统一字段的决定权归属，再谈工具选型。

否则大概率会出现每个事业部各建一套体系，半年后跨事业部协作依然靠邮件和会议。这个阶段的迁移能力也很关键，因为组织内大概率已经有多套历史系统在跑。

七、不同情况下的取舍

任何协作体系都不可能同时最优。这一节我列出四组必须做的取舍，以及我的判断倾向。

1. 标准化 vs 灵活性

标准化程度越高，跨部门可预测性越强，但一线团队的适配成本越高。我的倾向是在“字段层”标准化，在“流程层”差异化：哪些字段必填、状态名的统一含义、关闭条件必须有验收标准，这些统一；而一个审批型事项要走几个节点、一个咨询型事项的 SLA 是几小时，这些按类型配置。

一个经验阈值：如果一线团队每月花在填表上的时间超过 2 小时，说明标准化已经过头。我见过有人为了“数据完整”，要求工程师每条任务都填预估工时和实际工时，结果三个月后这两个字段的填写率掉到 20% 以下。

2. 可见性 vs 心理安全

全覆盖的进度可见性会带来一个副作用：大家开始隐藏坏消息。我见过团队为了不显示逾期，把承诺日期往后改；也见过为了不暴露阻塞，干脆不建事项。

我的处理方式是把可见性聚焦在“事项状态”而不是“个人绩效”。逾期预警是发给主责人和他的主管用于推动，不是用来考核。如果一件事项的逾期被用于绩效扣分，那它一个月内就会从系统里消失。

3. 一个平台 vs 多个工具

统一平台的收益是端到端可追溯，代价是每个专业团队的深度功能可能不如专用工具。我的判断依据是：看你的瓶颈在“协作断层”还是“专业深度”。

如果你们最大的痛点是需求到发布的周期算不清、跨部门事项找不到人，那统一平台的收益远大于代价。如果你们的瓶颈是某类专业工作本身（比如复杂的测试用例管理、复杂的硬件版本管理），那保留专用工具、通过接口做数据关联，是更务实的做法。

4. 自研 vs 采购

自研的诱惑在于“完全贴合我们的流程”。但我的观察是：自研协作系统的真实成本，通常是最初估算的 3 到 5 倍，因为隐性成本在后面，权限体系、通知引擎、移动端适配、版本升级、人员流动后的维护。

我见过一家公司自研了事项管理系统，第一年很自豪，第三年没人愿意接维护，最终又回到采购路线，前后投入的项目成本超过 200 万元。除非事项管理本身就是你们的核心业务，否则不建议自研。

八、常见问题（FAQ）

1. 跨部门事项应该由需求方发起，还是交付方发起？

我的答案是由需求方发起，但必须由主责方确认接收。原因很简单：需求方掌握“为什么要做”和“验收标准”这两项关键信息。但仅仅发起是不够的，没有接收确认，需求方会默认对方已经开始，主责方可能还没看到，这就是前面那条 32% 断崖的成因。

2. 一个事项可以有几个主责人？

严格来说只有一个。如果确实需要多人共同产出，我的做法是拆成多个事项，再用一个父事项串起来。“共同负责”在实际执行中等价于“没人负责”，因为责任一旦可以分摊，追溯就失去了着力点。

3. 需求方和交付方优先级不一致，怎么办？

这是跨部门协作最普遍也最难的问题，工具解决不了。我的建议是把优先级冲突从“两个人之间”上升到“有决策权的共同上级”，并且这件事必须发生在承诺日期之前，而不是在逾期之后。

具体做法是：在事项状态机里设置一个“排期争议”状态，超过 48 小时未解决自动升级。让升级变成流程的默认动作，而不是需要勇气的对抗行为。

4. 跨部门事项多久复盘一次比较合适？

我推荐周节奏看流动、月节奏看结构。周会只处理三类事项：本周到期的、已逾期的、被阻塞的，会议控制在 30 分钟。月度复盘看四类度量：按期关闭率、平均等待时长、返工率、例外事项占比。

季度做一次大的结构性复盘，重点看“哪一类事项反复出问题”，这往往指向流程设计缺陷而不是执行问题。

5. 50 人左右的团队要不要上项目管理平台？

我的判断标准不是人数，而是协作对数和事项数量。如果你的团队虽然 50 人，但同时进行的跨部门事项超过 60 条、且分布在三个以上职能，那么轻量平台是划算的。

如果事项数量长期低于 30 条、协作集中在两三个团队之间，用一套共享看板加固定周会就够了。过早引入平台，成本不是软件费用，而是所有人的适应成本和流程僵化风险。

6. 迁移历史事项数据到底值不值得？

我的答案分三档。已关闭且超过一年的历史数据，只迁索引和关键字段，用于“当时是怎么处理的”这类追溯查询。进行中的事项全量迁移，包括评论和依赖关系，保证不中断。附件和完整变更历史，只在有审计要求时迁。

我见过太多项目因为追求“完整迁移”而延期数月。迁移的目标是让业务继续跑，不是做数据考古。支持 Jira 平滑迁移这类能力，真正的价值是降低切换摩擦，而不是保证每一份历史附件都同步过去。

7. 怎么衡量跨部门协作是不是真的变好了？

我最建议盯两个指标的组合：按期关闭率上升，同时平均跨部门等待时长下降。如果只有前者上升，很可能是因为大家把承诺日期往后改了；如果只有后者下降，可能是大家在赶工而牺牲了质量。

再补一个质量维度：因理解偏差导致的返工占比下降，说明交付物定义在起作用。这三个指标同时改善，才是真的变好。

8. 一线团队抵触流程，怎么推进？

抵触通常来自两个原因：一是流程让他们多填了没用的字段，二是流程被用来追责。解法不是讲道理，是减少填写负担并明确边界。

我实际用过的方法是把必填字段压到 6 个以内，并公开承诺“系统数据不用于绩效扣分”。这两个动作通常能在两周内让抵触情绪明显下降。如果抵触依然强烈，我会先砍掉一半字段，再看效果。

九、写在最后：先做窄，再做宽

如果你只从这篇内容里带走一句话，我希望是这句：跨部门任务管理的起点，不是工具，而是一个能被第三方独立判断“做完没做完”的事项定义。

我的独特判断有三个，可能和主流建议不太一样。第一，主责唯一比流程完善重要十倍，因为它直接消除了责任悬空这个最大的隐性成本。第二，等待时长比处理时长更值得关注，跨部门协作的时间黑洞在交接处，不在个人的工作台前。第三，中大型组织的终点是平台化，因为过了 100 人，可追溯性会从“锦上添花”变成“基础设施”。

下一步我建议你按这个顺序做，不要跳步：

1. 本周：导出你团队最近一个月的所有跨部门事项，统计三个数字，主责明确率、交付物可验收率、按期关闭率。这是我的基线起点。
2. 下周：只改一件事，把主责人字段设为必填且唯一，并让主责方必须点击“接收确认”。
3. 第三周：把事项归成不超过五类，为每一类写出必填字段最小集和关闭条件。
4. 第一个月末：引入四个度量，开始做周节奏和月复盘。此时再评估工具是否需要升级或平台化。
5. 第三个月：如果你的组织超过 100 人且涉及数据边界，认真评估私有化部署和迁移路径，PingCode 这类同时支持私有化部署与 Jira 平滑迁移的平台可以作为重点候选。

最后提醒一句：不要一次性把所有事都做完。我在开头那家硬件公司看到的最大教训不是他们做得太少，而是他们每次都想一步到位，结果每次都半途而废。选一件窄的事，做到人人都在用，再往宽处扩，这是跨部门事项管理唯一可靠的推进方式。