进行中怎么做？企业管理者入门指南：看板从0到1

不少团队的看板上，“进行中”一列总是最拥挤：任务看起来都有人负责，真正能交付的却不多。要让看板从0到1，管理者首先要做的不是增加列、换软件或要求大家天天更新，而是说清楚什么工作可以进入“进行中”、同时能推进多少项，以及卡住后由谁采取什么动作。看板的价值不在于把任务贴出来，而在于让工作流动起来。

一、先讲结论：看板的起点不是画板，而是管理流动

1. “进行中”不是一个颜色标签

在不少团队里，“进行中”同时代表已经开始、正在等待、暂时搁置、等审批、等客户反馈，甚至“负责人还没来得及更新”。这些工作状态并不相同，却被放在同一列里，管理者自然很难判断哪里需要支持。

我建议先把“进行中”看作一个需要管理规则的工作区，而不是单纯的状态名称。进入这一列，至少意味着任务已经具备开始条件，有明确负责人，且团队准备投入时间推进；如果它只是等外部反馈，应标注为等待或阻塞，而不是假装仍在持续处理。

2. 看板从0到1，先回答四个问题

• 管理什么工作：选定一种边界清楚的工作流，例如市场活动、产品需求或客户交付，不要先把所有部门的任务混成一张板。
• 工作如何流转：画出任务实际经过的阶段，而不是先照搬某个模板的列名。
• 什么可以进入进行中：明确开始条件、负责人、必要信息和可用容量。
• 卡住后如何处理：规定阻塞标识、跟进责任和升级路径，让异常不是“看见了就算处理”。

这四个问题的顺序很重要。先谈工具或看板模板，团队往往会把旧流程原样搬进新界面；先谈工作流和规则，工具才有机会帮助团队看见真实问题。

3. 管理目标应从“任务启动数”转向“完成流动”

如果管理者只关注谁手上有多少任务，团队容易奖励“开了很多工”，而不是“完成了重要工作”。我更愿意先看三个问题：已承诺的工作有多少按期完成？任务在进行中停留多久？有多少时间耗在等待、返工或交接上？这些问题比“大家今天忙不忙”更接近交付结果。

这并不意味着每个团队一开始就要建立复杂指标体系。试行初期，记录在制任务数、完成任务数和阻塞原因，通常已经足以帮助管理者判断流程是否在改善。先让数据能被一致地记录，再讨论用数据做什么决策。

二、看板为什么会失灵：真实场景通常不是缺少一块板

1. 任务都在“做”，没人知道先做什么

设想一个市场团队同时推进内容发布、活动页面、销售物料和客户案例。每项工作都有负责人，也都有截止日期。看板刚上线时，团队把所有任务移进“进行中”，状态显得很透明；但一周后，设计在等需求确认，文案在等产品数据，活动页面又被临时需求插队，真正的交付顺序仍由聊天消息和临时会议决定。

这种情况下，看板并非没有信息，而是信息没有连接到决策。管理者看见了任务，却没有定义优先级如何影响队列，也没有约定遇到冲突时谁来取舍。于是团队继续多开任务，试图通过“每件事都先动起来”降低被追问的压力，结果每件事都更慢。

2. 状态名称相同，团队理解却不相同

“进行中”可能被甲理解为“已经分配”，被乙理解为“开始实际制作”，被丙理解为“只要任务没完成就放这里”。这不是成员不配合，而是状态没有可操作的定义。若状态含义模糊，数据看似完整，管理判断却会建立在不同口径上。

解决办法不是要求大家“认真维护”，而是用具体工作说明进入与退出条件。例如，内容任务只有在选题确认、目标读者明确、资料责任人落实后才能进入制作；提交审核后则移入“待审核”，不再继续占用制作阶段的容量。

3. 跨团队依赖被误认为个人执行慢

任务停留时间长，不一定是负责人效率低。它可能在等法务意见、数据权限、供应商交付或另一个团队的排期。如果管理者只按负责人追问，很容易让实际解决不了依赖的人背上压力，反而错过了真正需要协调的环节。

我会先把“任务由谁做”与“任务由什么条件卡住”分开记录。负责人对推进负责，不等于负责人能单方面消除所有依赖。看板应该帮助团队暴露跨团队等待，而不是把协作问题转化为个人责任标签。

