看板如何做好自定义状态？PMO流程优化与操作步骤

看板状态越多，项目未必越透明。我在流程诊断中更常见的情况是：团队把“待排期、处理中、等反馈、待验收、已完成”都加进看板，却仍说不清一张卡片为什么停了两周、下一步由谁推动。自定义状态的关键不是增加列，而是让每个状态都能回答三个问题：工作现在在哪个阶段、什么条件允许它进入这里、谁负责把它带到下一步。

一、先讲结论：状态是流程信号，不是装饰性列名

1. 先解决流程问题，再决定要不要加状态

如果团队只是觉得“进行中”听起来不够细，不一定需要新增状态。真正值得调整的信号，通常是工作交接反复发生、评审和执行混在一起、卡片停滞原因不可见，或者不同团队对同一个状态有不同解释。

我会先追问：新增这一列以后，谁会据此采取不同动作？如果答案只是“看起来更清楚”，但没有对应的负责人、进入条件或退出动作，这个状态很可能只是把原来的模糊流程换了个名字。

2. 状态、责任、优先级和风险要分开管理

状态描述工作所处的流程阶段；负责人描述谁推动工作；优先级描述先做什么；风险或阻塞描述什么可能影响交付。这几类信息可以同时出现在一张卡片上，但不应全部塞进状态列里。

例如，“待评审”是流程状态，“产品负责人”是责任人，“高优先级”是排序信息，“等待外部接口”是阻塞原因。把它们混成一组状态，会让状态既像阶段、又像标签，还承担人员管理，后续统计和自动化都会变得困难。

3. PMO 的目标不是统一所有列，而是统一可解释的规则

PMO 可以建立核心状态定义、变更审批和指标口径，但不一定要把所有项目压进完全相同的流程。跨团队统一的重点，应是“状态代表什么、如何流转、怎样报告”，而不是所有项目必须使用一模一样的列名。

对跨部门项目，PMO 通常需要可比较的阶段口径；对研发、市场活动、采购等不同工作类型，则可能需要各自的局部流程。统一治理规则，保留合理流程差异，往往比统一每一个状态更实用。

二、背景和真实场景：为什么看板会“越来越细，越来越难用”

1. 一个常见的跨团队项目场景

设想一个企业内部系统升级项目，参与团队包括业务、产品、研发、测试和信息安全。最初看板只有“待办、进行中、已完成”。项目规模变大后，团队开始增加“待排期、需求澄清中、开发中、代码评审、测试中、待业务验收、等待安全审批、已发布”等状态。

这些状态看起来更贴近工作，但项目负责人仍可能不知道“等待安全审批”已经停了几天，也不清楚审批材料是否齐全；研发团队把“开发中”理解为已经开始编码，业务团队却把需求讨论也放在这一列。状态变细了，信息质量却没有同步提高。

这类场景的根因通常不是状态数量不足，而是状态定义、责任交接和停滞处理规则没有一起设计。看板能显示卡片位置，却不会自动补足卡片背后的管理约定。

2. 用“可行动信息”检查每个状态

我会用一个简单的问题筛查状态价值：团队看到一张卡片处于这个状态时，能不能判断下一步动作？如果“待评审”没有评审人、材料要求和预计处理时间，团队仍然需要线下追问；这说明状态名称还没有变成可行动信息。

另外，状态必须有边界。比如“处理中”若同时包括未开始、正在执行、等待协作和返工，团队就无法从看板识别真实进度。此时要先确认这些情况是否需要不同的管理动作，再决定拆成状态、标签、字段还是提醒。

3. 先找停滞原因，不要把停滞本身误判为新阶段

卡片长期不动，可能是负责人没有更新，也可能是审批等待、需求不完整、外部依赖未就绪，或者实际工作已经完成但没有人确认。单纯增加“卡住了”一列，未必能区分这些原因。

