产品-FDE 接口

TL;DR:FDE 与产品团队之间的摩擦会毁掉部署。本文档明确了双方的职责归属、FDE 可以向产品团队提出的要求,以及如何处理不可避免的冲突。

挑战

FDE 组织中最常见的功能失调:

产品团队认为:

  • "客户定制由 FDE 负责"
  • "我们需要专注于路线图"
  • "他们看代码就能搞明白"

FDE 团队的实际体验:

  • 无法搭建开发环境(需要几天,而不是几小时)
  • 没有说明产品如何运作的文档
  • 产品优先级与客户需求不一致
  • 等待产品团队响应时被阻塞

结果:FDE 70% 的时间花在与内部摩擦作斗争上,只有 30% 用于客户工作。

核心原则:FDE 是你产品的第一批真实用户

如果 FDE 都无法有效使用你的产品,客户也不会。

FDE 与你的代码库斗争的每一个小时,都意味着:

  • 一个小时没有用于客户成果
  • 一次对客户未来体验的预演
  • 一份你正在输出到一线的技术债务

职责边界

FDE 团队负责

领域范围示例
客户成果让客户成功所需的一切部署、定制、培训、采用
客户专属配置将产品适配到客户场景数据映射、UI 定制、集成
演示构建创建客户专属演示行业专属演示、POC 环境
一线反馈将所学提炼为可执行的输入功能需求、缺陷报告、模式识别
生产部署让解决方案在客户环境中上线环境搭建、上线、初期稳定

产品团队负责

领域范围示例
核心产品功能开箱即用的功能平台能力、标准工作流
技术文档如何使用和扩展产品API 文档、数据模型、架构指南
开发环境FDE 能够在本地工作的能力安装脚本、docker 配置、种子数据
影响 FDE 工作的缺陷修复对阻塞一线问题的优先响应关键缺陷、环境问题
产品路线图参考一线反馈功能优先级排序、技术方向

共同负责

领域产品团队角色FDE 角色
早期客户部署(前 1-2 个)主导技术工作支持、学习、提供客户背景
演示环境提供基础演示能力构建客户专属扩展
功能需求排定优先级并开发识别模式、清晰表达需求
架构决策最终决定积极贡献、提供一线视角

FDE 可以向产品团队提出的要求

这些是不可妥协的。没有它们,FDE 无法有效工作。

1. Working Development Environment

标准:FDE 应能在 4 小时内从零开始跑起代码。

产品团队必须提供：

  • 单一代码仓库（或清晰的多仓库指南）——不能分散在 GitHub、Azure DevOps 和本地机器上
  • README，其中包含切实可行的安装说明
  • Docker/容器化配置或清晰的依赖列表
  • 环境变量文档，附示例值

验证方式：新的 FDE 仅凭书面说明即可完成安装配置。

2. Target Data Model Documentation

标准：FDE 应了解产品期望的数据结构。

产品团队必须提供：

  • 实体关系图或等效文档
  • 关键实体的字段级文档
  • 能覆盖主要工作流程的示例数据
  • 验证规则和约束条件

为什么重要：FDE 负责构建从客户数据到产品数据模型的适配器。不了解目标，他们只能靠猜。

3. API/Integration Documentation

标准：FDE 应无需阅读源代码即可完成集成。

产品团队必须提供：

  • API 端点文档（请求/响应格式）
  • 身份验证/授权指南
  • 错误代码及处理指南
  • 速率限制和性能预期

4. Feature Flag / Configuration Guide

标准：FDE 应了解哪些内容无需修改代码即可配置。

产品团队必须提供：

  • 功能开关列表及其控制的内容
  • 配置选项及其效果
  • 如何按客户启用/禁用功能

5. Response Time SLA

标准：FDE 不应因等待产品团队回复而被阻塞。

