进行中怎么做？跨部门团队协同管理：看板从0到1

跨部门项目进入“进行中”后，最容易出现的不是没人做事，而是每个部门都觉得自己在推进，项目整体却没有往前走：设计等需求确认，研发等接口，运营等上线时间，项目负责人只能靠私聊拼出一份过时的进度表。解决这类问题，重点不是多画几列，而是先约定什么任务可以进入“进行中”、谁负责推动下一步，以及遇到依赖和阻塞时如何处理。

进行中怎么做？跨部门团队协同管理：看板从0到1

一、先讲结论：看板不是状态墙，而是协作规则的可视化

1. “进行中”必须有进入条件和退出条件

我判断一张看板有没有管理价值，通常先看“进行中”这一列：团队成员是否对它代表什么有一致理解。如果有人认为任务被分配就算进行中，有人认为已经实际开工才算进行中，这列里的信息就无法比较，也无法用于判断项目风险。

建议把“进行中”定义为：负责人已经确认任务，必要输入已经具备，实际工作已经开始。任务如果仍在等待需求确认、外部资料、审批或其他团队交付，就不应仅因为有人认领而放进这一列。

退出条件同样重要。任务完成了实际工作，不一定等于交付已被接收。团队可以根据流程设置“待确认”或“待验收”，并明确谁来确认、确认依据是什么。否则，任务从进行中直接变成已完成，常常只是把未解决的问题从看板上藏起来。

2. 看板要回答四个问题

一张跨部门看板至少要让参与者快速回答：现在要交付什么、由谁负责、下一步依赖谁、什么事情正在阻碍推进。若看板只能显示任务名称和状态，却回答不了这些问题，它更像展示板，而不是协作工具。

• 交付物：任务结束时应产生什么可检查的结果。
• 负责人：谁对推动任务到下一状态负责，而不只是参与执行。
• 依赖项：任务开始或完成前，需要哪个团队提供什么输入。
• 阻塞处理：谁负责跟进阻塞，超过约定时间后由谁协助升级。

3. 先跑通一个项目，再决定是否扩大

从零搭建看板时，我不建议先把全公司的项目、部门和流程一次性搬进去。更稳妥的做法是挑一个范围清晰、确实需要跨团队交接、结果能够验收的项目先运行一轮。看板最初的目标不是“字段齐全”，而是尽早暴露团队真实的协作断点。

下面的示意流程把任务从“待开始”到“进行中”、再到“待确认”的关键条件分开。它不是固定模板，实际状态应由团队的交接节点决定。

二、为什么跨部门项目一进入“进行中”就容易失真

1. 每个部门都在工作，不代表整体依赖已经对齐

以一次新功能上线为例，产品团队完成需求说明，设计团队完成视觉稿，研发团队开始开发，运营团队准备上线材料。单看各部门任务，似乎都在推进；但如果研发依赖的接口方案还没确认，运营依赖的功能截图还没交付，项目实际上已经形成等待链条。

问题往往不在于谁“不配合”，而在于依赖关系没有写进共同的工作视图。团队各自管理自己的任务时，容易把“我已完成本部门事项”当成项目进度，而跨团队结果需要的是可接收的交付物、明确的交接时间和下一位接手人。

2. 同一个状态名称，背后可能藏着不同事实

“进行中”可能代表四种完全不同的情形：正在执行、等待输入、等待审批、暂时搁置。如果这些事项都挤在同一列，项目负责人很难知道哪一项能由团队自己推进，哪一项需要外部决策，也看不出工作量究竟落在执行还是等待上。

我更倾向于把“工作状态”和“阻塞信息”分开记录。比如任务仍处于进行中，但额外标注“等待法务确认”，并写明跟进人和更新时间。这样既不会为了表达阻塞而频繁改状态，也不会让等待事项在普通进行中任务里失去可见性。

3. 进度汇报通常描述过去，项目管理需要下一步行动

“已经做了80%”听上去具体，却不一定帮助团队行动。剩下的20%是什么、谁来完成、是否依赖别人、何时能验收，才决定项目是否有风险。百分比如果没有统一计算方法，还可能让不同部门对同一进度给出完全不同的判断。

