FDE实践｜如何通过AI+需求管理，让团队每个版本少开5次会？

什么是需求管理

上周末我有幸以主讲人之一的身份参加了山禾 FDE 社群的首场线下分享。首先，非常感谢山禾 FDE 社群的@jinchenma_ai马哥以及院长，给了我一次公开分享的机会。

首先澄清，这并不是标题党，而是真实实践出来的结果。

其次，这篇文章本来应该更早发出来，一开始我也想单独把分享部分做一个总结，并凝练一些自己的思考与感悟，先写一篇长文。然后单独出一篇文章讲我自己的。实践经历。

但思来想去，还是放弃了前者。因为市面上讲 FDE 理念的文章已经很多了。比起理念，我觉得还是用真实的实战经验，带着大家完整地看一遍我在企业当中是如何用AI解决问题的，以及我自己总结出的一些经验教训。

另外，本文也将涉及一类市面上可能比较少见的领域——需求管理。

只要公司有一定体量，哪怕只是中小公司，可能都会经常碰到下面这些情况：

• 每天总有开不完的会。会赶会，忙不过来，但是到头来问题依然没解决。
• 领导每天都在说“我们对齐一下颗粒度”。但到头来，内部颗粒度对齐了，却离客户的需求越来越远。

那么为什么会出现这种情况呢？我们设想一下下面这个场景：

售前和销售每天都很忙，要接触大量客户，也有很多会议。他们在会议间隙抽空向群里丢一个需求，例如：某某公司的某总想要我们的产品加上某某功能。

群里很长时间没有回复；又过一阵，决定下个版本要开始做了，于是开始讨论这个需求：当时客户是什么意思呢？售前和产品内部开会，一顿讨论。产品和研发可能还需要再讨论、再开会。到最后，研发做出来了，测试也通过了，结果发布的时候才发现，客户说的不是这个意思，或者与客户的预期相距甚远。

那这是为什么呢？这就是没有做好需求管理的后果。

需求管理，顾名思义，指对每一条需求进行适当的管理；而所谓管理，就是让每一条需求的每一个环节，都被认真对待。这个管理贯穿这条需求的全生命周期：从售前流转到产品，再到研发、测试，最后到售后。每一个环节都要对这条需求进行操作，并采用对应的处理方式：是提前关闭这条需求，还是让这条需求成为正式立项的一部分？这条需求最后是以正式发版的形式存在？还是给客户做单点修复？这都是需要斟酌的问题。

而这些，从需求进来的那一刻——客户在群里说话时，就已经开始了。

如何发现问题

刚入职的时候，我看到产品和测试在发版前进行讨论。产品说：“你这个功能不对，客户要的不是这样，你得改东西，或者得加需求。”测试苦着一张脸说：“马上就要发版了，这还怎么改呀？”于是二者爆发了一场不大不小的争论。

当时我刚入职，并没有深入思考这件事情，之后我就投身于日常研发工作。直到一次整个产研团队的战略会议，我本来不在参会名单里，但旁边带我的大哥提了一嘴，我就说想去听一听。也就是蹭会。而会上我听到了一句话：

需求又多又散，承接的人也不知道它到底是不是真需求。

我把这句话记了下来。这时我才意识到，我从来没有站在多个部门或整个团队的角度，去看待整个事业线的工作。

我自己属于研发，是整个产研链路中的一环。上游要对接产品，下游对接测试，有时候可能还会接触一下售前，而售后则完全没接触过。总体来说，我处于中游的位置。但这次会议让我第一次从全局视角看待整个团队的工作，也让我第一次知道团队中存在这样的问题。

其实对于这个现象，我是有设想的。在我入职之前，“团队开会多，但问题解决不了”作为一种职场通病，我也多多少少有所耳闻。只是我日常做的研发更多偏交付，所以自然没有被这些会议干扰。

