談到如何駕馭復雜性就就不得不提到我們當下所處的VUCA時代，因為VUCA這個詞中的C就是指復雜性。而VUCA這個詞是由易變的（Volatility）、不確定的（Uncertainty）、復雜的（Complexity）和模糊的（Ambiguity）等四個英文單詞的首字母拼接而成。VUCA本身就強調復雜性，項目本身管理的復雜性給項目的實際管理者即項目經(jīng)理帶來了全新的挑戰(zhàn)?！禤MBOK® 指南》第7版還特意的把駕馭復雜性作為其主要原則的一部分，可見其對管理項目復雜性上升到一個全新的高度。

項目的復雜性一般是由于項目所涉及干系人的行為做法迥異，項目所在的外部環(huán)境或系統(tǒng)的模糊性造成的。項目經(jīng)理通常是無法預見復雜性的突然出現(xiàn)，項目的復雜性是眾多風險、事件及不同事件的彼此依賴性共同作用的結果。比如時下的技術創(chuàng)新事件層出不窮，技術創(chuàng)新可能導致項目所在組織當下產(chǎn)品交付、服務和工作方式的顛覆式改變。例如，刷二維碼支付代替?zhèn)鹘y(tǒng)的刷銀行借記卡方式，基于手機的線上購物已經(jīng)成為目前年輕人的主要等物選擇。

我們都知道項目的復雜性的最直接原因是由于項目所涉及的干系人針對項目目標的理解彼此不一致導致的。解決人員對項目目標的認同、彼此工作方式的協(xié)同是項目經(jīng)理在進行日常項目管理過程中需要特別留意的。著名的《人月神話》和《設計原本》的作者布魯克斯曾經(jīng)斷言：“多數(shù)軟件項目的問題在于人的因素，而非技術”。另一本著名軟件著作《人件》也非常強調良好的團隊建設與團隊工作氛圍對項目成功的影響?！度思芬粫淖髡吖矁晌唬麄兪?/span>Tom DeMarco和Timothy Lister,目前是某著名公司的首席咨詢顧問，并致力于復雜組織的文化變革和項目團隊建設的咨詢工作。這兩位大師曾經(jīng)有過一場針對軟件工程的社會因素的深入研討。在一次長途飛機上,他們突發(fā)靈感，創(chuàng)造性的提出“軟件系統(tǒng)的主要問題不在于技術,而在于社會性因素。”這個結論對IT技術人士的固有認知無疑是顛覆性的，很多人以前都是堅信技術就是一切,無論出現(xiàn)什么問題,總會有更好的技術為我們找到出路。但是如果我們確定我們所面對的問題天生就屬于社會學的范疇,再好的技術可能也提供不了什么幫助。例如,對于一組必須工作在一起的人，他們偏偏彼此不信任,那就沒有什么軟件包或萬能工具能改變他們并解決現(xiàn)實問題。事實證明大師的論斷的正確性，在大多數(shù)項目中，社會性的復雜程度遠比技術上的挑戰(zhàn)要難處理得多。在《人件》一書中大師也談到在他們以往所研究的絕大多數(shù)項目中，沒有一個是由于單純的技術問題導致失敗的。

那么到底是什么社會性導致了項目的失敗呢？這里的社會性因素可以說是多種多樣的。比如缺乏催化劑式的項目經(jīng)理，一般具備這樣特質的項目經(jīng)理，可以通過自身的影響力甚至是個人魅力來促成項目團隊成員之間的相互交流和融洽相處。由于這種靈魂人物的存在使團隊內(nèi)部更加有粘度，項目得日常工作也變得更加有趣。另外，由于客戶或市場得壓力，項目經(jīng)理通常采用不合理的加班手段來壓縮項目進度，這間接導致團隊士氣低落和項目交付產(chǎn)品質量低下。因為一味地追求項目進度，在缺乏充足項目資源配備或相對固化的項目活動順序的前提下，必然會導致高標準質量要求的舍棄。當然，沒有成功打造一個高績效的項目團隊也是社會性的根本體現(xiàn)。很多項目團隊并非天然的具備背景的多樣性和行為的自組織等特點，他們往往缺乏獨立自主的工作態(tài)度。更有甚者，有些項目團隊成員更加具備帕金森綜合癥的特點，即只要還有時間，工作就會不斷擴展，直到用完所有的安全時間，導致關鍵項目活動的延遲，最終導致項目延期。

綜上所述，項目經(jīng)理要充分評估針對您所指導的項目的社會性因素，納入項目所存在的問題和潛在的風險管理的范疇，做到持續(xù)的監(jiān)督和積極的應對，最終能夠成功駕馭項目的復雜性。

我們且通過以下的場景例題來體會如何駕馭復雜性：

典型例題：一位經(jīng)驗不足的項目經(jīng)理被分配到了一個新項目上把控項目，因為將來他所從事的項目為矩陣組織。那么他所面對的溝通形式為？

A.簡單的

B.公開但準確的

C.復雜的

D.難以自動操作

參考答案：C

矩陣型組織的特點是雙重匯報。項目團隊成員來自職能部門，而且是兼職做項目的。項目團隊成員一般有兩個個績效匯報的溝通渠道，職能線條需要向自己部門的職能經(jīng)理述職，同時在項目線條又需要把工作情況報告給項目經(jīng)理。本題目提到是經(jīng)驗不足的項目經(jīng)理，所以今后他面對的最大挑戰(zhàn)就是成員雙重匯報和多頭溝通的復雜性。

典型例題：你是一家電子游戲的項目經(jīng)理。你的項目一開始有點含糊不清。它的復雜性和規(guī)模與團隊成員去年所做的項目相似。關鍵相關方希望積極地參與進來，并能夠隨著項目的進展修改需求。團隊已經(jīng)準備好定義和評估活動了。下列哪個陳述是正確的? （共選三個可選答案）

A.  你應該使用敏捷方法來增量地交付商業(yè)價值，并適應需求變更的需要。

B.    你應該使用敏捷方法，這種方法不需要進度管理計劃。

C.    當使用敏捷方法時，最大限度地關注對客戶的價值，最小限度地關注過程。

D.    基于業(yè)務需求、風險和對組織的價值對待辦項進行優(yōu)先級排序。最重要的用戶故事位于待辦事項列表的頂部。

參考答案：A, C, D. 

根據(jù)PMBOK®指南，無論你使用什么項目生命周期管理方法，都應該完成進度管理計劃，故不選B。通過本題目的管理實踐，我們知道刻意通過敏捷方法，以增量交付的方式來駕馭項目的復雜性。

典型例題：敏捷方法可以緩解存在高度不確定性的項目場景所產(chǎn)生的問題。以下哪一項是敏捷在這些情況下解決的痛苦的例子？（共選三個可選答案）

A．項目目標不清晰

B. 低缺陷

C．需求不明確

D. 技術債務

參考答案：A、C、D

此題在考敏捷項目管理所適用的場景，當一個項目包含高度的不確定性、變更和復雜性時，項目團隊可能會經(jīng)歷許多痛點。敏捷方法通過執(zhí)行諸如創(chuàng)建清晰的團隊章程（即愿景和使命）等活動來直接解決這些難題。通常項目所面臨的痛點包括目的目標不明確、需求不明確、技術債務和高缺陷。B選項的低缺陷不屬于項目所面臨的痛點范疇，故不選B。