1 我眼中的專案經理

1.1 人云“一個管理，半個專家”，我說“一個管理，兩個專家”

如 今，我發現我們不得不面對這樣一個現實——角色兼職。我習慣上把專案分為三類：性命攸關的專案（涉及到人身安全的專案，如鐵路專案）；使命攸關的專案（具 有明確時間節點的企業級資訊化專案）；普通專案（中小軟體專案）。我相信大多數專案經理都同我一樣，奮戰於使命級和普通級專案。雖然，從軟體工程角度來講，我 們需要外科手術式的團隊，人人各司其職，以專注於不同的方面。但事實是，我們的大多數僱主不會僱傭他們眼中“多餘”的人員。這時，就需要由專案經理進行兼任。 從廣義上講，專案經理除了管理以外，常常會兼任兩種角色——設計者和開發者。很多時候，我們不得不面對這樣一種尷尬的局面，就是我們花費大量的時間在設計和編 碼上，而不是專案管理。我也時常在反思，作為專案經理，我的知識體系應該是何種結構呢？

我想大多數的開發者都認同，專案經理需要具備一定的技術實力，否則就會發生外行管理內行的悲劇。從我的經歷來看，在技術領域，有兩方面知識對專案經理來說最為重 要。其一，軟體設計領域知識（需求分析、架構設計、資料庫設計、UI設計）；其二，軟體實現領域知識（開發語言、測試除錯、IDE的使用）。之所以，我認 為這兩點很重要，是因為專案經理需要承擔責任。很多時候，需要我們在沒有技術總監支援的情況下來完成專案。

1.2 不是所有人都適合專案經理

我認為專案經理需要具有以下天生的品格：

真誠 真誠自不用說，這是每一個管理者都應該具備的，最基本的不能被後天習得的能力。
骨氣 血氣之怒不可有，義理之怒不可無。專案經理必須有勇氣對不合理的要求說“不”，必須敢於維護團隊的利益。
堅毅 專案經理必須能抗壓力，即使是專案這條大船正在沉沒，專案經理也應該以超乎常人的勇氣與決心來發號施令。
1.3 雖然理論很重要但更重要的是經驗

書上的東西是死的，如何有效地將理論知識轉化為生產力需要的是長期的經驗積累。理論必須聯絡實際，管理沒有攻略。

1.4 管好專案首先要管好自身

我不相信一個連自己都管理不好的人，能夠管理好一個團隊。一個人的為人處世透露了這個人的性格特點。我覺得一個對自己都不負責任的人，如何能負責一個團隊呢？一個經常遲到的人，專案進度可以保證嗎；而一個生活邋遢的人，可以保證專案質量嗎？

1.5 找尋平衡而不是最優

範圍、時間、成本、質量，我們受制於這4個維度。現實中，我們必須認識到，我們的專案成敗決定於這四個維度的平衡。所以，更提倡的是，找到這四個維度的平衡點，而不是力求把這四的方面都做到最好，那是不現實的。

1.6 “四拍主義”不可留

“四拍主義”是最另我反感的做法，但的確在身邊屢見不鮮。“一拍腦門幹了；二拍胸脯沒問題；三拍大腿出事了；四拍屁股走人了。”身邊見過的聽過的這樣的例 子不少。面試官的能力不足以及背景調查的不徹底，助長了這些不負責任者的氣焰。把一個專案做臭了，丟下個爛攤子就走， 不斷地從一個專案換到另一個專案，換了幾次簡歷上很漂亮，工資上漲也很快，但管理能力名不副實，很難理解這樣的人卻有很多企業搶著要。

2 Open Mind

2.1 海納百川，取長補短

不管是對過程管理或者是對人管理，不同陣營之間的爭吵越來越激烈了。不論你去參加何種認證考試，或已經處在某個陣營中，常常都會被像洗腦一樣被灌輸了某 種模式或理論體系比其他的更好。但其實真的沒有必要，把專案管理風格劃分的如此對立。如同軟體工程的核心目的是降低軟體開發的複雜度，我們不斷探尋專案管 理模式為的也是最大可能地促成專案成功。所以，我認為任何好的，被廣為認可的，能夠促成專案成功的實踐，在公司允許並且風險在可控範圍內的都應該被實踐和 推廣。比如，我在專案中，雖然是對過程進行管理，但我仍然在不斷地實踐敏捷開發中的“持續交付”思想，我也得益於此。

2.2 學會思考

