我与SAP成 都研究院吴院长的二三事

这几天Jerry没怎么看手机，今天才注意到，昨天SAP中国研究院公众号上发布了一篇文章：SAP高管说: 体验经济时代下的SAP客户体验。仔细一看，这不是咱SAP成 都研究院的吴院长么。

在今年没有发生部门架构变化的很长一段时间里，吴院长都是Jerry的直接领导，因此本文想和大家聊一聊吴院长的另外一面。在SAP中国研究院的文章里，有一个视频，大家可以从中获取吴院长(也是吴博士，好像是火箭飞行器制造专业的博士学位)对于SAP客户体验的洞见，而从Jerry本文讲述的几件事情里，大家能体会到吴院长是如何关心员工成长的。这些事情都是在Jerry工作中发生的真实场景，出于保密目的，有些隐私细节略去。

事件1：2017年3月的时候，Jerry还有1个月的时间就要去德国出长达3个月的差了，但很多事情还没有落实，而且迟迟没有进展，让Jerry很是烦心。没有进展的原因出在Jerry自身：当时我认为很多准备工作，不应该由我来做。当时我内心坚持认为，作为程序员，在三个月出差这件事情上，我只需要在技术层面做好准备，过去之后可以立即和德国同事对接，然后开工就行了。至于其他的事情，自有公司专门部门的同事去操心。

后来3月的一天晚上，已经很晚了，Jerry收到了正在上海出差的吴院长一封邮件。Jerry收到邮件后第一件事是看了下发送时间(后来才知道吴院长是白天忙完工作后晚上回到酒店写的这封邮件)，然后把邮件正文粘贴到word里一看，2000多个words. 当时我的内心是几乎崩溃的。

邮件里吴院长对我当时一段时间的行为进行了分析和敲打，一条条阐述Jerry看了之后表示心服口服。后来吴院长出差回来后又当面和Jerry就这件事情继续聊过，我领悟到的一点就是：在SAP哪怕只是开发岗位，也绝对不意味着只需要埋头专研技术，写好代码就足够了。是否具有business acumen，是区分一个专业的应用软件开发人员，和一个纯粹的码农的标志之一。

事件2：很快2017年4月Jerry就出差去了德国，过起了三个月快乐的单身汉生活。2017年7月7日，回国前的最后一个工作日，Jerry在工作上犯了一个不应该犯的错误，当时我还没意识到。德国时间下午2点，Jerry收到来自吴院长一封措辞严厉的邮件，陈述了Jerry所犯的错误，并且在邮件结尾用了几句以感叹号和问号结尾的句子来向Jerry发问。当时我的内心是几乎崩溃的。

后来我马上用Skype向吴院长发起电话连接，在这个持续了一个多小时的越洋电话里，我首先向吴院长解释了我自己心中设想的做了这件事情后会给团队带来的正向价值；吴院长在肯定了我说的这一点后，接着问了我一个问题：有没有想过是否存在对团队的负向影响？当时我压根就没有意识到会存在负向影响的可能性。吴院长又问了我几个问题：假设在我做了这件事情后，团队有同事会XXXX，那么我们该怎么办？我答不出来。吴院长这时才给我分析了这件事情可能会给团队造成的负向影响，对这些分析我很是服气。

从这件事的教训我悟出一个道理：真实的工作场景远非程序员喜欢的二进制世界那么单纯，非0即1，非false即true. 真实的工作场景远比这复杂得多，我们在职场上的很多行为，可能都不是像我们单纯想象的那样，只有纯粹的正向或者负向意义。如果我们真的那么认为，可能只是一厢情愿罢了。做事果断，有自己的判断力固然是好事，但这不意味着在做一件事情之前不用去从全局和整体的角度去考虑它可能带来的影响。程序员因为工作性质，比其他岗位更容易陷入看待任何事物都使用非黑即白的眼光，因此更需要刻意去避免这种职业病。格局，或许也是区分职场菜鸟和职场老鸟的标志之一。

