目标进度落地方案：跨部门团队开展项目目标的入门指南案例解析

三周前，我陪一个客户复盘了一个跨部门目标：市场部、产品部、技术部共同背"Q3新增付费用户增长30%"。第21天，三个部门的进度分别是78%、41%、12%。开会两个小时，最后的结论是"下周加强协同"。散会时，技术负责人跟我说了句实话：不是不想推，是我到上周才知道自己部门被算进了这个目标。

这不是能力问题，也不是态度问题，更不是工具问题。跨部门目标之所以难落地，绝大多数时候是因为目标从设定那一刻起就没有被翻译成可执行、可追溯、可同步的结构。会议只是把这个结构缺陷暴露出来，而不是制造了它。

这篇内容不打算再讲一遍"什么是目标对齐""为什么要用OKR"。我直接把过去几年在十几个跨部门项目里反复验证、也反复踩坑的一套做法拆开讲：目标怎么从一句话变成一张卡，责任怎么从"大家一起负责"变成"谁决定谁执行"，进度怎么在不增加会议的前提下被看见，偏差出现后怎么在48小时内被处理掉。全文配了一套可以直接抄的字段定义、议程模板和分级标准，也包含一个完整的推演案例。

一、先给结论：跨部门目标落地失败，八成不是"沟通不够"，而是"信息结构不对"

先把最重要的判断放在前面，避免你在后面几百句里找答案。跨部门目标进度失控，第一原因通常不是沟通频率不够，而是每一次沟通所交换的信息结构是错的。大家在会上交换的是"我这边挺忙的""我这边还行""下周应该能推进"，这些都是状态描述，不是进度数据。

1. 三个反常识判断

第一个判断：沟通频率与落地进度几乎不成正比。我复盘过的项目里，日会的项目并不比周会的项目更快达成目标，但日会的项目会议总耗时平均高出2.4倍。原因是日会交换的是"我昨天做了什么"，而真正决定进度的"我卡在谁的决策上"很少被说出来。

第二个判断：责任矩阵比目标拆解更影响结果。大多数团队在目标拆解上花的时间是责任划分的3倍以上，但目标拆解只回答"要做什么"，不回答"谁有权拍板"。跨部门场景下，没有人拍板比不知道做什么更致命。

第三个判断：进度同步的真实成本在"解释"，不在"汇报"。一个部门把进度讲清楚需要3分钟，但要向另外两个部门解释"为什么这个数字是41%而不是60%"，往往需要20分钟。这20分钟才是会议开不完的原因。

2. 一句话判定你的跨部门目标能不能落地

我常用一个很粗暴的检验方式：把目标、负责人、当前进度、下一个决策点、卡点这五项写在纸上，如果其中任何一项你无法在30秒内说清并指到具体的人，这个目标就还没具备落地条件。注意，是"指到具体的人"，不是"指到具体的部门"。

落地条件 = 可量化 + 可追溯 + 可同步。三个条件缺一个，机制都会在某周突然失效。缺可量化，进度会变成形容词；缺可追溯，出问题时会互相等待；缺可同步，信息只在会议里存在。

3. 什么时候这套机制不适用

说清楚边界比说清楚方法更重要。如果项目周期短于4周、参与方不超过2个部门、目标本身不需要跨部门资源调配，那用这套机制是过度设计，投入的协调成本会超过收益。这种情况直接指定一个负责人、每周对齐一次就够了。

反过来，如果目标跨越3个以上部门、周期超过一个季度、且涉及预算或人力在部门之间的重新分配，那么不搭这套机制，进度一定会在某个节点停住，只是时间早晚的问题。

二、背景和真实场景：跨部门目标的进度为什么总在第三周开始塌

我观察到的一个稳定规律是：跨部门项目的前两周通常很热闹，第三周开始安静，第四周开始互相等待。这不是团队懈怠，而是机制在三周后失效了。

1. 进度衰减的三个时间窗口

第1，7天是热度期。启动会开完，所有人都记得目标，任务分配得也很清楚，这周的完成率通常能到70%以上。这个阶段的数据会给人一个错觉：好像不难。

第8，14天是摩擦期。第一批依赖关系开始出现，"我这边要等他们提供接口""他们那边的数据口径还没定"。进度开始出现局部停滞，但表面上的任务完成率还在50%左右，不容易被察觉。

