什麼樣的系統算是坑——後傳
自從《什麼樣的系統算是坑》公眾號文章發布之後，很多人留言問我接下來會怎麼處理，表示會持續關注。
現在一年過去了，也許是應該好好說一下了。
艱難時刻
沒錯，剛接手的時候，是真的很艱難。這套系統是真的很坑，不僅用戶操作繁瑣，而且系統功能和數據出錯率極高，運行速度很慢。曾經用JMeter做過壓測，20個用戶登錄的登錄響應差不多要85秒，查詢一個畫面響應時間要5分鐘以上。
系統裡面到處是程式碼寫死，稍微有一點業務變動或者Bug修復就要做大量的程式修改，而且還只能得讓供方來做。比如新增一個庫位程式碼，ERP這邊是分分鐘的事情，在這套系統上面就要前後改一個月。那個時候我最怕的是用戶提Bug修改和新增需求，因為任何的改動都需要供方來做，沒有兩個月是搞不定。
接手之後我花了半個月的時間，召集用戶部門關鍵用戶梳理了幾版業務需求和Bug清單，形成文檔跟業務領導和供方確認。但確認之後的系統改動進展緩慢，四個月之後才交付新版本發布，也只是修改了2個需求而已。
後來一直在催促供方加快開發進度，期間系統也陸陸續續出現過不少的低級錯誤，如人為配置錯誤導致測試數據對接到其他系統的生產機了，跟供方交涉，但他們死豬不怕開水燙，一臉滿不在乎，甚至回復：出現這種情況在所難免，建議甲方把其他系統的網路屏蔽掉，這樣可以杜絕類似的事情發生。
被我回懟了之後，供方公司的項目總監和PM從此沒再理我，也幾乎不在交流的群和郵件里吭聲，無論我如何嗷嗷叫，如何要求他們，甚至譏諷責罵他們都是無動於衷。碰到問題只讓唯一一個留在甲方的支援人員打打醬油。
後來系統又發布了一版，驚訝得發現供方私自拿我們的測試系統當小白鼠，雖然有修復部分Bug，但在上面還修改了好多底層架構，加了不少的功能，而這些功能在我們看來是不需要的東西，反而增加了用戶的工作量。一開始供方答應用戶上線初期會幫忙維護數據，但到後來這部分工作都落在用戶的頭上了，用戶和IT是被折騰得沒脾氣，大家都敢怒不敢言，默默承受著。
所以接手之後很長的時間裡，對這套系統的運維和開發，甲方的參與度很低，干預的程度很有限。供方有恃無恐，對甲方的項目不緊不慢，需求也滿不在乎，也妄想像血蛭持續趴在甲方的身體上貪婪地吸著血，期望著有三期四期的運維！
也許你會說幹嘛不在項目款項上扣款甚至不付款，這個方法我當然想過，可如果供方從此撂攤子不幹，萬一出了問題，業務玩不轉，個別業務領導會很恐慌！
逆風翻盤
最後實在看不下去了，還是我們IT大領導有魄力和遠見卓識，果斷決策內部在其他平台自行開發一套新系統。我拿到這柄「尚方寶劍」之後，開始著手系統替換的工作。
其實原來系統的功能很簡單，在現成的開發平台上，我們只花了3-4個月的時間就開發完成了，並召集用戶進行三輪大量的測試。前後只有一個開發人員，開發費用差不多是之前那套系統開發費用的十五份之一。
用戶知道我們開發了一套新系統，天下苦秦久矣，都非常的期待，測試配合度非常高。
此外我們還添加了非常多的功能，極大簡化了用戶的操作，物料主數據原來需要人工錄入數據的工作現在都是系統對接大中台商品中心了，上線的時候再把舊系統的數據全部遷移過來，詬病已久的SAP系統入庫數統計功能經過完善也都準確無比。
上線之後，除了部分物料數據有問題之外，就是一些系統UI和操作上的小改動，幾乎當場就能解決，上線僅2天之後系統就非常穩定了，可以說上線是非常成功的。
從此那套滿是坑的系統就這樣被我們扇到歷史垃圾里去了。
角色互換
供方自知自己水平差，項目做成這個樣子，要款變得很困難，再加上我比較強勢，更別提什麼之前規劃的三期四期的項目了，所以他們就把唯一駐留甲方的人員撤走了，開始提驗收付款的工作。
當然，這個時候有恃無恐的已經變成是我們了。
因為他們合約裡面一些需求沒有辦法完成，而我也是要求他們按合約規定款項來做驗收付款，不然就扣款。中間也是來來回回扯了很久，驗收過程經常哭著喊著嗷嗷叫。當然，這個時候著急的反而是他們了。
所以還是那句話：不要作，遲早會作到自己身上！
