看板进行中教程：项目成员入门指南，避坑指南

看板上最容易制造误判的，不是“待办”或“已完成”，而是“进行中”：任务卡片已经被拖进这一列，团队却不知道它是否真的开工、卡在哪里、下一步由谁推动。成员入门时先记住一个结论：状态不是进度装饰，而是团队对任务当前事实的共同描述。只有开始实际工作、具备基本开工条件，并且有人负责推进时，任务才适合进入“进行中”；如果只是排上日程、等待资料或等待评审，就应该如实保留在相应状态。

一、先讲核心结论：进入“进行中”前，先确认事实

1. 状态要回答三个问题

我判断一张卡片是否适合进入“进行中”，会先看三个问题：工作是否已经实际开始？当前负责人是否明确？团队能否从卡片或协作记录中看出下一步是什么？如果三项里有两项答不上来，这张卡片通常还没有准备好进入进行中。

这不是要求成员每次移动卡片都填写一份长报告，而是避免状态与实际工作脱节。看板的价值在于减少追问：同事不必逐个私聊“现在到哪了”，就能大致理解任务处境。只改列、不留下一步，卡片虽然移动了，信息却没有真正增加。

2. “进行中”不是一个万能状态

有些团队把所有开工后的事情都放进“进行中”，另一些团队会拆成“设计中”“开发中”“待评审”“测试中”等阶段。两种做法都可能合理，关键在于状态能否帮助团队识别下一项行动。状态列越多，描述越细，但维护成本也越高；列太少，成员容易把等待、执行和验收混在一起。

我通常建议从团队真正需要区分的交接点出发，而不是先追求看板看起来完整。若“等评审”和“正在修改”需要不同的人采取不同动作，就值得考虑分开表示；若拆列后没人据此改变行动，增加状态只会让流程更难维护。

3. 一张合格的进行中卡片，至少有可辨认的下一步

“处理中”“持续跟进”“尽快完成”听起来像进度描述，实际上很难指导协作。更有用的表达是“补齐接口字段后提交联调”“周三前提供两份文案供评审”或“等待业务确认后开始验收”。这些句子告诉别人任务现在处于什么位置，以及接下来发生什么。

如果工作本身暂时无法拆出下一步，成员也应说明原因和所需支持。例如“等待业务方确认字段范围，负责人已于周二发出问题清单，周四前需获得答复”。这比把卡片留在进行中、等别人自行发现异常更可靠。

二、看板的真实使用场景：列名相同，含义可能不同

1. “已经开始”不等于“已经排上计划”

一个常见场景是：成员周一收到任务，先把卡片拖到进行中；但真正需要的资料周三才会到，周二本人还在处理另一项工作。此时卡片显示进行中，实际却处于等待。负责人看板时会误以为工作已被消化，团队也可能因此延迟发现依赖。

更稳妥的做法是将任务留在“待开始”或团队约定的候选状态，直到成员确实开始投入工作。若工具没有“等待输入”这一列，可以在卡片上标记依赖，并写明责任人和预计更新时间。具体用哪种方式并不重要，重要的是不要用“进行中”掩盖尚未启动的事实。

2. “正在做”也可能包含不同的工作阶段

对一个小团队来说，一张“进行中”卡片可能足以表达信息；对多人协作的交付流程来说，同一列可能同时装着方案设计、开发、等待评审和返工。项目负责人看到任务堆积时，很难判断问题出在工作量、审批等待还是资源冲突。

此时不要急着增加十几个状态。先观察团队是否需要据此做不同决策：如果评审等待期间需要评审人采取行动，等待就值得显式呈现；如果一项任务的不同阶段由同一个人连续完成，而且团队不需要分别跟踪，合并状态可能更省心。

3. “任务卡住”不等于“负责人没有做事”

卡片停留较久，可能是范围变更、外部依赖、审批等待，也可能是任务本身复杂。仅凭停留时间不能判断成员是否懈怠。更有用的检查顺序是：卡片有没有下一步？下一步是否受阻？阻碍是否明确？需要谁采取行动？如果这些信息都缺失，先补信息，再讨论时限和资源。

我会特别留意“没人认领的等待”。例如卡片写着“等确认”，却没有说明由谁确认、何时跟进。它不是一个有效的状态描述，而是把责任藏在模糊措辞里。把下一位行动者写清楚，团队才有办法判断事情是否需要升级。

三、成员常见的五个误区：看起来更新了，信息反而更乱

1. 接到任务就拖进进行中

