前小米產品經理在騰訊工做一年的工做總結！

　　時光飛逝、日終年短，中午沖涼的時候無心中想到從正式入職公司、開始工做到如今竟然已經1年多了，是否是該回頭看看、整理整理總結總結了，同時，也但願把本身的經驗和經歷與對這個行業感興趣的同窗們分享。

　　這篇很長的文章將分爲4個部分：

　　1) 產品經理的工做內容和範圍

　　2) 產品經理的工做方式和方法

　　3) 心得體會

　　4) 其餘經驗分享

　　第一、2節分享給對這個行業感興趣的學弟學妹和剛入行的同窗們，第三、4節(也是本文的重點所在)整理分享了本身工做一年多來一些主要的心得體會和經驗。

第1節產品經理的工做內容和範圍

　　這一節主要解釋了產品經理是作什麼的，這是一個入門級問題，可能對學弟學妹比較有用吧。可是要注意的一點是，因爲行業很大，隨着細分領域的不一樣(桌面產品、web、遊戲、移動終端等)、公司的不一樣、甚至部門的不一樣，不一樣的產品經理的職責也不盡相同，因此felix所寫的只能表明在騰訊的產品項目制度下，移動客戶端產品經理的工做內容。因此，當如下出現PM(產品經理)這個字母組合的時候，你要在大腦中的替換爲：騰訊模式下移動互聯網客戶端項目的產品經理。

　　1)挖掘用戶需求，撰寫需求文檔;

　　2)跟進產品開發過程，與項目組內各種角色成員合做以確保產品開發的順利進行;

　　3)跟進發布過程，確保產品順利發佈;(包括髮布策略的制定)

　　4)產品相關數據的監測和分析;

　　5)行業、市場及競爭對手的監測和分析;

　　6)聆聽並回複用戶的聲音，發現產品問題和篩選有價值的需求;

　　7)與公司內外部的產品進行功能層面上的互利合做;

　　以上，1～7的部分是一名客戶端產品經理必須處理好的基本工做內容，此外，還有一些事情PM也是要或多或少參與的，只是根據產品形態、公司/部門的大小，會有一些專人去作這些事情，所以PM在這些事情中的參與度會小不少：

　　a)產品的市場宣傳相關內容

　　重點在宣傳：品牌的創建和推廣、對企業等組織進行宣傳合做、對終端消費者進行宣傳合做、同時研究消費者內心

　　b)產品的市場拓展相關內容

　　重點在拓展市場：具體到移動互聯網上的客戶端產品，就是經過投入資源與手機廠商，或者產業鏈其餘環節進行合做幫助產品經過廠商內置、後置等渠道拓張市場份額;

　　c)產品的商務拓展相關內容

　　重點在商務：根據產品形態的不一樣，不必定會有這樣的部門。做爲接口，它鏈接產品項目組和外部的與咱們有商務合做的組織或我的

　　d)產品的渠道推廣相關內容

　　重點在推廣：動用各類渠道類資源，幫助產品擴張市場份額;緊跟市場大盤，預測市場發展規模並制定相關策略

　　e)產品的內容運營相關內容

　　重點在運營：根據產品形態的不一樣，緊跟社會熱點進行內容類的運營，通常意義上而言，對於大多數半年以上的產品，內容運營相當重要。(如何處理產品的可運營性和功能特性之間的關係也是PM要花時間細想的領域，這是後話)

　　以上，a～e的部分則一名PM或多或少要參與其中的工做。

　　因此小結一下，一個PM的工做範圍是以上1～7和a～e的和，而主要的工做內容(也是花時間最多的部分)是1～7的部分。

第2節產品經理的工做方式和方法

　　第1節概要性的描述了PM要作什麼，而這一節則主要描述PM會怎麼作。與上面1～7相對應的順序。

　1、需求撰寫

　　1)需求從哪裏來?

　　a. PM根據本身的專業素養(也就是感受)體驗本身產品和市場上其餘產品時發現的問題或是靈感閃現出的關鍵點;

　　b. 各級產品領導的直接反饋和建議

　　c. 用戶使用中遇到的問題、困惑、以及反饋很是須要的功能點

