进行中怎么做？企业管理者最佳实践：看板从0到1

“进行中”列里有 47 张卡片，团队却说不清哪项工作最可能延期，这不是看板缺少颜色，而是看板没有把工作流、责任和决策规则说清楚。企业从零搭建看板，真正的起点不是画几列，而是确定什么工作可以进入、何时算开始、卡住后谁来处理，以及管理者看见异常后要做什么。

我的核心判断是：看板不是任务展示墙，而是组织的流动控制系统。它的价值不在于让所有任务都“可视化”，而在于尽早暴露阻塞、限制并行工作、缩短从需求到交付的等待时间。本文用一个明确标注为情景模拟的企业案例，拆解从工作流梳理、试点配置到管理复盘的落地方法；其中示意数字用于说明测量方式，不代表行业统计，也不应被当成任何产品的效果承诺。

一、先讲核心结论：看板从0到1，先管流动，再管任务

1. 看板不是“把所有事情贴出来”

很多团队第一次做看板，会把需求、会议待办、缺陷、行政事项全部塞进一张大屏。结果卡片确实齐了，信息却更难读：工作类型混杂，优先级互相冲突，管理者无法看出瓶颈究竟在评审、开发、测试还是验收。

我建议把看板的设计目标压缩成三个问题：工作从哪里进入，经过哪些可验证状态，交付之后由谁确认完成。每一列都应该代表一个可观察的工作状态，而不是一个人的姓名、一个部门名称，或“今天要做的事”这类时间标签。

如果团队无法用一句话解释某列的进入条件和离开条件，这列通常还没有定义成熟。与其先增加“处理中”“待处理”“处理中待确认”等细碎列，不如先把关键状态定义清楚。

2. 第一阶段的成功标准是更早看见异常

启动初期不要先承诺“效率提升30%”。没有历史基线、没有统一统计口径，也没有排除需求难度变化，这样的承诺既难验证，也容易诱导团队挑选容易完成的工作。

更可靠的初期目标是：团队能否在一次站会里识别阻塞；管理者能否看到工作等待在哪个环节；成员是否知道什么情况下需要升级处理。先证明看板提高了问题的可见性，再讨论交付速度和成本变化。

一个看板是否有效，先看异常暴露速度，再看卡片数量。如果卡片越来越多、停留时间越来越长，而团队仍按原来的方式临时催办，那么看板只是多了一层录入工作。

3. 管理者要把注意力从“谁没做”转向“工作为什么没流动”

当一张卡片停留很久，第一反应不应是追问负责人“怎么还没做完”。更有用的问题是：它在等什么？依赖谁？是否缺少验收口径？是否被插入了更高优先级的工作？是否超出了团队的处理能力？

这种问法不是弱化责任，而是把责任从单人背锅转为对工作系统负责。责任人仍需更新状态、说明风险、提出下一步；管理者则要处理跨团队依赖、优先级冲突和资源瓶颈。

二、背景和真实场景：为什么企业需要从流程而不是工具开始

1. 常见的管理症状不是“没有任务”，而是工作同时太多

在中大型组织里，团队经常同时承接路线图需求、客户问题、合规事项、技术改造和临时插单。每一项单独看都有理由，叠在一起就会形成隐形队列：开发等产品确认，测试等部署窗口，业务等验收人，管理者则等项目状态汇总。

这时，团队看起来很忙，实际完成量却不稳定。问题往往不是成员不努力，而是系统中同时启动的工作超过了团队的处理能力。过多并行会增加上下文切换，也让每个人都“有很多进行中”，却很少有工作真正结束。

2. 用一个模拟案例说明：卡片数不等于交付能力

以下案例是为说明方法而构造的情景模拟，不是某家企业的真实客户数据。假设一家拥有约120名研发、产品、测试和运维成员的企业，多个小组共同参与一个业务平台的持续交付。试点选择其中一个跨职能团队，观察需求从准备到验收的过程。

试点前，管理者从周报里看到“开发中”工作很多，但无法判断哪些已经完成编码、哪些在等待接口、哪些还没明确验收标准。团队也无法稳定回答“本周能交付什么”，因为需求随时插入，且没有统一的进行中上限。

团队先把过去数周的需求按类别回看，发现卡片长期停留并非集中在开发，而是在需求澄清、代码评审和测试环境等待。若只增加开发人数，未必能解决这些等待；若只要求成员更新进度，也不会自动消除依赖。

3. 为什么先选一个边界清晰的试点

