进行中怎么做？管理层实操方法：看板从0到1

任务一旦进入“进行中”，管理者最容易犯的错，不是看不见任务，而是把“已经开始”误当成“正在有效推进”。如果一块看板上有二十张卡片都停在“进行中”，团队看起来很忙，管理者却仍然不知道：哪些工作真正占用产能，哪些在等审批，哪些因为优先级冲突而没人敢做决定。看板从0到1，起点不是选工具或画列，而是说清工作怎样流动、什么叫卡住、谁负责解除阻塞。

一、先给结论：看板不是任务墙，而是管理工作流的控制面

1. “进行中”要有进入条件，也要有退出条件

我判断一块看板是否能用于管理，通常先看“进行中”有没有可执行的定义。只要任务被领取就算进行中，状态很快会变成个人的主观标签；如果进入条件和完成条件清楚，管理者才有机会分辨工作究竟在制作、评审、等待依赖，还是已经完成但未验收。

起步时可以这样定义：任务满足必要信息、负责人明确、优先级经过确认，并且当前确实有人开始处理，才进入“进行中”；任务交付物满足约定的完成标准后，才离开该状态。如果工作因为审批、外部依赖或资源不足而停下，应记录阻塞原因，而不是为了让看板显得整齐，继续把它留在一个含糊的状态里。

2. 先管理流动，再管理个人进度

看板的管理价值，不在于每个人都能填一个百分比，而在于团队可以从卡片的移动和停滞中发现流程问题。管理者首先要问：工作从哪里进入、经过哪些必要环节、在哪些地方等待、怎样才算交付？这些问题没有答案时，任务状态再频繁更新，也只是更勤快地记录混乱。

我建议把看板的目标写成可观察的问题，例如“识别需求从确认到交付的主要等待点”，而不是“提升协作效率”。前者可以通过停留时间、阻塞原因和完成记录来检查；后者太宽泛，很难判断到底改变了什么。

3. 第一阶段追求可解释，不追求看板复杂

刚开始时，几列、几种卡片颜色、多少种标签都不是核心。更重要的是，团队成员看到同一张卡片时，对其状态、责任人和下一步有相同理解。一个能解释当前工作、并能引出下一项管理动作的简洁看板，通常比一个字段齐全却无人维护的复杂系统更有用。

我的起步原则是：先让任务状态可信，再让数据丰富；先处理流程瓶颈，再谈个人效率。如果试点团队连一周内的状态变化都无法稳定记录，就不应急着把看板数据接入绩效评估或组织级报表。

二、看板为什么常常失灵：管理者看到的是状态，团队经历的是等待

1. “进行中”很满，实际工作却在排队

常见场景是：需求分析、设计、制作、审批、联调和验收都被合并为“进行中”。任务只要开始过一次，就长期留在这列。管理者看到的是一批正在推进的工作，执行人员感受到的却可能是大量等待：等业务方确认、等接口、等评审、等另一个团队排期。

这类看板的问题不一定是成员不更新。更可能的原因是状态粒度不够，导致“正在处理”和“暂时无法处理”无法区分。把卡片颜色换得更醒目，或者要求每天多更新一次，并不能修复状态设计上的缺口。

2. 汇报会替代了工作流管理

如果团队每天在会议上逐人汇报“昨天做了什么、今天做什么、有没有问题”，但会后没人推动跨团队依赖，会议就变成重复收集信息。看板应该帮管理者减少逐人追问，把讨论集中在异常上：哪项工作停滞、需要谁作出决定、哪一个约束正影响多张卡片。

我会特别留意一种信号：状态更新很勤，但任务仍然反复延期，或者阻塞原因总是写“处理中”。这说明团队可能完成了状态填写，却没有建立问题升级和决策机制。记录阻塞只是第一步，阻塞需要有负责人、响应时限和解除条件。

3. 过多并行任务制造“忙碌感”

一个人同时负责多个紧急任务时，卡片可能都在“进行中”，但实际工作会在它们之间频繁切换。此时，看板上的“进行中数量”不是产出，而是团队承诺和注意力分散的信号。管理者不应把“卡片越多”理解成“团队产能越高”。

这也解释了为什么限制在制品并不等于要求员工少做事。它要限制的是尚未完成的并行工作数量，让团队有机会完成已开始的事情，并更早暴露等待和优先级冲突。限制过严会让工作入口拥堵；完全不限制，则容易让半成品持续堆积。

4. 用看板做个人排名，会让数据失真

如果任务数量、关闭速度或卡片停留时间直接成为个人排名依据，成员就会有动力拆小任务、避开复杂工作，或者把状态改得更好看。短期报表可能更漂亮，团队却更难看见真实的协作成本和质量风险。