如果阻塞只是偶发情况，用阻塞标记、原因字段和提醒机制可能更合适；如果某类等待是稳定、重要且需要单独管理的流程节点，才有理由将其设计成正式状态。是否拆状态，取决于管理动作是否不同，而不是某种情况是否经常出现。

三、常见误区：状态膨胀通常是信息设计失衡

1. 把所有异常都变成状态

“延期”“高风险”“等人回复”“缺少资料”都可能是重要信息，但它们不一定是流程阶段。把每个异常都设为一个状态，会让正常流程和例外处理混在同一条路径上。

更稳妥的做法是先判断它属于哪一类：若它改变了工作所处阶段，考虑状态；若它描述工作特征，考虑标签或字段；若它需要某人采取行动，考虑负责人、提醒或待办。这样能降低流程的复杂度，也更方便后续统计。

2. 只改列名，不定义进入和退出条件

“待验收”听上去清晰，但不同团队可能分别理解为“开发已经完成”“测试已通过”或“业务正在体验”。如果进入条件不同，报表里的“待验收数量”就不能直接比较。

状态说明至少要写清它代表什么、工作满足什么条件才能进入、达到什么条件后离开，以及由谁确认。无需把流程写成厚重的制度文件，一张状态字典表通常就能解决大部分歧义。

3. 把负责人和状态绑在一起

有些团队会设置“产品处理中”“研发处理中”“测试处理中”，用状态名称表达当前责任部门。这种做法在小范围内容易理解，但部门一旦增加或责任发生变化，状态列表就会跟着膨胀。

如果流程阶段没有变化，只是责任人切换，更适合保留统一阶段并更新负责人或协作团队。只有当交接本身构成明确的流程节点，且需要独立审批、时限或统计时，才值得单独建状态。

4. 把“看起来整齐”当作流程优化成果

颜色、卡片布局和列排序能提高识别效率，却不能代替流程定义。即使看板设计得很整齐，如果卡片没有负责人、完成标准或阻塞原因，管理者仍然无法判断风险。

我会把“视觉改善”和“流程改善”分开验收。前者检查信息是否容易扫描，后者检查交接是否明确、等待是否可见、异常是否有人处理。两者都重要，但不能用页面变漂亮来证明流程已经变好。

四、专业判断逻辑：用四道问题决定是否拆分状态

1. 这个状态是否代表一个真实、稳定的阶段

状态应描述工作项当前所处的位置，而不是某个人此刻在做什么，也不是一次临时事件。一个阶段如果只偶尔出现、边界不清或每个团队含义不同，通常不适合直接作为组织级状态。

例如，“等待外部审批”可能是稳定阶段，也可能只是偶发阻塞。若所有此类工作都必须提交材料并等待审批结果，且PMO需要独立跟踪时限，可以考虑单列；若它只是少数卡片的临时障碍，阻塞字段更灵活。

2. 进入和离开它是否会触发不同动作

状态的价值，来自它对行动的提示。进入“待评审”后，是否需要指派评审人、检查材料、计算等待时间？进入“待验收”后，是否要通知业务负责人？如果状态变化不带来任何不同动作，它可能只是对原流程的重复描述。

我建议把每个候选状态对应到一个动作。如果找不到明确动作，要么补充责任与规则，要么考虑用其他字段表达。这样可以避免状态只增加报表维度，却不改善协作。

3. 该信息是否适合用属性表达，而非流程列

一个实用判断是：同一张卡片能不能同时拥有多个此类信息？一项工作可以同时“高优先级、存在风险、等待供应商”，因此这些更像属性；但一项工作通常只处于一个主要流程阶段，因此阶段更适合用状态表达。

当然，工具的数据模型各不相同，具体配置方式要以所用平台的能力为准。无论使用状态、标签还是字段，都要保持定义一致，并确保团队知道谁负责更新。

4. 增加状态会不会破坏跨项目统计

PMO 常需要汇总项目进度、等待时间和交付结果。某团队新增状态后，如果无法映射到组织级阶段，跨项目报表可能出现“同名不同义”或“异名同义”。因此，状态自定义不能只看单个看板，也要检查组合报表的口径。

