最近一直在想自己在專案中的一些得失，在每乙個專案結束都要問自己一下：這個專案中自己獲得哪些成長，下次是不是可以做到更好。長期的專案過程往往會讓人陷入一種思維的定式：好像每個專案的工作都一樣，這樣很容易進入一種比較消極的狀態，會忘記自己曾經給自己設定的目標。以前看過這樣乙個問題：什麼才算得上有效經驗？有些人做了三年其實只有一年的經驗，因為後面基本上是前面的copy。這也是為什麼有人說乙個人的成長在於前面三五年，後面很有可能會遇到天花板。當遇到天花板的時候能不能突破是乙個關鍵。下面講乙個整個專案中需要做什麼。我會在介紹整個流程的同時插入自己的一些想法和思考。更重要的是思考，思考是人的精髓所在。
專案流程
1. 需求階段
這是專案的最初的階段，這個階段主要需要明確這個專案要做什麼？目標是什麼？一般來講這個過程是產品經理去做，這個階段的醞釀時間往往比較長。因為乙個專案最開始可能只是乙個idea，對於整個目標可能他自己也沒想好，甚至是不可行的，需要進行一段時間的溝通和釐清才會逐漸形成乙個真正的需求。另外對於產品經理而言是以業務結果為導向，可能會提出一些從技術角度不合實際的想法。這個時候就需要專案經理和產品經理進行溝通，乙個是明確具體要做什麼，另外乙個是可行性（引入成本收益原則，就是完成這樣一件事情的成本是多少？收益是多少？是不是值得？就應了那句話：一切皆平衡）。當這兩個目標達成一致才可能往後面去做。如果興沖沖的往前走，往往會適得其反。所謂「磨刀不誤砍柴工」。
2. 概要設計文件
明確整個需求後開始要做的就是啟動專案。確定專案經理、架構師、開發人員、測試人員、前端等各種資源都需要到位。架構師需要產出概要設計文件（可能比較多的專案這個文件是由專案經理產出），並對整個專案的時間有乙個評估，確定整個專案的重要時間節點。整個專案流程中幾個重要的節點的時間都需要敲定，並對其規模需要比較仔細的評估。另外整個專案風險在**，都需要做到盡量的列舉，以往的專案經驗在這個過程中就會起到非常重要的作用。
3. 詳細設計文件
在概要設計後需要對這個整個專案進行分解，這時候可能並不是架構師來設計，很有可能是每個開發工程師進行分模組設計，資料庫表結構、介面、快取等一系列和此專案相關的東西，然後在做乙個合併，這種方式對於開發來講會有比較多的成長。如果整個設計過程只是專案經理或者架構師參與，而開發工程師只是參與編碼工作，這樣的乙個流程對於開發工程師的成長而言就會非常有限。
專案文件的詳細程度會根據整個專案的規模來判斷，大專案和小專案在流程上會有一些差異，小專案可能就不需要繁文縟節的專案流程和文件，這樣可以加快整個專案的程序。大專案整個流程和文件是不可或缺和非常重要的。如果說小專案可以靠個人進行保證，那麼大的專案更多的依賴於流程和管理。所以專案的流程並非一層不變，完全可以根據專案的規模在實際應用中採取靈活變通的方式。在大的流程框架下做一些優化和變通對於實際應用中是非常有好處的。引用中國那句很有名的話：「不管黑貓白貓，抓到老鼠就是好貓」。可能有些公司會非常強調流程的重要性，我覺得整個流程不能太死板，對於網際網路行業來講，最重要的是應對變化和把握時機。流程是為了保證產品的質量，而不要為了流程而流程。
專案經驗分享
這是我經歷的第二個專案，這個專案相對於第乙個專案dzpay相對較簡單，介紹 第乙個專案名稱 dzpay。大宗商品交易，類似某寶 這次主要總結我測試billbank的一些個人經歷 測試第一要義就是要詳讀產品需求，產品需求中有哪些模組，每個模組中又有哪些子模組，每個模組以及子模組對應的需求點都要搞清楚。...
專案經驗分享
color cyan dh師兄的經驗分享 color color olive 就在公司工作的經驗，針對shopxx專案的交流。color color darkblue 1.乙個專案，要先分出模組來。不要把所有功能都寫在乙個模組裡。如果這樣的話，專案會變得非常臃腫，模組間的耦合性太強，維護起來很困難。...
專案經驗分享
自 這篇文章裡說的內容，其實都是老生常談，但是裡面有一點我覺得非常有道理，在做完乙個專案之後，我通常想的是，這個專案中有哪些不足，而不是 怎樣把這個專案做的更好 兩者看上去沒什麼區別，其實有很大區別，因為出發點不同。凡事都應該是目標導向，你所做的一切，都應該是為了實現你的目標。下面是正文 最近一直在...