因此，我会把项目沟通从“汇报完成了多少”改为“当前卡在哪个交接点，下一步由谁在什么时候完成什么”。看板不需要替代所有沟通，但应该让这类关键事实可以被持续查看，而不是只留在会议纪要或个人聊天记录里。

三、常见误区：看板越复杂，未必越可控

1. 把所有任务都放进“进行中”

这是最常见的失真方式之一。团队为了表示任务已经有人接手，把所有已分配事项都标成进行中，结果这列越来越长，却看不出哪些工作真正开工、哪些只是排队、哪些早已被外部依赖卡住。

处理办法不是增加更多颜色，而是重新检查进入条件。没有输入、没有负责人确认或没有实际动作的任务，应留在待开始或明确标记等待。状态应描述事实，而不是表达积极态度。

2. 用大量字段替代清晰的责任边界

字段越多，填写和维护成本越高。团队一开始就要求填写优先级、工时、风险等级、业务线、复杂度、审批人、多个日期，成员很快会把维护看板理解为额外报表工作，甚至为了完成填写而随意填值。

初版任务卡只保留会影响推进或验收的信息即可：负责人、交付物、截止时间、依赖项、阻塞情况和更新时间。某个字段若不能改变排序、决策、交接或验收，就先不要放进必填项。

3. 只记任务，不记依赖和交付标准

“完成页面开发”不是足够清楚的任务描述。它没有说明页面要达到什么验收条件、谁确认结果，以及是否依赖设计稿、接口或内容资料。任务卡缺少这些信息时，跨部门协作就会退回到反复追问。

更可执行的写法是：“完成活动页前端开发；按已确认设计稿适配移动端；接口联调通过后提交测试；测试负责人验收。”这类描述不必写成冗长文档，但要让接手人知道什么结果才算交付。

4. 把每天开会当成看板维护

如果每次站会都要逐条念一遍所有任务，看板只是会议的背景板。会议应该优先讨论阻塞、依赖变化、即将逾期的交付和需要决策的事项。普通状态更新由负责人直接维护，会议把时间留给需要多人协作的问题。

反过来，如果团队更新看板后没人看、没人据此调整优先级，维护也会失去意义。关键不是强迫大家频繁填状态，而是让更新能触发后续动作，例如安排验收、协调资源或处理升级事项。

5. 用单一“完成率”掩盖项目风险

一个项目完成了大多数小任务，不代表关键路径上的工作没有风险。比如上线前的合规确认尚未完成，其他十项任务都已关闭，整体仍可能无法按计划发布。总完成率适合概览，不适合单独作为判断项目健康度的依据。

我会同时关注关键交付是否按时、等待事项是否有负责人、跨部门依赖是否变化，以及阻塞持续了多久。比起把所有任务汇总成一个漂亮百分比，这些信息更能提示项目需要采取什么行动。

四、专业判断逻辑：从项目范围搭到运行机制

1. 先选试点，不要先选工具功能

试点项目应具备三个特征：有明确交付结果；至少两个团队之间存在真实交接；在可控周期内能观察到一轮完整流转。选择一个没有依赖、所有事项都由同一人完成的小任务，无法检验跨部门看板的价值。

项目启动时，先写清楚看板管理范围。例如，只跟踪本次上线的跨团队交付和关键依赖，不把各团队所有日常工作都纳入。边界越明确，成员越容易理解哪些事项需要进入共享视图。

2. 按交付物拆任务，不按部门切成孤岛

如果看板横向按部门划列，常见后果是任务完成后停在部门边界：市场做完需求后，不知道该交给谁；设计交完稿后，不知道研发是否已接收。更好的拆分方式是以可验收的工作结果为单位，再标注执行团队和接手方。

例如，“准备上线资料”可以拆成文案确认、截图交付、帮助页面发布等任务。只有当每项工作有独立负责人、清楚交付物或明确依赖时，才值得单独成为任务卡。拆得过细会增加维护成本，拆得过粗又会隐藏风险，需要以“是否影响协作和验收”为判断标准。

3. 状态设置要贴着交接点，而不是追求完整生命周期

初始看板通常用少量状态就够了，例如“待开始、进行中、待确认、已完成”。如果等待审批是项目中的高频瓶颈，可以单独设置“待审批”；如果只是偶发情形，先用阻塞标记和原因字段表达，避免每种例外都新增一列。

