在“總結複盤（上）”文章裡，針對項目的階段1進行較為詳細的複盤，本文主要針對項目的階段2：項目開發階段前期。
三、項目開發階段前期回顧
1、過程回顧
可以分為幾個階段：
階段1，開發籌備，時間在6月到8月中旬。
這一部分主要有兩條線，一條是組建内部開發團隊，整理開發規範，進行開發技術選型等，另一條是配合老大确認某業務外包開發團隊。
内部開發團隊組建還算順利，團隊在Java上的積累較多，順利任命了組長，他也很有心氣願意全情投入，前端因人員變動太大，隻能找了個入職一年不到的新手，他自己有些猶豫但被我們說服，用戶端工作因為不多，選了個主管牽頭，但可以到項目後續再進來。
麻煩的是外部開發團隊的确認，一開始客戶有一個意向團隊，前期商務溝通已經感覺不太舒服，覺得對方内部有分歧，即老大和銷售有想法，但實際的産品和項目負責人有些猶豫。客戶組織過一兩次技術和項目方面的交流，在電話會議中我已經覺得不對，因為方案讨論中有些明顯的技術常識缺陷對方卻借甲方的說法進行掰扯。
最後，經過老大跟客戶負責人的幾次來回往複，最後還是選了老大找的合作夥伴的外包團隊，我參與了前期溝通，也跟老大表達了我的看法，在行業經驗上，這隻隊伍會比客戶找的那家少，是以在産品上估計需要我們多投入，在技術開發上，因為本期架構設計調整較大，是以别指望可以利舊多少原有産品。
确定了外包團隊後，又經曆了一次變化，第一家過來的項目經理和産品經理到了現場後，結果是我們跟客戶都不滿意，尤其是産品方面，客戶直接發飙，結果隻能把合作夥伴老大叫到現場，老大和我們也都過去，重新梳理需求并表态後，然後又換了一家外包團隊。這時，都已經快到8月中旬了。
跟外包的技術團隊一起，趕緊确認各端的技術棧，後端以我們為主，前端我們本來就不太強，我做了一個前期很糾結痛苦的決定，讓外包方為主搭建整個前端的技術架構，選擇了他們更加熟悉的Vue3+vite+ts技術棧。在階段1、2過程中，内部團隊的2個前端壓力很大，需要邊熟悉邊幹活，因為之前的項目都用的是vue2，還好最後挺過來了，對進度和品質影響不大。
階段2，基礎平台開發與文檔驗收，時間在8月中下旬到10月上旬。
從這個階段開始，開發進度就逐漸受到客戶需求确認及文檔驗收工作的影響，加上外包團隊的産品一直不夠給力，是以開發計劃無法保障，出來後過不了客戶的功能驗收，整體的技術把控相當吃力，技術還不是核心問題，但因為産品一直被質疑，客戶情緒非常差。
之前的項目計劃是在9月底出一個原型功能驗證版本，結果從9月開始，因為家裡上司開始了一直延續到年底的封閉教育訓練，我就無法出差去現場，這對我的項目把控是很大的挑戰，這讓我的短闆更加放大，即我會更加傾向于面對面的交流，通過電話和微信的交流總覺得差些意思。在這樣的情形下，産品的需求遲遲無法定版，加上客戶臨時在9月中旬增加了階段性文檔驗收的工作，甚至優先級很高，是以在帶着一些破罐子破摔的想法，投入了核心文檔撰寫的工作，把技術開發的把控工作放在了第二位。
帶來的結果就是，階段性文檔工作順利完成，基本都沒有讓核心開發人員投入過多精力，但是軟體版本就無法按期傳遞了，或者說打包出來的版本基本無法示範。
雖然客戶并沒有對開發團隊施加太大的壓力，因為他也知道目前的主要問題在産品，以及文檔驗收工作的精力牽扯，但從整體來看，項目進度繼續延期，而且明顯達不到年底上線，春節正式割接的目标了。
階段3，應用開發與階段驗收，時間在10月中旬到12月中下旬。
雖然階段2并沒有100%完成，但跟項目經理協商後，我們還是進入了下一個版本疊代，将業務應用開發、APP開發等工作也納入進來。随着戰線更加拉長，我越來越感覺力不從心，一個是客戶現場的開發人員越來越多，遠端協調和解決問題的效率不高，另一個客戶并沒有按照我們的節奏，還在跟産品慢慢摳細節，而需求無法快速确認、階段性版本範圍始終無法封閉，之前答應其他合作夥伴要啟動的另一個項目隻能持續延期，是以我開始安排逐漸退出。
先是跟現場的副總溝通，讓他更多地開始把控項目的各類技術工作，我逐漸後撤，更多關注在另一個很重要但相對外部溝通較少的任務——一二期主要業務資料割接，以及投入到項目的部署、割接方案等通用管理性工作上。
2、個人複盤
（1）問題教訓
- 各端技術細節了解不夠，在進行技術棧選擇時，發現從系統整體架構落實到具體的子產品開發、具體的流程銜接、核心技術細節實作時，發現自己對各端的技術原理掌握有很多欠缺，不管是Spring架構系列的功能開發流程、Vue開發過程、重要功能或性能的實作方案等，能夠知道大概，可以參與讨論并且決策，但如果到了指出方向和優化方案時就會比較吃力，隻能是邊學邊做。
後續優化措施：按照Vue前端、Spring的順序進行學習，了解其基礎原理，并按照實際項目開發過程進行過程标準化，各形成1~2篇文章作為成果展示，7月底前。
- 電商産品體系不了解，因為前期在營運商領域相關業務方面積累更多一些，對于電商領域涉獵很少，也沒有主動去了解過，是以首先想到的就是eTOM的重産品模型，而不是基于SKU的電商産品模型，還好把這部分内容放在最後開發階段，是以問題暫時沒那麼明顯。
後續優化措施：通過學習、實踐對基于SKU的電商産品模型了解并掌握，與eTOM的營運商産品模型進行對比，形成一篇文章作為成果展示，時間，7月10日前。
- 非現場把控能力不足，如上文所說，因為家庭原因無法去現場進行把控，導緻項目技術部分逐漸失控，展現了自己在非面對面交流把控方面有很多問題，一方面是本來項目技術把控過程并沒有形成自己的套路，另一方面在發現問題時的處理不夠主動積極，雖然有一定的客觀因素影響，但主要還是自己有放棄的傾向存在。
後續優化措施：通過整理項目技術把控過程的套路先解決第一個問題，即從一個完整的前端、後端、APP或小程式端的項目入手，整理技術負責人把控的規範化控制項及實施指南，形成1~2篇文章作為成果展示，8月底前。
- 與産品協同推進不足，在産品推進不夠有力的情況下，雖然也跟老大、副總回報過多次，但還是站在技術負責人的位置上，旁觀的多，共同推動幾乎沒有，而其實在産品上我也能有一些發言權，如果參與進去不說一定能加速或改善很多，但至少對于團隊來說，是真正的“all in”，真解決不了也是大家能力不足，否則至少我心中還是遺憾和自責的。
後續優化措施：暫時沒有進一步的具體措施，需要在觀念上進行調整，在後續的工作中一定要勇于跳出自己的工作範圍。
- 與客戶溝通引導不足，因為沒有在現場出現，是以客戶負責人也很少單獨找我，更願意找現場的副總或項目經理，這就導緻了跟客戶的親密度、信任度一直不高。客戶的應對政策完全沒錯，這裡的問題主要在自己，因為沒有去現場，就偷懶了，不願意主動跟客戶交流，隻有在大會上等必要的場合才進行互動。
後續優化措施：暫時沒有進一步的具體措施，需要在觀念上進行調整，在後續的工作中一定要跟對口的客戶銜接人員保持良好的溝通。
（2）經驗積累
- 前端技術棧選擇，如上所述，雖然對前端的技術棧了解不夠深入，但在第一個階段，發現内部的前端負責人兩天沒有按自己承諾的時間搭建好開發環境，剛好跟外包開發團隊溝通，他對我們的前端技術棧不熟悉。于是我決定讓他來搭建前端技術架構，用他們最熟悉的技術棧，讓内部團隊邊幹邊學。現在回顧，這個決定是正确的，因為最後外包團隊的工作量最大，如果用他們不熟悉的技術架構，估計項目時間還要更長，品質可能還要更差。
- 項目知識管理，項目還未正式啟動，我就已經在語雀上建立了專門的團隊知識庫，将需求、設計逐漸上傳，并且通過語雀進行版本管理，并在上面進行各類開發規範的撰寫、讨論、修改、定稿等，現在項目上線後，基本上所有的核心成果文檔以及過程文檔都很好地儲存下來，後續開發、測試、維護團隊的人員變化後，新人能夠快速、體系化地學習了解，相信這也是公司文檔最齊全、最優質的一個項目了，算是給公司留下的小小一筆财富了！
3、公司複盤
（1）問題教訓
- 項目積累轉化不足，公司之前項目做了不少，但文檔确實不多，留存最多的文檔是客戶要求的驗收文檔，但資深人士都知道，驗收材料的目的更多在于通過驗收而不是在于真實記錄項目過程或成果，參考意義有，但不大。而最多的文檔就是接口文檔，其實就是使用類似Swagger等自動化文檔技術生成的，幾乎隻需很少的整理工作。但實際上，項目最需要的設計文檔、尤其是設計過程文檔很少，或者說就是沒有。
後續優化措施：可參照語雀的項目知識庫，根據項目的規模進行适當增減，核心是公司上司或技術負責人有知識積累的意識，輔助一定的檢查機制，随着項目的實施，知識積累自然就有了。
- 管理層信任度不足，在項目過程中，因為産品工作老大和副總均參與了，客戶及内部原來都希望老大能親自上陣，因為覺得他的産品化思路最完整、全面，也有深度。但最後他還是不願意躬身入局，讓副總帶隊上。但過程中，雙方配合一般，在外包團隊的産品沒有達到要求時，大家更多的是抱怨而不是協同，加上我也置身事外，是以我們幾個人對項目的延期以及客戶的不滿都有不可推卸的責任。當然，這可能也是我後來選擇另行找人合作的原因之一吧。
後續優化措施：暫無，需要管理層各自覺察，提升個人認知，才能解決。