需求管理需求收集教程：项目负责人制度设计，避坑指南

需求收集最常见的失控，不是没人提需求，而是每个人都能把自己的想法直接变成“项目必须做的事”。一个业务负责人说客户在催，销售说竞品已经有了，技术说改动只要两天，项目负责人便把三句话合并进排期；几周后才发现，客户并不愿意为此付费，所谓“两天”也不包括权限、数据迁移和验收。需求管理真正要设计的，不是一个提交表单，而是一套能区分事实、判断和承诺的项目负责人制度。

一、先讲结论：项目负责人不是需求收集员，而是决策链的守门人

1. 需求制度要管住“从提出到承诺”的转换

我判断一套需求收集机制是否有效，不先看表单有多少字段，也不先看系统里积累了多少条需求。我会沿着一条链路检查：谁提出问题，谁确认问题真实存在，谁评估影响与成本，谁决定优先级，谁有权对外承诺，谁在上线后确认结果。

如果这些责任没有被明确分开，团队就容易把“有人提出”误认为“应该做”，把“评估过”误认为“已经批准”，把“排进计划”误认为“已经承诺交付”。项目负责人制度的核心，是明确每个阶段的决策权和责任边界，而不是把所有工作集中到一个人身上。

在实践中，我会把需求至少分为四种状态：待澄清、待评估、已决策、已承诺。它们不是换个颜色的标签，而是不同的管理状态。待澄清不进入开发估算；待评估不允许对外报交付日期；已决策仍可能排不上近期版本；只有明确资源与验收条件后，才可转为已承诺。

2. 负责人制度需要三个角色，而不是一个万能负责人

小团队可以由同一个人兼任多个角色，但制度上仍要区分职责。否则，组织一旦扩大，兼任就会变成谁都以为别人已经做过判断。

• 需求发起人：说明问题发生在哪个场景、影响了谁、目前如何处理，并提供可核实的例子。
• 项目需求负责人：维护需求上下文，组织澄清与评估，推动决策记录完整，不替代业务和技术做所有判断。
• 决策人或决策小组：在业务价值、风险、成本和战略方向之间作取舍，并对优先级承担责任。

我会特别提醒团队：项目负责人有权要求补充证据、退回不完整需求、召集评审，但不应因为负责流程，就自动获得代表业务承诺价值或代表技术承诺工期的权力。流程负责人和结果决策人可以是同一个人，但必须能看出他分别以什么身份作出判断。

3. 判断制度质量，先看决策是否可追溯

一条需求在评审后，至少应能回答五个问题：它解决的用户问题是什么；证据从哪里来；不做会有什么后果；做了怎样验收；由谁在什么条件下作出优先级决定。缺其中一项，后续就容易出现“当时不是这么说的”。

建议把目标从“提高需求收集量”改成“减少无证据承诺和反复返工”。前者容易诱导团队多报、多录、求覆盖；后者才能让团队关注输入质量和决策后果。需求数量增加，未必意味着需求管理进步；新增需求中有多少能被复述、验证、估算并作出取舍，才更有判断价值。

二、需求收集为什么会失控：入口多不是问题，责任断点才是

1. 真实场景：同一问题从不同部门进来，最后变成三条需求

设想一个企业服务团队同时收到三条反馈：销售提出“客户想要批量导出”，客服提出“用户经常逐条下载”，运营提出“月底对账效率低”。如果团队只按提交部门分别建单，就可能得到三个名称不同、目标相近的需求。

但三者也可能确实不是同一问题：销售客户需要跨项目汇总，客服关注单个用户的操作便利，运营则受限于财务字段和审计流程。仅凭标题合并，会丢掉关键差异；完全不做归并，又会让重复需求各自争夺研发资源。负责人要做的不是“看起来像就合并”，而是围绕用户、场景、目标和约束判断它们是否属于同一个问题簇。

我会把“原始反馈”和“产品需求”分开保存。原始反馈保留提出者的语境与证据；问题簇用于归并相似情形；正式需求则描述解决方案范围及验收条件。这样既能避免把不同问题揉成一个大需求，也能追溯一个解决方案究竟回应了哪些真实反馈。

2. 多入口最容易制造优先级幻觉

