本章內容提綱

8.1 軟體專案團隊管理概述
8.2 專案組織的規劃
8.3 團隊人員獲取
8.4 團隊建設和日常管理
8.5 溝通管理
8.6 軟體專業人員的非技術素養

8.1 軟體專案團隊管理概述

• 什麼是軟體專案團隊？

    軟體專案團隊是由軟體專案的不同干係人所組成的，具有共同目標、緊密協作的集體。

• 軟體專案團隊包括所有專案干係人：專案發起人、資助者、專案組（開發團隊）、供應商、客戶等。

• 有時，軟體專案團隊特指專案組（開發團隊）。

軟體專案團隊的特點           

• 與一般的人力資源相比，軟體專案團隊的特點是：

臨時性；
團隊成員的不穩定性；
年輕化程度較高；
是高度集中的知識型團隊；
成員的業績不易量化考核。

什麼是軟體專案團隊管理

• 美國的專案管理協會（PMI）的《專案管理知識體系指南》（PMBOK）對“專案人力資源管理”有如下定義：

• 為最有效地使用專案參與人員而執行的各項過程。包括針對專案的各利益相關方展開的有效規劃、合理配置、積極開發、準確評估和適當激勵等方面的管理工作。

• 軟體專案團隊管理的定義：

軟體專案團隊管理就是採用科學的方法，對專案組織結構和專案全體參與人員進行管理，在專案團隊中開展一系列科學規劃、開發培訓、合理調配、適當激勵等方面的管理工作，使專案組織各方面的主觀能動性得到充分發揮，同時促進高效的團隊協作，以利於實現專案的目標。

軟體專案的人力資源特徵

人既是最大的成本又是最重要的資源

• 人力成本：儘量使人力資源投入最小

• 人力資源：儘量發揮資源的價值，使人力資源的產出最大

軟體專案團隊管理的主要內容

• 專案組織的規劃

    確定專案中的角色、職責和組織結構。

• 團隊人員獲取

    獲得專案所需的人力資源（個人或集體）。

• 團隊建設

    提高團隊成員個人為專案做出貢獻的能力；提高團隊作為集體發揮作用的能力。

• 團隊日常工作管理

    跟蹤團隊成員工作績效，解決問題和衝突，協調變更事宜。

• 溝通管理

    對在專案干係人之間傳遞專案資訊的內容、方法和過程進行綜合管理。保證專案干係人及時得到所需的專案資訊。

團隊協作的重要性

• 良好的團隊協作可發揮出集體的力量。

“Linus法則”：只要眼球足夠多，所有臭蟲都好捉。
               —— Eric Steven Raymond
                    《大教堂與市集》

類比：蟻群覓食。眾多螞蟻各自分散地尋找食物，找到後用一種非常高效的、可擴充套件的通訊機制互相通訊。
蟻群覓食

• Linux的開發充分利用了全世界開發者的集體智慧，使得系統中的缺陷被迅速修復，而Linus通過在Internet上頻繁地釋出Linux版本來不斷地向開發者反饋其開發成果。

• 在軟體的高層設計中，在產品和專案的許多決策中，發揮集體智慧都是極為重要的，一個人往往按照其習慣的和擅長的思維方式和解決問題的方式，在一條路徑上探索。而許多人在一個問題空間裡進行探索，其效能遠遠超過單個人。

• Raymond說：Linus最重要的貢獻不是建立了Linux核心本身，而是開創了Linux的開發模式。
  

• Linus說：我基本上是一個很懶惰的人，喜歡從實際上是別人做的事情上獲得榮譽。

• 諸葛亮，智慧的代名詞，治國能力極強，“鞠躬盡瘁，死而後已”。

• 但他事無鉅細，都要親自參與才放心。這樣做不僅使自己過於勞累，也不利於人才的培養。他去世後蜀國人才凋零，很快就滅亡了。

• 一個企業或組織要想持續健康發展，不能只靠個別人鞠躬盡瘁，而要發揮集體的力量。

8.2 專案組織的規劃

通過專案組織的規劃，確定專案團隊的角色，明確彙報關係（組織結構），分配人員職責，制定人員配置管理計劃。
8.2.1 專案團隊角色
8.2.2 專案的組織結構
8.2.3 專案人員職責分配
8.2.4 人員配置管理計劃

8.2.1 專案團隊角色

• 專案團隊中的不同角色要形成一種相互配合、相互制約的關係，共同促進專案目標的實現。

• 軟體專案團隊中常見的角色包括：專案經理、系統分析人員、架構師、開發人員、測試人員、質量保證人員、專案管理和支援人員、市場人員、使用者支援人員等。

• 不同型別的軟體專案所包含的角色是有區別的。

• 例如：微軟的一個軟體產品專案團隊通常由一個“產品單元經理”（Product Unit Manager）領導，包含有不同的角色。

微軟的專案團隊角色

• 產品管理人員

  獲取和定義使用者需求，市場分析和研究，產品推銷和公共關係。

• 後勤管理人員

  對專案所需的裝置、材料、軟體工具等資源進行管理，保證專案能夠平穩地進展。

• 注意：各種角色的地位是平等的，從而形成一個檢查和平衡機制。

• 在小型專案中，可以簡化團隊的組成，也就是說，可以把一些角色組合在一起。

微軟專案團隊構成

• Windows2000 Team

內部IT        50
市場人員      100
文件人員      100
本地化人員    110
培訓人員      115
程式經理      450
技術支援人員  600
技術傳播人員  1120
開發人員      900
測試人員      1800
合計          5345

• Web Matrix Team

