看板如何做好进行中？企业管理者效率提升与操作步骤

看板如何做好进行中？企业管理者效率提升与操作步骤

很多团队的看板上，“进行中”一列塞满了任务：有的刚开始，有的在等审批，有的已经几天没人更新，还有的其实已经做完，只是没有人移动卡片。管理者看到的是一排忙碌的状态，却仍然答不上来三个关键问题：谁在推进、下一步是什么、哪里需要协助。看板要做好“进行中”，关键不是增加颜色和字段，而是把这一列定义成一个有准入条件、有推进动作、能识别异常的工作区间。

一、先给结论：“进行中”不是状态标签，而是管理规则

1. 一张有效的看板，要能回答四个问题

我判断“进行中”是否管得住，通常不先看工具界面，而是看每张卡片能否回答四件事：谁对推进负责，当前做到哪一步，接下来准备做什么，有什么因素会影响完成。若只能看到任务名称和一个状态标签，管理者得到的只是静态清单，不是可以采取行动的信息。

“进行中”应该表示：团队已经为任务投入实际工作，任务有明确责任人和下一步动作，且当前进展或异常能够被其他相关人员理解。如果任务只是排上了日程、等待外部资料，或者负责人尚未开始处理，就不应仅因为“有人认领”而被放进这一列。

2. 管理目标不是让卡片移动得更快，而是让工作流更顺

把卡片从“待办”拖到“进行中”很容易，真正困难的是减少无效等待、频繁切换和反复返工。任务移动得快，并不等于任务交付得好；如果团队为了追求状态更新而频繁改标签，流程看起来很活跃，实际交付却未必改善。

因此，管理“进行中”至少要同时照顾三类结果：团队正在做多少工作、任务在流程中等待多久、交付是否满足约定标准。只盯卡片数量，可能让团队为了降低在制任务而拆得过细；只盯完成速度，又可能诱发跳过验收或牺牲质量。

二、为什么“进行中”最容易变成任务堆积区

1. 任务状态可见，不等于真实进展可见

项目任务通常跨越多个角色和环节。一个任务可能已由负责人接手，但还没有开始实质工作；也可能已经完成主要工作，却在等业务方确认；还有些任务正在推进，但依赖其他团队提供数据。若这些情况都只显示为“进行中”，看板就把性质不同的工作压成同一个信号。

管理者容易因此产生两种误判：第一，看到很多进行中任务，就认为团队资源已经充分利用；第二，看到任务长期没有变化，就认为执行者不积极。实际上，卡住的原因可能是需求未确认、审批未完成、外部依赖未交付，或团队同时承担太多优先事项。看板规则若不能区分这些情况，管理者就只能凭印象催进度。

2. “等别人”也可能被误记为“正在做”

某项工作需要其他部门补充数据时，责任人可能已经完成自己能做的部分，但后续工作暂时无法继续。若卡片仍留在“进行中”，表面上看任务有人负责，真实情况却是工作流停在依赖点。等到交付日期临近，团队才发现等待时间没有被纳入计划。

这类任务不一定要单独设置一整列。团队可以使用“阻塞”标记、等待标签或明确的依赖字段，但必须规定标记后谁负责推动、什么时候复查、什么条件解除等待。把问题标出来只是发现，不是解决；真正的管理动作是让阻塞有责任人、有处理路径、有复查时间。

3. 任务越多同时开工，不一定产出越多

在工作知识型团队里，成员经常同时处理多个事项：写方案时回消息、改需求时参加评审、准备交付时又插入紧急任务。每个任务都显示为“进行中”，但可连续投入的时间被切碎，任务间切换与重新进入上下文会占用精力。

这不意味着所有团队都应该采用相同的在制任务上限。工作类型、人员数量、依赖关系和交付周期不同，合理上限也会不同。更实用的做法是先观察当前在制量、任务停留时间和阻塞比例，再小幅调整规则，而不是照抄某个固定数字。

三、先拆掉五个误区，再决定怎么改看板

