最近筆者面試了很多專案經理，都是有PMP認證(PMP指的是專案管理專業人士資格認證，它是由美國專案管理協會（Project Management Institute發起的，嚴格評估專案管理人員知識技能是否具有高品質的資格認證考試)，但沒有幾個人把專案管理從理論到實踐落地，實際上我們需要就是從書本到實踐，從實踐回到書本，每個知識領域都是這樣，個人與團隊才會有提升，另一個客戶也是過于相信PMP認證，認為只要有PMP認證的專案管理就能夠做好專案管理，其實不然，
專案管理鐵三角
有些專案經理夸張到專案管理鐵三角都講不清楚， 也叫三重約束， 我們再到回顧下：每個專案都要平衡由時間、成本和范圍組成的“三角形” ，若要更改其中一項，就一定會影響另外至少一項，專案經理的作業是防止整個三角形失衡，
- 范圍：基本在專案前期已經規劃好，并且有為完成專案所需要的詳細待辦任務清單，在后續執行的程序中很少會去進行調整；
- 時間：完成范圍內待辦任務所需要的時間投入；
- 成本：完成范圍內待辦任務所需要的成本投入，
所以在傳統的專案管理中，范圍在前期經過大量調研和規劃進而最終確定的情況下，只能通過時間和成本的調整來完成既定的任務，即，如果要節省時間則需要加大成本，如果要節省成本則延長時間，對于范圍本身因為前期的大量投入，很難說在范圍上面做太大的調整，
在當前的時代背景下，軟體領域快速發展、客戶要求的不斷提高、用戶訴求的日新月異，我們很難以保證在自己先期投入大量成本的專案規劃是準確無誤的，因為對于變化我們很難以去預判，也難以去管控，我們更需要不斷的嘗試和總結來，即采用經驗程序控制的方式來完成軟體專案的管理，也就是敏捷專案管理三角的由來，
- 價值：將目標聚焦在客戶和用戶的視角，軟體用來交付他們需要的價值，而非站在專案角度去完成對應的待辦任務，
- 質量：軟體行業發展至今，用戶對軟體的依賴越來越強，要求也越來越高，
- 約束：制約用戶價值和軟體質量的因素，由傳統專案管理三角型中的范圍、時間和成本構成，
對于傳統三角的范圍不變，敏捷三角反其道而行之，在既有的約束條件下，我們會高質量的優先完成高價值的事情，雖然約束條件中的三角和傳統專案管理的三角在字面上是一樣，但本質的區別在于，敏捷三角的范圍是可變的而傳統三角則很難，
約束點中的時間能夠以敏捷專案管理中的迭代實踐來進行計算，以周為單位將時間抽象成一個相對固定的基礎單元；而成本最多在與人力投入，在敏捷實踐中的全功能團隊規模也很方便計算出整體的投入，在單位時間內的投入和產出相對穩定的情況下，可以合理的通過調整范圍來靈活調配約束這個點，以滿足三角形中的價值和質量要求，
在敏捷意義上，有一個固定的時間表（在Scrum中我們通過時間限制的 Sprint和固定資源來實作這一點，因此，當事情根據計劃不起作用時，需要減少范圍，在敏捷中但是，我們確保即使我們必須在范圍上妥協，我們仍然會在產品積壓中提供最高優先級的專案，以最大化專案產生的價值，
敏捷三角相較于傳統三角，將范圍從固定演進為可變以靈活適應市場的變化，將目標聚焦于客戶價值而非既定任務以滿足多元化的用戶需求，加強質量的權重以提升終端用戶的體驗，價值驅動的專案管理方式在當前的軟體時代背景下顯然是由于計劃驅動的管理方式的，
我們再來看軟體工匠的宣言，與敏捷思想相關，回應變化，增加價值，如果我們給客戶交付的軟體沒有價值，還有什么意義？
不僅要讓軟體作業，更要精益求精，
不僅可以回應變化，更要穩步增加價值，
不僅要有個體與互動，更要形成專業人員的社區，
不僅要與客戶合作，更要建立卓有成效的伙伴關系，
實施敏捷需要團隊中每個人能力都能獨擋一面，如果人的能力跟不上，還是控制變化為主，
程序
PMP專案管理實際上是瀑布程序，而當下我們的軟體開發大都是迭代開發程序，一個優秀的IT專案經理需要這點兒上面有思考，因為PMP教材不會告訴你，傳統專案管理與軟體工程專案管理相結合，
傳統專案管理通常采用的是瀑布式、部分迭代開發模式，要求在專案建設時，需求足夠明確、檔案足夠規范，迭代程序中需求變更越多、越晚，對專案影響越大，會影響到專案的交付質量，
敏捷專案管理作為新興的專案管理模式，簡化了傳統專案管理的繁瑣流程和檔案，以 Scrum 為代表，歡迎需求變更，在客戶需求不明確的時候，以在較短的周期內開發出可用的軟體為目標，來幫助客戶描述自己的需求，迭代程序中的需求變更會加入到專案繼續迭代需求池，豐富專案的產品功能，
具體的敏捷方法在每個迭代周期中都存在立會制度，燃盡圖、看板監控、計劃發布等，這些和PMBOK中對專案生命周期的五個程序組啟動、規劃、執行、監控和收尾的定義沒有沖突矛盾，實際上敏捷專案管理的這些措施可以看作是PMBOK專案生命期五個程序組執行的微縮版，區別在于敏捷專案管理的迭代周期，時間很短，在去執行程序中裁剪了很多規范正式的專案管理流程制度，這些問題作為IT專案經理需要融會貫通，
范圍蔓延
在實際作業中，范圍蔓延往往出自相關方的良好愿望，如客戶要求采用不斷出現的新技術，或者專案團隊希望討好客戶等，在專案中，隨意增加哪怕是一小件作業，都會消耗專案資源，都可能給整個專案帶來不小的干擾，任何未經批準的專案范圍變更都是不允許的，這種情況叫做“鍍金”，即客戶沒有要求而專案團隊主動增加的范圍，除了討好客戶的原因外，秀才藝、配置強迫癥也是造成“鍍金”的原因，就是一定要給客戶做完美才行，任何動作都會消耗資源，可做可不做的事情就不要做，
與“鍍金”對應的另一種情況叫“爬行”，即由于客戶增加或改需求，專案經理被動接受而造成的范圍蔓延，客戶可能認為讓專案團隊多做一些事情會增加專案的價值，但往往會降低專案的價值，
這其實也是一種范圍蔓延了，別看其中所提及的版本聽起來只是比你原計劃的版本強一點點而已，但是這種范圍蔓延會耗費大量的時間和資源，在專案只中，最狡猾、最不易發現的一種范圍蔓延就是偽裝成“改進方案”或“優化方案”的蔓延，
為減少這種隱秘的范圍蔓延，專案經理和團隊應當明確每一步計劃所包含的范圍，至于那些計劃之外的部分，可以當作是需求變更，走整體變更流程，
(1) 透徹理解相關方的需求，需求變更往往就是在需求分析時所埋的坑，
(2) 對頊目的所有要求都要記錄在案， 形成規范的頊目檔案，讓需求變更有據可查、有理可依，
(3) 嚴格按頂目管理方法編制范圍計劃 ，做到專業的頊目管理，
(4) 制訂并遵守專案范圍管理計劃，
(5) 不接受口頭或微信群的變更申請，變更要走 整體變更控制流程，
(6) 堅持規范的綜合評審，相關方也許會因為必須接受綜合評審，而放棄某個 拍腦袋的不合理要求，
(7) 強調完工時間和預算的重要性，如果要追加作業，就只有取消另外的作業
今天先到這兒，希望對技術領導力， 企業管理，系統架構設計與評估，團隊管理, 專案管理, 產品管理,團隊建設 有參考作用 , 您可能感興趣的文章:
精益IT組織與分享式領導
領匯入怎樣帶領好團隊
構建創業公司突擊小團隊
國際化環境下系統架構演化
微服務架構設計
視頻直播平臺的系統架構演化
微服務與Docker介紹
Docker與CI持續集成/CD
互聯網電商購物車架構演變案例
互聯網業務場景下訊息佇列架構
互聯網高效研發團隊管理演進之一
訊息系統架構設計演進
互聯網電商搜索架構演化之一
企業資訊化與軟體工程的迷思
企業專案化管理介紹
軟體專案成功之要素
人際溝通風格介紹一
學習型組織與企業
企業創新文化與等級觀念
組織目標與個人目標
初創公司人才招聘與管理
人才公司環境與企業文化
企業文化、團隊文化與知識共享
高效能的團隊建設
專案管理溝通計劃
構建高效的研發與自動化運維
某大型電商云平臺實踐
互聯網資料庫架構設計思路
IT基礎架構規劃方案一(網路系統規劃)
餐飲行業解決方案之客戶分析流程
餐飲行業解決方案之采購戰略制定與實施流程
餐飲行業解決方案之業務設計流程
供應鏈需求調研CheckList
企業應用之性能實時度量系統演變
如有想了解更多軟體設計與架構, 系統IT,企業資訊化, 團隊管理 資訊，請關注我的微信訂閱號：
![MegadotnetMicroMsg_thumb1_thumb1_thu[2]](https://img.uj5u.com/2020/09/11/53031110242056.jpg "MegadotnetMicroMsg_thumb1_thumb1_thu[2]")
作者：Petter Liu
出處：http://www.cnblogs.com/wintersun/
本文著作權歸作者和博客園共有，歡迎轉載，但未經作者同意必須保留此段宣告，且在文章頁面明顯位置給出原文連接，否則保留追究法律責任的權利，
該文章也同時發布在我的獨立博客中-Petter Liu Blog，
轉載請註明出處，本文鏈接：https://www.uj5u.com/gongcheng/4079.html
標籤：其他
上一篇：高項復習筆記（二）
下一篇：Git和Svn的區別