自定义状态怎么做？PMO协同管理：看板从0到1

看板上有“待开始、进行中、处理中、待验收、已完成”五种状态，项目负责人却仍说不清一项工作卡在哪里，这通常不是状态数量不够，而是每个状态没有对应明确的进入条件、责任人和下一步动作。做 PMO 协同看板，我的判断是：先设计工作如何流转，再决定看板显示什么；先让团队对状态有相同理解，再追求跨项目汇总。

自定义状态怎么做？PMO协同管理：看板从0到1

一、先讲结论：状态不是标签，而是协作规则

1. 状态要回答三个管理问题

状态设计的价值，不在于把任务分成更多颜色，而在于帮助执行者、项目负责人和 PMO 对同一项工作形成一致判断。一个可用的状态，至少要回答三个问题：这项工作现在处于什么阶段？谁负责推动它进入下一阶段？满足什么条件才可以切换？

如果状态只写“处理中”，却没有说明谁在处理、处理到什么程度、何时需要其他团队介入，那么它只是一个标签。管理者看到它，仍然要通过会议、私聊或临时表格追问进展。换句话说，状态名称提供可见性，状态规则才提供协作能力。

因此，自定义状态不应从工具的配置页面开始。先把实际流程画出来，再识别哪些节点需要让团队共同看见，最后才在项目管理工具中配置状态、权限、提醒或报表。

2. 先区分“阶段”和“属性”

许多看板之所以越来越难读，是因为把不同维度都塞进了状态。例如“高优先级”是优先级属性，“等待客户”可能是阻塞原因，“待验收”则是流程阶段。把它们都做成状态，会让一张简单的任务看板变成一串彼此交叉的分类。

我的判断方式很直接：如果一个信息可以与多个流程阶段同时存在，它通常不该单独占用一个流程状态。比如一项高优先级工作可以处于“待开始”，也可以处于“进行中”；“高优先级”更适合用字段表达，而不是另设一条流程线。

• 状态：工作流程走到哪里，例如“待评审”“实施中”“待验收”。
• 属性：工作的特征，例如优先级、所属项目、业务线、风险等级。
• 阻塞信息：为什么暂时无法推进，例如依赖外部团队、等待审批、缺少输入资料。
• 责任信息：当前由谁推动，通常用负责人或协作人字段表达。

3. 先建立最小可运行版本

对刚开始搭建的团队，我建议先选出少量核心状态，跑通一条真实工作流，再评估是否需要增加节点。这里的“少量”不是一条适用于所有行业的硬性标准，而是一个降低初始复杂度的设计原则：每增加一个状态，就增加一次培训、维护、判断和数据解释成本。

尤其是跨部门项目，如果团队第一次就要求所有项目统一到一套复杂状态，往往会出现两种结果：有人把实际进度硬套进不合适的状态，有人则在系统外另做一份表。看板看似统一，数据却失去了可比性。

二、背景和真实场景：PMO为什么常常“看得到板，看不懂进度”

1. 同一个词，在不同团队里可能不是同一件事

假设产品团队把“已完成”理解为开发工作已经结束，测试团队理解为测试通过，业务团队却理解为已经正式上线。对单个团队而言，每个人都可能觉得自己的定义合理；但当 PMO 把多个项目汇总到一张视图里，“已完成”就不再代表同一类结果。

这会直接影响管理判断。项目状态看起来稳定，实际交付可能尚未经过验收；看板上的“进行中”数量很多，但其中有些是正在执行，有些是等待外部输入，还有些已经停滞。颜色和列名都在，关键的过程信息却缺席。

因此，PMO 的问题往往不是“能不能汇总”，而是“汇总的数据是否同口径”。在跨部门管理中，统一字段名并不等于统一工作含义。要让状态可汇总，必须让关键状态拥有共同定义，且让状态转换条件能在不同团队中被重复解释。

2. 看板会暴露流程断点，不会自动修复流程断点

