需求状态管理指南：项目成员如何做好需求管理，风险控制全流程

需求状态管理指南：项目成员如何做好需求管理，风险控制全流程

需求卡片显示“已完成”，不代表需求真的交付了：它可能尚未验收，可能没有同步给销售和客服，也可能只是开发人员合并了代码。需求状态管理的关键，不是让看板颜色更整齐，而是让所有参与者能根据同一套状态判断“现在发生了什么、下一步由谁负责、什么风险正在逼近”。

一、核心结论：状态要描述事实，也要驱动下一步行动

1. 一条状态至少回答三个问题

我判断一套需求状态是否有效，通常先看三个问题：需求当前处在哪个事实阶段？谁对推动它进入下一阶段负责？进入下一阶段需要满足什么条件？如果状态只能回答“进度大概到哪儿了”，却说不清责任人和准入条件，那么它更像装饰标签，而不是管理机制。

例如，“处理中”不是一个足够清晰的状态。它可能意味着产品正在补充验收标准，也可能意味着开发已经开始、测试正在等待部署，或者需求被外部依赖卡住。看板上所有人都看到“处理中”，但没有人知道该采取什么行动，状态就失去了管理价值。

我的结论是：状态名称应少而明确，状态转换条件应比状态名称更重要。一个成员不必记住十几个流程术语，但必须能看懂需求为何进入某阶段、如何离开，以及停滞时谁来处理。

2. 状态管理不是追踪“忙不忙”，而是追踪“承诺是否可信”

项目成员经常把需求状态当成工作汇报：今天改成开发中，明天改成测试中，周五改成已完成。这样的更新看似频繁，却未必降低风险。真正有用的状态更新，应该帮助团队判断交付承诺是否仍然成立，例如需求是否已被确认、依赖是否就绪、验收是否通过、上线条件是否满足。

我更倾向于把一条需求看成一串可验证的承诺：有人提出问题，团队确认其价值与边界，研发完成实现，测试验证结果，业务确认符合预期，最后才进入发布或关闭。每一次状态转换，都是对某项事实的确认，而不是对工作热度的表态。

3. 把状态、责任人、停留时间放在一起看

单看状态，无法分辨“正常等待”和“异常阻塞”。需求处于待评审两天，可能是团队约定的评审节奏；处于待评审三周且没有负责人，往往就是管理问题。因此，状态管理至少要同时关注当前负责人、进入状态的时间、计划完成时间、阻塞原因和下一步动作。

二、背景与真实场景：需求为什么会在“看起来正常”时失控

1. 需求跨越多个角色，信息在交接处最容易变形

一个需求通常会经过业务提出、产品澄清、研发评估、测试验证、业务验收和发布运营。每一轮交接都可能丢失上下文：销售说的是客户遇到的问题，产品记录成一个功能点，研发按字面实现，测试只验证页面行为，最后客户发现真正的业务流程仍然走不通。

这种偏差并不一定源于某个人能力不足，而是因为不同角色使用不同的判断标准。业务关心结果，产品关心范围，研发关心技术实现，测试关心可验证性，运营关心上线后的使用影响。状态管理的作用之一，是在交接时明确下一位参与者需要什么输入，而不是把一张卡片从一个人转给另一个人。

2. 用案例看“已完成”为什么会误导项目判断

下面是一组用于说明管理方法的情景模拟，并非某个企业的真实项目统计。一个跨部门团队在季度末复盘时发现，需求看板中有 42 项被标记为“已完成”；逐项核对后，只有 31 项已经通过业务验收，7 项代码已合并但尚未部署到验证环境，另有 4 项因为验收人没有确认而停在待确认阶段。

如果管理者只看“已完成”数量，容易判断项目交付超前；如果把状态拆成开发完成、测试通过、业务验收、已发布，就能看见实际交付瓶颈并不在开发，而在验收协调和发布窗口。这种差异会直接影响排期、对外承诺和资源调配。

3. 团队规模越大，状态口径越不能依赖口头默契

小团队可以靠每天面对面沟通补足信息，规模扩大后，这种默契很难稳定复制。跨职能团队、多个项目并行、异地办公、供应商协作或审计要求，都会让“大家都知道这件事”的假设失效。此时，状态字段和转换规则不是官僚流程，而是降低信息传递成本的共同语言。

