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

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

　　時光飛逝、日長年短，中午沖涼的時候無意中想到從正式入職公司、開始工作到現在居然已經1年多了，是不是該回頭看看、整理整理總結總結了，同時，也希望把自己的經驗和經歷與對這個行業感興趣的同學們分享。

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

　　1) 產品經理的工作內容和范圍

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

　　3) 心得體會

　　4) 其他經驗分享

　　第1、2節分享給對這個行業感興趣的學弟學妹和剛入行的同學們，第3、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)需求從哪里來?

　　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. 領導那里會有關于市場、產品今后發展方向的更多的信息，因此他們會幫助你評估這些需求是不是符合當前產品的發展方向、會不會/會如何影響到公司/部門在這一個點上的定位和布局、會不會比他們對這個產品的期望不符。

　　具體這一步的流程和在項目循環中的位置，在后面一節“項目相關的流程”那里會進一步說明。

　　二、開發過程

　　與上面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的主要作用，而實際工作中一般要處理的事情會更多一些。

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

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

　　另一方面，用戶數據可以簡單直觀理性的證明給我們自己和各級相關同學：我們在做的事情是正確的!是有價值的!是想著光明的方向的!這些數據幫助你看到用戶真實的想法，即使你在網上看到一堆人罵一個功能沒用僅僅噱頭，但看到數據顯示92%的用戶會頻繁的使用該功能，你心里會不會踏實很多?

　　這里大概說一下吧，一般情況下我們更關注規模數據、操作數據和運營數據，其他的還好。

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

　　數據這里比較敏感就不細講了，感興趣的同學可以在網上找找書什么的，或者在工作中自行摸索。

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

　　#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點多的時候差不多就要開始腰背酸疼了…然后要挺到8、9點…)

　　結合上面提到的“效率與質量、工作與生活”的章節，盡量給自己的生活留下充分的時間。培養至少一種自己愿意堅持的運動類型，這樣不僅可以強身健體，更可以換換心情。

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

【前小米產品經理在騰訊工作一年的工作總結】相關文章：

產品經理的工作總結01-23

產品經理工作總結02-20

產品經理工作總結09-09

產品經理的工作總結[熱門]01-15

數據產品經理工作總結03-16

產品經理工作總結范文03-07

騰訊產品及游戲策劃筆試題目09-22

產品經理個人工作總結05-20

產品經理工作總結怎么寫04-11