问题类型响应时间解决时间
环境阻塞问题4 小时24 小时
严重缺陷（影响客户）4 小时48 小时
文档问题24 小时不适用
功能请求1 周（确认）按路线图

产品团队作为早期 FDE

规则

对于尚无生产环境客户部署的产品，产品团队应作为前 1-2 个客户的 FDE。

为什么有效

  • 产品人员亲身体验自身的摩擦点
  • 他们能感受到文档缺失带来的痛苦
  • 他们会发现部署中真正的难点
  • 他们无法把责任推给 FDE“不理解”
  • 更快的反馈循环
  • 无交接延迟
  • 即时修复
  • 真实客户需求驱动路线图
  • 更好的后续交接
  • 产品团队了解 FDE 需要什么
  • 文档在部署过程中同步创建
  • 对 FDE 工作的合理预期

如何安排

客户 1：产品团队主导（90%），FDE 跟随观察（10%）

  • FDE 通过观察学习产品
  • 产品团队在过程中同步创建文档
  • FDE 提供客户关系支持

客户 2：共同承担（50/50）

  • FDE 承担更多技术工作
  • 产品团队填补空白并解答问题
  • 文档得到测试和改进

客户 3 及以后：FDE 主导，产品团队支持

  • 完全交接
  • 产品团队可随时处理升级问题
  • 定期反馈同步（每周）

何时可以跳过此流程

  • 产品已有 3 个以上成功的客户部署
  • 现有文档和工具完善
  • FDE 团队对类似产品有深厚经验

反馈循环

每周同步（必须参加）

参会人：FDE 负责人 + 产品负责人

时长：30 分钟

议程：

  • FDE 阻塞项（5 分钟）— 什么在阻碍进展？
  • 客户模式（10 分钟）— 我们在各客户身上观察到了什么？
  • 路线图核对（5 分钟）— 是否有影响 FDE 工作的变更？
  • 行动项（10 分钟）— 谁在何时之前做什么？

待办事项可见性

FDE 实施待办事项应对产品团队可见。

目的：

  • 识别各客户的共同需求（→ 应转化为产品功能）
  • 发现客户需求与产品方向之间的冲突
  • 为优先级决策提供依据

形式：共享看板（Jira、Linear 等），包含：

  • 客户名称
  • 需求描述
  • 业务影响
  • 当前变通方案（如有）

季度回顾

FDE + 产品团队全员回顾：

  • 本季度出现了哪些模式？
  • 哪些应从“FDE 定制”转为“产品功能”？
  • 还有哪些文档/工具缺口？
  • 下一季度的路线图对齐

升级流程

何时升级

情况行动
FDE 在环境/工具上被阻塞超过 24 小时升级至产品负责人
关键客户承诺面临风险升级至双方负责人 + 工程管理层
反复出现摩擦的模式升级至工程领导层以进行系统性修复
在方法上存在根本性分歧升级至共同上级或 CTO

升级路径

FDE → FDE Lead → Engineering Manager → VP Eng / CTO
         ↓              ↓
    Product Lead → Engineering Manager

升级模板

SUBJECT: [ESCALATION] [Client Name] - [Brief Issue]

SITUATION:
What's happening? What's the impact?

BLOCKER:
What specifically is blocking progress?

ATTEMPTED:
What have you already tried?

ASK:
What do you need, from whom, by when?

CONSEQUENCE:
What happens if this isn't resolved?

平台优化理念

错误所在

在 FDE 尚能有效使用平台之前，就针对“低代码/无代码”最终用户进行优化。

现实情况

对于早期产品：

  • FDE 是你的第一批用户
  • FDE 需要的是开发者体验（DX），而非最终用户体验（UX）
  • 如果 FDE 无法在你的平台上构建，客户也无法做到

这意味着什么

优先：

  • API 优先的开发
  • SDK/程序化访问
  • 清晰的扩展点
  • 开发者文档

暂缓（目前）：

  • 可视化构建器
  • 拖拽式界面
  • 无代码配置
  • 最终用户教程

