我的筆記：中建電商傷了個人心？回收驗貨組後L真是用心良苦（3）

我回收驗貨的第一件事，就是叫我以文檔的形式交出我熟悉的東西。我預感到這是在叫我作交接，可是我仍以日常心對待。認真配合每一項工做：我想的是，我工做中不犯錯他沒理由辭退我。可是如今回想起來，真的是我太簡單了，從我再次回到收驗貨組就不停找各類理由針對。

就拿上面說的回來後第一件事，叫我整理我熟悉的業務。最後還給我扣上估計拖延工做的帽子。我離職前整理了一個文檔 對此時進行說明，可是他們不認賬了，具體說明參看這個連接：交接硬要扣一個故意拖延的帽子，說我不積極交出本身知道的業務  。

叫出我整理的業務後，第二件就是按照他的意思重構我以前寫的關鍵業務代碼（說白了，其實這也是在變相的交接工做，可是我也沒有絲毫怠慢和抱怨）。此次重構工做很順理，測試基本沒測試出由我致使的bug。可就在重構版本測試經過的時候,都來不及等到發佈到正式環境，他就找了個理由，不讓我寫代碼了。（由於此時我所掌握的東西都交接給他了）。接下來咱們，講哈這個不讓我寫代碼的理由，由多麼的牽強。

　　　　早上10點過，領導L告之去修改昨天他們測試出來的我從未參與過的業務邏輯的一個開發環境bug。
　　　　我便開始從源代碼分析。
　　　　早上10點40左右，領導L批評我處理bug慢，並告知直接鏈接到攝像頭調試就分析出緣由了
　　　　當時的狀況是：項目組只有一個攝像頭，且一直是被測試人員正在使用，同測試協商後，贊成中午後給我聯調使用
　　　　早上11點35，客服部反饋一項目現場同步數據失敗，

早上11點50左右，L口頭安排我去排查此問題緣由，並坐在我身旁盯着 我處理

　　　　

　　　　13點15 找出錯誤緣由並處理調異常，L在釘釘告之客服問題處理了

　　　　

　　　　此時L便去吃午餐了（我和他都沒吃午餐一直在處理這問題），我接着觀察修復後數據，確保錯誤不會再次發生（那天我未吃午餐）

　　　　14點，從測試哪裏拿到攝像頭設備，開始處理早上分配給個人那一個bug

　　　　14點40左右，領導主動問到,問題題處理好沒有，我回答：涉及的代碼和業務太多(確實設計的業務過並且牽涉核心業務邏輯)，我還在分析。此時領導再次批評處理過慢。並告知下午4點前能不能處理好，此時我已經調試大半部分代碼了，因此回答：4點確定沒問題。

　　　　15點20分，一現場問題分配給我，我停下手中工做（此時bug修改進度90%）去處理線上問題。

　　　　15點27分，L發話： 放下手上的工做，而後叫出去談話。嚴厲批評我修改這個bug工做效率低下。並中止我全部開發工做且不在讓我參與開發。

　　　　大概16點，L將此事彙報個部門領導W，W所以事約談我（間接談離職的事）

　　　　在我未寫出bug，未影響業務的狀況叫我不用寫代碼了，憑空認定我不能寫代碼：錄音

今後，L不讓我參與項目開發工做，便叫我專門去作線上技術問題支持。並告知若是這個支持工做都作很差就要走人。

第二件事：L和我溝通業務的時候，本身對業務不瞭解，我幫他糾正業務，卻發火，瞪眼，最後拍桌子走人。

背景：咱們業務後收貨和發貨。正常狀況是：收貨是先是車+貨稱重（簡成重車），而後再是卸掉貨物只稱空車（簡稱空車）也就是，同一車某次收貨通常是先稱重車後稱空車。同事若是是從工地上拉東西出去（發貨）。就是先稱空車（空車從項目外進來，而後準備拉貨），後稱重車（轉載貨物而後拉出去） 不論是收貨仍是發貨由於車子都不是屬於項目的，車子出了項目當前那次收發貨就完成了。

衝突：基於如上業務，L任務再數據庫（時間爲序存放的數據）裏面同車牌連續兩條數據，若是前一條的重量大於後一條的重量，則是收貨。反正是發貨。這個判斷確定不對，我屢次舉例給他辯證這樣判斷不行。可是他一直認爲本身的是對的，最後發火、瞪眼、罵人以致於拍桌子走人。