1. 误区一：任务有人认领，就可以算进行中

认领只说明有人对任务负责，不说明工作已经开始。若团队把“已分派”直接等同于“进行中”，管理者会把待启动事项误判成正在消耗产能的事项。更清晰的状态设计，是把“待办”定义为尚未开始，把“进行中”留给已经投入实际工作的任务。

如果团队暂时不想增加状态列，至少要为“进行中”增加一个开始条件，例如负责人已确认目标、开始时间已记录、第一步行动已明确。这样可以减少任务刚分配就占据在制空间的情况。

2. 误区二：卡片更新得勤，说明团队效率高

频繁更新状态可能只是产生更多管理动作，并不必然改善交付。若成员每天花时间修改字段，却没有解决需求不清、资源冲突或审批等待，团队的可见度提高了，实际工作仍然受阻。

检查节奏应以异常和决策为中心，而不是要求所有人逐条汇报。管理者可以优先看超出预期的任务、带阻塞标记的任务、责任人不清的任务，以及最近一次更新不能说明下一步的任务。其余正常推进的事项无需在会上重复念卡片。

3. 误区三：字段越多，看板越专业

字段需要被维护，也需要有人根据字段采取行动。若团队填写了十几个信息，但没有任何管理决策会使用其中大部分字段，这些内容只会增加更新负担，最后变成形式化记录。

我通常建议先从最小信息集开始：任务目标、主要责任人、优先级、下一步动作、预期完成时间、依赖或阻塞情况。运行一段时间后，只有当团队确实需要某项信息来判断风险或分配资源时，再增加对应字段。

4. 误区四：所有团队都该用同一套状态列

软件研发、市场活动、客户交付、采购审批和生产现场的工作流差异很大。需要评审与验收的任务，可能需要“待验收”；存在外部审批的流程，可能需要明确“待审批”；节奏稳定的重复工作，则可能用更简洁的列就够了。

状态列应反映工作真实经过的阶段，而不是为了显得完整而复制一套通用模板。跨部门看板可以有共同的汇总状态，但执行团队仍可能需要自己的细分规则。关键是让汇总能对应到真实进度，避免把不同含义的状态强行合并。

5. 误区五：逾期任务只要提醒负责人就能解决

提醒只能把问题推回给责任人，不能自动消除优先级冲突、审批延迟和资源不足。管理者发现任务超期时，应先判断它属于估算偏差、依赖等待、范围变化、工作量过载还是执行过程中的质量返工，再决定是调整计划、协调资源、缩小范围还是升级风险。

如果每次超期都归因于“个人没有跟进”，团队就会倾向于隐藏阻塞、乐观估时或提前关闭任务。较健康的看板文化，是让风险尽早暴露，并把暴露问题视为管理输入，而不是自动视作绩效扣分依据。

四、建立“进行中”管理规则的专业判断逻辑

1. 先定义状态，再选择字段和工具

看板设计的起点不是选颜色、拖列或挑软件，而是回答每个状态代表什么。对“进行中”，团队需要先写出可观察的定义，例如：“负责人已开始实质工作，当前有明确下一步，卡片可以说明任务所处环节。”定义越可验证，团队越容易对齐。

状态定义不应写成抽象口号，例如“积极推进中”或“处理中”。这类说法无法判断任务是否符合条件。更有效的定义会说明实际行为或记录：已开始访谈、已提交初稿、正在联调、等待指定部门反馈等。

2. 为进入和退出设置不同的门槛

进入“进行中”时，重点确认任务是否具备开工条件；退出“进行中”时，重点确认交付是否达到约定标准。两者不能只靠负责人拖动卡片决定，否则状态会随个人习惯变化，无法进行团队协作。

3. 给责任人和协作者分清角色

一项工作可以有多个协作者，但最好有一名主要责任人负责推动下一步、更新关键信息和暴露风险。责任人不等于所有工作都由其单独完成，也不意味着其他协作者可以不承担具体任务。