我通常会先问项目负责人：最近一次工作从一个状态切换到下一个状态，具体发生了什么？如果回答只是“到时候就改了”或“大家一般会更新”，那么真正缺少的可能不是软件功能，而是流程规则和责任安排。

例如，一项跨部门交付工作显示“待验收”两周。如果看板没有验收人、验收标准和等待原因，PMO很难判断这是验收资源不足、交付物不完整，还是负责人忘记更新。给它增加“验收中”“验收待反馈”“验收退回”等更多状态，未必能解决问题；有时只会把原有模糊拆成多种模糊。

3. PMO视角和执行者视角需要共同设计

执行者关心下一步怎么做、由谁配合、什么算交付；项目负责人关心依赖、风险、里程碑和资源；PMO更关注项目之间是否能够比较、风险是否可以提前识别、汇总数据是否可信。三类需求都合理，但不能用同一层状态去承载所有管理问题。

我的做法是先区分团队日常协作视图和 PMO 治理视图：前者可以呈现更贴近执行动作的信息，后者则聚焦少数可统一的管理节点。两者共享必要字段和映射规则，但不必要求每个岗位在同一张板上看到完全相同的细节。

三、常见误区：状态越多，不等于管理越清楚

1. 用增加状态解决责任不清

看到任务停滞，有人会立刻新增“等待某部门”“等待审批”“等待客户”“等待资源”等状态。新增后，团队可能确实更容易描述停滞原因，但如果没有指定当前推动者和重新跟进的时间，任务仍然不会自动前进。

更稳妥的设计是把“流程阶段”和“阻塞原因”拆开。例如任务仍处于“实施中”，但阻塞原因字段选择“等待外部输入”，并记录下一次检查日期和负责跟进的人。这样既保留流程阶段的可比性，也能让管理者看到问题所在。

2. 只统一名称，不统一定义

把不同项目中的“处理中”统一改成“进行中”，只统一了词面，没有统一团队的使用习惯。只要进入条件、完成标准和责任人各不相同，汇总报表仍然是在比较不同口径的数据。

状态定义应写成一句可以执行的规则，而不是一句抽象解释。例如，不只写“待验收：交付进入验收阶段”，还要说明交付物由谁提交、谁执行验收、依据什么标准判断通过，以及退回时任务回到哪个状态。

3. 把所有操作步骤都变成状态

状态适合表达管理上需要共同识别的阶段，不适合替代每一个操作步骤。如果一次任务的细分工作已经可以用子任务、检查清单或活动记录表达，就不必把每一项都升格成状态。否则，成员每天花时间维护状态，却很难从看板中看出真正重要的进展。

一个实用的判断问题是：这个节点是否会改变责任归属、决策要求、风险判断或下一步协作对象？如果答案都是否定的，它更可能是任务记录或清单项，而不是一个新的状态。

4. 只按 PMO 的汇总需求设计看板

PMO需要统一口径，但如果状态体系只方便汇报、不方便执行，团队就可能绕开看板。相反，如果看板完全按单一团队的工作习惯设计，PMO又可能无法对照不同项目的进度。设计时要明确哪些字段必须统一、哪些细节可以因工作类型而异。

我会将这项权衡写成规则，而不是口头约定：哪些核心状态全项目共用；哪些项目类型可以启用扩展状态；扩展状态如何映射到 PMO 的统一阶段；新增状态由谁评估和批准。

四、专业判断逻辑：从真实流程到可治理的状态体系

1. 先访谈最近一次真实工作，而不是讨论理想流程

启动设计时，我不会先让每个部门提交一份“理想状态列表”，因为团队很容易把所有希望看到的信息都写成状态。更有效的办法是挑选一项最近完成的工作、一项正在进行的工作和一项已经停滞的工作，沿着真实过程复盘：事情从哪里开始，谁交给谁，在哪里等待，何时发生了决策或返工。

