FDE模式：前线工程师如何破解数字化落地鸿沟

2019年我参与某大型企业的数据平台升级项目时遇到一个非常典型的场景厂商的交付团队在验收报告上签完字就撤了客户这边却陷入系统上线三个月业务部门基本不用的尴尬局面。后来我们临时抽调三名工程师驻场三个月跟着客户梳理了四十多套业务流程才勉强把系统救活。那一年我意识到传统意义上的交付完即结束模式正在失效行业真正需要的是一种驻扎前线、和客户一起把方案磨出来的人。这两年这种角色被越来越多地称作FDE也就是前线部署工程师。围绕FDE模式、腾讯FDE课程、FDE工程师学习路线、FDE的轮岗晋升社区分享机制、以及FDE解决方案部署工程师高级报名和证书的一系列讨论已经从零散的岗位描述逐渐演变成一套完整的人才培养与组织运作体系。这篇文章我想结合自己的观察和实操经验聊聊FDE模式到底在解决什么问题、前线工程师的真实工作流长什么样、以及这个方向的学习和进阶路径。1. FDE模式为什么突然火了前线共创的逻辑起点1.1 从交钥匙到陪跑共创FDE与传统实施工程师的本质差异传统项目实施模式下厂商的工作边界很清晰签合同、做需求调研、开发配置、测试上线、验收走人。行业里把这个叫交钥匙工程听起来省心但问题恰恰出在这里——客户买到的是一套能运行的软件不是一套能解决问题的机制。我见过太多失败的案例项目的需求文档写了两百多页页面权限、角色配置、字段映射全都定义得密密麻麻。可一旦交付团队撤场业务部门真实使用的时候才发现系统里跑的数据结构和他们日常纸质流程根本对不上线上审批卡在某个环节没人知道怎么办。合同上写的是功能已实现但功能实现和业务跑通之间隔着一道看不见的鸿沟。FDE模式出现的根本原因就是行业发现这道鸿沟靠传统的交付流程填不上。FDE工程师的角色定位是常驻客户一线从需求澄清、方案设计一直跟到落地运维和持续迭代他不是交钥匙的人而是陪跑的人。这个区别用一句话说清楚传统交付工程师对合同范围负责FDE对业务结果负责。我自己做过的几个驻场项目里FDE最明显的动作是坐在业务人员旁边办公而不是坐在会议室里写纪要。业务人员点错一个按钮、报表多出一列数据、审批流程多走一个分支这些细碎的、无法提前写进需求文档的信息才是FDE真正的价值输入。1.2 FDE解决的核心痛点需求断层与方案落地鸿沟把FDE模式放回行业大背景看它解决的是两个长期被轻视的问题。第一个是需求断层。传统模式下需求调研通常由售前顾问和产品经理完成他们访谈的是客户的信息化负责人而不是真正使用系统的车间主任、财务专员或客服主管。等开发团队拿到需求说明书时原始业务上下文已经丢失了一大半。FDE的存在改变了信息传递路径工程师直接站在业务现场听到的是库存管理员的真实吐槽而不是被转述的需求条目。第二个是方案落地鸿沟。很多系统功能具备但客户不会用、不愿用、不敢用。这其中有操作习惯的问题也有流程再造带来的岗位焦虑。FDE要做的不只是部署安装还要做大量的解释、培训、流程微调、甚至临时写脚本帮客户过渡。这些工作在传统交付合同里没有名字却是系统真正产生价值的必经之路。从行业数据看过去几年头部互联网企业和软件公司陆续开始设立FDE岗位给我的体感是这个角色正在从应急救火队变成标准配置。原因不复杂SaaS和平台型产品竞争到后期产品功能本身越来越难拉开差距真正的护城河在实施落地效率和客户成功深度上。FDE模式本质上就是一种把客户成功从口号变成具体岗位职责的组织设计。1.3 FDE模式的双向赋能到底指什么标题里的双向赋能不是一句漂亮话它有两层非常务实的含义。正向赋能是指FDE把公司的产品能力和技术方案带进客户现场帮客户团队自助使用、二次开发、甚至是培养客户自己的运维能力。一个好的FDE在项目结束时会发现客户团队已经能独立处理八成以上的日常问题而不是养成依赖。反向赋能则是FDE把前线的真实需求、使用数据、共性痛点带回产品团队。这点在驻场项目中体会特别深。以前产品经理做需求排期靠的是问卷和二手反馈有了FDE之后产品组能拿到的是现场录屏、操作日志、甚至客户原话。这些素材对产品迭代方向的修正作用远超几十份PRD文档。双向赋能真正运转起来需要组织制度配合比如后面会详细讲的轮岗机制和案例沉淀。如果没有制度保障FDE很容易变成驻场外包既无法反哺产品也留不住人。这一点我认为是很多公司模仿FDE模式最容易踩的坑。2. FDE工程师的真实工作流从现场诊断到方案落地的完整链路很多人以为FDE就是去客户现场驻场但驻场只是表象真正的工作内容是高度结构化的一整套流程。我按照自己带团队的经验把FDE的完整工作链路拆成四个阶段每个阶段都有明确的目标、关键产出和常见坑。2.1 第一阶段现场诊断与需求澄清FDE进入客户现场的头一到两周最重要的目标不是写代码更不是急着出方案而是建立对客户业务的手感。我给自己定过一个要求前两周不碰键盘做开发只做三件事。第一件事是跟着业务人员走完一遍核心流程。我见过一个做仓储物流项目的同事头三天就蹲在分拣线上看现场操作记了一整本笔记连工人怎么贴面单、怎么处理异常件都画了流程图。这个细节在后面配置WMS系统参数时简直救命他比客户自己的IT团队更清楚哪些规则是刚性的、哪些是人为约定。第二件事是访谈关键干系人。这里有个非常重要但常被忽略的原则访谈对象不能只覆盖管理层和使用者还要包含系统运维人员。管理者给你的是期望使用者给你的是痛点运维人员给你的才是约束条件。权限策略、网络环境、数据备份要求这些硬约束往往只有运维团队会说真话。第三件事是把模糊需求转化成可验证的验收标准。业务方说报表要更好看FDE要能追问出哪些角色看、多久看一次、看到之后要做什么决策然后把它变成导出按钮3秒内响应首页展示昨日核心指标这样的可执行描述。这一步做不好后面所有开发和配置都会摇摇欲坠。2.2 第二阶段方案设计与定制开发边界需求澄清完成之后FDE要对解决方案有一个总体判断哪些需求是产品标准功能可以覆盖的哪些要通过配置实现哪些必须走定制开发。这三件事的成本和风险完全不是一个级别。标准功能覆盖的需求直接进入配置清单配置项的需求要重点评估是否会影响未来产品升级定制开发是最后的选项我必须反复确认业务方的真实诉求因为很多非定制不可的需求本质上是对标准逻辑不理解产生的误解。这个阶段我还坚持一个原则叫先纸面推演再环境验证。FDE在设计方案时不能只在脑子里想要拉出一套测试环境把逻辑跑一遍。比如客户要求超过48小时未处理的工单自动升级听起来简单但48小时是按自然日还是工作日算、法定节假日怎么处理、升级之后原负责人是否还能看见工单——这些问题在测试环境一跑就全暴露了。纸面上讨论永远发现不了边界条件只有实际执行会让隐藏的复杂度浮出水面。2.3 第三阶段部署实施与稳定性运维方案确认后进入实施期这部分工作看起来和传统实施工程师重叠但FDE模式下的实施有一个显著区别变更节奏更快、且直接暴露在业务侧。传统实施可以按周发布FDE在客户现场往往需要做到按天甚至按小时响应。我在驻场阶段最常做的工作是这三类第一种是环境配置包括服务器部署、数据库初始化、第三方系统接口联调这部分最考基本功网络通不通、端口放没放、证书过期没过期这些看似基础的问题往往要折腾半天第二种是数据迁移和清洗客户上线新系统最怕的就是历史数据导入不进去编码规则不一致、字段长度超标、时间格式混乱每一条都要手工处理这个阶段FDE要有极强的耐心第三种是问题响应业务方白天在用系统任何异常都会第一时间找你这就要求FDE对系统日志、监控告警这些排障手段非常熟练。稳定性运维还有一个容易被忽视的维度变更管理。在客户现场修改配置、升级版本必须做记录、备份、回滚预案。我踩过最大的一个坑就是直接在客户生产环境改了一个字段校验规则没有通知任何人结果下游数据全乱了。从那以后我给自己定了铁律任何变更走工单任何变更有回滚计划任何变更后测试核心链路。2.4 第四阶段反馈闭环与产品反哺系统上线稳定运行不代表FDE工作结束反而是一部分工作的开始。度过了最初的上线磨合期FDE要把精力从救火转向反哺。反哺工作分两个方向。一个是帮客户建设自运维能力包括输出运维手册、做知识转移培训、帮客户IT团队梳理日常巡检清单。好的FDE要做到客户能独立处理80%的日常问题而不是事事都找你。另一个是向产品或研发团队输出前线洞察。每个季度我会整理一份现场问题分析报告核心内容是三个清单共性需求清单、产品缺陷清单、行业差异清单。这份报告的价值非常大它比任何市场调研都真实因为每一个条目背后都是客户真实的业务动作和损失。产品经理看到这份报告就知道下一个版本该优化什么。反哺这个环节做得好的团队和做得不好的团队之间有一个明显差别做得好的是产品团队真的会消化这些反馈并且回给FDE结果做不好的是FDE写了报告没有下文。后者会让前线工程师觉得自己是信息上传的工具很快就没了积极性。这一点需要组织机制来保障我在第5章会专门讲社区分享机制怎么解决这个问题。3. FDE工程师的能力模型技术、沟通与业务的三位一体网上关于FDE工程师学习路线的讨论很多但多数只停留在技术栈层面。我的体感是FDE的能力模型跟纯后端开发或纯售前顾问都不一样它是技术、沟通、业务三块能力拧在一起的状态。缺哪一块都会在实际工作中碰壁。3.1 技术硬实力哪些技术栈必须扎实先说技术这是FDE的立身之本没有这个前面讲的流程和方法论都是空中楼阁。我建议FDE工程师重点掌握以下几类技术能力。第一是操作系统和网络基础。FDE跟客户现场的环境打交道Linux系统操作、基础网络排查、DNS解析、端口连通性测试这些是每天都要用的。我面试FDE候选人时会拿一道最简单的题客户说系统访问不了你第一步干什么很多候选人上来就说查代码而正确答案是先确认网络连通性和域名解析。第二是数据库能力。FDE要经常查数据、导数据、改数据SQL水平必须过硬简单的增删改查、多表联查、索引优化、数据备份恢复这些都得熟练。我在现场解决过最经典的问题就是客户报表统计口径有误最后排查发现是SQL里left join和inner join用混了。第三是脚本开发能力。FDE在客户现场会遇到大量重复性的手工操作比如批量改用户权限、定时同步数据、解析日志文件。这时候会写Python脚本或Shell脚本效率能提升十倍。我见过一个同事用一百行Python脚本把原本需要三个通宵才能完成的数据清洗工作缩短到十分钟。第四是产品和系统架构理解力。FDE虽然不用自己从零开发大系统但必须深刻理解自家产品的架构设计知道每个模块之间的依赖关系、数据流向、扩展点在哪。这样在给客户做方案时才能判断哪些需求可以在现有架构上低成本满足哪些需要做较大调整。技术这个维度我不建议一开始就追求深度最好是广度优先深度跟进。所谓广度是指上面几个方向都要能上手干活所谓深度是指在项目实施中遇到某个具体场景时再针对性地把相关技术学透。这和做研发的思路不太一样FDE的技术能力是在无数个具体问题的解决中磨出来的不是看书看出来的。3.2 软技能为什么说FDE是翻译官FDE这个角色最有意思的地方在于它在客户和产品团队之间扮演的是翻译官。但这个翻译官要翻译的不只是语言更是业务语言和技术语言、期望和现实之间的鸿沟。业务人员说我希望系统能自动帮我们做风险预警FDE心里要能立刻拆解成风险规则有哪些维度预警阈值是多少通过什么渠道通知通知不送达时是否升级这些问题的答案业务人员往往自己也没有想清楚FDE的沟通能力就体现在通过提问把自己的理解嵌入对方的业务语境中。FDE沟通还有一个特殊场景冲突调解。客户提的需求和产品既定路线不一致时FDE不能简单地说这个做不了而是要给替代方案反例是客户非要一个复杂的自定义报表工具但你判断这会导致未来升级困难那就可以建议先用标准报表加上定期人工导出过渡同时把真实需求反馈给产品团队排期。这个过程既要让客户感觉自己被尊重又要守住技术底线。我给团队新人的建议是FDE的沟通要遵守三要三不要。要复述确认、要给选择题、要留文字记录不要当场承诺开发周期、不要在电话里吵技术对错、不要绕过运维直接改生产环境。这三要三不要背后都是血泪教训。前年一个新人忘记了留文字记录客户需求变更两个月后翻脸不认账最后凭一封邮件才说清楚责任归属。这类问题在驻场项目中非常普遍文字记录不是形式主义是工作留痕更是保护自己。3.3 从初级到高级能力进阶的四个阶段结合FDE解决方案工程师高级报名和认证的考察方向来看FDE的成长大致可以分成四个阶段每个阶段的能力侧重和典型交付物都不太一样。第一阶段是纯执行者。主要工作是在有资深工程师指导的情况下完成环境部署、数据导入、接口联调。这个阶段要求技术基本功扎实能严格执行方案遇到问题有排查意识。多数人在这个阶段待三到六个月。第二阶段是独立交付者。开始独立负责中小型项目的整体落地能完成需求诊断、方案设计和运维保障全流程能和客户业务方顺畅沟通。到了这个阶段FDE已经开始展示翻译能力了能独立澄清业务部门说不清楚的需求。第三阶段是方案架构者。很多人卡在这个阶段上不去。核心差别在于这个阶段要求FDE具备跨模块甚至跨产品的方案设计能力能够针对客户的复杂业务场景设计出融合多种能力的整体方案。不再只是问这个功能怎么配而是思考这套业务该怎么被数字化重构。第四阶段是行业专家。在这个层级FDE已经不局限在单一客户项目了而是能总结出行业共性痛点、沉淀解决方案模板、参与产品路线规划。高级FDE对产品团队的影响力往往比一个产品经理更大因为他手里握着真实的市场需求数据。阶段核心任务关键技术要求主要产出纯执行者部署实施、数据清洗、问题响应Linux操作、SQL、脚本基础部署记录、问题处理报告独立交付者独立负责中小项目全流程需求澄清、方案配置、沟通协调项目落地方案、客户培训记录方案架构者复杂方案设计和产品化架构理解、跨模块设计、行业认知高层方案、解决方案白皮书行业专家行业沉淀与产品反哺行业方法论、咨询能力、影响力行业解决方案模板、产品改进建议4. FDE学习路线与认证从入门到高级解决方案工程师关于FDE工程师学习路线的问题我在各种技术社区的私信里被问过无数次。比起具体的书单或课程列表我更想先分享一个结论FDE不是一个先学后做的岗位而是在项目中迭代成长的角色。但这不代表没有学习路径而是学习路径必须围绕场景来组织而不是围绕技术栈来组织。4.1 面向新人的FDE学习路线规划针对零基础和转行候选人我的建议是把学习分成三条线并行推进。第一条线是技术基础线周期约三到六个月。这条线不追求深度拉通即可。Linux系统操作、SQL增删改查与数据迁移、Python或Shell脚本基础、基本网络知识这几项可以按周排计划每周集中攻克一个主题。我对候选人的最低要求是给一台干净的操作系统能够独立安装软件、配置环境、部署一个简单的web应用并能看懂日志排查启动失败的原因。能做到这些就具备了进入项目的底线动手能力。第二条线是产品认知线。这段时间要仔细研究自己所在公司或目标公司的产品线把产品的核心功能模块、典型应用场景、各版本演进脉络全部梳理一遍。最好的方法是搭建一套自己的学习环境实际操作把官方文档里提到的每一个配置项都点一遍记录操作效果。产品认知的积累没有捷径我跟团队新人说过一个死办法把过去一年项目的实施文档和问题处理记录翻完你会比做一年重复工作的人进步快得多。第三条线是软技能线。这条线常常被新人忽略但它往往是决定是否被客户信任的关键。我的建议是刻意训练两种能力需求追问能力和汇报表达能力。需求追问能力的训练方法很简单找一个朋友扮演业务方给出一个模糊的需求你在一周内追问出十个可以写进验收标准的具体问题。汇报表达能力的训练每周写一篇项目周报要求用简洁的语言说清楚问题、原因、方案、结果。4.2 高级解决方案工程师的考核要点聊到FDE解决方案工程师高级报名很多人关心的核心问题是高级比中级到底多考了什么从我带团队和参与评审的经验来看高级考核与初中级的差异主要体现在三个维度。第一个维度是复杂度处理能力。中低级别的考核题目通常给一个相对明确的需求考察的是能否把方案做对高级题目往往刻意设置需求矛盾比如资源有限、时间紧迫、业务方要求冲突考察的是能否在约束条件下做出合理的取舍。我印象很深的一道考核题是一个跨三个业务部门的需求协调场景三个部门对同一个数据字段理解不同要求解决方案团队给出既能满足当前要求、又不会阻断未来扩展的方案。这考的完全不是技术而是权衡和推进能力。第二个维度是方案的可复制性。高级工程师做方案不能只看单个客户的成功还要考虑方案能否沉淀为标准模板让其他同事快速复用。这也是为什么很多高级认证会要求提交解决方案沉淀材料本质上是在考察你的抽象总结能力。第三个维度是商业意识。到这个层级FDE要能算清楚账知道一个方案的人力成本、实施周期、潜在风险分别是什么。只懂技术不知道方案报价构成和商务逻辑的高级FDE在项目决策中是没有话语权的。4.3 证书的含金量与职业价值关于FDE证书的价值我的观点一直是证书不是敲门砖而是职业路径的结构化证明。技术行业原则上更看重能力但FDE这个职业方向相对新兴外界对其能力边界的认知还不统一这时候一套体系化的认证和培训课程确实能帮助从业者快速建立知识框架、让招聘方直观判断候选人的专业度。尤其对转行候选人来说考取认证的过程本身就是系统学习的过程。我在面试清一色简历的候选人时会专门问认证学习过程中印象最深的一个知识点或者是一次实操练习的细节。问这个问题的逻辑很简单如果候选人真的花了时间做了练习这种细节问题必然能答上来如果是背题库刷证书两三个问题就露馅了。因此我给的建议是不要把考证书当成终点而要把它当成一次结构化梳理的机会。学完、考完、落地一两个项目之后证书上写的那些知识点才会真正长在自己身上。5. FDE模式的轮岗、晋升与社区分享机制双向赋能的制度保障FDE模式要真正跑通单靠几个优秀的个体撑不起来必须靠组织制度。我在第1章提到双向赋能需要制度配合这一章就展开聊FDE的轮岗、晋升和社区分享机制这三者共同构成了FDE模式的组织底座。5.1 轮岗机制为什么FDE需要定期回炉FDE常驻客户现场有一个天然风险离公司太远技术和认知会逐渐和产品团队脱节。如果FDE长期只在客户现场做定制化开发和运维他会变得越来越像外包人员对产品的理解停留在自己常用的那几个模块上。轮岗机制就是用来解决这个问题的。理论上讲FDE应该每隔六到十二个月轮换一次角色回到产品研发团队待一两个月参与迭代开发和产品规划。这段回炉期有三重价值。第一重价值是技术保鲜。FDE回到研发团队后能接触到最新的技术架构、研发规范和工具链避免掉队。我看过太多FDE驻场两年后技术栈还停留在旧版本回到公司连新架构都看不懂。第二重价值是认知对齐。FDE在客户现场积累的感性反馈只有在回到产品团队后才能真正转化为产品改进项。面聊的效率比写十份邮件都高。我在产品团队轮岗时最有效的动作是直接把客户现场的录屏扔给产品经理看三分钟比三页PRD更能说明问题。第三重价值是职业新鲜感。FDE长期面对同一个客户的同一堆问题很容易产生职业倦怠。轮岗机制让FDE有机会接触不同行业、不同客户、不同的技术挑战这是留住人才的关键。5.2 晋升通道从现场工程师到产品专家的路径FDE的晋升通道设计核心要解决一个问题做FDE做得久了是不是只能继续做FDE如果答案是肯定的那这个岗位迟早留不住人。我看到比较健康的FDE晋升通道是双通道并行。一条是技术专家线沿着初级FDE、中级FDE、高级FDE、首席解决方案专家这条线往上走越往上越强调方案架构能力和行业深度另一条是管理线从FDE转项目管理、交付总监、区域负责人越往上越强调带团队和客户经营能力。除了纵向晋升还有横向流动。FDE这种岗位特别适合往两个方向转一是转产品经理因为FDE手里握着大量真实客户反馈做产品规划比坐在办公室的产品经理有手感得多二是转售前解决方案架构师因为FDE是极少数既能讲技术、又懂客户业务的人做售前几乎是降维打击。我在实际带团队中见到最多的晋升陷阱是把优秀的FDE提拔成糟糕的管理者。技术上很强的FDE被领导塞进了管理岗结果既不擅长带人又荒废了技术。针对这个现在很多团队的晋升制度里专门设置了继续做高难度项目这条晋升路径并不是只有带团队才算晋升。5.3 社区分享机制案例沉淀与经验复用的力量FDE模式下社区分享机制的价值怎么强调都不为过。FDE分布在不同客户现场每个人都在解决相似又不完全相同的问题。如果没有知识复用的机制公司等于在让每个FDE从零开始摸索这是巨大的组织浪费。一个成熟的FDE社区分享机制我认为至少要包含三类活动。第一类是案例复盘会形式可以是月度的内部技术分享也可以是文字版的拆解文章。复盘的关键是讲坑不讲究不能只讲成功案例更要讲走过的弯路。我印象最深的一次分享是一个同事复盘他如何在数据迁移过程中因为忽略字段编码规则导致上线后出现几万条乱码数据的经历。这个案例后来被写进了新人培训手册让至少三代FDE避免了同样的坑。第二类是解决方案模板库。每个项目结束后FDE要把可复用的部分沉淀为模板包括环境检查清单、数据迁移脚本、问题排查手册。这些资产的复用价值比培训课高得多。我自己的习惯是每次解决了奇怪的问题就把排查思路和根因写进知识库下次遇到类似问题的同事搜关键词就能找到。第三类是前线需求反哺会。社区分享不仅是FDE之间交流也要拉上产品团队一起。这种会的核心是需求分诊FDE收集的前线反馈被分类处理能排入产品路线的排入路线不能排入的要给出明确理由并反馈给当事人。做过FDE的人都知道最打击士气的事情是反馈提交上去石沉大海所以反哺会必须有闭环。社区分享机制对FDE还有一种看不见的心理价值消解孤立感。驻场工程师长期在客户现场没有同事在身边很容易产生我是来搬砖的的消极情绪。定期的社区活动让FDE感到自己是一个知识共同体的一员自己的经验在被别人使用也能用别人的经验解决问题。这种归属感对长期驻场人才的稳定性帮助巨大。6. 关于FDE模式我想泼三盆冷水FDE模式近两年热度很高课程、认证、岗位层出不穷我在这篇文章里也说了不少好话。但作为一个在这个模式里摸爬滚打过的人我想在最后分享几个反面的真实观察希望正在研究这个方向的读者看得更全面。第一盆冷水是不是所有项目都适合FDE模式。FDE模式的人力成本比传统实施高不少派一个工程师驻场半年光人力成本就是一笔大数字。标准化程度高的产品、需求简单的项目强行上FDE模式只会让客户为不需要的服务买单。判断标准很简单客户业务复杂度高、决策链长、系统需要深度定制才值得投入FDE。第二盆冷水是FDE不是万能救火员。很多公司设了FDE岗位却把项目失败的所有责任都推给FDE觉得你们在一线就该把客户搞定。但FDE能解决的是产品能力和客户需求之间的适配问题解决不了的是产品本身有致命缺陷、交付时间不切实际、客户高层根本没有数字化意愿这类结构性难题。FDE模式要发挥作用公司必须先做好产品和管理层预期管理。第三盆冷水是做FDE要有明确的成长规划否则容易越做越窄。FDE在客户现场解决的大部分是具体问题这些经验高度碎片化如果不有意识地做总结、学新知、扩边界三五年后你会发现自己的核心竞争力只是一些特定客户环境下的特定经验换一家公司就水土不服。所以文章前面讲的轮岗、分享、进阶认证不只是公司制度更应该是每个FDE个体的自我要求。哪怕公司没有成熟的机制自己也要主动创造机会离产品近一点、离行业深一点。我在给团队新人做入职培训时经常打一个比方FDE职业路径就像是传统软件行业的全栈缩影它不要求你在单个技术方向上做到最深但要求你在技术、业务、沟通这些维度上始终保持在场。行业对数字化转型的诉求越来越具体FDE模式大概率不会是一阵风它会从一种岗位演变成一种能力要求沉淀到更多工程类角色的职业素养里。对未来想往这个方向走的朋友我的建议始终是把头扎进现场去跟业务待在一起你遇到的问题越多成长的速度就越快。