第15，21天是塌陷期。停滞开始串联，一个部门的等待导致另一个部门的返工，返工又导致原计划失效。这时再看完成率，会出现断崖式下滑。我见过的项目里，第21天的完成率通常只有第14天的60%左右。

2. 我在17个项目样本里看到的三个数字

下面这组数据来自我个人的项目记录，样本口径是"3个以上部门参与、周期超过8周"的项目，共17个，其中11个最终达标、6个延期或缩减范围。它不是行业统计，但量级上有参考意义。

达标组的平均"偏差发现延迟"是2.1天，延期组是8.4天。换句话说，能不能早点发现问题，比能不能拼命执行更决定结果。

达标组的"单次同步会议平均时长"是38分钟，延期组是92分钟。延期组的会议不是不够多，而是每次会议都在补信息缺口，而不是在做决策。

达标组中，有10个项目在启动后两周内就更新过一次责任矩阵，延期组中只有1个。责任矩阵不是一次性文件，而是一个持续维护的活体结构。

3. 被完全忽略的成本：决策等待

大部分团队的进度管理只统计"人天投入"，不统计"等待时长"。一个任务卡在"等对方确认口径"上三天，这三天不会出现在任何工时报表里，但它实实在在推迟了整体交付。

我在复盘时会让每个部门单独填一列"本周等待他人决策的累计小时数"。17个项目里，延期组的平均等待时长占个人总工时的19%，达标组只有6%。这13个百分点的差距，几乎全部来自责任边界是否清晰。

三、拆解四个高频误区：你以为在做目标管理，其实在制造进度幻觉

下面四个误区我几乎在每个出问题的项目里都能见到至少两个。它们的共同点是：看起来都很合理，做起来都不难，但都不能解决真正的问题。

1. 误区一：目标只落到部门，没落到人

"市场部负责拉新、产品部负责转化、技术部负责性能优化"，这句话听起来分工明确，实际上什么都没说。部门不是执行单元，人是。当目标停在部门层级，部门内部会再做一次分配，而这次分配往往没人监督，也不对外透明。

结果就是：所有人都在等对方先动。我见过最典型的场景是，三个部门都认为"增长30%"这个目标自己不是主责方，因为主责方写成的是"多部门共同负责"。"共同负责"在跨部门语境下约等于"无人负责"。

2. 误区二：把单团队的OKR模板直接搬到跨部门

OKR在单团队内部很有效，因为目标的所有者、执行者、评估者是同一批人。但搬到跨部门场景，会出现一个结构性错配：OKR解决的是"聚焦"，而跨部门需要解决的是"接口"。

具体表现是，每个部门都能写出漂亮的O和KR，但这些KR之间没有依赖关系描述，也没有接口约定。到了执行阶段，A部门的KR要等B部门的KR产出，而B部门并不知道自己被依赖了。我一般建议跨部门目标在OKR基础上做减法：减少KR数量，增加依赖关系和交付接口字段。

3. 误区三：用周会代替进度机制

周会本身没问题，问题是把周会当作进度的唯一载体。会议是有损压缩：一周的信息压缩进60分钟，每个人只能分到几分钟，能讲清楚的是结论，讲不清楚的是过程和卡点。

更麻烦的是，一旦周会延期或有人缺席，进度信息就出现真空。我判断一个团队有没有真正的进度机制，标准很简单：如果取消一周的所有例会，进度数据是否仍然完整、可查、可追溯。如果答案是"不行"，那你拥有的不是机制，而是会议。

4. 误区四：偏差处理采用"再观察一周"

跨部门场景下，"再观察一周"的成本远高于单团队。因为跨部门的纠偏需要重新协调多方资源，等待一周意味着后面要压缩更多人的排期，而这种压缩往往会引发新的抵制。

我给客户的一个硬性建议是：跨部门目标的偏差不允许"无结论顺延"。要么当周调整方案，要么明确升级到更高层级决策，要么显式缩减目标范围。三种都可以，唯独不能什么都不做地等一周。

四、四步框架：把目标从"一句话"变成"一套可运行的机制"

这套框架我用了三年，中间改过五版，最终稳定在四步。顺序不能换，因为每一步的输出都是下一步的输入。

1. 第一步：目标共识，从各说各话到一张目标卡