当需求可以通过会议、聊天、邮件、客户群、工单和系统表单同时进入，团队往往误以为“谁喊得最急，谁就最重要”。实际上，声音大小可能与业务影响无关。一个战略客户的单次表达，可能值得快速核查，但并不自动说明该功能适用于多数客户；多个重复投诉可能指向一个高频障碍，也可能只是同一事件被不同渠道转发。

因此，入口可以多样，正式决策入口必须可汇总。负责人需要维护统一台账，至少保留来源、原始描述、发生频次、影响范围、证据附件、当前状态和下一步责任人。所谓统一，不等于强迫所有人使用同一个表单，而是确保不同渠道最终落到同一套可检索、可追踪的记录中。

3. “需求收集会”常常只收集意见，没有收集证据

会议里最容易听见的是结论：“客户需要这个”“大家都觉得不方便”“这个功能很简单”。这些话可以作为线索，却不是完整证据。负责人应继续追问：具体是谁，在什么任务中遇到什么障碍？最近发生了几次？现有替代办法是什么？如果不解决，损失体现在哪里？

追问不是质疑提出者的专业性，而是把主观判断转成可讨论的输入。对业务方来说，清楚说明问题能减少反复解释；对技术方来说，具体场景能减少错误估算；对管理者来说，证据能让多个看似都很重要的需求进入同一把比较尺子。

4. 负责人制度失灵时，通常会出现四个信号

• 需求没有提出者：大家都知道要做，却没人能解释最初的业务场景。
• 优先级不断变动：不是因为新证据改变了判断，而是因为最新一次会议上声音更大。
• 估算经常被当作承诺：技术评估的工作量被转述成发布日期，风险和前置条件被省略。
• 上线后没人验收：功能已经交付，但最初提出问题的人没有确认是否真的解决。

三、常见误区：看起来流程齐全，实际仍在靠人情排优先级

1. 误区一：字段越多，需求质量就越高

表单字段堆得太多，提出者会复制旧内容、随便填默认值，最后形成“信息看似完整、关键问题仍然空白”的记录。字段设计应该服务决策，而不是展示管理的严谨程度。

初始提交可以只收集最关键的信息：问题描述、目标用户、发生场景、影响、已有证据、期望时间和提出人。复杂度、收益测算、风险、依赖关系以及验收标准，可以在进入评估阶段后由相应责任人补充。字段不应要求提需求的人一次性猜出答案，更不能用必填校验假装完成了澄清。

2. 误区二：让业务部门给需求打分，就能得到客观优先级

打分表只能让判断结构化，不能自动产生客观性。业务部门可能高估收入机会，技术团队可能低估采用障碍，管理层可能把战略相关性解释得过宽。若评分标准没有统一口径，数字只是把争论包装成了小数点。

我更看重每一项评分背后的依据。例如，影响范围要说明涉及多少用户或流程；紧急程度要说明错过窗口的后果；成本要包括依赖、迁移、测试和维护，而不只是一句“开发约几天”。遇到关键判断缺乏证据时，应该标记不确定性，而不是强行给出一个貌似精确的分数。

3. 误区三：项目负责人等于产品经理或项目经理

不同组织对岗位名称的使用并不一致，但职责不能靠名称推断。项目经理通常关注进度、资源、风险与交付协同；产品角色关注用户问题、方案和产品价值；业务负责人对业务结果承担责任。项目需求负责人可以承担其中部分协调工作，却不应自动替代所有专业判断。

如果一个人既负责接单、又独立判断价值、批准优先级、估算成本、承诺日期并负责验收，制度就缺少制衡。小团队可以因人少而兼岗，但关键决策仍建议让至少另一名相关责任人复核，尤其是高成本、跨部门或涉及合规风险的需求。

4. 误区四：需求一旦评审通过，就不能再变

需求并非越稳定越好。发现新证据、监管要求变化、客户场景改变时，合理调整比死守旧版本更负责任。真正要防的不是变化，而是没有说明变化缘由、影响范围和重新决策过程。

每次重要变更都应回答：新信息是什么；影响了哪些目标和验收条件；估算、依赖、发布日期和风险是否改变；原批准人是否需要重新确认。这样团队讨论的是“有证据的变化”，而不是把反复加塞包装成敏捷。

5. 误区五：工具能替代负责人制度

工具可以记录状态、分派任务、提醒超期、保留讨论历史，也可以帮助跨团队共享需求。但工具不会替团队决定谁有权批准范围，也无法从一句“客户急用”自动判断机会成本。