一个好用的状态能让成员知道下一步应该做什么。如果两种状态的处理动作完全相同，可能没必要分开；如果同一状态里同时存在执行、等待和搁置三类工作，就需要调整定义或补充可见标记。

4. 用任务卡明确责任，而不是把责任留给部门

跨部门任务应有一个推动负责人，即使交付需要多人协作，也要能找到一个人负责跟进下一步。部门负责人可以承担资源协调和优先级决策，但不宜让“某部门”成为唯一责任主体，因为部门名称无法回答谁会更新状态、谁会提醒依赖方。

任务卡还应写明验收人或接收团队。发起人不一定是最终验收人，执行人也不应自行把任务关闭。把生产、交接和确认三种责任分清，能减少“我以为已经交了”和“我没收到可用结果”的争议。

5. 让阻塞信息包含下一步，而不只是一句原因

“被卡住了”只能说明现状，不能推动解决。阻塞记录至少包括原因、影响范围、跟进人和下次检查时间。若需要其他团队提供输入，还应写清楚请求内容和期望时间，而不是只在评论里留下“等反馈”。

升级规则也要提前约定。比如，阻塞超过项目约定时限仍没有回应，由项目负责人协调相关负责人；涉及资源冲突或目标变更时，提交给有决策权的人处理。具体时限应按项目节奏制定，不宜把某个固定小时数套用到所有团队。

6. 用固定节奏维护，而不是用高频催促代替流程

成员应在约定时点更新任务，项目负责人则定期查看阻塞和依赖变化。小型项目可以每周安排一次聚焦风险的同步；节奏更快的上线项目可以增加检查频率。频率由工作变化速度决定，而不是由“看起来管理得严格”决定。

每次检查可以围绕四类问题展开：哪些任务即将到期、哪些任务正在等待、哪些依赖发生变化、哪些事项需要决策。没有风险或异常的普通任务，不必在会议中逐条复述。

五、案例拆解：一次营销活动如何把“等一等”变成可管理事项

1. 场景设定：四个团队共同完成一次上线

以下是用于说明方法的情景模拟，不代表真实客户数据或实际企业案例。假设一场线上营销活动需要市场、设计、产品和运营协作，交付结果包括活动方案、页面素材、功能配置和上线检查。

如果只用一张任务表，可能会看到“活动方案进行中、页面设计进行中、功能配置进行中、上线准备进行中”。这些状态没有说清楚谁在等待谁，也没有指出任务之间的先后关系。项目负责人只能在会议上逐个追问，追问结果还可能在会后失效。

2. 把任务卡改写成可以交接的工作单元

我们可以将“活动上线”拆成几张彼此关联的任务卡，而不是给每个部门单独列一个大任务。每张卡都写清产出和接收关系，让前后团队知道什么时候可以开始下一步。

3. 让等待显形，而不是继续用“进行中”覆盖

假设设计已经完成视觉稿，但活动规则仍在修改，页面配置无法准确开展。此时设计任务可以进入待确认，页面配置则保持待开始，并在依赖字段中关联“活动规则确认”。项目负责人由此能看见真正需要推动的是规则确认，而不是催促研发“加快进度”。

再假设功能已经配置完成，但最终文案尚未通过审核。页面配置可以提交验收，文案事项单独进入待确认，并明确审批人和下次检查时间。这样，研发任务完成与营销活动可上线这两件事不会被混为一谈。

4. 示意观察：任务总量相同，等待结构不同，风险也不同

下表采用情景模拟数字，只用于展示分析方法。两种状态分布都包含18项任务，但第二种情形里更多任务处于等待交接或审批状态。单看任务完成百分比，可能看不出差别；结合等待构成，项目负责人就能更早发现需要协调的环节。

5. 复盘时看流动和阻塞，不只看任务关闭数

试点结束后，可以逐项复盘：任务是否按约定进入状态、交付标准是否被理解、依赖是否提前暴露、阻塞是否有人跟进、待确认事项是否形成积压。若任务关闭很多，但团队仍频繁在聊天中追问“现在到哪了”，说明看板没有替代隐性信息流。

在没有稳定数据来源前，不要对外宣称效率提升了某个百分比。可以先建立试点前后的记录口径，例如重复追问次数、阻塞持续时间、超期任务数量和从提交到验收的时长。连续观察几个周期后，再判断看板规则是否带来可验证变化。