思考大有玄機，人不是天生就會思考，我們需要規避某些陷阱。

偏見 人是愛面子的動物，人容易被感情左右。當我們聽到反對的聲音時，多數人會本能地進行抵抗，而不是接受意見並進行深入思考。諸如此類的偏見還有很多，未經訓練或者缺乏相關知識的人，很難把持中立地去看待問題。
片面地思考 樂觀的人只看到問題好的方面而容易忽略風險，悲觀的人則只看到問題的風險，忽略潛在的價值。
從眾心理 人是群居動物，不擅長獨立思考，人類需要社會，需要朋友。在思考時，人更傾向於選擇大眾說接受的，而不是思考者內心所真正認同的觀點。這就是人的從眾心理，但很多時候真理只掌握在少數人手裡。
2.3 心理學其實很有用

幾年前，我看到我熟悉的某位前輩在看心理學書籍。當時我很困惑，我不理解他的業餘時間為什麼要花費在和IT毫不相關的書籍上。但當我在某些思維或者專案管理書籍上，發現了心理學的影子，我才感覺到——心理學其實很有用。舉一個例子，如下：

當我進入某個專案後，我發現了一個已經蔓延的低階缺陷，這出現了一個奇怪的現象，就是同事們有不少都發現了這個問題，並且認為有更好的寫法，但是卻沒有 人反應給設計組，而原因驚人的一致——“這問題太菜了，肯定別人有去反應的！”在心理學裡，這就是“旁觀者效應”。關注一些知名的心理學實驗，有助於我們 正確地審視團隊，發現某些問題背後的本質。

2.4 前期準備為自己

項 目前期，我們面臨著一個巨大的壓力，僱主在催促我們儘快開始編碼。如果，我們不能勸說僱主，並且學會向不合理的要求說不，那麼很可能為後期的專案失敗埋下 伏筆。軟體專案，反應著這樣一個本質——工作項之間有強硬的邏輯存在，而且，越是專案早期解決缺陷的成本越低，我們左右專案的方向也越容易。因此，如果項 目的前期準備不夠充分，便草草開始編碼，很可能會在專案的中後期暴露出大量缺陷，進度、士氣、質量、成本都將受到損害。所以，為了團隊考慮也為我們自己， 請做好前期準備後再開始編碼。

2.5 質量很重要

質 量這一關鍵核心維度，往往成為我們追趕進度的犧牲品。在範圍、時間、成本都能檢視和追溯的時候，會有人去犧牲那個最難以檢視的質量。從開發者角度，我們不 斷地強調程式碼質量，但是到頭來，那些真正地敢於面對不合理設計說“不”的，努力維繫程式碼質量的程式設計師，卻得不到重視。進度固然重要，但很多沒有技術基礎的 專案經理，特別是不瞭解程式設計師文化的專案經理，正在犧牲質量來掩飾他們對專案進度管理的無能。

對質量的第一層認識——我們可以交付低等級的軟體，但不能交付低質量的軟體。

對質量的第二層認識——質量不是無止境的，滿足需求即可。

對質量的第三層認識——低質量會造成優秀的開發者情緒低落。（如果讓優秀程式設計師長期面對糟糕的程式碼，開發低於他自身質量標準的軟體，會讓那些真正熱愛程式設計的人情緒低落，甚至質疑團隊的技術實力並選擇離職。）

2.6 落地的才是成果

忘記你的甘特圖吧，在UAT沒有通過之前，你的努力僅僅是一堆除錯通過的程式碼。別被圖表上漂亮的進度所欺騙，因為很多時候，進入UAT才會發現潛在的缺 陷（尤其是前期準備不足的時候）。我們如果對賬面上的進度過分地樂觀，往往會造成對風險管理上的疏忽。所以，保持一顆理性的心，UAT通過才算落地。

2.7 程式碼審查好過測試

不要過分地依賴測試，好的程式碼審查和快速反饋機制能夠在早期缺陷還沒有蔓延的時候就將其修復，而且根據我瞭解到的一些數字，程式碼審查發現的缺陷數量要遠遠高於測試。

3 工具

專案經理需要掌握常用工具的使用：

開發工具 如VS，Blend，程式碼生成器等。
管理工具 如SVN，TFS，Project等。
文件工具 如Visio，Rose，Excel等。
部署和釋出工具 如IIS，Sql Server，Win Server等。
4 團隊建設

4.1 尊重你的同僚

