我與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的原創文章，請關注公衆號"汪子熙":