但既然这一点被作为一个问题提出，说明整个团队目前正在经历这件事。而既然提到需求又多又散，我便想着去看一看，团队需求目前到底是什么样的存在状态？它是如何被记载或管理的？

于是我去翻了翻我们的需求总表，是一张飞书多维表格。简单翻阅了一下，两个问题就浮出水面：

1. 字段维护率并不是100%，存在大量”以前填过、现在不填了“或者“以前没有填、现在刚开始填“的字段。真正被成体系维护的字段不超过10%。
2. 另外，需求优先级有 90% 都是 P0。这意味着客户几乎每提出一个需求，我们就需要倾注研发精力去做。

前者意味着，整个需求表格还处于比较混乱的阶段。我们似乎已经为每条需求建立了很多指标，但并不稳定，更多是阶段性迭代；后者意味着我们对需求没有很好的排序，以至于几乎每一个客户需求都会占用整个团队的宝贵时间。由于每个需求可能不够明确、目标不够清晰，并且信息在产研团队的反复沟通中变得模糊，这就导致最终整个团队的产出比较低效。

由此一来，会议上的那句「需求又多又散，承接的人也不知道他们是不是真需求」，原因就找到了。落实到具体可解决的问题，就变成了：

1. 如何判别一个需求是真需求？
2. 如何对又多又散的需求进行管理？

如何解决问题

2.1 如何判断真需求

带着问题，我又回看了一下会议记录。在会议中，领导点名强调了真需求的必备的4个要素：

• 客户是谁？
• 使用场景是什么？
• 痛点是什么？
• 预期效果是什么？

我立刻想到，可以设计一个小工具，针对每一条客户扔进来的单点需求，进行四问追问。而这个本质其实可以是一个很简单的、给定特定提示词的 Chatbot。如果再包装一下，就是 Agent。如果多轮对话后四要素中仍然有不明晰的地方，就证明这个需求本身说不清楚，那它就不是一个真需求。

举一个很简单的例子。假设你是iPhone Duo 的售后，在接受用户反馈、准备迭代到第二代的时候，如果一个用户跟你说：“我觉得 iPhone Duo 实在不太智能。”另一个客户说：“我觉得 iPhone Duo 在双屏运行的情况下，右半屏打开应用的时候会有两秒左右的延迟。”

你会毫不犹豫地更加倾向于接受第二位客户的反馈，因为他能准确地说出自己的一个使用场景和痛点。而我们还可以从已有机型的单屏延迟去推演客户的预期效果，至少也是毫秒级的。所以第二个是有效反馈。而第一个用户的反馈”不太智能“，实在过于宽泛。这也就是我们常说的：客户的抱怨可能并不是真需求。

如果客户仍然扔一句话进来，怎么办？我们可能需要按照这4个要素，对客户的话进行提炼，并人工确认。如果仍有缺失，就需要在我们真正投入任何精力做后续动作之前，先确认客户需求。如果多轮之后仍然无法补齐，则不予放行。当然，这需要一些沟通技巧。

如果你是FDE的从业者，会发现这一点尤为关键。

2.2 如何管理需求

这可能涉及一些企业需求管理的方法论。简而言之，我们可以依照如下逻辑进行推导：

1. 我们最重要的指标是产品成功率，但所有客户的需求总和超出我们能够顾及的范畴
2. 需要按照一定优先级对客户需求排序，以最大化产品成功率
3. 但又不能放任客户的需求不管
4. 于是先收集需求，再筛选需求
5. 所以需要设立一定的机制完成这两个动作

于是就有了需求池和版本立项这两个概念。前者是将所有需求收集到一起，后者是按照一定的比例和标准对需求进行筛选。需求进来后，我们可以按照一定维度对需求进行打分，比如痛点程度、热度等。将这些维度的总分相加，即可对需求进行排序。

