看板如何做好进行中？项目成员制度设计与操作步骤

项目看板最容易失真的一列，往往不是“待办”，而是“进行中”：卡片越来越多，更新时间越来越旧，成员都说自己在推进，却没人能准确回答哪些工作真正开工、哪些正在等人、哪些已经卡住。要把“进行中”管好，关键不是催大家勤更新，而是把进入条件、责任边界、在制上限、阻塞处理和完成标准写成一套团队都能执行的规则。

看板如何做好进行中？项目成员制度设计与操作步骤

一、核心结论：把“进行中”从状态栏变成协作协议

1. 一张卡片进入“进行中”，意味着团队作出了明确承诺

我设计看板规则时，会先问一个具体问题：如果现在有人把一张卡片拖进“进行中”，团队其他成员能否据此判断工作已经启动？如果答案是否定的，这个状态就只是一个标签，而不是可靠的管理信号。

状态进入至少应该意味着：工作目标和交付物已经说清楚；主责人已经确认；启动所需的输入、权限或前置工作基本具备；团队知道下一步要做什么。并不是每个任务都必须满足相同的细节，但成员至少要能从卡片上看出“谁在推动、推进到哪、下一步是什么”。

2. 管“进行中”不是盯人，而是让工作流中的问题浮出来

如果成员已经把任务写清楚、及时暴露阻塞、按约定交接，任务仍然停滞，问题可能在等待审批、跨团队依赖、优先级冲突或资源不足。制度的目的，是让这些约束及时可见，而不是把所有延误归咎于卡片负责人。

最实用的检验标准，不是看板上有多少张卡片，而是团队能否快速回答三件事：工作卡在哪里、谁来推动下一步、如果不处理会影响什么。如果这三件事说不清，增加状态颜色、提醒次数或日报频率通常只是增加维护负担。

3. 先明确规则，再讨论工具；先解决等待，再追求更细的管理

看板软件能帮助团队展示状态、负责人、期限和阻塞信息，但它不能替团队决定“什么叫开工”“谁有权插单”“等待多久需要升级”。这些决定必须先形成协作约定，再由工具承载。

实践中我更愿意先用一页规则说明和一个小范围试点验证流程。规则能被成员复述、卡片字段能支撑日常协作，比一次性搭出十几种状态、数十个必填字段更重要。

二、背景与真实场景：为什么“进行中”会越堆越多

1. “已认领”常被误当成“已开工”

不少团队把负责人接下任务、参加过启动会，甚至在卡片上写了姓名，都算作“进行中”。但认领只是责任确认，不等于工作已经开始。任务可能还在等需求澄清、设计稿、测试环境、审批或其他团队提供资料。

当这些状态都挤在“进行中”里，管理者看到的是一排正在推进的工作，成员实际面对的却可能是一半在做、一半在等。此时看板无法准确反映团队负荷，也很难分辨新任务是否应该进入。

2. 卡片缺少“下一步”，更新状态就没有协作价值

“处理中”只能说明某种状态，不能说明工作如何向前移动。比如“接口联调中”可能意味着工程师正在验证，也可能意味着测试账号没有开通；“等反馈”也可能没有写清楚等谁、等哪项反馈、何时再跟进。

我通常会把“下一步动作”视为进行中卡片的必要信息之一。它不必写成详细日报，一句话就够：例如“今天请业务确认字段口径，若下班前未回复，由主责人联系需求负责人”。有了动作和时间点，卡片才能帮助团队协调。

3. 案例推演：同一列里，实际存在四种不同状态

下面是一个项目团队的情景模拟，不代表某家企业的实测数据。团队看板上有20张“进行中”卡片，逐张核对后发现：11张确实有人在做，4张在等待外部输入，3张已完成但未验收，2张近期没有明确动作。表面上看团队同时做20件事，真实的活跃工作却只有11件。

