本文為轉載，原文作者地址已忘記了(版權歸作者所有)。
wp轉入hexo，本筆記初次記錄日期為2014-10-19 21:19:25

本文目錄：

項目實戰(zhàn)筆記之一：高效會議的組織方法

項目實戰(zhàn)筆記之二：風險管理

項目實戰(zhàn)筆記之三：時間估算的三步曲

項目實戰(zhàn)筆記之四：團隊建設(尊重)

項目實戰(zhàn)筆記之五：里程碑管理

項目實戰(zhàn)筆記之六：團隊建設的三種境界

1. 項目實戰(zhàn)筆記之一：高效會議的組織方法

關于開會大家應該都不陌生，而且應該有不少人被過度頻繁的會議“傷過”，甚至”談會色變“ 。當一個組織的人員較多，結構復雜時這個問題會更加突出。如果開發(fā)人員/測試人員參加會議過多，會導致工作打斷嚴重，直接影響到團隊工作效率。如果管理人員參加會議過多，就會導致管理人員離開所負責的管轄范圍時間較長，不能及時響應事情，從而導致團隊整體管理效率變低，典型表現(xiàn)是很多事情沒有及時處理、開始積壓。

當然會議是需要的，主要是我們要總結出一套高效的方法。下面分享一些總結，有興趣的同事可以一起探討。

1.1. 第一，確認會議類型及目的

我認為在我們公司的研發(fā)體系里以會議目的劃分，會議大體可以分為以下6種：

團隊建設：激勵團隊，培養(yǎng)員工的團隊意識，讓每個參與人員了解共同的目標，樹立全局觀念，無形中能夠幫助團隊減少協(xié)調成本。 例如：版本項目周會。

報告績效：向上級管理層匯告版本當前績效情況，并且根據(jù)需要可以獲得適當?shù)馁Y源支持，例如：RDM的項目分析會議。

平級溝通：針對問題通過會議討論形成解決方法或是達成處理協(xié)議. 例如：開發(fā)和測試周會，跨部門合作會議。

信息傳達：將信息傳達出來，讓相關人得到信息并理解信息，以方便進行下一階段的工作。例如：新流程培訓會議，經驗分享會議。

創(chuàng)意開發(fā)：針對某一個問題的解決方案或是某個方向的創(chuàng)新主題進行討論。

評審會議：技術方案/需求文檔評審，疑難問題討論等確定好會議類型及目標之后才能選定出需要討論哪些內容，匯報哪些信息，以何種方式組織。

這里舉個示例：

示例：一個項目組對RDM做績效匯報(項目分析會)。我們首先確定會議目標為：
a. 向RDM提供版本總體計劃情況，當前進展，當前存在風險及計劃應對措施，趨勢預測等
b. 申請關鍵資源支持，因為RDM聽過完整匯報時，對版本有了比較系統(tǒng)的判斷，此時如果確實需要資源協(xié)助，比較容易得到批準
確定目標后，我們就可以發(fā)現(xiàn)開發(fā)和測試在這里是被作為一個團隊看待的，因此在這個會議過程中開發(fā)和測試的意見應該是一致的，并且匯報的內容不能重復，但可以各有側重。
因此會議前開發(fā)和測試應該進行明確的匯報分工，各自總結完后，內部討論得出一致結論?；谶@樣定位而組織的項目分析會，就會非常高效，并且能夠在短時間內將版本整體情況展現(xiàn)出來，同時也促進了開發(fā)和測試內部一次完整性總結。而如果沒有這些前期工作，項目分析會過程中，開發(fā)和測試意見就可能非常不符，甚至進行爭吵，更嚴重的是發(fā)生互相責怪，推卸責任的情況。
確定目標后，我們就可以發(fā)現(xiàn)開發(fā)和測試在這里是被作為一個團隊看待的，因此在這個會議過程中開發(fā)和測試的意見應該是一致的，并且匯報的內容不能重復，但可以各有側重。因此會議前開發(fā)和測試應該進行明確的匯報分工，各自總結完后，內部討論得出一致結論。基于這樣定位而組織的項目分析會，就會非常高效，并且能夠在短時間內將版本整體情況展現(xiàn)出來，同時也促進了開發(fā)和測試內部一次完整性總結。而如果沒有這些前期工作，項目分析會過程中，開發(fā)和測試意見就可能非常不符，甚至進行爭吵，更嚴重的是發(fā)生互相責怪，推卸責任的情況。

