最近因為疫情原因一直在家，已經有快半年沒有更新部落格了，最近返回公司上班之後，去年做的專案已經完結，雖然已成功交付使用者使用，但是在我看來這仍然是失敗專案，在這裡我想回顧這些經歷，算是給後面的自己乙個警醒吧
我一直認為這是乙個失敗的專案，原因有如下幾點：
專案為能如期交付，原定計畫是在2月份交付並發行1.0穩定版，但是由於種種原因推遲到了6月1號，延期了快半年
專案到後期難以維護，在後期**複雜度上公升了不止乙個層次，給維護與擴充套件帶來了不小的麻煩
專案質量無法達到預期效果，在發布之時仍有部分隱藏bug，沒有經過細緻的測試，為了按時交付，很多測試工作都省略了，目前只進行了兩輪測試。
功能有些無法達到預期效果，當初為了趕進度很多不重要的功能也是能省則省，有些需求並沒有很好的實現
前期需求設計不合理：早期立項的時候，我參考了許多類似的產品、與相關同事進行過**，但是由於經驗不足，沒有相關產品的開發與使用經驗，導致許多需求設計不太合理，後續變更需求頻繁，甚至出現過回爐重造的情況，這個主要責任在我這邊，當時很多需求是我自己一拍腦門想起來覺得這樣做可能符合客戶需要，但是沒有跟其他人進行商量，導致在後續實施時要麼是在此基礎上無法實施，或者成為雞肋功能影響後續工作。
後續需求變更頻繁：後續需求變更頻繁，很多時候老闆看過專案之後覺得哪塊不好會直接提出來，比如某些功能不合理，某些地方配色，頁面布局不合理之類的。測試人員會在測試實際使用中告知他們想要某個功能，以便更方便的使用與測試。但是這些變更往往是在後期開發已經完成，正式進入測試流程中時提出，給後續開發與維護造成很多不必要的麻煩。這種情況的主要問題在於老闆與測試人員在早期需求制定時參與過少，以及我本身對這方面不夠專業。導致出現後期瘋狂修改需求的情況
架構設計問題：還是由於自己當初經驗不足，當時考慮到使用者可能需要二次開發，所以規定當時所有的功能都採用restful-api的形式，並且前端採用純粹的ajax請求直接呼叫後台介面，但是有些功能確實不太適合做成介面，而且對於前端大家都不了解的情況下沒有使用常用的前端介面框架，而純粹採用自己編寫的方式造成大量的時間浪費與遺留無法解決的bug。這些都給專案造成了不小的麻煩；
沒有詳細設計：當初專案留給前期設計的時間並不充足，按照一般軟體功能的流程來說，重要的時間應該留給前期設計，編碼與測試只佔極少數部分，而在這個專案進行過程中，完全顛倒過來了，不到乙個月完成前期的需求與詳細設計以及開發測試的分工，和接近3個月的開發與測試。導致的結果就是**臃腫，很多公共功能沒有抽象為具體的函式，重複**過多，**結構混亂無法進行後續維護。也就是說我們專案一開始就早就出了乙個屎山。
分工不合理：在前期設計與開發環境框架制定完成之後，進入到分工環節，在這個環節**現分工不夠合理的問題。主要體現在我自己不清楚員工的能力與擅長的部分，在制定計畫時採用平均分配的方式沒有考慮需求難度與員工自身的能力相結合。導致後續能力強的員工快速完成任務而存在空閒時間，而能力一般的往往會拖慢進度，或者對於困難需求實現的也是差強人意。或者出現能力強的員工去幫助能力一般的員工完成剩餘需求，出現能者多勞但是無法多得的情況。
測試與驗收問題：在早期設計階段並沒有完整的測試計畫，測試一直推遲到開發完成之後，在那個時候發現想要詳細測試時間不夠、測試出來的bug由於設計等原因難以修改、甚至出現某些地方使用不太合理又要新加需求的情況，這些都導致無限期的加班與**修改，**越改越亂，人心煩躁，開發與測試怨聲載道。
培養自己的產品思維：早期需求制定的不合理，我自身有很大的原因，我由於本職工作是做開發的，很多時候在設計需求時採用的是開發者的思維方式，而沒有站在使用者角度，設計出來的系統在後續測試中會發現很難用，沒有合理的引導，功能過於分散，常用功能操作不夠簡單，操作步驟過多等情況時有發生，為了使用者必須得改需求。我想自己得加強這方面的素養，設計完成之後少改需求
制定規範的需求管理制度：在需求制定、變更、實現、驗收這些過程，在專案中沒有與很好的得到解決和管理，造成很多需求後續無法查證，不合理的需求無法定位到具體的責任人，甚至誰都可以提需求。為了解決需求相關的問題，需要引入規範的需求管理制度，加入需求評審等操作，讓需求更合理，更有跡可循。
規範開發中的**審查機制：員工的能力，與**編寫風格對專案的可維護性有巨大的影響，過去我一直覺得開發人員應該保留自己的個性，編寫能體現能力的牛x的**，但是經過幾次與他人合作、帶領團隊開發專案之後，我改變了這個看法，作為底層的碼農，為了專案的統一於可維護性，最好還是安心做一顆螺絲釘，多人合作不需要個性，一切為了專案才是正道。所以在後續如果還有專案需要我帶隊開發，我會統一編碼格式與注釋格式，像大廠那樣制定編碼規範，甚至細微到如何給變數、函式、類命名等等。最好每天下班前一次 code review，及時消除冗餘**、不規範的**、不合理的功能，特別是同乙個功能，多個人編寫函式，函式的引數列表與實現完全不同的情況。
測試與開發並行的機制：之前測試永遠是等到所有開發任務完成之後進行，一旦專案完結，進入維護節點，要修改bug是相當困難，而且是牽一髮而動全身的，測試應該與開發並行，在需求評審時應該做到給出需求驗收標準與對應的測試用例，而且需要配合**審查，提醒開發人員針對每乙個功能函式編寫單元測試。需求完成之後立即對照測試用例進行測試，保證每個需求都準確無誤。
更加合理的工作安排：合理安排工作，需要做到針對員工的能力和需求評審時得出的需求的難度來合理安排，合理安排包括合理的時間、合理的人員與合理的需求安排等等。這個可能沒有相應的參考標準，只能根據經驗來判斷了。
自己應該更加投入到這個專案中：由於我在公司待的時間較長，對公司業務比較熟悉，所以很多時候總有人會來問問題、商量某些事，我一貫又是乙個老好人的態度，甚至有時候做到事無鉅細都親自動手。甚至公司主要產品也需要我來進行維護，而且由於專案人手不夠，我也參與到專案的具體開發與測試工作之中，導致長時間都消耗在無意義的事情之上，無法專注於專案管理工作上。在後面專案需要做需求變更、更改開發計畫時無法及時記錄與評審；看到不合理的**沒有時間做code review、提取公共部分，重構部分**，這些工作都由於沒有時間而暫時擱置了。在後面專案越發的超出我的掌控。
以上就是之前帶隊開發時出現的問題以及一些反思，如果後面還有機會作為專案的leader，我想盡量避免這些情況。更加專注於專案。制定相關制度，保證專案質量。
記一次失敗的面試經歷
背景 面試者 王某 以下簡稱我 嵌入式行業剛入門 10年工作經歷 從事方向為 gps bd導航，物聯網，車聯網方向 面試官 前華為員工 3年工作經驗，現為1 創業公司嵌入式部門leader，公司已獲得風投注資500w rmb，產品方向為物聯網和小眾市場產品。面試地點 陝西某眾創空間 職位 高階嵌入式...
記一次失敗的買房經歷
最近在買房，一提到房子，中國人民都感興趣 來蘇州工作快一年了，正好限購也結束了，最近一兩個月一直在看房 看了好多二手房，心真的叫乙個累啊 要麼價錢不怎們合適 要麼位置比較偏 要麼比較老舊 你可以想象乙個姑娘騎著電瓶車週末兩天都去看房 那真叫乙個累啊 看了房子多了，就慢慢知道房價區域的 就慢慢知道中介...
記一次失敗的刷資料經歷
最近因業務需求需要重新整理線上的資料，遇到幾個問題。原本想著線上的資料量也沒有多少，在取資料的時候就沒有分批次取，將所有的資料拿出來，在mysql將所有的資料給php之後，因為php設定的記憶體最大容量有限，所以記憶體直接溢位了。因為是對原有的資料表進行操作，所以需要將原來的表備份，以便出了問題還原...