六、不同情况下怎么行动：让做法匹配团队成熟度

1. 团队第一次使用共享看板

如果团队此前主要通过群聊、邮件或个人表格协作，先不要上复杂流程。选一个项目，设置少量状态和最必要字段，优先解决“任务谁负责、交付给谁、何时需要”的问题。

• 只纳入会影响跨部门结果的任务，不迁入所有个人待办。
• 每张卡指定一位推动负责人，协作成员可以另行列出。
• 先约定状态定义，再开始填任务，避免数据从第一天就不可比较。
• 试运行后询问成员：哪些信息最常被重复追问，哪些字段没人使用。

2. 团队已经有看板，但“进行中”越来越拥挤

这种情况下，先抽样查看进行中任务，而不是马上加更多状态。检查每张卡是否实际开工、是否仍在等待、是否有明确的下一步。若大量任务没有更新或长期停留，重点应放在状态定义、并行工作量和阻塞跟进上。

可以试着限制同时推进的工作数量，但不要直接套用统一数字。团队应根据人员配置、任务粒度和依赖复杂度观察：并行工作增加后，是否出现切换频繁、任务周期拉长或等待堆积。限制的目的是减少过度开工，不是把数字本身变成考核目标。

3. 项目参与团队多、依赖关系复杂

当多个职能、区域或供应方都参与交付时，普通任务列表可能不足以展示关系。此时应把关键依赖、责任交接、决策节点和风险升级路径明确记录，必要时将整体项目视图与各团队的执行视图分开。

对复杂项目，不要试图把每一项执行细节都塞进同一张共享看板。共享视图关注跨团队承诺和关键路径，团队内部视图管理更细的工作分解。两者通过任务关联或定期同步保持一致，避免共享看板变成无法阅读的长清单。

4. 项目变化频繁、优先级经常调整

需求变化快时，状态之外还要记录变更原因和决策人。否则，任务被反复插入和暂停，团队无法区分正常调整与管理失控。优先级变化应同步评估对既有承诺的影响，不要只把新任务放到队列前面，却不说明哪些事项因此后移。

如果任务经常被暂停，建议保留暂停原因、恢复条件和重新评估时间。对暂时不再重要的工作，应明确移出范围，而不是长期堆在“进行中”或“待开始”里。

5. 团队已有多个工具或历史任务系统

先梳理信息流，而不是立刻决定全部迁移。哪些记录是项目决策依据，哪些只是个人执行细节，哪些状态需要与其他流程同步？只有明确数据所有者、字段映射、历史信息保留方式和切换窗口，迁移才不会把旧系统里的混乱原样带到新看板。

如果涉及任务迁移，应先用小批量数据验证负责人、状态、截止日期、关联关系和附件是否完整，再安排正式切换。迁移完成后需要指定新旧系统的边界，避免团队一边更新旧表、一边更新新看板，产生两个版本的“真实进度”。

七、怎么取舍：状态、字段、会议和数据都要有边界

1. 状态越少越好，还是越细越好

状态太少时，等待和执行混在一起，问题不容易定位；状态太多时，团队不确定该选哪一个，更新负担上升。判断是否新增状态，可以问两个问题：这个状态是否对应不同的下一步动作？团队是否需要单独统计或升级它？如果答案都是否，优先用标签、字段或备注表达。

例如，“待审批”如果会触发独立的责任人、时间要求和升级流程，可以成为单独状态；如果只是偶尔等待某位负责人确认，记录审批人和阻塞原因可能已经足够。

2. 全员共享，还是按角色展示不同视图

所有人都看到同一份完整任务明细，有利于透明，但也可能造成信息过载。我的建议是共享规则和关键交付，执行细节按角色组织视图。项目负责人看依赖、风险和日期；执行者看自己要处理的任务；管理者看范围、关键节点和需要决策的事项。

不同视图不能变成不同事实。底层任务状态、负责人和交付标准必须保持一致，避免项目负责人看到“已完成”，接收团队却仍认为没有收到可用成果。

3. 会议多一点，还是更多异步更新

如果任务边界清楚、依赖少、参与成员分布分散，异步更新可以减少打断；如果项目处于密集交接、风险快速变化或需要即时决策的阶段，短而聚焦的同步可能更有效。会议频率应随风险变化调整，而不是固定追求“每天开”或“完全不开”。