　　d. 行業最新的動向

　　固然，以上僅僅說明了需求的來源，這大量的需求最終在前線PM這裏彙總，PM根據本身的專業能力對需求進行篩選、優先級劃分、推理權衡和細化，並時刻與產品核心路線進行對比校訂，最終拿出產品下一步發展的方案;

　　2)怎麼寫?

　　a. 主要工具

　　word、ecxel、ppt什麼的、原型設計類的軟件，這些都不重要。因此你能夠自由的選擇本身須要的工具、軟件、甚至系統，本身順手就好，因此建議時不時的換一換工具換一換心情。

　　b. 寫做技巧

　　#1 開始寫以前，必定要在本身的腦子裏完美的想好這個功能點的方方面面(或者至少想個80%)，各類可能、各類異常處理都要想清楚;

　　#2 寫做的時候，要儘可能清晰全面的把想好的東西寫出來:

　　#2.1 清晰是指邏輯清晰，必定要讓交互、設計、開發、測試同窗能很好的理解你想要傳達的想法;

　　#2.2 而全面是指詳細，必定要詳情，很是很是的詳細，需求產生的背景、要怎麼改善、爲何這麼改善、這麼改善後指望達到什麼樣的效果、觸發條件呢(前置後置)、具體怎麼改善呢(最大量的寫做工做、事無鉅細描述清楚你的邏輯、同時考慮全部的異常狀況)、必要的流程圖、適當的最終效果(這裏後面還會有說起)等等等等

　　#2.1和2.2是一名PM專業程度的體現，必定要拿出邏輯清晰的文檔，由於你是本身產品的上帝，你的每一處邏輯都會影響到千千萬萬在這種邏輯下生活着的終端用戶，經過完美的邏輯，概念設計一個完美是世界是這個工做最有價值的部分之一，但是最快樂的部分，不要錯過它。

　　#3 寫做以前和寫做以後

　　#3.1 真正動筆寫做以前最好能先把你的想法和涉及的開發、交互溝通一下，初步斷定一下可行性，不然天馬星空的設計若是最終被開發斷定實現不了，或者實現的成本高於你的預期，就要再斟酌斟酌了。

　　#3.2 寫做以後的流程

　　本身寫出來的東西還不能直接拿給項目組開始開發的流程，還要至少組織一次會議請同爲策劃的同事、需求相關的同事和各級領導進對你寫的東西進行一次評審，這樣作的目的主要有3個：

　　a. 幫助你檢查需求的嚴謹性，找出錯誤和漏洞，討論出更優的方案

　　b. 知會到需求相關方，也就是這個需求會涉及到的項目組之外的其餘組織的相關同窗，在正式開工前聽到他們的意見，一方面能夠根據他們的現實狀況對需求作一些調整，另外一方面能夠與他們約定好後續的合做方式、須要的資源，對方準備也須要一個時間

　　c. 領導那裏會有關於市場、產品從此發展方向的更多的信息，所以他們會幫助你評估這些需求是否是符合當前產品的發展方向、會不會/會如何影響到公司/部門在這一個點上的定位和佈局、會不會比他們對這個產品的指望不符。

　　具體這一步的流程和在項目循環中的位置，在後面一節「項目相關的流程」那裏會進一步說明。

2、開發過程

　　與上面1～7相對應相對應，如今咱們開始討論第2個部分：開發過程。開發過程是咱們的產品從概念變成真正可販賣的工業品中必不可少的神奇一步，是多種不一樣分工、不一樣專業背景的同窗在一塊兒協同工做的過程，很重要。後面會以以下的一個目錄方式逐步講解這裏的細節：

　　1)項目的概念

　　2)項目組

　　#1 人(資源)

　　#2 流程(人和人之間如何協同)

　　3)PM在開發過程各個階段中的做用

　　#1 需求階段(需求方全體確認需求)

　　#2 開發階段(開發團隊集中開發階段)

　　#3 測試階段(質量檢查的階段)

　　#4 發佈階段(內測、灰度、正式發佈等逐級發佈階段)

　　#5 發佈後的階段(效果跟蹤的階段)

