进行中怎么做？研发团队制度设计：看板从0到1

进行中怎么做？研发团队制度设计：看板从0到1

研发看板最容易失真的地方，往往不是“待办”或“已完成”，而是“进行中”：卡片越来越多，负责人都说自己在推进，项目却迟迟没有可交付结果。我的判断是，团队从0到1搭看板，第一步不是选工具、画列，而是先统一三件事：什么条件允许任务进入进行中，遇到等待和阻塞时如何标记，什么标准才算真正完成。

一、先讲核心结论：看板管理的对象是工作流，不是卡片数量

1. 看板制度要回答三个可执行的问题

如果团队成员对“进行中”的理解不同，看板即使每天更新，也无法让项目状态变得可信。有人把刚分配到手的任务放进进行中，有人等到开始写代码才移动卡片，还有人把等待评审的工作继续放在进行中。列名相同，背后的工作状态却不同。

因此，我设计看板制度时，先不讨论颜色、标签和自动化，而是要求每个状态都能回答三个问题：任务满足什么条件才进入这个状态？当前负责人要做什么？满足什么条件后可以离开？如果这三个问题答不清楚，看板的状态列就只是装饰。

“进行中”不是“我接到了”，而是“我已经开始处理，并且知道下一步如何推进”。这是整套制度的中心判断。接单、排队、等待输入、等待评审，都可能是任务生命周期中的真实状态，但不应一律被混进“正在处理”。

2. 从最小制度开始，先保证信息可信

初建看板时，制度不宜一开始就追求完整。对多数研发团队，先明确工作流边界、状态规则、卡片最小字段、负责人和阻塞处理方式，已经足以形成一版可运行的制度。字段越多不代表管理越成熟；如果成员不知道哪些字段必须更新，或者更新成本超过实际协作价值，信息很快就会失真。

我建议把制度写成一页纸，而不是一份厚重的流程文件。成员能在几分钟内找到“怎么进入进行中”“卡住了怎么办”“什么情况算完成”，制度才有机会被使用。规则运行一段时间后，再根据真实问题增加字段和流程。

二、背景和真实场景：为什么“进行中”会变成任务收纳区

1. 状态定义不同，项目进度就会出现多种版本

考虑一个示意场景：某研发团队有产品、开发、测试和运维协作，项目看板只有“待办、进行中、已完成”三列。需求澄清后，产品把卡片移到进行中；开发认为还没排到自己，任务仍在待办；测试看到版本已经部署，却发现验收环境不可用。几个人都在描述真实情况，但项目负责人无法从看板判断工作到底停在哪里。

这个场景的问题不是团队缺少责任心，而是看板把不同性质的状态压在同一列里：已分配、正在执行、等待依赖、等待验证混为一体。管理者看到的“进行中”数量因此既不是实际工作量，也不能说明交付进度。

要修正这种情况，不一定需要把看板拆成十几列。更重要的是明确状态的含义，并决定哪些等待必须显式呈现。列的多少是展示问题；工作流能不能解释清楚，才是制度问题。

2. 工作越跨职能，隐形等待越容易被误认为执行

研发任务经常依赖需求确认、接口提供、环境准备、设计评审、测试结果或外部团队决策。卡片可能长期没有实质推进，但由于它仍停在“进行中”，等待时间被误读成执行时间。结果是团队不断增加新任务，却没有先解除旧任务的瓶颈。

我会把“等待”看作一种需要管理的工作状态，而不是工作没有发生。等待本身可能合理，但它应该有原因、有责任方、有下一次检查时间。否则，“我在等对方”就会变成无法验证的状态说明。

3. 任务粒度太大，会让进展无法被观察

如果一张卡片写着“完成新版本研发”，团队很难用它判断每天发生了什么，也很难识别具体卡点。任务粒度太大时，负责人可能连续多天都在做事，但看板上没有任何可见变化；到了临近交付时，才发现接口、测试或验收环节尚未启动。

任务拆分的目的不是增加卡片数量，而是让工作具备可判断的完成条件。一个合适的任务通常能让团队说明：交付物是什么、谁负责、如何验收、当前最大依赖是什么。拆分尺度应由工作性质决定，不必强求所有卡片都在同样时间内完成。