1.2. 第二，開有準備的會議

有準備的會議需具備以下三個特點:

有清晰的會議歷程及會議預期
例如：大多數(shù)開發(fā)和測試的例行溝通會議，是以明確問題及達成協(xié)議為主，而不是解決具體的某個問題，如果過于深入會導致時間浪費，更嚴重的是隨意決策。

選擇合適的人參與
會議召開前需確定好哪些人要必須要出席，哪些人得到討論結果告知即可。將會議控制在必要范圍里的好處在于，避免會議浪費其他人員時間，同時保證會議的發(fā)言質量。

選擇合適的時機
合適的時機是指要評估與會人員的時間繁忙程度、解決問題的條件是否成熟，這個時間開會的效果如何？例如：項目進度非常緊張的情況下，項目組每周舉行耗時很長的個人知識及讀書經驗分享是不合事宜的。

1.3. 第三，議而有決，決而有行，行而有果

從結果導向來看，會議都是基于某種目標而召開的，因此達成預定目標是非常重要的，會議過程中，組織者要進行有效的時間控制，出現(xiàn)跑題情況時要及時引導糾正，防止參會人員天馬星空或過于深入細節(jié)，浪費大量時間。這個過程可以簡稱為議而有決。

決而有行是指，會議討論出的決策要形成任務分解，并落實責任人。行而有果是指，已經分解的任務要進行跟蹤，產出效果。

第三點總結起來比較簡單，但是往往是我們最難以落實的地方，所以經常會出現(xiàn)諸如“這個問題，我們好像上次討論過”的這類情況。

其他一些小技巧羅列如下：

大會之前通常要有小會，從而達成高效

會議開始前先講解會議歷程及預期

會議上以明確問題、達成協(xié)議為主，不深入問題討論

會議上的決策直接指派落實責任人

會議記錄要在24小時內發(fā)出，最晚48小時之內

對于例行會議，可以收集參會人員的會議質量反饋，進行持續(xù)改進

2. 項目實戰(zhàn)筆記之二：風險管理

風險管理是項目經理必備的硬功夫之一。風險管理貫穿于整個項目生命周期。根據(jù)風險的狀態(tài)劃分，可以將風險分為兩個階段：風險發(fā)生前，風險發(fā)生后。在不同的階段里，需要我們使用不同的技能。

2.1. 一、風險發(fā)生前

2.1.1. (一)關注風險效用函數(shù)

由于風險決策者的個人偏好、價值觀和背景不同，不同的決策者對于同一風險事件會做出不同的決策，這種現(xiàn)象被稱為風險態(tài)度，傳統(tǒng)的效用的理論被廣泛應用于分析決策的風險態(tài)度。根據(jù)效用理論，風險態(tài)度分為三種：

厭惡型：對風險極其敏感，要求在前期消除所有不確定性，會帶來一定的成本浪費，中后期的版本風險將會遞減或持平。

愛好型：喜歡挑戰(zhàn)困難，自信滿滿，對風險神經大條，識別不出風險，通常版本風險在中后期會出現(xiàn)持續(xù)遞增。

中性：隨著項目的進展，問題的暴露對風險的態(tài)度隨之加以變化，典型表現(xiàn)為前期對風險不關注，版本進展到中后期對版本風險投入更多關注。

