在專案中成長

  最近一直在想自己在專案中的一些得失，在每一個專案結束都要問自己一下：這個專案中自己獲得哪些成長，下次是不是可以做到更好。長期的專案過程往往會讓人陷入一種思維的定式：好像每個專案的工作都一樣，這樣很容易進入一種比較消極的狀態，會忘記自己曾經給自己設定的目標。以前看過這樣一個問題：什麼才算得上有效經驗？有些人做了三年其實只有一年的經驗，因為後面基本上是前面的copy。這也是為什麼有人說一個人的成長在於前面三五年，後面很有可能會遇到天花板。當遇到天花板的時候能不能突破是一個關鍵。下面講一個整個專案中需要做什麼。我會在介紹整個流程的同時插入自己的一些想法和思考。更重要的是思考，思考是人的精髓所在。

       專案流程

1.    需求階段

        這是專案的最初的階段，這個階段主要需要明確這個專案要做什麼？目標是什麼？一般來講這個過程是產品經理去做，這個階段的醞釀時間往往比較長。因為一個專案最開始可能只是一個idea，對於整個目標可能他自己也沒想好，甚至是不可行的，需要進行一段時間的溝通和釐清才會逐漸形成一個真正的需求。另外對於產品經理而言是以業務結果為導向，可能會提出一些從技術角度不合實際的想法。這個時候就需要專案經理和產品經理進行溝通，一個是明確具體要做什麼，另外一個是可行性（引入成本收益原則，就是完成這樣一件事情的成本是多少？收益是多少？是不是值得？就應了那句話：一切皆平衡）。當這兩個目標達成一致才可能往後面去做。如果興沖沖的往前走，往往會適得其反。所謂“磨刀不誤砍柴工”。

2.    概要設計文件

        明確整個需求後開始要做的就是啟動專案。確定專案經理、架構師、開發人員、測試人員、前端等各種資源都需要到位。架構師需要產出概要設計文件（可能比較多的專案這個文件是由專案經理產出），並對整個專案的時間有一個評估，確定整個專案的重要時間節點。整個專案流程中幾個重要的節點的時間都需要敲定，並對其規模需要比較仔細的評估。另外整個專案風險在哪裡，都需要做到儘量的列舉，以往的專案經驗在這個過程中就會起到非常重要的作用。

3.    詳細設計文件

       在概要設計後需要對這個整個專案進行分解，這時候可能並不是架構師來設計，很有可能是每個開發工程師進行分模組設計，資料庫表結構、介面、快取等一系列和此專案相關的東西，然後在做一個合併，這種方式對於開發來講會有比較多的成長。如果整個設計過程只是專案經理或者架構師參與，而開發工程師只是參與編碼工作，這樣的一個流程對於開發工程師的成長而言就會非常有限。

        專案文件的詳細程度會根據整個專案的規模來判斷，大專案和小專案在流程上會有一些差異，小專案可能就不需要繁文縟節的專案流程和文件，這樣可以加快整個專案的程式。大專案整個流程和文件是不可或缺和非常重要的。如果說小專案可以靠個人進行保證，那麼大的專案更多的依賴於流程和管理。所以專案的流程並非一層不變，完全可以根據專案的規模在實際應用中採取靈活變通的方式。在大的流程框架下做一些優化和變通對於實際應用中是非常有好處的。引用中國那句很有名的話：“不管黑貓白貓，抓到老鼠就是好貓”。可能有些公司會非常強調流程的重要性，我覺得整個流程不能太死板，對於網際網路行業來講，最重要的是應對變化和把握時機。流程是為了保證產品的質量，而不要為了流程而流程。

4.    編碼階段

        這個階段沒什麼異議，開發工程師按照設計文件中進行coding。如果是開發工程師在這個階段會有比較多的感觸。在專案管理中會有比較多的形式對開發進度進行保證，比如 說每天的晨會制、週報制。各種彙報機制各有不同，也各有優劣，比如說晨會制每天都可以監控到整個專案的進度，週報制的好處是給予開發一個比較大的發揮空間，但是對於專案管理而言會產生一些風險。

         一個任務應該分成多細。也就是說一個任務分配下去多長時間合理。這個曾經我們也一起討論過這個問題。有的說1天，2天，也有的說3天5天等等。對於我而言是不太喜歡把一個任務分解到一天，這樣心裡會感覺到非常的不爽，受到了嚴格的束縛。我比較贊同這樣一種分法：可以把一個星期的任務分配下去，然後由開發工程師再將這一個星期的任務進行分解，一個層面上來講開發工程師有一定的自由分配能力，他可以在這個過程中獲得成長。另外就是給予開發工程師一定的空間，而不是完全把時間交給了專案經理。