看板数据适合提出问题，不宜脱离任务难度、依赖关系和质量要求，直接用来比较个人。比如一张卡片停留时间长，可能是需求反复变化，也可能是在等待外部审批；在没有查明原因前，不能把“停得久”简单归因于执行者不努力。

三、从0到1搭建：先选工作流，再把规则写进看板

1. 选择一个边界清楚的试点

不要第一周就把整个公司所有部门、项目和临时事项都搬进一张板。试点最好满足三个条件：有相对稳定的工作类型、有能够参与规则讨论的负责人、有足够频繁的任务流转可以观察。比如一个跨职能交付小组、一类客户需求处理流程，或一条内部审批与执行链路。

范围太大，问题会混在一起；范围太小，可能看不到真实的等待和依赖。试点边界应让参与者说得清楚：什么工作会进入这块看板，什么工作不在其中，谁负责维护工作流规则。

2. 先画出实际流程，不要先套模板

我会让团队选取最近完成或正在处理的几项代表性工作，沿着真实经历复盘：任务从哪里来，什么时候可以开始，经过谁的处理，哪些情况需要返工，什么条件下才算交付。这里要还原实际工作，而不是画理想流程图。

如果某个环节只是偶尔发生，可以先用标签或阻塞备注记录，不一定要为它单独增加一列；如果一个阶段经常造成等待、交接或决策差异，则值得评估是否独立成列。每增加一列，都应能回答一个问题：这能否帮助团队识别以前看不见的工作状态？

3. 用最少的列表达关键状态

起步时可以考虑“待澄清、待开始、进行中、待验收、已完成”这样的骨架，但它只是讨论起点，不是标准答案。研发、内容制作、客户交付、采购审批的真实流转不同，不能为了统一外观而把不同性质的等待都塞进同一个列。

建议每列都配一条简短定义，说明任务进入条件、离开条件，以及是否需要明确负责人。例如“待验收”表示交付物已提交、正在等待指定验收人反馈；如果任务只是尚未有人开始，就不应放进这个状态。

4. 让任务卡支持决策，而非堆满字段

一张卡片的字段应服务于协作和下一步判断。常见的基础信息包括：要交付什么、谁负责、优先级依据、期望时间、完成条件、当前状态、阻塞原因和最近一次更新时间。并非每项工作都需要截止日期；如果日期没有业务依据，过多的“假截止日期”会削弱团队对真正承诺的重视。

字段设计应从最小集合开始。试点运行后，如果团队经常因为缺少某项信息而返工，再增加字段；如果某字段长期没人使用，或填了也不影响任何决策，就应考虑删除。字段越多，维护成本越高，不能把“记录更全面”误认为“管理更有效”。

5. 设定在制品限制：从可观察的容量开始

在制品（WIP）指已经开始但尚未完成的工作。限制可以按整条流程设定，也可以只对容易拥堵的阶段设定。实际数量应结合团队人数、任务类型和工作依赖试运行，不宜照搬其他团队的固定数值。

一个可执行的起点是：先统计目前各阶段的在制品数量，再观察哪些阶段最常出现等待和交接拥堵；为这些阶段提出一个暂行上限，连续观察后再调整。触及上限时，团队优先讨论如何完成、协助或解除已有工作，而不是不加判断地继续启动新任务。

四、让看板真正运转：管理层要建立的日常动作

1. 会议围绕流动和异常，不要逐人念卡片

短会可以从“已完成什么”开始，但重点应落在接下来怎样推动工作。一个实用的检查顺序是：先看接近完成的任务，再看阻塞和长期未更新的任务，随后检查在制品是否超过上限，最后才决定是否启动新工作。

团队可以围绕具体卡片讨论，而不是依次让每个人口头汇报。管理者需要追问的是“下一步是谁在什么时间做什么”，不是“你为什么还没完成”。前一种问法能暴露依赖和决策缺口，后一种问法容易把系统问题变成个人解释。

2. 为阻塞建立明确的升级路径

阻塞记录至少要包含原因、需要的支持、责任方和下一次检查时间。比如“等待业务确认”还不够，最好进一步说明需要确认的内容、由谁提供、目前影响哪项交付，以及何时需要升级给能作出决定的人。

试点团队可以先约定一个简单规则：阻塞出现时由卡片负责人记录；如果在约定的检查节点仍未解除，由团队负责人协调；如果问题涉及优先级或资源冲突，则升级到有权调整承诺的管理者。时限要根据工作节奏设定，关键是每个人都知道什么时候该找谁。

