看板如何做好自定义状态？项目负责人制度设计与操作步骤

看板如何做好自定义状态？项目负责人制度设计与操作步骤

看板上的状态从 5 个加到 12 个，任务却还是卡在“处理中”；负责人每天打开看板，能看到一排卡片，却说不清哪些任务在等评审、哪些缺少输入、哪些只是没人接手。自定义状态真正要解决的不是“列不够用”，而是让团队对工作到了哪一步、由谁推进、什么条件才算完成达成一致。我的判断是：先定义流转规则和责任，再决定要不要增加状态。

一、先给结论：状态是流程信号，不是分类标签

1. 一个状态至少要说明三件事

每个看板状态都应该帮助团队回答三个问题：这项工作当前处于什么阶段？谁负责推动下一步？满足什么条件后才能离开这个状态？如果成员看到某一列后仍然需要在群里追问“现在具体在等什么”，这个状态就没有提供足够的信息。

例如，“待验收”如果只是一列名称，团队仍可能对谁验收、验收什么、未通过后回到哪里各有理解。把这些规则补齐后，它才成为可执行的流程节点：交付材料齐全后进入，由验收人检查约定标准；通过后转入完成，未通过则退回执行阶段并写明差异。

我设计状态时优先追求“可判断、可交接、可复盘”，而不是看板看起来完整。状态数量本身不是成熟度指标；能否据此判断工作位置和下一步动作，才是状态设计有没有价值的检验标准。

2. 把阶段、责任和例外拆开设计

团队经常把多个管理问题挤进状态列：既想看进度，又想标优先级，还想知道由哪个部门处理。结果是列名越来越长，信息却越来越难读。更稳妥的做法，是把不同维度分别放到适合的位置。

如果卡片处于“执行中”，同时标记“高优先级”“合规审查”“等待外部输入”，这些信息分别描述进度、处理顺序和上下文。把它们拆开，管理者才能区分“正在做但优先级高”和“阶段没变化、因为外部依赖而阻塞”这两类完全不同的情况。

3. 为状态定义设定最低标准

在我看来，一个状态要进入正式看板，至少应该有明确含义、进入条件、退出条件、当前责任角色和异常处理方式。若其中两项以上只能靠口头解释，就先不要把它当作团队标准发布。

这条标准不是要求每个状态都配一份复杂制度，而是避免“大家都知道大概意思”的模糊约定。团队成员更替、任务跨部门流转或负责人休假时，依赖口头默契的状态最容易失效。

二、为什么看板会越改越复杂：从真实工作场景找原因

1. 任务停滞，常常不是状态数量太少

设想一个常见场景：产品需求已经排进看板，开发卡片显示“处理中”两周，负责人认为工作在推进；项目经理却发现实际卡点是接口说明没确认。团队新增“等待产品”这一列后，类似任务被挪了过去，但如果没有指定谁去确认、确认结果怎么回填，问题仍然只是换了一个列名。

这种场景里，看板揭示了“等待”这个阶段，却没有解决等待的管理问题。更有效的规则通常包括：等待什么输入、由谁跟进、什么情况下需要升级、输入到位后由谁确认恢复。若任务卡点只是偶发的，也可以使用阻塞标记或原因字段，而不必把所有特殊情况扩展成状态。

2. 跨部门交接容易出现责任空档

状态流转时最容易被忽略的，是旧责任结束、新责任尚未接手的那段空白。卡片从“待评审”拖到“待验收”后，原执行人以为任务已经交出，验收人却没有收到通知或缺少检查材料，于是卡片在新列里无人处理。

因此，负责人制度不能只写“每张卡片要有负责人”，还要规定交接动作：谁发起交接、接收方如何确认、缺少材料时退回到哪里、卡片负责人在交接成功前是否仍承担跟进责任。明确这些边界，才能减少“我以为已经交给你”的情况。

3. “等待”与“进行中”混在一起会掩盖风险

“处理中”有时包含正在编辑、正在审查、等待客户答复和排队等资源等多种状态。它们的下一步动作不同，停滞原因也不同。把所有任务都塞进一个大列，确实能让流程看起来简单，但会让负责人更难判断工作为什么没有变化。