5.    測試階段

        測試階段對於開發來講是比較輕鬆的，主要的工作重心轉移到了測試人員身上。這個階段的重要性不言而喻，因為測試階段是對於專案質量保證的比較後面的一道關卡，也是可能發現問題最多的一個階段。測試的質量很大程度上會影響整個專案的質量。QA在前期對於整個需求已經有一個很清晰的瞭解，根據需求文件和設計文件產出測試用例。很多的測試會陷入開發的思維，採取開發的思維方式去測。這種方式往往會出現漏測甚至測錯的情況。QA應該是儘量獨立於開發，QA應該完全按照其本身的專業特徵進行，這樣才能保證在測試階段儘量多的暴露問題。

        這裡再說說開發自測的問題。一般來講開發工程師開發完成後都會進行一些自測工作，但是不管多仔細，或多或少都會產生一些遺漏。比較好的方式是可以根據測試的TC進行自測，因為開發很有可能會陷入自己的思維定式，在自測的過程中會很難覆蓋到所有的點。這裡也遵循了一個專案原則：問題越往前暴露專案風險越小。

6.    釋出階段（交付）

       這是專案的最後階段，這個專案能不能正常上線，仰仗於前面的工作，是對前面工作的一個檢驗。PM在前面準備釋出計劃。確定整個專案釋出上的一些工作。

 

專案管理

        對於PM而言核心的目標就是按質按時的保證專案上線。在上面6個階段中其他人員可能某一兩個階段介入（嚴格意義來一個專案對於每個人都需要全程介入，實際專案中可能會有一些差異）。但是對於PM而言需要全程的跟進整個專案，對於整個專案要了然於胸。在專案的前期PM需要協調各方資源，比如說確定開發人員、測試人員等和專案有關的各方人員，推動整個專案的進行。

        在專案階段可能會有不同的管理工具或者管理方法，比如說定期的例會，專案階段性報告（上面也有所提及）。這都是在專案中間階段讓整個專案處於可控狀態。這些往往需要在實際過程中不斷總結。

       在專案的過程中可能會遇到形形色色的問題或者風險，這些問題在每個專案都或多或少的都會出現，稍微列舉一下：

1.    資源不到位，開發資源不夠或者測試資源不夠等等都會影響整個專案的進行。

2.    專案時間評估不準，這個也比較容易出現，如何保證在任務階段評估出一個準確的時間？

3.    需求變更，專案過程中需求變更是一件非常常見的事情，這時候如何處理好需求和專案進度，如何平衡好這兩者之前在關係。

4.    外部資源協調，如果是一個跨部門甚至是跨公司的專案，PM如何保證專案的進行。一般來講外部資源極有可能影響整個專案的進度。這時候又如何去做？

5.    開發進度延期，實際開發中如何保證開發的進度。開發的時間和最初整個任務評估時間有些出入，這時候又需要怎麼做？

6.    編碼質量的保證，除了保證時間外，如何保證整個專案的質量。除了靠QA保證外，開發本身又如何保證程式碼的質量？

7.    釋出問題，一個專案釋出後完全沒有問題的概率還是比較小的，所以如何保證釋出後的善後工作。

8.    人員變更問題，專案中有人離職或被調離等。

個人問題總結

       不管是何種角色在整個專案中都是非常重要的。每個角色除了站在自己的崗位上把自己的工作做好之外是否可以做更多的延伸。這個舉一個例子，比如說你目前是一個開發工程師，後面的發展路徑是專案經理，這個過程中你要怎麼積累？我想一定不是簡簡單單的把自己的模組開發完成後就OK了。一定可以往外學到更多的東西。目標只有一個：離自己的目標更近一些。