进行中怎么做？产品经理效率提升：看板从0到1

看板上有 12 张卡片都标着“进行中”，但没人能说清楚哪几张今天会推进、哪几张在等人、哪几张其实已经停了，这不是看板列得不够多，而是“进行中”没有进入条件、容量边界和异常处理规则。产品经理从0到1搭看板，真正要设计的不是一排状态列，而是一套让工作持续流动、让阻塞及时暴露的协作机制。

一、先讲结论：“进行中”不是状态标签，而是一组工作约定

1. 看板的价值，在于让下一步变得可见

我判断一块看板是否有用，不先看它有多少列、颜色是否整齐，而是看任何一张卡片能不能回答三个问题：现在卡在哪里？下一步由谁做？什么条件满足后可以离开当前状态？如果看板回答不了这些问题，它通常只是任务清单的另一种排版。

“进行中”尤其容易失真。团队成员可能把“我已经开始想这件事”“我发出了一个问题”“我正在等别人回复”和“我正在实际产出”都放进同一列。表面上任务动起来了，实际上工作状态、责任归属和预计交付时间都变得模糊。

我的核心判断是：规则先于工具，流动优先于状态展示。先定义一件工作怎样进入、怎样推进、怎样暂停和怎样完成，再决定用表格、白板还是项目管理平台承载。工具可以降低记录成本，但不能替团队做优先级判断，也不能自动消除依赖和等待。

2. 从0到1，先解决一个具体工作流

不要一开始就把产品规划、版本需求、线上缺陷、运营活动和团队杂事全部放进同一张板。不同工作有不同的入口、验收方式和紧急程度，混在一起之后，团队很难解释“进行中”的数量意味着什么。

更稳妥的起点是选一条工作流，例如“一个版本内的需求交付”，先让这条流转起来，再考虑其他工作是否需要独立看板或不同泳道。第一版看板不需要覆盖全部管理场景，它需要能让团队识别工作、责任、等待和完成。

二、背景和真实场景：为什么任务越多，“进行中”越不可信

1. 产品经理经常管理的是依赖，不只是任务

产品工作通常要经过需求澄清、业务确认、设计评审、研发实现、测试验收等协作环节。产品经理未必是这些环节的直接负责人，却需要让关键决定和依赖可见。任务停在“进行中”时，真正的原因可能不是负责人不努力，而是等一个业务口径、一个接口、一个评审结论，或者一份尚未准备好的数据。

如果只看卡片数量，团队会误以为工作已经全面启动；如果进一步记录阻塞原因和下一步责任人，才看得出实际流动情况。管理者需要的不是更多“进度汇报”，而是更少的状态猜测。

2. “正在做”与“正在等待”不是一回事

设想一个注册流程优化项目：产品方案已经评审，设计稿在制作；设计稿需要业务方确认文案，开发排期也依赖接口方案。此时至少有三种不同状态：设计师正在制作、产品经理正在推动确认、开发任务因接口结论未定而等待。

如果三者都在“进行中”，看板无法反映谁能继续行动。更好的做法不是一味增加细分列，而是先明确状态语义：有主动产出的工作留在“进行中”；等待外部输入的工作标注“等待”；已经无法按当前计划推进的工作标注“阻塞”，并写清原因和跟进动作。

3. 第一版看板的目标不是预测一切

新看板刚上线时，数据通常不完整，任务粒度也不一致。此时不要急着用它预测季度交付，也不要因为某周完成数量少，就简单判断团队效率下降。第一阶段更现实的目标是统一任务状态、暴露等待、找到反复卡住的环节。

我建议把看板当作一套可观察的工作假设：我们认为任务会按某种路径流动；运行一段时间后，再检查实际流转是否符合预期。看板不是一次设计完成的制度，而是团队根据真实工作持续校准的工具。

三、常见误区：看板看起来很满，工作却没有变快

1. 误区一：把所有状态都塞进“进行中”

这是最常见也最隐蔽的问题。团队认为只要有人接手，卡片就应进入“进行中”；但接手不代表已经开工，开工也不代表可以持续推进。结果是“进行中”既包括刚领取的任务，也包括已停滞数日的任务，管理者只能靠追问判断真实进度。

修正方式不是不断拆分列名，而是给状态一个可观察的定义。例如，“进行中”意味着负责人正在执行卡片描述的下一步；“等待”意味着当前需要外部输入；“阻塞”意味着现有条件下无法继续，且需要明确的协调或决策。

2. 误区二：任务越细，管理越精确

将一项需求拆成几十张极小卡片，可能让看板变得更忙，却不一定让交付更清楚。任务拆分的目的不是制造更多更新动作，而是让团队能识别责任、下一步和验收结果。

