三亩地 三亩地SAN MU DI · CODE DIARY
ARTICLE DETAIL

日记详情

真实记录编程学习的某一天,欢迎挑你感兴趣的翻一翻。

FDE系列11:差异分析——产品与客户需求之间的鸿沟怎么填?

FDE系列11:差异分析——产品与客户需求之间的鸿沟怎么填?

FDE系列11:差异分析——产品与客户需求之间的鸿沟怎么填?

本文是《FDE工程师-从AI技术实现到业务落地》系列文章第11篇


“我们的产品有这个功能,为什么客户还是不满意?”

因为"有"和"能用"之间,隔着一道鸿沟。


什么是差异分析?

差异分析(Gap Analysis),是FDE最核心的分析工具之一。

它的核心问题只有一个:

"产品现有的能力"和"客户真实的需求"之间,差距在哪里?

不是"有"和"没有"的问题,而是"能不能在客户环境中真正用起来"的问题。


差异分析的四个维度

维度一:功能差异

产品自带的"能力" vs 客户需要的"能力"

案例

  • 产品有"智能客服"功能——但客户需要的是"多语言客服"
  • 产品有"数据报表"功能——但客户需要的是"移动端报表"
  • 产品有"权限管理"功能——但客户需要的是"细粒度到字段级别的权限"

功能差异是最容易识别的,也是最容易解决的。

维度二:数据差异

产品假设的"数据环境" vs 客户实际的"数据环境"

案例

  • 产品假设数据是"干净的结构化数据"——客户的数据是"脏的非结构化数据"
  • 产品假设数据量是"百万级"——客户的数据量是"十亿级"
  • 产品假设数据是"实时流式数据"——客户的数据是"每天凌晨批量导入"

数据差异是AI项目中最常见的"杀手"。

维度三:技术架构差异

产品假设的"技术环境" vs 客户实际的"技术环境"

案例

  • 产品假设跑在"云原生架构"上——客户的环境是"传统IDC"
  • 产品假设用"PostgreSQL"——客户用的是"Oracle 11g"
  • 产品假设"API调用"——客户的系统只支持"文件导入导出"

技术架构差异,是"最后一公里"问题的主要来源。

维度四:组织能力差异

产品假设的"用户能力" vs 客户实际的"用户能力"

案例

  • 产品假设用户是"数据分析师"——客户的使用者是"生产线操作员"
  • 产品假设"用户能自己调参"——客户希望"开箱即用"
  • 产品假设"有专门的运维团队"——客户只有一个兼职IT支持

组织能力差异,是最容易被忽视但最致命的问题。


差异分析矩阵模板

把四个维度的差异,整理成一个矩阵:

维度产品能力客户需求差距解决方案优先级
功能标准客服多语言客服缺少NLP多语言能力集成第三方翻译APIP1
数据结构化数据非结构化文档需要OCR+NLP开发文档解析模块P0
技术架构云原生传统IDC部署方式不兼容提供Docker离线部署包P0
组织能力专业运维兼职IT培训需求大提供操作手册+培训P2

每一行,都是一个"执行任务"。


差异分析的实战方法

方法一:Delta分析法(源自Palantir)

Palantir提出了一个概念叫"Delta"——产品原厂能力与客户需求之间的鸿沟。

Delta分析三步法:

第一步:列出产品能力清单

产品自带的能力清单: 1. 数据接入:支持CSV、JSON、API 2. 数据分析:支持SQL查询、可视化报表 3. AI能力:内置预测模型 4. 部署方式:SaaS云部署

第二步:列出客户需求清单

客户需求清单: 1. 数据接入:需要从SAP、Oracle ERP接入 2. 数据分析:需要自定义报表、移动端查看 3. AI能力:需要定制化模型训练 4. 部署方式:需要私有化部署

第三步:逐项对比,识别Delta

Delta分析结果: 1. 数据接入:缺少SAP、Oracle ERP连接器(Delta1) 2. 数据分析:缺少移动端报表(Delta2) 3. AI能力:缺少模型训练平台(Delta3) 4. 部署方式:需要私有化部署方案(Delta4)

每个Delta,都是一个"需要FDE解决的工程问题"。

方法二:需求-功能映射矩阵

把客户需求映射到产品功能上,直观地看到"覆盖度"。

客户需求 → 产品功能映射矩阵 需求1(数据接入SAP)→ 产品功能A(数据连接器)+ 自定义开发 需求2(移动端报表)→ 产品功能B(报表引擎)+ 定制UI 需求3(定制模型)→ 产品功能C(ML平台)+ 模型微调 需求4(私有化部署)→ 产品功能D(Docker部署)+ 安全配置

绿色(完全覆盖):不需要额外工作
黄色(部分覆盖):需要FDE做胶水工程
红色(完全不覆盖):需要产品团队支持


差异分析的应用场景

场景一:项目评估阶段

在决定是否接一个项目之前,先做差异分析。

如果差异太大(比如客户的技术架构和产品完全不兼容),这个项目可能不适合做。

场景二:方案设计阶段

在方案设计时,差异分析可以帮助你:

  • 识别"哪些差异是可以通过胶水工程解决的"
  • 识别"哪些差异需要产品团队支持"
  • 识别"哪些差异是项目风险,需要提前规避"

场景三:项目执行阶段

在执行过程中,差异分析可以帮你:

  • 追踪"差异是否被解决"
  • 发现"新的差异"
  • 调整"解决方案的优先级"

差异分析自检清单

  • 我有没有从"功能、数据、技术架构、组织能力"四个维度分析差异?
  • 我有没有列出"产品能力清单"和"客户需求清单"?
  • 我有没有把"差异"转化为"可执行的行动项"?
  • 我有没有给每一个差异设定"优先级"?
  • 我有没有识别出"无法解决的差异"并提前预警?

🔥 关注「AI拉呱」

本系列持续更新中。

下一篇预告:FDE系列12:PoC的正确姿势——用最小代价验证最危险的假设

我们不见不散。

← 返回列表