1、需求理解要透徹

需求關乎專案要做什麼，要達到什麼樣的結果，對公司開展業務有什麼樣的幫助等，需要在需求階段理解清楚，做到心中有數。另外需求是工作量評估的基礎，要想工作量評估適當且充分，不出現大幅度偏差，就需要客觀理解需求。

2、工作量評估做到群策群力

我們會把整體計劃拆分成細小的功能點，然後按照技術人員的特點，分配到具體的開發負責人。由於很多功能點都是互相關聯，單方面評估往往不能反應真實的情況，因此我們會召集專門的評估會議，對某一個功能點由對應的開發負責人和相關的人員一起來確定，確保大家的資訊對稱。

3、任務分工角色要配置齊全

美的金融的專案從需求到上線部署，甚至生產環境有時開發人員也要參與。這就需要開發人員不僅要會編寫程式碼，還需要具備專案生命週期中一整套解決方案。我們在專案中設定了DBA、運維、程式碼質量控制、進度控制，測試技術五大基本角色，都是普通開發兼任，每一種角色會研究自身領域的知識，同時由於自身負責開發，理解更具體，做出來的東西更符合專案本身的需要。

一來開發人員自身得到了提高，很多成了技術多面手，在專案中收穫更大的成就感；二來提升專案組整體解決問題的能力，降低了專案的風險，遇到問題不必等、靠、要其他部門的太多幫助，降低溝通成本。

4、程式碼質量控制擺到重中之重

良好的程式碼質量需要工程師付出很多的努力，這些努力都是值得的，為後期維護、BUG診斷、擴充套件等降低了難度。我們組織了大範圍的程式碼評審，小範圍的程式碼檢查，利用sonarqube做程式碼掃描，力爭做到對劣質程式碼零容忍，同時也兼顧開發進度。

5、保持對外介面更友好一直在路上

外部業務系統對接是發揮系統本身價值的根本，因此我們一致強調要保持友好，更友好，包括Dubbo異常處理、統一錯誤碼、統一錯誤資訊、統一的許可鑑權、統一的返回資訊格式等，力爭做到外部系統對接不用考慮太多，降低接入的難度。

6、單元測試要完全覆蓋

開發人員做單元測試，一是檢查自己的程式碼是否有缺陷，做到對自己程式碼負責；二是可以站在測試的角度去思考問題，可以減少後期測試不必要的測試點，讓專案進度整體可控。因此我們要求開發人員要單元測試全部覆蓋，並按照標準輸出單元測試報告，並由具體的負責人推進。據測算，30%左右的bug可以在單元測試階段檢查出來，並且這些bug大多是比較低階的。

7、保持開發人員的積極性

工作總是人做出來的，開發人員的工作積極性是專案好壞的決定性因素。做好專案，先必須讓團隊氛圍良好。讓每一人都具備主人翁意識，都可以有自己發展的空間，在自己的領域裡有所建樹，在專案中找到存在感，讓開發人員變得更優秀，滿足大家提升自我的本真需要。

8、重視結果

過程很重要，是因為它關乎結果，結果才是做專案的目的。所以專案要重視結果，如期完成上線不僅是公司期望的，也是團隊每個人成就感的重要組成部分，它是繼續保持高昂情緒，繼續保持打勝仗信心的關鍵；相反專案出現延誤，一拖再拖，給開發人員造成極大的挫敗感，造成情緒低落。由於專案中經常出現一些不可預知的問題，對專案進度造成延遲，因此我們在開發工程中，高度重視專案進度，儘量做到功能點提前完成，以預留出一些不可控因素對專案可能造成的延遲。

收尾

專案開發過程中往往是曲折往復的，需要我們的耐心和決心。按時完成一個專案，不管大小，都代表了一種做成事情的能力，比專案本身更重要，它讓我們對未來做成更多事充滿了信心。