三、拆解常见误区：看板不是把旧流程换成彩色列

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

把“待需求确认、待设计、待开发、开发中、待评审、待测试、待发布、已完成”全部列出来，看似细致，却可能带来新的问题：成员不确定任务应该放在哪里，跨团队交接时反复移动卡片，管理者需要花时间维护状态，却没有更早发现风险。

我的判断标准不是列数，而是新增一列能否改变行动。如果“等待评审”单独出现后，团队会主动清理评审队列、明确评审负责人，这一列有管理价值。如果它只是改了名称，没有对应责任和处理节奏，那么新增列只增加维护成本。

2. 误区二：所有“进行中”任务都应该每天汇报百分比

百分比在部分任务上有用，但对探索性研发、排查问题或复杂技术任务而言，“完成了70%”不一定能说明还剩多少工作。更重要的是，百分比往往缺少统一口径：有人按投入时间估算，有人按功能模块估算，有人只是表达主观信心。

我更愿意先看可验证的进展信号：设计结论是否确认、接口是否可用、代码是否进入评审、测试是否覆盖关键路径、阻塞是否解除。确实需要进度估算时，应定义估算口径，并把它与交付物、风险和依赖一起看，而不是把百分比当成事实。

3. 误区三：限制在制品就是给每个人设任务上限

在制品限制的目标，是让团队避免同时启动过多工作，不是把简单的个人任务配额机械地加到每个成员身上。不同角色的工作形态不同：一个人可能并行处理紧急故障和常规开发，一个评审环节也可能由多人共同承担。统一数字如果没有结合工作流，就可能让合理的并行工作变成违规填表。

更稳妥的做法是先从团队或环节层面观察工作堆积，再试行限制。团队发现开发完成的任务大量挤在评审环节，就可以先针对评审队列设置可讨论的上限，或约定优先清理旧任务。限制值是实验起点，不是行业标准。

4. 误区四：任务移到“已完成”就代表交付结束

开发完成、代码合并、测试通过和业务验收，是不同类型任务可能经过的不同节点。如果团队没有定义完成条件，卡片可能在开发者认为“写完”时就被关闭，随后又因为缺少测试、文档或部署确认而重新打开。

“完成”的定义要与任务类型匹配。缺陷、需求、技术改造和运维任务的验收方式不必完全相同，但每类任务都应有足够清楚的完成标准。这样看板上的完成数量才有可比性，返工也能被正确记录。

四、专业判断逻辑：先设计边界，再定义状态和流动规则

1. 确认一张看板服务的工作流

在画列之前，先写清楚看板管理的对象。它是某个产品项目的需求交付，还是研发团队的迭代工作？是缺陷处理，还是从需求到上线的端到端工作？如果一张板同时放进临时支持、长期项目、例行维护和研发需求，团队很难给它们设置相同的优先级和完成条件。

团队规模较小、工作类型相近时，可以先用一张板试点；跨多个产品线或职能团队时，通常需要明确不同工作流之间的交接规则。看板边界不是组织架构图，而是帮助成员识别“这件工作从哪里来、经过哪些处理、交付给谁”。

2. 用“进入条件”和“离开条件”定义状态

下面是一套可裁剪的轻量状态示例。它不是固定模板，团队可以按真实流程合并或拆分，但每个状态都应对应明确的判断和行动。

3. 为“进行中”设置足够轻的开工门槛

进入进行中之前，至少要确认任务负责人、目标或交付物、当前可执行的下一步。对存在关键外部依赖的任务，还要判断依赖是否已满足；如果尚未满足，可以保持待处理，或进入清晰可见的等待状态，不要为了显示“项目在动”提前把任务标成进行中。

开工门槛不等于审批门槛。它的作用是减少“拿到卡片才发现什么都没准备好”的情况。对探索性任务，最初不可能知道全部方案，可以把第一阶段的交付物定义为“完成调研并给出决策建议”，而不是假装已经能准确估算全部实现工作。

4. 让卡片信息服务协作，而非堆满表单

初期卡片通常需要任务目标、负责人、优先级、验收条件和关键依赖。截止日期、成本、风险等级、影响范围等字段，只有在团队确实用它们作出决策时才值得保留。卡片字段要少而有效，字段说明要明确，避免同一个字段在不同成员手里有不同解释。