因為風險管理是由人來執(zhí)行的，執(zhí)行人本身的偏好，將很大程度上影響到風險識別的敏感度及風險的應對方法。項目經理可以在以下兩方面中使用風險效用函數(shù)：

了解公司對風險持有的通用態(tài)度及對本項目持有的特有態(tài)度，并且明確風險上報的標準。

根據(jù)自己的風險偏好，結合項目的特點，尋找合適的管理搭檔或組建管理團隊(通常這件事應該由上級領導決定，但是我們可以反向影響領導的決策。這是作為優(yōu)秀的項目經理都應該具備的能力)。

2.1.2. (二)識別風險

風險管理中強調的一個觀念：無法識別的風險是無法預防的。因此識別風險是風險管理的一個核心。識別風險需要做好以下兩點：

1. 整體性的全局分析，識別出關鍵風險

就像將軍通過沙盤推演把握戰(zhàn)事一樣，項目經理需要對項目做整體性的沙盤計劃，部署優(yōu)勢兵力在關鍵風險處，降低版本失敗概率。以結果導向的角度來看項目，通常組織或客戶對項目的期望是“cheaper，faster，better”。根據(jù)這三點，我們得出項目的制約三角形：

加上項目團隊是由人組成的，全局性分析風險可以從以下五方面進行：

從范圍角度：當前項目是存在清晰的需求，需求是否復雜，市場定位是否明確等。從成本角度：項目的預算是多少，風險儲備金是多少，是否充裕？從時間角度：工期要求是不是限定的，是不是簽署了相關合同，進度和計劃的可跟進性等從質量角度：當前的技術方案是否存在風險，預研是否充分，人員的經驗是否充足從人力角度：人力組成是否充分，關鍵人力是否得到保證，是否存在不可替代的人員等

2. 保證信息的透明性，發(fā)揮群體力量

除了敏感的信息外，項目經理應該盡量保證項目相關信息的透明性。信息透明可以從兩方面來描述：

項目經理要將自己對版本的整體性分析、風險分析、趨勢預測等信息告知團隊，并獲得共識。

建立相對獨立團隊間的溝通機制(例如：開發(fā)團隊、測試團隊、規(guī)劃團隊)。

信息透明化的好處在于，能夠培養(yǎng)團隊成員的風險意識、團隊歸屬感，從而能夠對管理人員的風險識別起到正向的糾正及補漏作用，而且能夠讓整個項目上下同欲，達成統(tǒng)一認識，對風險的應對方法減少抵觸情緒。

風險識別應該貫穿于項目的整個過程。識別出的風險可以登記在風險登記冊或風險管理表上。

2.1.3. (三)定期評估風險狀態(tài)

風險狀態(tài)通常包括這三點：風險發(fā)生的概率，風險發(fā)生的影響，風險的優(yōu)先級。緊急不重要的工作因為時間的限制，通常優(yōu)先級會被夸大。因此如果沒有定期評估風險的機制，項目經理容易被當前緊急事情所驅動，難以集中精力處理重要的事情。定期評估風險的意義便在于跟蹤風險變化的趨勢，幫助版本經理集中精力處理高優(yōu)先級的工作，從而保證項目的成功率。這里可以參考使用概率影響矩陣。

2.2. 二、風險發(fā)生后

2.2.1. (一)資源協(xié)調，解決問題

風險發(fā)生代表風險已經轉化為版本的實際問題，需要我們立刻進行解決。由于風險的存在及其不確定性的特點，通常在版本計劃中版本經理會預留應急儲備。應急儲備可以用資金，+時間來進行衡量。這種情況下，我們需要評估應急儲備是否能夠消化該問題，如果不能消化，則需要采用變更進度計劃，申請資源支持，或者加班趕工的方式來挽救項目。一個計劃管理和風險管理意識不強的項目經理所負責的項目，通常會有”進度前松后緊，質量前面是太平盛世，后面是水深火熱“的現(xiàn)象。

2.2.2. (二)持續(xù)做經驗總結

