第一節 干系人的心態

根據第一章的系統意志理論，每個作為系統元素的個體的人首先會被賦予其在組織里所處的地位的基本心理特點。

這種心理特點可能會被人的個性化差異所掩蓋，往往會使我們忽略其所在位置而獨有的心理特征，轉而把目光集中在其個性獨有的心理分析上，這樣往往起不到很好的效果。

記住“形式決定內容”這句話，自身所在的位置和個體之間相互具有的關系決定了個體的基本心理狀態。我們在后面的篇幅里面稱之為個體的“結構屬性”。

為了便于理解，我們可以看一個日常生活中的例子：婆媳關系。可以這么講，天底下的婆媳關系都很微妙，人品無關，結構使然！婆媳關系自古以來就是一個令人頭疼的事情，因為在結構上，婆媳關系本身就是一種為了爭奪稀有資源而產生的矛盾關系。這種矛盾關系不能化解，只能緩解。個性的差異只會對這種矛盾起到減弱或者強化的作用，不會根本解決這個矛盾。一個組織內不同職位和關系的人之間的矛盾同樣可以從這個角度來理解。但是，實際生活中，我們往往會忽略這個結構矛盾，而把目光放在具體干系人的個性事件上，也就是說，當發生矛盾的時候，我們往往會說這是那個人比較自私，沒有團隊意識；或者說這是因為那個人的怠慢；或者我們干脆把某些矛盾歸因于我們的壞運氣。

1.結構屬性改變人的行為的心理學實驗

（1）心理學家們曾經安排三個人一組，一起閱讀一篇文章，兩個人談心得，一個人打分，討論時會提供四塊餅干。他們發現那個“打分者”更可能拿最后一塊餅干，不在乎吃相，并且不收拾餅干渣。

（2）監獄模擬實驗。為了研究人及環境因素對個體的影響程度，心理學家津巴多于1972年設計了一個模擬監獄的實驗，實驗地點設在斯坦福大學心理系的地下室中，參加者是男性志愿者。他們中的一半隨機指派為“看守”，實驗者發給他們制服和哨子，并訓練他們推行一套“監獄”的規則。剩下的另一半扮演“犯人”角色，他們穿上品質低劣的囚衣，并被關在牢房內。所有的參加者包括實驗者，僅花了一天的時間就完全進入了實驗。看守們開始變得十分粗魯，充滿敵意，他們還想出多種對付犯人的酷刑和體罰方法。犯人們垮了下來，要么變得無動于衷，要么開始了積極地反抗。用津巴多的話來說，在那里“現實和錯覺之間產生了混淆，角色扮演與自我認同也產生了混淆”。盡管實驗原先設計要進行兩周，但它不得不提前停止。“因為我們所看到的一切令人膽戰心驚。大多數人的確變成了‘犯人爺和‘看守爺，不再能夠清楚地區分角色扮演還是真正的自我。”

所以在項目中，我們需要首先從干系人的結構屬性上來分析這個人的基本心理特征。如果一個公司的信息部門負責實施公司的一個信息化項目，那么我們就可以從結構上來判斷這種結構下的矛盾。類似的結構和項目類型，我在不同領域，金融、保險、電信、化工等行業都遇見過，而最令我感到驚訝的是，項目中的人的心理特征幾乎一致，有的時候，連抱怨的話語都如出一轍。

信息中心的人：會常常抱怨這個項目影響到每個人的日常作業行為，而自己上層領導又授權不足，所以導致自己在項目中沒有太多的決定權，凡事要看業務部門的臉色行事。最頭疼的事情是在前期收集業務部門的需求的時候，業務部門的人往往找借口推托，不積極配合。而在項目進行過程中的時候又往往提出新的需求變更。尤其在項目快上線的時候，他們會提出更多的反對意見。

心理學應對：做項目的人，為了和這樣的甲方信息中心的人拉近關系，取得他們的理解和配合，要多和他們講為提高系統的穩定性、安全性以及可維護性你們所做的努力。還要多和他們講，你們是如何為了保護他們的信息化方面的投資而采用開放式結構，系統由可替換的插件組成等等。而在私下的時候，要適當地表示對他們在項目中的授權不足而惋惜。適當的時候，最好給他們帶一本你認為和這個項目相關的一本書，告訴他你從這本書上收獲很大，請他參考，或許有用。如果有可能，請你們公司的總裁在書上寫上一段推薦的話等。