反过来，把每一种等待原因都变成独立状态也不合理。状态应描述相对稳定、团队愿意管理的流程阶段；临时原因优先作为属性或阻塞信息处理。判断标准不是“能不能再细分”，而是细分后是否会改变责任动作、管理判断或后续决策。

4. 用小样本审计发现看板盲点

在正式改流程前，我建议抽取近期已完成、仍在进行和曾经阻塞的卡片做一次轻量审计。每张卡片只追问：状态是否准确？下一步是否明确？当前责任人是否知情？如果某一列里大量任务的下一步完全不同，说明状态可能过粗；如果两个相邻状态长期由同一批任务来回切换，则可能是定义重叠。

下面的数字是用于说明审计方法的情景模拟数据，不是行业平均值，也不是任何工具的实测结果。团队可用相同口径分析自己的卡片：先看问题分布，再决定是改状态、补规则，还是处理资源瓶颈。

三、设计自定义状态：从真实流程而不是理想流程开始

1. 先选一种任务类型，画出实际路径

不要一开始就试图给公司所有工作设计一套通用状态。产品需求、客户交付、采购申请和故障处理的阶段、责任人及验收标准可能完全不同。先选一个流量稳定、角色相对清楚的任务类型，梳理工作从提出到结束的真实路径。

我建议把最近一段时间内已完成和未完成的卡片放在一起观察，并记录它们实际经历的节点，而不是只访谈管理者“流程应该是什么”。未完成任务尤其重要：它们能显示真实的等待、返工和交接断点，而理想流程图通常不会主动展示这些例外。

梳理时可以区分三类节点：团队确实要管理的工作阶段、工作阶段中的状态属性，以及很少发生的异常情况。第一类通常适合作为状态；第二类可能适合字段或标签；第三类应有明确的异常处理办法，但未必需要成为主流程中的一列。

2. 用“进入，处理，退出”写状态定义

每个状态都可以用一张简短的规则卡描述。定义要写得让第一次参与项目的人也能判断，而不是只写“处理中”“待跟进”这类依赖上下文的词。

定义不需要写成流程手册，但必须具备可操作性。比如“及时验收”无法复盘，“指定验收人检查交付物中的约定项目，并记录通过或退回原因”就更容易执行和追踪。

3. 用三个判断筛选候选状态

我会逐个检查候选状态，避免因为某个现象真实存在，就立刻在看板上增加一列。

• 它是否是一个稳定阶段？偶发等待或一次性例外，通常不值得成为主流程状态。
• 进入这个状态后，责任动作是否发生变化？如果角色、处理方式和管理判断都没变化，可能只需要补字段或说明。
• 团队是否需要单独观察它？如果该阶段影响交付、风险控制或容量安排，单独呈现才更有管理价值。

这三个问题能帮助团队区分“信息更丰富”和“状态更多”。例如，“等待客户回复”可能在客户交付流程中需要单独观察，因为跟进责任和对外承诺发生了变化；但若只是偶尔有一张任务等待同事提供图片，原因字段加责任人提醒可能已经足够。

4. 控制状态颗粒度，防止细到无人维护

状态颗粒度没有跨团队通用的最佳数量。影响合理颗粒度的，是流程阶段之间的责任差异、交接成本、风险要求和管理用途。一个十几人的临时项目可能只需要少量核心阶段；拥有多角色审批和审计要求的复杂交付，可能需要更细的节点，但每个节点都要有维护者。

下面的图表为情景模拟，用来说明状态过少和过细的取舍，不代表任何组织的实测效率。评估时请用团队实际的错误转列、停滞和维护耗时替换示意值。

四、项目负责人制度：把项目推进、卡片执行和规则维护分开

1. 项目负责人负责流程运行，不是所有任务的执行人

项目负责人需要关注整体推进：是否有关键任务无人接手、跨团队依赖是否有跟进人、停滞是否影响里程碑、当前规则是否需要调整。负责人可以推动问题被看见和处理，但不应默认替代每一张卡片的执行责任人。

如果所有状态变化都必须由项目负责人亲自操作，团队很快会形成新的瓶颈：负责人忙于替别人更新看板，成员则把卡片维护当成项目经理的工作。更合理的要求是，当前任务责任人更新卡片并完成交接，项目负责人治理流转质量和异常。

2. 任务负责人对当前卡片的下一步负责

