項目管理思考小記之一

         最近筆者面試了不少項目經理，都是有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,企業信息化, 團隊管理 資訊，請關注個人微信訂閱號：

做者：Petter Liu
出處：http://www.cnblogs.com/wintersun/ 本文版權歸做者和博客園共有，歡迎轉載，但未經做者贊成必須保留此段聲明，且在文章頁面明顯位置給出原文鏈接，不然保留追究法律責任的權利。 該文章也同時發佈在個人獨立博客中-Petter Liu Blog。