这三类样本能够帮助识别正常流程和例外流程。只看已经完成的项目，容易忽略等待和返工；只看卡住的项目，又容易把偶发问题误判为必须固定设置的流程节点。

2. 判断一个节点是否值得成为状态

我会用四个问题评估候选节点。第一，它是否有明确的进入条件？第二，能否说清当前责任人？第三，是否会改变下一步动作或协作对象？第四，PMO是否需要在项目层面识别它？答案越明确，越适合成为共享状态；如果只有局部团队需要的信息，可考虑放在团队级字段、子任务或备注中。

这里的重点不是让每个状态都满足完全相同的模板，而是让状态的管理作用可解释。若某个状态无法回答“谁接手、下一步做什么”，它就可能只是描述，而非有效的协作节点。

3. 为每个状态建立定义卡

状态定义卡是我认为最值得先做的基础材料。它可以是一张表，也可以是流程配置中的说明文字。只要团队能在遇到边界情况时找到它，就比单纯记住状态名称可靠得多。

4. 区分核心状态、可选扩展和异常原因

对 PMO 而言，可以把状态体系分成三个治理层次。核心状态用于跨项目识别共同阶段；可选扩展用于确实存在业务差异的项目类型；异常原因用于解释为何工作没有按常规路径推进。这样做的目的不是把所有差异抹平，而是让差异有位置、可解释、可汇总。

举例来说，交付型项目可能需要显示“待验收”，研发迭代则可能需要“待测试”。PMO不一定要把两者强行改成同一个词，但可以规定二者在统一汇总中都映射到“验证阶段”。管理层看到的是可对照的阶段，团队保留的是符合实际工作的细节。

5. 先定流转规则，再配工具能力

状态设计完成后，再选择工具配置方式。不同平台的权限、自动化、报表和私有化能力各不相同，因此不应把某个工具的菜单结构反过来当成业务流程。先写清流程，再判断工具能否支持对应的状态转换、字段校验、提醒和汇总。

如果组织要评估 PingCode，可将其作为中大型企业及 100 人以上组织的候选平台之一，重点核验状态自定义、跨项目视图、权限配置、自动化、私有化部署和现有数据迁移等能力。若组织当前使用 Jira，也应在迁移评估中确认项目结构、字段、历史记录、权限、工作流和报表口径如何承接，而不是只验证任务是否能导入。实际功能、版本与实施范围应以供应方当前说明和验证结果为准。

五、具体案例：把“进行中”拆成可判断、可跟进的协作信息

1. 案例背景与边界

以下是一个用于说明设计方法的模拟场景，不代表某家企业的真实项目数据。设想一家跨部门组织正在推进多个内部交付项目，产品、研发、测试和业务团队各自维护工作进度，PMO每周需要汇总风险与里程碑。原有看板只有“待处理、进行中、已完成”三种状态。

试运行复盘发现，“进行中”同时包含开发执行、等待需求确认、等待测试资源和交付后待验收等情况。项目负责人看板上的任务很多，却无法通过状态判断下一步应该谁来推动。问题不在于任务没有记录，而在于看板没有呈现责任交接和关键等待。

2. 先改变信息表达，不急着扩大状态数量

在模拟方案中，我们没有把每一种等待原因都新增为状态，而是先将工作流程整理为少数管理阶段，再把责任和阻塞原因拆成独立字段。流程阶段负责回答“走到哪里”，阻塞原因负责回答“为什么没动”，当前责任人负责回答“谁来推动”。

3. 用观察指标验证是否值得保留

试运行不是为了证明新设计一定成功，而是为了找出哪些规则难以执行。我们会观察几类信息：成员是否能正确判断状态、任务是否反复来回切换、哪些节点长期没有更新、项目负责人能否从看板定位下一步责任人。