人 人生而平等。當讀者讀到這段文字，或許會認為自己已經足夠足夠尊重我們的同僚，但事實真的如此嗎？很多時候，當我們自認為自己身經百戰，能力高人一籌時， 我們真的能夠秉承原則嗎。下面列舉的話語很極端，多少有些誇張，但我建議，同時也是真切地希望，專案經理們不要做下面的事情，因為那樣真的會傷害他人。

“這程式碼寫的什麼呀！” 不要去否定他人的勞動成果，如果開發者的程式碼無法達標，請說：“你的程式碼存在缺陷，我有更好的建議。”
“設計我說的算，開發你閉嘴！” 不要遇到反對的聲音就一概否定，開發者才是最前線的士兵，不論我們有多大自信，我們也應該傾聽反對的建議，並進行公允地評估。
“這東西你要用一天寫完？” 不要當眾讓開發者難堪，情緒低落只會讓開發者向專案引入更多的缺陷。如果開發者沒有完成進度，我們應該找到原因，解決問題，而不是一味地指責。
“你能力不行！” 對開發者自身價值的完全否定，此話一出，等著應對離職吧。
4.2 瞭解你的同僚

就像銷售把客戶分群一樣，我們也應該學會將干係人分群。在這裡我不想探討如何進行干係人管理，這個話題太大了，我想說的是如何管理團隊。歸根結底，專案經理 是在對人進行管理。我們需要了解我們的同僚，不僅是其技術上的能力，也包括他們的性格和心理需求。人和人不同，有人圖錢，有人為了學技術，有人工作求穩， 有人追求認同感等等。我們的同僚有不同的心理需求，在我們使用管理方法時需要結合實際情況加以調整，而不是一味地按照教科書照本宣科。很多時候，技術培 訓，授權比加薪更能穩定人心。

4.3 永遠追求多贏

“真正的團隊需要同舟共濟。”

專案的成功不能以犧牲開發人員利益為代價。我們購買書籍，參加培訓，考取認證，出席峰會，花費大量時間來完善和實踐專案管理方法，為的是能夠在不損害團 隊成員的利益前提下，控制成本，確保專案成功。很多時候，專案經理的績效工資與利益掛鉤，但我們不該為了個人利益而犧牲質量或者團隊成員的利益。我們不站在公 司、團隊、客戶任何一方，而是站在三者的中心，以平衡矛盾。秉承職業道德，並不容易，會有同行的嘲諷，領導的評評或者客戶的謾罵，但真誠和職業道德是我們 立足於業界的根本，僅僅這一個原因就足夠了。

5 效率

5.1 高效會議

“當一艘大船即將沉沒時，需要的是發號施令的船長，而不是坐下來開會。”

現實中，我們往往把大把的時間都浪費在了低效的會議上。很多公司都不會開會，也絲毫不會發現低效會議背後的成本問題。我一直在實踐高效會議的方法，以下是個人的經驗分享：

常開會，開小會 這裡所說的小會，其實更準確的說法應該是“快速簡報”。定期進行快速簡報，做到問題早發現，小的問題早期處理，大的問題集中開會討論，可以減少“重型”會議的頻率，並縮減缺陷修復週期和成本。
六頂思考帽 在會議上，使用“六頂思考帽”方法，可以使會議更為高效，結論更為可靠，利於解決實質問題。（我的博文“ 六頂思考帽”給我的啟示 ”）
抓住本質 不用花費精力過分地修飾會議上使用的文件，尤其是技術會議，我們需要的是準確的圖和表，而不是動畫。文件主次清晰，結構分明，字型大小合適即可。
5.2 高質量文件

文件體積不等同質量 本著“沒功勞也有苦勞”的想法，大量低質量文件全無重點，廢話太多。
格式不可少但內容更重要 滿足範本要求只是最基本的，內容才是文件的核心。
不能超越文件的範圍 只寫該文件包含的內容，不寫多餘的。
應該主次分明，而非流水賬 把每一個小事情都匯抱的很負責，只會挑戰讀者的耐心。
圖表更有力 多用圖和表。
5.3 快速反饋

復缺陷的成本隨著“從引入缺陷到檢測到缺陷這間的時間”變長而急劇增加。（就像放射性物質在食物鏈中的沉積一樣）

類似的，在專案管理中我們需要建立數個快速反饋環，諸如：