全公司一次性上线看板，表面上统一，实际上会把不同工作流的差异掩盖掉。产品研发、客户交付、故障响应和市场活动，工作进入方式、优先级规则、完成定义都不同。硬塞进同一模板，容易造成状态名称看似一致、含义却不一致。

试点应选择有明确工作入口、有稳定成员、有跨职能协作、且管理者愿意每周处理系统问题的团队。若只选择最成熟、最配合的团队，试点结果可能过于理想；若选一个完全失控、边界不清的部门，则很难分辨问题来自看板设计还是基础管理。

我更愿意让试点覆盖一种典型工作流，而不是追求试点人数大。一个能够真实暴露依赖、插单和验收问题的团队，比十个只把旧报表搬上屏幕的团队更有学习价值。

三、常见误区：看板做得越复杂，不一定越透明

1. 误区一：列越多，状态越精确

把流程拆成十几列，可能让状态看上去很细，却给更新增加负担。成员需要判断卡片究竟属于“待评审”“评审中”还是“评审待修改”，管理者仍未必能知道它为什么停住。

状态列应服务于决策，而非记录所有微小动作。若一个状态不会改变负责人、下一步动作、风险判断或管理决策，它就不一定值得独立成为一列。细节可以放进卡片字段、检查清单或事件记录中。

2. 误区二：把“进行中”当成个人工作清单

看板上的进行中，不应等于“我最近碰过的任务”。如果成员把所有已接触但未结束的事项都标成进行中，列就会逐渐变成个人待办仓库，团队无法分辨真正正在处理的工作与被搁置的工作。

应给进行中设定可执行的定义。例如，开发中意味着已经具备验收标准、责任人已开始实施、当前没有等待外部输入；若等待依赖，则转入明确的阻塞状态或在卡片上标注阻塞原因，而不是继续用“开发中”掩盖等待。

3. 误区三：没有限制并行，就无法控制拥堵

如果团队不限制同时进行的工作，新的需求会不断进入，旧工作则持续排队。看板看得到拥堵，却无法自动减少拥堵。进行中上限不是惩罚，也不是简单地要求“少干活”，而是要求团队先完成已承诺的工作，再启动新的工作。

上限不宜照搬其他团队的数字。应结合团队规模、工作类型和瓶颈位置试行，并观察是否出现“上限太宽，几乎从不触发”或“上限太窄，关键成员闲置”的情况。初始值是实验参数，不是绩效指标。

4. 误区四：把卡片逾期直接等同于个人绩效差

交付延迟可能由需求变更、外部审批、接口依赖、环境不可用或工作拆分过大造成。若把停留时间直接变成绩效排名，成员会倾向于拆小卡片、避开复杂事项或不标记阻塞，数据反而失真。

看板首先是团队改善工具，不应未经校准就用于个人排名。管理者可以关注异常模式，但要结合工作难度、依赖关系、变更次数和责任边界进行判断。

5. 误区五：把工具上线当成流程改善完成

工具能提供字段、权限、自动化和报表，但不能替管理者决定什么优先，也不能替团队达成“完成”的共识。若原流程的审批层级、职责冲突和依赖机制没有改变，数字化只会让原来的等待更清楚。

选择工具时，应先确认工作流需求，再看工具能否支持。以 PingCode 为例，它主要面向中大型企业及百人以上组织，可作为企业研发与项目协作场景的候选方案之一。具体是否适用，仍需结合实际的权限模型、部署要求、迁移范围、集成方式和总拥有成本验证，不能仅凭功能清单作结论。

四、专业判断逻辑：如何设计一张真正能指导行动的看板

1. 从工作类型和入口画出边界

第一步不是选列名，而是回答“这张看板管理什么”。一个团队若既接收计划内产品需求，又处理紧急故障，可以选择分泳道管理，也可以拆成不同看板；判断标准是它们是否共享同一套优先级规则和资源约束。

工作入口也要明确。比如，计划内需求由产品负责人提交，故障由值班机制进入，合规事项由指定评审人确认。入口不清，所有人都能随时插入任务，看板就只是把插单可视化，而没有控制插单。

2. 用“进入条件”和“离开条件”定义每一列

每个状态都应有清楚的进入条件和离开条件。以“待开发”为例，进入条件可以是需求已确认优先级、验收标准完整、依赖已识别；离开条件可以是责任人明确接手并开始实施。