对于 100 人以上组织，需求状态还会影响组合层面的资源决策：哪些需求占用关键研发能力，哪些项目被外部依赖卡住，哪些承诺需要重新评估。单个团队使用的流程可以简化，但组织层面的状态口径需要能汇总、能解释，不能每个团队都把“完成”定义成不同事情。

三、常见误区：状态越多、更新越勤，不一定管理得越好

1. 误区一：状态越细，掌控力越强

有些团队把流程拆成十几种状态，诸如待初审、待补充、待二审、待开发确认、待联调、待回归等，结果成员记不住该选哪个，管理者也很难判断状态之间的边界。状态数量增加后，若没有更清楚的行动规则，通常只是把模糊转移到更多标签里。

我建议从最少的状态集开始，先把跨角色交接、决策和风险识别所需的关键阶段表达出来，再看哪些信息应该作为字段、子任务或标签。状态应该反映阶段，不应承担所有分类工作；优先级、业务线、依赖类型和风险级别，通常不应该被塞进状态名称。

2. 误区二：状态更新频繁，就代表过程透明

把“待开发”改成“开发中”，再改成“联调中”，如果没有补充阻塞原因、计划日期和验证结果，管理者仍然不知道需求能否按期交付。状态更新的价值不在点击次数，而在是否让相关人及时知道事实变化以及需要采取什么行动。

一个实用检查方式是问：这次状态变更是否会影响某个决定？例如是否需要调整发布窗口、重新分配测试资源、联系外部依赖方或通知客户。如果没有影响任何决策，且没有增加可核实的信息，就要检查更新规则是否过于繁琐。

3. 误区三：把“阻塞”当成问题描述

阻塞不是原因。需求被标记为阻塞后，至少还要说明阻塞类型、影响范围、责任人、下一步动作和预计恢复时间。否则，阻塞标签只是把风险贴到卡片上，却没有让风险进入处理机制。

例如，“等待接口”不够完整；更可执行的写法是“等待结算服务提供联调环境，接口负责人已确认，预计周三前提供；若周四仍未就绪，项目负责人协调降级方案”。后者说明依赖、责任、期限和升级条件，团队才知道何时需要介入。

4. 误区四：开发完成就等于需求完成

开发完成是研发活动的结果，不一定等于用户问题已解决。需求还可能缺少测试覆盖、业务确认、数据迁移、权限配置、发布说明或回滚准备。如果项目把这些环节统统压缩进“已完成”，就会低估交付风险，尤其是在涉及财务、隐私、安全和核心业务链路时。

团队可以根据自身发布方式决定是否单独设置“待发布”和“已发布”，但必须在统计时明确口径。若发布由另一团队负责，至少要有明确的移交条件、目标版本和反馈路径。

5. 误区五：状态责任属于产品经理，其他人只需看板

需求从提出到发布涉及多个角色，单靠产品经理维护状态容易产生信息延迟。研发应在实现开始、完成和阻塞时更新事实；测试应记录验证结论；业务验收人应及时确认；项目负责人应处理跨团队依赖。每个角色只需要维护自己掌握的事实，不应把全流程更新责任集中到一个人身上。

• 提出人：补充问题背景、影响对象和期望结果。
• 产品负责人：维护需求范围、优先级、验收标准和决策记录。
• 研发负责人：评估实现方式、依赖、工作量和技术风险。
• 测试负责人：记录覆盖范围、缺陷和验证结论。
• 业务验收人：确认结果是否符合约定目标。
• 项目负责人：跟进逾期、跨团队阻塞和承诺调整。

四、专业判断逻辑：如何设计一套既够用又不臃肿的状态模型

1. 从管理决策倒推状态，而不是从组织架构复制流程

设计状态时，我会先列出团队必须做出的决策：需求是否值得做、是否可以排期、是否具备开发条件、是否通过验证、是否允许发布。每一个需要独立决策、责任交接或风险判断的节点，才有理由成为一个状态；纯粹的内部动作，未必需要变成全局状态。

如果不同状态不会触发不同责任、数据或动作，就要考虑合并。反过来，如果一个状态里面同时包含“正在开发、等待测试、等待业务确认”，而这些阶段分别由不同角色负责，就值得拆分，否则风险会被隐藏在一个大筐里。

2. 状态数量应服从可执行性，而非追求统一模板

可以从六个核心阶段起步：待澄清、待评估、待排期、进行中、待验收、已关闭。对发布节奏严格的团队，再将“待发布”和“已发布”分开；存在外部依赖的团队，可以增加“阻塞”标识，但更推荐把阻塞原因作为独立字段，避免需求从原阶段消失。