常见办法是保留组织级核心阶段，同时允许团队配置局部状态，并为局部状态指定汇总映射。例如，多个团队的“代码评审”“设计复核”可以映射到统一的“评审中”，但不必强迫它们使用同一个工作列。

五、具体设计与案例：从真实流程拆出可管理状态

1. 先用一条简单流程做基线

以下状态仅作示例，不是适用于所有行业的标准答案。对一个包含需求确认、执行、评审和交付的企业项目，可以从“待处理、准备就绪、处理中、待评审、待验收、已完成”开始，再根据真实工作特点删减或拆分。

2. 用一个项目样例验证状态是否有用

下面用一组情景模拟数据说明判断方法，并非客户案例或行业统计。假设某项目组抽查了 40 张近期开启的卡片，发现其中 12 张在“处理中”停留超过 10 个工作日；进一步核对后，4 张实际在等待外部资料，3 张等待业务确认，5 张仍在执行但更新不及时。

如果直接把“处理中”拆成“等待资料、等待业务、执行中”三个状态，前两种等待可能更容易被看到，但“更新不及时”仍没有解决。此时更合理的组合可能是：保留“处理中”作为主流程状态，为外部依赖和业务确认增加阻塞原因字段，并对长时间未更新的卡片设置提醒。

只有当“等待业务确认”是固定交接环节，且有明确的业务责任人、确认材料、处理时限和独立复盘需求时，才考虑把它设为正式状态。这个判断把“发生过”与“值得纳入流程”区分开来，能减少为了少数异常而改造整套看板。

3. 用试点数据观察规则是否真的改善了协作

试点不需要一开始就追求大型数据看板。可以先选一个项目，记录试点前后相同口径的数据，例如状态定义争议次数、卡片停留时间、交接退回次数、缺少负责人的事项数，以及PMO人工追问耗时。

比较时要避免只看“已完成数量”。项目进入阶段、事项规模、团队人数和工作类型都可能影响结果。若试点前后并非同一类项目，数据只能作为线索，不能直接归因于状态配置带来的效率提升。

六、操作步骤：从盘点到上线验证

1. 抽样盘点现有状态和实际用法

不要只看系统里的状态名称，还要检查卡片实际如何流转。建议抽取一个近期项目，查看状态使用频率、长期停留卡片、状态回退情况、无人负责事项，以及团队对状态含义的解释差异。

如果工具支持导出，可用表格做一次基础盘点；如果不支持，先抽样检查也足以暴露明显问题。盘点的目标不是马上统计出一套漂亮指标，而是找到“状态定义与实际行为不一致”的位置。

2. 绘制真实工作流，而不是理想流程

和项目经理、执行人员、评审人分别确认工作从提出到交付的实际步骤。尤其要问清楚例外路径：需求退回后回到哪里、审批失败谁处理、外部依赖如何重新启动、已完成事项如何返工。

流程图不必复杂，关键是把交接点标出来。状态通常应该落在团队能识别的阶段边界上，而不是把每个微小操作都做成一列。

3. 为候选状态建立状态字典

每个候选状态都写明名称、定义、进入条件、退出条件、责任角色、必要字段、允许的前后状态，以及是否需要纳入PMO统计。状态字典不是形式文件，它是组织在不同项目之间共享含义的基础。

在设计阶段就要检查名称是否容易误解。例如“已交付”可能指成果已提交，也可能指客户已经接受；如果两者需要不同管理动作，就不要使用一个含混名称覆盖两个节点。

4. 在工具中配置并核对权限和流转

不同项目管理工具的菜单名称、状态配置方式、自动化能力和权限模型可能随版本及部署形态变化。实施时应按当前版本核实，不能把某个工具的操作路径当成通用标准。

在配置时至少验证状态名称、排序、进入限制、退出流转、必填字段、审批权限、通知规则和统计映射。需要自动化的规则应从少量、明确且低风险的场景开始，避免一次性配置大量依赖关系，导致后续难以排查。