跨部门任务尤其需要写清“谁交付什么”。例如，业务方提供需求确认，数据团队提供数据口径，项目负责人负责协调时间和整合交付。只写一个项目负责人姓名，容易让依赖方误以为后续工作全由对方兜底。

4. 用在制上限管理工作量，不要把它变成绩效配额

在制上限的作用，是提醒团队不要在当前能力范围之外持续启动新任务。它不是惩罚成员的数字，也不是要求每个人每天必须完成固定数量任务的配额。团队可以先记录一段时间的实际在制量，再结合任务复杂度和人员分工试设上限。

试运行时，如果待启动任务不断积压，但进行中任务长期不结束，问题可能不是上限太低，而是任务粒度太大、验收等待过长或优先级切换过多。上限应促使团队讨论“怎样完成当前工作”，而不是简单阻止所有新需求进入。

5. 用周期和吞吐观察流动，不把单一数字当排名

看板的运营数据可以帮助发现流程问题。常见观察项包括在制任务量、任务从开始到完成的周期、一定时间内完成的任务数，以及任务停留时间的分布。它们能提示团队“工作在哪个环节变慢”，但不能单独解释原因。

例如，周期变长可能来自需求等待、任务变大、人员被频繁打断或验收规则变化；完成数量变少也可能是团队正在交付更复杂的工作。团队应把指标用于流程诊断和计划讨论，而不是脱离任务难度直接比较个人。

《Kanban Guide》将工作项在制数量、吞吐、工作项周期等列为团队可以使用的流动指标。指标定义和统计起止点必须由团队保持一致，否则同一张图在不同团队或不同月份之间并不可比。参考资料：The Kanban Guide，https://kanbanguides.org/english/。

五、七步把看板“进行中”从展示列变成工作区

1. 第一步：选定一类工作，先画出真实流程

不要一开始就把全公司所有事项塞进一个看板。先挑一个边界明确的工作类型，例如客户需求交付、内容制作或内部审批，和实际参与者一起列出任务从提出到验收经过的步骤。

流程图不必复杂，重点是找出工作真正经过的阶段，以及容易发生等待的节点。若流程里有“等资料”“待审批”“待验收”等明显停留原因，就需要讨论它们是独立状态、标签还是卡片上的阻塞信息。

2. 第二步：写出每个状态的进入与退出条件

每列都应有简短定义，特别是“进行中”。团队可以把定义放在看板说明或规则页面，并在试运行时检查成员是否理解一致。规则不需要一次写得很长，但必须让新人能够判断一张卡片该放在哪里。

实用的判断方法是拿三张真实卡片做演练：一张刚分派但尚未开工，一张正在做但依赖外部输入，一张工作已完成但未验收。若团队成员对卡片应处的状态意见不一，说明定义还不够清楚。

3. 第三步：确定卡片最小信息集

卡片信息的目标是帮助团队协作和决策，不是收集所有可能的信息。启动时可使用以下字段，随后根据实际问题做删减或补充。

• 任务目标：让协作者知道要交付什么，而不只是看到一个模糊名词。
• 主要责任人：明确谁推动下一步，协作者可根据需要另列。
• 优先级或交付期限：支持排序和资源协调，不要用“紧急”代替明确期限。
• 当前进展与下一步动作：说明正在做什么，以及接下来可执行的动作。
• 依赖与阻塞：记录等待对象、需要的输入和计划复查时间。
• 完成标准：避免不同参与者对“做完”的理解不一致。

4. 第四步：设置在制上限，并用实际流量校准

团队可以先从现有工作量建立基线，再根据任务停滞和人员切换情况试设上限。不要把“每人最多两项”作为没有验证的通用规则：有的团队任务按人分配，有的则由多人协作；有的任务数看似多但每项很小，有的任务一项就需要多周投入。

试行上限时，先明确超限后怎么办。例如，团队暂缓启动低优先级事项、帮助完成接近交付的工作，或由管理者协调资源。若上限只是一个红色数字，却没有对应动作，它很快就会变成装饰。