我尤其建议给阻塞信息留出独立位置。至少写清阻塞原因、需要的协助、跟进责任人和下一次检查时间。只有“被阻塞”三个字，仍然无法推动问题解决；而没有阻塞标记，管理者就可能误以为任务仍在正常执行。

5. 通过工作流观察决定是否设置在制品限制

在制品限制应围绕瓶颈设置，而不是为了形式完整而给所有列都填一个数字。观察团队一段时间内的任务流动：哪一列持续堆积？哪些卡片频繁等待？哪些工作刚进入便被紧急事项打断？如果看不见瓶颈，先改善状态定义和更新纪律，通常比直接设限更有价值。

试行限制时，团队要同时约定超限后的动作。例如：不再启动新任务，先协助完成当前工作；需要插入紧急事项时，明确由谁决定、原有哪项工作暂缓。若只设数字、不规定超限处理方式，限制就会成为看板上的装饰。

五、具体案例与数据观察：用示意团队验证“进行中”治理

1. 案例设定：先把观察口径说清楚

以下是一个明确标注的情景模拟，不代表某家企业的真实业绩，也不是行业基准。假设一个由12名成员组成的研发小组，负责一个产品版本，工作涉及需求分析、开发、评审、测试和发布准备。试点开始时，团队不改变人员配置，也不引入新的考核，只做三件事：统一状态含义、标记等待原因、每周检查停滞卡片。

为避免用“效率提升”这种模糊结论包装制度效果，观察指标选择为可在看板中核对的过程数据：进行中卡片数、阻塞卡片数、超过约定时间未更新的卡片数，以及从开工到完成的中位天数。中位数用于降低少数极端长任务对观察的影响，但也不能单独说明原因。

2. 先看状态构成，而不是只看卡片总量

假设试点前看板有40张进行中卡片，其中18张实际执行、9张等待外部依赖、7张等待评审或验证、6张超过约定时间没有更新。这个构成说明，单独报告“进行中40张”并不能回答团队的关键问题：多少工作正在推进？多少工作其实需要别人采取行动？

团队把等待状态显式标记后，卡片总数未必立刻减少，但任务性质更容易被看清。管理者可以分别处理执行瓶颈、依赖协调和评审排队，而不是要求所有负责人笼统地“加快进度”。这也是看板制度的一个重要价值：把不同问题分开，让行动更有针对性。

3. 把规则变化和结果指标分开观察

情景模拟中，试点两周后，团队可能看到长期未更新卡片减少、阻塞原因记录更完整；但这还不能证明交付周期已经改善。要判断变化是否持续，至少要连续观察多个工作周期，并结合任务类型、需求变更、人员休假和紧急故障等背景解释。

如果完成时间下降，但返工量显著增加，团队不能直接把它总结成成功。如果阻塞卡片变多，也不必立刻判断制度失败：更透明的记录可能只是暴露了过去没有被看见的等待。关键是看阻塞是否更早被发现、是否有人跟进、是否有合理的解除路径。

4. 什么时候数据不足以支持结论

如果团队两周只完成少量任务，或前后任务类型差异很大，就不应把中位完成时间的变化解释为制度带来的效果。若期间新增了重大需求、人员发生调整，或者发布窗口变化，也要记录这些影响因素。

我会把看板数据先用于团队改善，而不是个人排名。完成卡片数受到任务大小、复杂度、协作关系和分工方式影响，简单按个人比较，很容易诱导成员拆小任务、抢容易工作或避免帮助他人。看板的首要用途是让工作流更可见，让团队找到阻塞和等待，而不是把卡片变成绩效代理指标。

六、不同情况下的行动建议：用问题决定下一步，而不是照搬模板

1. 如果团队刚开始使用看板

先选一个边界清楚的团队或项目，定义三到五个必要状态，指定每张任务卡的负责人，并写清进入进行中和完成的条件。试点期间不要同时改变估算方法、考核方式和会议制度，否则发生变化后，很难判断哪项规则真正有帮助。

