這周接了一個定製化的開發任務,讓我長了不少教訓.
本來預估的1人天的事情結果搞了差不過3天才勉強弄完.
這個事情讓我不得不反思自己的工作方式和能力.
根據以往經驗,正常來說一個定製化的告警郵件發送插件功能一天就能做完並附帶調通,最多不超過兩天。但是這次這個客戶的對接開發工作給了我一次紮紮實實的教訓.
首先第一天,同意進行定製開發的流程剛審批完,銷售竟然就說客戶當天就想要.這個情況是比較少見的,雖然我對於內部人員溝通時都預估的1人天的工作量,但這絕對不是說從開始開發到交付只需要一天的時間,也就是說這個時間進度上,銷售是有理解偏差的.我當天跟銷售反饋說,做不到當天就完成交付,他卻說客戶很急,我說既然客戶這麼急那應該早幾天就跟我說本次的定製化開發大概率會實施,並且客戶很急,那樣我就會提前進入開發中,然後銷售竟然又把鍋扔給我的一個上級,說他早就跟我領導說過這事了.我對此只能無言以對.
客戶爲上,我只能儘量加急開發,因爲我的經驗告訴我,一天時間應該能搞定,可是沒曾想,由於客戶給的文檔裏沒有提到接口有權限認證,並且這個認證方式需要用到客戶的sdk,而這個sdk也是之前客戶給的文檔裏沒有提到的,所以我一開始的代碼寫的就偏差比較大,所以第一天沒能完成.
然後第二天,客戶補充了認證的方式,我幾乎是重新開發,結果開發完後調試時又發現客戶給的文檔還是有不完整的地方,中途反覆改過代碼不下兩次,然後接口通了,我的接口調用能收到響應結果爲成功了,但是最重要的一點,郵件沒收到,這種情況就需要客戶那邊定位問題了,但由於時間已經很晚了,客戶沒有回覆,於是第二天也沒能完成.
第三天,客戶給出最後一個文檔沒有的細節補充,然後終於能收到郵件了,但是竟然還是有一些問題,郵件內容存在中文亂碼情況,根據我這邊服務打印的日誌裏記錄的報文,是能正常顯示出接口調用發送的數據是正常的,並且很詭異的是,兩個字段我都是完全一樣的處理方式,可結果是一個字段亂碼而另一個字段正常,這不得不讓我懷疑是客戶給的sdk的問題或者是客戶那邊的服務器的處理邏輯問題,同時,客戶取出我日誌裏記錄的報文去調用同樣的報文卻能收到正常的郵件,這便又是一個無法解釋的現象,似乎問題是我這邊代碼的問題,之後我反覆排查也沒能定位到原因是哪個環節的,百思不得其解.
最後,客戶那邊傳來消息,說他們自己又通過什麼其他方式搞定了,可以收到正常的郵件了.並且這個消息還是銷售告訴我的,在我和客戶所在的羣裏,客戶根本沒說這事.這就太讓我好奇了,我不禁要想是否是客戶定位到了是他們的問題,不願意直說,因爲這麼短的時間內,他們不可能單獨開發一整套的邏輯去完成這個事,最可能的情況是他們基於我推送的數據做了簡單的發送處理,或者乾脆就是修復了他們服務器的一個可能導致亂碼的bug.
最後銷售也只是淡淡給我留言說,"我剛和客戶溝通了，目前能收到郵件，亂碼的問題他們也會去查原因。辛苦了".
這就是本次事件整個的經過.過程中我也是壓力山大,因爲銷售從一開始就在對我傳達客戶很急的意思,並表示客戶一直在催他,甚至罵人.
現在來看,還好最後這個事情算是完成了,因爲客戶那邊領導層的目的達成了,完成了對他們各個生產數據庫的監控報警.否則我現在不要說在這裏寫文章總結,可能因爲這個事情影響到績效甚至更嚴重的後果都有可能.
所以,無論這個事情過程中誰是誰非,誰的責任更大,我都應該吸取教訓,一定不能再讓這樣的事情再次發生.
1.預估工作量時需要更謹慎和仔細些,確認清楚客戶的對接開發是否需要用到指定的sdk.
2.瞭解客戶想要完成的deadline,一次都不能忘記,我唯一忘記的這次就給我埋了坑.
3.對銷售說工作量時,要強調實際的完成時間和工作量之前的區別,避免誤解,因爲他不知道我手上的其他工作的緊急程度.
4.跟客戶強調一定要提前通知我開發,給出足夠的緩衝.這樣我才能做到讓問題提前暴露出來.
總的來說,定製化對接開發工作由於大部分客戶都無法提供測試環境,一個接口又可能涉及到兩三個系統間的交互,問題定位鏈條較長,並且聯調又是和客戶的開發人員進行的遠程協作,這就造成了各種預想不到的情況很多,且溝通效率很低,整體進度不容易把控,我需要儘可能提前預研和發現問題,以求在客戶計劃的deadline之前完成交付.