南宁市网站建设_网站建设公司_Photoshop_seo优化

时间过得真快，又到年末了。

我感觉自己的人生，从30岁之后，仿佛按下了快进键，一转眼的功夫，就已经到了四十不惑的年龄。现在已经是奔五的人了。

2006年10月我参加 SAP 校园招聘，拿到了 SAP 实习生 Offer.

同年12月，我拒了手头上华为和腾讯的 Offer，和 SAP 签了三方协议。

当时手上还有一些其他外企的 Offer. 2006 年还是外企在中国最鼎盛的时期，也是我所在的大学同学们校园招聘求职首选的目标。中兴和华为只是我们用来做保底的备胎。

2006 年成都从火车南站往天府软件园的道路两旁，全是大片大片的荒地，房价也就一千多一点吧(现在均价已经两三万了)。那一年成都软件园一家总部位于美国的世界五百强通信企业，给应届硕士生开出的月薪是8500元。

我研究生读的是公费，每个月国家补助300块。在学校食堂早饭一个肉包子一个鸡蛋一杯豆浆总共1块多钱，午饭一个荤菜3块，素菜6毛，米饭2毛，所以300块一个月的伙食费在学校绰绰有余。

可想而知，2006年时这些成都本地的通信外企开出的薪水，对我们这些没啥钱的学生们来说具有多大的吸引力。

我自己也不知道当时为什么会在这么多家外企的 Offer 里最终选择了 SAP. 2007年1月我就去 SAP 实习了，从最基础的 ABAP 开发做起。当时只是一个懵懵懂懂的职场新人，就想着先踏踏实实干几年再说吧，也没有任何中长期的职业规划。没想到这一干就是18年，一直到现在。

这19年来我做过 SAP On-Premise 产品的开发：SAP CRM 和 SAP S/4HANA，也做过纯云的 SAP Business By Design 和 SAP Cloud for Customer 这些 SaaS 软件。用过的技术栈和工具很杂：ABAP，Java，JavaScript，TypeScript，Python，Docker，Kubernetes，也曾经北至沈阳，南抵深圳，去过国内多家 SAP 客户现场帮助他们解决产品使用上的问题。

项目级别的远程支持过的海外客户就更多了，作为 SAP Labs 的员工，我是以 Dev Angel 的角色参与到客户项目中。这个角色的职责就是全程跟随客户项目实施项目，当实施过程中遇到影响按时上线的问题和故障时，Dev Angel 要及时协调 SAP 开发部门的资源，尽早将问题解决。项目顺利上线后，Dev Angel 的工作即宣告结束。

因为我自己就是开发人员，所以在我担任这个角色的早期阶段，哪怕客户遇到的问题是一个我陌生的领域，我也喜欢挽起袖子自己动手研究，并试图给出解决方案。如果问题不能从产品层面解决，就去寻找项目层面的临时解决方案，即行业黑话"Workaround".

这样做的好处之一是自己在研究问题的过程中，对问题的细节和上下文能有非常清晰的理解,同客户那边的实施人员沟通时，就能有来有回的深入交流，避免成为一个传话筒。

弊端就是会花费更多的时间，而且有可能自己闭门造车最后找不到解决方案，回到问题原点，延误项目进程。

我担任 Dev Angel 角色支持的第一个项目是一个俄罗斯客户，客户使用 SAP ERP 和 CRM，通过中间件实现两个系统之间的数据同步。

项目实施过程中客户报给我的绝大部分问题，我接过来之后都自己“消化”了，通过我自己埋头的研究给客户提供了解决办法。有的方案可能不是最优解，但不影响客户项目上线。每天时间不够，我就加班，用增加的工作时长来提高产出。

后来我例行向我老板汇报工作时，他发现了我这个问题，提醒我 Dev Angel 是一个资源协调和调度者，而不是一个特种兵，让我不要单打独斗搞个人英雄主义，要讲究 Teamwork，利用好我身后强大的 SAP 开发部门的资源。他说，“比如关于 XXX 问题，你要是没有思路，去问问我们的 Chief Architect Carsten".

我当时听了口头应承下来，心里却不以为然，心想，“我如果能凭借自己的能力把问题搞定，干嘛还麻烦别人。来回 Communication 难道没有时间成本吗？如果我去问 Carsten，光把问题来龙去脉讲清楚都要说半天，有这功夫说不定我自己都解决了”。

那个项目从开始到结束我都没有去找过 Carsten.

