9月30日的中午12點30分，本來還在專案管理的課堂學習。得知本月還有10多筆應收業務拋財務系統有問題。向公司領導請假後，我和一名技術人員趕回了公司。這個系統在什麼樣的背景下誕生的？建設中面臨了哪些困難？
從業務、管理角度來看，這個系統建設難度比較大。系統要支援6個角色，pc、app、小程式等幾乎全終端覆蓋。系統本身也是一個複雜的業務系統，除了與內部多個上下游業務系統對接以外，還要與三方開放的資料平臺及監管部門系統對接。公司目前資訊化要求也比較高，業務系統要與稅務系統和財務系統對接。所以，從業務和管理角度來看，系統建設難度可想而知。
從專案建設角度，開發、系統管理、專案管理都有一定難度。公司選擇了把專案外包給一家公司，作為內部技術團隊的我們在中後期逐步介入專案。雖這家公司在大行業有一定經驗，但在我們細分領域的經驗不足。技術選擇了springcloud全家桶，linux部署。在系統開發、日常管理上相比傳統技術有了更高的要求。前後端完全分離，而公司開發資源又是矩陣式的管理方式，在開發計劃上面需耗費不少精力。因此，專案建設難度可見一斑。
從公司高層角度來看，高層領導對貫徹先進管理思想期盼已久。我們所做的是一個傳統的業務領域，利潤率極低。整個社會都在期盼著通過技術創新或者模式創新來增加競爭力、提高盈利水平。而傳統行業變革是既需要大環境的孵化，也需要一個長期嘗試、滲透感染的過程。高層領導迫切的希望與業務管理實際之間的差距，是系統建設不得不面對的鴻溝。
由於各種原因（這裡不詳述），外包方交付的品質不太好，需要一個較長的使用者驗證期。專案前後5個月分別上線了業務和結算板塊。今天是結算上線25天的日子，也是第一次月底的考驗。通過月底的考驗，也暴露出了業務方和我們技術團隊的一些不足。業務方對高層領導的迫切期望理解不足，系統主人翁感不夠強烈，日常業務的及時性、正確性管理還有提升的空間等等。技術團隊對專案建設難度判斷不太準確，對使用者驗證深入度組織不夠，對公司內部資源矩陣管理風險認識不足等等。
這個專案總體來說，還是得到了公司各級領導的關心，業務人員、結算人員、財務人員的配合。技術人員當然也算是加班加點，我也睡了幾次辦公室，勉強填補了外包方交付品質不好的坑。第一個月的考驗在磕磕碰碰中勉強通過，後續還有一些亟待改進的點。想想去年國慶，我從公司另外一個團隊到現在的團隊。想做好事情的心指引領著我，壓著牙、耐著性子，和團隊一起終於向上線成功邁進了一大步。至此，兩個團隊的核心主系統我也都算主力成員了。
不會吹牛，就笨鳥先飛。去很多崗位深度體驗，去跟車、爬螺紋鋼堆子、找鋼卷、操作剪下加工線、下加工單、開出庫計劃單、蹲門崗、幫承運商對賬、辦理結算、開發票、為來賓講解。原來做的這一切是今天專案管理培訓學到的一個詞語「人種學研究」方法。這次培訓讓我知道了理論的重要性，不繼續學習理論，就缺少了很多除實踐以外的方法論。高時間成本的投入，是靠多少個夜晚加班換回的，失去了很多陪伴家人的機會。當然，深入崗位，也讓我得到了許多大宗倉儲物流行業的知識。
在這個雙節之際，祝各位朋友節日快樂！