　　下面會根據這樣一個目錄進行說明：

　　1)項目的概念

　　項目的概念相對簡單，能夠理解爲一個話題或者主題，不少人爲了同一個目標、同一個主題、一樣的利益和願景聚攏在一塊兒造成了項目組。這一點和公司等任何組織的造成相似。

　　2)項目組

　　#1 人(資源)

　　項目組裏有不一樣的人，通常來講，一個處於開發循環中的核心項目組包括了這樣的一些人：產品經理、視覺設計人員、交互設計人員、開發人員(前端開發、後臺開發)、測試人員、項目經理等。

　　所謂的開發循環中的核心項目組是指一個造成一個產品所須要的最少(最標準)的人力配置結構，固然一個更寬泛意義上的項目組還包括了不少不少其餘角色：運營、渠道、運維等等等等;

　　這些角色在開發循環中(顯然，不在循環中的時候某些角色還有本身的獨立於項目組以外的工做)的主要職責是：

　　a. 視覺設計人員(視覺設計，你看到的幾乎每個優美的圖案)

　　b. 交互設計人員(交互設計，你在使用產品過程當中哪些舉動能夠得到反饋以及以什麼形式得到什麼樣的反饋)

　　c. 開發人員(前端開發同窗的成果就是你拿到的最終安裝包、後端開發同窗的成果則是在服務器端的邏輯，離你看起來很遠，但實際上息息相關)

　　d. 測試人員(寫過程序的同窗都清楚，開發過程當中不免會有各類各樣的問題，有些很容易看出來，但有些要經過必定的測試手段和方式才能找出)

　　e. 項目經理(成熟穩健的項目經理對一個團隊來講很是重要，人力資源在項目中的保證和調配、確保項目中涉及的各流程的順利運行，以及處理好項目組內成員及其分別的外部支援團隊與項目組之間的關係，這些是項目經理工做的內容，因此你看到了與項目經理良好的互動和項目配合對PM的工做會有很大的幫助)

　　##題外話一下，項目經理的英文 Program Manager,產品經理的英文 Product Manager，因此你看到二者若是英文縮寫的話會很像，所以不一樣的公司都會想辦法在英文名上對這二者進行區分，在騰訊，公司制度上項目經理縮寫爲PM，而產品經理縮寫爲PDM，但實際上不管是在行業內仍是在公司內，你們仍是老是喜歡叫產品經理爲PM。因此如下我會繼續這樣寫。

　　#2 流程

　　互聯網產品的一個典型的項目組內環形開發流程是這樣的：

　　需求的撰寫和定稿--》交互設計和視覺設計--》開發--》測試--》發佈--》新的需求的撰寫和定稿……

　　##因此你看到了，需求階段是整個環形開發的起點，所以當你綜合考慮PM的職責和他在開發流程中這樣特殊的位置時，就會明白他是很不容易的，有不少事情須要他來處理和承擔責任(背黑鍋而受到指責什麼的……因此新手特別是畢業生產品經理是很艱難的，類比導演專業一畢業就帶攝製組出去拍攝，艱難程度可想而知，所以對於新手，在你從業的前半年到一年的時間是須要準備好隨時接受來自項目組內外的壓力，這裏冷暖自知了，最後第3部分心得體會和你們分享一點點)

　　那個循環開發流程只是說項目組內須要一同經歷的流程，也就是說爲了協調你們各類角色的時間、更好的進行協同工做所須要的循環流程，但實際上項目組內的部分同窗，除了這個流程之外，在這裏的項目組裏天天每週都還有無數其餘的流程要走。與項目相關的，好比PM在本身的組內有需求評審的流程、好比交互設計師和視覺設計師分別在本身的視覺/交互組內都有各自的評審流程;

　　3)PM在開發過程當中各個環節中的做用

　　#1 需求階段

　　#1.1 加工從各個需求渠道過來的需求、撰寫需求的部分就不說了，上面已經講到了

　　#1.2 帶着寫好的需求文檔通過需求評審的流程，並根據評審的建議或意見進行修改，直到達成一個絕大多數人都可以承認的需求;