一张卡片可以有多个协作人，但同一时刻应有一个明确的当前推进责任人。这个人不一定要亲自完成所有工作，却要知道下一步是什么、需要谁配合、何时更新状态。如果当前阶段的责任已经转移，卡片也要完成清楚的交接，而不是只改变列位置。

任务负责人离开项目、角色调整或工作转交时，应重新指定当前负责人。负责人字段为空、填写整个团队名称，或长期保留已离岗成员，都意味着看板上的责任信息不能作为管理依据。

3. 流程维护人负责状态规则的版本

建议明确一名流程维护人，负责维护状态说明、审核新增或停用状态的申请、记录规则变更，并定期收集误用案例。小团队可以由项目负责人兼任；多项目或多业务线组织则可以由流程负责人、项目管理办公室或经授权的管理角色承担。

需要特别区分：流程维护人负责规则，不代表他要审批每一张卡片的日常移动。只有涉及关键控制点、审计要求或高风险流程时，才需要考虑将特定状态的变更权限单独约束。

4. 用责任矩阵消除职责重叠

下面的分工表不是固定组织架构，而是一个起步模板。团队可以根据规模合并角色，但不要让“规则维护”“任务执行”“项目推进”三个责任全部落到一个含糊的“大家”身上。

5. 为停滞建立透明但不过度监控的规则

停滞并不等于负责人失职。任务可能因为外部决策、资源排队、材料缺失或技术风险而无法继续。制度要做的是让这些原因可见，并明确谁负责推动下一步，而不是只用红色标记制造压力。

团队可以根据工作节奏约定检查频率或提醒阈值，但不应把某个固定天数宣称为所有项目的行业标准。研发任务、审批流程和客户交付的合理等待时间不同；先观察本团队正常周期，再为关键节点设定有依据的提醒规则。

五、从试点到上线：自定义状态的操作步骤

1. 先盘点卡片，不要先打开设置页面

开始配置前，收集近期任务样本，至少包括已经完成、仍在执行、曾经退回和当前阻塞的工作。按任务类型观察真实路径，记录哪些阶段确实改变了负责人或处理动作，哪些只是描述不同但实际做法相同。

如果团队当前没有足够的卡片样本，可以先用近期项目回顾记录流程，并把结论标成待验证假设。不要因为一次讨论就把临时想法永久写进正式看板。

2. 先合并重复状态，再讨论是否新增

把现有状态逐一写出定义，找出名称不同但进入条件、退出条件和责任动作相同的节点。对于“已排期”“计划中”“准备开始”等可能重叠的状态，先通过实际卡片确认区别是否稳定存在。

若两个状态没有明确的区别，优先合并并保留必要的补充字段。减少同义状态能降低选择成本，也能减少卡片在相邻列之间反复移动。

3. 召开短会，逐项确认规则而不是争论词语

讨论时不要只问“这一列叫什么比较好”，而要拿一张真实卡片问：什么事实说明它可以进入？进入后由谁做什么？什么结果才算结束？未达到标准时回到哪里？当团队对这四个问题能形成一致答案，状态名称通常更容易确定。

如果不同角色给出不同答案，这不是用词问题，而是流程责任或业务标准尚未统一。应先决定规则，再配置工具，否则看板只会把分歧可视化。

4. 配置状态、字段、权限和通知

在看板工具中依照已批准的规则配置状态，并检查负责人字段、必要信息、权限、提醒及自动化是否与流程一致。不同平台对状态、列、工作流和权限的实现方式各不相同，菜单名称和功能边界应以所用工具的官方说明为准。

例如，团队规模较大、项目类型多、需要统一治理或有部署要求时，可以把 PingCode 作为候选项目管理平台之一进行评估。它主要服务中大型企业及 100 人以上组织，并支持私有化部署和 Jira 平滑迁移等场景；具体能力、版本范围和迁移边界应以当前产品资料及实际验证结果为准。工具能否支持需求，不应替代团队对流程规则的判断。

5. 先试点，再决定是否全组织推广

选一个流程相对稳定、参与角色愿意反馈的项目作为试点。试点期间观察成员是否能正确判断状态、交接是否有遗漏、阻塞原因是否可见、负责人是否愿意持续更新。不要只看配置有没有完成，还要看规则是否改变了实际行为。