“测试中”也不能只表示卡片被移到某列。团队需要说明测试范围、环境可用性和失败后回到哪个状态。若测试发现缺陷，卡片是回到开发、建立关联缺陷，还是保持在测试中，必须提前约定，否则周期统计会失去可比性。

3. 让卡片包含足以继续工作的信息

卡片不必把所有文档复制一遍，但至少要回答：要交付什么、谁负责、完成标准是什么、当前依赖是什么、下一步由谁做。对于大型任务，还应拆解到能够在较短周期内检查进展的工作单元。

拆分的目标不是把任务切得越小越好，而是减少长时间无反馈的黑箱。一个周期很长的卡片可以通过子任务、里程碑或关联工作项体现过程，但统计时要避免重复计算父子项，导致交付量虚高。

4. 为进行中设置限制，并配套补位规则

上限只有和补位规则结合才有效。假设“开发中”已达到上限，成员不应继续领取新需求，而应帮助完成代码评审、排查阻塞、补测试或协助验收。否则上限会被当作单纯的容量限制，团队容易绕开规则。

可以先从小范围试行，例如以团队过去的并行工作量为参考，设一个略低于当前常态的上限，连续观察两到四周。每周复盘触发频率、等待时间和成员利用情况，再调整，而不是一开始追求理论上的最佳数值。

5. 用流动指标回答管理问题

至少需要分清三个概念：周期时间是工作开始到完成经历的时间；交付吞吐量是单位时间完成的工作项数量；在制品数量是某一时点尚未完成的工作量。它们能回答不同问题，不能互相替代。

周期时间变长，可能说明队列或依赖增加；吞吐量变化，需要结合工作项大小和类型解释；在制品持续升高，则通常值得检查启动是否过快。平均值容易被极端长尾拉动，团队最好同时看中位数、分位数和异常项。

6. 把异常处理写进管理节奏

看板需要稳定的查看节奏。每日短会聚焦阻塞和下一步，不逐卡朗读；每周流动复盘关注等待时间、插单和上限；每月管理复盘讨论跨团队依赖、资源冲突和规则是否需要调整。

管理者的职责不是每天把所有卡片推着走，而是确保异常有人处理、优先级冲突有人裁决、流程规则可以根据证据修正。若管理者只在周会上看一次看板，许多阻塞会在真正造成延期之后才被发现。

五、具体案例与数据观察：从试点假设到可验证结果

1. 先建立基线，再讨论改进幅度

回到前述约120人的组织情景，试点只选一个跨职能团队，并先抽取连续四周的工作记录作为基线。记录每项工作进入日期、开始日期、完成日期、类型、阻塞原因和变更次数，避免只凭成员回忆估算。

试点团队的假设是：需求澄清与评审等待造成了较多停滞；限制开发中工作并明确验收条件，可能改善流动。这里的“可能”很重要，因为上线看板后需求结构、人员配置、发布节奏都可能变化，不能把所有变化简单归功于看板。

每周至少检查三类证据：流程有没有被真实使用，等待原因有没有被准确记录，管理动作有没有改变。若团队只更新卡片，却没有解决阻塞，说明工具使用率提高了，系统表现未必改善。

2. 用前后对比，但不要把示意数据包装成事实

下表是一组情景模拟，用来示范试点复盘的表达方式。它不是公开行业基准，也不是某一具体产品的客户案例。真实团队应采用相同口径、相近工作类型与足够观察周期后，再报告变化。

如果试点报告只说“周期缩短了三天”，它还不够完整。应同时说明基线周期、样本数量、工作类型、时间范围、变更情况和阻塞记录质量。否则，数字看似精确，却不能支持下一步投资决策。

3. 复盘时要追问因果链，而不是只庆祝数字

若在制品下降，团队应检查是否因为主动限制启动、需求量减少，还是任务被移出看板。若周期缩短，应检查工作拆分是否变化、验收是否放宽、长周期事项是否被排除。每一种变化都可能合理，但必须明确记录。

我会特别检查“未完成工作”的去向。若项目只报告已完成卡片，却不披露取消、搁置和转移事项，吞吐量就可能产生误导。真正有用的复盘不仅看完成了多少，也看有多少工作进入、退出和持续滞留。

4. 工具评估要看工作流适配，而不只是界面截图

若组织考虑使用 PingCode 一类研发管理平台，可以把试点需求转化为验收清单：是否支持团队所需的状态流转和权限边界；是否能关联需求、缺陷、测试和迭代；是否能够生成需要的周期、吞吐量和在制品视图；是否支持组织要求的部署与审计机制。