他認定：前一次稱重記錄重量大於後一次就必定是項目上收貨，由於咱們收貨就是先稱重車再稱空車，這樣前一次重量確定大於後一次重量。可是反過來講就不成立啊。我當時有舉例辯證：一輛車不是來收貨的，是發貨的（先空車後重車）。可是，他空車如此稱重的時候，因爲（停電了，或者司機走的其餘線路沒走地磅上過，或者軟件出錯了 等不少咱們如今有出現過的這些狀況） 最終致使這一條稱重記錄沒有記錄到咱們數據庫中。而後可是當他裝完貨物離場的時候稱重正常數據被記錄到系統。次日這輛車又被安排來發貨，當他空車進入項目後，數據庫會記錄一條空車記錄。這樣就是前一條重車 ，後一條是輕車。真實狀況是來發貨的，結果咱們軟件會把他判斷爲收貨。這樣就出錯了。

我解釋了不少，可是他已經堅持本身的是爭取的，並直接在工位上當着全部人拍桌發火走人 。

這裏是發火錄音（錄音效果差，最後摔比 而後拍桌子的聲音不明顯 可是有這個行爲的）：這裏是錄音

第三件事：不是個人錯也是個人錯。

背景：我主要負責現場端部分開發。 我把現場稱到的重量和車牌獲取到以後，調用L寫的WebAPI接口。而後L經過此接口接受到的參數，分別把重量信息和車牌號往雲端的A表和B表寫入。測試時發現錯誤A表數據寫入成功，B表數據寫入失敗。測試將此bug分配給我。

我堅持本身代碼沒有錯誤，並給測試解釋。我傳遞給L寫的接口是一份數據，他拿到這一份數據，往A表和B表都寫入車牌和重量。A表寫成功了就表示車牌和重量都我都準確的傳遞給他了。A表數據寫入，B表沒寫入，那通常是L的webApi接口內部處理錯誤。並叫他去找L確認修改。可是測試不認這個理，仍是一直叫我改我上傳時候調用的代碼。以致於我和測試爭論愈來愈就激烈。

L聽到咱們爭論後，把我叫到外面談話（測試點事沒有），批評我工做不負責，影響團隊氣氛等。我沒當面反駁（由於基於相似這樣的事，我當面越反駁個人後果越嚴重）。

後來，我屢次主動和測試用很是柔和的語氣溝通這個問題，最終他承認是webapi的緣由。而後通知L修改webapi後此bug修復。

第四件事：誇大我錯誤。我被勞務組臨走前，我明確告之過原領導D，有段邏輯處理待優化，可是若是取消調其中一個if語句會引發生產環境更多更大的錯誤。結果我被調用的勞務組期間，收驗貨發佈版本時候真的入我擔憂的那樣，取消調了我提醒的那個if判斷。結果致使線上數據修改無效。我回到收驗貨項目組後很快就收到用戶相關的投訴，我立馬分析出是以前提到的if語句引發的。可是L就是不一樣意發佈新版修復此bug。而是在我回項目組後20天左右才發佈版本把這個if語句啓動（此問題才得以修復）。當時我很明白他的目的：就是爲了要證實他接受的時候軟件有多爛，因此故意讓此bug拖延20天不修復。而修復成功就是啓用一段已經寫好的if邏輯。

第五件事。莫須有的罪名，欲加之罪何患無辭。並請此時彙報給部門老大，說我工做不積極。

2019年1月18日（臘月26），週六，放假。大約下午4點客服收到現場反饋：某項目前一天晚上因爲軟件閃退的緣由致使無人值守無法使用，從而引發多輛車排隊過磅，以致於排隊車輛都排到國道上去了。項目上但願明年咱們年後幫他解決軟件閃退的問題。由於報告此問題的時候項目上已經放春節假，磅房電腦關機，工做人員已放假。 且這事一直是客服對接處理，還沒轉到技術這邊。

   2019年1月20日，週一早上L領導對我進行嚴厲批量，說因爲我沒有及時處理問題，致使項目車輛排隊到國道上了。當時我都還不知道怎麼回事，後來我從客服qq羣聊天記錄知道這過後，再次給L領導彙報：一、項目彙報的時候是週末，我休假中沒看到羣消息，且整個交流過程我沒參與也沒收到客服的任務轉接。2項目反饋的是前一天晚上的事，在羣裏反饋的時候他們項目已經放年假停工了，磅房電腦也關機了，工人也放假了。無法遠程到現場處理。三、項目也明確提出但願咱們年後處理，並非立馬處理。

就這個緣由：L斷定我技術支持也作很差（以前他提到過，若是技術支持也作很差就要走人）。真的是：欲加之罪何患無辭！

轉自：https://www.cnblogs.com/paulxie/p/2020/03/26/12571939.html