如果每张卡片都需要频繁维护，团队可能把时间花在改状态和补字段上。相反，过大的任务也会遮蔽风险：一张“完成会员体系改造”的卡片挂在进行中两周，其他人依然不知道它现在到底卡在调研、设计还是联调。

实用的粒度判断是：一张卡片应能说清一个可交付结果和一个近期下一步。如果无法说明下一步，任务可能太大或信息不足；如果任务完成后没有可单独验收的产出，可能拆得过细。

3. 误区三：设置“进行中上限”，却不处理插单

限制同时开展的工作，有助于团队看见过载；但如果领导、销售、运营或线上问题不断插入，原有任务没有被明确延后，容量上限就会变成一条没人遵守的规定。

上限的意义不是禁止紧急工作，而是迫使团队说明代价：新任务现在进入，意味着哪项工作暂停？谁确认优先级变化？受影响的交付对象是否需要同步？没有这些配套约定，团队会在看板上标注一个上限，实际却继续积累隐形工作。

4. 误区四：把状态更新频率当作效率

每天要求每个人多次更新卡片，并不能自动提高交付速度。更新太少会让信息滞后，更新太密则会形成额外负担。应当关注的是信息是否足以支持协作：遇到阻塞时是否及时暴露，优先级变化时是否同步，任务完成时是否有验收依据。

如果团队需要频繁开会才能弄清卡片状态，问题可能不是更新次数不够，而是卡片没有下一步、责任人不明确，或者看板没有覆盖真实工作流。先修正信息结构，再决定更新节奏。

四、专业判断逻辑：从工作流、容量、状态和结果四层搭板

1. 第一层：先确定工作流的边界

搭板前先回答：这块看板管理什么、不管理什么？例如只管一个版本的需求交付，还是同时包含缺陷修复和临时运营事项？边界越清楚，后续统计越有解释力。

接着找出工作真实经过的阶段。建议先从少量阶段开始，例如“待评估，已就绪，进行中，待验收，已完成”，再根据实际等待情况决定是否添加“等待／阻塞”。如果某一列长期堆积，先查它代表的条件是否模糊，不要立即通过新增列掩盖流程问题。

2. 第二层：规定进入条件，而不是只规定列名

“已就绪”应当意味着任务可以开始，而不只是有人把它拖到这一列。团队可以检查目标是否清楚、负责人是否确认、关键资料是否可用、依赖是否可接受、验收方式是否明确。并不是每项工作都要等所有细节完美，但必须知道哪些未知会影响启动。

进入“进行中”前，还要确认负责人确实有容量。产品经理可以在团队例会上检查当前在制任务、近期优先级和临时工作，而不是按卡片数量机械地分配。一个人同时负责多个紧急任务时，卡片上的“负责人”并不能说明这些工作都能并行推进。

3. 第三层：设计任务卡的最少必要信息

字段越多，维护成本越高；字段太少，协作信息又不够。第一版建议保留能支持决策的字段，之后根据真实问题增加，而不是把所有可能信息都放进卡片。

4. 第四层：用团队自身数据调整并行容量

我不建议直接照搬某个固定的“每人最多几张卡”数字。设计任务、研发任务、调研任务的持续时间和协作方式不同；团队人数、工作类型和外部依赖也会改变合理容量。

可以先记录一段时间内每个工作阶段的任务数量、等待时长和完成节奏，再从容易执行的约定开始。例如，团队发现评审任务长期挤在某个阶段，就先限制进入该阶段的数量，或安排固定评审时段。容量规则应当可调整、可解释，并与真实瓶颈对应。

五、案例拆解：一项注册流程优化如何穿过看板

1. 先把模糊需求改成可检查的工作

以下是一个虚拟案例，不代表真实客户项目或实测效率数据。某产品团队收到“优化注册流程”的需求。如果直接建立一张“注册体验优化”卡片并拖到“进行中”，团队很难判断什么算完成，也不知道是产品、设计还是研发正在承担下一步。

产品经理先把目标写清楚：识别注册过程中用户遇到的主要障碍，确定要改动的环节，并交付经过评审的方案和可验收的版本需求。之后再拆出用户问题整理、方案设计、业务确认、开发实现和验收等可识别的工作。

2. 让任务按条件进入，而不是按热情启动

用户问题整理进入“进行中”前，团队约定分析样本范围和输出形式；方案设计进入“进行中”前，确认需要解决的问题、业务约束和评审参与者。这样做的目的不是增加审批，而是避免执行到一半才发现大家对目标有不同理解。