4. 工具更新了，工作规则没有变

数字看板可以减少信息分散，但不会自动替团队决定优先级、定义完成或解决资源冲突。若原来靠口头插单，现在只是把插单写进系统；原来没有验收标准，现在只是新增一个“待验收”列，问题仍会留在流程里。

因此，是否换工具应晚于流程边界的澄清。即便使用电子看板，也要先确定哪些信息必须记录、哪些状态代表真实工作阶段，以及什么情况下需要管理者介入。

三、拆解常见误区：看板做得复杂，不代表管理更成熟

1. 误区一：列越多，流程越清晰

把每个细小动作都设成一列，看起来精细，实际可能让成员花更多时间搬动卡片，却没有更快地发现瓶颈。判断要不要增加一列，可以问：这个阶段是否有独立的责任人、等待原因或管理动作？如果答案都是否定的，它可能只是把同一件事切得更碎。

列太少也会带来问题。例如把“制作、等待审批、客户确认”统统放入“进行中”，团队无法区分实际工作和外部等待。合适的颗粒度不是固定数量，而是能让团队据此采取不同动作的最少状态数。

2. 误区二：限制在制工作等于限制个人产出

在制工作限制（WIP limit）约束的是团队同时推进的工作量，不是给每个人设定“最多只能干几件事”的绩效上限。它的目的，是避免团队不断开新工作，却没有容量把已有工作收尾。

若任务复杂度差异很大，单纯数卡片可能不公平。一张小修订和一项跨部门交付不能被当作相同工作量。因此，限制值要结合任务类型、团队技能和实际等待情况来试行，必要时把大任务拆成可验收的工作项，而不是直接给每个人定一个统一数字。

3. 误区三：每天更新状态，就等于持续改进

更新看板只是在维护事实，不等同于改善流程。如果任务连续几天停在审批环节，团队每天把日期改一遍，却没有识别审批人、处理时限或升级机制，信息更新并没有改变交付结果。

管理者需要把看板检查从“谁没更新”转向“哪种等待反复发生、下一步谁有权消除它”。对于偶发阻塞，协调一次可能足够；对于重复出现的阻塞，应追问流程设计、容量配置或决策权是否存在问题。

4. 误区四：看板数据可以直接用于个人绩效排名

任务数量和停留时间受工作复杂度、依赖关系、优先级变化以及验收口径影响。把它们直接拿来比较个人，容易诱导团队拆小任务、回避难题或把等待时间从板上隐藏起来。

看板初期更适合用于团队流程诊断。若组织确实需要评价个人表现，应结合岗位职责、工作难度、协作贡献和结果质量，不能把“卡片移动得快”当成唯一标准。

5. 误区五：第一次试行就追求全公司统一

企业可以统一数据定义、权限要求和必要的协作原则，但不同工作流未必应该使用同一组状态。客户交付可能有实施与验收，内容运营可能有编辑与发布，行政审批则可能有申请、核验和批准。统一模板太早，容易让真正差异被隐藏。

更稳妥的做法是先选一个边界清晰的团队跑通流程，再区分“可以共享的原则”和“必须因工作类型而异的状态”。

四、专业判断逻辑：从一类工作搭出可用看板

1. 先选定一条价值流，不从组织架构开始

管理者常按部门建板，但任务实际交付可能横跨多个团队。更有用的起点，是选择一类从提出需求到交付结果的工作，例如“新活动从立项到上线”或“客户问题从受理到关闭”。这能让团队看到工作经过了哪些环节，而不只是每个部门各自做了什么。

选范围时，我会检查三点：是否有相对稳定的工作类型；是否能找到对流程负责的人；是否能在一段合理时间内观察到任务移动。如果范围太大，变化因素太多，团队很难判断改动效果来自哪里。

2. 画出实际流程，再删去没有管理意义的状态

请成员回忆最近完成的几项工作，按真实经历列出阶段。不要从理想流程开始，因为理想流程容易遗漏返工、补资料、等确认等常见环节。画出实际流程后，再讨论哪些阶段需要单独呈现，哪些可以合并。

每个状态都要回答两个问题：工作凭什么进入？满足什么条件才离开？如果团队无法给出清楚答案，这个状态可能需要重新定义。以下表格可作为讨论起点，实际名称应根据团队工作调整。