　　#1.3 和交互設計師深刻交流，不要只說你要什麼效果，而要全面的講講爲何要這樣作，你達成一個什麼樣的目的，這樣能夠更好的藉助交互設計師的專業知識，能夠提供給你和他更開放的思路一塊兒想出可能原先想都想不到的更好的實現方案。

　　## 題外話一下，若是你所在的公司和部門在你所在的項目中提供了專職的專業交互設計師，那麼建議在寫需求文檔的時候可使用一些低保真的原型工具(低保真!)，而不是Axure由於這樣會限制你和交互設計師、以及在需求評審階段的每個人的思惟，這絕對不是你想要的效果，因此，試試低保真的原型圖吧

　　#1.4 和視覺設計師深刻交流，不要說你想到哪裏用什麼顏色，一樣，儘可能說說你想到達到什麼樣的效果，至於配色什麼的交給視覺設計師吧

　　以上1.1～1.4的部分纔是一個完整的需求方肯定需求的部分。

　　#2 開發階段

　　#2.1在問題出現時權衡取捨、作出決策

　　開發過程當中，隨時會遇到概念設計階段想不到的新情況，好比開發同窗開發過程當中發現有的地方很差處理、或者有的地方有兩種以上的實現方案可是都有優缺點、或者某些地方要是真按照需求文檔那樣寫會有一些潛在的風險，而以上的任何一種狀況出現，都須要你，一個一線PM根據本身的經驗和感受、根據產品方向和核心價值進行權衡取捨後給出直接明確的答案：作或者不作、選A方案或是B方案、哪些損失是值得的。

　　#2.2 保證資源及時到位

　　#2.2.1 及時與某些項目資源輸出方溝通

