記錄這三年，關於專案管理上的一些心得體會 – 概述篇

本文主要目的，是記錄我從華為身上學到的一些專案管理上的知識精華，記錄在案，一來供個人今後在職業生涯道路上越走越遠的時候，不時回來觀望一番；二來供奮鬥在行業前線又想了解一下的同學一起交流。個人愚見，僅供參考。

大抵是在12年，承蒙外企老闆的厚待，給我了一個機會讓我開始接觸專案管理，踏入這扇大門。

既然是概述篇，具體的知識細節點一筆帶過，只描述一下概要即可，對應的知識細節鋪開理解，可到博文的其他兄弟章節中 一 一 體會。

• 外企專案管理崇尚自由、敏捷、高效

• 初識開發模型

• 軟體生命週期

• 各個階段輸出件

• 專案啟動會

• 風險識別及管理

外企專案管理崇尚自由、敏捷、高效

得益於在外企待上的這一年多，完全體會到了外企高管對於企業文化薰陶的重視性。
外企不同於國內中小型企業，大多外企致力於打造專業的團隊，提供極度優質的軟體服務，打造的是 客戶→服務→產品→迭代二→迭代三
而不是像國內中小企業一樣致力於 客戶→交貨→新客戶→交貨

因而公司給予了博主一個 大概8人的 純前端工程師團隊 進行管理。
在這期間，零零散散的接觸到了之前從未接觸到的專案管理知識：
做專案計劃、甘特圖、WBS工作分解、PDCA戴明環、Delphi預估方法 等等。

舉個例子：

國內中小企業：

之前博主剛畢業之際，在一家小型外包企業謀求得到一份C#工程師的工作，而在這期間，對於程式設計師的我來說，就是接到領導的單子，然後口頭宣講需求，然後就開始動手做，趕工做完了先交一次客戶，不滿意，只能利用週六周天或者平時下班時間加班改，正常作息時間是拿來做下一個專案的。如此一直迴圈的工作方式。
有一次做某專案，由於太趕工期，且需求變更太頻繁，到專案釋出會當天，驗收會上，首頁都還在報錯，頁面下方佈局層次不齊，如此質量也得到了某領導的高度評價和讚賞，然後順利驗收交貨進入維護階段。
而這樣的情況由於缺乏正確有效的專案管理手段，例子比比皆是。

切身體驗來說，可以如是概況：對於這樣的小企業，如果未經過合理的專案管理手段，會使得專案毫無章法，毫無規劃，而員工處於這樣的工作方式，對個人發展很是不利。

外企：

在外企工作期間，每一份工作項，需要經過需求分析，需求宣講，工作量評估，軟體設計，再進入開發階段，力求一步到位，想客戶之所想不到，容客戶之所看不到，因為有之前的幾個環節，所以通常能夠使軟體交付質量異常的高。
不得不說，做好一款軟體，是雙方配合的過程：客戶表達清楚我想要的，軟體工作者做出超出你想要的，這是win & win。
我曾經遇到過一個澳大利亞的客戶，在來往的郵件中，切實的體會到客戶對於當前的痛點描述的很清晰，並且為了方便我們理解，發來了大量的參考Excel資料集合。最後在雙方的合作下順利交付。

在外企的工作經歷，帶給我的體會是這樣的：由於有之前的中小型企業工作經歷，這份外企工作經歷更加顯得彌足珍貴，雙方相形見絀。外企崇尚的敏捷、自由、高效的執行。當然這也需要每一位參與者的能力都達到了一定的高度，才能夠有更加快捷的運作效率

初識開發模型

上文提到了專案管理中的開發模型：敏捷
其實運用在軟體開發中的開發模型有很多，也因專案性質不同，可使用的開發模型也不同。
隨著時代的發展，越來越多更加科學合理的開發模型被髮掘和應用，這裡簡單介紹幾種博主使用過的開發模型和不通的適用場景。

• 瀑布模型：
  循規蹈矩的進行軟體開發、從需求到設計到開發到測試，幾乎一氣呵成，不存在大量的變動，一般適用於大型專案。
  要使用這套模型，我個人總結，需要具備以下條件：
  1、專案變動不大、客戶需求穩定
  2、該模型最後才能夠輸出專案成果，需要客戶參與到軟體開發過程中，最好設定幾個體驗時間節點
  3、專案經理能力要求較高，過程管控能力要求較高
  4、各節點負責人需要具備文件能來，來撰寫各個階段輸出件