程式經理      2
開發組長      1
開發人員      7
測試組長      1
測試人員      13
合計          24

• 要明確定義角色的職責和能力要求。

• 專案經理是整個團隊的核心角色，對專案的成敗起著關鍵作用。

專案經理的責任

• 制定開發計劃

  制定正確計劃的前提是理解使用者需求，理解專案目標。有全域性觀和系統觀。

• 組織實施

  組建專案團隊，為專案團隊成員分配任務，有效調動每個人的能力。

• 專案控制

  監控專案的執行，積極預防問題的發生，糾正偏差。

專案經理的權利

• 組織領導要賦予專案經理足夠的權利。

• 決策權：對專案事務有決策權。

• 專案資源的分配：對劃撥給專案的資源（如人員和裝置），專案經理有權決定具體的使用。

• 適當的財務權。專案經歷要有適當的支配專案經費的權利，這樣有利於控制成本，提高團隊工作積極性。

專案經理的能力要求

• 管理能力

專案團隊的組織、溝通、協調，充分發揮每個成員的能力和集體智慧。
專案團隊與外部組織的溝通和協調。
很好的口才和寫作能力。

• 技術能力。專案計劃、人員的使用、技術評審等均需要一定的技術能力。

• 管理能力和技術能力哪個更重要？

• 視具體專案特徵而定。

• 商業頭腦。

  理解產品需求，市場策略，盈利模式、企業戰略。

• 其他

  責任心、熱情、抗壓能力等。

8.2.2 專案的組織結構

• 專案的組織結構確定了團隊成員（部門）之間的彙報關係。

• 專案的組織結構是專案團隊所有成員為了進行分工協作，而在職務範圍、權力和責任方面所形成的結構體系。

組織結構的本質是團隊成員的分工協作關係；
組織結構的內涵是人們在職、責、權方面的結構體系，所以組織結構又稱為權責結構。

• 專案的組織結構主要包括以下內容：

職能結構：為完成專案目標所需的各項業務工作及其比例和關係。
層次結構：管理層次（上下級）的構成，又稱為組織的縱向結構。
部門結構：各管理部門的構成，又稱為組織的橫向結構。
職權結構：各層次、各部門在權力和責任方面的分工及相互關係。

• 沒有什麼好的或壞的組織結構，只有適合或不適合的組織結構。要根據具體的企業情況和專案情況來設計專案組織結構。
  

本小節的主要內容：
1.專案組織結構的型別
2.專案組織結構圖
3.專案小組結構
4.有關專案組織人員規模的討論

專案組織結構的型別

• 專案組織結構的型別與企業整體的組織結構有密切關係。

• 常見的專案組織結構有三種類型：

職能型
專案型
矩陣型

職能型組織結構的特點

• 職能部門是按照專業職能和業務來劃分，例如研發部門、銷售部門、財務部門等，研發部門又可進一步細分（如硬體、軟體等）。

• 專案可以由一個或多個職能部門承擔，專案成員分別受他所在的職能部門的經理管轄。

• 雖然也可能有專案經理，但其權利非常有限，通常只負責各部門間的溝通、協調、和監督作用，對專案成員沒有完全的領導權。

職能型組織結構

職能型專案組織結構的優點

• 以職能部門作為承擔專案任務的主體，可以充分發揮職能部門的專業優勢和資源集中優勢，有利於保障專案需要資源的供給和專案可交付成果的質量。

• 職能部門內部的技術專家可以同時被該部門承擔的不同專案所使用，節約人力，減少了資源的浪費。

• 同一職能部門內部的專業人員便於相互交流、相互支援，對創造性地解決技術問題很有幫助。

• 當有專案成員調離專案或離開公司，所屬職能部門可以增派人員，保持專案的技術連續性。

• 專案成員可以將完成專案和完成本部門的職能工作融為一體，可以減少因專案的臨時性給專案成員帶來的不確定性。

• 這種組織結構適用於主要由一個部門完成的專案或技術比較成熟的專案。

職能型專案組織結構的缺點

• 不能完全做到以專案目標作為驅動力和導向。職能部門往往集中精力於對本部門有益的工作上，而專案和客戶的利益可能得不到優先考慮。

• 決策過程要經過多個管理層，過程繁瑣，因此對客戶和市場的需求反應遲鈍而且容易失真。

• 當專案需要由多個部門共同完成時，權力分割不利於各職能部門之間的溝通交流、資源調配、團結協作。

• 專案成員在行政上仍隸屬於各職能部門的領導，專案經理對專案成員沒有完全的領導權。

專案型組織結構

• 專案型組織結構中的部門完全是按照專案需要進行設定的，是一種單目標的垂直組織方式。存在一個專案就有一個專案部門。

• 專案經理具有高度獨立性、對專案享有完全的領導權。

• 完成每個專案目標所需的全部資源完全劃分給該專案，完全為該專案服務。

專案型組織結構的優點

• 專案經理對專案可以全權負責，可以根據專案需要隨意調動專案組織的內部資源或者外部資源。

• 專案型組織的目標單一，完全以專案為中心安排工作，能夠對客戶的要求做出及時響應，有利於專案的順利完成。

• 專案成員有專案所需的技能，專屬於本專案，不需要與其他專案共享關鍵人員。

• 組織結構簡單，專案成員直接屬於同一個部門，彼此之間的溝通交流簡潔、快速，提高了溝通效率，同時也加快了決策速度。

專案型組織結構的缺點

• 不同的專案組織，資源不能共享，即使某個專案的專用資源閒置，通常也無法應用於另一個同時進行的專案，人員、設施、裝置可能會重複配置，造成一定程度的資源浪費，成本較高。