　　保證資源的到位是項目經理的職責，但實際上產品經理也要深刻的參與其中。好比設計資源的到位狀況，項目經理會保證在一個時間段內這個設計人力能夠100%的屬於這個項目組，可是在設計師動手以前你須要與之充分溝通，確保設計師與你向着相同的方向在努力;而當設計師輸出設計資源之後，還要根據設計資源的質量(也就是可否知足須要、是否契合PM但願達到的視覺氣質等等)反覆與設計師溝通，這個過程可長可短，而項目組後續的不少工做都有可能卡在這裏，因此PM在這裏也有責任保證資源的保質保量及時的輸出。(##題外話，因此如何保質保量及時也是一個問題，這裏涉及到「信任」和「妥協」，在第3部分心得分享的模塊，會作進一步說明)

　　#2.2.2在項目過程當中隨時與項目資源輸出放溝通

　　既然如上所說，開發過程當中隨時都會有新的問題，都會有項目內外部各級的同事領導體驗反饋出問題，那麼相應到，不少資源上的新需求，也是在項目過程當中隨時產生的，當有此類場景出線時，及時與相應的資源輸出方(通常是交互和設計)進行快速有效的溝通很是必要。

　　#2.2.3 及時審覈確認

　　天天項目都會有新的進展，天天都會有一些功能點完成、一些修復優化的點開發好，所以及時的審覈確認也是PM工做的一部分，不然等到了測試階段或者上線前的階段再發現一些重大問題(或是與需求文檔不一致的地方，你會發現這種事情時有發生)就會形成很大的修復成本，時間、人力、項目組的信心、PM被信任的指數等等等等都有可能受到不一樣程度的傷害，所以這也是一個很重要的部分。

　　#2.3下一個循環也在同步的進行

　　移動互聯網市場正在突飛猛進的迅猛變化，當前行業裏最雄厚的資本、最傑出的人力資源都在以極快的速度向這個領域內彙集，所以騰訊MIG去年常說的一句話就是「快比什麼都重要」，因此具體到騰訊的模式下你會發現以兩週或者三週爲週期的項目組開發週期很是的廣泛(記得一年多之前還有2個月多一個週期，那個時候PM還有喘口氣的時間，這是題外話了)，所以做爲一個PM，在一個正在進行中的項目週期中，你除了要作到上面的#2.2.1~2.2.3以外，還在同時爲下一個項目週期作好準備，開始進行需求的撰寫、評審以及其餘的需求方流程。

　　#3 測試階段

　　通常來講，在前期開發過程當中，PM會進行高頻率的產品自測，也就是上面的#2.2.3所描述的部分，而到了真正的專業測試階段，PM介入的就比較少了，專業的測試人員測試出問題後大部分狀況會直接反饋給開發同窗，只有當有不少不少問題開發同窗作不完須要PM排優先級的時候、或者是有些優化點優先級低可是可能意義非凡時，須要PM來作一些時間和效率上的取捨。(關於質量與效率等問題，在第3部分心得體會那裏也會有說起)

　　#4 發佈階段

　　通常狀況下，在通過了專業測試以後的產品差很少就能夠發佈了，之後的過程可能不一樣的公司/部門都會有所不一樣，但大體上仍是比較類似的：

　　#4.1找一小撮玩家進行測試

　　能夠找公司內的同事，也能夠招募一些公司外部的玩家用戶測試，這一階段的目的是找出專業測試也沒有發現的重大問題(好比安卓平臺上因爲機型和系統的嚴重碎片化，很容易發生程序在某個特定機型上出一點小情況的事情)以及聽聽用戶對某一個新feature是否會有比較大的正向或是負面的反應;

　　#4.2 灰度發佈

　　仍是基於萬一出現問題時控制受衆範圍的考慮，通常咱們會採用灰度發佈的策略(固然這個策略的制定也是PM工做的一部分)，灰度策略制訂時通常考慮兩部分受衆：新增用戶、老版本用戶。新增用戶如何處理、什麼比例;老版本用戶如何處理、什麼比例，這些問題通常經過PM的經驗結合這款產品的用戶規模、所在生命週期的某一特定階段而制定。

　　#4.3全量發佈

　　灰度發到100%就是全量了，也有不通過灰度發佈直接全量的狀況。

　　#4.4其餘

　　固然，以上#4.1～4.3纔不會是咱們工做的所有，還有不少不少的事情須要你來作，好比提早一週左右輸出發佈計劃給全部相關部門和人員、發佈前的各類各樣的資料準備、發佈前和各宣傳相關的渠道的交流(微博、軟文、、)、發佈前準備好客服公告、新版本發佈時安裝包裏幫助文件的更新、發佈後信息知會給全部相關部門和人員等等等等。

　　#5 發佈後的階段

　　#5.1 效果跟蹤

　　能夠經過不少渠道直接或間接的得到用戶反饋，好比論壇、微博、Q羣、幫助社區、新聞(騰訊的產品不論好壞通常都會有或多或少的行業評論)、甚至家人、朋友、同事、領導等等等等。

　　#5.2 數據分析

　　畢竟只有血淋淋的數字才能直觀的證實一項新功能/改動的正確性和效果，所以版本發佈後的數據分析也是必不可少的工做。數據分析這裏至少將包括規模數據的分析、和各主要特性的分析兩大部分，固然用戶及市場反饋的部分也是一個重要的可選項。

　　以上1)～3)總體上概要性的描述了開發環節中PM的主要做用，而實際工做中通常要處理的事情會更多一些。

　3、產品相關數據的監測和分析

　　這一部分講到了數據，雖然在內心我傾向於認同PM(至少在需求的創造這一方面)其實是一種(感性的)藝術，不該該以數據來做爲惟一的判斷標準進行衡量，可是醒醒吧阿宅，經濟學常識告訴咱們，在一個市場經濟主導的經濟社會裏處於競爭環境中的企業內工做，這樣的環境註定了用數字說話才更有力量，由於數據才表明了收入和金錢，因此藝術只能讓位於商業，好吧，這麼說有點冷酷，那麼聽聽下面的說法：

　　另外一方面，用戶數據能夠簡單直觀理性的證實給咱們本身和各級相關同窗：咱們在作的事情是正確的!是有價值的!是想着光明的方向的!這些數據幫助你看到用戶真實的想法，即便你在網上看到一堆人罵一個功能沒用僅僅噱頭，但看到數據顯示92%的用戶會頻繁的使用該功能，你內心會不會踏實不少?