接单只代表有人负责，不一定代表工作已启动。任务可能还缺需求确认、素材、权限或前置交付。过早标记进行中，会让其他人误以为这些准备工作已经完成，也会让项目负责人低估待启动工作量。

改法：把“已分配”和“已开工”区分开。成员接到任务后先确认目标、输入和优先级；准备条件齐全且实际开始处理后，再调整状态。若团队没有专门的待开始列，就在卡片中明确标出尚缺的条件。

2. 只拖卡片，不更新进展

卡片从待办移动到进行中，能表达阶段变化，却未必能说明任务做到了什么程度。对于需要多人接手的工作，至少要留下当前进展、下一步和关键依赖。没有必要每天写流水账，但状态变化或风险变化时，应更新最相关的信息。

改法：更新时优先回答“完成了什么、接下来做什么、是否需要帮助”。例如“已完成数据字段核对；下一步验证两种异常输入；测试环境权限尚未开通，已请平台管理员处理”。这条记录比“进展正常”更便于协作。

3. 卡住了却继续维持进行中

阻塞并不一定要求马上把卡片移动到另一列，但它必须被看见。如果团队把“进行中”定义为正在执行，长期等待依赖仍留在其中，就会让进行中工作量失真。成员至少要标明阻塞原因、影响范围、需要谁协助以及下一次检查时间。

改法：是否移动到“阻塞”或“等待”列，由团队流程决定；无论是否换列，都要让阻塞状态可识别。不要用“稍后处理”代替负责人，也不要把求助信息只留在容易被忽略的私人消息里。

4. 把完成定义成“我这边做完了”

某个成员完成自己的部分，不等于整个任务已经交付。若任务还需要评审、测试、验收或业务确认，直接移到完成会造成交付口径不一致。另一种情况是团队没有写清楚完成条件，成员只能凭个人理解判断。

改法：开始工作前确认验收标准。完成时检查约定产物是否存在、必要检查是否通过、交接对象是否收到。若工作已经提交但等待他人确认，应采用团队定义的待评审或待验收状态，而不是提前标记完成。

5. 用卡片数量推断个人效率

某位成员名下进行中任务多，不一定说明效率高；任务少，也不一定说明投入不足。不同任务的工作量、风险、依赖和拆分粒度差异很大。把卡片数量直接当作绩效结论，容易鼓励成员拆小任务、抢接任务或隐藏复杂度。

改法：把卡片数量当作排查线索，而不是单独的评价指标。进一步看任务是否持续推进、等待是否有明确责任、交付是否满足约定，以及团队是否因并行过多而频繁切换。任何指标都应结合任务背景解释。

四、专业判断逻辑：用“进入，推进，异常，退出”四道检查

1. 进入检查：任务是否真的具备开工条件

进入进行中之前，成员应确认任务目标基本清楚、负责人明确、必要输入已到位，并且自己已经开始实际工作。这里的“目标清楚”不要求所有细节永远不变，而是至少能说明本轮要交付什么、如何判断结果可接受。

如果任务还缺关键决策，先标出等待项和决策人；如果只是细节待完善，但可以先开展明确部分，则要说明边界，避免成员擅自扩大范围。状态更新不应替代需求澄清，也不应掩盖尚未做出的决定。

2. 推进检查：卡片能否解释当前进展

任务进行中，成员不需要为了看板更新而重复汇报。比较实用的触发点包括：完成一个重要阶段、发现新的依赖、范围发生变化、原计划明显需要调整，以及其他人需要接手信息时。普通的小幅进展，如果没有改变判断，未必需要单独写一条记录。

更新内容可以采用简洁结构：已完成事项、下一步行动、风险或依赖、需要谁协助。团队可以把这四项作为建议格式，但不必每次都填满。没有风险时，不需要为了形式写“无风险”；真正有用的是让异常足够可见。

3. 异常检查：判断是正常等待还是实际阻塞

我会区分“可预期的等待”和“已经妨碍推进的阻塞”。例如任务按计划等待明天的评审，且评审人和时间都明确，可能只是正常交接；如果评审人不明、时间不确定，或缺少评审导致后续工作全部停下，就需要显式处理。

判断时可以依次问：等待对象是谁？对方何时能回应？当前是否有可并行的工作？不处理会影响哪个交付？如果问题已经影响承诺时间，是否需要调整优先级或升级协调？这些问题比单纯统计卡片停留天数更接近实际风险。

4. 退出检查：完成的是任务，还是只完成了个人动作