组织超过百人、跨产品线协作或需要私有化部署时，平台能力会影响流程能否规模化运行。以 PingCode 这类面向中大型企业及 100 人以上组织的研发管理平台为例，选型时可以核查需求与迭代、缺陷、测试、项目之间的关联，权限与审计能力，部署和迁移方案，以及是否支持 Jira 平滑迁移。支持私有化部署和既有流程迁移是重要条件，但不能单独推出“国产替代不二选择”这样的结论；最终仍要用组织的安全、成本、集成和使用要求逐项验证。

评估平台时，我建议拿真实流程做小范围验证，而不是只看功能清单：挑选一条跨部门需求，检查从提出、澄清、评估、决策到验收能否完整追踪；再挑一条变更频繁的需求，检查权限、历史记录和版本关系是否清楚。工具适配制度，制度也要接受工具使用体验的检验。

四、专业判断逻辑：用五道关口把需求从意见变成决策

1. 第一道关：确认问题，不急着接受方案

需求提出者往往直接给出方案，例如“做个导出按钮”“增加一个审批节点”。负责人先把方案暂时放一边，尝试用一句话复述问题：什么人，在什么情境下，无法完成什么任务，造成了什么影响。

如果不同角色对问题复述不一致，说明团队还没到评估方案的阶段。可以用实际案例、操作记录、访谈纪要或工单样本补足背景。对暂时无法验证的判断，明确标记为假设，并写明下一步由谁验证、何时回看。

2. 第二道关：核验影响，不把单个声音当作总体结论

影响分析不必一开始就追求复杂模型，但要区分事实和推测。发生频次可以来自工单或日志；用户范围可以来自账户或流程数据；营收影响可以基于已验证的合同、续约或转化信息；合规影响则应由适当的专业角色判断。

当数据不完整时，负责人不要填补想象中的精确数值。可以先做小样本访谈、查看一段时间的支持记录、观察任务完成情况，或与提出者一起走一遍现有流程。关键不是立刻证明每项需求都值得做，而是让重要判断的依据透明。

3. 第三道关：评估成本与风险，而不只问开发要几天

需求成本至少包含方案设计、开发、测试、数据处理、权限调整、发布协作、用户迁移和后续维护。尤其是跨系统改动，表面上的一个字段或按钮，可能牵连报表、接口、权限、历史数据和培训。

我会要求技术评估说明估算边界：哪些条件成立时估算有效，哪些依赖尚未确认，什么情况会导致返工或延迟。业务方也要说明可接受的最小范围。例如，先支持单个团队还是所有客户，先满足关键路径还是一次覆盖所有例外。缩小范围不是降低质量，而是用更低成本验证关键假设。

4. 第四道关：比较机会成本，明确为什么现在做

优先级并不是给需求贴一个高、中、低就结束了。真正的比较问题是：在资源有限时，做这件事比做其他候选事项更值得吗？放弃它，团队会错过什么？选择它，又要推迟什么？

可以采用简单的评分模型做初筛，但必须保留讨论与决策记录。以下是一个便于初期使用的示意框架：价值、影响范围、时间敏感性和战略相关性加分；成本、不确定性和依赖风险作为扣分或单独标记。不要把公式输出直接当作最终结论。

5. 第五道关：定义验收与回看，让决策闭环

验收标准要能判断问题是否改善，而不只是功能是否上线。比如“增加批量导出”是交付描述；“目标角色完成月度核对所需时间下降，且数据字段准确率达标”更接近结果描述。两者可以同时保留，但不能互相替代。

需求转为已承诺时，负责人应核对范围、责任人、依赖、计划、验收方式和变更规则。上线后则由需求发起人或业务验收人确认目标结果，并记录未达成的原因。若收益需要较长时间才显现，可以约定回看时间，避免上线当天就宣称价值已经实现。

五、具体案例：批量导出需求如何经过负责人制度筛选

1. 初始表达：先记录原话，再把问题说完整

下面是一个用于说明流程的情景模拟，不代表任何企业的真实客户数据。某业务团队提出：“希望尽快增加批量导出，不然客户会流失。”如果负责人直接把这句话转成开发任务，后续就无法判断到底是下载速度慢、文件格式不适用、权限不足，还是月末对账流程本身过于复杂。