聰明的人會從自己的經歷中學習，智慧的人會從別人的經歷中學習，沒有反思，沒有總結，就沒有成長。風險管理是一項尤其依賴于個人能力及經驗的過程組。只有我們不斷反思、總結和別人交流，才能快速積累起這方面的經驗。

3. 項目實戰(zhàn)筆記之三：時間估算的三步曲

項目績效的重要衡量指標之一便是時間，這里總結下親身經歷的三步曲

3.1. 第一個階段

項目經理簡單估算+倒推+部門預備機動人員

優(yōu)點：估算速度非?？?很多時候，項目計劃都是從上級給的發(fā)布時間倒推出里程碑)缺點：計劃非常不準，項目成功率不高。主要原因是：

項目經理個人思維限制考慮事情不可能百分之百周全，尤其遇到新的項目經理，項目成功的幾率更是直線下降。

部門的人員總是要干活的，當項目發(fā)生風險時，原計劃的機動人員總是不夠用，或是不能停下手頭的事投入項目中，如果遇到多個項目同時需要機動人員支援時，整體部門基本要全線加班，集體奮斗了。

項目組成員參與度不夠，如果工作加班，有一定怨言

總體來說：還好每當這時候項目經理都能身先士卒加班，這時候部門的同事都是難兄難弟，總是很辛苦，但是項目結果總是不理想，不能按期交付。

3.1.1. 第二個階段

公司級形成估算團隊做專家估算

為了改進估算，同時保證各部門績效的公平性，公司針對A部門的項目會找其他的部門的專家參與估算，估算使用3點發(fā)計算出版本時間點，如果某個專家估算的不 準，則要求重新估算或當面討論，最終取得一致后將成為項目發(fā)布的績效點.

優(yōu)點：相對公平，有一定信服力缺點：

容易出現(xiàn)扯皮現(xiàn)象，項目估算時間很長，并且外部估算的時間計劃難以轉化為內部計劃，工作量浪費很大

專家質量與主動參與度難以保證，尤其是參加多次估算后，專家容易倦怠

公司不關注人員分配，不考慮具體項目的最長路徑，計算時間公式為：工作量/人力=項目時間

項目組成員參與度不夠，如果工作加班，有一定怨言

總體來說：公司級的估算是CMMI引進到公司的，起到了很大作用，但是一定程度上造成了公司級的RDM組織和部門的對立，能力強的項目經理能夠做很多線下活動，從而得到自己的績效時間期望。

3.1.2. 第三個階段

部門自下向上估算+專家指導

其實第二個階段和第三個階段在一定程度上是有重疊的，第二階段中，有一些先知先覺的項目經理，在公司開始進行估算前，首先進行了內部自下向上的估算，這樣自己知道了自己的底限，如果有關鍵路徑消除不掉，則要在總工作量加大，以達成自己的預期.

第三階段主要的特點是項目估算以部門及項目為主導，當出現(xiàn)關鍵路徑后，部門或公司專家?guī)椭?#xff0c;如果消除不了，以項目估算為準做績效點。

優(yōu)點：

能夠保證信服力

鼓勵項目經理一開始把版本事情考慮周全，如果項目計劃可行性非常高

全體項目人員參與的估算，更加準確，并且成員愿意為自己估算的時間負責

RDM和部門關系形成互助關系

估算結束后，直接產出可執(zhí)行的項目計劃

缺點：

估算周期稍長，通常需求基線后1-2周能給出

總體來說：這種方法是我個人最推崇的方法，能夠有效提高員工的參與度及估算的準確度，同時維持組織的互助性，對版本成功非常有幫助。

4. 項目實戰(zhàn)筆記之四：團隊建設(尊重)