千萬不要鼓吹你的項目包含了什么先進的管理思想，以及你們實施之后給原來的客戶帶來多少業務上的價值！

業務部門的人：他們會常常抱怨自己實在是太忙了，幾乎沒有時間來參與這個信息化項目。另外他們總會說信息部門的人不關心業務，不真正了解業務需求。還有以前使用的信息系統有多么不合理，總是出現各種BUG（缺陷、漏洞）。公司有的時候不能針對他們的實際情況來實施一套恰如其分的IT系統，真正幫到他們業務工作。

心理學應對：和他們交流的時候，一定要注意不要鼓吹你的系統的先進性，這是首要條件。接下來，你需要這樣講：我們的系統不敢說是最先進的，但是有一點我們可以肯定地說，我們在理解你們的業務需求上所花費的時間比其他公司的都多。另外，一定要記住，不論你實施了多少類似的項目，也無論他們的業務需求如何，你千萬不能說他們的業務流程其實很簡單。任何時候都需要記住一句話：“你們的業務是獨特的！”

同時，根據公司實際情況，可以邀請他們來做你們的業務顧問，進行業務指導。在系統上線時間允許的時候，你可以邀請里面有影響力的人來代替你們做內部講師，幫助你們給其他人培訓。當然了，你們需要單獨給他們先培訓一下。

2.項目干系人的心理特征分析

我們再來看看PMBOK給出的干系人的例子并分析這些干系人的基本心理學特征。

贊助者：項目中贊助者往往具有很大的影響力。為了取得贊助者的支持，最好利用責任分配矩陣等工具（RAM）明確地規定贊助者在整個項目中所起的作用。和贊助者溝通，不要過多流于細節，要根據他們的關注點進行匯報。因為贊助者看待項目往往從戰略的角度，更高的層面來看待。作為項目經理，要準確分析他們的關注點。

客戶和用戶：客戶付錢，用戶使用。一定要知道我們的項目最終的決策權在于客戶那里而不是用戶。而客戶的關注點和用戶的關注點也不盡一致。當客戶的意見和用戶的意見發生矛盾的時候，我們一定要清楚地認識到我們需要以客戶的意見為主。

客戶的關注點更多在于性價比上，他們會不斷地在自己付出和得到的成果之間做權衡。會想著有沒有可替代的方案。用戶的關注點更多在可交付的產品的使用是否方便，是否能夠支持自己的使用。某些情況下，客戶和用戶可以成為一個人，就是說客戶就是用戶。但是在其他情況下，客戶和用戶也可能需求完全相反。例如實施一個工作流管理系統，客戶可能是公司的高層管理者，他們需要掌握工作各個環節的實時信息，他們需要各個環節提高可視化，這樣便于監控。而用戶則希望有更大的自主權，也不希望自己的每一個行為都得到監控，他們往往對那些莫名其妙的報告節點忍無可忍。這種在采購這個環節上表現得尤為明顯。

供應商：對于供應商來說，我們相當于客戶。所以這個時候我們會具有客戶的心態，而供應商成了我們。如果你需要在項目中從外面采購的話，你可以體驗一下客戶的感受了。對于供應商來講，你要設置好監控點和底線。你的項目的壓力供應商不會感覺到，所以一個辦法就是把壓力想辦法傳達給供應商。讓他們感覺到時間的緊迫感。

業務合作伙伴：他們共同參與到這個項目，為甲方提供安裝、培訓等服務。記住他們在項目中的位置決定了他們會盡可能地推脫責任。他們最怕的是項目如果出現問題最后發現是他們的原因。知道他們的這個特點，你可以很好地利用了。

其他部門：簡單地說其他部門的人都傾向于認為你們的進度實在太慢了！

銷售部門：他們永遠會認為你們沒有很好地滿足用戶的需求，你們開發的產品進度也永遠在銷售期望值之下。他們討厭你們有了改動沒有及時和他們講，害得他們無法跟客戶解釋。他們常常奇怪，為什么別的公司很容易提供的功能我們公司卻要這么困難。他們還會抱怨項目組的人不夠配合，沒有提供有力的技術支持。

安裝部門：他們總是懷疑測試組的人有沒有認真測試。

職能經理：要記住他們看待問題的角度是從自己所在的部門的利益出發的，這和項目的根本利益有著很大區別。如人力資源部的人會對你們項目中的不遵守公司的作息時間的現象耿耿于懷。