负责人先保留原始表达，并追问具体场景。业务方补充：主要反馈来自需要按月核对项目费用的客户；当前操作需要逐项下载多个文件，再由员工手工汇总；用户提出的愿望是“一次导出全部”，但他们是否需要所有字段、所有项目和所有历史数据还没有确认。

经过这一轮澄清，问题可以暂时表述为：“部分客户在月度费用核对中需要汇总多个项目的数据，逐项下载和手工合并增加了操作时间。”注意，这仍是待验证的问题描述，不等于已经证明批量导出是最佳方案。

2. 证据补充：把声量拆成频次、影响和不确定性

负责人从支持工单中筛出相关记录，核对反馈时间、客户类型与实际操作步骤，并请两位业务代表演示当前流程。假设这次情景模拟收集到 12 条相关反馈，其中 5 条能对应到同一类月度核对任务，另外 7 条实际涉及不同问题。这个结果提醒团队：12 条反馈不能简单等同于 12 个相同需求。

接着，团队与少量代表用户核对最小需求：他们是否只需要指定字段，是否可以按项目筛选，是否必须在某一时间完成，当前是否已有表格或接口替代办法。若无法确认目标用户普遍需要“全部数据”，就不应把“全量导出”当作唯一解法。

3. 方案评估：比较小范围验证与完整建设

技术评估发现，最小版本可以先支持指定范围和固定字段导出，但全量历史数据、细粒度权限与可配置模板会增加测试和维护复杂度。业务方则认为，月末对账是高频任务，但可接受先验证一个项目范围。

在这个情景中，决策小组选择先验证方案乙，但不承诺后续一定扩展到方案丙。决策理由不是“方案乙打分最高”，而是它与已确认的任务更接近，范围又小于完整报表平台；同时，团队把权限验证和数据量测试列为进入正式交付前的条件。

4. 验收方式：检查任务是否变好，不只检查按钮是否出现

团队为试点设定三个观察点：目标用户是否实际采用；月度核对步骤是否减少；导出数据是否满足核对需要且权限控制正确。具体阈值应根据业务基线与风险确定，而不应为了让项目通过而临时选择。

以下数字仅用于说明如何设计观察指标，是情景模拟，不是实测结论：试点前后各观察一个完整核对周期，记录参与用户数、每次任务耗时和需要人工修正的记录比例。若采用率低，即使功能按时上线，也要继续调查用户是否不知道入口、字段不合用或现有做法已经足够。

六、不同团队的行动建议：先匹配治理强度，再增加流程

1. 十人以内的小团队：先解决口头承诺和遗忘

小团队不需要一开始就搭建复杂委员会。指定一名需求协调人，建立一个共享台账，规定所有正式需求都要记录提出者、场景、问题、证据、优先级决定和验收人。每周用固定时间处理新需求，紧急事项也要补记原因，避免“口头插队”成为默认机制。

如果创始人或负责人直接作出决策，也应留下简短记录：为什么现在做，推迟了什么，哪些条件尚未确认。小团队流程的目标不是增加审批，而是让核心人员离开会议后仍能复原当时的判断。

2. 多团队、百人以上组织：把分类、权限和依赖纳入制度

组织规模扩大后，单一需求列表会变成拥挤的意见池。建议按产品、业务域或项目建立明确的归属规则，给每个需求指定业务负责人和交付责任人，并通过统一分类、状态定义和字段口径保持跨团队可比较。

这类组织还应关注跨团队依赖、权限隔离、审计记录、历史数据和系统集成。若评估 PingCode 等研发管理平台，应以实际流程验证需求与项目、迭代、测试和缺陷等对象之间的关联，检查现有数据迁移路径和私有化部署要求是否满足约束。对已经使用 Jira 的团队，还应把字段映射、工作流、权限和历史记录纳入迁移演练，而不是只做一次导入测试后就假设平滑迁移已完成。

3. 强监管或高风险业务：提高证据门槛，保留审批链

涉及隐私、财务、医疗、关键基础设施或监管义务时，需求价值不能覆盖安全与合规审查。应明确哪些需求必须经过安全、法务、数据治理或合规角色确认，并保留批准人、审查结论、风险接受范围和变更历史。

这类团队不宜把“快速上线”当作唯一效率指标。一次未记录的权限变更，后续可能带来远高于开发成本的调查和整改。可以通过标准化风险分类减少重复审查，但不能让自动流程代替责任人的正式判断。