3. 管理者要处理规则无法解决的冲突

看板能让冲突显性化，却不能替管理者作出所有取舍。两项高优先级工作争用同一位专家时，需要有人决定先后顺序；多个团队共享一个审批角色时，需要有人调整服务方式或资源安排。把这些卡片摆出来之后，管理层应承担起取舍责任，而不是要求执行人员自行消化矛盾。

我会把管理动作分成三层：团队可以自行解决的任务排序和协作问题，由团队处理；跨团队依赖由双方负责人协调；影响业务承诺、资源配置或风险接受度的问题，由有决策权的管理者拍板。层级不清，卡片只会把等待公开化，却不会缩短等待。

4. 把看板更新嵌入工作，不另造一套汇报负担

状态应该在工作发生变化时更新，而不是等到周报前一次性补录。任务从待开始转为进行中、交付物提交验收、发现阻塞或完成，都应成为更新节点。这样做不是为了追踪每个人每小时做了什么，而是为了让团队依赖的信息尽量及时。

如果成员需要在看板、表格、邮件和会议纪要里重复填写同一信息，就要检查流程是否产生了多份事实来源。管理者应明确哪一处是团队协作的有效记录，哪些报表可以从现有记录整理出来，减少重复维护。

5. 复盘关注流程原因，不只盯单个数字

复盘时可以从三类问题开始：工作在哪里等得最久？哪些阻塞反复出现？任务为什么会退回或重开？如果发现待验收阶段积压，不要马上要求验收人“抓紧处理”；先核实验收工作是否集中在少数角色、验收口径是否清楚、是否存在集中交付的习惯。

每次复盘最好只挑少量可执行的改进项，并为每项安排负责人和检查日期。规则调整后继续观察一个完整周期，再判断是否有效。一次同时改列结构、会议频率、任务模板和上限，之后就很难知道哪项变化带来了影响。

五、用一个假设案例看懂“卡在进行中”该怎么处理

1. 场景：看起来在做，实际在等确认

下面是一个假设场景，不代表真实企业案例。某个跨职能团队的需求卡片已经进入“进行中”七天，负责人仍然在跟进，但交付内容依赖业务方确认一项规则。原来的看板没有“待确认”状态，卡片也没有阻塞字段，因此管理者只看到任务没完成，执行者则反复在聊天里追问。

如果只问“为什么进度这么慢”，团队得到的答案可能是“还在沟通”。这句话既不能显示需要谁作决定，也不能判断任务是否还在消耗制作产能，更无法帮助管理者协调优先级。

2. 先把事实补齐，再选择处理动作

管理者可以先要求卡片补充四项信息：具体等待什么确认、由谁确认、确认内容影响哪个交付点、下一次检查时间。确认后再判断它属于哪种情况：工作尚未真正开始，应退回待开始；任务正在处理但有明确外部依赖，应标记阻塞并保留当前阶段；如果此类等待频繁发生且确实构成稳定工作步骤，再评估是否增加独立状态。

关键不在于“是否一定要新增一列”，而在于管理者能不能根据卡片判断下一步。如果一次性的等待，用阻塞标记就能追踪；如果一类工作经常经过正式确认，而且等待需要单独管理，独立状态才可能带来额外价值。

3. 将管理问题转成规则变更

假设团队发现同类需求经常因规则确认而停滞，可以试行一条入口规则：业务确认未完成的任务不进入实质制作；确需提前启动的，由提出者明确风险和临时方案。与此同时，指定确认责任人，并为超过约定时间仍未响应的卡片建立升级方式。

这不是为了让看板列得更细，而是把反复出现的模糊等待变成可管理的决策点。若试行后等待并未减少，就继续查找原因：可能是责任人没有决策权限，也可能是需求说明不完整，或确认请求没有明确时限。

六、指标怎么选：先定义口径，再用数据提出问题

1. 先记录少量能回答管理问题的数据

试点初期不必追求完整的指标体系。通常可以先记录任务开始和完成时间、各状态进入与退出时间、阻塞原因、任务重开情况，以及当前在制品数量。记录这些信息的目的，是判断工作流哪里需要管理动作，不是为了让仪表板看起来更丰富。

在计算前先统一口径。例如“完成周期”从什么事件开始算？是需求进入队列，还是负责人开始处理？“完成”是否包含验收和交接？如果不同团队采用不同定义，即使都报出一个数字，也无法公平比较。

2. 用周期、吞吐和在制品互相校验