• 公司裡各個獨立的專案型組織處於相對封閉的環境之中，公司的巨集觀政策、方針很難做到完全、真正的貫徹實施，可能會影響公司的長遠發展。

• 在專案完成以後，專案型組織的使命即完成，專案成員有可能閒置甚至被解僱，對專案成員來說，缺乏一種事業上的連續性和安全感。

• 公司承擔的專案之間處於一種條塊分割狀態，專案之間缺乏資訊交流的機會。

• 沒有強大的職能群體，技術支援困難，也阻礙了公司能力的持續提高。

矩陣型組織結構

• 同時具有職能型組織結構和專案型組織結構的特徵，試圖把兩者的優點結合起來。

• 根據專案的需要，從不同的職能部門中選擇合適的人員組成一個臨時專案組織，由專案經理領導，他對專案的成功負有全部責任。

• 專案經理的職權由總經理直接授予。擁有一定的組織地位和權力。

• 職能部門有責任向專案提供最好的技術支援。

• 矩陣型組織結構的性質有強弱之分，這取決於專案經理對所擁有的職能資源的影響力。

• 當專案經理比職能經理對職能資源的使用有更大影響力時，矩陣結構才是強有力的。此時專案經理有能力提供技術指導、委派職責，對專案成員的工作成效有很大影響。

• 如果職能經理比專案經理更有影響力，那麼矩陣結構就是軟弱的。

矩陣型組織結構的優點

• 專職的專案經理負責整個專案，以專案為中心，能迅速解決問題。

• 公司的多個專案可以共享各個職能部門的技術骨幹和其他資源，節約成本。

• 既有利於專案目標的實現，也有利於公司巨集觀目標方針的貫徹。

• 專案成員在事業穩定性上的顧慮減少了。

矩陣型組織結構的缺點

• 容易引起職能經理和專案經理權力的衝突。

• 資源共享也能引起專案之間的衝突。

• 專案成員（處在矩陣行和列的交織處）有多頭領導。他們的任用、升遷、解僱的權力仍由職能部門經理把持，而職能部門經理對他們的績效考核又必須通過專案經理才能完成。當職能部門經理和專案經理的命令相沖突時，可能會出現無所適從的情況。

使用矩陣型組織結構的注意事項

• 橫向的專案組織與縱向的職能部門各自負責的工作和管理內容要明確，否則容易造成責任不清、雙重指揮的混亂局面。因此矩陣型組織良好運作的關鍵是這兩類部門的協調。

• 由於專案經理和職能經理都有各自的權力和責任，他們必須站在專案大局的高度進行良好的溝通和協調。避免出現以下情況：專案經理只考慮什麼對自己的專案有利（而不關心其他任何方面），職能經理則認為自己的部門比任何專案都重要。

• 由於專案成員往往來自不同的職能部門，其工作目標和工作方法可能有所差異，在專案初期的磨合階段可能會產生矛盾。要求專案經理及時識別矛盾，並控制和疏導由此產生的對抗。

• 由於專案成員從屬於某個職能部門，專案經理必須解決好以下問題：

如何才能激勵成員為專案工作，並保證對專案忠誠？
當專案指令和規則與部門政策相沖突，尤其是當成員感到自己的職能部門上司可能會對自己不滿時，如何說服他按專案的要求做？

組織結構型別的選擇

• 沒有一種組織結構型別是萬能的。要根據專案的實際要求和專案所處的企業環境進行選擇。

• 大多數現代組織會在不同層次上用到所有這些結構，形成一種複合型組織結構。例如，基本屬於職能型結構的公司，也可能會建立專案型的團隊來開發重要的專案，這樣的專案型團隊具有專案型組織結構的許多特徵，它可以從不同職能部門調來全職工作人員，可以制定自己的一套辦事程式，甚至可以不按照標準和正規的請示報告系統來開展工作。

專案組織結構的設計

• 選擇了專案組織結構的型別，只是在巨集觀上確定了專案組織結構的性質。

• 在此基礎上，還要設計專案組織的各組成部分及其報告關係、責任關係。設計結果通常用專案組織結構圖表示。

• 對於大型專案，可以分層次進行設計，即先考慮整體的組織結構，再逐層細化。

專案整體組織結構（舉例）

箭頭線表示管理流

開發組組織結構（舉例）

專案支援組組織結構（舉例）

專案小組結構

• 在大型軟體專案中，通常根據軟體的功能模組將從事開發的人員劃分為若干小組(Team)，每個小組負責一個功能模組的開發。

• 小組的組織結構對小組的工作效率和工作質量有很大影響。

• 專案小組的人員要“少而精”。人數太多的小組會產生較大的溝通開銷和溝通問題，影響工作效率和軟體質量。

專案小組結構的型別

• 小組的結構形式可分為三類：

1.民主分散型（Democratic Decentralized, DD）。小組沒有固定的領導，而是根據不同的任務來指定臨時的任務協調員。決策由小組通過協商來共同制定，小組成員之間的通訊是水平的。
2.控制集中型（Controlled Centralized, CC）。頂層的問題解決和小組內部協調由小組領導負責。小組領導和小組成員之間的交流是垂直的。
3.控制分散型（Controlled Decentralized, CD）。小組有一個固定的領導，來協調不同的任務。還設有若干二級管理者，負責子任務的完成。問題的解決仍然是集體行為，但解決方案的實現由小組領導劃分給不同的成員或成員組。個人和成員組內部的交流是水平的，同時也存在沿著控制層次的垂直交流方式。