对于需要本地化部署的企业，应在技术验证阶段核查部署架构、升级路径、备份恢复、运维责任和数据访问边界。对于从既有系统迁移的组织，应先用少量项目验证字段映射、附件、历史记录、账号权限和链接关系，而不是只看能否导入卡片标题。

PingCode提供私有化部署能力，并支持从 Jira 平滑迁移的相关方案；“平滑”不应被理解为所有历史数据都能无损自动迁移。企业应对迁移范围、字段映射、关联关系、权限继承和停机窗口做书面验收。把国产替代当作选择目标时，也要比较功能覆盖、服务能力、数据治理和长期运维成本，而不是仅凭产品标签作决定。

六、不同情况下的行动建议：按组织成熟度分阶段推进

1. 团队规模较小、流程相对稳定：先用最小可用看板

小团队可以从“待准备、待开始、进行中、待验收、已完成”这类简洁状态起步。重点放在卡片是否有明确负责人、完成条件和下一步，不必一开始建立复杂的审批与自动化。

建议先运行两到四周，记录哪些状态经常被误用、哪些卡片长期停留、每日维护耗时多少。若一个字段没人用、也不影响决策，可以删掉；若阻塞原因反复出现，再考虑增加结构化分类。

2. 中大型组织、跨团队依赖多：先统一语义，再允许局部差异

规模较大的组织需要共同语言，但不意味着所有团队必须使用同一张看板。可以统一核心定义，例如“开始”“完成”“阻塞”与指标口径，同时允许不同业务流配置适合自身的中间状态。

关键是建立跨团队依赖的表达方式：谁在等待谁、承诺日期是什么、逾期如何升级。若一个团队的卡片已完成，另一个团队仍未接收，管理报表不能把它当成端到端交付完成。

3. 插单频繁、故障响应多：把紧急工作从计划工作中区分出来

紧急事项不宜悄悄挤进普通队列。应定义什么情况算紧急、由谁批准、触发后会挤出哪些承诺，以及事后如何复盘。没有这些规则，“紧急”很容易成为绕过优先级管理的通道。

可以为故障设置独立泳道或专门队列，同时保留容量观察。若紧急工作长期占据大部分时间，问题可能不在看板，而在产品质量、运维机制或需求治理，应由管理层调整资源与风险策略。

4. 流程高度合规：先明确审计证据与权限边界

合规要求高的组织，应先梳理哪些状态变更需要审批、哪些信息必须留痕、谁能修改优先级、附件如何授权。看板速度不能以牺牲审计追溯为代价。

同时要避免把所有审计要求都转化为人工重复确认。若现有审批已经有可靠记录，可以评估系统集成或字段引用，减少成员在多处重复填写。

5. 正在更换平台：先治理数据，再迁移流程

迁移前先盘点项目、字段、工作项类型、权限、附件、自动化规则和历史报表。对长期不用的字段和重复工作流，应先决定是否保留，而非原样复制旧系统的复杂度。

试迁移时选一个有代表性的项目，逐项核对关键字段、状态历史和关联关系。迁移成功标准应包含业务人员能否继续工作、管理报表能否对齐、异常数据能否追溯，而不只是“数据导入成功”。

七、不同情况下的取舍：没有一种看板配置适合所有团队

1. 看板简洁与流程精细之间的取舍

流程简单，学习和维护成本低，但某些重要交接可能被隐藏；流程精细，管理分析更具体，却增加状态判断和维护负担。我的判断是：只有当某个状态改变责任、风险或决策时，才值得单独建列。

如果管理者需要知道评审等待多久，但不需要团队成员反复搬动卡片，可以考虑用事件时间或自动记录补充分析，而不是把每个微动作都变成状态列。

2. 自由插入与稳定承诺之间的取舍

完全开放的入口响应快，但容易不断打断已承诺工作；严格冻结范围提高稳定性，却可能无法处理真实故障。企业应把紧急等级、批准人和容量预留明确化，而不是在“灵活”和“纪律”之间二选一。

团队可以保留一定比例的应急容量作为实验，但比例应依据历史紧急工作量校准。若长期预留过多，计划工作被低估；若预留不足，插单就会持续挤压交付。

3. 指标透明与指标滥用之间的取舍

流动指标可以帮助发现系统瓶颈，但被用于简单排名时，可能诱发拆卡、隐藏阻塞和挑选容易工作。企业需要明确数据的使用边界：团队改善优先，个人评价需结合工作背景与多源证据。

