最近因爲疫情原因一直在家，已經有快半年沒有更新博客了，最近返回公司上班之後，去年做的項目已經完結，雖然已成功交付用戶使用，但是在我看來這仍然是失敗項目，在這裏我想回顧這些經歷，算是給後面的自己一個警醒吧
爲何說這是一個失敗的項目
我一直認爲這是一個失敗的項目，原因有如下幾點：
- 項目爲能如期交付，原定計劃是在2月份交付併發行1.0穩定版，但是由於種種原因推遲到了6月1號，延期了快半年
- 項目到後期難以維護，在後期代碼複雜度上升了不止一個層次，給維護與擴展帶來了不小的麻煩
- 項目質量無法達到預期效果，在發佈之時仍有部分隱藏bug，沒有經過細緻的測試，爲了按時交付，很多測試工作都省略了，目前只進行了兩輪測試。
- 功能有些無法達到預期效果，當初爲了趕進度很多不重要的功能也是能省則省，有些需求並沒有很好的實現
項目中存在的一些問題
- 前期需求設計不合理：早期立項的時候，我參考了許多類似的產品、與相關同事進行過探討，但是由於經驗不足，沒有相關產品的開發與使用經驗，導致許多需求設計不太合理，後續變更需求頻繁，甚至出現過回爐重造的情況，這個主要責任在我這邊，當時很多需求是我自己一拍腦門想起來覺得這樣做可能符合客戶需要，但是沒有跟其他人進行商量，導致在後續實施時要麼是在此基礎上無法實施，或者成爲雞肋功能影響後續工作。
- 後續需求變更頻繁：後續需求變更頻繁，很多時候老闆看過項目之後覺得哪塊不好會直接提出來，比如某些功能不合理，某些地方配色，頁面佈局不合理之類的。測試人員會在測試實際使用中告知他們想要某個功能，以便更方便的使用與測試。但是這些變更往往是在後期開發已經完成，正式進入測試流程中時提出，給後續開發與維護造成很多不必要的麻煩。這種情況的主要問題在於老闆與測試人員在早期需求制定時參與過少，以及我本身對這方面不夠專業。導致出現後期瘋狂修改需求的情況
- 需求記錄不及時：在前期需求設計時我會詳細記錄需求的相關內容與演示效果，但是後續開發任務緊張，需求變更頻繁，無法有充足的時間進行需求變更的記錄，很多時候都是老闆或者測試人員口述，然後由開發人員進行修改，沒有合理的需求評審，沒有詳細的記錄，有時候時間一長自己都給忘了當初是如何制定的。後續無法覆盤
- 架構設計問題：還是由於自己當初經驗不足，當時考慮到用戶可能需要二次開發，所以規定當時所有的功能都採用restful-API的形式，並且前端採用純粹的ajax請求直接調用後臺接口，但是有些功能確實不太適合做成接口，而且對於前端大家都不瞭解的情況下沒有使用常用的前端界面框架，而純粹採用自己編寫的方式造成大量的時間浪費與遺留無法解決的bug。這些都給項目造成了不小的麻煩；
- 沒有詳細設計：當初項目留給前期設計的時間並不充足，按照一般軟件功能的流程來說，重要的時間應該留給前期設計，編碼與測試只佔極少數部分，而在這個項目進行過程中，完全顛倒過來了，不到一個月完成前期的需求與詳細設計以及開發測試的分工，和接近3個月的開發與測試。導致的結果就是代碼臃腫，很多公共功能沒有抽象爲具體的函數，重複代碼過多，代碼結構混亂無法進行後續維護。也就是說我們項目一開始就早就出了一個屎山。
- 分工不合理：在前期設計與開發環境框架制定完成之後，進入到分工環節，在這個環節中出現分工不夠合理的問題。主要體現在我自己不清楚員工的能力與擅長的部分，在制定計劃時採用平均分配的方式沒有考慮需求難度與員工自身的能力相結合。導致後續能力強的員工快速完成任務而存在空閒時間，而能力一般的往往會拖慢進度，或者對於困難需求實現的也是差強人意。或者出現能力強的員工去幫助能力一般的員工完成剩餘需求，出現能者多勞但是無法多得的情況。
- 測試與驗收問題：在早期設計階段並沒有完整的測試計劃，測試一直推遲到開發完成之後，在那個時候發現想要詳細測試時間不夠、測試出來的bug由於設計等原因難以修改、甚至出現某些地方使用不太合理又要新加需求的情況，這些都導致無限期的加班與代碼修改，代碼越改越亂，人心煩躁，開發與測試怨聲載道。
後續該如何改進
- 培養自己的產品思維：早期需求制定的不合理，我自身有很大的原因，我由於本職工作是做開發的，很多時候在設計需求時採用的是開發者的思維方式，而沒有站在用戶角度，設計出來的系統在後續測試中會發現很難用，沒有合理的引導，功能過於分散，常用功能操作不夠簡單，操作步驟過多等情況時有發生，爲了用戶必須得改需求。我想自己得加強這方面的素養，設計完成之後少改需求
- 制定規範的需求管理制度：在需求制定、變更、實現、驗收這些過程，在項目中沒有與很好的得到解決和管理，造成很多需求後續無法查證，不合理的需求無法定位到具體的責任人，甚至誰都可以提需求。爲了解決需求相關的問題，需要引入規範的需求管理制度，加入需求評審等操作，讓需求更合理，更有跡可循。
- 延長早期設計時間：在大學中學習軟件工程相關課程時，我的老師告訴我，在項目開發中，編碼只佔很少一部分，而現在似乎反過來了，編碼佔據了時間的大頭，而前期設計只是爲了給開發人員安排工作而已。我想一個成功的項目應該是會在前期設計過程中下了很大的功夫的。可以在前期多進行相關會議，比如需求評審、針對需求進行測試用例的評審、開發框架與相關方案的評審、以及工作計劃的合理安排等等。
- 規範開發中的代碼審查機制：員工的能力，與代碼編寫風格對項目的可維護性有巨大的影響，過去我一直覺得開發人員應該保留自己的個性，編寫能體現能力的牛X的代碼，但是經過幾次與他人合作、帶領團隊開發項目之後，我改變了這個看法，作爲底層的碼農，爲了項目的統一於可維護性，最好還是安心做一顆螺絲釘，多人合作不需要個性，一切爲了項目纔是正道。所以在後續如果還有項目需要我帶隊開發，我會統一編碼格式與註釋格式，像大廠那樣制定編碼規範，甚至細微到如何給變量、函數、類命名等等。最好每天下班前一次 code review，及時消除冗餘代碼、不規範的代碼、不合理的功能，特別是同一個功能，多個人編寫函數，函數的參數列表與實現完全不同的情況。
- 測試與開發並行的機制：之前測試永遠是等到所有開發任務完成之後進行，一旦項目完結，進入維護節點，要修改bug是相當困難，而且是牽一髮而動全身的，測試應該與開發並行，在需求評審時應該做到給出需求驗收標準與對應的測試用例，而且需要配合代碼審查，提醒開發人員針對每一個功能函數編寫單元測試。需求完成之後立即對照測試用例進行測試，保證每個需求都準確無誤。
- 更加合理的工作安排：合理安排工作，需要做到針對員工的能力和需求評審時得出的需求的難度來合理安排，合理安排包括合理的時間、合理的人員與合理的需求安排等等。這個可能沒有相應的參考標準，只能根據經驗來判斷了。
- 自己應該更加投入到這個項目中：由於我在公司待的時間較長，對公司業務比較熟悉，所以很多時候總有人會來問問題、商量某些事，我一貫又是一個老好人的態度，甚至有時候做到事無鉅細都親自動手。甚至公司主要產品也需要我來進行維護，而且由於項目人手不夠，我也參與到項目的具體開發與測試工作之中，導致長時間都消耗在無意義的事情之上，無法專注於項目管理工作上。在後面項目需要做需求變更、更改開發計劃時無法及時記錄與評審；看到不合理的代碼沒有時間做code review、提取公共部分，重構部分代碼，這些工作都由於沒有時間而暫時擱置了。在後面項目越發的超出我的掌控。
以上就是之前帶隊開發時出現的問題以及一些反思，如果後面還有機會作爲項目的leader，我想盡量避免這些情況。更加專注於項目。制定相關制度，保證項目質量。