高層經理：高層經理站在整個公司的角度，如何在高層經理那里為本項目爭取更多的支持是項目經理需要思考的任務。和高層經理匯報的時候要多用圖表，注意匯報關鍵節點和重大里程碑。他們最關心的是現在的項目整體情況和最終是否可以順利交付。所以你可以使用RAM來固定他們的參與，可以考慮用EVM圖來告訴他最直觀的項目進展情況。另一個關鍵點是，無論他們是否要求，項目經理都要養成定期匯報的習慣。

一定要注意，這些干系人和項目經理的關注點不一樣，而項目經理常常忽略這一點，以為自己頭疼的事情其他干系人也一定會頭疼，自己認為不重要的事情，其他干系人也會忽略。所以，交流的時候，一點要先想：他的關注點是什么？

第二節 組織結構心理學——結構本身就會帶來矛盾

要記住一句話：人品無關，結構使然！

項目組織有結構、有層次關系就會產生固有的矛盾。根據前面的論述，這種矛盾與人品無關，結構使然。

以前在培訓微軟解決方案框架（MSF）的時候，曾經多次在課堂上做過一個相同的活動，這個活動是這樣的：

每個小組按照下圖角色出5個人，只能按照下圖的箭頭所表示的途徑進行交流，這模擬了一種常見的分層級的組織結構。這5個人組成一個團隊和其他小組進行比賽，他們需要共同找出每個人手中都有的圖形，過程中不允許說話，最快的組獲勝。

每次做完這個活動之后，除了總結項目中應該如何進行溝通之外，我還要求他們討論組員的行為還有哪些可以改進。最后我把各個組的改進建議收集上來，按照角色進行分類。結果一個有趣的現象出現了。

我驚訝地發現，每個角色所抱怨其他組員的內容幾乎一樣。這個活動在不同的課堂上進行，而不同的課堂的抱怨也幾乎一致。

A角色的人總是抱怨：

（1）為什么這么簡單的事情你們用了這么長時間？

（2）能不能提高一下你們的執行力。

（3）最好充分理解我的指示，不要自以為是。

（4）你們發生什么了我根本不知道，有問題了也不跟我說，直到最后無法交差了我才知道。

C、D、E角色的人總是抱怨：

（1）到底發生了什么？

（2）上面到底要做什么他們自己知道嗎？

（3）我的意見從來得不到上面的尊重，最后證明，我的意見是正確的。

（4）在這樣的小組真是壓抑。

（5）能不能先想好了要做什么再讓我們做，不要中途老是變。

B角色總是抱怨：

（1）我很忙，壓力很大。

（2）底線要到了，壓力很大。

（3）下面的人總是抱怨我，壓力很大。

（4）上面的人總是催我，壓力很大。

（5）我很忙。

不用問，B就是那個苦命的項目經理，他很忙，壓力很大，在上下的夾擊下成了“三明治”。

這個活動充分證明了組織結構對項目成員會產生比較一致的影響，這種影響也會讓他們傾向于產生相同的心理狀態。所以說，這些心理狀態就是我前面說到的人品無關，結構使然。這種矛盾的結構注定了這種矛盾也會一直存在下去。

一定要注意“人品無關”這句話，因為在課堂上，做完這個活動之后，幾乎沒有人會認為他們的抱怨的根源主要來自于這種層次結構，他們都會特別自信地說，如果那個某某角色可以改進一下他們工作態度或者習慣，我們會完成得更好。還有一種傾向就是試圖用技術手段來徹底解決結構問題，比如說，一直到課程結束之后仍然有學員爭論，如果采用畫圖方法就可以完全克服這個層次結構帶來的弊端。他其實沒有想到，即使采用所有組員都畫圖的方法，那么如何讓每個人都充分了解需要采用這種方法并且正確地實施下去的過程中，產生的抱怨絕對不會比完成任務本身所產生的抱怨少。

如何解決這種結構矛盾？有一種觀點就是優化流程，明確各個流程節點的績效，明確每個人的職責。這些的確可以緩解一部分矛盾，但是不可能真正化解。就像前面說到的那個木桶，那種“重力場”的作用還在，這些流程和規定只是在通過消耗能量來維持一種平衡。如果沒有木桶的晃動，也就是沒有項目中的各種困難、人員的約束、里程碑底線的壓力、資金的緊張以及需求的不斷變更等，那么木桶中的粒子是平衡的。但是如果木桶開始晃動，那么在這個重力場的作用下，粒子就會逐漸克服那些能量的束縛，走向自己的位置。表現在項目組的人員身上，就是產生幾乎一致的心理特征。