周期时间反映一项工作从约定起点到完成经历多久；吞吐量反映一段时间内完成了多少工作；在制品数量反映当前尚未完成的工作规模。这几项不能孤立使用：在制品增加、吞吐不变、完成周期变长，可能提示入口过量或瓶颈加重；但任务难度、工作类型变化也可能影响结果，必须结合卡片内容解释。

如果只追求吞吐量，团队可能把大任务拆成许多容易关闭的小卡片；如果只盯周期时间，成员可能倾向于避开高风险或依赖多的工作。因此，管理者要把数字和任务类别、质量结果、返工情况一起看，而不是寻找一个可以代表所有效率的单一分数。

3. 对比前后时，避免把示意数据写成改善结论

没有企业实际记录时，可以用假设数据演练计算方式，但必须明确标注为示意或情景模拟。例如，可演示如何从“各阶段停留时间”定位瓶颈，却不能把示意数值描述成行业平均值或真实试点结果。真正发布管理结论，应说明数据来源、统计周期、样本范围和指标定义。

前后对比还应考虑工作组合变化。试点后如果团队接到的任务更简单，平均完成周期缩短，不一定意味着看板规则改善；反过来，如果复杂任务比例上升，周期暂时变长，也不能直接断定试点失败。尽可能按相近工作类型比较，并同时观察阻塞和返工变化。

4. 指标应触发问题，而不是自动触发处罚

当某项任务停留时间明显偏长，管理者可以触发检查：状态是否准确、是否有阻塞、完成条件是否清楚、当前优先级是否仍有效。当某一阶段持续积压，可以检查阶段容量、交接质量和授权方式。指标的价值在于缩短发现问题的时间，而不是替代对具体工作的理解。

建议把指标报告写成“观察，假设，验证动作”。例如，观察到待验收任务增加；假设是验收集中在一位负责人；下一步核对验收分布并试行备份安排。这样既保留了数据依据，也避免在没有验证前把猜测当成结论。

七、按团队情况调整：不同情形要做不同取舍

1. 团队规模小、工作类型相对稳定

小团队通常更适合从简单看板开始，列数控制在能区分关键阶段的范围内，先靠短会和负责人协作解决问题。初期不必急于建立复杂的权限、自动化和多层报表，先确保每张卡片有人负责、有下一步、状态及时。

取舍重点是降低维护成本。若每次状态更新都需要填写大量字段，团队很可能回到口头沟通。小团队可以先使用阻塞备注和简单的任务分类，只有当某类等待反复出现、需要单独治理时，再增加状态或规则。

2. 多团队协作、依赖频繁

跨团队工作通常不适合只看单个团队的执行状态。需要明确交接责任、输入输出、依赖方的响应预期和升级对象。必要时可以使用相互关联的团队看板，但要避免重复维护同一张任务卡，或每个团队都用不同含义解释“完成”。

取舍重点是边界与一致性：团队可以保留本地工作细节，但跨团队交接、状态定义和关键时间点需要有共同约定。否则一方看到“已完成”，另一方可能仍认为资料未齐，最终的等待依然藏在系统边界之外。

3. 工作高度不确定、紧急事项很多

探索型工作、故障响应或高频临时需求，难以完全按固定流程安排。此时不应为了整齐而强迫所有任务走同一条路径。可以区分计划内工作与紧急通道，并定期检查紧急事项是否挤占了常规承诺，以及所谓“紧急”是否已经变成日常入口。

取舍重点是响应速度与团队连续性。紧急通道能提高突发问题的可见度，却会带来切换成本；如果使用频率不断上升，管理层应检查需求入口、服务承诺或资源配置，而不是仅靠执行人员加班填平缺口。

4. 已有项目管理平台，但数据质量较差

工具已经上线，不等于管理机制已经运行。若看板字段很多、状态含义不一、卡片长期不更新，建议先抽样检查一批任务，找出最常见的误用：任务未拆清、负责人缺失、状态迁移标准不明，还是系统流程与真实工作不符。

取舍重点是先修规则还是先换工具。多数情况下，如果问题来自责任不清、没有升级机制或完成标准模糊，换一个工具不会自动改变这些行为；如果现有工具确实无法表达必要的工作流、权限或部署要求，再评估迁移成本、数据连续性和团队适应负担。

八、试点四周怎么推进：用节奏建立可信的反馈回路

1. 第一周：对齐范围和词义

第一周只做几件事：确定试点工作范围，整理真实工作流，定义状态进入与退出条件，确认卡片必需信息，并记录当前最明显的管理问题。不要在规则尚未对齐时就发布复杂指标，也不要把“所有任务都进系统”当作唯一成功标准。