后来随着工作年限的增加，我才意识到自己对待项目实施中技术问题这种“只见树木，不见森林”的方式，让我过度关注一个个问题的具体技术细节，而忽视了整个项目进展的状况，缺乏大局观。同时自己跨团队，跨部门的协同能力，沟通能力也完全没有得到锻炼。Carsten 是 SAP CRM 首席架构师，CRM One Order 的奠基者，我通过自己的固执，成功错过了和他学习的机会。

回到职业发展路线这个话题上来说，从 SAP 开发人员成长为 SAP 解决方案架构师，开发技能的修炼只是最最基础的一环，更重要的是从自己负责的某个具体功能模块的狭隘视角中跳出来，洞察整个系统的设计、组成、交互和演进，培养自己的系统化思维。

后来我逐渐意识到，如果只是满足于沉浸在客户问题技术层面的细枝末节里纠缠，而不去刻意训练自己站在一个更高的层面，从全局和整个产品层面的视角去思考问题，我就永远不可能有新的成长。

这个俄罗斯客户的支持结束之后，我再接到 Dev Angel 的任务时，就开始刻意压抑自己什么问题都想亲自动手干的冲动了。不过当时俄罗斯客户对我的工作产出倒非常满意，毕竟他们报的问题 SAP 很快就解决了，他们根本不关心到底是 SAP 哪个部门的人解决的，只要不影响项目继续就行。

我们每天和客户的项目同步会议都是用 SAP Connect 在电话里完成。我记得项目成功上线之后，我也重新回到原来的产品开发团队继续做标准开发了，有一天我的手机忽然接到一个未显示来电号码的电话。

接起来一听，原来是这个俄罗斯客户实施方的项目经理打过来的，我起初还以为项目上线后又出幺蛾子了，心里还纳闷不是说好了 Dev Angel 的支持工作到客户上线后就结束了吗？怎么出问题又找到我了，而且还是直接打我私人的手机？

后来聊了几句才明白，原来这老外说项目上线后系统运行良好，他专门打电话给我，向我三个月来的支持工作表示感谢云云。我一边道谢一边想，老外们还挺客气啊。

没想到我和这个客户的交集还没有结束。两年之后，我早已换组了，没有再做 CRM 开发了。一天我忽然又收到了来自这个客户的邮件，大意是他们项目又上2期了，实施过程中遇到了一些 Show Stopper 问题无法继续下去，点名想让我再去做项目的 Dev Angel.

我一看就囧了，当时我已经在另外一个团队做 SAP Fiori 的标准开发了。我就回邮件说，这事情我没办法做主，我先问问我老板怎么弄吧。后来经过我老板和我所在的团队协调，我暂时把手头的开发工作停下来，又继续回到这个客户项目去了。

紧接着我收到了客户发过来的一封邮件，CC 了项目组实施团队的人员和 SAP Account Executive 同事，内容是当前的项目进展情况。邮件里说，“今天我们有一个坏消息和一个好消息，坏消息是目前我们还有 X 个 Very High 的 tickets 没有关闭，好消息是，Jerry is back”。那一刻我觉得还是蛮有成就感的。

后来做了一段时间的 SAP Fiori 标准开发，我又被分配到一个做灯具照明的德国客户 Fiori 实施项目上做 Dev Angel. CRM Fiori UI + On-Premise ABAP 后台是我眼中最完美的组合之一，前台采用 Freestyle UI5 开发，这意味着强大的 Extensibility 可扩展能力。就算标准应用里提供的 extension hook 不够，客户也可以通过 controller extension 的方式，创建自己的 controller 实现，然后覆写标准 controller 实现。

而 CRM 后台，One Order 框架本身具备强大的可配置和可扩展性，各种 BAdI，再加上 ABAP 平台本身提供的 Function Enhancement 技术和 ABAP OO 的 Pre/Post Exit 能力兜底，可以说客户任何合理的后台定制化需求，都能通过增强的方式实现且保障升级安全。

事实也是这样，这个客户最后总共三十多个定制化需求，我都把需求抽象出来，在 SAP 内部系统给他们做出了原型实现，一步步的做法全部写成博客发布到 SAP Community 上了。用现在自媒体流行的术语，就是“喂饭级教程”。

虽然 CRM Fiori 前后台有着卓越的可扩展性，但这只是我个人的看法，因为我每天的日常工作就是同 Fiori 应用的源代码打交道，所以产品什么位置可以做增强，怎么做增强我很清楚。

但客户项目实施的开发人员，他们的关注点并不在产品源代码上，而 SAP 生态圈只有对增强原理的泛泛介绍，缺乏具体的图文并茂的增强步骤的材料。所以这个项目期间，我在 SAP 社区上写了大量的 Fiori 主题的博客。素材就来自项目里客户的定制化需求，做了脱敏和抽象处理。客户来一个需求之后，我就做出一个例子，写好博客，把链接发给他们。

