**自：
這篇文章裡說的內容，其實都是老生常談，但是裡面有一點我覺得非常有道理，在做完乙個專案之後，我通常想的是，這個專案中有哪些不足，而不是——「怎樣把這個專案做的更好」，兩者看上去沒什麼區別，其實有很大區別，因為出發點不同。
凡事都應該是目標導向，你所做的一切，都應該是為了實現你的目標。
下面是正文：
最近一直在想自己在專案中的一些得失，在每乙個專案結束都要問自己一下：這個專案中自己獲得哪些成長，下次是不是可以做到更好。長期的專案過程往往會讓人陷入一種思維的定式：好像每個專案的工作都一樣，這樣很容易進入一種比較消極的狀態，會忘記自己曾經給自己設定的目標。以前看過這樣乙個問題：什麼才算得上有效經驗？有些人做了三年其實只有一年的經驗，因為後面基本上是前面的copy。這也是為什麼有人說乙個人的成長在於前面三五年，後面很有可能會遇到天花板。當遇到天花板的時候能不能突破是乙個關鍵。下面講乙個整個專案中需要做什麼。我會在介紹整個流程的同時插入自己的一些想法和思考。更重要的是思考，思考是人的精髓所在。
1. 需求階段
這是專案的最初的階段，這個階段主要需要明確這個專案要做什麼？目標是什麼？一般來講這個過程是產品經理去做，這個階段的醞釀時間往往比較長。因為乙個專案最開始可能只是乙個idea，對於整個目標可能他自己也沒想好，甚至是不可行的，需要進行一段時間的溝通和釐清才會逐漸形成乙個真正的需求。另外對於產品經理而言是以業務結果為導向，可能會提出一些從技術角度不合實際的想法。這個時候就需要專案經理和產品經理進行溝通，乙個是明確具體要做什麼，另外乙個是可行性（引入成本收益原則，就是完成這樣一件事情的成本是多少？收益是多少？是不是值得？就應了那句話：一切皆平衡）。當這兩個目標達成一致才可能往後面去做。如果興沖沖的往前走，往往會適得其反。所謂「磨刀不誤砍柴工」。
2. 概要設計文件
明確整個需求後開始要做的就是啟動專案。確定專案經理、架構師、開發人員、測試人員、前端等各種資源都需要到位。架構師需要產出概要設計文件（可能比較多的專案這個文件是由專案經理產出），並對整個專案的時間有乙個評估，確定整個專案的重要時間節點。整個專案流程中幾個重要的節點的時間都需要敲定，並對其規模需要比較仔細的評估。另外整個專案風險在**，都需要做到盡量的列舉，以往的專案經驗在這個過程中就會起到非常重要的作用。
3. 詳細設計文件
在概要設計後需要對這個整個專案進行分解，這時候可能並不是架構師來設計，很有可能是每個開發工程師進行分模組設計，資料庫表結構、介面、快取等一系列和此專案相關的東西，然後在做乙個合併，這種方式對於開發來講會有比較多的成長。如果整個設計過程只是專案經理或者架構師參與，而開發工程師只是參與編碼工作，這樣的乙個流程對於開發工程師的成長而言就會非常有限。
專案文件的詳細程度會根據整個專案的規模來判斷，大專案和小專案在流程上會有一些差異，小專案可能就不需要繁文縟節的專案流程和文件，這樣可以加快整個專案的程序。大專案整個流程和文件是不可或缺和非常重要的。如果說小專案可以靠個人進行保證，那麼大的專案更多的依賴於流程和管理。所以專案的流程並非一層不變，完全可以根據專案的規模在實際應用中採取靈活變通的方式。在大的流程框架下做一些優化和變通對於實際應用中是非常有好處的。引用中國那句很有名的話：「不管黑貓白貓，抓到老鼠就是好貓」。可能有些公司會非常強調流程的重要性，我覺得整個流程不能太死板，對於網際網路行業來講，最重要的是應對變化和把握時機。流程是為了保證產品的質量，而不要為了流程而流程。
4. 編碼階段
這個階段沒什麼異議，開發工程師按照設計文件中進行coding。如果是開發工程師在這個階段會有比較多的感觸。在專案管理中會有比較多的形式對開發進度進行保證，比如 說每天的晨會制、週報制。各種匯報機制各有不同，也各有優劣，比如說晨會制每天都可以監控到整個專案的進度，週報制的好處是給予開發乙個比較大的發揮空間，但是對於專案管理而言會產生一些風險。
5. 測試階段
測試階段對於開發來講是比較輕鬆的，主要的工作重心轉移到了測試人員身上。這個階段的重要性不言而喻，因為測試階段是對於專案質量保證的比較後面的一道關卡，也是可能發現問題最多的乙個階段。測試的質量很大程度上會影響整個專案的質量。qa在前期對於整個需求已經有乙個很清晰的了解，根據需求文件和設計文件產出測試用例。很多的測試會陷入開發的思維，採取開發的思維方式去測。這種方式往往會出現漏測甚至測錯的情況。qa應該是盡量獨立於開發，qa應該完全按照其本身的專業特徵進行，這樣才能保證在測試階段盡量多的暴露問題。
這裡再說說開發自測的問題。一般來講開發工程師開發完成後都會進行一些自測工作，但是不管多仔細，或多或少都會產生一些遺漏。比較好的方式是可以根據測試的tc進行自測，因為開發很有可能會陷入自己的思維定式，在自測的過程中會很難覆蓋到所有的點。這裡也遵循了乙個專案原則：問題越往前暴露專案風險越小。
6. 發布階段（交付）
這是專案的最後階段，這個專案能不能正常上線，仰仗於前面的工作，是對前面工作的乙個檢驗。pm在前面準備發布計畫。確定整個專案發布上的一些工作。
對於pm而言核心的目標就是按質按時的保證專案上線。在上面6個階段中其他人員可能某一兩個階段介入（嚴格意義來乙個專案對於每個人都需要全程介入，實際專案中可能會有一些差異）。但是對於pm而言需要全程的跟進整個專案，對於整個專案要了然於胸。在專案的前期pm需要協調各方資源，比如說確定開發人員、測試人員等和專案有關的各方人員，推動整個專案的進行。
在專案階段可能會有不同的管理工具或者管理方法，比如說定期的例會，專案階段性報告（上面也有所提及）。這都是在專案中間階段讓整個專案處於可控狀態。這些往往需要在實際過程中不斷總結。
在專案的過程中可能會遇到形形色色的問題或者風險，這些問題在每個專案都或多或少的都會出現，稍微列舉一下：
1. 資源不到位，開發資源不夠或者測試資源不夠等等都會影響整個專案的進行。
2. 專案時間評估不准，這個也比較容易出現，如何保證在任務階段評估出乙個準確的時間？
3. 需求變更，專案過程中需求變更是一件非常常見的事情，這時候如何處理好需求和專案進度，如何平衡好這兩者之前在關係。
4. 外部資源協調，如果是乙個跨部門甚至是跨公司的專案，pm如何保證專案的進行。一般來講外部資源極有可能影響整個專案的進度。這時候又如何去做？
5. 開發進度延期，實際開發中如何保證開發的進度。開發的時間和最初整個任務評估時間有些出入，這時候又需要怎麼做？
6. 編碼質量的保證，除了保證時間外，如何保證整個專案的質量。除了靠qa保證外，開發本身又如何保證**的質量？
7. 發布問題，乙個專案發布後完全沒有問題的概率還是比較小的，所以如何保證發布後的善後工作。
8. 人員變更問題，專案中有人離職或被調離等。
不管是何種角色在整個專案中都是非常重要的。每個角色除了站在自己的崗位上把自己的工作做好之外是否可以做更多的延伸。這個舉乙個例子，比如說你目前是乙個開發工程師，後面的發展路徑是專案經理，這個過程中你要怎麼積累？我想一定不是簡簡單單的把自己的模組開發完成後就ok了。一定可以往外學到更多的東西。目標只有乙個：離自己的目標更近一些。
專案經驗分享
這是我經歷的第二個專案，這個專案相對於第乙個專案dzpay相對較簡單，介紹 第乙個專案名稱 dzpay。大宗商品交易，類似某寶 這次主要總結我測試billbank的一些個人經歷 測試第一要義就是要詳讀產品需求，產品需求中有哪些模組，每個模組中又有哪些子模組，每個模組以及子模組對應的需求點都要搞清楚。...
專案經驗分享
color cyan dh師兄的經驗分享 color color olive 就在公司工作的經驗，針對shopxx專案的交流。color color darkblue 1.乙個專案，要先分出模組來。不要把所有功能都寫在乙個模組裡。如果這樣的話，專案會變得非常臃腫，模組間的耦合性太強，維護起來很困難。...
專案經驗分享
最近一直在想自己在專案中的一些得失，在每乙個專案結束都要問自己一下 這個專案中自己獲得哪些成長，下次是不是可以做到更好。長期的專案過程往往會讓人陷入一種思維的定式 好像每個專案的工作都一樣，這樣很容易進入一種比較消極的狀態，會忘記自己曾經給自己設定的目標。以前看過這樣乙個問題 什麼才算得上有效經驗？...