离开进行中前，成员应根据团队约定核对产物和验收条件。代码提交、文档完成、设计稿上传可能只是任务的一部分；若流程要求评审或验证，应继续流转到相应阶段。反过来，如果团队已经确认完成，不必为了等待形式上的汇报而让卡片长期留在进行中。

建议将“完成条件”尽量写在任务创建或启动时，而不是等到交付当天才临时讨论。标准可以很短，例如“提供可复现的测试结果并通过指定检查”，但要让执行者和验收者理解一致。

五、案例推演：同样是卡了三天，处理方式可能完全不同

1. 先还原一个常见的团队场景

以下是一个匿名化、情景模拟的项目片段，不代表某家公司的真实统计：一个跨职能团队用看板跟踪一批交付任务，项目负责人发现进行中列里有多张卡片数日未变化。最初的判断是“大家推进慢”，但逐张核对后发现，卡片背后其实有四种不同情况：有人在执行，有人等待输入，有人等评审，还有人不知道下一步由谁推动。

如果负责人只催所有人“尽快更新”，可能会让成员补写大量状态文字，却没有解决真正的依赖。更有效的做法是把卡片按当前行动分组：仍在执行的任务看下一步和工作量；等待输入的任务找决策责任人；待评审的任务确认评审安排；无人推动的任务重新指定负责人。

2. 一个最小化改进，不需要先换工具

在这个模拟场景里，团队先做三件事：写下进入进行中的条件；为阻塞卡片增加原因、责任人和下次检查时间；每周短会只讨论需要协作决策的卡片。团队没有先增加复杂审批，也没有强制所有成员每天写长篇日报。

需要观察的不是“看板是否变漂亮”，而是问题能否更早暴露、等待任务是否有人跟进、评审是否有明确接手人，以及重复询问是否减少。若想评估效果，可在实施前后记录同一口径的数据，但不能仅凭某周变化就断言改进完全由看板规则造成。

如果团队希望做量化复盘，可以先设定统一统计口径。例如“阻塞识别时长”定义为从首次出现依赖到卡片明确标记阻塞的时间；“待评审等待时长”定义为提交评审到获得结论的时间。连续观察数个迭代，再结合任务类型和人员变化解释结果，比拿一个前后数字直接宣称效率提升更可信。

六、不同情况下怎么行动：按任务处境选择更新方式

1. 任务刚接手，信息基本齐全

先确认交付目标、负责人、优先级和完成条件，再开始实际工作。符合团队约定的开工条件后，将状态改为进行中，并写下第一项可执行动作。这样做能让同事知道任务已经启动，也能减少“分配了但还没开工”的误会。

2. 任务已开始，但遇到外部依赖

不要只写“等待中”。说明缺少的输入、提供方、对当前任务的影响，以及下一次跟进时间。若仍有可并行的工作，可以写明正在推进的部分；如果已经完全无法继续，则按团队规则改为等待或阻塞状态。

3. 工作持续进行，短期没有明显交付节点

复杂任务不一定每天都有可见产物。成员可以按有意义的阶段更新，例如完成调研范围确认、验证关键假设或完成第一轮方案评审。若任务周期长到无法判断是否推进，应考虑拆成可检查的阶段任务，但不要为了看板活跃而拆出没有独立价值的碎片。

4. 任务已提交，正在等待评审或验收

确认交付内容已经提交到约定位置，并让接手的评审人或验收人可识别。若团队将评审视为独立阶段，应移动到相应状态；若不单独建列，则在卡片中清楚标明等待对象与时间。执行者不应因他人尚未处理而被误判为没有交付。

5. 任务范围变化或原计划不再成立

不要继续沿用旧状态和旧完成条件。成员应说明变化来自哪里、影响什么、需要谁确认，并与负责人讨论是否拆分、调整优先级或重新估算。范围变化若只存在于聊天记录里，看板很快会变成过时版本。

6. 进行中任务过多，成员频繁切换

先看每张卡片是否都真的需要并行推进，再找出等待、依赖和优先级冲突。不要一上来就把卡片批量移回待办，也不要用简单的数量上限惩罚复杂工作。团队可以试行一个小范围的并行任务限制，观察交付等待和切换成本是否改善，再决定是否扩大。

七、怎么取舍：状态细到什么程度才合适

1. 小团队和短周期任务：少状态，重下一步