这个例子说明，卡片数量本身无法直接代表团队正在推进的工作量。制度设计的第一步不是限制成员，而是先把“执行中、等待中、待验收、无下一步”区分出来。否则，团队可能误以为需要增加人手，实际需要的却是清理等待和明确验收。

4. 进行中堆积，通常是系统信号，不宜先归因于个人态度

如果多个成员的卡片都卡在同一审批环节，问题很可能是审批机制；如果卡片常因需求反复变化而返工，问题可能是进入开发前的澄清；如果任务频繁被临时插入，问题可能是优先级决策没有明确负责人。

当然，个人没有更新卡片也可能发生，但它只是原因之一。好的制度会让团队能区分“成员没有按约定更新”和“流程让成员无法推进”，而不是把这两种情况都处理成加密检查。

三、常见误区：看板越复杂，不一定越可控

1. 误区一：每张卡片都写了负责人，就算责任清楚

负责人字段只能回答“谁对这张卡片的推进负责”，不能自动回答“谁可以决定优先级”“谁提供输入”“谁验收结果”。如果一张卡片依赖多个角色，却只写一个名字，负责人可能被误解为所有工作都必须由他独自完成。

更稳妥的设计是区分主责人与协作人。主责人负责推动信息透明、组织协作和确认下一步；协作人负责约定范围内的输入或交付。需要跨部门决策时，再明确决策人，而不是把所有相关人都塞进负责人字段。

2. 误区二：一个人只能同时做一件事，才叫控制在制品

WIP（在制工作）限制是用来管理系统中同时启动的工作量，不是给每位成员设置统一的任务配额。任务大小、等待时间、角色分工和团队规模差异很大，“每人只能有一张进行中卡片”不适合作为所有团队的通用规则。

例如，一个工程师可能要等待代码评审，在等待期间转去处理一项短小的维护任务；如果把所有卡片简单计入个人配额，规则可能反而让空闲时间增加。关键是团队是否有足够能力完成已启动工作，以及等待是否正在掩盖真正的瓶颈。

3. 误区三：设置WIP上限以后，超限卡片就自动解决了

上限只能提醒团队“不要继续无条件开新工作”，不能告诉团队应该先处理哪项任务。达到上限后仍然需要判断：能否协作完成已有工作？是否有卡片被阻塞需要升级？是否有低优先级任务应该暂停？是否是紧急工作，需要由有权限的人调整排序？

如果团队没有约定超限后的动作，上限很快会变成红色数字，成员继续把新工作私下接走，或把任务拆成更小卡片绕过限制。制度设计要把“达到上限时怎么办”写得和上限本身一样清楚。

4. 误区四：要求每天更新，等于提高透明度

如果团队规定每天固定时间更新，却没有明确要更新哪些信息，成员可能只改日期或重复写“持续推进”。这种更新对协作没有帮助，还会让看板维护变成额外的汇报工作。

更有效的约定是以事件触发为主：任务开始、状态改变、出现阻塞、发生交接、交付验收或优先级变化时更新。每日同步可以用于发现例外，但不必把重复填报当作透明度的替代品。

5. 误区五：状态越细，项目越容易管理

拆分状态有助于识别真实等待点，但过细会增加移动卡片和解释状态的成本。若团队经常争论“待确认”和“待业务确认”是否应该分成两列，而这些差异又没有引发不同处理动作，就没有必要继续细分。

一个简单判断方法是：新增状态是否能改变下一步的责任人、处理动作或升级时机？如果不能，先不增加。状态应服务于决策，不是把每种口头说法都变成一列。

四、专业判断逻辑：制度要覆盖进入、推进、异常和退出

1. 进入条件：开始之前，先确认工作具备可执行性

一张卡片进入“进行中”前，至少要能够回答四个问题：目标是什么、交付物是什么、主责人是谁、眼下第一步是什么。对有明显依赖的任务，还要检查所需输入是否已到位，或是否已经明确由谁在什么时间提供。

有些团队还需要在开始前确认优先级和验收人。并非所有字段都必须设为软件里的必填项，但团队应明确哪些信息缺失时不能开始，哪些可以在推进过程中补充。