顺序：

  • 构建可用的 API
  • 在 API 之上构建 SDK
  • 在 SDK 之上构建可视化工具
  • 只有到那时：无代码/低代码功能

FDE 对产品的贡献

FDE 应贡献代码

发现产品缺口的 FDE 应被授权：

  • 构建可运行的原型
  • 向核心产品提交 PR
  • 提出架构变更建议

贡献规则

应该做的：

  • 走最快路径解决客户问题
  • 记录你构建的内容及原因
  • 标记出任何应该被泛化的内容
  • 遵循现有的代码规范

不要：

  • 维护长期存在的分叉版本
  • 构建与产品功能重复的并行系统
  • 做出只对某一个客户有效的更改
  • 跳过测试或文档

合并预期

变更类型谁来合并时间线
Bug 修复产品团队审查，FDE 可合并<1 周
小功能产品团队审查并合并1-2 周
架构变更联合设计评审，产品团队实施按路线图

长期分支是被禁止的

偏离 main 分支超过 2 周的分支就是一种失败模式。

如果你有一个长期存在的分支：

  • 它本应被合并（拆分成更小的变更）
  • 它本应成为一个产品功能（将其纳入路线图）
  • 它本应被放弃（无法扩展的客户特定临时方案）

常见 dysfunction 及修复方法

“产品团队太忙，没时间处理 FDE 的请求”

症状：FDE 的请求在待办事项中搁置数周。

根本原因：产品团队不认为自己对 FDE 的成功负有责任。

修复方法：

  • 将 FDE 的阻塞事项纳入产品团队的冲刺规划
  • 将“FDE 被阻塞的时间”作为一项指标进行跟踪
  • 让高管层了解 FDE 遇到的摩擦

“FDE 不断提出不在路线图上的需求”

症状：客户需求与产品团队正在构建的内容之间存在矛盾。

根本原因：路线图没有反映一线的实际情况。

修复方法：

  • 季度规划中必须纳入 FDE 的意见
  • 明确分配：路线图中 X% 由一线反馈驱动
  • 产品团队成员与 FDE 共同拜访客户

“文档总是过时的”

症状：FDE 无法信任书面文档。

根本原因：文档被视为与代码分离的东西。

修复方法：

  • 文档存放在代码仓库中
  • PR 审查包括文档更新
  • FDE 发现文档问题时直接修复（并且会被快速合并）

“我们不知道 FDE 在做什么”

症状：产品团队对 FDE 的定制化工作感到意外。

根本原因：对 FDE 的工作缺乏可见性。

修复方法：

  • 为 FDE 的实施工作建立共享看板
  • 每周同步会议（不可协商）
  • FDE 在产品团队会议上进行演示

成功指标

领先指标

  • 新 FDE 搭建环境所需时间（目标：<4 小时）
  • 在待办事项中搁置超过 1 周的 FDE 请求（目标：0）
  • FDE 的 PR 在 1 周内合并的比例（目标：>80%）

滞后指标

  • 客户部署时间（呈下降趋势）
  • FDE 对产品团队支持的满意度（季度调查）
  • FDE 发现的模式最终成为产品功能的比例

检查清单：你的协作接口是否有效？

对于 FDE 负责人：

  • 新 FDE 能否在 4 小时内搭建好环境？
  • FDE 是否清楚产品团队必须提供什么？
  • 是否有一个真正能按时举行的每周同步会议？
  • FDE 是否感到自己有能力贡献代码？
  • 被阻塞时是否有明确的升级路径？

对于产品负责人：

  • 你是否知道 FDE 目前正在做什么？
  • 在上一季度，你是否亲自参与过一次客户部署？
  • FDE 的反馈是否在明显影响你的产品路线图？
  • 你的文档是否足够准确，让 FDE 信任它们？
  • 你能说出 FDE 面临的三大摩擦点吗？