　　這裏大概說一下吧，通常狀況下咱們更關注規模數據、操做數據和運營數據，其餘的還好。

　　另外一方面，以什麼樣的週期來關注數據也是一門學問了，根據公司/部分/產品/數據種類的不一樣而不一樣。

　　數據這裏比較敏感就不細講了，感興趣的同窗能夠在網上找找書什麼的，或者在工做中自行摸索。

　4、行業、市場和競爭對手的監測和分析

　　#1 行業與市場

　　行業和市場信息的閱讀和了解其實沒有必要進行制度性的要求，只要平時多看看行業新聞就好，主要是培養本身的產品sense(這一點多用多想別人的產品也有很大幫助)和行業敏感度，這一點對熱心於這個行業的新同窗來講歷來都不是問題吧。

　　值得提的兩點是：

　　#1.1 兼容幷蓄、海納百川的心態

　　主觀上不要輕視任何一種創意和市場行爲，每一條科技新聞的造成背後都有一堆執着的人和必定的市場基礎，多看多想，不要急於否認和排斥，能夠多練習造成本身的觀點和判斷(這個階段不必定要分享出來)。

　　#1.2 行業敏感度的培養與驗證

　　當你對一個產品一個功能一種趨勢有了本身的判斷，即便身邊的人、項目組暫時不能接受，但市場終究會給出一個答案。若是你的預見，老是能通過時間的證實(好比一段時間後在競品的身上看到了本身原先的設計)，對本身自信心的造成會有很好的正向激勵做用。

　　#1.3 工具、方式

　　通常來講，做爲一個客戶端PM白天你幾乎是沒有時間用來看網頁看新聞的，因此你會比別人更須要一些移動智能終端設備好比iPhone、iPad什麼的，便於你利用一些碎片時間update到最新的資訊，不然本身會很快過期，逐漸陷入到本身特定的領域內沒法造成宏觀的視野，也會容易缺少自信，變得依賴於崗位。

　　#2 競爭對手的監測和分析

　　維護一張表格，週期性的檢查競品的動態，挑出一些你關注的點進行持續性的分析，知己知彼才能更好的戰勝對手。

第3節心得體會

　　如今回頭看，在前面的章節中大量的許了願要在第三節中進行心得體會的分享，千萬不要有太高的指望啊，只是felix本身在工做中的一些不徹底的感悟和總結(怎麼可能期待我在這樣的大半夜1點半回憶完整個這1年的經驗呢～呵呵)，不免會有偏頗和不成熟的地方(畢竟才1年級嘛，否則之後靠什麼吃飯)，僅供參考。

　　1)服務意識

　　第一點並無提MIG內部常說的「產品經理是火車頭」的概念，由於若是以那個觀點做爲出發點，操做層面其實比較走彎路，特別是毫無管理經驗的畢業生同窗。

　　因此根據本身長期的摸索，認爲以「服務意識」做爲一個PM心態的原點會比較好的應對面臨的問題。這麼想的緣由是：

　　#1 首先從新審視一下咱們的工做其實是要求面面俱到，在開發循環中的任何一個環節全權表明產品團隊和項目組在作一個一線的決策，所以可想而知天天可能每一個環節的同窗，包括各級領導都有可能來找你確認、查詢、解決、反饋一些問題。確實會很忙很亂時間徹底碎片化，有時也會由於老是被打斷正在進行的事情，和接到不少臨時性的任務而心煩意亂，因此這種時候若是認爲別人的「打擾」干擾了你的「正常工做」，那你就輸了，由於不斷被「打擾」，不斷被確認也是咱們工做的一部分，所以這種時候若是能認識到「個人工做就是一種服務性的工做啊呵呵呵呵」基本上心理會比較容易擺正心態。

　　#2 服務的心態能夠更順利的做爲一種內驅力，在項目組正常運行時提供助推劑;好比你不會專斷的任務需求的產生是你一我的的事情(雖然你確實收到了比較專業的訓練)，而是會用一種開放的心態與項目組內成員充分的交流;同理，不少事情，好比外部團隊幫助下制定的產品宣傳策略和品牌推廣活動，做爲一個接口人你也能夠開放的分享的項目組的其餘成員(固然雖然他們也許沒有時間看，而你也不必定有時間這麼作)