不同小組結構的比較

• 集中式的小組結構有權威指導和統一管理，能以較快的速度完成任務，適用於處理簡單問題。分散式的小組結構能夠激發人員的創造力和集體智慧，產生更多、更好的解決方案，因此更適合於解決困難的問題。

• 民主分散型（DD）的小組容易產生更高的士氣和工作滿意度，因此適用於那種生存期較長的小組。

• 民主分散型的結構內部通訊路徑較多，通訊開銷也較大。但適用於解決那種可模組化程度較低的問題，因為解決這樣的問題需要大量的通訊和互動。

小組結構

• 如果需解決的問題可以被高度模組化，控制集中型（CC）和控制分散型（CD）小組結構則比較適合。

• 有經驗表明，CC和CD型小組產生的軟體缺陷比DD型小組少。

• 選擇小組結構時，主要應考慮以下因素：

需解決問題的難度。
軟體的規模（用程式碼行或功能點度量）。
小組存在的時間（小組生命週期）。
問題可被分解和模組化的程度。
對系統的質量和可靠性的要求。
系統交付日期的緊迫性。
專案所需要的交流的頻繁程度。

小組結構舉例-主程式設計師小組

• 最早的小組結構形式是CC型，其代表是 “主程式設計師小組”（chief programmer team），最早由IBM公司於20世紀70年代初期開始採用。

• 主程式設計師小組的核心是一個具有豐富經驗的工程師（主程式設計師），他負責計劃、協調和審查小組的所有技術活動。程式設計師（通常2到5人）負責分析和開發任務。一個後備程式設計師支援主程式設計師的工作，並在必要時可替換主程式設計師的工作。

• 可能還會有若干技術專家、書寫員及文件管理員來支援主程式設計師。

• 文件管理員可以為多個小組服務，他的工作包括：維護和控制所有軟體配置項，收集和整理相關資料，分類和索引可複用軟體構件，支援小組的研究和評估工作等。

小組結構舉例：微軟開發小組

• 在微軟，一個稍大一些的產品部門，分成幾個功能塊組（Feature Team）。每個功能塊組一般負責一個具體的功能模組，並由10到50人組成。根據功能模組的大小，功能塊組可能被分成若干子功能塊小組。最後每個功能塊小組一般不超過10人，其中至少會有一個程式經理（Program Manager），幾個開發人員和幾個測試人員。

• 程式經理全權負責功能模組的完成。對功能進行定義、規劃和設計；進行各種決策，掌握進度；協調開發和測試人員的工作並跟蹤錯誤；協調本開發小組和外部其他部門（市場、使用者支援等）的工作。

• 程式經理是管理者和協調者，不直接參與程式設計和測試。不同於其他軟體公司的開發小組“技術負責人”。

有關專案組織結構和人員規模的討論

• 專案組織中人員的溝通開銷會隨著人員數量的增加而增加。

• 假設專案中每個人員都可以和其他任何人員通訊，那麼通訊路徑數會隨著人員數的增加而呈指數增加。

溝通路徑

• 溝通開銷也與專案組織結構有關。專案組織結構通常限制了人員之間的通訊路徑（例如一個人員或部門主要和有彙報關係/責任關係的人員或部門通訊，控制集中型小組內部的通訊路徑少於民主分散型）。

• 由於不同人員/小組負責開發不同的軟體模組，軟體模組設計的弱耦合性也可有效減少不同人員或小組之間的通訊。

開源專案的典型通訊機制

• 世界各地的程式碼貢獻者和測試者把他們的程式碼和缺陷報告通過Internet傳送給專案核心組，專案核心組通過頻繁地在Internet上釋出新版本而對他們提供反饋，而程式碼貢獻者或測試者之間幾乎不需要通訊。

8.2 專案組織的規劃

8.2.1 專案團隊角色
8.2.2 專案的組織結構
8.2.3 專案人員職責分配
8.2.4 人員配置管理計劃

8.2.3 專案人員職責分配

• 為專案組織中的部門或個人分配職責，避免因責任不清而造成工作互相推諉，責任互相推卸的現象。

• 責任分配矩陣（Responsibility Assignment Matrix, RAM）是用來對專案團隊成員進行分工，明確其角色與職責的有效工具 。

責任分配矩陣舉例

RAM還可以用於更詳細地定義團隊成員與任務間的關係。

專案人員職責分配

• 對於很小的專案，可以通過RAM把職責直接分配給個人；對於較大的專案，RAM可以劃分出多個層級，先把職責分配給子團隊或部門，然後再繼續細分。

• 如果需要詳細描述角色的職責，也可使用文字敘述的方式，包括角色的職責、授權、能力和資格等資訊。這樣的檔案可以稱為崗位描述、角色-職責-授權表格等，對將來的專案有很好的參考價值。

8.2.4 人員配置管理計劃

• 人員配置管理計劃描述何時以何種方式滿足專案的人力資源需求。

• 在專案期間，人員配置管理計劃可能會不斷進行更新，以指導專案的人員招募和團隊建設工作。

• 根據具體專案的需要，人員配置管理計劃可以是詳細的或寬泛的，內容也有所區別，但一般應考慮以下內容。

人員配置管理計劃的內容

• 專案團隊組建的相關問題。例如，人力資源來自於組織內部還是外部？團隊成員需要同地辦公還是遠距離分散辦公？組織的人力資源部門可以為專案管理團隊提供多大程度的支援？

• 時間表。說明專案對每個或每組團隊成員工作時間的安排，以及招募活動何時開始。資源直方圖是一種常用的人力資源圖表工具。

資源直方圖