试点周期由任务频率和项目节奏决定。低频审批流程可能需要更长时间才能覆盖真实例外；高频需求流程则可以更早发现状态定义模糊的问题。关键不是追求统一的天数，而是让样本足以覆盖正常、退回和阻塞路径。

6. 发布规则版本并安排复盘

正式上线时，发布状态说明、适用范围、角色责任、异常处理办法和反馈渠道。每次变更都记录变更原因、生效时间和受影响流程，避免不同团队各自沿用不同版本。

复盘时优先检查长期未更新卡片、相邻状态反复流转、状态为空、负责人失效和退回原因缺失等现象。若问题集中在某个状态，先确认定义和责任是否有歧义；若规则清楚但任务仍积压，则可能是资源、优先级或决策时效问题，不应继续堆叠状态。

六、案例拆解：把“等着验收”变成有责任、有出口的节点

1. 案例背景：交付完成不等于工作结束

以下是一个示意案例，用于展示规则如何落到卡片上，并非某家企业的真实业绩。某跨部门交付团队有产品、实施和业务验收角色。原看板只有“待处理、进行中、已完成”三种状态，实施人员提交材料后把卡片标为“已完成”，业务部门却认为还没有验收，项目负责人只能在会议上逐项询问。

团队最初想新增“已提交”“待业务看”“等反馈”“验收通过”四个状态。我会先检查它们是否分别代表稳定阶段。梳理后发现，“已提交”和“待业务看”实际都表示成果已交付给验收方；“等反馈”是异常等待原因；“验收通过”则是验收完成后的结果。因此，不必把四个想法都照搬进主流程。

2. 用少量状态区分主阶段，用责任字段呈现执行人

调整后的示例流程为“待澄清，准备中，执行中，待验收，已完成”。如果发生外部等待，卡片仍保留当前主阶段，同时填写阻塞原因、跟进责任人和需要的输入。这样管理者既能看出任务所处阶段，也能区分正常验收和临时卡住。

“待验收”的规则明确为：执行人已提交约定交付物并标注检查范围后进入；验收人负责检查；通过后转入“已完成”；未通过则写明差异并退回“执行中”。如果验收超过团队约定的检查窗口，任务负责人先确认验收人是否收到材料，项目负责人再判断是否需要协调升级。

3. 用模拟数据观察规则是否值得保留

下面的数据是用于展示复盘方式的情景模拟，并非真实项目统计。模拟团队在调整前后分别抽取相同数量的卡片进行观察，重点不是宣称效果，而是展示可以用什么指标判断状态设计是否改善了可读性和交接质量。

这组观察指标比“新增了几个状态”更接近管理目标。即便数据变好，也要避免直接把变化全部归因于看板配置；人员变动、项目复杂度、任务组合和管理节奏都可能影响结果。更稳妥的做法是同时记录口径、样本范围和其他重要变化。

七、不同团队情况下的行动建议与方案取舍

1. 小团队、流程简单：先统一定义，不必急着建审批机制

如果参与角色少、任务路径稳定，通常可以由项目负责人组织讨论，直接为每个状态补充简明定义和责任人要求。初期不需要设计多层审批，只要有人维护规则、有人收集反馈，并约定何时复查即可。

此类团队需要警惕的是照搬大型组织的管理层级，导致改一个状态也要多轮审批。制度的目标是减少误解，不是让看板规则比实际工作更难维护。

2. 跨部门项目：优先定义交接责任和输入条件

多个部门共同完成任务时，状态设计的重点通常不是增加部门名称，而是说明交接何时成立。明确提交材料、接收角色、确认方式和退回路径，比把每个部门各设一列更有助于定位责任。

如果卡片必须经过多方审批，可以在流程中区分关键审批节点；如果只是需要其他团队提供补充信息，则用依赖关系、责任人或阻塞原因呈现，避免把“等待谁”误写成“工作到了哪个阶段”。

3. 多项目、大规模组织：增加规则治理，但允许局部差异

当多个团队共享项目管理平台时，需要规定哪些状态是组织级标准，哪些可以按项目类型扩展，谁有权修改默认流程，以及变更如何通知相关成员。规模越大，状态含义不一致造成的报表失真和跨项目协作成本越高。