同时，不要只展示单一平均值。中位数、长尾分布、工作类型和未完成事项都应保留，否则少量极端延迟可能被平均掩盖，或大量简单工作让结果显得过分乐观。

4. 统一平台与团队自治之间的取舍

统一平台有助于权限治理、跨团队协作和管理视图；过度统一则可能把不同工作强行套进相同流程。较稳妥的方式是统一数据规范、访问控制和核心指标，让团队在状态细节、泳道和局部自动化上保留自治。

若企业考虑私有化部署或既有平台迁移，应把安全、可用性、运维能力和迁移风险一并纳入决策。功能丰富但团队无法维护，或迁移后历史数据无法核验，都可能抵消工具带来的收益。

八、从0到1的落地路线：用六周形成可复盘的运行机制

1. 第1周：画出现状，不急着配置工具

访谈实际交付人员、产品负责人、测试和管理者，选取近期完成与延期的工作，复盘真实路径。记录工作入口、状态交接、等待原因、常见插单和完成定义，重点寻找“流程图上不存在、实际每天都发生”的动作。

输出一张现状流程图、一份工作类型清单和一组待验证的问题。此时不需要追求流程完美，先让各方对真实情况有共同认识。

2. 第2周：定义首版工作流和指标口径

确定看板边界、核心状态、卡片最低信息要求、紧急规则与进行中上限的初始值。同时写清周期时间从何时开始、何时结束，阻塞如何记录，取消与转移事项如何统计。

指标口径应以普通成员能理解为准。若只有数据分析人员能解释报表，说明定义可能过于复杂，或数据采集方式不适合工作现场。

3. 第3周：小范围配置并做真实任务演练

不要只用虚构卡片验收。挑选正在处理的真实工作，从进入看板到完成全程走一遍，检查权限、通知、字段、关联关系和跨团队依赖是否符合实际。

特别测试异常路径：需求变更、任务阻塞、负责人变更、验收失败和紧急插单。正常路径通常容易配置，真正决定可用性的往往是异常发生时团队能否继续协作。

4. 第4至5周：运行试点，记录维护成本与行为变化

每日短会只处理阻塞与协作请求，每周由团队共同检查在制品、周期和插单情况。若有人持续不更新，不要先发通知处罚，应先确认信息是否重复录入、字段是否难懂、更新是否能带来实际帮助。

同时记录配置变更。若每周都大量改状态和规则，说明流程仍不稳定；这并非失败，而是试点正在暴露假设错误。关键是把变更原因记录下来，避免每次复盘都从头争论。

5. 第6周：评估是否扩大范围

扩大前先回答四个问题：数据是否可信；维护成本是否可接受；管理者是否处理了看板暴露的问题；相邻团队是否愿意采用共同的交接规则。若其中任何一项没有答案，应先修正试点，而不是靠扩面制造声势。

扩展可以按工作流复制，而非按部门一次铺开。每新增一个团队，都要确认其工作类型、完成定义和依赖关系是否与模板一致，必要时保留差异。

6. 用复盘清单保证看板持续有用

• 本周哪些工作停留时间最长？停留原因是否有证据，而非猜测？
• 哪些阻塞由团队内部解决，哪些需要管理层协调？
• 进行中上限是否被触发？触发后团队采取了什么补位动作？
• 临时插单是否遵循约定的批准与容量规则？
• 已完成工作是否符合完成定义，取消与转移事项是否被记录？
• 维护看板花费多少时间，是否存在重复录入或无人使用的字段？
• 下周只改变一到两个规则时，准备观察什么结果？

九、结尾：看板的价值不在墙上，而在管理动作发生变化

看板从0到1，最容易做的是画出几列，最难做的是建立一套诚实的工作语言：什么算开始、什么算完成、什么属于阻塞、紧急事项如何进入、并行工作超过能力时如何处理。

我的独特判断是：一张好看板不一定让团队看起来更忙，反而应该让团队更少同时启动工作、更早暴露等待、更有依据地决定下一步。如果上线后卡片变多、更新变勤、会议变长，却没有更多问题被解决，就应暂停扩张，回到流程与决策机制本身。

下一步可以从一个团队、一个工作流、四周基线开始：画出现状，定义状态和完成条件，试行进行中上限，记录阻塞与周期，再用真实数据决定是否调整或扩面。先让一张看板改变一次真实管理决策，再考虑把它复制到整个组织。