3. 把任务卡片设计成协作接口，而不是资料仓库

一张卡片的字段越多，不代表信息越有用。初始阶段可先包含任务名称、负责人、优先级、目标日期、验收条件和当前阻塞。其他字段只有在能帮助排优先级、推进协作或复盘时再增加。

描述要让接手的人知道下一步行动，而不是只留下项目名。例如，“完善活动页”很难判断是否已具备开始条件；“根据已确认的活动规则完成首屏文案和报名入口说明，由市场负责人验收”则更容易协作。

4. 为“进行中”建立进入、退出和例外规则

可以把规则写成简短的团队约定，而不是厚重流程文件。进入条件说明什么工作可以占用团队执行容量；退出条件说明什么算交付到下一阶段；例外规则则说明紧急任务如何插入、谁能批准，以及插入后哪些事项需要顺延。

如果紧急任务总是被口头插入，优先级系统形同虚设。建议为插单保留明确决策权，并记录插单原因。团队不必禁止所有临时工作，但要让临时工作产生的取舍可见。

5. 从小范围试行中校准WIP限制

不要凭空设一个看似科学的固定数字。先观察团队在正常工作周期中同时推进多少项工作、哪些任务经常等待、哪些成员承担了瓶颈环节，再设一个可讨论的试行上限。

如果上限经常被突破，不要只要求成员“遵守规则”。要查明是优先级变动过多、紧急工作没有入口，还是任务拆分过大、跨团队依赖无人协调。限制值是用来暴露容量和流程问题的，不是用来掩盖问题的。

6. 定义阻塞处理机制，不让红色标记成为装饰

阻塞任务至少需要有原因、下一步动作和责任人。原因可以是等待审批、缺少输入、外部依赖、资源冲突或技术风险；下一步动作要具体到“由谁在何时联系谁”或“何时提交升级”。只写“卡住了”并不能推动任务前进。

团队还应约定阻塞多长时间需要升级。时限不必一刀切：当天可解决的内部问题，与需要供应商或客户响应的事项，处理方式不同。关键是阻塞不能无限期地躺在板上，管理者也不能只在例会上才看到它。

五、用一个模拟案例演示：从“都在做”转向“知道下一步”

1. 案例边界与观察口径

下面以一个虚构的12人市场团队为例，模拟其用看板管理活动上线工作。案例中的人数、任务量和时间都是为了说明分析方法而设置的情景数据，不代表真实企业调研结果，也不应被当作行业基准。

团队原有流程包括需求收集、内容制作、设计、业务确认和上线，但这些阶段没有统一的进入条件。负责人通过聊天工具接收新任务，活动临近时经常插单；任务即使在等业务方确认，也继续放在“进行中”。管理者能看到忙碌，却无法判断哪些任务真正消耗团队时间。

2. 第一步：先把工作流显出来

团队将看板拆成“待评估、待开始、进行中、等待确认、待发布、已完成”几个状态。把等待确认单独列出后，制作工作已经结束、但业务方尚未给意见的事项不再占据制作中的位置。

团队同时给任务卡片补上验收条件、负责人和目标日期。对于未明确受众、缺少活动规则或尚未确定审批人的需求，先留在待评估，而不是为了“显得启动快”直接送进执行阶段。

3. 第二步：观察进行中的停留和阻塞

试运行期间，团队每周只做两类检查：一是进行中任务是否超过约定上限；二是等待或阻塞事项是否有明确的下一步动作。管理者不以卡片数量评价个人，而是查看是否存在大量等待业务确认、反复返工或临时插单。

情景模拟中的起始记录显示，某周有14项任务被标记为进行中，其中5项实际上在等确认，3项缺少完整资料。这个观察提示团队：单纯增加制作人员未必能解决问题，先改善需求确认和输入质量，可能更直接。

4. 第三步：用完成记录检验规则有没有作用

团队连续记录四周的完成任务数、平均周期和阻塞任务数。这里的“周期”统一定义为任务进入进行中到满足验收条件的时间；等待任务仍计入周期，以免把真实等待从数据中剔除。若一个任务跨越周末，团队需要提前约定按自然日还是工作日计算，并始终采用同一口径。