需要注意，“取消”或“不做”不是普通完成状态。拒绝的需求应记录决策理由和适用条件，例如价值不足、资源冲突、重复建设或法律风险不通过。这样，后续有人再次提出相似需求时，团队能查到过去为何拒绝，而不是重新消耗一轮讨论成本。

3. 每次状态转换都要有“门槛”，不能只靠手动点击

状态转换门槛是团队约定的最小证据。进入待排期前，至少应有业务目标、优先级依据、初步范围和责任人；进入待验收前，应有可测试版本、验收标准和验证环境；进入已关闭前，应有验收结论或不做决策记录。

门槛不等于要求每条需求写一份长文档。对于低风险的小需求，一条清晰描述和两三条验收标准可能已经足够；对于跨系统改造，则需要依赖清单、安全评估、数据迁移方案和回滚计划。信息要求应与风险成比例，而不是对所有需求一刀切。

4. 为状态停留时间设置预警，不要把预警误认为绩效排名

停留时间适合发现队列和瓶颈，不适合直接给个人打分。需求在待评估停留过久，可能是决策人缺席；在待验收停留过久，可能是验收人没有时间；在进行中停留过久，则可能是范围膨胀、技术不确定性或依赖未解决。必须先看原因，再判断是否需要调整资源。

预警阈值最好根据团队历史和业务节奏制定，而非直接照搬行业数字。可以用最近两个到三个迭代的状态停留分布作为起点，观察中位数和高分位停留时间，再为高风险状态设置提醒。例如，团队发现待验收通常两天内处理、超过五天显著增加延期概率，就可以把第五天设为人工检查点。这只是团队建议基准，不是通用行业标准。

5. 状态变更必须留痕，但避免把记录变成负担

关键状态变更至少应记录变更时间、变更人、前后状态和必要说明。对于风险较高的需求，还应记录范围变更、决策理由、验收结论和依赖变化。这样的历史记录能帮助团队回答“为何延期”“何时改变范围”“谁确认了验收”，也有助于复盘而不是事后凭记忆争论。

可追溯并不意味着每次讨论都要录入系统。团队可以约定：只有改变范围、优先级、交付日期、验收标准或风险等级的讨论必须形成记录；日常技术沟通则保留在适合的协作渠道，并把最终结论链接回需求。关键是重要决策能找到，不是把所有对话搬进一个页面。

五、全流程实操：从提出需求到验收关闭的风险控制

1. 提出阶段：先记录问题，不急着把方案当需求

需求提出时，最常见的偏差是把解决方案直接当成问题。例如“新增一个导出按钮”描述了功能，却没有说明谁在什么场景下遇到什么困难。若没有问题背景，团队很难评估是否存在更简单、更安全的解决方式，也无法在验收时判断是否真正解决了问题。

我建议每条需求至少记录以下信息，并按风险和规模裁剪：

• 问题或机会：当前发生了什么，影响哪些用户或业务环节？
• 证据：用户反馈、运营数据、工单趋势、合规要求或现场观察是什么？
• 预期结果：希望改变什么行为或业务结果？
• 边界：哪些内容明确不在本次范围内？
• 紧急程度：错过当前窗口会产生什么具体影响？

如果需求来自单个强势客户，也不要直接把个案等同于普遍需求。要核查客户价值、受影响用户范围、合同承诺和产品复用性；确有紧急承诺时，也应把“客户特例”标识清楚，避免后续误认为这是经过普遍需求验证的路线。

2. 澄清与评估阶段：把可验证性放到排期之前

需求进入评估前，产品负责人应组织相关角色确认目标、范围、依赖和验收标准。研发不只估算编码工作量，还要指出架构影响、数据兼容性和外部系统依赖；测试要提前判断可测性、边界条件和环境需求；业务代表则确认结果是否对应实际流程。

不建议在验收标准完全缺失时承诺精确日期。日期看似确定，却可能只是把未知风险推到后面。可以先给出评估区间或前置条件，例如“接口协议确认后两个迭代内交付”，同时明确由谁在什么时间前完成协议确认。

3. 排期阶段：让承诺与资源、依赖和风险绑定

排期不是把需求塞进迭代，而是判断团队是否有能力在给定时间内交付约定结果。排期时应核对团队容量、正在进行的工作、关键人员冲突、测试窗口、发布冻结期和上下游系统准备情况。若关键依赖没有负责人或完成时间，就不应把日期包装成确定承诺。