• 敏捷模型：
  快速吸收客戶需求，將專案管理和溝通更多的放在 每日晨會/看板會/站立會上，每個人都是100%的參與者，通過不斷的溝通，快速響應需求，並且以一個一個階段的方式將大型或中型專案進行分解拆分，分階段達成。
  敏捷開發模型，需要具備如下幾個特點，再使用，才能更加高效：
  1、團隊人員不在多，而在高、精。 控制在 5~10人團隊，精準管控
  2、客戶需求存在多變或還未定的情況，專案支援分階段驗收
  3、客戶可接收很少的輸出件，簡化專案開發期間的過程輸出

• 螺旋模型：
  相當於是很多個小的瀑布模型的集合，或者說看成，在客戶的需求已經明確的情況下，在初期將超級大型的專案分成了迭代一迭代二迭代三，只不過每一個階段都加入風險把控分析，然後及時把控停留或推進專案。
  螺旋模式使用超級大專案，通過版本迭代的方式，剝離使用者原始需求，拆分實現，要使用這個模型，個人愚見需要如下幾個條件：
  1、客戶也傾向於分階段交付專案
  2、專案人員組成相對穩定，角色分明
  3、專案經理具有風險分析及識別能力

其實軟體開發模型有很多，只不過不在這裡做太多介紹，概述一下專案管理需要用到大概哪些知識即可。需要看更詳細的專案開發模型詳解，請參看《我從華為身上學到的專案管理經驗 – 開發模型篇》

軟體生命週期

不同的專案，軟體生命週期可能有些許的不一樣，但正常的軟體專案生命週期應該是這樣的：

1. 客戶提出明確或模糊的需求
2. 進入【需求分析階段】，進行需求分析，專案計劃
3. 進入【設計階段】，根據需求和客戶剛需，進行原型設計和設計初稿設計，後期輸出軟體概要設計文件和軟體詳細設計文件
4. 進入【開發實施階段】，配合QA進行相關專案管理
5. 進入【測試階段】，配合TPM進行測試管理
6. 進入【釋出階段】，配合售後進行專案維護

大家必須明確的是，在專案管理中，有三點是最關鍵的因素，也是左右專案，適時調整的最大誘因。

時間、成本、質量

成本，是指投入的人力成本和物資成本，都是成本的範疇
時間，是允許的整體時間跨度，如何衡量這個時間，有個小竅門，先拿到最小時間和最長時間，再加上自己預留的BUFFER 來衡量
質量，是指在上述兩個條件下所產生出來的軟體整體質量，成本大了，時間長了，質量自然就上來了
三者層層巢狀，環環相扣。
但是其中某個環節在某個時間點出問題的時候，如何微調，這個就是技術活了，需要靠不斷的專案經驗慢慢積累，不方便細說。

各個階段輸出件

各個階段有明確的輸出件，相關名詞解釋等。
如：
需求階段輸出：《SRS.doc》《FRS.doc》《專案計劃.mpp》等
設計階段輸出：《概要設計文件》《設計初稿》等
開發實施階段輸出：《干係人》《週報》《雙日報》《日報》等
測試階段輸出：《測試報告》《轉測說明書》等
釋出階段輸出：《使用說明書》《引數配置表》等
輸出件有許多，不能一一拆分將就，詳情請參看其他《我從華為身上學到的專案管理經驗》章節

專案啟動會

這項工作是個技術活，個人認為屬於專案管理中的核心範疇之一，也可以從側面直接反饋出作為專案經理所應具備的風險應對能力和統籌策應能力。

在專案進行到即將啟項的時候，需要有一個專案啟動會，啟動會會需要囊括到專案範圍，交付範疇，專案計劃，專案干係人等方方面面。

就專案計劃而言，需要藉助甘特圖，來分析什麼人，到了什麼時候，他應該去做什麼事，預留BUFFER有多少，在考慮buffer的情況下做完之後有沒有空餘時間等等
就專案干係人而言，需要考慮資源的投入產出比，成本，資源穩定性，應急人才備選，資源時間投入比例等

並且在會上，需要明確的闡明交付時間跨度，里程碑，交付件等關鍵資訊給客戶或領導做展示。

相關詳細的專案啟動會輸出件demo，會在後面的相關章節中做詳細介紹並附上幾個不同的專案啟動會ppt供參考。

風險識別及管理

風險管理個人看來是個虛活。
這項技術需要更多的量累計，才能達到質的改變。

• 客戶風險識別
• 業務風險識別
• 管理風險識別
• 技術風險識別
• 決策樹

此處不一一贅述，確實太虛了，無法落筆到本文中，看後面能不能花點兒時間把博主所遇到的一些風險案例 撰寫出來，才能體會到。

總之一句話：只計算IT行業的專案管理的話，本人只有3、4年的經驗，以上只是我個人的一些愚見總結出來的一個概述，具體的精華部分，會花時間，以舉例demo，上傳附件等方式來詳述，落實到各個其他章節中。
專案管理深似海，慢慢泛舟學習吧。