開發團隊與測試團隊之間 實現缺陷的跟蹤、指派、追溯，提高缺陷修復率，防止蔓延。
測試（部署）團隊與關鍵使用者之間 快速蒐集使用者反饋，對使用者進行指導，並及時通知使用者釋出新版本的時間，更新內容。
專案經理與關鍵使用者之間 及時收集和處理變更，及時通知使用者變更的處理情況，讓其瞭解專案的進展（主要是讓其知道我們在做事，從而放心）。
專案經理與開發團隊之間 瞭解團隊現在，傾聽內部的聲音，及時溝通並收集意見，預防人員流失。
6 溝通

6.1 入職座談不可少，離職座談更重要

入職一週後與離職前需要進行座談。

每個人到達新環境都多少會有些不適應，加之程式設計師喜歡獨自悶頭做事，新人入職後需要額外的關注。需要在一週左右，與新人談心，瞭解其是否遇到問題，並徵求其對專案團隊建議。這樣既可以，讓新人儘快融入集體，減少團隊震盪的時間，又可以進行過程改進以提高功效。

離職談話比入職談話更重要。人員非正常流失，一定有其原因，必須通過離職談話找尋問題的癥結，好對症下藥，進行持續的過程改進。此外，對銷售來說的“每一個人都是潛在的客戶”同樣也適用於我們，也許下個專案他就是你的專案干係人，IT圈子本就不大，我們需要朋友。

6.2 駕馭“牛仔”

“牛 仔”特指那些在團隊中，特立獨行的硬手，他們精通領域技術，有出眾的能力和工作熱情，而且多少會有些難以融入集體。雖然，牛仔們與專案經理的戰爭時常爆發（主 要是技術上爭論），但我認為他們是真正的團隊之寶。因為他們是真正的資深專家，而且往往具有更高的質量標準，他們常常發現那些別人容易忽視的質量缺陷，或 者有更好的寫法，能夠提出中肯的建議，能在技術問題上提供比較可行的解決方案。但是，性格使然，大多數“牛仔”都多少會有這樣一種想法，別人的技術不如 我，我說的才是正確的，我不能降低自己的標準。這種心理導致了他們難以融入團隊，並時常引發爭論。以下分享我與“牛仔”接觸的方法：

認同“牛仔”的能力，尊重他們的建議 大多數牛仔追求的是團隊的認同感，而不是薪水，認可他們就是對他們最大的尊重。
讓其獨立完成某些複雜的核心功能 他們喜歡挑戰複雜的任務，而那些C\V（複製、黏貼）的工作讓他們感覺自己在浪費生命。
量才使用，酌情授權 他們在某些領域往往能達到一定的程度，根據其能力可以授權其負責某些程式碼質量或設計方面的工作，這樣不僅能讓他們感覺自己的能力被團隊認可，同樣也能利用 他們的“高質量標準”心理來提高程式碼質量（注意凡事有度，讓“牛仔”做程式碼審查需要事先與其溝通，因為他們可能不會顧及別人的面子，而採取非常直接的溝通 方式，比如激怒那些年紀大的開發者，所以相對於“程式碼審查”他們更適合“技術培訓”以及“設計評審”。）
6.3 如何面試

首先，我們只負責技術面試不要和應聘者溝通工資問題；其次，以下步驟，如果有未通過的，就沒有下一步了。

第一步：破冰消除面試者的緊張感，一般是讓面試者自我介紹下。

第二步：試探簡歷是否造假方法一，人對數字的記憶比較模糊，如果簡歷造假，那應聘者就會對簡歷上虛構的數字比較模糊；方法二，對簡歷上的專案經驗有針對性地問詢，看是否符合行業慣例。

第三步：能力評估結合筆試內容和崗位要求考核應聘者是否有能力勝任當前崗位，一般是純技術性的探討。

第四步：答疑介紹崗位或工作描述並回答應聘者問題 。

6.4 排除“資源”是最壞的做法

當 我們的開發人員無法勝任他的角色時，我更傾向於安排培訓，而不是招募新人。說實話，看不懂現在的行情。大量的開發者湧入社會，他們對新技術誇誇其談，但確 不明白自己寫的程式碼在幹些什麼。我也負責面試，在年輕的程式設計師中，基礎好的已經越來越少了。所以，不要寄希望於能通過裁員並從新招聘來解決資源技術能力不 足的問題。看過《人月神話》的同學們，都應該知道——往一個進度落後的專案裡注入資源，只會使進度更加落後。所以，當發現“資源”能力不足，請優先考慮培 訓，培訓老員工的成本和週期要比新員工低的多，若培訓不合格再考慮進行招募。