知識型工作者只有讓他們感到被尊重，被認可才能激發(fā)出他們的工作熱情。制造業(yè)工廠監(jiān)工式的管理方法，絕對量化的考核指標在知識型團隊管理中將會失效，這是管理人員面臨的挑戰(zhàn)，德魯克也在《卓有成效的管理者》中對管理者和這種監(jiān)工做了明確區(qū)分，其中的觀點是監(jiān)工是上司，但不是管理者。

一個抱著積極、認真負責，打拼事業(yè)心態(tài)的員工做事的有效產出和機械完成任務的人員的有效產出是多么的不對等，這里不需要再列舉各類研究結果。尊重是激勵文化構建的基石，如果沒有尊重，激勵就是空中樓閣亦或是短暫的激情。本篇筆記重點談談在項目管理過程中對如何給予員工足夠的尊重。

4.1. 1、項目的意義

成就感是讓團隊努力向前的最好激勵方案，任何項目的成立都是有意義的，如果能夠讓整個項目團隊時刻清晰的認識到自己是再做一件對部門、乃至對公司意義重大的事，則往往能夠煥發(fā)出團隊很強的戰(zhàn)斗力。受到關注就會給人被看重感，人就感覺到要對事情付更多的責任。

推薦策略：

項目啟動時，高層領導進行動員，宣傳項目意義

項目中期，規(guī)劃負責人/項目經理要能定期發(fā)出一些市場人員/客戶對項目的期望

項目結束后，高層領導要能夠反饋項目獲得的成績

4.2. 2、項目時間估算

我個人比較推崇的估算方法是自下向上的估算(具體可以上篇文章：時間估算的三步曲)，自下向上的估算能夠給予項目組員一定的發(fā)言權及主人翁感，并且能夠調動大家責任心，通常大家愿意為自己的決定負責，但是如果是領導直接壓下來的任務尤其比較緊急時，通常有些抵觸。當然在自下向上的估算中，要有專家進行指導和把關，包括估算漏掉的哪些事情，項目組內例行需要消耗的時間等，并且針對”獅子大開口“的時間需要進行討論，達成一致。

在這種估算方法做出的項目計劃下，如果項目最后出現(xiàn)了問題，盡管項目經理要承擔直接責任，但是項目團隊成員通常會比較自主的愿意與團隊共度難關。因為決策是大家一起制定出來的。

推薦策略：

盡量使用自下向上+專家指導的方法進行估算，如果有人員到位或者估算周期的有限制，至少要保證關鍵人員的參與，而慎用自上向下的估算方法.**

4.3. 3、善用加班文化

IT公司加班是件很自然的事情，如果哪家公司沒有加班情況，反而會讓人感覺不正常。做為項目經理應該首先理解，加班雖然是IT公司的普遍現(xiàn)象，但是確實是組員為了項目做出了額外的奉獻，他們犧牲與家人團聚的時間，犧牲了休息時間，甚至影響了健康。這種行為值得我們尊重，我們要小心使用這項權力。

不要動不動就拋出一句“這個今天搞不定，就打地鋪解決”等，這種言論是對員工額外奉獻的一個嚴重的漠視，而且?guī)е軓姷膫€人意愿

時時保證項目的進展的透明性，可以通過周會，日報的形式在團隊中發(fā)布。當遇到趕工時，跟當事人講解當前團隊面臨的困難，總之，加班是個艱難的決定，是為了整個團隊的績效，不是項目經理的個人意愿

任何加班時項目經理都應該盡量身先士卒帶隊

在一些公共場合，尤其有上級領導在時，公開表揚那些為團隊做出很多額外貢獻的人

績效考核肯定以結果為導向，不能以加班多少論英雄，但要有其他措施安慰最辛苦的人

推薦策略：

加班是一種奉獻精神，我們要小心使用，認真對待。不能簡單的當做管理者的權力，輕言肆用，否則久之必招其離心

4.4. 4、開放溝通的團隊氛圍