2. 推进条件：每张卡片都要能说出下一步

我建议卡片的进行中信息控制在足够协作、不过度写报告的范围内。通常包含主责人、当前工作说明、下一步动作和检查时间；如果有外部依赖，再补充等待对象、阻塞原因及所需支持。

检查时间不是承诺最终完成日期的替代品，而是提醒团队何时重新检查进展。对长周期任务，可以用里程碑或可验证的阶段成果降低“一张大卡片长期不动”的风险。

3. 异常条件：把“阻塞”设计成可以触发帮助的信号

标记阻塞时，卡片最好同时包含四项信息：发生了什么、影响哪个结果、需要谁采取什么动作、预计何时复查。只写“被卡住”不能让协作方判断优先级，也无法帮助负责人追踪问题是否得到处理。

团队还应定义升级条件。例如，依赖方超过约定时间未响应时，主责人先提醒；继续延误并影响关键节点时，再由项目负责人协调。具体时间不应照搬固定天数，而要按任务节奏、风险和外部承诺设定。

4. 退出条件：完成要依据验收标准，而非主观感觉

“已提交”不一定等于“已完成”。任务可能还需要评审、测试、业务确认或发布验证。团队可以把工作流设计为“处理中，待评审，待验收，完成”，也可以保留少量列、用卡片字段表示评审状态，关键是所有人知道何时能离开进行中。

完成标准应能被观察和验证。例如，交付文件已提交并通过指定角色确认；测试结果满足约定条件；上线事项完成必要验证。标准不必写得很长，但不能只写“做好”“完成开发”这类无法判断的词。

5. 判断WIP上限：先观测现状，再通过小步调整验证

我不建议团队在没有基线的情况下直接选一个“看起来合理”的数字。先观察一个有代表性的工作周期：每天活跃执行的卡片数、等待中的卡片数、周期较长的卡片、卡片从开始到完成的大致时间，以及中途插入的工作量。

随后选择一个便于讨论的试行上限。它不是永久规定，而是一个实验条件：达到上限时，团队先协作清理现有工作，不自动启动新的普通任务；如果必须插单，则说明由谁批准、需要暂停或调整什么。试行后再根据实际积压和交付节奏调整。

6. 不把单一指标当作绩效排名

周期时间、吞吐量、在制数量和阻塞时长都可以帮助团队观察系统，但不能脱离工作类型和质量要求比较个人。若只奖励完成卡片数量，成员可能拆小任务、回避复杂工作，甚至忽略返工和验收质量。

比较有用的做法是看团队的趋势和分布：完成速度是否更稳定，等待是否减少，长时间未变化的卡片是否变少，交付后返工是否增加。指标用于提出问题，不应该自动替代讨论和判断。

五、操作步骤：从现有看板到可执行制度

1. 第一步：盘点真实工作流，不要先照搬模板

找出工作从需求提出到验收完成的实际路径，询问成员任务通常在哪些环节等待、哪些信息经常缺失、什么情况下会被插单。不要只画理想流程，也要记录团队实际发生的返工、暂停和跨角色交接。

盘点可以从最近一个工作周期的卡片开始。抽样检查卡片的负责人、最后更新时间、阻塞原因、验收情况和下一步动作，比开一场只讨论“理想状态”的会议更容易发现规则缺口。

2. 第二步：用最少字段支撑协作

建议先保留任务目标、主责人、优先级、当前状态、下一步动作和验收条件。对等待依赖明显的团队，再增加等待对象、阻塞原因和复查时间；对有严格节点要求的项目，再增加计划日期或里程碑。

每个字段都要有明确用途。若成员填了字段后没有人阅读、没有触发处理动作，也不影响排序或验收，可以考虑删除或改成可选项。字段越多，维护成本越高；真正有用的字段应能帮助成员作出下一步决策。

3. 第三步：为每个状态写清进入与退出条件

