翻看一年半以前做過的一個大專案的專案總結，雖然時間過去這么久，還是覺得這篇總結里的很多內容非常有感觸。貼出來分享一下。
在我的觀念里，一個優秀的專案經理，無論你采用瀑布，迭代，還是敏捷;都能夠積極的激發團隊的創造力，并靈活的駕馭流程，創造最大的價值。 在我看來，團隊比流程更重要。
專案背景介紹：
互聯網里的軟體專案。對原產品的一個核心功能進行優化和重構。從專案啟動到專案發布總共一個月時間，原預估的開發周期為3個月，總作業量為500人日，專案核心成員(PD、ued、dev、qa、pm)11人。我在專案中作了如下的嘗試：
一、 專案流程的改進嘗試
流程應該是輔助我們提升效率提高質量的手段，為遵守流程而遵守流程是沒有任何必要的。我們的專案要在這么短的時間里完整非常復雜的目標，一個關鍵點就是能靈活的運用現有流程，通過適當的程序裁剪和并行開發來提升效率。專案中的具體做法如下：
1. 裁剪專案里程碑控制點，強化專案計劃以及功能預演在專案中的關鍵作用，榷訓評審活動對專案行程的制約以及對專案資源的消耗。
2. 專案多項活動并行開展，提高專案效率，縮短專案周期。
i. 專案啟動之后，需求分析、前端開發、設計、編碼、測驗分析作業同步開展;并非像以前一樣要等到所有需求或者demo都穩定后才能進入設計編碼，而是當整體需求明確，需求細節還不完善時即進入開發;同時也根據demo的完成情況靈活的安排開發任務。使得整個專案組能快速的回應需求，使整個程序更加靈活、敏捷。
1) 實際上是將一個大活動分成了若干個小塊，每個小塊完成之后下一項活動就可開展，而不是要等到整個大活動完成之后才能進入到下一活動。
2) 這種方式在一定程度上也引起了需求變更，反復修改等問題，在一定程度上增加了資源量的投入。因此需要良好的控制。在并行開始前，整體需求(比如需求范圍，包括的功能點等)必須是確認清楚的，只有一些需求的細節是有待明確的;同時需要整個專案組都對整體需求有統一的認識;特別是開發人員。
ii. 在測驗階段，也將單元測驗、功能測驗以及codereview等審核作業并行開展。
1) codereview等審核作業不再成為專案進入測驗的制約條件，而是可以并行開展的。但codereview作業對專案質量控制室非常重要的一環，因此在專案編碼前要有詳細的設計方案知道開發人員進行編碼，在編碼程序中需要有架構師或技術負責人指導和跟蹤開發人員編碼。
2) 單元測驗由測驗人員和開發人員協同完成，測驗人員撰寫TC，準備測驗資料，開發人員利用測驗人員的TC和測驗資料來撰寫單元測驗。
4. 測驗階段，由測驗負責人主導和控制，全員參與測驗，共同保證專案質量。產品的質量是做出來的，而不是測出來的;PD、PM、開發更需要對產品的質量負責。
5. 流程是死的，人是活的!要靈活運用流程，而不是被流程束縛
二、 專案團隊成長的改進嘗試
在我的專案管理理念里，一個成功的專案，除了要能多快好省的完成專案目標，滿足客戶和公司的利益以外;還應該讓每個專案成員獲得成長和進度，讓每個人對自己的作業充滿激情和斗志，成為人員培養的重要實踐。在我自己的專案中，我也會堅持貫徹我的理念。下面則是在專案中在這方面所做的一些努力和嘗試。
1. 專案成立初期，每位專案成員確立個人的專案目標，在專案中對個人能力的培養有一個清晰的定位，也是對每個人的激勵。
2. 在專案程序中合理調配任務為每個人的能力培養提供條件。比如
i. xx搞單元測驗，深入學習單元測驗方面的知識
ii. xx學習自動化測驗，撰寫自動化腳本，運行自動化。同時組織團隊活動。
iii. xx主要熟悉發布線offer業務，讓其承擔了詳細頁面主要功能的開發。
iv. xx主要做offerscan這塊業務，參與offerscan 這塊復雜業務的設計作業
v. xx主要是與何崚一起設計專案的技術方案，同時對發布線的代碼進行規范整合。
vi. xx主要是在專案管理上鍛煉資源配置、任務跟蹤，進度控制的能力。
3. 在專案中要求專案成員寫專案日志，幫助大家培養計劃、總結、主動回報的良好習慣。
4. 專案程序中，重角色輕崗位。
i. 需求分析和產品設計階段，由PD、需分主導，同時開發、測驗也積極參與其中，對產品的實作方案提出積極的建議。讓所有專案成員都有為產品負責的意識，都能更多的去從商業上考慮需求的價值，積極的參與產品的設計。
ii. 測驗階段，讓PD、開發都參與測驗，同時由測驗負責人來主要控制;培養PD、開發的質量意識，讓他們深刻理解測驗人員的作業，更好的實作PD、開發、測驗的協同作業。
iii. Owner意識的培養，大局觀的培養;專案所有成員對整個專案負責;而不是PD只對需求負責，開發只對編碼負責，測驗只對測驗負責。每一個成員關注的是整個專案，而是不自己負責的內容。
三、其它方面的經驗
1. 高效的溝通：如果是跨團隊的專案或者稍微大一點的專案，亦或者是比較緊急的專案，那溝通成本則是專案資源消耗的一個大頭;那么專案閉關則是一種非常必要的形式。那閉關對高效溝通有哪些明顯的幫助呢?
1) 面對面的溝通;一旦發現問題，可以直接面對面的溝通，隨時溝通，而不必發貿易通，打電話，或者跑來跑去，減少了很多時間的浪費。
2)減少不必要的溝通，快速應對緊急問題;在專案程序中沒有召開過例會、周會;評審會也是能少則少;但是一旦發現重要問題，則立即組織大家召開緊急會議，討論對策，制定方案。
3)這里也會有一個問題，那就是閉關時，可能溝通頻率會增多，這樣會影響到別人的作業效率;那因此在專案程序中也應要求專案成員注意掌握溝通的頻率和時機，不能因為頻繁的溝通反而影響作業效率
2. 充滿激情的團隊
團隊是專案成敗的關鍵。PM需要讓整個團隊保持持久的激情和高昂的斗志;這樣整個團隊才能所向披靡。那在專案中需要通過哪些方法來讓團隊保持奮斗激情呢?
1)專案目標共享共擔。首先要讓所有專案成員認同專案的目標，無論是商業目標、技術目標還是質量目標。所有人需要認同專案目標，同時也要讓大家明白，是所有專案成員對專案目標負責，而不是專案經理或者PD。
2)要讓所有人都能保持激情，還需要在專案程序中不斷的調節大家的情緒。比如我們專案有時搞點娛樂活動、經常點點水果、經常買點吃的，，另外，最重要的是，一個專案中要有一兩個比較活躍的人，能夠帶動團隊氛圍的人;如果能有一兩個女孩子就更好了。男女干活，搭配不累是很有道理的。
3)專案經理要創造一種非常open的氛圍，讓每個人都有同等重要的發言權，讓每個人都覺得自己是專案的owner。
3. 團隊執行力
要讓每個人釋放出最大的能量;PM除了把握一些關鍵細節點外，其余的任務都可以給團隊成員充分的發揮空間，讓他們盡情的去發揮自己的才智。
最讓我感動的一句話就是專案成員說的“我們是一群瘋子，我們是一家人!” 專案里面最重要的是團隊。
uj5u.com熱心網友回復：
支持分享，專案管理主要是時間、質量和成本的管理uj5u.com熱心網友回復：
縱觀全文，都是為了說明“團隊比流程”重要。。確實，有了好的團隊，作任流程（只要不是完全不可行的）都能很好的完成目標，就象是俄羅斯的飛機，只要發動機夠強勁，就是綁兩塊木板也可以飛起來。。但是，我想說的是，組織起一只有瘋狂作業熱情的團隊與其說是一種管理方法，不如說是一種管理藝術。。而藝術，本質上是不可復制的，就象是樓主的此篇文章，程序和結果似乎都看得到，但真正的原因卻在文章之外。。
而我更想說的是，軟體本身質量的好壞或許是程式員決定的，但其實軟體能否產生出應有的價值，卻決不是程式員這個層面能解決的，基至也不是軟體架構師能保證的。。軟體價值的真正基石，應該是在業務架構師這個層面，沒有對業務深入的理解和建模，再好的軟體架構師也只能是巧婦難為無米之炊，結果只能是勉強把所有現行的業務固化到軟體之中，并在后期的維護中越來越難以控制。
uj5u.com熱心網友回復：
團隊比流程”重要，支持uj5u.com熱心網友回復：
開發軟體的時間如何計算？？uj5u.com熱心網友回復：
你可以通過計度計劃管理軟體來管量你的軟體開發周期，現在市場上這種軟體很多。如PowrePlan、P6、project等等。uj5u.com熱心網友回復：
支持團隊比流程重要uj5u.com熱心網友回復：
比較客觀，不錯。uj5u.com熱心網友回復：
作業十幾年，管理比什么都重要。uj5u.com熱心網友回復：
風險可控、團隊給力的前提下，團隊比流程重要uj5u.com熱心網友回復：
寫得真好，就像柳傳志都常講，最重要的是人。uj5u.com熱心網友回復：
如果團隊強大了，開發的單元拼起來就是一個大專案。我現在看到的專案開發量都很小了，基本上是產品應用，修修補補就上線了，哈哈轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/13145.html
標籤：項目管理