业务方要的AI功能和你规划的方向冲突，听谁的？

———— / BEGIN / ————

业务方说："客户要一个像 ChatGPT 一样的助手，能回答所有问题，下个月必须上线。"

研发说："这个需求至少要 6 个月，现在的技术根本做不到。"

产品经理夹在中间，翻译了半天，谁也没说服谁。

做 AI 产品这几年，类似的撕扯几乎每天都在发生。业务方觉得 AI 什么都能做，研发觉得需求不合理，产品经理卡在中间不知道该听谁的。

其实，90% 的需求冲突不是人的问题，而是三方对同一件事的理解完全不在一个频道上。业务方想的是快速拿下客户，产品经理想的是能不能复用,研发想的是技术实现和长期维护。大家说的都是同一个需求，但理解的完全不同。

一、问题出在哪里？

语言不通

业务方说"我要一个像 ChatGPT 一样的助手"，心里想的是 AGI，什么都能做。产品经理听到的是"FAQ 自动回复系统，覆盖 80% 的常见问题"。技术团队理解的是"这个需求需要大模型 + 知识库 + 人工标注，至少 3 个月"。

举个例子，业务方说"我要个智能推荐"，产品经理理解成"基于规则的推荐"，技术团队理解成"协同过滤算法"。开发了 3 个月，业务方说这不是我要的，产品经理说我就是这么理解的，技术团队说需求不明确。

预期错位

业务方的"好"是能快速上线、能签单、能带来业绩。产品经理的"好"是能解决核心问题、能复用、能长期维护。技术团队的"好"是技术先进、架构优雅、代码质量高。

业务方要求"先上线一个 80% 准确率的版本，快速验证市场"。技术团队说"80% 准确率太低，至少要 95%"。产品经理夹在中间，要速度还是要质量？

目标错位

业务方的目标是完成这个季度的签单，客户要什么就答应什么。产品经理的目标是构建可复用的产品能力，这个需求能不能复用到其他客户。技术团队的目标是构建稳定的技术架构，这个需求会不会带来技术债。

举个例子，业务方要求"为客户 A 定制一个功能，客户愿意付 10 万"。产品经理说"这个功能只有客户 A 用得上，无法复用"。技术团队说"定制功能会增加系统复杂度"。

三方说的是同一件事，但理解完全不同，撕扯就这么来了。

二、怎么判断

既然三方理解不同，产品经理怎么判断到底听谁的？

答案是用三层判断：业务目标对齐、技术可行性、长期可维护性。这三层都通过了，需求才做。

业务目标对齐

先问清楚需求解决什么问题。

让业务方用"如果不做这个需求，我们会损失 XX"的句式说清楚。追问：这个损失是立即发生还是潜在风险？影响一个客户还是一类客户？投入 X 人月，能带来 Y 收入或 Z 效率提升？

举个例子，业务方说"客户 A 要一个智能问答功能，如果不做，客户就不签约了"。产品经理追问"客户 A 的合同金额是多少？如果做了，能复用到多少客户？"业务方回答"合同金额 50 万，但这个功能只有客户 A 用得上"。

这是一个战术需求，为单个客户定制。产品经理要权衡，50 万合同值不值得投入 3 个人月开发一个只有一个客户用的功能。

关键问题是，这个需求是必须做还是最好做？是现在做还是以后做？是我们做还是客户自己做？

技术可行性

再问清楚需求能不能做，要花多少成本。

让技术团队给出可行性评估（1-5 分），追问：如果做，需要多少人、多少时间、有哪些技术风险？能否用更简单的方案达到 80% 的效果？

举个例子，业务方要求"智能推荐准确率要达到 95%"。技术团队评估"现有数据量只够训练到 85% 准确率，要达到 95% 需要 10 倍数据量，至少 6 个月"。产品经理提出"能否先用规则 + 协同过滤做到 85%，快速上线验证效果，再根据用户反馈优化？"

这是一个渐进式交付的方案。业务方可以快速看到效果，技术团队可以逐步优化，产品经理也能控制风险。

关键问题是，这个需求是技术驱动还是业务驱动？必须用 AI 还是用规则也能解决？一步到位还是分阶段交付？

长期可维护性

最后问清楚需求会不会成为技术债。

让技术团队评估：这个需求会增加多少代码量、会影响多少模块、如果未来要改需要多少工作量？

举个例子，业务方要求"为客户 A 定制一个数据导出格式"。技术团队评估"这个格式只有客户 A 用，每次改动都要单独测试，维护成本高"。产品经理提出"能否把数据导出做成可配置的，让客户自己选择格式？"

这是一个可复用的方案。虽然开发成本略高，但长期维护成本更低，而且其他客户也能用。

三层判断不是用来拒绝需求，而是用来找到三方都能接受的方案。

三、怎么解决

判断完了,接下来怎么解决？用需求分层表和决策流程。

需求分层表

把需求按业务对齐度和技术可行性分成四类：

用三层判断给需求打分：业务目标对齐度 1-5 分，技术可行性 1-5 分。≥4 分算高，<4 分算低。

举个例子，某 AI 客服项目的需求分层：

P0 需求三方都认可，立即投入资源。P1 需求业务方认可但技术需要攻关，排期到下个版本。P2 需求技术简单但业务价值有限，作为增值服务。P3 需求业务价值低且技术成本高，明确告诉业务方不做或延后。

决策流程

需求分层之后，走五步评审流程：

第一步，业务方提出需求记录原始需求，不做评判。

第二步，产品经理翻译需求用业务方听得懂的话，翻译成业务目标（解决什么问题、带来什么价值）。用技术团队听得懂的话，翻译成技术需求（需要什么能力、用什么方案）。

第三步，技术团队评估可行性给出可行性评分（1-5 分）、所需资源（人月）、技术风险（高中低）、备选方案（如果有）。

第四步，三方评审产品经理拿着业务目标、技术可行性、长期可维护性，组织三方评审会。每个方案都要回答三个问题：业务方的收益是什么？技术团队的成本是什么？产品经理如何平衡？

第五步，决策与记录最终决策记录到需求分层表，明确优先级、责任人、交付时间。

总结

产品经理的核心能力不是说不，而是找到三方都能接受的方案。

用需求分层表和决策流程，把撕扯变成协作。业务方的需求不是敌人，技术团队的顾虑也不是借口。产品经理要做的，是翻译、对齐、决策。

先翻译，把业务方的需求翻译成业务目标，把技术团队的顾虑翻译成技术风险。再对齐，用三层判断找到三方都认可的方案。最后决策，用需求分层表把方案落地。

需求冲突不可怕，可怕的是三方各说各的，谁也不服谁。产品经理的价值，就是把三方拉到同一个频道上。