1. 項目進度被一拖再拖，原定2018年春節前完成一期功能的上線並完成相關實驗局的部署，但目前已經4月份一期功能還未完全完成。

2. 項目質量問題很多。該項目分為前端和後端平臺兩套系統，這兩套系統的協同工作出現很多問題，直至現在，一些基本的功能還老出問題。

3. 項目管理流程混亂，一個問題出現經常找不到幹系人，沒有統一的協調和控制，解決問題的效率很低。

對該項目出現的問題做了一些反思，分別從項目管理和軟件質量管理的角度做了一些分析。

從項目管理的角度，我覺得問題出在這些地方：

1. 項目管理中相關幹系人的識別上出現了問題，該項目涉及的開發團隊和產品很多，但相關產品的責任人並不明確，所以出現問題了不知道找誰的問題經常出現。

2. 項目經理對於項目進展的控制沒有很好地執行PDCA的過程，在軟件團隊開發過程中，沒有定期的監控、反饋和溝通，使得不同團隊的協作一開始就非常生澀。

3. 對項目風險識別不夠深入，該項目中前段團隊開發的是基於Android的APP，但使用的是第三方的開源SDK，而且涉及領域也是完全陌生的領域。根據經驗，這種軟件的開發應預留更多的時間，並預估更多的風險，並在初期應加大投入，但前端團隊在前期基本沒有投入，後期匆匆上馬，導致軟件質量問題很多。

4. 項目計劃時間不合理，違背了軟件開發的基本規律，前期開發時間留的比較長，但前後端團隊聯調的時間很短，就更不提測試所預留的時間了。

5. 前後端開發團隊的開發方式存在問題，前後端開發團隊在開發過程中沒有開發模擬工具，而是前端等後端，後端等前端，都開發完畢再聯調。這樣即使一個團隊先開發完成，也就幹等著，其實完全可以先通過模擬工具進行測試。這樣最後導致在有限的聯調時間裏完全無法完成基本功能的聯調。

在軟件質量方面，開發團隊也存在一些問題，尤其是前端團隊，從頻頻出現的軟件故障可以推斷軟件的測試一定存在問題。其實這也是目前公司大多數軟件開發團隊都存在的問題：重開發，輕測試，沒有專門的QA對軟件做質量的監管和統計，團隊對於質量管理的執行力普遍很弱。

回想以前在ZTE工作的日子，那時對於質量的控制大抵有下面幾個方面的措施：

1. 每個產品、項目有專門的QA和故障接口人（主要負責外部故障）。QA負責產品項目的軟件代碼質量檢測和監督，定期提醒項目經理相關問題。

2. 軟件團隊強化質量意識，在開發時使用靜態檢查工具、單元測試、集成測試、自動化測試等提升軟件質量。由於質量與考核掛鉤，因此團隊中對於質量問題的執行力都非常強。

3. 在產品線內設立質量總工的職位統一對各產品項目的質量進行管理，並定期出產品線的質量周報進行公示與通報。（當年帶團隊開發時，最怕的就是質量總工的電話，因為他打電話一般都沒好事。）

雖然覺得以前工作中質量管理也不盡完善，但如果把這些措施實施在現有團隊，強化團隊的質量意識，我想產品質量也會有一個飛躍。

回到這個項目，根據目前項目的情況，首要問題是要需要把項目計劃好好梳理一下了，將項目中出現的質量問題按緊急度和重要性的象限重新劃分，確立明確的幹系人，盡快解決問題，重新制定裏程碑，以保證項目的順利進行。

軟件團隊的質量管理執行力的提升是一個長期的過程，這個只能從公司的管理制度著手逐步改善了。

反思一個軟件項目執行中的問題