当方案需要业务方确认文案时，卡片转到“等待”，并注明确认人、待确认内容和跟进日期。若确认结果影响研发方案且暂时没有替代路径，就标记为“阻塞”。这两种状态分别说明“正在等一个输入”和“现有条件下无法继续”，处理方式并不相同。

3. 用示例数据看出状态规则带来的差异

为了说明看板字段怎样支持协作，下面使用一组情景模拟数据：项目中有8项工作，其中3项主动执行、2项等待业务输入、1项因接口条件阻塞、2项已完成验收。这里的数字只用于演示看板读法，不应被当作效率对比或行业基准。

这张表没有试图展示“完成了多少百分比”，而是让团队知道下一步由谁推动。对于阻塞卡片，产品经理可以判断是否需要协调接口团队；对于等待业务确认的任务，则要确认跟进时间，避免它悄悄停留在待办或进行中。

4. 复盘关注流动，不把卡片数量当成绩

这个案例的复盘问题应当是：等待时间主要发生在哪里？哪些任务开始时缺少必要输入？阻塞是否有明确的跟进责任？完成条件是否导致返工？这些问题能指导流程调整，比单独比较个人完成卡片数更有价值。

如果一项需求跨越多个团队，卡片停留时间可能受到评审日历、接口排期和决策链路影响。团队需要将这些上下文纳入解释，不能因为某张卡片耗时较长，就直接得出负责人效率低的结论。

六、数据怎么用：从看板记录到可解释的效率观察

1. 先统一统计口径

看板常见的观察指标包括在制任务数、任务从开始到完成的周期时间、阻塞时长、未更新任务数和返工情况。但指标名称相同，不代表统计口径相同。例如，“周期时间”从进入“进行中”开始，还是从需求提出时开始，得出的数值就可能不同。

团队开始统计前，应明确统计对象、起止状态、是否包含等待时间、是否按任务类型分组。若没有这些约定，图表看起来精确，实际却可能把不同工作混在一起。

2. 先看过程信号，再讨论结果

当交付变慢时，先检查在制任务是否堆积、等待是否增加、某个阶段是否形成队列、临时工作是否未登记。它们是可能的原因线索，不是自动成立的因果证明。团队需要回到具体任务，确认数据变化对应的实际事件。

例如，周期时间变长可能是任务更复杂，也可能是外部依赖增多，还可能是团队把“进行中”的起点提前了。只有在任务类型、统计口径和工作条件大致可比时，跨周期对照才有解释价值。

3. 不用指标给个人简单排名

单看个人完成卡片数会鼓励拆小任务，单看周期时间也可能惩罚承担复杂协作的人。更合适的做法是把指标用于发现系统问题：哪个阶段等待最多、哪些任务经常返工、哪些请求绕开了入口、临时插单挤占了多少计划工作。

如果管理者希望讨论个人负荷，应结合任务复杂度、职责范围、依赖数量和协作投入，而不是把看板统计直接当作绩效结论。看板数据首先服务于工作改进，其次才可能成为管理讨论的输入。

七、不同团队怎么行动：先按复杂度选择最小可行方案

1. 小团队或单项目：先用轻量规则跑起来

如果团队人数不多、协作链路短，先用“待处理，就绪，进行中，待验收，完成”即可。为“等待”和“阻塞”增加标签或明确标记，要求进行中任务写负责人和下一步动作。团队规模小，不意味着可以省略状态定义；口头约定一旦被不同人理解成不同意思，规模小也会产生混乱。

每周固定检查一次进行中任务，重点看长期未更新、超出容量和缺少验收条件的卡片。先记录问题，不必第一天就设计完整报表、自动化规则和多层权限。

2. 多团队项目：增加依赖可见性和升级路径

跨团队协作时，同一张卡片可能同时涉及产品、研发、测试、数据和业务接口人。此时要明确谁是当前推动人，谁提供依赖，超过什么约定时间需要升级处理。若“负责人”被理解为所有环节都由一个人完成，任务卡会掩盖真实责任结构。

可以用泳道区分团队、工作类型或优先级，但要避免泳道过多。若成员无法快速判断卡片应该放在哪里，说明分类设计可能超出了看板的实际用途。

3. 中大型组织：把团队级看板与项目级视图分开

在中大型组织中，项目经理、产品经理和不同职能团队可能各自关心不同层次的问题。团队级看板用于管理具体工作流；项目级视图用于识别里程碑、跨团队依赖和风险。试图用一张看板同时满足所有人，容易造成字段过多、状态定义冲突和维护成本上升。