• 成員遣散安排。確定團隊成員的遣散方法和時間。在最佳時機把團隊成員撤離專案，可節約成本，而且如果把成員平滑過渡到其他專案中去，可提高士氣。

• 培訓需求。如果預期分派的專案成員不具備所需的技能，則可以制定相應的培訓計劃。

• 表彰和獎勵。用明確的獎勵標準和有計劃的獎勵系統來促進所期望的員工行為。

• 合規性。人力資源的使用要符合相關的政府規定和其他既定的人力資源政策。

8.3 團隊人員獲取

根據專案團隊的角色和職責、專案組織結構圖和人員配置管理計劃，獲取完成專案工作所需的人力資源。
本節內容提要：
8.3.1 獲取團隊人員的方法
8.3.2 虛擬團隊

8.3.1 獲取團隊人員的方法

• 預分派

  在某些情況下，一些成員已預先分派到專案中工作，例如在競標過程中承諾分配特定人員到專案中，或專案的成功依賴於特定人員的專有技能。

• 談判

  大多數人員的獲取需要經過談判。例如專案經理需要與職能部門經理或其他部門負責人談判，以獲得所需要的人員。
  在談判時，專案的影響力會起作用。

• 招募

  當企業缺少完成專案所需的內部人才時，就需要從外部獲得所需服務，包括招聘和分包。

在獲取和任用專案團隊人員時，除考慮人員的專業技能外，最好能結合人員的性格特徵和興趣，做到“知人善任”。

獲取團隊人員後的成果

• 專案人員分派到位

• 明確人力資源可利用情況

  人力資源可利用情況記錄了專案團隊成員在專案上可工作的時間。明確了專案團隊成員在時間安排上的衝突，包括休假時間和承諾給其他專案的時間。

• 更新後的人員配置管理計劃

  實際的專案人員分配很少能夠完全符合最初的人員配置管理計劃，因此需要對其進行變更。

8.3.2 虛擬團隊

• 虛擬團隊為專案團隊人員的招募提供了新的可能性。虛擬團隊是指擁有共同目標，但工作地點分散，在工作過程中很少或完全不面對面交流的一組人員。

• 電子通訊設施的完善（電子郵件、即時通訊、視訊會議等）使虛擬團隊成為可能。

虛擬團對的好處

• 可以組建在同一組織工作，但工作地點十分分散的團隊。

• 僱用方式更為靈活，可以為專案團隊增加特殊技能和專業知識，即使專案人員不在同一地理區域。

• 可以納入在家辦公的員工。不僅節省了工作空間和裝置的費用，而且可能提高工作效率。

• 可以安排不同時區的人員的任務分工來減少任務的持續時間。

• 可以把行動不便的人納入專案團隊。

虛擬團對的約束

• 分配給虛擬團隊員工的任務需求要十分明確。

• 協調分散的員工也許很難，特別是跨國和跨時區的情況。

• 計算工作量和付費也許需要按件計算，而不是按工時計算。

• 遠端或者素不相識的協作者之間也許缺乏信任感。

8.4 團隊建設和日常管理

• 專案團隊建設是指提高團隊成員的技能，以加強他們完成專案活動的能力；提高團隊成員的信任感和凝聚力，以促進團隊協作。

• 專案團隊日常管理是通過觀察團隊的行為、管理衝突、解決問題，以及評估團隊成員的績效，來促進專案的進展。

• 團隊建設和日常管理涉及到人際關係和人的情感、動機等因素，所以不僅需要制度上的保障，還需要專案管理者的“情商”，進行“人性化管理”。

8.4.1 培訓

• 通過對團隊成員的培訓，可以提高專案團隊的綜合素質、工作技能和技術水平。同時有助於提高專案成員的工作滿意度，降低專案人員的流動比例和人力資源管理成本。

• 針對專案的一次性和約束性（主要是時間和成本的制約）的特點，對於團隊成員的培訓主要採取短期性的、片段式的、針對性強、見效快的培訓。

• 培訓方式主要有兩種：

崗前培訓：對團隊成員進行一些常識性的崗位知識和專案管理知識的培訓；
崗上培訓：主要根據開發人員的工作特點，針對操作中可能出現的實際問題，進行特別的培訓，多偏重於專門技術和特殊技能的培訓。

• 培訓的方法有多種，例如課堂培訓、線上培訓，指導和輔導等。

8.4.2 人員激勵

• 激勵就是通過一定的引導行為來激發團隊成員的工作動機和工作熱情。

激勵要因人而異。常見的激勵方式有：

• 薪酬激勵：必須讓薪酬與績效掛鉤。

• 機會激勵：獲得機會實現職業發展。讓員工有平等的機會參加學習、培訓、從事有挑戰性的工作和獲得升遷等。

• 環境激勵：企業內部良好的工作環境和氛圍。例如管理層對工作人員的支援和關注，寬鬆和富有建設性的技術創新氛圍等。

團隊人員的激勵

• 情感激勵：員工需要被認同、被尊重、被關心。
  

• 有關激勵的理論研究有很多，例如馬斯洛的需要層次理論，海茲伯格的激勵理論，麥格雷戈的X-理論、Y-理論，超Y理論，Z理論，期望理論等。

馬斯洛的需要層次理論

• 人類的需要是分層次的（見下圖）。人們的行為受到這一系列需要的引導和刺激。

• 在軟體企業中，知識型員工普遍追求高層次的需要，企業管理者不能只停留在滿足員工低層次的需要上。例如：

• 知識型員工的自尊心強，不要在公開場合批評和貶低員工的工作。

