去年年底我陪一个同事去客户现场做交付项目本身不大——帮一家零售连锁搭一套门店销售预测系统。按理说三天搞定的事硬是拖了两周。问题出在哪不是技术是需求。客户说我要一个预测模型我们就给了预测模型。客户说能不能加个门店对比功能我们就加了门店对比。客户说报表能不能自动发邮件我们也做了。你别说每个需求拆开来都不难但两周下来我同事差点崩溃——每天改需求每天补功能每天都是再加一个就好。有意思的是后来我换了种方式跟客户聊——我不问你要什么功能我问你每天早上开晨会看什么数据。就这么一句话整个项目走向变了。这个事让我想明白一个道理FDEForward Deployed Engineer前沿部署工程师做到一定程度瓶颈根本不在技术。你 Docker 玩得再溜K8s 调得再顺如果永远在接需求做功能那你做的永远是项目不是解决方案。项目 vs 方案差的不是代码量是思维。先说项目思维是什么样。客户说我要一个仪表盘你吭哧吭哧做出来客户说颜色不对你改颜色。客户说再加个筛选器你加筛选器。看起来挺高效实际上你一直在给客户当打字员——客户说一句你打一句永远慢半拍。而且最要命的是客户自己都不知道他到底要什么。你问他要什么功能他给你列一堆做出来发现根本不是他想要的。这不怪客户客户不是产品经理客户是业务专家。你可能会说那我能怎么办客户说啥我做啥还不行吗说实话以前我也这么干。直到有一次一个客户在验收会上说了一句话让我印象特别深你们做的东西都对但我觉得不是我要的。都对但不是我要的——这六个字就是项目思维和方案思维的分水岭。方案思维不问你要什么问你遇到了什么问题。举个具体例子。我上一个项目里客户一开始说要做一个门店销售预测看板。如果按项目思维直接开干就完了。但我多问了一句你拿到这个预测之后下一步要做什么客户愣了一下说如果预测 A 店下周销量会下降我就提前调货过去。那你现在怎么判断要不要调货的店长凭经验拍脑袋。那你希望这个系统帮你做决策还是帮你做判断帮我做判断吧——系统告诉我数据和趋势我自己决定怎么调。你看聊到这儿我才发现客户真正要的不是预测看板而是一个辅助调货决策的数据工具。前者是一个功能后者是一个解决方案。如果我按项目思维做做完预测看板客户可能还是不满意因为他拿到预测数据之后还得自己手动算调货量。但按方案思维我在预测看板后面加了一层——把预测结果和库存数据打通自动生成建议调货量。代码量不大但客户说这下对了。你别说这个多问一句的习惯后来成了我判断一个 FDE 有没有开窍的标志。普通 FDE 等需求优秀 FDE 挖需求。普通 FDE 交付功能优秀 FDE 交付价值。那怎么做到可复用的方案思维我琢磨了一阵发现核心就三个习惯。第一个习惯是做抽象。每做完一个项目别急着清缓存走人。花半天时间把项目里写的代码、配的规则、画的架构图拎出来看一遍哪些是跟这个客户强相关的哪些是可以抽出来给下一个项目用的。我现在的工具库里有一个通用数据接入模板就是从三次不同客户的项目里反复抽象出来的——第一次给零售客户用第二次给物流客户改了一下第三次给金融客户改改完发现 80% 是通用的。从那以后这个模板成了我所有项目的起点至少省一半时间。第二个习惯是画场景图不是画架构图。架构图是给工程师看的场景图是给客户看的。你画一个用户从打开系统到完成决策的完整流程每一步标出这里客户在纠结什么这里需要什么数据这里谁来操作。画面一摆出来客户自己就会说哦这里其实不需要那么复杂简单点就行。我吃了好几次亏才发现——客户不是看不懂技术而是你没用他能看懂的方式跟他沟通。第三个习惯是留扩展口。做方案的时候别把功能做死。比如你写一个数据查询接口别只返回当前客户需要的字段加一个自定义字段的扩展参数。下一次新客户来需求变了你改几个配置就行不用重新写代码。说实话我见过太多 FDE 每次交付都从零开始不是因为技术差是因为没想过下次还能用。看到这儿你可能会想这些道理我都懂但项目催得紧哪有时间做抽象、画场景图我完全理解。说实话我也不是一开始就这么干的。我第一次做抽象的时候项目方催得跟什么似的我硬挤了两天时间做模板化结果下一个项目一来直接省了一周。从那以后我就信了——省时间的最好方法是花时间把事情做对。谁适合培养方案思维如果你已经在 FDE 岗位上做了半年以上每天面对客户的需求觉得做不完或者做完了客户还是不满意——那你大概率缺的不是技术是方案思维。如果你刚入行还在学技术栈的阶段先别急着学方案思维把代码写稳了再说。谁不适合如果你只想安安静静写代码不想跟客户聊需求不想做需求分析——那方案思维对你来说可能是个负担。FDE 这个岗位本身就有很强的接客属性不喜欢跟人打交道的话做纯后端开发可能更舒服。这不是贬义每个人都有自己的赛道。下一篇我会聊聊快速学习一个陌生领域的方法论——FDE 经常要面对昨天没听过今天要搞定的领域怎么快速上手我踩过不少坑到时候给你讲讲。你觉得方案思维是天生的还是可以练出来的欢迎在评论区聊聊你的看法。
