M0第 2 课 · FDE 与相邻岗位
M0-L2.2角色判据
一句话： 比”写不写代码”更能区分 FDE 和相邻岗位的是三个问题：代码是否进入生产环境，一线经验是否回流到产品，工作是按时间还是按结果计价和考核。
“写不写代码”不是区分岗位的好办法。解决方案工程师写代码，技术咨询顾问写大量代码，外包团队整天都在写代码。真正不同的，是代码、知识和钱最后去了哪里。
| 判据 | 要问的问题 | FDE 的答案 | 它把 FDE 和谁区分开 |
|---|---|---|---|
| 1. 代码去哪里？ | 你做的东西是否在客户的生产环境运行？ | 是，并且要达到生产标准 | 售前（demo 代码）、客户成功（很少写代码） |
| 2. 经验去哪里？ | 项目结束后，你学到的东西是否进入了某个产品？ | 是，可复用的部分回到本公司的产品 | 咨询、系统集成、外包 |
| 3. 为什么付钱、按什么考核？ | 工作是按投入时间还是按结果定价，人是按什么被考核的？ | 按结果：采用、客户指标、续约扩容 | 人力外派、按人天计费的合同 |
FDE 为什么需要
Section titled “FDE 为什么需要”这些判据让你可以给任何岗位定位，包括你自己的，而不必争论头衔。它们也是对”FDE 是不是换了名字的咨询？“的诚实回答：有时候是，判据能告诉你什么时候是。
单个判据不够用
Section titled “单个判据不够用”一家大型咨询公司能通过判据 1（它交付生产系统），也可能通过判据 3（存在按结果收费的合同）。外包团队也能通过判据 1。判据 2 是最持久的区别，因为它取决于一个结构性的东西：有没有一个属于 FDE 所在公司的产品，让这份工作建立在它之上并回流到它里面。正是这种关系让下一个客户的成本更低。
判据背后的四个维度
Section titled “判据背后的四个维度”比较岗位时，看四件事：
- 责任： 这个人最终对什么负责。
- 与产品的关系： 工作是否建立在本公司的产品之上。
- 可复用的产品杠杆： 做出来的东西是否让下一次部署更便宜。
- 对生产结果的所有权： 如果在生产中失败，这个人是否要负责。
同一批工程师，不同的合同
Section titled “同一批工程师，不同的合同”设想同一支团队为一家零售商做补货 Agent。按天计费、除工时外没有其他义务，这是外包。固定范围、合同里写明可复用组件回到供应商的产品，这已经接近 FDE。按缺货率是否真的下降来收费，同时可复用部分回流，这是完整形态的 FDE。工程师和代码可以一模一样；改变角色的是合同和知识的流向。
判据用来定位，不是打分
Section titled “判据用来定位，不是打分”大多数真实岗位是混合的：主要写生产代码但也支持售前，部分经验回流，目标部分按结果。用判据看清一个岗位在哪里，以及你想往哪个方向走。
- “写生产代码就是 FDE。” 咨询和外包也写。要看判据 2 和 3。
- “必须按结果收费。” 很多 FDE 拿固定薪水，公司卖的是订阅。判据 3 问的是这个岗位是否按结果考核，而不是发票上怎么写。
- “没通过某个判据，岗位就更差。” 那只是另一种岗位。
FDE 和咨询顾问有什么区别？
区别不在写不写代码；好的技术咨询顾问也交付生产系统。区别在产品：FDE 在本公司的产品之上交付，并把学到的东西回流进去，所以公司服务每个客户的成本会随时间下降。咨询公司的复用沉淀在方法论和加速器里，收入仍然随人数增长。
你会问什么来判断这个岗位是不是真正的 FDE 工作？
上一个部署的代码现在还在跑吗，谁在维护？为客户做的东西有没有进入产品？这个岗位按什么指标考核？
- 文章：Dev versus Delta: Demystifying Engineering Roles at Palantir（Palantir 博客，约 10 分钟）— 一家公司内部，产品工程与部署工程如何配合