• 軟體開發人員是追求自我實現的群體，企業管理者可以幫助他們制定職業生涯規劃，盡力提供培訓、工作鍛鍊的機會來幫助員工實現其職業發展需要。

Z 理論

• Z理論是威廉.大內於1981年在《Z理論》一書中提出的，其基本思想是：企業經營管理者與員工的目標是一致的，二者的積極性可以融合在一起。Z理論的主要觀點包括

（1）企業對員工實行長期或終身僱用制度，使員工與企業同甘苦共命運，並對員工實行定期考核和逐步提級晉升制度，使員工積極關心企業的利益和企業的發展。
（2）企業經營者不單要讓員工完成生產任務，而且要注意員工培訓，使他們成為多專多能的人才。
（3）管理過程既要運用統計報表、資料資訊等鮮明的控制手段，而且要注意對人的經驗和潛在能力進行誘導。
（4）企業決策採取集體研究和個人負責的方式，由員工提出建議，集思廣益，由領導者做出決策並承擔責任。
（5）上下級關係融洽，管理者對職工要處處關心，讓職工多參與管理。

8.4.3 增強團隊凝聚力的措施

• 通過一些措施加強團隊的實際存在感。例如定期召開會議（包括專案啟動會，專案評審會等）；可建立一個團隊空間，在其中可以張貼專案組織結構圖，專案進度圖表等，大家可以一起工作和討論問題。

• 可以組織一些正式或非正式的團隊建設活動，增進團隊成員的友誼，確立良好人際關係。

8.4.4 績效評估

• 績效評估就是工作行為的測量過程，即用過去制定的標準來比較工作績效的記錄及將績效評估結果反饋給職工的過程。

• 績效評估的根本目的是發現問題，完善工作，並使員工更好地發展。

• 按照目的劃分，績效評估的型別有：獎金分配評估，提薪評估，業績評估，人事評估，職務評估，晉升評估。

• 績效評估程式：

    （1）建立業績考核體系。
    （2）將業績期望告知員工。
    （3）測量實際業績。
    （4）比較實際業績和考核標準。
    （5）進行矯正。

8.4.5 衝突管理

• 專案的高壓環境、責任模糊、技術上的不同觀點等都可能引起團隊成員之間的衝突。

• 如果適當管理，衝突的解決會帶來益處，有助於提高創造力和做出好的決定，相反則會帶來負面影響。

• 要管理衝突，應回答下面幾個問題：

為什麼會產生衝突？
該怎樣處理衝突？
能否預測和防範衝突？

衝突的誘發因素

• 衝突的誘發因素有很多，常見的有：專案管理方式方法、技術見解、人力資源分配、成本估計、進度規劃等。

• 各種原因的衝突在專案的不同階段，其表現強度是不同的。例如技術衝突和管理方式方法衝突在專案後期的表現強度較弱，而在專案的中期則相對較強。

衝突的主要處理方式

• 1.問題解決（Problem Solving）：也稱為“正視”（Confrontation）。雙方一起積極地定義問題，收集問題資訊，開發並且分析解決方案，直到最後選擇一個最合適的方法來解決問題。這是衝突管理中最有效、最可取的一種方法。

• 妥協（Compromising）：雙方協商並且都做出一定程度的讓步，尋找一種能使雙方都可接受的方法。

• 求同存異（Smoothing）：雙方都關注他們同意的觀點，而避免衝突的觀點。

• 撤退（Withdrawal）：把眼前的問題擱置起來，等以後再解決。

• 強迫（Forcing）：採用一方的觀點，否定另一方的觀點。屬於“贏-輸”式的處理方式，除非有特殊情況，一般不推薦這種方法。
  

• 採用哪種處理方式視衝突的具體情況（為什麼衝突？與誰衝突？）而定。

衝突管理的規劃

• 在專案初期就應該對衝突管理進行計劃，分析在專案的各階段會出現哪些衝突，該怎樣避免，怎樣處理。

• 不適合在整個企業層次上建立衝突管理的政策和程式。因為每個專案產生衝突的情況和解決衝突的方法都有特殊性。
  

案例：IBM的團隊建設絕招

• IBM有一個讓所有員工堅信不疑的遊戲規則：幹得好加薪是必然的。為了使每位員工的獨特個性及潛力得到足夠尊重，IBM一直致力於工資與福利制度的完善，並形成了許多值得我們參考的特色。

1.激勵文化
    薪水是企業管人的一個有效硬體，直接影響到員工的工作情緒。 IBM的薪資管理非常獨特和有效，能通過薪資管理達到獎勵進步、督促平庸的效果，IBM將這種管理已經發展成為了高績效文化。
2.薪資與職務重要性、難度相稱
       每年年初，IBM的員工特別關心自己的工資卡，自己去年工作乾的好壞可以通過工資漲幅體現得有零有整。IBM的薪金構成很複雜，但裡面不會有學歷工資和工齡工資。
        IBM員工的薪金和其崗位、職務重要性、工作難度、工作表現和工作業績有直接關係，工作時間長短和學歷高低與薪金沒有必然聯絡。在IBM，你的學歷是一塊很好的敲門磚，但絕不會是你獲得更好待遇的憑證。
       在IBM，每一個員工工資的漲幅會有一個關鍵的參考指標，這就是個人業務承諾（Personal Business Commitments, PBC）。只要你是IBM的員工，就會有個人業務承諾（每年一次），制定承諾計劃是一個互動的過程。從總裁開始，寫下PBC，然後層層溝通和傳達。某層員工會根據上