项目成功上线之后，客户的项目经理发邮件向我表示感谢，同时还包含一个 zip 附件。附件包含了他们项目总共 8 个 Fiori 应用的定制化实现源代码，客户说感谢我在博客里提供的实现思路，这些定制开发都是参照我博客的例子进行实现的，让我把它们反馈给 SAP 产品经理，分析一下这些需求是否足够通用，可以做到标准产品里让其他客户也能用。

我当时看了就和其他同事议论，说这个客户非常 nice 啊，自己做完项目还想着能不能留下点东西造福整个生态圈。要是每个客户都这么 nice，我们的工作就好做多了。

在 SAP 这种体量的软件公司工作，开发人员参与从第一行开始编写的项目不算多。很多时候都是从其他团队开发了一部分的产品代码基础上接手过来继续迭代。我们称之为"Hand Over".

我之前曾经待过一个开发团队，从 SAP 美国某部门接手了一个 SAP CRM 中很小众的模块。有多小众？除了 SAP 官网帮助文档和 SAP 社区 wiki 之外，找不到任何关于它的资料。

我接手新产品之后都有个习惯，先把现有代码大致捋一遍。毕竟我是需要在这些代码上持续做开发，如果已有代码都看不懂，怎么在上面加新代码？当时还没有 Github Copilot 和 Cursor 这种 AI 编程工具。

于是我当时一边捋代码，一边把这个产品相关的设计和工作原理，以我自己的理解写成博客，发布在 SAP 社区上。当时写了一个系列，纯粹就是为接下来自己即将动手开始写新代码的工作进行预热。写完之后我也觉得自己差不多可以开始接开发任务了，写好的博客有没有人看，有没有人点赞我也没去关心。

过了大概一年多，我收到一封邮件，一个瑞典的客户说他们在用 SAP 这个模块，但是使用过程中遇到一些问题，在 SAP 社区上看到了我的系列文章，认为我是这个模块的专家，想请我去给他们做一个该模块的 Workshop 并解答一些项目上遇到的疑问。

邮件里让我动心的一句话是，客户承担我来回的飞机和住宿费用。后来我找老板评估了一下，结果是这个支持的 case 背后的 scenario 可能很复杂，我很可能 handle 不下来，最后没去成。但这也让我意识到，即便是我认为话题很小众，写出来没什么人看的文章，说不定有一天真的能帮助到地球某个角落的某个人，只是我自己根本没意识到。

从那以后，我就继续坚持着技术写作，一直到现在。并且开始使用中文在国内的社区上写作。

这让我认识了很多其他部门，其他团队，其他城市和国家的 SAP 同事，也让我跳出了我所负责产品的那一小块一亩三分地，结识到了 Labs 之外很多 SAP 生态圈的从业者和客户，比如现在正在阅读这篇文章的各位。曾经的我坐井观天，认为 SAP 这三个字母就意味着自己手头做的那一点点小功能，现在想起来，当时的自己简直浅薄得可笑。

回顾过去，虽然已经工作了 18 年，尽管每一年工作的内容和开发的 SAP 产品不尽相同，但工作的方式，除了去客户现场出差之外，每天也就是在家和公司之间两点一线。这种单调的生活方式，一下子就过去了18年，想到这里真的觉得可怕。

这18年来我到底有什么产出？好像什么也没有。SAP 一个个成功的产品，我虽然也参与其中，贡献了一小部分源代码，但说到底我只不过是这部庞大的代码生产机器上一颗微不足道的螺丝钉。

还好我从2021年开始，将自己这几年来所学进行系统归纳和整理，形成了下面这些技术开发教程。看到它们才让我稍稍觉得心安，算是我这些年积累下来的一些数字资产吧。

• 零基础快速学习 ABAP
• ABAP CDS View 开发教程：从入门到精通
• 一套适合 SAP UI5 开发人员循序渐进的学习教程
• SAP Fiori Elements 从入门到进阶
• 30天入门 SAP BTP 开发
• SAP OData 开发实战教程 - 从入门到提高
  

2026年如果业余时间有空，我想继续整理 HANA，CDS，SAP BTP(CPI) 和 AI 方面的教程。这些并不是笔者建议的2026年技术趋势，纯粹是出于个人爱好，想在这些领域进一步学习。

我仍然坚信，目前自己厚积薄发的这些技术和业务知识，总有一天能派上大用场。

路虽远，行则将至。