这一阶段需要听取实际执行者的意见，因为他们最清楚任务是怎样交接、哪些信息经常缺失、什么状态最难判断。管理者要做的是明确目标和决策边界，而不是替团队假设每个环节的真实情况。

2. 第二周：运行最小规则，观察失真点

第二周开始按试点规则维护任务，重点记录状态不一致、卡片缺信息、等待原因不明和任务反复退回的情况。发现问题先记录，不要每出现一次特殊情况就立刻增加一列或一条审批规则，避免看板被临时补丁迅速复杂化。

每次短会可以用十几分钟检查阻塞、超限和接近完成的工作，但会议时长不是目标。若需要更多时间处理跨团队决策，应单独安排协调会议，而不是把所有问题都塞进日常状态同步。

3. 第三周：针对一个瓶颈做小幅调整

第三周选出一项证据相对充分的问题，例如待验收阶段持续积压，或大量工作因需求信息不完整而返工。只改一个主要机制：调整入口条件、明确验收责任、设置阻塞升级规则，或试行一个在制品上限。

调整前先写下预期变化，例如“减少缺少验收人的任务进入执行”，而不是“整体效率提升”。之后查看相同类型任务的状态变化和相关等待，确认机制是否有效；如果没有改善，就回到原因分析，而不是把目标改写成成功。

4. 第四周：决定保留、修改或停止

第四周复盘时，检查三件事：看板记录是否可信，团队是否能从看板发现过去不易发现的问题，管理者是否对暴露出的阻塞作出响应。若团队填了数据却没人用它作判断，说明这套机制还没有融入管理。

试点结果不必只有“推广”或“失败”两种。可以保留有效规则、修改不适合的状态、暂停成本过高的字段，也可以缩小试点范围。扩大范围前，最好确认规则解释稳定、维护责任明确、关键问题有处理路径，并且数据口径能被复用。

九、管理者上线前自检：别让看板变成新的形式主义

1. 检查规则是否能被执行者解释

• 团队是否能用相同的话解释“进行中”代表什么？
• 每个状态是否写明了进入条件和退出条件？
• 任务卡是否有清楚的负责人、下一步和必要交付信息？
• 遇到阻塞时，谁负责记录、谁负责协调、何时需要升级？
• 在制品限制是否来自团队观察，而不是机械照搬别人的数字？
• 任务完成前是否有明确的验收或交接标准？
• 数据是否用来发现流程问题，而不是简单给员工排队？
• 试点是否安排了复盘，并为改进动作指定了负责人？

2. 检查管理层是否准备好接住问题

看板可能让一些长期被口头沟通掩盖的问题变得更明显：优先级相互冲突、审批责任缺失、资源不足、跨团队承诺不一致。管理层需要提前想清楚，问题暴露后由谁决定、哪些事项可以调整、哪些风险需要升级。

如果组织只要求团队“把问题写出来”，却不愿意调整资源、顺序或决策方式，看板会逐渐失去信用。成员会发现，阻塞写不写都没有差别，最后回到私聊和临时协调。透明度不是把问题展示出来就结束，而是让问题有机会被处理。

3. 检查数据是否有清楚的解释边界

每个指标都应有定义、数据来源和适用范围。平均周期需要说明起止时间；任务完成量需要说明统计单位；阻塞数量需要说明怎样算一次阻塞。若不同任务类型差异很大，应该分组观察，不能把一个混合平均数当成团队全部工作的画像。

如果只有很少样本，或试点期间工作结构发生明显变化，应把结论表述为观察线索，而不是确定因果。管理者可以说“本阶段发现验收等待值得进一步核对”，不宜直接说“某项规则使效率提升了某个百分比”，除非数据设计能够支持这种归因。

十、结尾：先让“进行中”可信，再让看板规模化

看板从0到1，真正的难点不是把任务拖进一列，而是建立一套团队愿意遵守、管理者能够响应的工作规则。任务何时开始、何时算完成、阻塞由谁处理、并行工作到了什么程度需要暂停新开工，这些问题决定看板是协作工具，还是一面更整齐的任务墙。

我的建议是，下一步先选一条范围明确的工作流，抽取近期任务还原真实过程；接着用最少的状态定义“待开始、进行中、待验收和完成”，为阻塞补上责任人和检查点；最后连续观察一段时间，复盘任务在哪里等待、规则哪里失真，再决定是否增加状态、调整在制品上限或扩大试点。

管理者判断看板是否有效，不要只看卡片有没有更新，而要看它是否让团队更早发现等待、更清楚地作出取舍，并让有权解决问题的人及时介入。如果这三件事还没有发生，优先修管理机制；如果已经发生，再考虑扩大工具覆盖范围。