看板如何做好进行中？管理层风险控制与操作步骤

看板上“进行中”任务越来越多，交付却没有变快，通常不是团队不够努力，而是这个状态失去了管理含义：有人把“准备开始”放进去，有人把“等别人回复”留在里面，还有些任务已经停滞，却仍显示为正常推进。管理层要管好的不是卡片颜色，而是每项工作何时开始、谁对下一步负责、风险何时升级，以及什么条件才算完成。

一、先讲结论：把“进行中”当作一项管理承诺

1. 状态变化必须对应真实工作

一张任务卡进入“进行中”，至少应同时满足三个条件：工作已实际启动，有明确的当前负责人，并且存在可执行的下一步动作。只有计划日期、没有实际动作的任务仍是待办；正在等待外部输入的任务，应标出依赖或阻塞，不能只靠“进行中”掩盖等待。

我判断看板是否有效，首先不看列名设计得多漂亮，而看卡片状态能不能解释真实工作。如果管理者问“这项工作现在卡在哪里”，执行者还要另外找聊天记录、邮件或会议纪要才能回答，看板就没有成为可靠的管理信息源。

2. 管理层要管理流动，不只是追问进度

管理者的任务不是每天逐项催问“做完了吗”，而是识别工作流中的异常：进入进行中的速度是否超过完成速度，任务是否在某个环节排队，阻塞是否持续无人处理，以及优先级调整是否让原有工作反复中断。

这些判断不能仅凭某一个数字下结论。任务停留时间长，可能是任务过大，也可能是等待审批、外部依赖或验收口径不清。看板应帮助团队提出正确的问题，而不是把一个异常指标直接变成对个人的评价。

3. 规则先于工具

无论使用实体白板、电子表格还是某项目管理平台，团队都需要先说清楚状态定义、进入条件、责任人、阻塞处理方式和完成标准。工具能让状态更容易记录、查询和追踪，但不能替团队决定“什么叫开始”“谁该解决依赖”或“怎样才算交付”。

对中大型企业和百人以上组织而言，如果任务涉及多个部门、需要权限治理或有部署要求，平台选型可以作为流程设计的一部分。比如评估 PingCode 时，可以进一步核对其私有化部署能力、Jira 平滑迁移方案及团队规模适配情况；是否适合，应结合权限、集成、迁移成本、数据治理和长期运维逐项验证，而不是把任何单一产品视为所有团队的唯一答案。

二、为什么“进行中”最容易失真：看板背后的真实场景

1. 卡片从待办移动，不等于工作真正启动

在跨部门项目里，任务可能已经被分配，却还缺少业务确认、接口信息、测试环境或审批结果。执行者为了让计划显得有进度，把卡片先移入进行中；此后几天，任务既没有产出，也没有新的状态变化。表面上团队有很多工作在做，实际上工作只是进入了一个看不见的等待区。

这种问题常见于部门交接处：上游认为已经交付，下游认为还没收到可用输入；项目负责人看到任务“有人负责”，便误以为风险已经受控。卡片状态没有定义清楚时，责任链条就会在交接位置断开。

2. 并行任务太多，会让“忙碌”被误读成“产出”

当管理者担心延期，常见反应是继续往团队里加任务，或者要求每个人同时推进更多事项。结果可能是切换成本增加、等待变长、完成节点变少。尤其是需要多人评审、环境资源或业务决策的任务，增加“进行中”卡片并不一定增加有效产出，反而可能扩大排队。

因此，我不建议只用“每个人手上有多少任务”衡量工作负荷。还要看团队整体在制任务、完成节奏、阻塞类型和任务颗粒度。人员数量相同，工作依赖结构不同，能承载的并行量也会不同。

3. 不同团队把同一个状态用于不同事实

研发团队可能把“进行中”理解为代码已经开始修改；运营团队可能在任务被认领后就标记进行中；审批流程中，它又可能意味着材料已提交但正在等待决策。若管理层把这些状态放进一张汇总看板直接比较，得到的只是名称相同、含义不同的数据。

如果业务场景确实需要不同状态，不必强行统一所有流程。可以统一管理层需要观察的信号，例如责任人、当前阶段、阻塞原因、开始时间和预计下一节点，同时保留各团队必要的专业状态。

4. 一个用于诊断的情景推演