无论采用哪种方式，都应把会议结论转成任务卡上的下一步、责任人和时间。否则，会议里解决的问题不会进入工作视图，几天后团队还要重新确认。

4. 追求完整数据，还是优先追求可信数据

开始阶段，可信比完整重要。成员愿意持续更新的少量数据，比一套看似全面却长期过期的字段更有价值。先保证负责人、状态、交付标准、依赖和更新时间准确，再逐步增加周期、工时或风险分类等指标。

要做效率分析，还必须确保口径稳定。例如，“任务周期”是从创建到完成，还是从进入进行中到验收？如果团队之间口径不同，汇总结果看似精确，实际无法比较。没有统一定义时，宁可暂不公布跨项目排名，也不要把口径差异包装成管理结论。

5. 透明度与心理安全之间的取舍

看板公开逾期和阻塞，目的是尽早协调，不是把任务状态变成个人惩罚榜。若团队认为更新“卡住”会被追责，成员就更可能延迟标记阻塞，直到问题已经影响交付。管理者需要区分可控失误、外部依赖和范围变化，并把透明信息用于解决问题。

可以公开任务与交付风险，但对个人绩效的判断不能只依赖单一状态或任务数量。任务复杂度、依赖条件和临时变更都可能不同，脱离背景比较数字，容易诱发拆小任务、隐藏等待等不良行为。

八、落地检查与下一步：先验证看板是否减少了协作盲区

1. 用一张清单检查首版看板

• 项目目标、交付范围和参与团队是否明确？
• 每张关键任务卡是否有负责人、交付物和接收方？
• “进行中”的进入条件与退出条件是否一致？
• 等待输入、审批和阻塞是否能被区分或清楚标注？
• 每个阻塞是否有跟进人、下一步动作和更新时间？
• 团队是否知道谁维护任务、谁协调依赖、谁负责决策？
• 会议是否聚焦异常与决策，而不是逐行朗读任务状态？

2. 先观察过程指标，再讨论结果指标

试点初期，建议先记录过程指标：任务状态长期未更新的数量、跨部门等待事项、逾期任务、阻塞持续时间、提交到验收的间隔，以及成员重复询问进度的频次。它们能帮助判断看板规则是否被执行、问题是否更早暴露。

如果团队之后希望评估项目效率变化，应同时记录观察周期、项目类型、任务范围和计算方法。不同项目的复杂度和外部条件差别很大，不能把某个试点的变化直接外推成普遍效果，也不应在没有基线时宣称“效率提升了多少”。

3. 四周试运行可以这样安排

1. 第1周：定边界。选定一个试点项目，确认目标、参与团队、关键交付物和现有协作痛点。先画出任务依赖，不急着配置大量字段。
2. 第2周：跑一轮状态流转。由负责人维护任务卡，记录进入进行中、提交验收和完成的条件，收集成员最常遇到的状态歧义。
3. 第3周：集中处理阻塞。检查等待输入、审批和长期未更新的事项，验证跟进人、升级路径和更新节奏是否可执行。
4. 第4周：复盘删改。保留能推动决策或交接的字段，删除长期没人使用的字段，决定是否调整状态、会议频率或试点范围。

四周只是便于组织复盘的示意节奏，不是所有项目都需要按此周期运行。周期短的项目可以更快检查，持续时间长的项目也可以按里程碑复盘。关键是每轮复盘都要产生具体改动，而不是只给看板打分。

4. 最后的判断：看板有没有让下一步更清楚

跨部门看板从零到一，真正要验证的不是页面是否完整，也不是每个人是否每天更新了状态，而是团队能否更早看见等待、明确责任、快速接住交付，并在关键节点做出决策。

我会用一个简单的问题结束试点复盘：如果负责人今天不参加会议，团队能否仅凭看板知道每个关键任务下一步由谁推进、需要什么输入、何时应升级？如果答案是否定的，就先不要扩大范围，回到任务卡和协作规则本身继续改。

下一步可以选一个正在推进的跨部门项目，先定义“进行中”的进入条件，再挑出三张最容易卡住的任务卡，补齐负责人、交付标准、依赖和阻塞跟进人。让一小段真实工作流动起来，比一次性搭出庞大看板更能检验方法是否适合团队。