4. 客户反馈量大、渠道分散的团队：建反馈归并机制

如果客服、销售、客户成功、社区和产品访谈都在持续产生输入，重点是建立反馈来源与正式需求之间的映射。每条原始反馈保留出处，再将相似反馈归入问题簇；当某问题簇出现明显变化时，回看不同客户类型、使用频次和场景差异。

对大客户的个别需求，既不要因为体量大就自动优先，也不要因为样本少就自动忽略。应分别评估合同风险、战略价值、产品通用性、定制成本与后续维护责任。若只对单一客户成立，要明确它是产品能力、付费服务还是定制交付，避免把一次性承诺悄悄变成全体用户长期维护的功能。

七、制度设计中的取舍：规则越重不一定越成熟

1. 集中决策与分散决策之间，需要设置清晰边界

集中评审有利于跨部门比较、统一资源分配，但可能拉长响应时间；分散决策能贴近现场，却可能造成重复建设和方向不一致。更实用的做法是按影响范围分层：局部低风险需求由团队负责人决定；跨团队、高成本或战略性需求进入更高层级评审；涉及合规与安全的事项增加必要专业审查。

层级不是职位高低的奖励，而应由影响范围、资源占用、不可逆程度和风险决定。把所有小改动都送到最高层，会制造审批拥堵；让每个团队自行批准所有事项，则会隐藏整体机会成本。

2. 快速响应与充分验证之间，要按可逆性取舍

可逆、影响范围小、便于回滚的变更，可以通过小范围试点快速获得反馈。不可逆、涉及历史数据、外部承诺或监管责任的变更，则值得投入更多验证时间。负责人应追问：如果判断错了，撤回需要多久，影响谁，数据能否恢复？

这比简单要求所有需求“快一点”或“评审更严格”更有效。速度应该优先用在低风险学习上；严谨应该用在高影响决策上。团队若把每一项都按最高风险处理，流程会失去辨别力；若把每一项都当成可快速试错，则可能低估不可逆后果。

3. 统一标准与业务差异之间，保留少量可解释的例外

统一字段、状态和优先级口径，能让组织横向比较；但不同产品线的价值指标可能不同。面向内部效率的需求看节省时间和错误率，面向商业产品的需求可能关注采用、续约或收入，合规需求则关注风险控制和审计要求。

我建议统一“如何解释与记录”的要求，而不强求所有业务使用完全相同的价值公式。例外必须说清适用范围、批准人和回看时间，否则例外会扩展成第二套不透明规则。

4. 统一平台与最小工具之间，按协作复杂度选择

早期团队用共享表格或轻量系统，可能比部署复杂平台更划算；当需求状态难以追踪、跨团队依赖频繁、权限审计不足或历史决策无法还原时，平台化才开始产生明显价值。购买工具之前，先说明要解决的管理问题，再验证工具是否支持相应流程。

对中大型企业来说，私有化部署、迁移能力、权限管理、审计、接口和运维成本都应纳入总成本评估。对小团队来说，过度配置工作流、字段和审批层级也会成为负担。选型不是比较功能数量，而是比较工具能否降低当前最昂贵的协作摩擦。

八、避坑清单：让制度落地，而不是停在流程图上

1. 发布制度前，先写清四类决策权限

团队常把“谁负责需求”写进岗位说明，却没有定义谁能做什么决定。至少要区分：谁能提交；谁能退回补充；谁能确定优先级；谁能批准资源和对外承诺。必要时再补充谁能接受风险、谁负责最终验收。

权限表不必写得像组织章程，但要能在真实争议中使用。比如销售能否承诺客户某个版本交付？项目负责人能否擅自调整已承诺范围？技术负责人能否基于风险暂停发布？这些问题如果不在流程上线前说清，最终还是会由关系和临场压力决定。

2. 定义“紧急”时，要求说明逾期后果

紧急不是一个自带优先级的标签。要求申请人说明如果延后一个评审周期会发生什么，并区分外部截止日期、客户表达的期望日期和内部目标日期。若是监管或安全事件，按对应应急机制处理；若只是“希望尽快”，则进入正常队列评估。

对插队需求，建议记录其挤占了哪项已安排工作，以及批准插队的责任人。这样不是为了阻止紧急事项，而是让组织看见加塞的真实成本，避免团队长期处于“每件事都急”的状态。