不必为每一列写长篇说明，但应让成员知道何时移动卡片。例如，进入进行中意味着已经开始实际工作；进入待验收意味着交付物已提交并明确验收人；进入完成意味着达到约定的验收标准。

如果团队对状态理解不同，先拿几张真实卡片现场判断，而不是只在文档里讨论抽象定义。让不同角色独立判断卡片该放在哪一列，分歧最多的地方通常就是最需要补规则的地方。

4. 第四步：写成员协作约定，明确谁做什么

成员制度不必写成考勤条例。它更像团队对协作行为的共同承诺，包括谁维护卡片、谁决定优先级、谁负责响应阻塞、什么情况需要交接、什么情况下可以插入紧急工作。

主责人负责让卡片信息可信，并推动约定的下一步；项目负责人或指定角色负责优先级冲突和跨团队协调；验收人负责按标准确认交付。角色可以兼任，但职责不能含糊。

5. 第五步：确定超限、插单和暂停的处理方式

达到WIP上限时，优先完成或协作推进已有工作。必须插入的紧急任务，应由有权限的角色确认等级，并说明对应的取舍：暂停哪项工作、哪项交付可能延后、是否需要重新安排资源。

暂停或取消的卡片应保留原因和决定信息，不要直接从看板删除。这样团队回看时才能分清任务是已经完成、被取消、被替换，还是单纯遗忘。

6. 第六步：小范围试行，按问题而不是按感觉复盘

选择一个项目或一支团队先试行一到两个工作周期。试行期间重点观察：卡片是否更容易看懂，等待问题是否更早暴露，超限时团队是否能作出取舍，更新信息是否增加了无效负担。

复盘时不要只问“大家喜不喜欢”，而要拿具体卡片验证：哪张卡片的信息帮助了决策？哪条规则没有被执行，原因是什么？哪些字段没人使用？如果删掉一个规则，风险会变大还是维护会变轻？

7. 将规则写成能直接使用的团队约定

规则文本宜短，便于团队成员在工作中查阅。可以从下面的模板开始，再按工作流删改，不必逐字照抄：

卡片开始实际处理后，才进入“进行中”。

每张进行中卡片填写一名主责人，并写清当前下一步动作。

状态变化、出现阻塞、发生交接或优先级调整时，及时更新卡片。

阻塞卡片说明原因、所需支持、责任对象和复查时间。

达到团队设定的在制上限后，先评估已有工作，不自动启动新的普通任务。

紧急插单由指定角色确认，并记录对应的暂停、延期或资源调整。

达到约定验收条件后，卡片才能进入完成状态。

规则先试行，复盘后调整；指标用于发现系统问题，不用于简单排名个人。

六、案例推演：一张卡片如何从开工走到验收

1. 任务背景：制作一份面向用户的上线说明页

以下是情景模拟。任务目标是制作上线说明页，涉及产品负责人、内容撰写人、设计人员和验收人。卡片不能只写“制作说明页”，而应明确交付物、主责人和验收条件，例如“说明页发布到指定位置，功能信息与已确认版本一致，并由产品负责人完成验收”。

在进入进行中前，主责人检查功能变更清单是否确认、所需截图是否可用、发布渠道是否明确。如果材料尚未到位，可以先保持待办，或将“收集材料”拆成一个清楚的前置任务；不应把尚未能启动的工作放进进行中，制造虚假的活跃状态。

2. 正常推进：用里程碑和下一步减少大卡片失联

卡片进入进行中后，主责人写明第一步：“整理已确认的功能变化，形成说明页初稿”。当初稿完成，卡片下一步改为“请产品负责人核对功能描述，周三前反馈”。如果工作涉及多个明显交付环节，可以拆分为子任务，但应确保拆分后更容易协作，而非为了增加完成数量。

这类卡片不要求每天复制一段进展。只有当交付物、状态、依赖或下一步发生变化时，更新相关信息即可。团队需要在同步会上讨论时，也可以直接以卡片中的变化为依据，而非让成员重复口头汇报。