第一次搭板的目标不是追求漂亮，而是让团队能在看板上回答：当前最重要的工作是什么？哪些任务正在推进？哪些任务因为依赖无法继续？接下来由谁处理？这几个问题可回答后，再决定是否增加评审列、发布列或更细的工作类别。

2. 如果“进行中”卡片很多，但交付很少

先检查工作流中是否存在过多并行任务、频繁插单、任务范围过大或评审环节积压。不要一上来就要求每个人提高速度，也不要只清理看板上的卡片。找到堆积位置后，选择一个瓶颈采取行动：暂停启动新任务、安排评审时段、拆分过大的卡片，或明确插单时要暂停哪项已有工作。

同时要确认任务是不是被错误地标记为进行中。如果卡片实际上在等需求确认或外部输入，应把等待状态单独呈现，并设置跟进责任。团队只有先看见真实工作构成，才能判断是执行能力不足，还是工作流中存在大量等待。

3. 如果跨团队依赖是主要瓶颈

在卡片中增加依赖对象、所需输入、请求日期和下次跟进时间。对关键依赖，约定由谁协调升级，不要把“联系对方”留给每个任务负责人各自摸索。若依赖关系较复杂，可以维护轻量的依赖清单，但应确保它与看板任务能相互定位。

这类团队不一定需要把看板拆得更细，而可能需要跨团队的定期协调机制。看板负责暴露依赖，协调机制负责作出决定。两者职责不同，不能指望一张任务卡自动解决组织间的优先级冲突。

4. 如果团队规模较大、项目和流程较多

当多个团队共享需求、版本、缺陷和发布流程时，制度重点会从“单张板怎么画”转向口径统一、权限边界、跨团队视图和数据治理。要先确定哪些规则必须一致，例如状态的含义、阻塞信息和完成条件；哪些可以由团队自主决定，例如具体列名、任务类别和例会节奏。

这时可以评估某项目管理平台是否支持多团队工作流、细粒度权限、跨项目关联、可配置报表和历史数据迁移。若组织已有大量项目数据或需要本地部署，还应把迁移验证、部署形态、权限审计和运维成本纳入选型，而不是只比较界面功能。

七、不同情况下的取舍：制度、工具和治理成本要一起算

1. 轻量看板与完整工作流的取舍

小团队的优势是沟通路径短，规则可以轻量，状态少也能运转。若工作内容稳定、协作人数有限，先用三列或四列看板，通常比搭建复杂流程更容易坚持。代价是跨职能等待可能需要通过明确的阻塞标记和会议补足。

多团队组织需要更强的关联能力和统一视图，但流程越完整，配置、培训和维护成本也越高。我的建议是按真实协作复杂度增加能力：先解决跨团队看不见的问题，再考虑更复杂的自动化和分析，不要因为平台功能丰富就把所有功能都启用。

2. 工具选择要先匹配管理场景

工具只是制度的承载方式。对小团队，优先看创建任务、更新状态、协作评论和基础视图是否顺手；对中大型企业或100人以上组织，还要检查多项目管理、权限治理、流程配置、历史数据迁移、私有化部署和运维支持等能力。

例如，PingCode可作为研发项目管理平台的候选方案之一，适合评估中大型团队的研发协作场景；其支持私有化部署，并提供从Jira平滑迁移的能力。是否适合某个组织，仍应通过试点验证流程适配、数据完整性、权限模型、使用成本和运维要求，不能只依据功能清单或“国产替代”的口号做结论。

选型时，我会要求供应方或内部团队用真实流程走一次：创建需求、拆分开发任务、关联缺陷、进入评审与测试、处理阻塞、完成验收，再抽查历史数据迁移。演示流程应包含异常情况，不应只展示最顺畅的路径。

3. 限额的取舍：先试运行，再根据流动调整

如果团队还没有可靠的状态数据，直接规定每人最多两项进行中任务，通常缺少依据。更好的做法是先观察一段时间，找出最明显的工作堆积，再设置小范围、可复核的试行规则。团队应提前约定什么时候复盘、哪些信号说明限制过严、哪些信号说明限制不足。

限制太松，团队可能继续启动新任务，旧任务迟迟不能完成；限制太紧，紧急修复和必要并行工作可能被阻碍。比较合理的目标不是追求“进行中越少越好”，而是让并行数量与团队能力、任务性质和交付节奏相匹配。