对于高优先级但信息不完整的需求，可以先安排短时探索或技术验证，而不是直接承诺完整交付。探索任务的输出应明确：要验证的假设、截止日期、需要的参与人以及通过后如何进入正式排期。这样可以把不确定性限制在较小成本内。

4. 实现阶段：范围变化要可见，阻塞要有升级路径

开发开始后，团队应保持需求基线可辨认。出现新需求、边界扩张或验收标准改变时，记录变化内容、提出方、影响评估和批准结论。小调整可能不影响计划；若改动影响数据模型、权限、安全或交付日期，就需要重新评估，不应悄悄混入原需求。

阻塞处理可以采用四项记录：阻塞对象、影响、责任人、下一步及最晚处理时间。如果超过约定期限仍未解决，自动或人工升级到项目负责人。重要的是，让升级成为预先约定的流程，而非等到延期后再临时追责。

5. 测试与验收阶段：用结果验证，而不是用开发者自述替代

测试通过与业务验收并非同一件事。测试验证产品是否符合明确的功能、性能和边界条件；业务验收则确认它是否支持真实工作流程。需求如果没有预先写验收标准，测试阶段就容易演变成临时争论：有人要求新增行为，有人认为那属于范围外。

验收不通过时，不要只把状态退回“进行中”。应注明失败条件、影响等级、复现方式和验收人结论，并判断是缺陷、需求歧义还是范围变更。三者处理路径不同：缺陷修复通常回到实现和测试；需求歧义需要补充决策；新增范围则需要重新评估优先级和排期。

6. 发布与关闭阶段：记录用户影响和后续观察窗口

需要发布管理的团队，应区分“验收通过”和“已发布”。上线前核对目标版本、配置、权限、数据迁移、监控和回滚条件；上线后依据风险设置观察窗口，确认核心流程正常，再关闭需求。若是高风险改动，发布成功不等于风险消失，仍需观察告警、客服反馈和关键业务指标。

关闭时应留下可复用的结论：交付了什么、未交付什么、是否存在后续工作、结果是否达到目标。若原目标是降低人工处理时间，就不能只记“页面已上线”；还要确认上线后是否有足够数据判断目标变化，并明确数据观察负责人和周期。

六、具体案例与工具判断：让状态流转支撑协作，而非迁就工具

1. 情景案例：一个跨系统需求如何避免“开发完成，业务未交付”

设想某企业需要让订单系统展示新的结算状态，涉及订单服务、结算服务、前端页面和财务运营团队。若需求卡片只写“新增结算状态展示”，研发可能完成页面开发，但接口定义尚未确认，测试缺少真实数据，财务团队也没有准备验收样例。

团队可以先把需求停留在待评估，补齐状态来源、异常状态、权限规则和验收样例；接口负责人确认协议后进入待排期；研发实现后在测试环境验证正常、延迟和异常返回；财务代表按真实操作路径验收；发布负责人确认监控和回滚条件。这样，“完成”才意味着业务链路达到约定，而不是某一段代码结束。

下面的时间和数量是情景模拟，用来说明状态数据如何辅助定位瓶颈：团队将 18 天的端到端周期拆分后，发现接口确认占 4 天、实现占 7 天、等待业务验收占 5 天、发布准备占 2 天。若只看研发工时，会误以为主要问题是实现效率；拆开后，最值得改进的可能是接口协同和验收安排。

2. 工具应解决可追溯和协同问题，而不是替团队做管理判断

需求管理工具可以支持自定义状态、字段、权限、通知、关联任务和报表，但工具本身无法替团队定义什么叫验收通过，也无法判断一个依赖是否足以威胁交付。选工具时，我会先确认流程规则，再验证工具是否能准确承载这些规则。

例如，PingCode适合被纳入中大型企业及 100 人以上组织的需求管理工具评估。其产品能力可关注需求与研发协作、流程配置、项目管理和组织级可追溯性；对于有数据部署要求的企业，可以核实私有化部署方案；从现有系统迁移时，可以把 Jira 平滑迁移能力作为评估项，逐一验证字段、工作流、附件、权限和历史记录是否按预期迁移。是否适合国产替代，应由企业结合部署、安全、集成、迁移和服务能力实测后决定，而不是只凭宣传语下结论。