3. 发生阻塞：把等待从“没人管”变成可追踪事件

假设撰写人发现关键功能截图尚未提供，卡片应标记为阻塞或转入等待状态，并写明“等待设计同事提供两张最终界面截图；若周二下午仍未提供，由主责人联系设计负责人确认排期”。这条信息说明了原因、需要谁行动以及何时复查。

如果等待时间影响了发布节点，项目负责人应协调资源或调整优先级，而不是只要求撰写人继续“想办法推进”。如果截图没有按时提供，团队也可以决定先发布文字版、调整上线时间或暂缓任务，但必须有人作出取舍。

4. 完成交付：区分提交、验收和关闭

说明页初稿写完后，卡片进入待验收，而不是立即完成。验收人检查内容是否与最终功能一致、截图是否为发布版本、链接是否可访问。发现问题后退回修改，并注明需要修改的具体项目。

满足验收标准后，卡片才进入完成。这样做看似多一个判断步骤，却能避免“文档写完了但没有发布”“已发布但链接错误”等情况被误记为完成。任务的结束标准越清楚，之后的进度复盘越可信。

5. 示例卡片字段与信息边界

七、不同团队的行动建议与制度取舍

1. 小团队或短周期项目：规则少一些，反馈快一些

如果团队人数不多、成员彼此能快速沟通，优先定义进入条件、主责人、下一步、阻塞处理和完成标准。可以先不设置复杂角色矩阵或多层审批，也不必一开始把每类等待单独拆成状态。

这类团队的主要风险通常不是缺少制度文本，而是临时任务太多、负责人边界模糊或卡片长期没人维护。先保证规则简短且可执行，再根据真实问题逐步增加字段或状态。

2. 多团队协作项目：优先明确依赖与升级路径

跨团队项目里，“等待谁”“谁能承诺交付时间”“延误后由谁协调”往往比卡片本身的细分更重要。建议为外部依赖设置责任角色、期望响应时间和升级条件，并让项目负责人能看到哪些等待会影响关键节点。

不同团队如果使用不同的流程，不一定要强行统一所有状态。可以统一必要的协作字段和项目级里程碑，同时保留各团队内部工作流。否则，表面上状态一致，实际含义却不一致，跨团队看板仍然无法比较。

3. 需求变化频繁的团队：优先治理插单和优先级

如果进行中卡片不断增加，常见原因可能是新需求不断被接入，但旧工作没有被暂停。此时应先明确谁有权改变优先级，以及插单需要换出什么工作，而不是先提高更新频率或要求成员加班消化。

可以把紧急工作分级，并明确哪些情况可以打断现有计划。紧急级别应有业务定义，例如安全风险、合规要求或关键客户影响，而不能由“谁催得急”决定。每次插单都留记录，复盘插单来源和对原计划的影响。

4. 高合规或需要审计的团队：提高可追溯性，但避免重复填报

受审计、权限或交付追踪要求约束的团队，可能需要保留状态变更、审批人、版本和验收记录。此时应把必要的留痕嵌入工作流，明确哪些信息必须记录、哪些由系统自动保存，避免成员在多个地方重复填写同一内容。

制度越严格，越要说明例外如何处理。例如紧急修复、临时授权或跨部门替代审批如何留痕。只写“必须遵守流程”而不定义例外，会导致真实工作绕开看板，最后反而降低可追溯性。

5. 选用工具时：看治理边界，不只看看板界面

对规模较小、流程简单的团队，轻量看板往往足够。对成员较多、项目并行、权限复杂或有部署要求的组织，还要评估角色权限、数据治理、流程配置、跨项目汇总和系统集成，避免只比较卡片拖动是否顺手。

例如，PingCode主要面向中大型企业及100人以上组织，产品资料说明支持私有化部署和Jira平滑迁移。对正在评估国产替代或部署方式的团队，这些能力可以列入考察范围；实际是否适配，仍应通过当前产品文档、迁移演练、权限测试和试点验证。工具能承载制度，但不会替团队定义进行中规则。