級經理人的目標去計劃自己的目標，然後讓下一層員工去建立他們較小的目標，如此類推。這樣可以很有效地把所有員工的注意力重新放到最重要的事上。而且使各部門和上下級之間的目標都是關聯的，降低了部門的自我中心意識。
你和你的直屬經理坐下來共同商討這個計劃怎麼做才切合實際，幾經修改，你和你的老闆其實立下了一個一年期的軍令狀，老闆非常清楚你一年的工作及重點，你自己對一年的工作也非常明白，剩下的就是執行。大家團結緊張、嚴肅活潑的幹了一年，到了年終，直屬經理會在你的軍令狀上打分，直屬經理當然也有個人業務承諾計劃，上頭的經理會給他打分，大家誰也不特殊，都按這個規則走。IBM在獎勵優秀員工時，是在履行自己所稱的高績效文化。
3.薪資充分反映員工的成績
       個人業務承諾考核通常由直屬上級負責對員工工作情況進行評定，上一級領導進行總的調整。每個員工都有進行年度總結，並與他的上級面對面討論這個總結的權利。上級在評定時往往與做類似工作或工作內容相同的其他員工相比較，根據其成績是否突出而定。評價大體上分10—20個專案進行。
       評價工作全部結束後，就在每個部門甚至全公司進行平衡，分成幾個等級。例如，A等級的員工是大幅度定期晉升者，B等員工是既無功也無過者，C等員工是需要努力的，D等員工則是生病或因其他原因達不到標準的。
       從歷史上看，65%—75%的IBM公司職工每年都能超額完成任務，只有5%~10%的員工不能完成定額。那些沒有完成任務的人中只有少數人真正遇到麻煩，大多數人都能在下一年完成任務，並且乾的不錯。

• 簡評

       激勵在哪裡都是需要的，激勵的最佳力度取決於業績與薪水之間的權衡。以業績為基礎的付酬方法的難點在於業績的評估，其中的一個問題就是員工的行為一般不會完全轉變成可以評估的業績，而IBM的個人業務承諾（PBC）針對每個員工制定了單獨的評估標準，很巧妙地解決了評估難的問題。同時，IBM不光注重自身的長遠發展，同時又兼顧了員工的個人需求。

8.5 溝通管理

• 溝通是人與人之間的思想和資訊的交換。溝通從一定意義上講，就是管理的本質。據統計，專案經理80%以上的時間用於溝通管理。溝通失敗是專案失敗的重要原因。

• 溝通管理就是確定專案干係人的資訊需要，並保證以合適的方式，把資訊及時傳遞給他們。

• 溝通管理的基本原則是及時性、準確性、完整性、可理解性。

8.5.1 溝通需求分析

• 通過溝通需求分析可以明確各種專案干係人的資訊需求。資訊需求包括資訊的型別和格式，以及該資訊的價值。

• 為降低通訊開銷，應限制通訊渠道。因此溝通需求分析需要依據專案組織結構圖和專案團隊成員的職責關係。

8.5.2 溝通方式

• 按傳播媒介的方式可劃分為書面溝通、口頭溝通和電子媒介。

• 按組織系統可分為正式溝通和非正式溝通

• 按資訊傳播方向可分為上行溝通、下行溝通、平行溝通和越級溝通。
  

• 採用什麼溝通方式取決於資訊的內容、對資訊需求的緊迫性以及專案環境等。

正式溝通

• 正式溝通是通過專案組織明文規定的渠道進行資訊傳遞和交流的方式。

• 正式溝通的一種主要形式是“專案評審”。專案評審以會議的方式進行，用來檢查專案當前的執行情況，並確定採取的管理措施。

• 專案評審可分為三種：定期評審、階段評審和事件評審。

定期評審

• 1.定期評審：根據專案計劃和跟蹤採集的資料定期（例如每週）召開評審會議，對專案的執行狀態進行評審，檢查專案規模的變化、各項責任落實情況、專案進度是否得以保證、資源調配是否合理等等，對於出現的偏差制訂糾正措施。

• 定期評審會議既是交流專案資訊的方式，也是一個很好的激勵方式。

階段評審

• 2.階段評審（里程碑評審）：在專案計劃中規定的時間點（或里程碑處），對該階段的任務完成情況和產品進行評審，目的是檢查當前計劃的執行情況，檢查產品是否合格，對專案風險進行分析處理，並對下一階段的專案計劃進行必要的調整。

事件評審

• 3.事件評審：對專案進行過程中相關人員提交的事件報告（主要指對專案進度、成本、質量有影響的事件）進行評審，通過分析事件性質和影響範圍，討論事件處理方案，並判斷是否影響專案計劃，必要時採取糾正措施。
  

• 專案評審結束後，要產生一個評審報告，包括評審結果和所發現的問題。評審報告要及時釋出。

非正式溝通

• 非正式溝通指在正式溝通渠道之外進行的資訊傳遞和交流。它具有隨意性和靈活性，並沒有一個固定的模式或方法。例如聊天、非正式的面談或聚會等。

• 軟體專案團隊中存在著大量非正式溝通。

• 非正式溝通補充了正式溝通的不足（正式溝通缺乏靈活性，且可能給專案人員帶來壓力），滿足了專案人員的需要。

8.5.3 溝通管理計劃

• 專案溝通計劃確定專案相關人員的資訊和溝通需求：誰需要什麼資訊，什麼時候需要，怎樣獲得，選擇的溝通方式，等等。

• 溝通計劃是整個專案計劃的一個附屬部分，應在專案的前期階段完成。在專案進行過程中，要根據溝通需求隨時對其進行檢查和修訂，以保證它的持續有效性和適用性。