此外，我们还需要对需求进行分类，包括基础体验层、体验优化层、战略前瞻层等等。这三类每期可以按照固定比例进行分配，从而在需求生命周期前段就建立起完整的管理机制。而这个动作就是后者——版本立项。

当然，整套需求管理是非常复杂的方法论，在这里我只粗略介绍了这两点。所以，针对这个问题，我能想到的解决方案是：对原有的多余表格字段进行整理，并且和之前类似，用 Chatbot 的形式给定一个打分标准，生成各个维度的评分。包装一下，又是一个Agent。

解决方案如何落地

大道至简，我相信用简单的技术解决复杂的问题才是最好的。另外，让团队成员以最低的额外操作成本完成我们整个解决方案的落地，也是非常必要的。试想一下，如果一个公司内部团队不停地开发系统、不停地部署上线，那员工们每次面对一个新的 Vibe Coding 出来的系统时，有 bug 暂且不说，每一套系统都要增加额外的学习和使用成本。这样其实对工作提效非常有限。

我在设计解决方案时秉持的一点是：如何让我们的团队成员在日常工作流程中，最好没有任何额外操作成本，或者说无缝体验到这个功能的增加。能点一下就坚决不让他们点两下。

因此我想到了绑定我们的日常使用生态——飞书。需求表格是多维表格。我要做的是建立一个飞书机器人，让他们像和正常同事说话一样，打开和机器人的聊天框，填入需求，或者用自然语言描述下一步行动。而机器人负责发送消息卡片或对话。消息卡片上的每个字段都与表格中的字段关联。每填好一个卡片并确认落库后，表格字段会自动填写好。这样没有任何学习门槛和成本。

或许有人会问：你这里都没有涉及任何系统选型、技术方案、数据库、架构等等，你敢把自己叫 FDE 吗？

我个人认为，合适的才是最好的。如果能用1+1解决的问题，就不要用1+2。在任何 FDE 的实践中，解决问题才是关键，技术永远排在第二位，甚至更靠后。

所以，最终我的解决方案落地形态是：建立了两个飞书机器人，并绑定了我们公司内部的AI coding工具。其中一个在销售或售前与飞书机器人对话时，对发送进来的需求进行四要素追问，若三轮追问仍无法补齐四要素，则判定为伪需求；另外一个专门负责对需求进行评分和立项。每一条需求进来后，可以通过设定好的多维度进行打分，并在需求库里查重。如果有重复，热度加一。最终按照需求评分以及设定好的比例排序，排出我们下一个版本值得做的需求。

最重要的踩坑经验

按理说在这一套流程跑通之后，我就应该立刻去向上级进行汇报，把这个解决方案拿出来做演示了。

但是事实上我并没有这样做。我又额外花了两周时间把整个产研链路的系统打通了。上到从客户在外部群里进行反馈收集需求，下到对整个需求管理的全周期进行需求内、版本内、跨版本的三个阶段复盘，我建立起了一套基于飞书的完整的需求管理机制，深度绑定飞书的多维表格和机器人消息卡片生态。

我把整个系统做好之后，才拿去和上级汇报。为了更直观的演示，我直接对整套系统进行了录屏。最终我被推向VP直接进行汇报，但由于她很忙，并没有时间看完这接近15分钟的视频，于是给我指定了一个对接负责人，让我去对接。

我认为最好的展示效果就是当面进行真机验证，这个或许没有错。只是我拿着一套完整的系统去和负责人讲这个事时，每推进一点，他就会对我做的这个功能，以及这个功能如何与现有生态进行绑定，去进行详细的分析与讨论。当然那位负责人的时间也有限，我也很感谢那位负责人能全程耐心听我分享。但最终的进度就是，我花了一个半小时和他讲这套系统，但是他能消化多少暂且不说，整个讲解进度还没有到40%。

这就让我意识到一个问题。在对话的最后，他也跟我提到了，“我们可以先解决文前提到的那两个问题，我们先跑出效果，然后再谈后续的落地。”这一点让我大受触动。