选型时可用真实场景做验证：建立一张有外部依赖的卡片，演练阻塞标记、责任交接、审批、验收和历史追踪；再测试成员权限和跨项目汇总是否符合需要。演示环境里的标准流程顺畅，不代表复杂项目中的例外场景也能顺畅处理。

6. 取舍判断：什么时候该增加规则，什么时候该删规则

当相同问题反复出现，而且已经影响协作、交付或风险控制时，值得增加规则。例如多次发生未验收即关闭，可以增加完成条件；多次发生依赖方无人跟进，可以增加等待责任和升级路径。

当某个字段长期无人使用、某种状态不改变行动、更新工作明显超过信息价值时，应考虑删减。制度不是越长越成熟，而是让关键行为更可靠，同时把维护成本控制在团队愿意承担的范围内。

下面的比较数据是情景模拟，用来说明试点阶段可观察哪些成本，不代表任何团队的实际效果，也不是保证值。团队可替换为自己的记录口径，重点比较规则带来的新增维护时间，是否换来了更及时的阻塞处理和更清晰的完成判断。

八、试行后的复盘：用趋势判断规则是否真的有效

1. 先看卡片是否更可判断，而不只看卡片是否更整齐

复盘时抽取不同阶段的卡片，检查成员是否能快速判断负责人、下一步、阻塞对象和完成条件。如果卡片颜色统一、字段齐全，却仍然要靠私聊才能知道任务情况，说明看板规则还没有形成有效协作信息。

也可以检查长期未更新的卡片，但不要只把它们当作违规记录。逐张确认是任务已停、等待未标记、验收未完成、优先级改变，还是确实忘记更新。不同原因对应不同的改进措施。

2. 观察结果指标的组合，避免单指标误导

建议从团队层面观察在制卡片数量、完成吞吐、周期时间、阻塞时长、逾期比例和返工情况。单看完成数量可能遗漏质量问题，单看周期时间可能忽略工作复杂度，单看逾期比例也可能受外部依赖影响。

在制品数量上升、周期时间变长、阻塞时长也增加，通常值得进一步检查启动过多或瓶颈堆积。若周期时间增加但返工明显下降，也可能是团队增加了必要的检查，不能脱离上下文直接判定规则失败。

3. 用一次完整复盘决定保留、修改或删除规则

每轮试点结束，可以把规则分成三类：保留，确实减少歧义或漏接；修改，方向有用但触发条件不清；删除，没有带来决策价值，维护成本却持续存在。复盘要写下改变内容、原因和下一轮检查时间，避免规则每次会议都被重新讨论。

如果团队规模、项目类型或监管要求发生变化，也要重新评估制度适用性。小团队验证有效的简单约定，不一定足以支持多个部门的依赖治理；原先适合长期研发项目的字段，也可能不适合短周期运营任务。

九、结尾：看板上的“进行中”，应该让问题更早出现

1. 从三张卡片开始检查，而不是先改造整块看板

现在就从现有看板里挑三张进行中卡片，检查有没有主责人、下一步动作、必要输入、阻塞说明和可验证的完成条件。若其中任何一项缺失，先补信息并询问成员为什么缺失，再判断需要改字段、改流程，还是明确决策权限。

随后选一个项目试行简短规则，观察一到两个工作周期。重点不是证明某套模板正确，而是确认团队是否更早发现等待、更容易交接、更清楚地判断完成，同时没有承担过多重复维护。

2. 真正有效的制度，不是让每个人填得更多

我对看板“进行中”的判断始终是：它不是工作已经开始的装饰性标签，而是团队愿意共同承担的协作承诺。卡片进入这一列，就应该能看见负责人、下一步和工作所需条件；一旦受阻，团队知道谁来响应；达到什么标准，所有人也都能判断它确实完成。

制度的价值不在于限制成员能做多少事，而在于让团队少启动一些无法推进的工作，少隐藏一些真实等待，并把有限的注意力放在最值得完成的任务上。