3. 不要只统计需求吞吐量，也要看返工与兑现情况

需求通过数、完成数和平均处理时间很容易统计，但如果只追这些指标，团队可能倾向于拆小需求、快速关闭状态，甚至降低验收标准。建议同时关注输入质量、决策等待、变更频次、延期原因、上线后结果和未解决问题。

指标应结合上下文解释。例如，需求从提出到决策的时间变长，可能是评审变慢，也可能是团队开始认真核验高风险事项；需求变更增加，可能源于前期澄清不足，也可能是外部环境确实变化。指标用于发现问题，不应用来脱离业务语境给个人排名。

4. 定期清理陈旧需求，避免台账变成仓库

台账里的旧需求不应因为已经存在就永久保留在候选清单。可以为长期未推进的事项设置回看条件：原问题是否仍然存在，提出者是否仍有需求，证据是否过期，外部约束是否变化，当前方案是否已经不再适用。

清理并不等于删除历史。应保留关闭原因和相关决策，以便未来相同问题再次出现时，团队知道过去为什么没有做。好的台账既记录可能性，也记录已经作出的取舍。

九、落地路线：用四周建立一套能运行的负责人制度

1. 第一周：盘点现有入口和决策断点

不要先写一份很长的制度。先抽取近期已经提出、正在排期、被推迟和上线后的需求，回看它们如何进入团队、由谁解释、谁决定优先级，以及问题是否在上线后得到验证。

重点找重复需求、无提出者需求、无验收人需求和没有记录的临时承诺。把问题分为入口、责任、证据、决策、交付和反馈六类，选出最影响团队的两三个断点。制度第一版应该解决真实断点，而不是覆盖所有理论上的例外。

2. 第二周：明确状态、责任和最小必要字段

用一个简明状态流覆盖从提出到回看的全过程，并为每个状态写一句定义和转出条件。字段只保留决策需要的信息，其他资料按阶段补充。与此同时，明确提出者、需求负责人、业务决策人、技术评估人和验收人的职责。

建议选择一条最近发生的需求，按新流程走一遍。如果出现“这个字段谁填”“这个状态谁批准”“现在能不能告诉客户日期”等问题，就现场修订规则。流程能被一个真实案例走通，比文档写得完整更重要。

3. 第三周：开展小范围试运行，记录例外而不是掩盖例外

选择一个团队或一个产品范围试运行一到两周。记录哪些信息经常缺失，哪些步骤造成等待，哪些人仍通过私聊直接提出承诺。不要在试点期追求所有需求都严格遵循流程；先找出规则为何被绕过，是入口难用、责任不清，还是决策周期不适合实际业务。

对紧急事项仍然保留快速通道，但要求记录紧急原因、批准人、影响范围和事后补全时间。这样可以兼顾响应速度与决策可追溯性，也能发现哪些紧急事项其实是长期规划不足造成的。

4. 第四周：复盘结果，确定下一轮改进指标

试点结束后，检查需求是否更容易找到来源，提出者是否知道当前状态，评审是否能比较不同事项，承诺是否有清晰前置条件，验收是否发生在功能上线之后。把数据和访谈结合起来，避免仅凭系统状态判断制度有效。

第一轮不需要建立复杂绩效仪表板。可以只选三项观察指标：需求从提交到完成初次澄清的时间；进入计划后发生范围变更的比例；上线后完成业务验收的比例。结合团队规模与基线设定目标，并在一个周期后再调整。

十、结尾：真正成熟的需求制度，敢于拒绝，也能解释为什么

我对项目负责人制度的判断很简单：它不是把更多需求收进系统，而是让每个重要需求都能说清来路、依据、责任、代价和结果。需求负责人不必替所有人做决定，却要确保决定发生在正确的信息基础上，并且留下能够复盘的记录。

这套制度最有价值的时刻，不是大家都同意做什么，而是团队面对冲突时仍能解释为什么此刻选择它、放弃了什么、哪些条件尚未确定，以及何时重新评估。好的需求管理不是承诺得更多，而是更少做未经证实的承诺，并更认真地兑现已经作出的承诺。

下一步可以从最近十条需求开始：找出来源不明、验收缺失、反复插队和上线后无人回看的事项；为每条补上提出者、问题证据、决策人和验收人；再试行一个月的状态与评审规则。先把一条真实需求从提出走到回看，再决定要不要扩展制度和工具。