下面是一个情景模拟，用于说明状态失真怎样影响管理判断，并非行业调查数据或真实企业绩效。假设某交付团队一周内把更多任务移入进行中，但完成数基本不变，管理者若只看“已启动数量”，可能误判产能上升；把等待和阻塞拆开后，才会发现新增任务没有形成相应的交付流量。

三、常见误区：看板整齐，不等于风险受控

1. 把所有未完成事项都塞进进行中

“有人负责”“已经排期”“正在等材料”和“正在执行”是不同事实。如果团队把它们统一放进进行中，管理者无法分辨哪里有工作在推进、哪里在等待、哪里需要决策。时间一长，进行中列只剩下一个含义：还没有完成。

改进时不必追求列越多越好，而要让状态对行动有区分价值。若团队经常发生“已开始但在等待”，就应增加等待或阻塞信号；如果等待种类复杂，至少要记录阻塞类型和责任方。

2. 用颜色代替问题描述

红色可以提醒管理者注意，却不能说明风险是什么。任务标红后，如果没有“影响什么、需要谁处理、下一次何时复核”，颜色就只是视觉装饰。风险标记应连接处理动作，而不应成为另一个无人维护的标签。

3. 任务长时间不动，只催负责人

停滞可能源于负责人未行动，但也可能是优先级冲突、依赖未满足、决策权不清、验收口径反复变化或团队容量被临时任务挤占。管理者若只问“为什么还没做完”，很容易把系统问题误判为个人懈怠。

更有效的追问顺序是：当前可观察到的下一步是什么？执行这一步还缺什么？缺口由谁控制？如果无法在约定时间解决，谁有权调整范围、资源或顺序？这些问题能把追责式对话转成可执行的风险处理。

4. 只设在制上限，却不解释怎么调整

在制任务上限可以帮助团队限制并行工作，但如果只规定“不能超过某个数”，却不说明新需求如何排队、紧急事项怎样插入、哪些任务可以暂停，团队可能通过拆卡、改状态或线下推进来绕过规则。

上限不是用来压低工作量的口号，而是提醒团队在新任务进入时，必须面对容量取舍。先试运行，再根据任务复杂度、依赖程度和完成节奏调整，不宜照抄其他组织的固定数值。

5. 把看板数据直接变成绩效排名

同样一张卡片，可能代表半小时的简单修改，也可能代表需要多方协调的复杂交付。完成卡片数量、停留时间或逾期数，如果没有任务难度、依赖和质量背景，不能单独用于比较个人表现。

看板首先是工作流和风险管理工具，不是天然公平的个人计分器。当团队担心数据会被用于不合理排名时，成员更可能隐藏阻塞、拆分任务或延迟更新，管理层最终看到的就会更不真实。

四、专业判断逻辑：判断进行中是否健康，要看五类信号

1. 进入条件是否稳定

先抽查最近进入进行中的任务：是否有明确目标、负责人、必要输入、下一步动作和验收要求。如果多数卡片在启动后才补充这些信息，团队实际采用的不是准入规则，而是“先移动、后补作业”。管理者应把缺失项按频率分类，再决定是补模板、补评审还是调整上游交付。

2. 工作是否持续流动

管理者要观察任务从进入到退出各状态的过程，而不是只统计某一天有多少卡片。若进行中数量连续上升、完成量没有相应变化，应进一步查看新增任务、暂停任务和阻塞任务的来源；若任务数量稳定但交付周期变长，则可能是复杂度、等待或返工增加。

单个时间点只能提供截面，不能说明趋势。建议按团队可操作的节奏查看一段连续时间，并把需求类型、紧急插单和人员变化一并记录，避免把短期波动解释成流程改善或恶化。

3. 停留时间是否需要解释

团队可以依据自身历史建立“需要复核”的观察阈值，例如某类任务在超过本团队常见周期后触发检查。这个阈值是提醒，不是自动判错线。对大型、复杂或依赖外部审批的任务，应按工作类型区分；把所有任务套进同一时限，会制造大量无效告警。

4. 阻塞是否有责任链

一条可管理的阻塞记录至少应包括阻塞事实、影响范围、所需协助、处理责任方和下次复核时间。执行者通常负责及时披露，项目负责人负责协调，管理层负责处理超出团队权限的资源冲突和优先级决策。不同组织可以调整分工，但不能让阻塞停留在“大家都知道”的口头状态。