目标卡的作用是消灭形容词。它的七个必填字段是：目标陈述（含量化口径）、目标所有者（一个人，不是部门）、协同方与各自贡献、衡量指标与数据来源、关键里程碑、当前进度口径、下一个决策点。

其中我要求最严格的是两个字段。第一是量化口径，必须写清楚统计范围和时间截点，例如"Q3自然季度内、新注册且完成首单支付的用户数"。第二是数据来源，必须写清楚从哪个报表或看板取数，避免出现两个部门报出两个数字。

共识会的议程我固定为70分钟：前15分钟由所有者讲目标卡全文，中间35分钟每个协同方只讲两件事，我能贡献什么、我需要什么，最后20分钟逐条确认字段并当场修改。允许在会上争论，不允许会后补充。

2. 第二步：责任拆解，简化版RACI在跨部门场景的用法

完整的RACI矩阵在跨部门项目里太重，容易做成形式。我一般简化为三列：执行人（谁做）、决策人（谁拍板）、知会人（谁必须知道）。每一行是一个具体交付物，不是一项职能。

这里最容易出错的是决策人。很多团队把决策人写成"项目组"，这等于没有决策人。我的规则是：每一项交付物必须有且只有一个决策人，且这个人必须是能调动资源的人。如果一项交付物需要两个部门共同决策，那说明它应该被拆成两项。

维护频率上，我建议在项目前四周每两周更新一次责任矩阵，之后每月一次。更新不是重写，而是确认是否有人换了、边界是否变了。

3. 第三步：进度同步，异步为主，同步为辅

同步机制的设计原则是：能用结构化数据表达的，不要用会议表达；必须当面讨论的，才放进会议。按这个原则，我把进度同步拆成两层。

异步层是进度看板，最小字段设计为：任务名、负责人、状态、计划完成日、实际/预计完成日、阻塞项、下一次更新日。其中"阻塞项"字段是跨部门场景的核心，它必须写清"在等谁、等什么、等多久"。没有这个字段，看板就只是任务清单。

同步层是周会，我把它压缩到30分钟，固定三个环节：上周偏差回顾（10分钟）、本周依赖确认（10分钟）、需要升级的决策（10分钟）。周会不做进度汇报，进度已经在看板上，会议只处理偏差和依赖。

4. 第四步：偏差处理，三级分级与升级路径

偏差分级是让跨部门协作不陷入扯皮的关键。我用的标准是三级：一级偏差是单任务延期但不超过3个工作日、不影响关键路径，由执行人自行调整并更新看板即可。二级偏差是关键路径任务延期3，7个工作日，或影响至少一个下游部门，需要在周会上决策并当场给出调整方案。

三级偏差是关键路径延期超过7个工作日、影响最终目标达成概率超过10%、或需要跨部门重新分配资源。这类偏差必须在发现后48小时内升级到目标所有者或更高层级，并在升级时同时提交两个以上的可选方案。升级不是告状，是请求决策，所以必须带方案。

5. 一套可直接复用的看板字段定义

下面是我在实际项目里用的任务字段定义，用YAML格式写出来，方便直接搬到任何项目管理工具里配置自定义字段。字段设计的原则是：每个字段都必须能被填成具体值，不能填成"进行中"这类无信息量的词。

task:
id: 唯一编号

name: 交付物名称 # 必须是名词，不能是动词

owner: 单个责任人姓名 # 不允许填部门

decider: 单个决策人姓名 # 每项交付物唯一

informed: [知会人列表]

milestone: 所属里程碑

plan_date: 计划完成日

forecast_date: 预计完成日 # 每周更新，与plan_date的差值即偏差量

status: 未开始 | 进行中 | 阻塞 | 已完成 | 已取消

blocker:

waiting_for: 等待对象姓名 # 阻塞时必填

waiting_what: 等待的具体事项

waiting_days: 已等待天数

dependency: [上游任务id列表]

progress_metric: 数值型进度 # 例如"已完成接口数/总接口数"

next_update: 下一次更新日期

这里我想特别强调 forecast_date 这个字段。它比 status 有用得多。因为 status 是主观的，而 forecast_date 是可比较的：如果预计完成日连续两周往后推，不用任何人解释，偏差就已经被看见了。

五、案例推演：一个"Q3增长30%"目标如何从停滞到重启

