一、項目簡介
零售改造項目是個長週期的一個項目，第一個上線版本計劃完成需1年時間；內部開發測試，使用迭代式開發。
二、項目過程
2.1、項目前
項目動員，必須的。而後，項目組員分工、人員安排、總體計劃等一一落實到位。
2.1.1、需求調研
具體是，項目前期，需求各區域調用階段，需求人員奔赴各地的同時；蒐集上來的人員已經開始根據實際情況，分優先級排期實現。當時，也曾擔心；爲什麼這個階段沒有安排技術人員去客戶現場，便於做系統需求分析及後續設計？這就牽涉到，具體的業務系統的數據模型設計的問題。不清楚這個擔心是否多餘。但從項目收尾總體看，領導對業務的把握非常準確，每個階段產出什麼，什麼時間開始某個需求的調研，什麼時間開始安排測試，等等。
2.2、開發測試
2.2.1、產品需求
根據產品需求文檔或是wiki，開發人員直接對接需求人員，每一小組總能有具體的需求負責人，這個負責人承接調研的需求，並彙總安排優先級並負責講解需求。有時，這個人員也會直接出差到各地蒐集實際業務情況，並在內部與領導、業務熟手一起討論，只有經過這些過濾下的需求，才形成開發人員面對的需求。
2.2.2、開發
開發，建模；開發，遇到一些共性問題，比如系統間數據同步，異步處理等需架構團隊提供支撐。說到這裏，也有個問題。就是項目開發之前，這些業務系統已經分的非常明確，將一個零售系統分解成幾個業務系統，每個業務系統各司其職。問題是，爲什麼這樣分？這牽涉到架構系統分解，也許這直接出自領導們以往的系統經驗，來自業務主體域。所以架構團隊實際上對業務總體上需要來自上層業務架構的指導。後續一些非主體業務系統，更多的來自系統建設性的分析設計，比如，服務化的處理、異步處理、緩存使用、公共組件服務的開發等等。這需要技術架構的支撐，並且在個別場景上需要較爲高度的抽象能力模型設計，特別是對多依賴，高併發這類公共的基礎設施。
2.2.3、測試
前期，測試團隊也挺困惑的。因爲這也牽涉到非常深的業務知識，並且一個業務的驗證可能跨越多個子系統。
首先，前期開發階段，測試人員是沒有參與進來，所以安排測試也只是一個非常簡單的基礎驗證，比如，能不能點擊，響應；頁面是不是展現的完整。後續，越來越多的功能疊加進來，也慢慢感覺這個時候，需要調整一下，測試人員也必須和開發、產品對接。不是開發完畢了，產品人員再回頭過來和測試人員講解相關需求。這樣定會拉長整個開發週期。
後續調整中，測試人員加大業務知識的學習與培訓，並在後續開發中直接參與與開發人員的需求討論會議。
同時，還有一個過程，在於開發提交的測試，測試部署問題統一化問題，這裏面牽涉到部署工具、代碼集成測試、相關規範制定需要架構團隊支撐。
2.3、預生產驗證
培訓，再測試階段已經開發通過和使用方溝通，講解業務處理流程。同時講解完畢，即在預生產環境驗證。及時反饋相關問題，持續改進。整個團隊進入快速響應期。對開發、測試、產品都是一個不小的挑戰。一方面需要爲下一個版本疊加進新需求，一個方面需要爲上一個版反饋過得問題持續改進。
培訓，這個粘性人需要對我們目前的系統有較好的把握，同時對使用方的實際場景熟悉。以便處理其中的一些使用習慣差異，以及不同架構、流程實現下的區別。主導業務產品走向。
這個階段，需要償還我們欠下的哪些組織債務呢？
1、培訓是否到位，是否前期打過預防針。對我們使用方實際場景，前期調研形成的需求是否與場景相一致。
2、我們的核心流程處理，使用方是否理解。交付一個強大但使用方難以理解使用的產品，是否是一個必須。
2.3、交付生產
完事具備，只欠上線。
鑑於運維團隊與開發團隊是隔離的，上線時的各種技術債務都在這個階段提現的淋漓盡致。
1、配置是否正確。
2、安裝文檔是否表述清晰。
3、系統架構文檔是否完備。
這還是在上線遭遇的安裝配置。上線後，驗證，測試，開發人員基本驗證功能。後續運行中的債務慢慢在後續優化來償還。