5. 完成是否有可复核的证据

“已完成”应对应交付物、验收记录或可验证结果。研发任务可能需要代码审查、测试或发布确认；业务任务可能需要业务方确认数据、流程或内容符合要求。完成标准不清晰时，团队容易在看板上提前关闭任务，之后又以返工任务的形式重新打开。

五、具体操作步骤：让每次状态变更都能追溯

1. 定义状态及进入、退出条件

先用短句描述每个状态，而不是只列出名称。比如，“进行中”可以定义为：负责人已开始执行当前工作，下一步动作明确，必要输入可用；“阻塞”则表示工作因可说明的障碍无法继续，需要记录影响和处理责任。退出条件同样要写清，避免任务因“看起来差不多”而被提前关闭。

规则应尽量贴近团队语言，减少流程术语。如果新成员无法根据看板规则判断卡片该放在哪里，说明定义还不够可操作。

2. 把任务拆到可以检查进展的颗粒度

任务卡不必小到记录每一次点击，也不能大到几周都没有可见产出。判断颗粒度是否合适，可以看三件事：负责人能否说出下一步动作，团队能否在约定周期内检查一次进展，交付结果能否被验收。

如果卡片描述是“完成系统升级”或“优化客户体验”，但看不到具体范围和结果，管理者应先要求补充交付物或拆成阶段任务，而不是把它放进进行中后期待进度自然出现。

3. 启动前确认责任、依赖和容量

在任务进入进行中前，由负责人确认自己承担什么结果、哪些输入已经就绪、依赖方是谁、当前是否存在更高优先级工作。如果依赖没有满足，可以保留在待办，或使用团队约定的等待状态；不应为了制造进度感而提前启动。

团队还要检查在制任务是否超出当前可承载范围。如果已经超载，先讨论暂停、延后或重新排序，而不是默认每项工作都能同时推进。管理层最重要的作用之一，是授权明确的取舍。

4. 开始后记录事实，而非写流水账

状态更新应回答管理问题：最近发生了什么变化、下一步是什么、是否出现风险。没有变化也可以如实写明原因和复核时间。频繁填写“继续推进”“持续跟进”之类内容，既增加维护成本，也不能帮助他人判断是否需要介入。

5. 阻塞出现时立即标明处理路径

发现阻塞时，执行者应尽快描述具体障碍，而不是只贴一个“卡住”标签。负责人再判断它属于信息缺失、资源冲突、审批等待、技术问题还是优先级变化。对于团队权限内的问题由团队处理；超出权限的事项应升级给拥有决策权的人。

6. 验收后再关闭，并保留必要记录

当工作达到约定结果后，进入验收或完成状态。若验收需要业务方确认，应标明确认责任和当前结果，不要把“已提交验收”写成“已完成”。出现范围变更、插单或延期时，记录关键决策，避免后续复盘只能依赖聊天记录还原过程。

7. 定期复盘流程原因，而非只复盘个人失误

复盘时可以挑选少量有代表性的任务，查看其进入条件、停留节点、阻塞解决过程、返工情况和最终验收结果。重点寻找重复发生的系统原因：输入长期不完整、审批队列过长、优先级频繁改变，或任务拆分方式不适合实际协作。

六、管理层风险控制：规定谁在什么情况下采取什么动作

1. 建立分层责任，而不是让所有人都负责

执行者应及时更新任务事实、披露阻塞并提出所需协助；任务负责人应处理日常协调、拆分和优先级确认；项目或部门管理者应解决跨团队依赖、资源冲突和目标变更。若责任只写“相关人员跟进”，风险就很可能变成无人负责的共同事项。

这并不意味着每个阻塞都要升级到高层。升级的目的，是把问题送到有权限解决的位置，而不是增加汇报层级。团队可约定哪些事项由负责人处理，哪些事项需要管理者做取舍，并为每类升级保留清楚的入口。

2. 用触发规则管理异常

可以针对长期无更新、预计交付时间变化、阻塞超过约定复核点、团队在制量持续超限等情况设定提醒或检查规则。阈值应由本团队的历史节奏和业务风险决定，并且要定期回看：触发太频繁，说明规则可能过于敏感；几乎从不触发，也可能意味着数据不完整或条件不合理。