　　#3醒醒吧啊宅，不要被「Manager」兩字矇蔽了雙眼，IT業內(傳統行業那個就不提了)最先提出PM概念的微軟在設立「PM」這個職位之初的定位：爲工程師端茶送水、預約會議室、與其餘團隊交流以及幫工程師團隊承擔來自外部的壓力、並盡最大努力幫不善言辭的工程師們推銷他們的想法。so ，看到了嗎?其實這個職位從設立之初就是個服務性崗位，so，我把這一點做爲「服務意識很重要」的最重要理論基礎了。

　　2)「產品經理是火車頭」的理解

　　這一句話基本上在騰訊MIG內部常常被說起，你的各級leader、項目經理，甚至開發團隊潛意識裏都會反覆提到這個詞，因此做爲這句話所涉及的主體行爲人，PM會怎麼理解這句話呢?個人理解是：

　　#1 執行力

　　輸出需求的效力、保證需求儘快經過各類各樣評審的效力、保證需求所涉及的各種資源的正常按時輸出、保證對開發過程當中出現的問題的及時解決、保證發佈正常進行的效力、以及各類各樣你主要處理的事情的執行力，由於通常狀況下，對方的單線程和線性的，而PM會同時面對不少人不少件併發的事情須要解決，所以若是在某一個方面某一批人那裏出現延誤和沒有處理好的狀況，PM很容易被認爲執行力差……因此執行力是一個很重要的要求。

　　#2 積極的感染力

　　就是怎麼看怎麼以爲有精神，類比各種動漫中的熱血小強型角色;

　　#3 責任感

　　主人公的意識，積極的涉足、主導和解決不期而遇的問題，時刻從產品大局出發權衡取捨;這裏你們已經很熟了就不說了。

　　#4 固然，還有黑鍋

　　如上所述，既然不少不少人的不少事情都與你有關，那麼進度卡在你這裏、或者你沒有說清楚、或者你沒有提任務、或者你沒有早說……就都是你的責任了，這種狀況下一方面參考一下#1的解釋調節調節，認真你就輸了;另外一方面，能夠經過一些制度性的行爲爲本身提供支持，好比及時郵件什麼的。

　　3)信任、妥協、營造氣氛

　　這條几乎上升到了方法論的層面，這兩條其實說大很大說小很小，靈活應用的話效果會比較好。

　　#1 信任與妥協

　　上面第二部分說了，PM所在的項目組中有各類各樣的角色(項目組外也是)，每一個人都有本身的專業分工，所謂「術業有專攻」，其餘角色頂着本身的帽子、帶着本身的頭銜，必定是在本身的專業領域內受到多年理論和實踐打磨的，爲何你不相信別人的專業素養卻要求別人相信你的眼光?因此信任很重要。

　　因此畢業生PM來公司若是立馬就開始背誦「產品經理是火車頭」，而且但願本身在任何一個領域內的見解都被嚴格執行的話，基本上立馬會躺槍，由於你的見解在某一個特定的領域內是不成熟考慮不全面的，因此在有些時候當你意識到在這個領域內有更專業的人能夠貢獻力量的時候，「妥協」吧!由於你們的目標是一致的(妥協的理論基礎)

　　#2 營造氛圍

　　若是能在必定時期裏項目組內，特別是需求方內部(產品、交互、設計)你們都能比較好的作到信任和妥協，就有可能造成一個良性的循環，其結果是PM的工做會輕鬆一些，而項目組的效率會更高一些。(眼熟麼，有點像微觀經濟學博弈論裏囚徒困境中雙方互信時的狀況，各方的利益都能最大化而且組織的利益也獲得了最大化)

　　4)承受壓力

　　固然，你要作不少的事情，你要接觸不一樣的人，會會有很大很大的壓力，在上面的第2節、第3節的2)#3裏也略微講到了如何面對壓力。這裏再稍微說一下

　　#1 正向操做