但治理不等于所有团队使用完全相同的流程。建议先统一关键定义和公共数据口径，再允许特定业务在有明确理由时增加局部状态，并记录适用范围、维护人和退出条件。若需要评估 PingCode 或其他项目管理平台，应把组织规模、部署要求、既有流程迁移、权限治理和集成情况放进同一份评估清单，而不是只比较某个功能是否存在。

4. 高合规或高风险流程：优先保证证据链与变更记录

涉及审计、合规、安全或重大业务承诺的流程，状态定义必须能对应检查证据和批准责任。哪些角色可以改变关键状态、是否要留存变更记录、未通过如何退回，都应与组织的风险要求和制度文件一致。

这类场景不适合只凭项目组讨论设定规则。项目负责人可以组织实施，但业务控制方、合规角色或授权审批人应确认关键标准。工具权限能提供一定约束，不能代替正式责任授权。

5. 先简单还是先完整：用维护成本和风险来取舍

状态越少，学习和维护成本通常越低，但过于粗略会让等待、交接和风险被隐藏；状态越细，阶段差异更容易观察，却增加成员判断成本、配置成本和治理负担。决策时要同时看任务复杂度、交接频次、失败成本和团队维护能力。

当团队无法稳定维护细状态时，选择简单方案并保留必要的风险标记，往往比配置一套无人遵循的精细流程更可靠。若组织确实需要细分，就同步投入规则维护和成员培训，不要只把治理成本留给项目负责人个人承担。

八、上线检查与持续复盘：判断状态是否真的有用

1. 上线前检查清单

• 每个状态是否有不同且可理解的业务含义？
• 是否写明进入条件和退出条件，而不是只写状态名称？
• 每张卡片是否能识别当前推进责任人？
• 状态是否被用来承载优先级、部门或临时备注？
• 阻塞、退回、等待输入和验收失败分别如何处理？
• 谁维护状态规则，谁可以提出变更，谁确认关键要求？
• 工具权限、提醒和自动化是否符合实际流程与组织授权？
• 团队是否有试点、反馈渠道和规则复查安排？

如果清单中有关键问题没有答案，不必为了按期上线而勉强发布复杂规则。先把不确定项标为待验证，使用小范围试点收集事实，通常比把未经验证的流程迅速扩散到所有项目更安全。

2. 复盘时观察过程质量，不只看完成数量

只统计完成任务数，容易忽略任务复杂度和返工情况。可以同时观察卡片在各状态停留时间、状态反复流转次数、阻塞原因是否有负责人、退回原因是否可追踪、责任人字段是否有效等信息。它们帮助团队判断问题究竟在流程定义、交接、资源安排还是决策速度。

每项指标都需要明确口径。例如，状态停留时间从首次进入开始还是从最近一次进入开始，卡片暂停期间是否计时，跨工作日如何计算，都应提前说明。口径不一致时，图表看起来精确，实际却无法比较。

3. 用状态变更记录验证改动，而不是凭印象判断

每次新增、合并或改名都记录改动原因、预期解决的问题和观察方式。复盘时不仅问“大家觉得好不好用”，还要拿出卡片样本检查：误放是否减少？交接是否清楚？阻塞是否更早暴露？有没有产生新的操作负担？若没有改善，应允许回退或调整。

状态规则不是一次性设计的静态配置，而是团队对工作方式的共同约定。复盘的目的也不是不断增加精细度，而是找出最小、足够、可持续执行的规则集合。

九、结语：先让责任和下一步可见，再让状态变多

1. 用一个问题检查看板设计

如果团队成员只看到一张卡片的当前状态，能否在不额外私聊的情况下判断下一步是什么、由谁负责、什么条件下才算完成？如果答案是否定的，优先补齐责任、进入条件、退出条件或异常处理规则，而不是马上再增加一个状态。

2. 下一步从三件小事开始

今天就可以抽取几张正在进行和已经停滞的卡片，核对它们的状态是否准确、下一步是否明确、责任人是否知情。随后选一个最常引起争议的状态，写出进入条件、退出条件和卡住时的处理办法，再让实际执行者试用并反馈。

看板的价值不在于把每种情况都画成一列，而在于把工作进度、责任归属和异常信号变成团队看得见、接得住、能复盘的规则。状态设计得越贴近真实工作，负责人制度就越不需要靠反复催问维持。