我更倾向于把异常规则设计成“需要复核”，而不是“自动判定失败”。同一时长对不同类型的任务意义不同，告警应引导管理者查看原因，而非替代判断。

3. 让插单和优先级变化可见

插单本身未必错误。生产事故、合规要求或关键客户事件都可能需要改变优先级。真正的管理风险是，任务不断插入，却没人决定哪些原有工作因此暂停或延期。每次优先级变化都应指出决策人、受影响任务和新的预期安排。

若多个部门都能随时把任务标成最高优先级，团队就会陷入隐性的多重承诺。管理层应建立轻量的冲突处理机制：谁能定优先级、何时集中评审、变更如何通知受影响团队。

4. 指标必须和业务解释一起看

建议至少联合观察进行中数量、任务停留时间、阻塞比例、完成情况和返工情况，但不要把所有指标压缩成一个分数。进行中数量上升可能意味着需求增长，也可能意味着启动门槛变低；完成量增加可能来自任务变小，也可能来自真实产能提升。没有业务背景的数字，很容易提供错误的确定感。

七、案例与数据观察：同一张看板，管理动作可能完全不同

1. 情景：跨部门交付团队的任务越堆越多

假设一个由产品、研发、测试和业务组成的团队，在月度复盘时发现进行中任务明显增加。团队最初的解释是“需求变多，大家都很忙”。管理者没有立即要求压缩工期，而是把任务按执行中、等待输入、等待决策和待验收重新分类，并补看开始时间、当前负责人和下一步动作。

这是一种示范性诊断，不是对真实企业的调查结论。关键不在于某个数字，而在于拆分之后能否发现：哪些任务真正消耗执行能力，哪些任务只是停在依赖环节，哪些任务已经形成结果但没有及时验收。

2. 用同一组模拟数据检验可能的解释

设想复盘发现，40项进行中任务里，24项正在执行，9项等待其他部门输入，5项等待决策，2项已经提交验收但未关闭。此时如果只减少执行人员手上的任务，未必能解决主要瓶颈；若等待输入和决策占比高，管理层应优先检查交接和决策链路。

这组比例是情景模拟，不代表行业基线。它展示的是一种分析方法：先把状态拆成可解释的工作事实，再根据阻塞分布采取动作，而不是先设定一个看似权威的目标比例。

3. 根据原因调整，而不是统一加压

若等待输入占多数，团队可以定义上游交付检查项，并指定依赖确认人；若等待决策集中在少数事项，可设置决策责任人和复核时间；若任务主要在执行中但停留很久，则需要检查任务拆分、资源和工作优先级；若待验收积压，则需明确验收时限和验收人。

同一个“进行中数量过多”的表象，可能对应完全不同的治理动作。管理者应先验证原因，再决定是否限制新任务、增加协作资源、调整流程或重新排期。把所有异常都归结为“执行不够快”，通常既不准确，也不能稳定改善交付。

八、不同情况下的行动建议与取舍

1. 新团队或刚开始使用看板

先建立最少但够用的状态：待办、进行中、阻塞或等待、验收、完成。每个状态写一句定义，并选取一小段工作试运行。不要一开始就设计复杂指标和自动化规则，先观察成员能否用同一套语言描述任务当前事实。

此阶段的取舍是：优先要一致性，不追求数据全面。若记录要求太多，成员会把看板当成额外行政工作；如果只记录标题和负责人，又无法支持风险判断。可先从目标、负责人、下一步和阻塞四项开始，逐步补充。

2. 进行中任务已经明显过载

先暂停无必要的新启动，梳理现有任务的业务优先级、依赖、剩余工作和停止成本。随后由有权负责人决定继续、暂停、拆分或取消，不要默认所有任务都必须保持活跃。对于已经投入大量工作、但价值或前提发生变化的任务，也应允许重新评估。

取舍重点是减少并行，不是机械减少卡片。若卡片代表不同规模的工作，单纯设数量上限可能误伤大任务或鼓励拆卡。团队可以按工作类型分类观察，并逐步寻找适合自身的限制方式。

3. 阻塞主要来自跨部门依赖

为关键依赖明确交付物、提供方、接收方和需要日期。执行者发现缺口后及时标注，项目负责人跟进协作，超过团队权限的事项再升级。对于高频重复的依赖，可把解决方式固化为交接清单或接口约定。