小团队沟通路径短、任务变化快，通常不需要为了流程完整而设置很多列。待办、进行中、待确认、完成可能已经够用，阻塞则通过标签或明确字段体现。此时最值得投入的是让任务目标清楚、负责人明确、下一步可见。

如果每次状态变化都需要成员花时间判断该拖到哪一列，说明状态设计可能过细。先合并那些不会触发不同动作的状态，再看团队是否仍能识别真正的交接和风险。

2. 跨职能或多人交接：状态应体现责任转换

当任务会在设计、执行、评审、测试等角色之间交接时，状态能帮助团队明确“现在轮到谁行动”。这类团队值得把关键等待节点显式化，但不必把每个内部操作都做成一列。优先表达那些一旦延误就会影响后续工作的交接点。

状态列如果只反映部门名称，却不能说明任务是否已交付给该部门，仍然容易造成责任空档。每个交接状态都应回答：交接物是什么？谁接手？接手后采取什么动作？

3. 远程协作：适度增加异步信息，别把看板变日报

时区不同或会议少的团队，卡片上的上下文更重要。任务开始、发生阻塞、交付评审等关键节点应留下可追溯信息。但这不意味着每天必须写固定字数的进展报告；如果更新内容无法帮助他人判断或行动，增加文字只会让重要信息更难找到。

可以把更新触发点与事件绑定，而不是与日历绑定：状态变化时更新，风险出现时更新，交接发生时更新。团队仍然可以安排定期检查，但检查的目的应是处理不确定性，而不是让成员重复证明自己在工作。

4. 需要审计或复杂治理：流程规则与权限要分开设计

对交付记录、审批责任或权限控制要求较高的团队，状态之外还可能需要保留操作记录、决策依据和验收信息。此时应由流程负责人明确哪些字段是必要记录，哪些只是便于协作的说明。不要把治理要求全部塞进看板列名，也不要把每个协作提醒都变成审批门槛。

工具能否满足部署、权限、迁移和记录留存等要求，应依据组织自己的安全、技术和采购标准验证。这类选型问题与“成员怎样使用进行中”相关，但不能由状态设计本身替代评估。

八、给项目成员的日常自查清单

1. 开始工作前

• 我是否理解这项任务要交付什么？
• 当前负责人和优先级是否明确？
• 开始工作所需的资料、权限或决策是否已经到位？
• 团队对这项任务的完成条件是否有基本共识？

2. 工作进行中

• 卡片状态是否反映真实工作阶段，而不是计划或愿望？
• 其他成员能否看出我接下来要做什么？
• 如果有依赖或风险，是否写明需要谁采取行动？
• 近期若有重要变化，我是否同步更新了卡片或相关记录？

3. 准备移出进行中时

• 约定的产物是否已经提交到团队认可的位置？
• 评审、测试或验收等必要步骤是否完成？
• 如果任务要交给其他人，接手对象和交接内容是否明确？
• 如果只是个人部分完成，是否避免提前把整体任务标记为完成？

这份清单不适合被做成逐项打卡的负担。成员可以把它当作发现异常时的快速检查工具：状态对不上事实，就先纠正状态；下一步不清楚，就补行动；任务被卡住，就说清需要谁帮忙。

九、结尾：看板的重点不是移动卡片，而是减少信息盲区

1. 先统一最小规则，再逐步调整

团队可以先约定三条最小规则：什么情况进入进行中；哪些变化需要更新卡片；什么条件满足后才能移出进行中。规则不需要写成厚厚的流程手册，但要让成员在遇到具体任务时能作出一致判断。

之后连续观察几个工作周期，记录状态误读、阻塞发现、交接等待和重复追问等现象。若一个新状态没有让团队采取不同动作，就考虑合并；若某类等待经常造成责任不清，再考虑显式呈现。让实际问题决定看板结构，而不是先追求列数或图表数量。

2. 下一步可以这样做

1. 挑选一张当前进行中的任务卡，检查状态、负责人、下一步、阻塞和完成条件。
2. 找出团队最近最常见的一种误判，例如等待被当成执行，或提交评审被当成完成。
3. 只针对这一类误判补一条状态约定或卡片更新要求。
4. 观察后续任务是否因此更容易交接，再决定要不要调整看板结构。

我对“进行中”的最终判断很简单：让卡片如实呈现工作，能让下一位协作者知道自己该做什么。如果一张卡片移动之后，没有增加事实、没有明确行动，也没有让风险更可见，那么这次更新只改变了位置，没有改善协作。项目成员真正需要练习的，不是拖动卡片，而是把工作状态说准确。