流程不行，徹底消除這種矛盾，只能改結構了。但是也不要忘了，不同的組織結構會帶來不同的矛盾。有的時候我們用更大的矛盾來解決當前的矛盾的做法會讓我們深受其害。

關于這點，微軟的MSF做了很好的嘗試，那就是創造出了一種沒有層級關系的項目組織結構。

MSF將一個項目中不同階段的工作人員分為六個角色，通過這六個角色，項目可以迅速、完善地實施。這也體現了項目開發的六個重要質量指標，它們在全球是一致的。這六個角色分別是：

（1）產品管理（product management）。他了解用戶特征，尤其是商業特征，明確用戶的需求以及需求的期望值。之所以強調用戶需求的期望值，是因為用戶的商業化特征比較強，需求無盡，無法界定到底如何才算需求得到了滿足。而確定了需求期望值后，用戶的商業目的就非常明確，實施起來也比較順暢。

（2）程序管理（program management）。他負責制訂計劃，每天找出完成該計劃的風險所在，排除風險，每天交付應該完成的內容，確保計劃按質、按量實施。

（3）用戶體驗（user experience）。設計友好的用戶界面，對用戶進行培訓，確保用戶能夠、并且愿意和喜歡使用開發出的產品。開發者在開發前期就參與用戶需求分析和項目計劃制定，他最清楚具體的開發過程。在開發期開始后，他負責進行代碼開發，在每一個階段，交付每一項內容的代碼。

（4）開發（development）。根據規格說明書創建解決方案。

（5）測試（test）。負責開發出的代碼的測試。測試者并不是要找到每一個開發者的每一段代碼的每一個錯誤（BUG），而是要找到代碼錯誤之間的關系，解決最根本的錯誤，掌握錯誤的狀態，從而迅速排除錯誤。

（6）發布管理（release management）。發布管理人員負責將實驗室的產品商品化，變成實際可以運行的產品，達到最初制定的商業目的，取得商業效益。這項工作在以往的項目中可能比較簡單，因為實驗室的環境可能和實際環境幾乎一致或差別不大。而現在卻不同了，實驗室環境可能十分簡單，而實際環境可能非常復雜，比如分布式環境、Internet/Intranet環境等，尤其是大企業，實際環境比實驗室環境復雜得多，因而將實驗室產品運用到實際環境中是一項非常重要的工作。這項工作沒有完成好，往往使整個項目前功盡棄，功虧一簣。

在此基礎上，項目團隊沒有真正的領導，程序管理人員的角色和項目經理的角色的最大區別是他更傾向于提供這些管理的服務給其他角色成員。那么，誰負責指揮項目組其他成員呢？答案就是輪流坐莊。在項目的不同階段，由不同角色的人來領導項目團隊，推動項目。

這種組織結構，伴隨著微軟的成長，逐步完善和發展，加上明細的項目生命周期階段的劃分，構成了MSF的基石。它克服了層級結構產生的各種抱怨和效率低下，有利于促進組員之間進行很好的溝通。同時，加上MSF團隊的理念：人人為我，我為人人。提倡為其他項目成員提供貢獻和幫助，大家共同完成任務。這種結構，鼓勵共享，鼓勵溝通，具有十分旺盛的生命力。

那么，既然有了微軟的親自實踐，消除了層級，明確了階段及任務，鼓勵共享和溝通，這種組織結構就是完美的組織結構了嗎？答案還是那個成為管理大師的經典答案：“不一定！”

這些都是在沒有變更（木桶的晃動）的假設下存在的，如果項目進行得特別順利，那么這種結構的確沒有什么問題。但是項目是不可能不產生問題的。如果項目產生了問題，那么這種結構也會暴露出自身的結構矛盾，例如各個項目成員會把責任推給上游成員，上游成員傾向于認為下游成員的能力不足等等。而這些也正好是作者在調查使用了MSF這種做法的安徽省某個電子政務項目所得出的結論。

接下來我們再分析一下PMBOK中所提到的三種組織結構類型。