5. 第五步：建立阻塞处理和升级路径

每种常见阻塞至少应有一种处理方式。等待业务确认的任务可以设置确认责任人和回复期限；依赖外部团队的事项需要写明对接人和下次跟进时间；资源冲突则交由有权限的人决定优先级。

升级机制不等于一遇到问题就向上汇报。可以设定一个团队可执行的复查约定，例如阻塞超过约定时间，责任人先联系依赖方并同步风险；仍无法解除时，再请项目负责人协调。具体时限要看工作节奏，不宜生搬硬套。

6. 第六步：用短会检查异常，而非逐条读卡片

例行检查的顺序可以是：先看超期和长时间未更新的任务，再看阻塞项与即将到期的交付，最后讨论新任务是否具备进入条件。正常推进、信息完整的卡片不必逐项复述。

会议中的提问应推动决策：“缺少什么输入？”“谁能帮助解除依赖？”“当前优先级是否仍然成立？”比“进展怎么样”更容易得到可以采取行动的答案。若会议结束后没有负责人、动作或复查时间，讨论往往只是重复看板内容。

7. 第七步：定期复盘并删掉无用规则

试运行一段时间后，团队可以复盘卡片是否频繁卡在同一阶段、阻塞原因是否反复出现、字段是否有人维护、状态变更是否符合实际工作。复盘不是为了证明看板设计正确，而是为了找出规则与真实工作之间的差距。

如果某个字段长期空白，可以先确认它是否确有管理价值；如果某个状态从未被使用，可能意味着工作流定义多余；如果大量任务都标成阻塞，可能需要检查阻塞定义是否过宽，或团队是否缺少处理依赖的机制。

六、一个具体任务示例：从卡住到重新流动

1. 情景说明：任务不是没人做，而是依赖没有显性化

下面用一个虚构的跨部门任务演示规则如何落地：运营团队要整理季度客户反馈并提交改进建议。工作涉及反馈归类、数据核对、业务确认和建议评审。最初，任务卡片只有标题和负责人，团队将其放在“进行中”，数日后仍没有明显变化。

若只看状态，管理者很容易得出“负责人没有推进”的结论。进一步询问后才发现，反馈数据已经整理，但不同部门对分类口径存在分歧，负责人正在等待业务确认；与此同时，卡片没有标注等待对象、确认时限或替代方案。

2. 按规则重写卡片，让下一步变得可执行

团队将卡片内容补全：目标是形成一份经业务确认的季度反馈分类与改进建议；主要责任人为运营项目负责人；下一步是请业务代表确认分类口径；依赖项是业务确认；若在约定日期前未收到回复，由负责人邀请相关人员进行短时决策；完成标准是分类口径确认、建议内容完成评审。

这时，任务依然可能处在进行中，但管理者已经能看见它卡在什么位置、谁需要行动、何时复查。看板的价值不是让任务立刻完成，而是把原本藏在聊天记录和个人记忆中的依赖转成公开、可处理的信息。

3. 管理者动作：协调条件，而不是只催状态

管理者可以先确认分类口径是否真的需要业务方拍板，再判断是否能由授权人员直接决策。如果必须等待业务确认，就明确对接人和反馈时间；若该任务优先级低于紧急交付，则调整计划，而不是要求负责人同时对所有事项承诺按期完成。

待依赖解除后，责任人更新下一步动作和预计完成时间；评审结束并达到完成标准后，卡片进入验收或完成状态。这样一张卡片就不仅记录了“做完没”，也留下了工作流在哪个环节受阻、管理者采取了什么协调动作。

七、不同团队、不同问题，行动重点也不同

1. 小团队刚开始用看板：先追求规则简单且人人理解

人员较少、任务类型相对集中时，不必马上搭建复杂字段和多层泳道。先用待办、进行中、待验收、完成等基本状态，再约定进入条件、责任人和阻塞标记。小团队的优势是沟通距离短，规则可以先口头试行，再把稳定部分写下来。