取舍是流程标准化和灵活性的平衡。所有协作都设审批节点会拖慢简单任务，但完全没有交接约定又会造成反复确认。应先针对高频、高风险或经常返工的依赖建立规则，而不是把每个例外都变成新的表单。

4. 任务跨团队、数据和权限要求较高

如果组织有多部门协同、复杂权限、私有化部署、历史项目迁移或合规要求，平台选择需要和流程治理一起评估。可以把 PingCode 纳入候选评估，重点核验是否满足中大型企业及百人以上组织的协同需求、私有化部署要求，以及 Jira 迁移过程中的字段映射、历史记录、权限迁移、集成兼容和用户培训安排。

“支持迁移”不等于迁移没有成本，“支持私有化部署”也不等于所有部署形态都无需额外运维。国产替代决策更应看功能适配、数据控制、服务响应、迁移风险和总拥有成本，而不能只凭单一卖点。工具可作为候选方案，但是否适用应通过试点和技术评估确认。

取舍重点是标准化与适配之间的平衡。平台应尽可能承载共同规则，但不同团队仍可能需要自己的流程字段、验收节点和权限边界。若为了统一看板而抹平关键业务差异，汇总数据看起来整齐，实际决策反而可能失真。

5. 任务停留时间长，但原因不清楚

先抽查一批长期未变化任务，逐项核对卡片描述、实际工作、依赖记录和沟通时间线。区分任务确实在执行、工作已经暂停、状态更新滞后、或任务本身范围过大。抽查结果比立即引入复杂评分规则更能帮助团队找到数据问题。

如果状态更新滞后是主要原因，重点应改进更新责任和节奏；如果范围太大，应调整任务拆分；如果等待居多，应处理依赖和决策；如果优先级频繁改变，应让管理层明确取舍。只有在原因清楚后，设置停留提醒才会真正有用。

6. 管理层希望提高可视性，但不想增加会议

把看板检查聚焦于异常事项，而不是要求成员逐卡汇报。会前由负责人更新阻塞、风险、优先级变化和需要决策的问题；会议中只讨论需要协调或取舍的事项；会后记录决策人、行动责任和复核时间。

取舍是可视性和维护成本。信息越细，不一定越有用。每个字段都应回答一个管理问题；如果字段长期无人查看、不能触发行动，就应考虑删除或合并。

九、落地检查清单：一周内先验证最关键的规则

1. 第一天：统一“进行中”的含义

找执行者、项目负责人和管理者一起讨论典型卡片，确认哪些属于实际执行，哪些属于等待、阻塞或待验收。用真实任务验证定义是否容易应用，而不是在会议室里只讨论抽象术语。

2. 第二至第三天：抽查卡片质量

抽取近期新增和长期未变化的任务，检查是否有负责人、下一步、依赖、验收条件和真实状态。记录缺失最频繁的两三类问题，优先解决高频原因，不必一次改完所有字段。

3. 第四至第五天：试行异常处理

选择少量明确规则，例如阻塞必须记录处理人和复核时间，优先级变化必须说明受影响事项。试行期间观察规则是否帮助团队更快处理问题，还是只增加了填报负担。

4. 一周后：复盘数据含义和例外

检查团队是否能从看板回答四个问题：哪些工作正在真实执行？哪些事项正在等待？最需要管理层处理的风险是什么？哪些任务已经满足完成条件却仍未关闭？如果无法回答，先改规则和数据质量，再考虑添加新的报表。

• 每项进行中任务是否有明确负责人和下一步动作？
• 等待、阻塞、执行和待验收是否能够被区分？
• 新增任务是否经过容量和优先级确认？
• 风险是否有处理责任人和复核时间？
• 完成状态是否对应可检查的验收证据？
• 插单和优先级变化是否记录了决策及影响？
• 管理层查看的指标是否使用一致口径并结合业务背景解释？

看板上的“进行中”不是越多越好，也不是越少越好；关键是每一项都能说明正在发生什么、下一步由谁推动、哪里需要管理介入。先用一周抽查真实任务，找出状态定义、依赖处理或验收中的一个主要断点，再只针对这个断点改规则。与其一次性设计一套庞大制度，不如让每次状态变化都变得可解释、可追踪、可行动。