当时Jerry向吴院长发起Skype连接时，已经是国内周五晚上的下班时间了，吴院长正在开车。接到Skype后，吴院长靠边停车，然后和Jerry进行了上述一个小时的沟通，让我非常感激。

事件3：2017年7月Jerry结束了出差，回到成 都研究院，8月就加入到一个协助客户上线的项目中去。当时客户在实施项目过程中遇到一些棘手的问题，需要SAP和partners合作将其解决。当时Jerry分到了几个优先级最高的难题，这不是Jerry第一次处理这种任务，我已经形成了自己认为行之有效的处理这类技术难题的套路。所以我按照自己的节奏来，一边读系统后台源代码，一边在公司wiki上查资料，想通过自己的力量将其搞定。2周过去了，那几个难题解决了一些，但有一个直接影响客户能否顺利上线的问题始终进展不大。

那一两个月工作非常紧张，吴院长和我们几个相关同事每天下班后都会在微信上就白天的工作内容继续讨论。从和吴院长在微信上的交谈中，Jerry感觉到了他对我进展不大的不满。吴院长微信上问我一个问题：假设我最后发现这个问题无法通过成 都本地同事的努力解决，那该怎么办？Jerry又一次没答上来。当时我的注意力，全放在如何把相关代码吃透，把相关文档看懂，如果在这之后还是不能解决问题怎么办？后果很可怕，但我当时没去想。

Customer First(客户第一)这个口号，在Jerry这次实际的客户支持项目中，一度变成了Research First，研究第一，陷在代码海洋和技术细节里。吴院长提醒我现在工作的首要重心是保证客户成功上线，而不是用产品开发的思维去按部就班做技术研究；我们是一个跨国公司，遇到难题不应该单打独斗，应及时向相关的德国同事求助；多条腿走路，提早制定plan B等等。

还好这个问题最后在Boris和Dean两位同事的大力帮助下，勉强找到了一个解决方案。最后客户也如期成功上线，算是有了一个好的结局。

事件3是否意味着当客户遇到紧急的问题必须立即处理掉，我们就可以采取非常规手段呢？还是拿实际例子说明。

2014年，Jerry担任国外一个CRM客户项目的dev angel，遇到一个使用中间件进行主数据同步的性能问题，当时同步一次主数据需要三天才能完成。因为这个客户也有很多定制化开发的代码，所以处理起来也很棘手。

Jerry花了大量时间把相关代码全部看了一遍，最后得出结论：只要修改属于software component AP-MD-PRO 下面的一个函数，就能解决这个性能问题。然而问题的关键是，这个component不是成  都团队负责的，我们不能直接修改其他团队的代码。当时Jerry极力向吴院长推荐自己这个方案，我的原话是“我有99.99999%的把握，这个函数按照我说的修改之后，就能解决客户的问题”。吴院长反问我，“这段待修改的代码是其他团队负责，如果有0.00001%的可能性发生，我们修改之后，会引出其他新问题，那这个责任谁来背？” 这个问题我也无法回答。

事后Jerry反思过，当时自己的建议确实非常欠考虑。Jerry建议修改的函数所在的component AP-MD-PRO，除了被SAP CRM使用之外，还用于一些SAP其他产品。就算Jerry是CRM专家，能保证修改了那个函数之后，能够解决CRM的问题，但谁又能100%保证这个改动不会影响到使用到该函数的其他SAP产品呢？CRM部门没有人有资格能做出这个保证。

这个例子让Jerry懂得，在任何情况下，100% functional correctness都是必须满足的底线，没有任何借口去绕过。就算是紧急的客户问题处理 ，也要在符合公司开发流程和规范的前提下进行。像Jerry在案例里提出的“直接修改其他团队代码”的做法，真的非常不专业。

通过这三个案例的分享，不知道SAP成 都研究院的吴院长在大家心目中是一个什么样的形象？欢迎留言告诉大家。

要获取更多Jerry的原创文章，请关注公众号"汪子熙":