此时最重要的不是购买复杂工具，而是避免所有任务都不加筛选地进入进行中。团队每周回看一次长期未更新和反复延期的任务，通常就能发现需求不清、任务过大或优先级频繁变化等早期问题。

2. 多团队协作且任务依赖复杂：优先让依赖和责任可追踪

当工作涉及多个部门、多人协作或长期交付时，简单的单列状态容易丢失信息。此时应明确依赖方、交付物、预期时间、主要责任人和升级路径，并考虑为等待审批、待验收或阻塞设置独立标记。

这类组织可以评估某项目管理工具或某项目管理平台是否支持团队看板、权限管理、跨项目视图、流程配置和数据汇总。中大型企业还应把访问权限、数据隔离、部署方式、审计要求、历史项目迁移和团队培训纳入选型，而不只是比较界面是否直观。

例如，面向中大型企业及百人以上组织的 PingCode，可作为项目管理平台选型时的一个评估对象。若组织有私有化部署、历史数据迁移等要求，可将其支持范围与现有流程、数据结构和迁移计划逐项核对；涉及 Jira 数据平滑迁移或国产替代时，也应要求供应方说明迁移范围、字段映射、附件处理、权限保留、验证流程及实施边界。产品能力需要按实际版本和合同范围核实，不能仅凭宣传语推断“无需改造”或“迁移无风险”。

3. 任务类型差异很大：拆分看板，不要强求一套字段

如果同一团队既处理周期短的日常请求，也处理需要多周协调的大型项目，任务周期、完成标准和阻塞原因可能完全不同。强行让两种工作使用相同字段，会让简单事项维护过重，也会让复杂事项信息不足。

可以按工作流拆分看板，同时为跨团队汇总定义少量共用字段，例如负责人、优先级、当前阶段和目标日期。这样既保留执行层面的差异，也能让管理者查看整体状态。拆分的原则是让信息更准确，而不是让每个小组都拥有一套互不兼容的定义。

4. 任务长期不动：先诊断原因，再决定是否加人

长期停滞并不一定代表工作量不足。若多数任务等待审批，应优化审批路径或授权规则；若任务反复退回，应检查需求和验收标准；若执行者同时承担过多工作，应讨论优先级和在制上限；若单项任务本身过大，则可以拆分出可独立交付的阶段。

加人可能有帮助，但并非所有瓶颈都能靠增加人手解决。若工作依赖单一审批人、稀缺专业角色或外部合作方，新增人员未必能缩短等待时间。先定位约束点，再决定资源投入，通常比看到逾期就扩充团队更稳妥。

八、工具与流程的取舍：先解决管理问题，再决定配置深度

1. 什么时候用简单看板就够了

如果团队规模不大、流程稳定、任务依赖少，使用共享表格或轻量看板就可能满足需要。只要团队能统一维护状态，能够看见责任人、下一步和阻塞情况，工具简单并不妨碍管理有效。

轻量方案的优势是启动快、学习成本低；限制是权限、自动化、跨项目汇总、历史数据分析和审计能力可能不足。团队应根据真实问题决定何时升级，而不是为了“数字化”而迁移所有任务。

2. 什么时候需要更完整的项目管理平台

当组织出现多团队协同、复杂权限、跨项目资源冲突、审计或私有化要求、历史项目数据迁移等需求时，单一简单看板可能难以支持治理和汇总。此时应评估平台能否承载流程差异，而不是只看是否有看板视图。

选型时可以安排实际任务演练：创建一项跨部门任务、设置责任人与依赖、标记阻塞、修改优先级、查看汇总状态，再验证权限、通知、历史记录和导出能力。供应方演示的标准流程不一定覆盖组织自己的例外场景，因此要用真实但脱敏的工作流验证。

3. 迁移时要在“保留历史”和“重建规则”之间取舍