这组情景数据只能说明一种分析路径：看板规则改变后，管理者应检查多个相关指标，并追问过程发生了什么变化。不能把“数字变好”直接写成看板带来某个固定比例的效率提升；任务复杂度、需求量和人员配置变化，都可能影响结果。

5. 案例里真正有价值的，不是“提升了多少”

案例最值得复用的不是模拟结果，而是管理动作：等待状态被区分，开始条件得到确认，阻塞有责任人，结果用统一口径记录。即使完成量没有立即增加，这些动作也能让管理者更早看见风险，并把讨论从“为什么还没做完”转向“哪个条件尚未满足”。

如果试行后周期变长，也不一定说明看板失败。团队可能刚开始如实记录等待时间，过去被隐藏的瓶颈终于进入数据；也可能是任务范围扩大、验收标准变严格。判断变化时，先解释数据生成过程，再决定要不要调整规则。

六、不同情况下怎么行动：按团队成熟度选择起步方式

1. 小团队、工作类型单一：从白板或轻量电子板开始

如果团队人数不多、工作路径相对稳定，可以先使用最简单的列和卡片。重点不在于功能多，而在于所有成员能否快速看到待办、进行中、等待和完成状态。

建议每周挑固定时间回顾一次：哪些任务长期停留？新任务为什么插入？哪些工作经常返工？此时不必追求复杂统计，也不必为每个任务建立大量字段。先确认规则是否被理解，再决定要不要扩展。

2. 多团队、依赖频繁：优先设计跨团队交接规则

如果工作经常经过产品、研发、法务、运营或客户团队，单部门看板只能显示局部忙碌。管理者应明确交接时需要提供什么信息、接收方何时确认、超时后由谁协调，并让等待状态有可见的责任归属。

组织规模扩大后，团队可能还需要统一任务编号、权限、审计记录、数据管理和跨项目视图。比如面向中大型企业或100人以上组织的项目管理平台，通常更适合评估多团队协作、权限管理、流程配置和部署方式；选择时应以实际需求和验证结果为准，不要只看功能清单。

3. 合规或数据边界严格：把部署和治理放在早期评估

金融、制造、政企或有严格数据治理要求的组织，除了看板功能，还应核对数据存储位置、访问控制、日志审计、备份恢复、接口管理与运维责任。若需要私有化部署，应将基础设施、升级维护、权限治理和应急响应一并纳入评估，不能只把“支持部署”当作选型结论。

以PingCode为例，若团队正在评估这类项目管理平台，可以将其作为候选对象之一，并直接向厂商核验当前版本的部署方案、适用组织规模、权限与审计能力、服务边界及迁移支持。是否适合中大型企业或100人以上组织，应由实际需求、演示验证和合同范围共同判断，而不是仅凭一句产品定位作结论。

4. 从其他系统迁移：先验证流程映射，再批量搬数据

迁移前先选一条典型项目做小范围演练，检查任务字段、状态流转、附件、评论、历史记录、权限和关联关系是否能保留。若从Jira迁移，应确认具体版本、数据结构、插件依赖和迁移工具支持范围，并要求供应方说明哪些内容可以平滑迁移、哪些需要人工处理。

“国产替代”也不应只被理解为替换软件名称。管理者还要比较功能覆盖、数据治理、服务响应、部署方式、总拥有成本和团队学习成本。一个能承接真实流程、降低迁移风险的平台，比宣传语更值得关注。

5. 工作高度不确定：先管理决策节奏，不要过度设限

探索性研发、突发响应或需求快速变化的团队，任务优先级可能经常调整。此时仍可使用看板，但要保留应急入口、明确决策人，并记录插单带来的延期影响。限制在制工作可以帮助团队看清过载，不应阻止必要的高优先级响应。

如果工作每周都大幅变化，先稳定需求入口与优先级讨论，再逐步建立WIP限制。否则团队会把规则看成妨碍响应的行政要求，绕过看板的行为也会增加。

七、不同情况下的取舍：规则、速度与治理不可能一次全要

1. 列少还是列细：可视性与维护成本之间取舍

流程短、团队小，状态少通常更容易维护；交接复杂、等待频繁，增加状态可能帮助识别瓶颈。判断依据不是“行业模板有几列”，而是新增状态能否带来不同的处理动作或责任归属。