5. 用真实任务走完整条路径

上线前挑选几种典型事项，实际走一遍新建、准备就绪、执行、评审、退回、阻塞、验收和完成。不要只测试最顺利的路径；退回、取消、重新打开和责任人变更，往往更容易暴露状态设计中的漏洞。

测试时检查两类问题：一是是否存在卡片无法进入下一状态的技术或权限限制；二是团队是否知道发生异常时该怎么处理。前者靠配置修复，后者需要规则说明和培训。

6. 先试点，再推广

试点范围宜小到能及时收集反馈，也要大到足以遇到真实交接。可以选择一个项目或一个业务流程，先运行一个完整周期，再决定是否扩展。试点期间记录规则问题，不要每遇到一个例外就马上新增状态。

试点结束后复盘：哪些状态几乎没人使用，哪些状态停留时间很长，哪些定义仍有分歧，哪些指标因状态映射不一致而无法比较。最后再决定保留、合并、拆分或调整规则。

七、PMO治理：让状态体系可维护，而不是一次性上线

1. 建立组织级核心状态和局部扩展规则

PMO可以维护核心阶段定义，并规定局部扩展必须具备的条件。例如，团队自定义状态时要说明业务原因、责任角色、进入退出规则以及对汇总报表的映射方式。这样既保留灵活性，也避免每个项目都创造一套无法互通的词汇。

可以将状态分成两层：组织级核心阶段用于组合报表和管理沟通；团队级局部状态用于表达具体工作细节。局部状态如何汇总到核心阶段，要在上线前确定，而不是等到月报无法对齐时再补救。

2. 设置变更记录和复核节奏

状态变更应记录变更人、原因、影响范围、生效时间和旧数据如何解释。否则看板历史记录可能前后不可比，项目复盘也难以判断某一阶段的停留时间变化究竟来自流程改善还是定义改变。

复核节奏不必僵化为统一频率，可以在项目阶段切换、组织流程调整或发现状态长期闲置时触发。重点是让“新增状态”有入口，也有退出机制。

3. 看流转质量，不只看完成率

完成率容易被关注，但它通常不能解释问题发生在哪里。PMO还可以观察阶段停留时间、退回率、阻塞事项占比、无负责人事项数、状态更新及时性和人工追问耗时，并结合项目类型解释差异。

这些指标没有适用于所有组织的统一阈值。若把某个团队的平均等待时间直接设成全公司的考核线，可能会惩罚流程本身更复杂的项目。先建立基线，再结合业务约束讨论目标，比照抄一个“行业标准”更可靠。

4. 把状态数据用于改流程，而不是给团队贴标签

当某个状态长期积压，首先应追查上游输入质量、资源安排、审批时限和责任交接，而不是立即归因于执行团队效率低。状态数据的意义是暴露系统中的等待和约束，帮助团队找到可改的环节。

如果一项指标要进入绩效评价，必须先确认定义稳定、数据更新机制可靠、团队对指标有合理控制力。否则团队可能通过提前改状态、拆分任务或隐藏阻塞来优化数字，却没有真正改善交付。

八、不同场景下的行动建议与取舍

1. 小团队、短周期、流程简单

优先使用少量核心状态，重点明确开始条件、负责人和完成标准。小团队通常可以通过日常沟通补充细节，过早引入多层审批和复杂状态映射，反而会增加维护负担。

如果团队常遇到阻塞，先增加阻塞原因和责任人信息，并建立简单提醒。只有当某个等待环节反复出现、需要独立跟踪时，再考虑将其拆成正式状态。

2. 多部门协作、交接频繁

把交接节点作为设计重点。每个交接状态都应明确交出方、接收方、必备材料和接收后的动作。重点不在于列更多，而在于减少“我以为已经交给你”的责任空隙。

如果部门之间使用不同术语，可以保留团队内部名称，同时建立统一阶段映射。这样既不强迫所有团队改变专业语言，也能让PMO按共同口径观察流程。

