我眼中的PM

1 我眼中的PM

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

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

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

1.2 不是所有人都適合PM

　　我認為PM需要具有以下天生的品格：

• 真誠?真誠自不用說，這是每一個管理者都應該具備的，最基本的不能被后天習得的能力。
• 骨氣?血氣之怒不可有，義理之怒不可無。PM必須有勇氣對不合理的要求說“不”，必須敢于維護團隊的利益。
• 堅毅?PM必須能抗壓力，即使是項目這條大船正在沉沒，PM也應該以超乎常人的勇氣與決心來發號施令。

1.3 雖然理論很重要但更重要的是經驗

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

1.4 管好項目首先要管好自身

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

1.5 找尋平衡而不是最優

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

1.6 “四拍主義”不可留

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

2?Open Mind

2.1 海納百川，取長補短

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

2.2 學會思考

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

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

2.3 心理學其實很有用

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

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

2.4 前期準備為自己

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

2.5 質量很重要

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

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

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

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

2.6 落地的才是成果

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

2.7 代碼審查好過測試

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

3?工具

　　PM需要掌握常用工具的使用：

• 開發工具?如VS，Blend，代碼生成器等。
• 管理工具?如SVN，TFS，Project等。
• 文檔工具?如Visio，Rose，Excel等。
• 部署和發布工具?如IIS，Sql Server，Win Server等。

4?團隊建設

4.1 尊重你的同僚

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

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

4.2 了解你的同僚

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

4.3 永遠追求多贏

　　“真正的團隊需要同舟共濟?！?/span>

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

5 效率

5.1 高效會議

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

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

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

5.2 高質量文檔

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

5.3 快速反饋

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

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

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

6 溝通

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

　　入職一周后與離職前需要進行座談。

　　每個人到達新環境都多少會有些不適應，加之程序員喜歡獨自悶頭做事，新人入職后需要額外的關注。需要在一周左右，與新人談心，了解其是否遇到問題，并征求其對項目團隊建議。這樣既可以，讓新人盡快融入集體，減少團隊震蕩的時間，又可以進行過程改進以提高功效。

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

6.2 駕馭“牛仔”

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

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

6.3 如何面試

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

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

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

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

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

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

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

轉載于:https://www.cnblogs.com/sczw-maqing/p/3191471.html

總結

以上是生活随笔為你收集整理的我眼中的PM的全部內容，希望文章能夠幫你解決所遇到的問題。

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