不要只看状态数量或看板更新率。更新率短期提高，可能只是成员在集中补录；状态数量减少，也不一定意味着流程更清楚。更有用的是把更新记录和实际交付事件对照：状态变化是否发生在工作真实交接时，阻塞记录是否带来跟进动作，验收状态是否对应明确的验收结果。

4. 数据观察要有分母、时间窗和解释边界

如果试运行期间要做数据复盘，我会先明确统计口径。例如“长期滞留率”可以定义为超过团队约定时限且仍处于同一状态的工作数量，占同期进入该状态工作数量的比例。没有时间窗和分母，单看滞留任务的绝对数量，很容易把项目规模差异误判成流程问题。

以下模拟指标仅示范怎样设计观察面板，不是实测结果。假设试运行前四周记录了 30 项代表性工作，后续再选取条件相近的项目观察。评估时应同时核对工作类型、团队规模和项目复杂度；若样本结构变化明显，就不宜简单把前后差异归因于状态设计。

六、不同情况下的行动建议：从诊断到上线分阶段推进

1. 还没有统一看板：先做小范围试点

如果组织目前主要依赖表格、会议纪要和即时消息，不必先全公司统一流程。选择一个代表性项目类型，整理最近发生的实际工作流，确认核心阶段、责任交接和异常记录方式，再让执行团队试用一段时间。

试点项目最好既不是流程最简单的“样板项目”，也不是例外最多、依赖最复杂的项目。过于简单的样本暴露不了治理问题，过于复杂的样本又容易让团队把特殊情况误认为通用要求。选取具有常见协作环节的项目，更能检验核心状态是否真的可复用。

2. 已有看板但口径混乱：先盘点使用行为

如果团队已经在用看板，不要一上来批量改名或删除状态。先检查最近一段时间的任务记录，了解哪些状态经常使用、哪些几乎无人使用、哪些状态被不同团队反复解释、哪些任务长期停留而没有跟进记录。

• 对使用频繁且含义一致的状态，保留并补全规则。
• 对名称不同但管理含义相近的状态，建立映射后再逐步统一。
• 对使用很少的状态，先核实是否仅对应少数特殊业务，不宜只按使用频率删除。
• 对长时间停留的状态，区分正常等待、风险积压与未及时更新，再决定是否调整流程。

3. 多项目跨部门协同：统一治理层，不强求所有细节一致

当 PMO 管理多个业务类型时，可以采用“共同核心阶段加项目类型扩展”的方式。核心阶段服务于管理汇总，扩展状态服务于具体团队操作；每个扩展状态必须有清楚的业务理由，并说明它映射到哪个核心阶段。

同时，要明确状态体系的维护责任。建议由 PMO 维护核心定义和映射关系，由业务负责人提出类型扩展，由实际使用团队参与验证。这样可以避免制度由管理端单向发布、执行端被动绕行。

4. 涉及平台迁移或私有化：先验证规则承接，再评估切换

如果状态设计与平台更换同时发生，项目容易把流程重构、数据迁移和团队培训混成一个大工程。我的建议是先列出需要迁移的工作流、字段、权限、历史数据和报表口径，再用代表性项目验证迁移后是否能保留关键含义。

以 PingCode 为例，若组织考虑其私有化部署能力或从 Jira 平滑迁移，应把这些作为选型验证项，而不是只看产品说明。至少需要确认：历史状态如何映射、工作流条件是否能承接、权限模型是否一致、自动化规则需要怎样重建、旧报表是否还能按原口径解释。中大型组织及 100 人以上团队还应把运维责任、升级方式、数据安全要求和实施资源纳入总成本评估。

七、不同情况下的取舍：统一、弹性与维护成本

1. 统一程度越高，汇总越容易，但局部适配空间越小

统一核心状态适合项目类型相近、管理汇总需求明确、PMO需要横向比较的组织。它的优势是培训和分析口径相对一致，代价是某些团队的细粒度动作需要放到子任务、字段或单独视图中表达。