人都希望自己能夠有發(fā)言權，能夠對關心的事情產生影響。上至國家領導人的選舉，下至日常的工作生活。如果發(fā)言權被長期壓制，就會產生壓抑和叛逆的心理。因此構建一個具有開放溝通的團隊氛圍則顯得很重要。而往往言路開明后，項目經理總是能在一些討論中，得到很多比預期更好的解決問題的方案。一個強權的管理者，容易獲得一定程度上的執(zhí)行力，但是容易被自己的盲點擊敗。而一個開明的管理者，往往能使用集體智慧，獲得跟隨者，更容易產生威望。

推薦策略：

項目沙盤等關鍵策略制定時，要全體項目參與討論

項目經理鼓勵大家發(fā)現(xiàn)問題，提問問題，對于好的措施，能夠采納執(zhí)行

4.5. 5、責任到戶 VS 大鍋飯

從頭到尾的責任到戶制應該是最理想的工作分配方式了，在這種分配方式下，團隊成員有一塊自己土地，通常愿意花更多的時間與精力去耕耘(例如：某個全新的模塊)，如果這個模塊又是他一直想嘗試的方面，那將會更加完美，我們有理由相信他將會在這里充滿了激情。

然而世界上總沒有十全十美的事情及百分百通用的方案，盡管責任到戶制如此之好，但是在某些項目上我們達成不了這樣的期望。

我所親身經歷過的兩個版本就遇到了這樣的狀況。兩個版本的共性是：在一個很大的系統(tǒng)上做覆蓋面很大的，很多小點的修改(例如：更換所有UI系統(tǒng))，但是基于老系統(tǒng)的復雜性及歷史問題，項目在中會遇到很多bug，各種各樣，在bug沒有查到原因之前并不好確定這個問題誰改動引發(fā)或是誰的責任，這種情況下責任到戶制會出現(xiàn)失效。在面對系統(tǒng)這么多的bug時，項目經理很容易想到一種方法：“那就是給大家分配bug數(shù)，下指標，每天每人要解決3-4bug等”。兩次項目經歷中，項目經理確實都想到了這種方法，區(qū)別是前者實施了，后者被我阻止了。原因如下：

團隊組員容易產生不被尊重感，被當成解決問題的機器

團隊之間的協(xié)作會發(fā)生困難，而且過度強調這項指標，例如誰每天不修改完這個bug數(shù)，就要加班到10:00之類的，會導致部分組員開始取巧，每天爭搶容易處理的bug

沒法發(fā)揮人的主動性，將團隊目標和個人目標相背離

這種情況下大鍋飯的機制似乎更合適一些，如果團隊沒有達成目標則需要一起想辦法或加班解決，而不是將這人歸咎個某個人。

推薦策略：

在正常項目中盡量使用責任到戶制，而對于一些特殊項目，則選用大鍋飯制，沒有一成不變的方案，具體情況具體變通。

5. 項目實戰(zhàn)筆記之五：里程碑管理

5.1. 一、背景

由于公司及部門的發(fā)展，項目經理已經開始面對人數(shù)眾多，時間跨度較長的版本管理挑戰(zhàn)。

如張湘輝(1994年加盟微軟，現(xiàn)任微軟大中華區(qū)CTO)所說：

以Windows 7為例，包含七八千萬條甚至上億條代碼，五六千人同時開發(fā)，還有很多合作伙伴確保周邊產品兼容。對這樣一個超大的項目而言，不能一眼盯到結果，不能像跑百米一樣，始終盯著終點。我們的經驗是盯終點肯定亂，因為要經歷非常漫長的過程。

從心理上說，當發(fā)現(xiàn)離終點還很遙遠時，人就會泄氣，不能以那么快的速度玩命跑下去。最好的方式，是將事情分成很多步驟來做。Windows7從開始到完成可能要耗時兩年，以兩年時間為一個周期，那么前六個月團隊就會被弄垮，所以你必須以也許每兩個月為一個終點。就像跑一千五百米，我們要考慮第一圈跑多快，第二圈跑多快。