如果某一列长期没人使用，或者成员无法一致判断任务是否符合进入条件，考虑合并或重新定义。若多个不同等待原因反复出现，则可先用标签区分原因，不必立刻为每种原因新建一列。

2. 统一模板还是团队自治：治理一致性与业务适配之间取舍

企业需要一定程度的统一，否则跨团队报告和管理审计难以进行。但统一的重点应是数据口径、权限底线、关键状态定义和治理要求，而非要求每种工作都按同样路径流转。

可以采用“共同底座加团队扩展”的方式：所有团队使用可映射的基本状态和共同指标，同时允许工作流增加符合自身业务的阶段。管理者应定期检查这些差异是否真实反映业务，而不是各团队随意命名导致无法协作。

3. 自动化还是人工复核：处理效率与错误放大之间取舍

任务创建、提醒、状态同步和报表生成适合在规则稳定后逐步自动化。若优先级和状态定义还没统一，自动化只会更快地传播错误：任务被错误地标记为完成、通知发给不相关的人，或报表把等待时间从统计中排除。

我的建议是先让团队连续使用一段时间，确认规则稳定、例外明确，再自动化重复且低风险的动作。涉及审批、权限和客户承诺的自动流转，应保留人工确认或可追溯的回退机制。

4. 看板数据还是管理对话：量化能力与解释能力之间取舍

数据能提示异常，却不能单独解释原因。周期上升可能来自任务变大、审批积压或需求变更；完成量下降可能是团队处理了更复杂的交付。管理者要同时看数据口径、任务构成和实际发生的工作，避免把指标当成结论。

适合初期的指标通常是少而稳定：在制任务数、完成量、周期、阻塞原因。若这些指标尚未被一致记录，不要急于增加吞吐效率指数、个人评分或跨团队排名。

八、试行后的复盘与下一步：用小改动验证看板是否真正有用

1. 复盘周期不必照搬，但问题要固定

可以先运行两到四周作为试行窗口；这只是便于观察的建议，不是唯一正确周期。工作周期较短的团队可能更快发现问题，长周期交付团队则需要更长时间观察。无论选择多久，都应提前约定复盘问题，避免会后只留下“继续优化”。

• 哪些状态经常被跳过？跳过是规则不合理，还是团队没有理解？
• “进行中”里的任务，多少项在实际推进，多少项处于等待？
• 阻塞主要来自需求不完整、审批、资源、跨团队依赖，还是优先级变化？
• 任务是否经常返工？返工原因是否可以在进入执行前被发现？
• 在制工作限制是否帮助团队完成旧工作，还是造成不合理的等待？

2. 每轮只改少数规则，留出观察窗口

若一次同时更改列名、验收规则、优先级、人员配置和工具，结果变好或变差都难以解释。每轮可以挑一两个最明显的问题改进，例如先明确进入进行中的条件，再观察任务等待和返工是否变化。

改动前记录基线，改动后用同一口径比较，并标记同期发生的人员、需求或业务变化。这样做不一定能证明严格因果，但能避免把所有变化都归功于看板。

3. 用“团队能否更早采取行动”判断价值

看板价值不只体现在任务完成得快不快，也体现在风险能否更早被发现。若团队能提前识别审批积压、及时协调依赖、减少无效开工，即使短期完成量没有明显变化，管理透明度和决策质量也可能已经改善。

反过来，如果看板每天都更新，但管理者仍要靠私聊追问才能知道任务状态；如果进行中任务不断增加，阻塞没有责任人，复盘也不产生规则变化，那么工具使用率再高，也不能说明看板已经落地。

4. 下一步从一张真实的工作看板开始

企业管理者可以在本周完成一个小行动：选定一类近期反复出现的工作，邀请实际参与者画出它从提出到验收的真实路径，然后共同定义进行中的进入条件、阻塞处理方法和完成口径。先让一条工作流可见，再考虑扩大范围或更换工具。

我的核心判断是：看板不是“任务展示屏”，而是团队约定如何启动、推进、等待、验收和改进工作的可视化机制。真正的从0到1，不是从空白画布到填满卡片，而是从“大家都很忙”走到“我们知道哪项工作该先完成、卡在哪里，以及谁能帮助它继续流动”。