完全统一并不总是正确答案。若项目包含研发、采购、实施、内容交付等差异明显的工作，强行要求每个团队采用完全相同的细流程，可能会让状态不再符合实际。此时，统一“管理阶段”而非统一“所有操作步骤”，通常更容易兼顾可比性与可用性。

2. 状态越细，过程更可见，但维护和培训成本也会上升

细颗粒状态能够暴露更多交接点，前提是这些节点真的会改变责任或决策。如果只是为了让进展看起来更精细，团队就要承担额外更新成本，管理者还需要理解更多状态含义。

评估是否值得细化时，可以把新增信息与维护负担放在一起看：新增状态是否能提前发现风险？是否能减少追问或会议确认？是否需要新增审批人、提醒和培训？如果这些价值无法说明，先用字段或活动记录表达，通常更稳妥。

3. 自动化可以提醒流程，但不能替团队作出业务判断

自动化适合处理可明确判断的规则，例如状态变更后通知下一责任人、进入待验收后提醒指定验收人、超出约定时间后提示项目负责人。它不适合替代模糊判断，例如“工作是否足够成熟”“结果是否真的满足业务要求”。这些问题仍需依赖明确标准和责任人的判断。

因此，自动化之前先检查规则是否足够清楚。一个定义含糊的状态被自动化后，错误只会传播得更快。最好先用人工流程跑通，再将重复、稳定的动作自动化，并为异常情况保留人工处理路径。

八、上线前检查清单与最终判断

1. 状态定义检查

每个状态都应能用简短、可执行的语言说明。检查时不要只问“名字是否清楚”，还要验证不同角色能否对进入条件和退出条件作出相同判断。

• 每个状态是否有明确的进入条件和退出条件？
• 每个状态是否有当前责任人或明确的推动角色？
• 进入后是否有下一步动作，而不是只改变颜色或名称？
• 异常等待是否能记录原因、跟进人和复查时间？
• 新增状态是否解决了明确问题，是否与现有状态重复？

2. PMO治理检查

看板在一个团队内能用，不代表已经适合组织级管理。PMO需要检查不同项目是否按同一口径理解核心阶段，扩展状态是否能映射到共同视图，以及状态变更是否有责任人和维护流程。

• 核心状态是否有统一定义、负责人和版本记录？
• 项目类型扩展是否有清楚的适用范围与映射规则？
• 状态修改由谁提出、谁评估、谁批准？
• 看板数据是否能说明统计周期、分母和排除范围？
• 项目执行者是否参与试用和复盘，而不只是接收通知？

3. 试运行复盘检查

试运行结束时，不要只做一次满意度投票。把状态记录与真实交付事件对照，抽样查看任务从创建到关闭的过程，确认转换是否发生在实际工作交接时。再询问执行者：哪些状态容易误用？哪些信息仍需在会议上反复追问？哪些规则反而增加了无效操作？

如果团队仍然无法判断状态含义，应先修订定义；如果状态清楚但任务迟迟不动，应查责任、资源和决策机制；如果数据已准确但管理者仍无法识别风险，应检查汇总视图和风险字段。不要把所有流程问题都归因于状态设计。

4. 下一步怎么做

如果你正在从零搭建 PMO 看板，可以从一项真实工作开始：选取近期完成、正在进行和已经停滞的任务，画出实际流转过程，标记责任交接与等待原因，再写出核心状态定义卡。随后选择一个代表性项目试运行，按约定周期复盘误用、滞留、返工和责任缺失。

如果你已有看板，则先盘点状态使用记录和团队解释差异，不要急着批量增删。先找出最影响管理判断的一个问题，再决定它应通过状态、字段、责任规则、提醒机制还是流程调整来解决。

自定义状态的真正产出，不是一张列更多的看板，而是一套团队可以共同执行、PMO能够合理汇总、并且出现例外时仍然知道如何处理的协作规则。先让每个状态都能回答“谁在推动、下一步是什么、什么结果才算完成”，看板才算真正从0到1。