是什么讓PM成為一個偉大的PM？
英文原文：What makes a PM a great PM
在正式進入這篇文章之前，我首先要聲明，以下內容純屬我個人主觀的觀點。我認為自己很幸運，因為我擔任過產品團隊的 PM，并且目前我成為了一個內容團隊的 PM，這個博客帖子是我對這兩個完全不同的組織的親身體驗。
如果你還不知道微軟 PM 職業的歷史，那么你可以先閱讀 Steven Sinofsky 寫的這篇文章。和 Steven 一樣，幾年前，我從 SDE 轉變為 PM，這是一段很有啟發性的旅程。
首先，一個偉大的 PM，360 度無死角地了解他們工作的產品。當然，一開始的時候，你可能會想——“既然我的目標是這一個功能，那么我將重點放在這個功能上就好了”。是，也不是。你會發現自己正陷入一大堆的產品難題中，你的問題需要在更大范圍內才能完美地解決。這意味著你需要知道產品的使命是什么，哪些關鍵部分構成了這個使命并推動了這個使命的發展。我們很容易給自己畫一個范圍——但請不要這樣做。不要再有諸如“那個不是我負責的，我不管”的想法——可能這個不是你負責的，但是你得明白沒有一個功能是獨立的。
在你剛開始你的事業，或剛過渡到 PM 角色（也許是同一個團隊，也許是不同的團隊）的時候——在水平化的產品空間上構建工程和管理的密切關系。就像我在《my PM internship at Microsoft》這篇博客中提到的，關鍵是你要敢伸出手去學習，學習再學習你正在工作的產品，尤其是這個產品已經在市場上擴張過一段時間了的。誰是你的用戶？他們有什么習慣？有哪些首要的交叉問題？你需要開闊自己的眼界去認識到，你發布一個看似封閉的組件會產生多大的影響。
另一個我認為偉大的 PM 需要具備的特點是應用軟技能的能力。如果你還不知道軟技能的意思（想要知道更多，可以看這篇文章），那么我告訴你，軟技能至關重要的是培養溝通技能，培養團隊合作的能力，展示信心，耐心，演講技巧，最重要的是——要對客戶感同身受。項目經理往往是一整個項目的代言人——你表現自己的方式就是你表現產品的方式。此外，產品的目的是提供價值給最終的用戶，所以你絕對必須緊密聯系那些真正使用團隊工作成果的人。
再談一談在一定程度上的多面手。這在不同的團隊，組織，甚至公司之間可能都會有所不同，但我堅信，一個偉大的項目經理得能夠在需要時快速地學習和轉換環境。從我自己的經驗來看，我常常需要寫規格說明書，經常需要為團隊編寫代碼和構建工具（如 Hummingbird）。一個偉大的項目經理不會回避這些并非 100％ 屬于這個角色的事情。是的，當然——在面對這些其他事項的時候，你得確保將事情按優先順序安排好，還有平衡責任，使得能對產品和公司產生最積極的影響，但這往往意味著需要跳出項目經理刻板的思考方式。
還有一點很有趣的是，之所以會創造 PM 這個角色，是因為工程師同時需要做太多的事情，有太多與產品相關的任務需要他們解決，白天的時間完全不夠用。引用上述 Steve 帖子中的話：
項目經理一職起始于微軟為 Macintosh 開發 Excel 的時候。當時公司面臨的挑戰是，我們不知道該如何推動技術的藝術狀態（使用新的圖形用戶界面的概念開發一個標志性的新 OS），開發人員在努力開發新的電子表格和建模算法的同時，根本就擠不出時間去做打印、展示、顯示圖形等工作。
所以本質上，PM 是負責看賽馬，分析數據，并確保他的馬（在這種情況下——指的是產品）具有最佳的品質，能夠一直取得成功。為了做到這一點，一個很大的 PM 必須能夠快速評估進程的不同方面，并在必要時作出調整。這在現在比 10 年前更為重要，因為現在如果產品開發或規劃中出現失誤的話就會耗資數百萬，并且結果除了浪費時間之外，毫無裨益。
偉大的項目經理不是因為等級制度的利益而存在，而是為了帶動產品的更大視野。大約是在去年的同一時間，Zach Watson 發表了一篇名為《Are Project Managers Irrelevant》的文章（于是，我認識到 Project Manager!= Program Manager），文中的觀點是：
我們現在越來越明顯地看到千禧一代（1980 年后出生、在優渥環境下長大的一代）——將成為今后幾十年的主要勞動力，他們并不僅僅是因為等級制度帶來的好處而喜歡等級制度。他們對技術的不斷追求出自于內心對精英體制的渴望——即使某人有更高的頭銜，千禧一代也并不會認為這個人的專業知識永遠正確。
上面的例子說明了項目經理被定位為具有一定優越度的員工，統領他下面的一切事務。但是 PM 的情況又有所不同，PM 沉湎于產品和公司文化，一種他們的團隊有許多共生鏈接卻沒有必要堆疊在彼此的頂部的公司文化。期望工程師站出來對執行用戶研究，驅動科研需求，分析產品情緒，分析傳入的遙感數據等許多在實際構建產品時的職責負責，是不切實際的。上面那篇文章隨后談到了以下這個領域：
在這個意義上，項目經理不再履行其作為輔助人員的角色，而是成為了創新和生產力過程中的推動力。在敏捷性被等同于創新的領域中，壓制團隊成員的速度被視為不可饒恕。
不讓項目經理擔任輔助人員是一個組織問題，而非角色問題。如果你想要為組織找輔助人員——那可以通過嚴格的面試以及面試后工作來篩選。要充分認識到，項目經理并不是為了跟蹤時間和微觀管理產品的每個方面，恰恰相反的是，項目經理得能夠讓他們的工程團隊在產品生產中實現 100％ 的潛力，同時確保應用潛力到正確的事情上。
有一個蠻有趣的觀點，一篇來自于《Harvard Business Review》的文章詳細介紹了 2002 年谷歌如何決定精簡他們的組織：
在 Google 創辦的早期，整個公司的人都在紛紛質疑經理人的價值。這種懷疑源于一種高度的技術官僚文化。作為一個軟件工程師，Eric Flatt 這樣說道，“We are a company built by engineers for engineers（我們是一家由工程師為工程師而創建的公司）”。并且大多數工程師，而不僅僅是那些谷歌的工程師，更希望把時間花在設計和調試上，而不是與老板溝通或監督其他工作人員的進展。在他們的心中，他們深信，管理弊大于利，會干擾具體的、以目標為導向的任務。
在公司設立了 PM 一職若干年之后，創始人 Larry Page 和 Sergey Brin 開始懷疑谷歌是否真的需要任何經理人。因此 2002 年的時候，他們試行了一個完全扁平化的組織結構，摒棄了工程管理人員，目的是為了打破壁壘，加快思想開發，復制他們在研究所自由的共治氛圍。此次實驗僅持續了幾個月：他們后悔了，因為有太多的人直接去找 Page 報告有關費用，人際沖突，以及其它具體細節性的問題。隨著公司的成長，創始人很快意識到，經理在許多其他重要的方面作出了貢獻——例如，通過溝通策略，幫助員工優先安排項目，促進合作，支持職業發展，確保進程和系統與公司的目標一致。
無論正在開發什么樣的產品，總需要比工程面對更多的面孔。而這正是真正偉大的項目經理大放異彩的地方。現實的情況很簡單——PM，在默認情況下，授予了足夠的靈活性，但在同一時間——有其職責，定義了他或她的角色。
偉大的項目經理是可以培養的——我正在努力成長為一個最好的 PM——這里有一個學習曲線，該曲線可以讓你盡快進入 PM 這個角色。從長遠來看，這將幫助你提升團隊的價值，并愛上這種駕馭團隊的感覺。
最后但并非最不重要的一點是，一個偉大的 PM 總能找方法來實現目標。底線是——要有交付成果，否則你發多少封電子郵件，安排了多少次會議，和多少人交談都毫無建樹。在這種情況下，你應該了解周圍環境，制定相應的計劃——你需要聯系誰，什么時候需要一些額外的幫助，以及什么時候終止功能和組件的業務？
上面該說的也已經說完了，我盡可能長話短說，并側重于在過去一年半時間里我注意到的幫助了我很多的關鍵環節。也許一年后，我會再想回來修改這篇帖子，添加更多的經驗和教訓。當然，各位如果有什么好的意見和建議，也請不吝指教。
-
譯文鏈接：http://www.codeceo.com/article/what-makes-a-pm-a-great-pm.html
翻譯作者：碼農網 – 小峰
來自: www.codeceo.com