从旧工具迁移时，全部照搬历史字段和工作流，可能把过去的复杂度带入新平台；只保留任务标题和当前状态，又可能丢失决策记录、依赖关系和审计信息。迁移前应先分层：哪些数据必须保留、哪些字段可以合并、哪些旧流程应在迁移前清理。

对于支持 Jira 平滑迁移等需求的平台，仍需逐项验证字段映射、附件、评论、用户权限、历史状态及关联关系能否按预期迁移，并制定抽样验收方案。迁移效果取决于原始数据质量和映射规则，任何“替代”方案都应有试迁移、业务确认和回滚计划。

4. 不同取舍的对照

九、用哪些信号判断看板是否真的改善了管理

1. 观察任务在“进行中”停留多久

可以按任务类型观察从进入进行中到离开的周期，并关注中位数和长尾，而不只看平均值。少数长期停滞任务可能显著影响整体交付体验；只看平均数，往往会忽略这些具体风险。

统计时要统一起止口径。例如，“进入进行中”的时间是负责人确认开工，还是卡片状态首次改变？“完成”是执行完成，还是通过验收？如果定义前后不一致，趋势变化可能只是记数方式变了。

2. 观察阻塞分布和复发情况

阻塞标签的价值，不在于证明团队遇到了很多问题，而在于帮助管理者发现重复约束。若大量任务都因等待同一审批、同一数据接口或同一关键角色而停留，改进重点就应放到流程和资源依赖上，而不是逐张卡片催问。

建议把阻塞原因控制在团队能理解的分类范围内，例如需求待确认、外部依赖、审批等待、资源冲突、技术问题和范围变化。分类不必过细，能够支持下一步决策即可。

3. 同时查看交付数量、周期和质量

如果团队只追求完成数量，可能通过把工作切成更小的卡片制造“完成增加”的表象；只追求周期缩短，也可能通过提前关闭未验收任务降低数字。因此应结合交付数量、周期分布、返工或退回情况，以及业务方是否接受交付综合判断。

指标是提出问题的工具，不是自动给出答案的裁判。看见周期变长后，团队应回到具体卡片查原因；看到阻塞增加后，应确认是否定义变化或依赖恶化；看到完成数量增加后，也要确认工作价值和验收质量没有被牺牲。

十、落地检查清单与最后的判断

1. 正式推行前，用六项问题做一次自查

• 团队能否用一句话解释“进行中”代表什么？
• 任务进入这一列前，目标、负责人和前置依赖是否明确？
• 每张卡片是否能看出当前进展和下一步动作？
• 阻塞、等待和超期是否有标记方式、责任人和复查安排？
• 团队是否知道在制任务过多时采取什么行动？
• 复盘时是否同时观察流动、交付和质量，而不是只看卡片数量？

2. 先小范围试运行，再扩大到更多团队

上线前先选一个工作流和一支团队试行，确认状态定义能被理解、卡片信息有人维护、阻塞事项有人处理。试运行的重点不是证明工具好用，而是检查管理规则能不能在真实任务中运行。

复盘时保留能帮助决策的信息，删除没人使用的字段；把反复出现的等待原因转成流程改进事项；把团队解决不了的问题明确交给有权限协调的人。规则经过一轮实际使用再扩展，通常比一开始设计完整、随后无人维护更可靠。

3. 最终原则：看板不是催进度的墙，而是暴露约束的系统

“进行中”做得好，不意味着所有任务都持续高速移动，而是团队知道哪些工作正在推进、哪些工作在等待、等待的原因是什么，以及下一步由谁采取什么行动。管理者的价值，也不在于每天检查卡片有没有变色，而在于及时协调优先级、清除依赖、调整工作量和修正规则。

下一步可以从一张正在堆积任务的看板开始：抽查十张“进行中”卡片，逐张确认责任人、下一步、阻塞和完成标准。若其中多张卡片无法回答这些问题，先改定义和流程，再考虑换工具。让“进行中”变得可信，效率提升才有可观察、可复盘的基础。