下面这个案例是虚构的，但每一个细节都来自真实项目，包括那些让人尴尬的部分。我用它来演示四步框架怎么用，以及用了之后哪些东西会变、哪些不会变。

1. 起点：第21天的现场

目标：Q3自然季度内，将新增付费用户数从季度基准提升30%。参与方：市场部（获客）、产品部（转化链路）、技术部（性能与稳定性）。第21天，三个部门自报进度78%、41%、12%，整体完成率不足30%。

更麻烦的是，没有人能说清"30%"这个数字的口径。市场部按注册用户算，产品部按激活用户算，技术部按可用性指标折算。三个部门各自都没做错，但三个数字放在一起毫无意义。

2. 第22天：用目标卡把口径统一

我把三方拉到一起，只做一件事：填目标卡。量化口径最终定为"Q3自然季度内、新注册且完成首单支付的用户数，取数为支付系统日终报表"。数据来源只有一份，口径争议当场结束。

目标所有者定为增长负责人一个人。协同方的贡献被写成具体承诺：市场部承诺季度内带来X个有效线索、产品部承诺将注册到首单转化率提升至某区间、技术部承诺核心链路P95响应时间控制在某阈值以内。

口径统一之后，三个部门的进度从78%、41%、12%变成了一个共同数字：整体完成度24%。这个数字不好看，但它是真实的，而且所有人都认同。

3. 第23天：责任矩阵与依赖登记

我们把所有交付物拆成28项，每项都有唯一决策人。拆完之后立刻暴露了9个跨部门依赖关系，其中有4个此前从未被明确登记过。这4个是后面三周的主要风险源。

同时识别出3项"两个部门共同决策"的交付物，全部拆成两项，各归一个决策人。这一步看起来是文字工作，实际上把后面两周的决策等待时间从平均3.2天压到了1天以内。

4. 每周节奏：30分钟周会加实时看板

周会固定在周一上午30分钟，三个环节：上周偏差回顾、本周依赖确认、需升级决策。看板每天更新，由各任务负责人在下班前更新 forecast_date 和 blocker 字段，不要求写文字说明。

前两周的效果是：偏差平均在1.3天内被发现，而不是之前的7天以上。发现得早，处理成本就低，很多偏差只需要一次十分钟的对话就能解决。

5. 第24天：一次典型的三级偏差处理

第24天，技术部的一个核心接口改造预计延期11天，属于三级偏差。按机制，必须在48小时内升级并带方案。技术部提交了三个方案：一是延后接口改造、先做临时降级方案，牺牲部分性能；二是抽调另一条线的两名工程师支援，牺牲那条线的排期；三是缩减本次改造范围，只覆盖主链路。

三方在一天内开会决策，选择方案三，同时接受性能指标从原定阈值放宽10%。整个处理过程用了31小时，其中等待决策的时间不到4小时。对比之前"再观察一周"的做法，这次省下了至少6天的无效等待。

6. 工具层怎么支撑：以 PingCode 为例

上面的机制可以在表格里跑，但当参与方超过三个部门、任务数超过50项时，表格会迅速失控。这时候需要工具来承载字段、权限和视图。

我在这类项目里用 PingCode 做过几次完整部署，它主要面向中大型企业及100人以上组织，几个特性在跨部门场景下比较实用。第一是自定义字段能力强，上面那套 blocker（等待对象、等待事项、等待天数）和 forecast_date 都能配成工作项字段，并且能设置成阻塞状态下的必填项，从机制上避免"只报状态不报卡点"。

第二是依赖关系可视化。跨部门项目最怕的就是依赖没被登记，PingCode 支持在工作项之间建立依赖并在视图中呈现阻塞链路，这比在会议里靠记忆点数可靠得多。第三是权限与可见性设计，不同部门可以在同一目标下看到彼此的关键进度，但不需要暴露各自的内部任务细节，这对跨部门协作中的"信息边界"问题很关键。

另外两个在实际落地中经常被提到的点：一是支持私有化部署，对于数据不能出内网的制造、金融类客户，这一条往往是选型的一票否决项；二是支持从 Jira 平滑迁移，包括工作项类型、字段和历史的映射，很多团队在替换工具时最担心的就是历史数据丢失和成员重新学习成本，这一点能省下大量迁移时间。在国产替代的语境下，它在功能覆盖和迁移路径上是我会优先考虑的一个选项。