　　#1.1 儘可能讓各級領導和你項目組中的同伴瞭解到你工做的內容(雖然很難，由於在項目跟進時PM的工做量很大但很瑣碎，每個點要花的時候都是不定且很難預估的)

　　#1.2 多和前輩溝通或者買些書來看，積累理論工具和有效的方法論。壓力不會憑空產生的，壓力必定是依託於某件或者某一些你可能面對不了的事情而發生的，由於你須要經驗的積累(理論工具!)和處理這些問題時可行的方法，這會更治本一些，從根本上減輕壓力。

　　#1.3 同理，爲了直擊壓力本源，你須要更好的解決問題，那麼能夠嘗試藉助更好的工具(新電腦、新鍵盤、iPad、Mac、)或者其餘人的力量幫你提升效率、分散壓力

　　#2 中庸緩和型操做

　　若是壓力太大，能夠看看電影逃避一下什麼的，或者洗個澡按個摩什麼的，或者找個哥們喝一杯什麼的、或者衝動性消費一下什麼的，或者暴飲暴食什麼的(雖然不建議)

　　5)平衡效率和質量、工做和生活的關係

　　#1 效率和質量

　　工做中的事情不少?並且老是在限定的時間內要求有結果，那麼其實對於PM來講隨時都在面臨一個效率和質量的問題，要效率高，必須趕在時間點到來以前完成手上的全部的事情，那麼每件事情的完成質量可能就會有誤差，不免有些狀況會不符合別人的預期;而若是重視質量，有絕無可能在限定的時間內完成咱們在上面提到的海量的工做，效率必然有損。因此如何平衡效率和工做是一個很重要的問題。若是達到這裏的平衡就要看本身了，若是處理很差很容易本身累死累活但吃力不討好。

　　#2 工做和生活

　　工做很重要，那生活呢?顯然，做爲一名PM你也許會不多會有休息的時候，週一到週五累死累活工做到很晚，週末兩天光是補覺洗衣服基本上就沒有時間了，這樣固然很差!時間長了，隨隨便便一個契機一個場景坐在那裏喝着咖啡就該開始走神感慨，個人生活爲何會是這樣?這是我要的生活嗎?若是不是，那這樣生活的意義何在?

　　因此爲了不這種困惑的發生，爲了緩解孤獨寂寞冷，儘可能調節本身的生活吧，給生活更多的時間。若是你沒有妹子的話，去找個妹子吧。若是你異地的話，找一種愛好吧，好比電影、運動、看書、桌遊或者單純一點：吃!

　　6)被信任

　　第3)點提到了信任，那裏的信任其實更多的是指PM對其餘成員和角色的信任，那麼反過來呢?如何被信任?

　　凡是講PM工做的書基本上都會提到PM我的影響力的構建，主要講得就是如何被信任這一永恆的話題。每一個人都會有本身的方法，但基本上都是要不斷的經過本身的努力累計被信任的成功案例來逐步達到這一點的。有點相似戀愛中的男方操做技巧不是嗎?

　第4節其餘經驗

　　這裏就很鬆散了，不能也不可能總結完全部的經驗，在操做層面出現的問題、總結的經驗仍是要本身親身體會會來的直接一些。因此像什麼會議以前xx、會議以後xxx，充分溝通，郵件電話之類的工做技巧就沒什麼可分享的了，並且隱隱以爲此類辦公技巧真的寫出來會被大牛嘲諷什麼的……

　　因此談談其餘一個更重要的話題吧，那就是健康!!!

　　# 健康

　　必定要保護好本身的身體，時常鍛鍊一下什麼的(雖然這一點我作的也不是很好，如今我坐到下午5點多的時候差很少就要開始腰背痠疼了…而後要挺到八、9點…)

　　結合上面提到的「效率與質量、工做與生活」的章節，儘可能給本身的生活留下充分的時間。培養至少一種本身願意堅持的運動類型，這樣不只能夠強身健體，更能夠換換心情。

　　沒想到一直連載了兩天，長達4次更新才寫完這篇文章，這一次總結的有點多了，下次吸收教訓框架能夠搭的小一點就不用這麼面面俱到了。