3. 100人以上组织或中大型企业

规模变大后，状态治理会涉及权限、模板复用、跨项目统计、历史数据解释和流程变更管理。此时需要评估工具是否支持组织级模板、角色权限、审计或变更留痕、数据汇总和部署要求，而不只是确认能否新增列。

例如，PingCode面向中大型企业及100人以上组织的协作场景，可作为评估项目管理平台时的一个候选。其具体功能、授权范围、部署方式和版本差异，应以供应商当前说明及实际演示为准；若涉及私有化部署或从Jira迁移，也应通过迁移范围、字段映射、历史数据、权限和接口的验证来做决策，不宜仅凭宣传表述判断适配性。

选择平台时，我更建议先准备一组真实项目样本，现场验证状态映射、权限流转、报表口径和异常路径。对于迁移项目，先迁一小批数据并完成业务验收，再制定分批切换计划，比一次性迁移所有流程更容易控制风险。

4. 需要合规审批或强管控流程

审批节点应有明确的授权边界、必填材料、审批责任和退回路径。状态可以用来显示审批阶段，但不能只靠看板列名代替正式审批记录或合规留痕。

若某一审批状态需要满足审计要求，应优先验证工具能否保留操作记录、权限变化和审批结果。流程图设计得再清楚，也无法弥补证据链不完整的问题。

5. 不同取舍：统一程度、可视性与维护成本

状态设计不是越统一越好，也不是越灵活越好。统一程度提高，有利于跨项目比较；局部灵活性提高，更贴近团队实际；状态数量增加，细节可见性可能上升，但培训、维护和数据解释成本也会增加。

九、落地自检：上线前确认这八件事

1. 状态定义是否能被不同角色复述

找项目经理、执行人员和接收方分别解释同一个状态。如果解释差异明显，先改定义和例子，不要急着培训大家记住一个模糊名称。

2. 每个状态是否有明确的进入和退出条件

没有边界的状态最容易被当成“差不多”的容器。对于关键状态，至少要写出进入条件、退出条件和责任角色。

3. 是否把属性误做成状态

检查优先级、风险、负责人、等待原因和工作类型是否被塞进列名。能用标签或字段表达的信息，不必全部变成流程阶段。

4. 是否考虑退回、阻塞和重新打开路径

只验证顺利完成路径是不够的。评审退回、审批失败、外部依赖中断和已完成事项返工，都要有明确的处理方式。

5. 新增状态是否对应独立管理动作

如果新增状态没有负责人变化、通知、审批、时限或独立统计需求，先考虑是否可以用现有状态加属性表达。

6. 是否影响历史数据和跨项目报表

确认旧状态如何映射，新状态如何归入组织级口径，历史报表是否需要重新解释。指标定义发生变化时，应记录生效时间。

7. 是否有试点和回退方案

先在可控范围验证，再决定推广。若配置后发现流转混乱，应能合并或回退，而不是因为已经上线就继续维护无效状态。

8. 是否规定状态清理和变更责任

明确谁可以提议新增、谁负责批准、谁维护字典，以及在什么情况下删除或合并状态。没有治理责任人，状态体系通常会随着项目增长而持续膨胀。

十、结语：看板的成熟度，体现在状态背后的规则

自定义状态最容易被误解成“把看板改得更符合团队习惯”。但真正有价值的调整，不是列名更丰富，而是团队能更快判断工作在哪里、为什么停住、下一步由谁负责，以及PMO如何比较不同项目的流程表现。

我建议下一步先不要打开工具新增状态。先抽查一个项目的卡片，找出停滞和交接最集中的环节；再为候选状态写清定义、进入退出条件和责任动作；最后挑一个项目试点，用同口径数据验证是否减少了歧义、追问或无效等待。

如果新增状态不能改变任何管理动作，它大概率只是增加维护成本；如果一个状态能让责任、交接和风险变得可判断，它才真正成为流程工具。