專案溝通計劃的主要內容

• 專案干係人的溝通需求：他們需要什麼資訊，什麼時候需要，這些資訊對他們有什麼價值。

• 溝通方式。描述傳達資訊所需的技術和方法。

• 人員聯絡方式。

• 工作彙報方式：明確表達專案組成員對專案經理或專案經理對上級和相關人員的工作彙報關係和彙報方式，明確彙報時間和彙報形式。

• 溝通時間安排。確定一些正式溝通的時間和頻率。

• 溝通計劃維護人：明確本計劃在發生變化時，由誰進行修訂，並對相關人員傳送。

8.5.4 專案效能報告

• 專案效能報告一般應包括專案當前的範圍、進度、費用和質量等方面的資訊。許多專案還要求在效能報告中加入風險和採購資訊。

• 及時釋出專案效能報告可以使專案相關人員瞭解專案的當前狀態、進展，以及下一步的工作計劃。

• 專案評審報告就是一種很重要的效能報告，包括定期評審報告、事件評審報告和階段（里程碑）評審報告。

• 專案週報模板

8.5.5 問題管理

• 專案團隊成員在遇到問題時，不要總是一聲不響、埋頭苦幹，而要及時與團隊中相關人員交流。問題的及時解決可促進團隊人員間的良好關係。

• 為了確保問題不被遺漏並及時得到解決，應建立一個問題跟蹤列表（或使用變更控制工具來跟蹤問題）。

問題跟蹤列表

Open表示問題還沒有解決；Resolved表示問題已解決，但還沒有經過驗證；已解決的問題經過相關人員驗證後，狀態稱為Closed。

8.6 軟體專業人員的非技術素養

8.6.1 團隊意識

• 團隊意識就是團隊成員為了團隊的整體利益和目標而相互合作、共同努力的意願和作風。

• 團隊意識具體表現在：

對團隊的強烈歸屬感和一體感；
團隊成員間的相互協作從而形成有機的整體；
對團隊事務的盡心盡力和全方位投入；
使團隊目標優先於個人目標；
願意分享資訊，理解別人的行為併產生適當的反饋；
當其他成員需要時給予幫助；
對別人的反饋作出積極地反應。

• 違反團隊意識（團隊精神）的常見做法：

不願把自己的技術知識與別人分享，怕別人威脅自己的職位；
不喜歡與別人交流，不願求助於別人，有問題後孤軍奮戰。

8.6.2 主人翁精神（Ownership）

• 主人翁精神是指對團體及其產品有一種“擁有”意識，因此主動關心團體的利益並願意為之付出努力。

• 主人翁精神還表現在發揮主觀能動性、敢於負責、勤于思考、勇於做出判斷並表達自己的意見。

• 案例

• 當你加入一個產品開發團隊以後，無論團隊是隻有一兩個人，還是成百上千人，你都是產品的一個負責人（Owner），都要有這樣一種精神和意識：“這是我的作品，我將製作它，我希望它能成功！”。

• 企業領導要有意識地通過各種方式培養員工的主人翁精神。如適當放權，配發股票等。

8.6.3 寫和說的能力

• 寫和說是人們向外界表達自己能力和才華的最重要途徑。可是表達能力低下卻是許多研發人員的通病。

• 要重視表達能力。“表達能力不重要，而技術才能才是最終要的”觀念是錯誤的。

• 軟體專業人員要不斷與別人溝通。而且如果表達能力差，就無法勝任需求開發、系統設計、管理等高層次的工作。

• 怎樣提高表達能力？“無他，唯手熟爾”。

• 珍惜每一次寫文件、會議發言、作報告的機會，保證質量完成任務，通過多練逐步提高。

• 技術類的文件（包括開發文件、商務文件、產品說明書等）有四大要素：內容、邏輯、實證、措辭。

（1）內容充實，切忌空洞無物，大話、套話連篇。
（2）內容表述要邏輯清晰，容易理解。
（3）內容要有真憑實據，不能有虛構、誇張、造假成分。
（4）措辭追求“正確、準確、優美”。

• 當眾發言（會議、演講、報告、講課等）要注意以下幾點：

（1）事先做充分準備。多練幾遍，熟悉內容，控制時間，避免在現場手忙腳亂。
（2）儀表整潔，精神抖擻。
（3）聲音響亮。
（4）避免過分隨意的口語和“口頭禪”。

8.6.4 管理能力

• 管理能力是指帶領團隊完成目標的能力。

• 在企業裡，不僅各級領導要會管理，而且還要讓員工們懂得被管理（俗稱洗腦）。

• 穩紮穩打的職業發展模式：先搞技術，擁有一技之長後再逐步轉向管理。

• 做好管理工作，不僅要用腦，而且要用心，不僅要有智商（IQ），而且要有情商（EQ）。

• 怎樣培養管理能力？  學習 + 實踐

• 要學習本行業基礎的管理知識

本門課程的知識；
能力成熟度模型（CMMI）；

• 從底層的管理者（如專案經理）做起，不斷實踐，積累經驗，提高能力。

軟體專案人員管理案例
聖人的話：
          在管理上，對於人力資源，要考慮：量材錄用，幫助提高，絕不輕視棄置。

本章小結

理解軟體專案人力資源管理的主要作用和主要內容。
理解專案組織結構的確定：專案組織型別及其特徵、不同小組結構的特徵。
理解專案團隊的建設：人員配備、培訓、績效管理、激勵。
理解專案溝通溝通方式、衝突管理，瞭解溝通計劃。
瞭解軟體專業人員要有哪些非技術素養。