這就需要把每個終點區(qū)分得很好，設定有效的里程碑，在邏輯上要很精準，是不是到了這個里程碑，同樣要非常清楚。這樣每個里程碑達到時，大家可以慶祝一下，重又奔向下個目標。如同爬珠穆朗瑪峰，沒有說不斷爬上去，而是先到大本營，再到第幾個營地，最后才能登頂。

從過去的3.0，BM2.0等較長時間的版本管理中，能夠看出我們的里程碑管理做得并不好。以前的里程碑就是一些項目關鍵時間點的劃分，例如：轉測試，轉聯(lián)調等，項目組在里程碑處的行為基本就是核實是否滿足進入下個階段的標準，滿足則進入?？傮w來說項目還是以最終發(fā)布時間點為目標，這樣非常容易導致團隊的疲憊。因此結合部門歷史經驗和其他公司的做法，產出里程碑管理的概念。

5.2. 二、目的

里程碑管理目的是解決時間跨度較長或任務比較艱巨的版本管理問題。里程碑管理期望可以達到以下4個效果：

使團隊將長期目標劃分為不同的短期目標，就像跑長跑一樣，不是以5W米為目標，而是把目標分解到每一圈

在里程碑處，團隊進行有效的休整。就像隊伍打仗時，一定要有休整，才能持續(xù)保證旺盛的戰(zhàn)斗力

促使組員進行上個階段的總結，找出自己的不足，并吸取其他人的優(yōu)點，從而讓組員進行成長

整理下個階段的工作思路，促進大家進行整體思考，并對模塊進行全面分析。

5.3. 三、具體內容

給予項目組時間，進行全員總結，包括上個階段的總結，下個階段的工作思路，做成PPT

由每個人在會議上將自己的總結PPT進行分享 (做成ppt并在項目會議上進行分析，會引起大家的重視，自然效果會好)

進行表彰，表彰做得好的人員，由主管親自頒發(fā)獎品(結合獎勵措施)

用本小組經費進行歡慶，吃飯+KTV之類

5.4. 四、計劃支持

項目計劃中安排好總結時間

制定里程碑獎勵措施，并且在上個里程碑點處進行宣傳，過程中進行相關數(shù)據(jù)統(tǒng)計

向公司提前申請所需的時間和金錢資源

6. 項目實戰(zhàn)筆記之六：團隊建設的三種境界

經過自己總結和項目經理們探討，認為項目或部門團隊建設可分為三個等級：

6.1. 一、烏合之眾，強權政治(新手)

很多新手都會經歷這樣的過程，新組建的團隊沖突不斷，大家對當各種制度措施，報以反感。為保證執(zhí)行力和項目成功，項目經理會選擇強權壓制，尤其是技術比較好的項目經理。大抵的邏輯是“我是老大并且我資深，要聽我的”。最終的結果是大家對項目目標已經完全不感興趣，一些沖突升級到個人情感沖突，項目經理左右突擊，上躥下跳，甚是辛苦，忙碌，確得不到大家的認可。

此時的項目經理至少需要做到兩點，才有可能進入下個階段，用杰克韋爾奇的兩句話概況：

“在你成為領導以前，成功只同自己的成長有關。當你成為領導以后，成功都同別人的成長有關。”

“世界上的每一個人都想得到發(fā)言權和尊嚴，而且也應當?shù)玫健?/li>

所謂“發(fā)言權”，是指人們希望有機會說出他們的思想，擁有自己的觀點、看法、獲得被傾聽的感受，無論他們的國籍、性別、年齡或者文化背景如何。

所謂“尊嚴”，是指人們本能地和自發(fā)地希望由于自己的工作、努力和個性而得到尊重。

這個階段之所以命名為烏合之眾，是因為大家對團隊根本沒有歸屬感，甚至厭棄團隊，期望團隊得到解散，或者團隊目標達成時，并沒有取得成就的感覺，而是有終于熬過來的感觸。