需要说明的是，工具只解决"信息结构能否被稳定承载"的问题，它不会自动让目标落地。我见过配了完整字段但没人在下班前更新的看板，那种情况下再好的工具也只是另一个摆设。

7. 结果与没变的部分

这个目标最终在第70天达成，比原计划晚了4天。但我想强调的是另一件事：机制并没有让执行变轻松。技术部依然加班，产品部依然要改需求，市场部依然要压成本。机制改变的只是这些摩擦被处理的速度，从平均7天缩短到1天左右。

所以如果有人告诉你上了某套方法或某个工具就能让跨部门目标轻松达成，那基本可以不听。跨部门协作的成本天然存在，机制的价值在于不让这些成本以"沉默等待"的形式被浪费掉。

六、不同情况下的行动建议：按团队规模和组织形态分三档

同一套机制在不同规模的团队里需要的复杂度完全不同。用错档位，要么过度设计拖慢节奏，要么机制太轻根本压不住问题。

1. 30人以下、2，3个部门参与

这个规模不要上完整框架。我的建议是只做两件事：一张目标卡，加一个每天更新的共享看板。目标卡确保口径统一，看板确保进度可见。周会可以保留，但压缩到15分钟，只讨论需要跨部门协调的事。

责任矩阵在这个规模下可以用一句话代替：每项交付物明确一个负责人，并在群里公开。不需要文档化，但必须公开。公开本身就是一种约束力。

2. 30，100人、3，5个部门参与

完整四步框架在这个规模收益最高。建议配置是：目标卡作为共享文档常驻、责任矩阵每两周更新、看板字段完整配置、周会30分钟固定议程。偏差分级机制必须建立，否则中层管理者会陷入无休止的协调。

这个规模下我建议指定一个轻量的协调角色，不一定是专职PMO，可以是某个部门里对全局比较了解的骨干，每周花2，3小时维护看板数据质量和依赖关系。这个角色的价值不在管理，而在保证信息不失真。

3. 100人以上、5个以上部门参与

这个规模靠人维护已经不可靠了，必须依赖工具承载字段、权限和依赖关系。前面提到的 PingCode 就是在这类场景下比较合适，它的定位是中大型企业和100人以上的组织，自定义字段、依赖可视化和私有化部署这几项能力在这个规模下才真正显出必要性。

同时需要建立两层机制：项目层保持四步框架不变，组织层需要一个统一的目标台账，把所有跨部门目标的目标所有者、当前状态、三级偏差记录汇总起来。没有这个台账，高层看到的永远是各部门自报的"进展顺利"。

另外这个规模下要特别注意信息边界。不是所有人都需要看到所有细节，过度透明会带来隐私和内部竞争问题。建议以"交付物级别可见、任务级别按需可见"为原则配置权限。

七、不同情况下的取舍：这套机制什么时候值得投入，什么时候应该放弃

任何机制都有成本。目标卡的填写、责任矩阵的维护、看板的每日更新，加起来每周大约占用项目组2，4小时。这个投入不是所有项目都值得。

1. 生命周期短于6周的项目：放弃完整机制

6周以内的项目，机制搭建本身要花掉一周，收益期太短。这类项目我的做法是：只做目标卡和口头责任确认，每周一次15分钟对齐，其他全部省略。短期项目的关键不是管理精度，而是响应速度。

2. 弱矩阵组织：先解决授权，再谈机制

如果项目经理没有跨部门资源调配权，那再完善的机制也会卡在"我需要两个人但调不动"这一步。这种情况下应该优先向上升级，争取明确的项目授权，或者把关键决策人直接放进项目组。

在没有授权的组织里推行跨部门目标机制，结果往往是把协调成本从执行层转移到项目经理个人身上。这不是机制能解决的问题。

3. 工具自建、采购还是用现成表格

表格适合50项任务以内、3个部门以内的场景，优点是零成本、无学习门槛。缺点是无法自动计算依赖、无法做权限分层、数据容易失真。

采购成熟工具适合任务超过100项、参与方超过4个部门的场景。这里要考虑的不只是功能，还有三点：数据是否需要私有化部署、成员的学习成本、以及未来是否可能需要迁移。对于已经在用国外工具、希望做国产替代的团队，迁移成本往往是最大的隐性支出，PingCode 在这方面支持从 Jira 平滑迁移，能显著降低切换风险，这是我建议在做选型对比时重点验证的一项。

