項目管理之道之團隊共享，把不願寫文檔的程式員趕出你的團隊

　　最近碰到一個很狗血的事情，也讓我頗為抑郁了一番。經我手開發的一個銀聯卡支付項目，系統運維階段集中爆發了一些問題。雖然最終都得到了解決，但是反思問題的出現及深層次的原因，對于項目管理的技巧和團隊規則的建立有了更深層此的感觸。暴發出來的問題主要包括以下幾個：

1.本行卡境外交易失敗。

2.本行卡境外交易部分國家失敗：有的國家成功，有的國家失敗。

3.境外卡行内交易失敗。

4.他代本交易，非規範封包資料庫表插入出現錯誤。

5.預授權交易處理失敗。

　　由于該項目是一個移植項目，大部分源程式來源于公司另外的一個項目，按照XX以及XXXX的說法，配置上就能用，說的好是輕松，就好像3天就可以上線，五天就可以完活似得。而我也竟然放松了警惕，輕信了這些說法，結果可想而知。

第一、項目沒有文檔：扔過來一個檔案包，包括代碼、定制、資料庫表一團。這就是所有，你自己看吧，鬼知道我該拿這些東東做個球用啊。對比，用對工具對比，自己去找差異，看來我真有病，誰有藥呢？

第二、變更沒有說明：

　　核心變了，沒有記錄；前置變了，也沒有記錄。處理到使用者認證和預授權類交易時，悲劇了，核心傳回的錯誤碼，不符合銀聯的規範，每次封包送上去，都會被拒。沒辦法，拿着銀聯規範一個個核對，最後發現核心使用的錯誤碼時2.0版本，驗證規則是2.0版本。拿着規則找核心的人去理論，核心不敢改，告訴我：XX地就是這麼處理的，這裡也該這麼處理，肯定沒問題。我的親娘四舅奶奶，到底是業務決定設計還是經驗決定設計呢。沒轍啊，糾結啊。後來找所謂的XX地要了最新版本，才發現，對方早已經變更過了，而我們還不知道。更悲劇的事情還要，不過我不能說。耶稣啊。誰來拯救你呢！

第三、Bug沒有記錄

　　前人種樹,後人乘涼。Bug管理系統的核心價值就在于此，可惜悲劇的是，前人種樹，種完了又挖走了，就留下一個樹坑，我還要從頭開始種。上述本行卡境外交易失敗的原因就在于缺少了一個國别代碼域，悲催啊。境内交易一切OK，境外交易，直接Over。對比啊，測試啊，終于找到問題所在，使用者臉也開始綠了。

第四、未經測試即釋出

　　未經測試的程式，直接釋出，你敢嗎？不管你敢不敢，反正我是不敢，可是不敢的我卻這麼做了。然後，挂了，然後再來。不是哥不想測試，是沒環境，沒有加密機，很狗血的一個理由吧，我感覺也是，别告訴我用仿真，别告訴我繞過去，可能是我真的很笨。強勢的使用者，無理的要求，被踐踏的流程。見過膽子肥的，沒見過這麼肥的。耶稣啊，你先在坑裡呆着吧！

本文版權歸作者所有，歡迎轉載，但未經作者同意必須保留此段聲明，且在文章頁面明顯位置給出原文連接配接，否則保留追究法律責任的權利。