6.2. 二、尊重，民主社會 (老手)

在經歷過挫折或是老前輩們的諄諄教導后，新手往往都能進入這個階段。當然有些厲害的人有時也會自己跳到這個階段。但是這個階段里的人，也有高下之分。在這個階段的人，往往可以帶團隊時，往往可以做到：

6.2.1. 尊重，言路開明

不把人當做機器。制定計劃，措施時，都可以征求的大家意見，當然計劃定下來后，執(zhí)行時是不能含糊的。

6.2.2. 善用人才，培養(yǎng)人才

團隊里有人才時，會使用授權等方式調用這些人的積極性，而不是幼稚的打壓，并且在團隊里沒有人才時，能夠積極選拔備選人員，并給予鍛煉機會

6.2.3. 分享榮譽

這個階段的項目經理，在交流中，會擯棄掉“我怎么樣，怎么樣”，多使用“我們，我們團隊怎么樣”，尤其是在面對表揚和榮譽時。在項目組內也想方設法樹立榜樣，并且非常愿意這些人被自己的上級所獲知，愿意為這些人謀個好前程。

6.2.4. 坦誠

坦誠是相處的長遠之計，而忽悠，畫大餅這些手段只能短期效應，并在長期上讓自己的人格受損。關于這點項目經理大多做得程度不一，有時說出一些不開心的事，是需要勇氣的，例如在績效溝通時。但是這個階段的項目經理都了解它重要性。

6.2.5. 團隊信息透明

只有信息足夠透明，大家才能夠為項目出謀劃策，才能有坦誠溝通的基礎，大家才能對項目歸屬?！皦艛嘈畔?#xff0c;以顯示自己領導的地位”是愚蠢的人才會干的事情

這個階段之所以命名為民主社會，這個階段的價值觀是：民主計劃，嚴格執(zhí)行，有付出有回報，集體榮譽。第一個階段到第二個階段可能需要時間的積累，而第二個階段到第三個階段，有時卻可望而不可達。

6.3. 三、激情，燃燒軍團 (高手)

激情團隊的充分必要前提是，團隊負責人是非常有激情的。這點很關鍵，一個打工者心態(tài)，沒有把工作當成自己事業(yè)經營的人是不會帶出有長久激情的團隊。檢視的原理：“看一下大家是不是為了同一個夢想而走到一起的”

要達成團隊激情，至少具備以下幾點：

老板風格，老板要有分享成功的決心，例如：股票，期權激勵

企業(yè)文化，企業(yè)要有文化宣揚集體奮斗的精神，企業(yè)的使命價值觀能夠深入人心，得到強烈響應，此時企業(yè)的創(chuàng)新精神，將是從內而外的，從下而上的，大家集體思考，集體進步，集體創(chuàng)新。

有激情的中層，公司中層是企業(yè)的中流砥柱，如果每個中層是有激情的，擴散開來的影響力是很大的，反之，則激情容易變成口號。

這里典型的案例是sony的沒落，從井深大的激情軍團的消失，井深大倡導”工作保證本身就是一種強有力的激勵“，把這種理念能夠深植公司是多么可怕，激情可以創(chuàng)造出很多奇跡。

約翰·科特說過“如果你想建造一艘船，首先要做的不是去采集木材、加工木板和分派工作，而應該去喚起人們對廣闊無垠大海的向往?！?管理者的本質是獲得追隨的人，一個企業(yè)，一個團隊如果能夠擁有一批愿意追隨公司成長的人，所產生的正向能量是無比巨大的。

這種境界的達到需要多方因素的促合，頗似于武俠里的天人合一，激情團隊的管理將十分簡單，保護這種激情，員工會很自主的進行自我管理。

當然實際工作中，以上每個階段不孤立存在，可能會存在一些階段的中間體。

總結

以上是生活随笔為你收集整理的转载-项目实战笔记的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。