自建工具我只在两种情况下推荐：一是组织内有成熟的技术团队且协作流程高度特殊，二是数据合规要求极端严格。除此之外，自建的成本通常在第二年就会超过采购成本。

八、第一周行动清单与三个可直接复制的模板

到这里方法论已经讲完。如果你现在手里就有一个正在停滞的跨部门目标，下面这套动作可以在一周内完成，不需要任何工具采购。

1. 第一周的五个动作

第一天：把当前目标的量化口径写下来，发给所有参与方，请他们分别回复"我理解的数字是多少"。收集回来的差异就是你的第一份问题清单。

第二天：召开70分钟目标共识会，用目标卡逐字段确认，当场定下唯一的目标所有者和数据来源。会上的争论一定要当场解决，不要留到会后。

第三天：拆交付物，每项指定唯一决策人。凡是出现"共同决策"的项，拆成两项。

第四天：建立看板，配置七个核心字段，特别是 blocker 和 forecast_date。指定每天的更新时间（建议下班前15分钟），不要求写说明文字。

第五天：开第一次30分钟周会，只做三件事，回顾上周偏差、确认本周依赖、处理需升级的决策。第一次周会的质量决定了这套机制能不能活过第三周。

2. 目标卡模板

模板要保持极简，字段太多会没人填。下面这七个字段是我验证过的最小可用集合。

goalsheet:
goal_statement: 一句话目标，必须含量化口径与时间截点

metric_definition: 指标计算公式

data_source: 取数来源系统 + 报表名 + 更新频率

owner: 目标所有者（单人）

contributors:

department: 部门名

contribution: 具体承诺的可交付成果

contact: 对接人

milestones:

name: 里程碑名称

date: 计划完成日

exit_criteria: 通过标准

current_progress: 当前进度值 + 统计日期

next_decision_point: 下一个需要决策的事项与时间

3. 责任矩阵与偏差分级模板

责任矩阵用三列就够，关键是每一项都有唯一的决策人。偏差分级则要写清楚每一级的判定标准和响应时限，避免执行层自行判断"这算不算严重"。

responsibility_matrix:

deliverable: 交付物名称

executor: 执行人

decider: 决策人（唯一）

informed: [知会人]

dependency: [上游交付物]

due_date: 交付日

deviation_levels:

level_1:

criteria: 单任务延期action: 执行人自行调整，更新forecast_date

response_time: 当天

level_2:

criteria: 关键路径延期3-7个工作日 或 影响>=1个下游部门

action: 周会决策并当场给出调整方案

response_time: 3个工作日内

level_3:

criteria: 关键路径延期>7个工作日 或 影响目标达成概率>10%

action: 升级至目标所有者，提交>=2个可选方案

response_time: 48小时内

这三个模板加起来不到一页纸，但它们覆盖了跨部门目标落地最容易出问题的三个位置：口径、责任、偏差。模板的价值不在于填写本身，而在于填写过程强迫所有人把模糊表述替换成具体的人和日期。

写在最后：跨部门目标落地的本质，是让每个人知道自己的动作如何影响全局

回到最开始那个场景。三个部门、一个共同目标、三周后进度停滞，表面上看是协同不力，实际上是从第一天起就没人能把"我在做什么"和"整体到哪了"这两件事连起来。

我这些年最深的体会是：跨部门目标管理不是管理目标，而是管理信息结构。目标卡解决口径问题，责任矩阵解决决策问题，看板和分级机制解决速度问题。三件事做完，目标本身没有被改变，但它的可执行性变了。

另一个体会是，机制的效果往往不在第一个月显现。第一个月你会觉得多填了几个字段、多开了半小时会。真正的差别通常在第三个月出现，当别人还在用两周时间处理一个偏差时，你的项目组用两天就闭环了。复利效应在协作机制上同样成立。

如果你现在就想动手，我建议先做最小的一步：找出你手上那个正在停滞的跨部门目标，把它写成一句带量化口径和时间截点的话，发给所有参与方，请他们回复自己理解的数字。光是这一步造成的差异，通常就能暴露出你之前没看到的三个以上问题。

第二步再考虑机制和工具。顺序反过来做，工具只会变成另一个没人更新的看板。