诚然，我有能力建立起一套比较完整的需求管理机制，平摊到每个人身上，可能也就多点击不过10次。但一旦某个系统在公司落地，并且涉及到整个产研团队的时候，即使操作成本再低，操作机制再简单，毕其功于一役也是难承其重。无论做企业内部的任何落地实践，都需要从一个小问题入手，从一个单点上跑出效果，才能谈后续的其他动作。这也是这次实践给我的一个最重要的教训。

于是最后整个做出来的系统只有这两项被先行采纳了。两个飞书机器人设置完毕后，直接分别开放给特定团队使用。

落地后的跟进与效果

解决方案落地后，我继续从事日常工作。后续我和对接负责人沟通，发现工作流程切切实实的改变了：

1. 需求守门：所有的需求并不会直接拿到评审会去进行评审，而是首先按照四要素的标准剔除伪需求，只留下值得认真对待的真需求。于是省下了一次内部需求讨论会、一次需求分析会。
2. 需求管理：在建立需求池后，每个版本都有明确的立项标准，并且只在真需求中进行筛选——上游的落地在下游以及后续所有链路中都发挥了效果。在固化立项标准之后，每个版本省下了一次需求评审会、一次跨部门信息同步会，以及为了调整需求优先级进行的临时会议。

而这一套系统落地的成本呢？除去我设计这两个agent并把它接入到飞书机器人工作流中花掉的不到 50块钱的token、在一台内网服务器上部署我们公司内部的 AI coding 工具之外，就没有其他成本了。当然在后续过程中也有额外的答疑和对接，但没有增加团队的经济成本。

而且这套系统的好处在于，无需任何额外的维护。只要虚拟机正常运转，系统都可以正常运行，持续进行需求管理。

于是我成功用AI+需求管理，让团队每个版本少开5次会。

此外还有额外收益：这套系统在进行池查询的时候，会自动对客户的新需求与历史的老需求进行相似度对比。后续发现客户提出的 30% 的新需求已经在我们已有的规划中或历史功能已有实现了，这又是额外的团队时间成本的节省。

一些思考——究竟何为 FDE？

在上周末的分享会里，我也仔细倾听了各位老师的分享。有同样信奉大道至简，力求用最简单的技术解决复杂的问题的巍哥；也有秉持着先用单点工具让效果被看见，再进入流程，最后才可能触动组织这一理念的鹏哥。当然还有我们的社群主理人马哥。三位都是在大厂摸爬滚打很多年的资深前辈。我也很有幸能与他们同台分享，并且在这次实践中悟出了与他们总结相同的道理。

首先，FDE的首要任务是解决问题，而不是使用最炫酷的技术。

其次，FDE交付的是结果，一个能真正产生效果、解决客户痛点，并且达到预期效果的结果。当然，结果的标准可能会随着任务的推进有所变更，但核心要义不变。而既然交付的是结果，那我们就有了一个 RaaS 的概念，也就是 Result as a Service。我个人认为这也是 FDE 的真正服务范式。

再次，有一点需要格外注意：先在小的单点做出结果，再去逐步推广或涉及更多的流程。尤其针对“需求管理”这一相对复杂的议题，我们更需要以单点为突破口，再逐步进行推广。

这是我在工作之余搭起来的系统，没有浪费很多时间，但效果非常显著。当然，需求管理还涉及到其他很多方面，本文介绍的只是一个很小的部分以及如何在组织中落地。

最后，如果你的团队也有这样的问题，不妨从一个小的切入口进行突破。有时候简单的一个动作，就能帮助团队减少很多无效的沟通以及信息磨损，从而提高你们团队的产品成功率。如果仍然有其他亟待解决的问题，欢迎交流。

我是 Jacky，黑客松冠军，目前在企业一线做 AI 落地和 FDE 实践。如果有任何问题，请在评论区留言或私信，我一定会解答。