需求管理流程 · 现状调研与未来方向探索
联合研讨会逐字稿
流程管理部 · 产品部 · 研发部 · 市场部 联合研讨
👥 参会人员
李静流程管理部 · 流程经理（主持）
王凯流程管理部 · 流程分析师（记录）
张明远产品部 · 产品总监
赵伟峰研发部 · 平台架构师 / 研发PMO负责人
陈雪丽市场部 · 市场运营经理
一、开场与背景说明 14:00 — 14:18
李静
好，那我们开始啊。今天人到齐了，三个业务方代表都来了，咱们流程部这边我和小王，时间不耽误，我先把今天会议的背景快速说一下。（停顿2秒）
李静
大家应该都知道，上个月公司高管层那边过了一个议题，叫"需求管理体系再造"，是 CEO 亲自挂帅的项目，立项编号 P-2026-018。为什么要做这件事？说白了就是过去一年，跨部门最大的吐槽点，就是"需求乱"。产品收的需求、市场报的需求、客户提的需求、销售带回的需求、研发自己识别的技改需求，全部都在系统里乱飞，谁也说不清一个需求从哪来、走到哪、为什么被砍、为什么被插队。
李静
所以我们流程部这次接到的任务是：先做一遍端到端的现状调研，把现在的需求管理流程画出来；然后牵头三个业务方一起，探索未来六个月到一年的目标流程长什么样。今天这场会就是调研启动会，目标只有两个——第一，把每个业务方现在怎么做需求管理的，原原本本讲一遍；第二，初步对一下未来方向上大家有什么想法，不求今天定方案，先把痛点和方向对齐。
张明远
嗯，明白。其实这事我们产品这边也憋了挺久了。每次月度复盘会，研发同学都说我们需求质量不行，市场又说我们响应慢。我们夹在中间，挺难受。今天有这个机会，我得多说点。
赵伟峰
同感。我们研发这边其实更直白一点——大半的火都来自需求侧。需求一会儿改一会儿改，迭代节奏全乱。
陈雪丽
我也想借这个机会反映一下市场这边的难处。我们的需求很多时候是来自客户和合作伙伴的，时效性特别强。但提到产品那边之后，经常就石沉大海了。这个问题困扰我们很久了。
李静
好，那这就是我们今天要解决的问题。我先讲一下今天的会议节奏：第一个小时，三个业务方分别讲现状，每位 15 分钟左右；中间休 10 分钟；第二个小时，我们交叉讨论，把痛点对齐；最后半小时，聊聊未来方向。咱们尽量不打断，每个人讲完再提问。可以吗？
李静
那我先补充一句。今天小王全程录音、转写，会后我们出一版纪要给大家确认。如果有不希望被记录的内容，请提前说明。OK，那张总你先来？
二、产品部 · 需求管理现状调研 14:18 — 14:42
张明远
那我先把我们产品这边的现状捋一遍啊。我们目前是这么做的，从需求来源开始讲。
张明远
我们产品部的需求来源大概有五个口子：第一个是市场部转过来的客户需求；第二个是销售带回来的；第三个是客服或者售后整理的客诉；第四个是产品经理自己做用户调研、竞品分析得来的；第五个是高管或者老板临时插的——这个口子最让人头疼。
张明远
这五个口子的数据，目前是分散的。市场部走的是飞书表格，销售那边在 CRM 系统里，客服在工单系统，产品经理自己用的是 ONES，老板那边……老板那边经常是微信、电话、走廊里碰到他、或者在评审会上拍一下桌子，就成了。
张明远
所以我们做的第一件事，是产品经理每周三、周五各做一次"需求归集"。说白了就是把这五个口子的需求，手动汇总到一张表里。这张表叫"需求池"，是 ONES 里的一个项目空间。
李静
手动汇总？小王你记一下，这是痛点 1：需求源分散，归集靠手工。
张明远
对，手动。每个产品经理每周大概要花半天到一天的时间在"搬运"这件事上。然后归集进来之后，第二步是分类和打标签，比如打"功能类/体验类/合规类/技改类"，再打"高/中/低"优先级。这个分类目前是产品经理凭经验做的，没有标准。
赵伟峰
我插一句啊，就这个"高/中/低"，我们研发这边接到的需求百分之八十都是"高"，剩下百分之二十是"紧急"，从来没见过"低"。
张明远
哈哈，这事我也无奈。因为打"低"以后基本就排不上了，产品经理为了让自己的需求被看见，都往高里打。所以这个标签基本失真。
李静
痛点 2：优先级标签失真，没有客观标准。继续。
张明远
第三步是需求评审。我们每周一上午有一个"产品需求评审会"，会上把池子里新进的需求过一遍。参会的有产品总监、产品经理、研发架构师、UI、有时候市场也来。但说实话，这个会效率非常低。
张明远
为什么低？第一，需求质量参差不齐。有的需求文档写得很详细，有的只有一句话——比如"客户希望支持批量导出"，光这一句话，我们没办法判断要不要做。第二，评审会经常变成需求争论会，产品经理之间互相 PK 自己的需求，谁声音大谁排前面。
陈雪丽
我打断一下啊。批量导出这个需求，如果是市场带过来的，我们后面是有客户原话和场景描述的。但你们这边好像很少看那个原始材料？
张明远
看是看的，但是分散嘛。市场的需求在飞书表格里，链接给到我们之后，产品经理还得点进去看，再回来写到 ONES 里。这个动作经常就漏掉了。最后落到 ONES 的，只剩一句话标题。
李静
痛点 3：需求原始信息流失，从市场到产品再到研发，每跳一次丢一次上下文。
张明远
对，您总结得准。然后是第四步，评审通过之后，需求会进入"待排期池"，由产品总监——也就是我，或者我老板——来跟研发对接，决定下一个迭代做哪些。这个动作目前是个黑盒，外人看不到为什么 A 进了下个迭代，B 没进。
赵伟峰
这个我深有体会。我们研发同事经常在站会上问我："这个迭代为什么这么排"，我也答不上来，因为产品给到我的就是一个排好的清单。
张明远
这块确实需要透明化。然后第五步是开发阶段，需求进研发之后，PRD 会沉淀到 Confluence，研发拿走开发，产品经理跟进。开发过程中如果需求要改，产品经理走变更流程，但说实话，这个变更流程经常是口头变更——产品经理直接微信告诉开发同学"这块改一下"，没有走系统。
赵伟峰
这个是大问题。我们经常迭代到一半，发现 PRD 跟实际开发的对不上，回头查变更记录，没有。最后追责的时候，又开始扯。
李静
痛点 4：需求变更游离于流程之外，没有追溯。张总，再讲一下后面的环节？
张明远
第六步是上线和复盘。上线之后，产品经理会做一个简单的"上线总结"，但说实话，做不做、做得好不好，没人审。理论上每个版本要做"需求达成度复盘"，看看上线的功能跟原始需求差多少，但这个动作目前是缺失的。我们有数据，但没人看。
李静
痛点 5：上线复盘缺失，需求生命周期没有闭环。嗯，张总你这边整体讲下来，我数了一下五个核心痛点。还有要补充的吗？
张明远
还有一个，就是跨部门可见性。市场部和销售部经常问我们某个需求做到哪了，我们的回答永远是"在排期中"，但具体什么时候上、有没有被砍，他们看不到。这个事在我们和市场部之间已经吵过很多次了。
📌 王凯记录小结：产品部痛点共 6 项 ——（1）需求源分散归集靠手工；（2）优先级标签失真；（3）原始信息流失；（4）变更无追溯；（5）上线无复盘；（6）跨部门可见性差。
三、研发部 · 需求管理现状调研 14:42 — 15:08
李静
好，那接下来赵总你来讲一下研发这边的需求接收和管理现状。
赵伟峰
嗯，我从研发的角度来讲，可能跟产品的视角不太一样。我们看到的需求，已经是"加工过"的需求。但即便是加工过的，也有一堆问题。我先把研发侧的链路捋一下。
赵伟峰
研发接收需求的入口主要有两个：第一个是产品的需求，从 ONES 同步过来；第二个是技术债、性能优化、架构升级，这类需求是研发内部识别的，走的是我们自己的 GitLab Issue。
赵伟峰
这两条线是分开的。产品需求在 ONES，技术需求在 GitLab，没有打通。这就导致一个问题：每次排迭代，研发负责人要在两个系统里来回切，手动平衡业务功能和技术改造的比例。这个比例目前是 7:3，大部分迭代实际能做到的是 9:1，技术债越积越多。
李静
痛点 7：业务需求和技术需求双轨制，平衡靠人肉。继续。
赵伟峰
第二个大问题是需求质量。我刚才打断张总也提了，研发拿到的需求质量参差不齐。最差的情况是，PRD 里只有一句话功能描述，没有边界、没有异常情况、没有数据规则。开发同学拿过去，自己脑补，最后做出来跟产品想的不一样，返工。
赵伟峰
为了应对这个问题，我们研发内部立了一个"需求准入清单"，要求 PRD 必须满足 12 项才能开发。但实际执行下来，70% 的需求是不达标的——产品经理太忙、或者产品总监已经拍板了，研发架构师不敢卡。最后还是带病上线。
张明远
这事我承认。我们产品经理人手不够，一个 PM 平均带 4 到 5 条产品线，确实写不出 12 项齐全的 PRD。
赵伟峰
所以根子还是上游归集和初筛的问题。如果上游能把需求过滤掉一半，我们这边的 PRD 才有机会做厚。
李静
痛点 8：需求准入清单形同虚设，研发被动接单。嗯继续。
赵伟峰
第三个问题是排期透明度。研发排期目前是两周一个迭代，每个迭代开始前会有一个"迭代规划会"。这个会上，研发同事会针对产品给的清单，做工时评估、识别风险。但评估出来之后，调整空间很小——产品总监已经定了，超出预算的需求一般是研发同事咬牙加班完成。
赵伟峰
长期下来，团队疲劳、bug 率上升、技术债积累。我们研发部门 2025 年的离职率是 18%，比公司平均水平高 6 个点。我做过访谈，"需求不稳定 + 加班 + 技术债没人管"是 Top 3 的离职原因。
李静
痛点 9：研发承接侧的话语权缺失，长期高压。这个我们后面要重点讨论。
赵伟峰
第四个，需求变更和插队。这是最让人头疼的。一个迭代两周，平均会接到 3 到 5 次插队需求。这些插队需求大多来自老板或者大客户，理论上要走变更流程，实际上往往是产品总监在群里说一声"这个加进去"，研发就得做。
赵伟峰
每次插队的成本是巨大的。一个开发同学被打断，重新进入工作状态平均需要 23 分钟，这是我们做过统计的。一个迭代被打断 5 次，光"切换成本"就吃掉了 10% 的产能。
李静
痛点 10：插队需求成本高，缺少机制化的"变更评估"。
赵伟峰
第五个问题，跨产品线的需求依赖。我们研发部下面有 6 条产品线，A 线提的需求经常依赖 B 线的数据接口。这种依赖目前是靠人工沟通的，A 线 PM 找 B 线 PM 谈，B 线 PM 再回来问 B 线开发能不能排上。这条链路一断，需求就卡住，谁也不知道卡在哪。
赵伟峰
我做过一个统计，2026 年第一季度，因跨线依赖导致延期的需求占比是 31%。这是一个非常恐怖的数字。
李静
痛点 11：跨产品线需求依赖管理空白。这个数据后面要写进调研报告。继续。
赵伟峰
最后一个是度量缺失。我们目前对需求管理的度量很薄。能看到的指标主要是"迭代完成率""bug 数""平均交付时长"。但是像"需求 cycle time"——就是一个需求从提出到上线总共花了多久，"需求拒绝率"，"需求变更率"这些深度指标，我们都没有。
赵伟峰
没有度量，就没有改进。这是研发管理的常识，但我们目前就是没做。
李静
痛点 12：需求管理缺少端到端度量指标。好，赵总辛苦，研发这边是 6 个新增痛点。
📌 王凯记录小结：研发部痛点共 6 项 ——（7）双轨制；（8）准入清单失效；（9）排期话语权缺失；（10）插队成本高；（11）跨线依赖空白；（12）度量缺失。
四、市场部 · 需求管理现状调研 15:08 — 15:30
李静
好，最后请市场部的陈经理来讲一下。市场部跟产品研发的视角差异比较大，希望听到一些新的痛点。
陈雪丽
嗯好的。我从市场部的角度讲三块：第一块是需求来源，第二块是需求传递过程中的体验，第三块是结果反馈给客户的痛点。
陈雪丽
先说需求来源。市场部的需求主要有四个口子：客户主动提出的（比如客户在 QBR 季度业务回顾会上说"你们应该支持 XX"）；销售拜访时记下来的；行业大会、客户走访带回来的洞察；以及竞品分析。这四类需求加起来，市场部一个月平均会沉淀 80 到 120 条。
陈雪丽
这些需求我们目前是用一张飞书表格在管——是的，就是一张表。表格里有需求标题、客户名、提出日期、市场对应人、紧急程度、提交给产品的日期、产品反馈状态。理论上闭环到"产品反馈状态"，实际上 80% 的状态停留在"已提交"，再后面就没有了。
张明远
这块我有点惭愧，我们没有把状态回写到你们那边。
陈雪丽
不只是回写的问题。回写的颗粒度也是问题。我们需要的状态不是"做了/没做"，我们需要的是"哪个版本上、什么时候上、不上的话原因是什么、客户能不能接受"。
陈雪丽
举个例子。一个大客户提了一个"批量导入合同"的需求，我们提交给产品两个月了，状态一直是"评估中"。客户每周问我们一次进展，我们每周给的答复都是"在评估"。第三个月客户火了，说"你们到底要不要做？" 我们也不知道怎么答。最后客户走了，签了我们的竞品。那一单是 380 万的年单。
李静
这个故事可以记一下，作为典型案例放在调研报告里。痛点 13：需求处理状态不透明，市场无法对客户做有效反馈，已经造成实质性丢单。
陈雪丽
谢谢李姐。然后第二块是需求传递的过程体验。我们填好表格、@产品对接人之后，一般要等 3 到 7 天才能拿到第一个反馈。如果是紧急需求，我们会再追一次，但追了之后产品方的反应是——"我先放进池子排"。
陈雪丽
我理解产品方有自己的节奏，但从市场视角看，"放进池子"等于"丢进黑盒"。我们没办法判断这个需求会不会被采纳，也没法管理客户预期。
张明远
这个我承认。说实话产品经理收到一条市场需求之后，第一反应是"我这周已经满了，先放着"。能不能采纳，要看下次评审会。但评审会到底什么时候过这条需求，确实没有给市场反馈。
陈雪丽
所以我们市场希望的是：提交即有响应。哪怕是"已收到，预计 X 月 Y 日评审"，都比"读不读不知道"强一百倍。
李静
痛点 14：需求受理无 SLA，市场侧无法管理客户预期。
陈雪丽
第三块是反馈给客户的痛点。这块跟刚才说的第一块有重叠，但维度不太一样。我刚才讲的是"信息颗粒度"问题，现在讲的是"信息呈现"问题。
陈雪丽
我们经常需要在客户面前讲产品 Roadmap。但目前公司没有一个统一对外的 Roadmap，也没有统一的需求看板。每次客户问"你们 Q3 会上什么功能"，我都要去找产品总监单聊，整理一份 PPT，再发给客户。这个动作每个月要做十几次。
陈雪丽
而且每次去问产品总监，得到的版本可能还不一样。上周问的是"Q3 会上 A、B、C"，这周问的是"A 推迟到 Q4，B 暂缓，C 还在评估"。我把这些版本发给客户，客户会觉得我们公司很乱。
李静
痛点 15：缺少统一对外 Roadmap，市场对客户输出信息不一致。
陈雪丽
最后一个我想补充的是需求质量背锅。每次需求做出来不达预期，最先被骂的是市场——客户找市场抱怨，市场再去找产品。但市场其实是最不应该背这个锅的，因为我们只是传声筒。
陈雪丽
我希望未来的流程能让责任划分清楚，每个需求从提出、加工、决策、开发、上线、复盘，每个环节谁对结果负责，能写得明明白白。
李静
痛点 16：需求生命周期的责任划分模糊。好，陈总辛苦，市场这边 4 个新增痛点。我们休息 10 分钟，回来交叉讨论。
📌 王凯记录小结：市场部痛点共 4 项 ——（13）状态不透明丢单；（14）受理无 SLA；（15）无统一 Roadmap；（16）责任划分模糊。三方累计 16 项痛点。
五、茶歇后 · 三方交叉讨论 15:40 — 16:30
李静
好，茶歇结束，我们回来。我把刚才小王整理的 16 个痛点投到屏幕上，我们一起做聚类。聚类的目的是找出几个核心问题，避免后面方案做出来散点式打补丁。
李静
我快速聚一下，大家看对不对。我把 16 个痛点聚成4 组：
第一组：需求源头治理问题 ——（1）需求源分散；（2）优先级失真；（3）原始信息流失；（13）状态不透明。
第二组：流程节点缺失问题 ——（4）变更无追溯；（5）上线无复盘；（10）插队无评估；（14）受理无 SLA；（16）责任划分模糊。
第三组：协同机制空白问题 ——（6）跨部门可见性；（11）跨线依赖；（15）对外 Roadmap 缺失。
第四组：管理体系问题 ——（7）双轨制；（8）准入清单失效；（9）排期话语权；（12）度量缺失。
这样聚有道理吗？
赵伟峰
聚得清楚。我看下来第二组和第四组是研发最关心的，第一组是市场的根本痛点，产品的痛点四组都沾。
张明远
同意。我补充一句——其实四组之间是有因果关系的。源头治理不好，节点就缺失；节点缺失，协同就乱；协同乱，最后就没有度量。所以我建议未来方案要从源头开始打。
陈雪丽
我同意张总。但市场这边最痛的其实是协同——"我看不到、问不到、客户问我我没法答"。所以协同机制如果能先动一动，市场会很受益。
李静
大家说得都对。从我们流程部的视角，这四组是一个完整闭环，不能只动一块。但落地节奏上可以分阶段。我们看一下时间，离最后议题还有 50 分钟，我提议接下来用 30 分钟做"未来方向探索"，最后 20 分钟定行动项。OK？
李静
在切到未来方向之前，我想再问一个问题。大家觉得，我们三方在需求管理上，最关键的"信任缺口"是什么？我感觉光治痛点没用，背后的信任问题不解决，再好的流程也跑不顺。
张明远
我先说。从产品视角看，研发对我们的不信任来自"反复变更"，市场对我们的不信任来自"沟而不通"。我承认产品在这两块做得不够好。
赵伟峰
研发的不信任主要在两点：第一，需求随时变；第二，承诺给我们的"上线后复盘"从来没做过。我们就觉得需求像泼出去的水，做完就没人管了。
陈雪丽
市场的不信任很简单——承诺过的事没下文。客户提的需求，我们承诺了"会评估"，但产品那边什么时候评估、评估结果是什么，我们不知道。久而久之，市场对产品的承诺就打折扣，甚至有些 BD 干脆不再往产品提了，自己去找研发同事走后门。
赵伟峰
这个我证实，我们经常接到市场私下找过来的需求，绕过产品。这是个很严重的问题。
李静
这个发现很重要：信任缺口已经导致流程被绕过。这是一个红色警报。这个问题如果不解决，未来方案做得再漂亮，落地都会打折。我们记下来。
李静
那好，带着这个信任缺口的问题，我们看未来方向。
六、未来方向探索 · 目标流程与赋能工具 16:30 — 17:00
李静
未来方向我先抛一个框架，大家在这个框架上拍砖。我建议从三个层次来构建未来的需求管理流程：第一层是制度层，把规则写清楚；第二层是工具层，把规则落到系统里；第三层是赋能层，引入 AI 把流程跑得更快更准。
李静
先说制度层。我建议未来的需求管理流程要明确八件事：需求来源标准、需求模板、需求评审节奏、变更管理、SLA 标准、责任矩阵 RACI、Roadmap 发布机制、复盘机制。这八件事每一件都要有书面规定，不能再靠默契。
张明远
同意。但我建议制度不要一上来做太厚。我之前在另一家公司见过一份 80 页的"需求管理办法"，最后没人看。建议第一版做精，20 页以内，每条规则配一张流程图。
李静
这个建议好。我们流程部接下来会牵头出第一版"需求管理 SOP"，目标 20 页以内，下个月底前给到大家评审。
李静
第二是工具层。目前 ONES 是产品研发的主战场，但 ONES 的需求管理模块说实话比较弱。我们可以考虑两条路：路径 A 是深度配置 ONES，加自定义字段、自定义状态流；路径 B 是引入新工具，比如 Aha! 或者飞书的需求管理插件。
赵伟峰
我建议先做 A。研发同事已经习惯 ONES 了，再换新工具的迁移成本很大。我们应该把 ONES 用透，包括它的工作流引擎、报表中心、变更追溯，这些功能其实都有，只是没用起来。
陈雪丽
市场这边可以看一下能不能也接入 ONES，至少需求录入和状态查询的入口要对市场开放。我们目前根本没有 ONES 账号。
张明远
这个能开。我下周让 IT 部给市场分配账号，但建议给"只读 + 提单权限"，别开太大。
李静
好，工具层 Action：ONES 深度配置 + 市场部账号开通。
李静
第三是赋能层，这个可能是今天最有想象力的部分。AI 能在需求管理流程里做什么？我罗列几个我们流程部最近在调研的方向，大家看哪些可以试：
李静
第一，需求归集自动化——用 AI 把市场表格、CRM、客服工单、ONES 这几个口子的需求自动汇总到统一池子，去重、合并、打标签。这个能解决产品经理每周半天到一天的"搬运"工作。
张明远
这个我们必须做。光是这一块，每个产品经理一年能省 50 天工时。我们 14 个产品经理就是 700 天。
李静
第二，需求质量自动评分——PRD 提交时，AI 按 12 项准入清单自动打分，不达标的自动打回，给出具体修改建议。这个可以解决研发说的"准入清单形同虚设"。
赵伟峰
这个非常好。AI 卡在前面，比研发架构师卡要客观得多，不会被说"刁难产品"。我建议这个一定要做。
李静
第三，需求语义聚类——AI 把语义相似的需求自动归到一组，避免重复评审。我看产品需求池里有大量"批量导出""支持 Excel""导出报表"这种讲的是同一件事的需求，目前是分散评审的。
李静
第四，状态自动同步——AI 监听 ONES 里的需求状态变化，自动回写到市场的飞书表格、自动给提报人发飞书消息。这个解决市场说的"沟而不通"。
陈雪丽
这个对市场是救命的。如果能做到，市场对产品的信任度会立刻回升。
李静
第五，插队需求评估器——每次有插队需求，AI 自动评估对当前迭代的影响（成本、延期风险、依赖项），给出建议是否插入。这个解决研发说的"插队成本高"。
赵伟峰
这个有点意思。如果 AI 能把每次插队的"影子代价"算给老板看，老板可能就没那么爱插了。
李静
第六，Roadmap 自动生成与更新——AI 根据 ONES 里的迭代规划，自动生成对外 Roadmap PPT 或者网页，市场可以直接拿去给客户。
陈雪丽
这个实用！我现在每个月就要花 3 天做 Roadmap PPT。
李静
第七，上线后自动复盘提醒——上线一个月后，AI 自动拉取数据、生成"需求达成度报告"，提醒产品经理做复盘。解决"上线无复盘"。
李静
这七个点是我们调研下来认为性价比最高的。大家看，有没有要补的？或者有没有觉得不该做的？
张明远
我加一个：需求与战略对齐度评估。每个需求 AI 自动判断它跟当年公司 OKR 的相关度，给出对齐分数。这个能从根上解决"老板插队"——因为如果某个老板插的需求 AI 评出来跟 OKR 无关，老板自己也不好意思硬塞。
李静
这个想法很大胆，但很有价值。记下来作为第八个赋能点。
赵伟峰
我也加一个：跨产品线依赖识别。AI 看到一个需求里提到的接口、模块、数据，自动识别可能涉及哪条产品线，提醒 PM 提前协调。这个能解决我刚才说的 31% 跨线延期。
陈雪丽
我也来一个：客户原话反向追溯。每个需求最终上线之后，AI 能回溯出"这个需求最早是哪个客户提的，提了多少次，对应的 ARR 是多少"。这个市场每次跟客户做 QBR 用得上。
李静
第十个。OK，今天我们一共抛出了 10 个 AI 赋能点。我建议不要全做，按价值/投入排个优先级，第一阶段做 3 到 5 个。
七、行动项与会议结尾 17:00 — 17:30
李静
最后半小时，我们把行动项落实下来。我先抛一版，大家补充。
李静
第一项，调研报告输出。我们流程部根据今天讨论，加上后续 1-2 周的部门访谈，输出一份《需求管理流程现状调研报告》。预计 5 月 31 日前完成初稿。负责人：王凯，复核：李静。
王凯
收到，我会按今天 16 个痛点为骨架，加上访谈深化。
李静
第二项，未来流程 SOP 起草。流程部牵头出第一版"需求管理 SOP"，目标 20 页以内，每条规则配流程图。预计 6 月 15 日前出初稿。负责人：李静。
李静
第三项，RACI 责任矩阵。三个业务方各派一名代表，6 月 5 日前一起梳理需求生命周期里每个节点的 R/A/C/I。负责人：张总（产品）、赵总（研发）、陈总（市场），流程部协调。
李静
第四项，ONES 深度配置方案。研发架构师对 ONES 现有功能做一次全量评估，列出哪些功能可以解决哪些痛点。负责人：赵伟峰。预计 6 月 10 日前。
李静
第五项，市场部 ONES 账号开通。本周内完成。负责人：张明远（协调 IT）。
李静
第六项，AI 赋能 POC 选型。我们流程部基于今天 10 个赋能点，做投入产出分析，挑出 3 到 5 个第一阶段做 POC。预计 6 月 20 日前出选型报告。负责人：李静 + 王凯。
李静
第七项，下次会议时间。两周后开第二次研讨会，主要议题是评审调研报告初稿、SOP 框架、AI 选型方向。提议时间 6 月 3 日下午。大家方便吗？
赵伟峰
下午我有个迭代规划会，能不能改晚一点？4 点开？
李静
好，6 月 3 日 16:00 — 18:00。陈总？
李静
今天三个半小时，我们做了三件事——把需求管理的16 个痛点摆到了桌面上，做了4 组聚类，初步抛出了10 个 AI 赋能方向。我个人觉得这是一次非常高质量的研讨，比我预期的更深入。
李静
但更重要的是——大家在会上承认了信任缺口。这一点不容易。流程优化最难的不是画图、不是写制度、不是上工具，而是让原本互相不信任的部门，重新对话、重新建立预期。今天我们做到了第一步。
张明远
我也认同。今天讲完之后，我会回去跟我们 PM 团队复盘，承担产品方该承担的责任。
赵伟峰
研发这边也会重新审视一下我们对插队需求的态度。我们过去太被动了。
陈雪丽
市场这边会改进我们的需求填报质量，把客户原话和场景描述写得更厚一些。
李静
好。那今天会议到此结束，谢谢三位的时间。会议纪要小王明天上午之前发出来，大家审完确认。散会。
📌 行动项汇总（共 7 项）
- 调研报告输出：王凯 / 5月31日前 — 16项痛点为骨架的现状调研报告初稿
- 未来流程 SOP 起草：李静 / 6月15日前 — 20页以内、每条规则配流程图
- RACI 责任矩阵梳理：三方各派代表 / 6月5日前 — 流程部协调
- ONES 深度配置评估：赵伟峰 / 6月10日前 — 现有功能与痛点匹配分析
- 市场部 ONES 账号开通：张明远协调IT / 本周内 — 只读+提单权限
- AI 赋能 POC 选型报告：李静+王凯 / 6月20日前 — 10个赋能点优先级排序
- 下次研讨会：6月3日 16:00-18:00 — 评审调研报告、SOP框架、AI选型方向
📎 全部录音已转写存档于：飞书云盘 / 流程管理部 / 需求管理项目 / 2026-05-20_联合研讨会逐字稿。下次会议前 3 天，王凯会发出会议预读包。
— 全文完 · 共约 10,200 字 —
本逐字稿由流程管理部记录，依据飞书妙记原始转写整理，已做语病和重复词清理，未做实质性删改