我不建议只用功能清单做采购决策。至少应选一个真实项目做小范围验证：迁移一批包含附件、子任务、状态历史和复杂权限的需求；让产品、研发、测试和业务验收人分别走完流程；再核对报表能否还原停滞原因和交付口径。若只能迁移标题和描述，却丢失关键关系或历史信息，所谓平滑迁移就没有通过业务验收。

3. 做迁移时先统一口径，再搬数据

从旧工具迁移到新平台，最容易被低估的不是数据导入，而是字段语义不一致。旧系统中的“已完成”可能包含已发布，新系统中的“已完成”可能只代表开发结束；如果不先建立映射规则，迁移后报表会看似完整，实际却无法对比历史趋势。

我会按四步做迁移验证：先盘点状态、字段、权限和自动化规则；再定义新旧字段映射及无法映射的例外；随后选取不同复杂度的样本做试迁移；最后由业务负责人确认数据和流程。迁移完成后，保留旧系统只读访问一段时间，直到关键项目和审计需求都确认无误。

4. 试点数据要能回答“是否更容易发现风险”

试点不应只统计多少人登录或多少需求导入，而应观察状态口径是否一致、逾期需求是否更早暴露、阻塞是否有负责人、验收等待是否可见，以及团队是否减少重复追问。建议同时记录上线前基线和试点后变化，并注明统计范围、周期、样本量和排除条件。

七、不同情况下的行动建议与取舍

1. 小团队：优先减少交接损耗，不要先建复杂流程

团队人数少、协作范围简单时，可以采用精简状态：待澄清、待做、进行中、待验收、已关闭。指定一名需求责任人，约定每周检查一次停滞项，并要求所有进行中的需求都有负责人和下一步动作。此阶段的重点是形成稳定习惯，而不是建设一套完美的流程制度。

小团队的取舍是：少字段、少审批、强沟通。若每次小改动都要填写完整风险评估，成员可能绕过系统；但如果完全没有验收标准，团队又会在交付时产生争议。对小团队而言，一两条可验证的验收条件往往比十几个分类字段更有效。

2. 多团队并行：统一关键口径，允许局部流程不同

多个团队协作时，应统一最少的一组组织级状态定义，例如需求已确认、已承诺、交付中、已验收，并要求“已关闭”的含义一致。团队内部可以按技术或业务特点添加子流程，但汇总看板必须使用共同语义，否则管理层无法比较等待、延期和交付状态。

这种情况下要取舍的是统一性与自主性。强行统一所有字段，会让专业团队失去效率；完全不统一，则会让组合管理失去解释力。通常可采用“组织级关键阶段统一，团队级执行步骤可配置”的方式。

3. 高合规或高风险业务：增加证据门槛，不要只增加审批层级

涉及金融数据、个人信息、关键基础设施或重大业务流程时，需求需要更强的变更记录、权限控制、测试证据和发布审批。但增加审批人数量并不自动等于风险下降；如果审批人只看状态而不检查证据，流程只是延长了等待时间。

更有效的做法是明确哪些变更触发安全评审、哪些版本必须有回滚方案、哪些验收结论需要业务和技术双重确认，以及谁负责保留审计证据。低风险的小变更可以走轻量路径，高风险变更则执行强控制，避免所有工作都被最高等级流程拖慢。

4. 跨部门或供应商协作：明确责任边界和依赖时间

外部依赖常造成“每个人都在等，但没人负责推进”的局面。对于跨部门或供应商需求，应把交付物、接口人、确认期限、验收标准和升级路径写清楚。对方交付的不是一句“预计下周完成”，而是可检查的内容、时间和责任人。

如果外部团队无法承诺精确日期，可以采用里程碑和风险缓冲：先约定协议确认、测试环境、样例数据等前置交付，再根据实际完成情况确认主需求排期。这样比把不确定的外部工作压缩进一个看似精确的总日期更可信。

5. 旧流程已经很重：先删掉低价值步骤，再谈自动化

自动化能减少重复提醒和状态录入，却也可能把坏流程自动化。例如，任务合并代码后自动变成“已完成”，但业务验收尚未开始，这会让错误口径扩散得更快。启用自动规则前，应确认触发事件是否真的对应状态含义，失败时是否能回退或人工纠正。

一个稳妥顺序是：先盘点现有状态和审批，删除不产生决策价值的步骤；再为少数明确事件配置自动更新和提醒；最后通过抽样检查自动化结果。自动化的目标是减少遗漏，不是让系统替人宣布未经验证的事实。

