解決建議：

（1） 各模組的開發負責人在進行模組設計和程式碼編寫的時候，主動和與該模組相關的其它模組負責人交流、討論介面互動規則和存在的疑問。我們的開發目前對自己的模組都很清楚和負責，也非常配合問題追蹤以及修改問題，如果大家在此基礎上多點主動與互動，產品的開發效率和質量就會更高了。

（2） 在各模組單元測試完成後，由專案負責人或測試負責人協調搭建專案聯調環境，協助各模組進行聯調測試。

（3） 在正式測試前一天，由專案負責人或測試負責人檢查聯調環境，確認系統基本功能已經實現，也就是說程式碼提交測試時確保專案是可work的。

解決建議：

（1） 專案啟動前由專案經理和專案負責人一起根據工作量及專案需求確定開發計劃，各模組負責人樹立起提交程式碼的deadline的時間觀念，在deadline前提交經過單元測試和聯調的程式碼，並提交該模組的安裝文件、功能說明文件和錯誤程式碼說明文件。

（2） 對於因為其他工作不能如期提交的模組，提前通知專案經理和測試負責人。同時，專案負責人或測試負責人及時跟進專案進度，協助各模組負責人解決存在問題以及提供必要的資源。

解決建議：

（1） 模組負責人在設計和程式碼實現的時候，建議使用閘道器小組目前的規範，一方面，可以充分利用前輩們留下的資源；另一方面，一個團隊中，每個人都有自己的特色，如果大家都不遵循規則，那一個產品的程式碼和設計風格就五花八門了，不利於以後的維護和產品的整理架構。

（2） 在專案啟動前，由專案負責人或測試負責人制定相關規範，大家討論認為合理後遵循該規範進行設計和編碼。

解決建議：

（1） 開發在修改bug的時候，通盤考慮與該bug相關聯的情況，避免因為修改bug而引進其它問題，確保程式碼修改質量。

（2） 開發修改bug 之後，在聯調環境進行單元測試或聯調測試，初步驗證該問題已經解決再提交程式碼。

解決建議：

（1） 測試負責人在需求階段開始跟進專案，瞭解專案需求、設計思想和業務流程，在測試前對負責該產品測試的其他測試人員進行業務培訓。同時測試相關人員也認真閱讀相關需求和規範文件，主動與開發確認業務處理細節。

（2） 測試前組織一次產品介紹，由專案經理對產品的主要功能和設計思想進行介紹，同時由模組負責人對該模組實現的功能和設計思想進行介紹，聽取大家的建議後對模組進行改進。

（3） 在測試前進行一次開發與測試之間的face to face業務培訓，由各模組負責人講解該模組業務處理流程、某業務流程觸發的條件及結果、該模組所使用的配置檔案，測試與開發對業務流程進行face to face的交流和討論。在交流之前，測試人員先閱讀相關文件，對業務有一個初步的認識。（4） 開發在提交程式碼的同時，提交一份功能說明文件和單元測試或聯調測試案例說明文件。

解決建議：

（1） 在開發完成設計後，由專案負責人和測試負責人對設計文件進行稽核，記錄不合理的設計或疑問，反饋給模組負責人。

（2） 開發在完成設計後對設計進行介紹，專案負責人、測試負責人或其它相關人員對設計不合理的地方提出修改建議，並對存在歧義的問題進行討論。

解決建議：

（1） 對於小的問題可以簡單做記錄然後擱置處理。

（2） 對於原則性的問題，組織一次face to face討論，通過良性的free talking對問題的解決達成一個共識。對於不能達成共識的問題，由專案經理或少數服從多數的原則確定解決方案。在大家意見存在嚴重分歧的情況下，的確需要有一個角色對問題進行衡量之後做最後的定奪，否則這個討論就得不到更好的解決，繼續討論也比較浪費時間。

解決建議：

（1） 需求或規範存在疑問時，及時提出並與專案相關人員討論，對於未能解決的疑問由專案負責人或測試負責人統一收集，向需求人員或工程人員一一確認。

（2） 使用配置項靈活實現模糊的需求或規範。