FDE应该向谁汇报？组织位置决定成败

这个问题看起来很行政，实际上是决定 FDE 真假的关键结构问题。同样一批人，挂在不同的部门下面，三个月后会长成完全不同的样子。

一、挂在销售下面会发生什么

销售体系的核心指标是签单和回款。挂在这条线下的交付团队，第一优先级会变成「不要让客户不高兴，保证尾款能收回来」。

结果就是客户提什么做什么，不敢说不。三个月后这批人做的事情和人力外包没有区别，只是名片上印着工程师。

更麻烦的是资源分配。销售负责人手里的资源永远优先给新单，已签约项目的深度打磨拿不到人。而 FDE 模式的价值恰恰在深度。

二、挂在纯研发下面会发生什么

研发体系的核心指标是版本交付和技术质量。挂在这条线下的工程师，会本能地把客户的个性化需求视为污染，能不做就不做。

这会走向另一个极端：产品很干净，但客户用不起来。现场那些「不合理」的流程恰恰是业务真实的样子，一味拒绝等于放弃理解现场。

还有一个现实问题：研发的排期以周甚至月为单位，而现场需要的是当天响应。节奏对不上，前置部署的意义就消失了。

销售线上的交付团队会变成外包，研发线上的交付团队会变成远程支持。两条路都到不了 FDE。

三、比较合理的两种安排

第一种是独立成线，直接向公司一号位或专门的交付负责人汇报，与销售、研发平级。好处是不被单一指标绑架，坏处是对公司规模有要求，小公司撑不起第三条线。

第二种是挂在产品体系下，但拥有明确的现场决策权和产品需求提案权。这样能保证现场发现的问题有回流通道，同时避免被销售指标牵着走。

无论哪种，有一条必须保证：FDE 提出的产品需求要有一条正式的、不需要求人的评审通道。没有这条通道，现场知识回流就是一句空话。

四、阿优至简的视角

我们团队规模不大，做法是把交付和方法沉淀合为一条线。谁在现场解决了问题，谁就负责把它写成下次能直接用的东西，这两件事不分给两个人做。

对中小服务商来说，组织设计的重点不是画多少个框，而是保证现场信息不被任何一个部门私自截留。信息只要在中间断一次，前置部署就退化成了跑腿。

落地前的三条至简建议

1. 先看汇报线：评估一家服务商时，问一句交付团队向谁汇报，答案很说明问题。
2. 先建通道：确保现场提出的产品改进有正式评审入口，而不是靠私人关系推动。
3. 先分指标：交付团队的考核里回款权重不宜过高，否则模式必然退化。

组织结构是一种沉默的指令。它不发通知，但每天都在告诉团队什么最重要。