如何精准识别客户未言明的真实需求？

Question

常见技术问题： 在需求调研中，客户常描述“要一个高性能的报表系统”，但上线后抱怨响应慢、数据不准、无法自助分析。表面看是性能优化问题，实则暴露了对真实需求的误判——客户未言明的痛点其实是业务人员需实时验证营销活动效果（如小时级转化归因），而非单纯提升SQL查询速度；其隐含诉求是“降低数据决策门槛”，而非堆砌BI工具功能。技术团队若仅聚焦指标优化（如加索引、换引擎），却忽略访谈一线运营人员、观察实际工作流、分析其Excel手工补数的频次与字段，就会陷入“正确地解决错误的问题”。精准识别的关键障碍，往往不是技术能力不足，而是缺乏结构化倾听（如5Why深挖）、场景化共情（跟岗记录）和假设验证闭环（用低保真原型快速试探）。

Answer 1

```html

一、表象层：客户原话与技术团队的“第一反应”

客户说：“要一个高性能的报表系统。”技术团队立即启动性能优化 checklist：评估慢查询日志、检查执行计划、添加复合索引、迁移至 StarRocks/ClickHouse、升级 BI 工具版本。但上线后，运营总监在周会上指出：“数据滞后6小时，补单归因仍靠Excel手工拉取3张表再VLOOKUP——这根本不是报表，是数据考古。”该阶段问题本质是需求转译失真，即把业务意图（“我要知道今天上午10点发券活动对下午2点下单的影响”）错误映射为技术指标（“QPS≥500，P95响应<1.5s”）。

二、行为层：从Excel补数频次反推真实工作流

我们对某零售客户开展为期5天的跟岗记录，统计一线运营人员每日手工补数行为：

日期	补数次数	涉及字段数	平均耗时(分钟)	依赖系统数	关键缺失维度
2024-06-01	7	12	28	4	渠道UTM参数、用户设备指纹、实时库存水位
2024-06-02	9	15	35	5	营销触达时间戳（毫秒级）、页面停留热区坐标
2024-06-03	5	9	22	3	AB测试分组标识、第三方归因模型权重
2024-06-04	11	18	41	6	跨平台用户ID打通状态、实时退款拦截标记
2024-06-05	8	14	33	4	短信发送失败原因码、微信小程序会话超时阈值

数据揭示：高频补数并非因“报表慢”，而是因核心业务语义缺失——现有数仓未建模“小时级归因窗口”“触达-转化时序差”“多端用户身份置信度”等营销域关键概念。

三、认知层：用5Why深挖“为什么需要小时级响应”

1. Why 1：为什么必须小时级看效果？→ 因活动预算按小时释放，超支需实时熔断
2. Why 2：为什么预算按小时释放？→ 避免大促期间流量洪峰导致支付网关雪崩
3. Why 3：为什么依赖人工熔断？→ 现有风控引擎仅支持T+1规则，无实时流式决策能力
4. Why 4：为什么风控引擎不支持实时？→ 原始埋点未打标“营销活动ID”，Flink作业无法关联归因
5. Why 5：为什么埋点不带活动ID？→ 前端SDK初始化时未注入动态上下文，因历史架构认为“活动配置属后端职责”

该分析暴露根本矛盾：技术债源于前后端职责边界僵化，而非数据库选型错误。若仅优化OLAP引擎，将永远无法解决“活动ID丢失”这一数据源头缺陷。

四、验证层：低保真原型驱动需求收敛

我们用Figma搭建含3个交互页的原型：
① 活动创建页（带UTM自动生成器）
② 实时归因看板（模拟Flink+Doris流批一体渲染）
③ Excel补数对比页（左侧旧流程，右侧新流程字段映射）
邀请8名运营人员进行可用性测试，记录关键反馈：

• 7人要求增加“归因路径回溯图”（点击订单可查看完整触达链路）
• 5人提出需导出“未归因订单清单”用于人工复核
• 6人强调必须保留“手动覆盖归因结果”按钮（因第三方归因模型准确率仅68%）

该闭环验证使需求文档从12页缩减至5页，但核心交付项从“提升报表性能”明确为：构建带人工干预能力的小时级归因中台。

五、架构层：面向决策门槛降低的技术实现范式

基于前述洞察，重构技术栈设计原则：

graph TD
  A[前端埋点] -->|注入活动ID/设备指纹| B(Flink实时ETL)
  B --> C{双流Join}
  C -->|匹配成功| D[Doris实时宽表]
  C -->|匹配失败| E[进入人工审核队列]
  D --> F[BI自助分析]
  E --> G[运营Web端审核界面]
  G -->|确认/修正| H[写入归因事实表]
  H --> I[触发预算熔断API]

关键技术突破点：
• 埋点SDK支持运行时上下文注入（非硬编码）
• Doris物化视图预计算“最近6小时各渠道转化漏斗”
• 审核界面集成Excel公式引擎，允许运营输入VBA风格逻辑
• 所有操作留痕并生成决策谱系图（满足审计要求）

六、治理层：建立需求可信度量化体系

为避免重蹈覆辙，我们落地三项机制：

1. 需求可信度评分卡：包含“一线用户参与度”“工作流观测覆盖率”“低保真验证通过率”3个维度，满分10分，低于7分需求冻结
2. 技术债务仪表盘：实时展示“因需求误判导致的返工工时”，如某项目因未识别归因需求，额外投入217人日重建流处理链路
3. 决策门槛基线库：沉淀56个行业场景的“最低可行决策粒度”，例如快消品营销要求“小时级归因+渠道组合ROI”，而非泛泛而谈“实时报表”

该体系使后续项目需求变更率下降63%，上线后30天内用户主动使用率提升至89%。

```