4. 指标的取舍：看流动，不拿单一指标考核个人

完成数量容易统计，却很难比较不同任务的价值和复杂度；完成时间能提示流动情况，却会受到任务类型和等待定义影响；阻塞数量能显示风险，却可能因为记录变透明而短期上升。每个指标都有解释边界，团队应把它们组合起来看，并结合具体卡片复盘。

制度评估可以关注三类问题：任务是否更早暴露风险，阻塞是否有明确跟进，工作是否能以更稳定的方式流动。若团队发现某个指标导致成员为了数字而改变行为，就应调整指标用途或停止使用，而不是把所有偏差都归因于个人执行。

八、两周试运行与长期复盘：把制度变成团队习惯

1. 第一阶段：选试点并写下最小规则

试点要选一个工作边界相对清楚的团队或项目，确定看板负责人、参与角色和试运行周期。不要挑一个所有流程都特殊、临时任务最多的项目作为唯一依据，否则团队可能把极端情况误认为普遍规律。

开始前写下五项规则：看板管理什么工作；任务卡至少需要哪些信息；什么条件进入进行中；阻塞如何呈现；什么条件算完成。规则应允许成员快速查阅，并且在试点期内保持基本稳定，避免每天改变定义导致数据无法比较。

2. 第二阶段：按卡片流动处理问题

试运行时，团队讨论应从“每个人逐一汇报做了什么”转向“哪些卡片需要团队采取行动”。先看接近完成但未完成的工作，再看等待和阻塞，最后再决定是否启动新工作。这种顺序的价值在于减少工作只被启动、却没有形成交付的情况。

同步时不需要让每个人念一遍卡片内容。负责人只需补充看板上无法表达的信息，例如风险变化、决策需求和依赖冲突。若卡片描述不清，先补信息；若卡片长期停滞，先判断原因；若多个任务争抢同一资源，再由团队明确优先级。

3. 第三阶段：按问题调整，不按想象增加流程

试点复盘时，逐张抽查停滞卡片，判断它们属于任务过大、优先级变化、外部依赖、验收模糊、资源冲突还是单纯没有更新。不同原因对应不同措施。任务过大就拆分，依赖不清就明确协作责任，验收模糊就补充完成条件，单纯漏更新则应改善更新习惯，而不是新增审批环节。

团队也应删掉没有被使用的字段和状态。字段若长期为空、状态若没人能说清含义，就需要重新评估它是否有价值。制度不是越写越多才成熟，而是能否用较低的维护成本持续提供可信信息。

4. 建立适合团队的复盘节奏

复盘不必每次都做完整流程分析。团队可以定期看四类信号：长期未更新卡片、阻塞原因和解除时间、评审或验证排队、任务重开和返工原因。若数据有变化，再抽取具体任务核对背景，避免只看报表就得出因果结论。

可以把复盘结论落实为一项或两项小改动，并明确负责人和观察周期。例如，下一周期先试行评审队列的责任人安排，或重新定义某类需求的验收条件。每次改动太多，团队就难以判断什么有效；每次只改一点，也更容易形成可验证的经验。

九、结尾：先让“进行中”可信，再追求看板完整

研发团队从0到1搭看板，真正的起点不是选好软件，也不是把所有任务搬进一张板，而是让团队对工作状态形成共同判断。进行中代表实际处理，阻塞代表无法继续的原因，完成代表达到约定的验收条件。这三条规则清楚之后，卡片才可能成为协作信息，而不是状态装饰。

下一步可以直接做一件小事：选一个团队，抽查当前所有“进行中”卡片，逐张回答“谁在处理、下一步是什么、是否在等待、怎样才算完成”。若有一半以上答不清，不要急着增加图表或流程，先修正状态定义和卡片信息，再用两周观察工作流是否更透明。

看板制度的价值不在于让所有工作看起来井然有序，而在于让团队尽早看见工作为什么停住，并能决定接下来由谁采取什么行动。工具可以承载规则，数据可以帮助复盘，但只有团队愿意遵守并持续修正的规则，才构成真正可用的看板制度。