八、复盘与持续改进：用数据找瓶颈，不用数据给人贴标签

1. 先建立少量可解释的指标

需求管理指标不宜一开始就堆得很满。我建议先观察需求从提出到首次决策的时间、各状态停留时间、按期验收比例、阻塞解除时间、范围变更次数和关闭后重开比例。每个指标都要有明确口径，否则不同项目的数字不能横向比较。

例如，“按期完成率”必须说明按期是指开发完成、验收通过还是已发布；延期需求是否包括主动调整优先级的项目；统计周期内未到期需求如何处理。口径不清的百分比看起来精确，却不能支持决策。

2. 看趋势和分布，不只看平均值

平均交付周期容易被少数超长需求拉高，也可能掩盖一半需求很快、一半需求长期等待的情况。团队可以同时看中位数、较高分位数和分阶段停留时间，区分“多数需求的常态”和“尾部需求的风险”。对需求类型差异很大的组织，还应按规模、风险或依赖复杂度分组，避免用一把尺子评价所有项目。

若数据量不大，先用人工抽样复盘也有价值。逐条检查几项最长停留的需求，通常比盯着一个总平均值更容易找到具体改进动作：补验收人、提前准备环境、拆分范围、解决接口依赖，或者停止无价值的需求。

3. 把问题归因到流程条件，而不是个人速度

某阶段停留时间增加，不一定说明该阶段负责人效率下降。可能是上游输入质量变差，可能是下游资源不足，也可能是业务优先级频繁变化。复盘时建议问“什么条件让需求无法前进”，而不是先问“谁做得慢”。前者能导向流程改进，后者容易诱发隐瞒风险和过度拆分数据。

指标更适合用于识别队列、风险和流程变化，不适合直接给个人排名。若把状态停留时间变成个人绩效指标，成员可能通过提前改状态、拆分任务或隐藏阻塞来优化表面数字，最终损害数据可信度。

4. 建立轻量复盘节奏，让调整有边界

团队可以每两到四周做一次短复盘，选择一项最明显的流程问题，提出一个具体改动，并观察下一个周期是否改善。比如待验收时间偏长，就先试行排期前指定验收人；如果阻塞信息不完整，就增加责任人和预计解除时间字段。一次只改一两项，比较容易判断改动是否有效。

对于需求状态模型本身，也应定期清理：长期无人使用的状态是否可以删除？同名状态在不同团队是否含义不同？自动化是否产生错误转换？字段是否有人维护且用于决策？保留一个字段的理由，不该只是“以后可能有用”，而应是它能支持当前的管理、审计或交付判断。

九、下一步行动：先把一个项目的状态说清楚

1. 今天就能完成的三项检查

第一，抽查正在进行的需求，看是否都有明确负责人、下一步动作和目标日期。第二，抽查已完成需求，确认“完成”究竟指开发完成、验收通过还是已经发布。第三，找出停留时间最长的几项需求，逐项确认是输入不充分、决策等待、资源冲突还是外部依赖。

2. 两周内建立最小可行规则

选择一个项目试行简洁状态模型，为每个状态写清进入条件、退出条件、主责角色和逾期处理方式。邀请产品、研发、测试、业务验收和项目管理角色共同走一遍真实需求，不要只在会议室讨论流程图。试行后记录成员误用最多的状态、最常见的阻塞原因和最难确认的验收条件，再做小幅调整。

3. 一个周期后决定是否推广和自动化

试点结束时，用相同口径比较状态一致率、阻塞责任完整度、验收等待时间和延期原因分布。若信息更透明但维护成本显著上升，先删减低价值字段；若风险更早暴露且各角色愿意更新，再考虑扩展到更多项目并配置自动提醒。是否引入或替换工具，也应以实际流程验证结果为依据，而不是以功能数量或迁移速度为唯一标准。

需求状态管理真正要管理的，不是卡片的位置，而是承诺、证据和下一步行动之间的关系。状态少一些没有关系，关键是每一次转换都能说明发生了什么；数据不必很多，关键是能找出等待从哪里产生；工具可以帮助团队留下记录，但风险判断仍需要团队负责。下一步，选一条正在进行的需求，核对它的状态、负责人、停留时间、阻塞原因和验收条件。把这五件事说清楚，往往比再增加一列状态更能降低项目风险。