这类组织可以考虑支持多团队协作、权限管理、工作项关联和流程配置的项目管理平台。PingCode主要服务中大型企业及100人以上组织，并支持私有化部署；对于需要从既有平台迁移的团队，其支持Jira平滑迁移的能力可以纳入评估。是否适合，仍应以数据结构、工作流适配、权限要求、迁移验证和团队培训成本为准，不应只依据功能清单下结论。

如果组织有国产化或数据部署方面的要求，也要具体核对部署方式、数据范围、运维责任、升级策略和迁移边界。任何平台的迁移都不只是导入任务：自定义字段、状态映射、权限、附件、历史记录和自动化规则都需要逐项验证。把“支持迁移”理解成“无需治理即可无损切换”，会低估实际项目工作量。

4. 工具选择：先写验收条件，再做演示和试迁移

工具选型可以从团队真实工作出发，列出必须满足的场景：任务流是否可配置、依赖是否可追踪、跨团队视图是否够用、权限是否符合组织要求、历史数据能否迁移、使用成本是否可接受。然后选择一条有代表性的工作流试跑，而不是只看销售演示里的理想路径。

八、不同情况下如何取舍：不要让看板变成另一套负担

1. 流程不稳定时，先少列少字段

如果团队还没形成一致的工作路径，先用少量状态记录实际流转，再观察卡片在哪里反复退回。此时不宜一次性加上审批、子任务、自动提醒和多层分类。流程尚未稳定，过度配置会把错误假设固化在工具里。

2. 风险高、依赖多时，宁可增加可见信息

如果任务涉及多个外部团队、合规审查或关键版本节点，少量额外字段可能值得保留，例如依赖对象、风险说明和计划确认时间。重点是这些信息必须帮助团队采取行动，而不是为了“填完整”而存在。

3. 插单频繁时，优先建立决策机制

如果需求不断插入，首先要约定谁有权调整优先级，以及新工作如何替换现有承诺。看板可以把变化显示出来，却不能替团队决定哪件事更重要。没有决策规则时，任何容量上限都容易被紧急事项冲掉。

4. 数据质量不足时，暂缓精细化分析

如果任务状态经常忘记更新、完成条件含糊，先不要拿周期时间做精确比较。把任务入口、状态含义和完成标准统一后，再逐步引入数据观察。与其用不可靠数据得出看似精确的结论，不如先建立可信的记录习惯。

九、启动清单：用一周做出第一版，再用事实迭代

1. 第一天：选定一条工作流

明确看板要管理的工作类型、团队范围和不纳入的事项。把当前真实流程画出来，不照抄其他团队的列名。先问清楚任务从哪里进入、经过哪些判断、什么结果算完成。

2. 第二天：定义状态与进入条件

为每一列写一句可观察的定义，重点解释“就绪”“进行中”“等待”“阻塞”和“完成”之间的区别。团队成员应能用同一张卡片得出相同判断；若做不到，说明规则还不够清楚。

3. 第三天：整理任务卡模板

只保留负责人、交付物或完成条件、下一步动作等必要信息。任务标题应让不了解背景的人也能大致识别工作内容，避免用“跟进”“优化”“处理”等宽泛词语代替产出。

4. 第四至五天：试运行并记录例外

把一组正在推进的工作放入看板，观察任务是否频繁退回、等待是否被隐藏、是否有任务没有明确负责人。遇到例外先记录，不急着为每种特殊情况新增一列或一条自动化规则。

5. 一周后：复盘一件最值得改的事

选择一个反复出现的问题，例如需求没有准备好就启动、评审等待无人跟进，或进行中任务过多。调整一条规则后继续观察，再决定是否需要增加字段、调整容量或更换工具。

• 看板管理的工作范围是否清楚？
• “进行中”是否意味着实际有下一步行动？
• 等待和阻塞是否能被看见并找到责任人？
• 每张任务卡是否有可检查的完成条件？
• 临时插单是否有优先级调整和工作替换机制？
• 团队收集的数据是否口径一致、足以支持讨论？
• 工具配置是否真的减少协调成本，而不是增加填报负担？

6. 最后的判断：看板不是催进度的墙，而是协作系统的镜子

产品经理搭看板，容易把注意力放在列名、颜色和工具功能上；但真正决定它是否有效的，是团队能否共同解释工作状态，并在工作停滞时知道下一步该做什么。尤其是“进行中”，只有当它代表明确的负责人、正在发生的动作和可见的离开条件时，才有管理意义。

下一步不必先采购工具，也不必先设计一套大而全的流程。选一个真实项目，写清任务怎样进入、谁负责推动、何时算等待或阻塞、什么结果算完成；运行一周后，找出最常见的一种卡点并修正规则。看板从0到1的关键，不是把所有工作都展示出来，而是让团队更早发现哪些工作无法继续流动。