在畢業(yè)前的最后一個暑假，緣分使然找了幾個月暑期實習之后進入了去哪兒，申請?zhí)崆叭肼毠ぷ髦两裾脻M一個月。

原先有在行業(yè)內實習過其他崗位，后來一段時間對產品經理產生了無法克制的熱切，一度認為這是世界上最適合自己的職位，但是這只是停留在各大公司對外的招聘需求，以及其他人的分享之上。然而，這一個月的實際經歷，顛覆了原有對產品經理工作的臆想，當然熱情不減。

文章的初衷只是總結在去哪兒做產品的體驗，給那些想求職產品經理的小伙伴一些參照。

一、對產品經理的認識

曾經以為，產品經理是創(chuàng)造出萬人使用的產品，要去改變世界的人，以喬老爺子和張小龍為偶像，每天工作就是構想產品概念，然后做出原型，然而當時太天真。實際上，產品創(chuàng)造相對而言并不普遍存在，大部分時間，大部分產品經理的都是在進行產品的優(yōu)化。

據(jù)自己的認識，我將產品經理分為了兩類：優(yōu)化型的產品經理和創(chuàng)造性的產品經理。前者的工作主要是對已有產品功能的完善優(yōu)化和增加新功能，后者的工作就是從0到1的過程。前者為業(yè)界的大多數(shù)，后者的要求更高。我所在的部門是去哪兒國內機票，在這一個月內的主要工作就是對系統(tǒng)的功能優(yōu)化，以及增加新功能來滿足業(yè)務需求。

二、總結的一些能力

看到很多文章講產品經理的特質，在這自己通過這段時間工作總結了幾點：

1. 溝通能力；
2. 自發(fā)驅動與執(zhí)行能力；
3. 邏輯思維與想象力；
4. 資源協(xié)調能力；
5. 數(shù)據(jù)分析能力與商業(yè)頭腦；

每一條都非常重要，同等重要，不能有短板。

溝通能力

溝通，好不夸張地說，產品經理的時間有7成以上，都是在溝通，因為這是了解問題最快速直接的方式。日常的工作中，你會和各種角色溝通，運營人員、開發(fā)、測試、其他產品、你的老板、用戶等等。所有業(yè)務相關的角色都會有接觸，作為產品只要你愿意，公司的每一個人你都可以打交道。而且大部分時間溝通，你們可能是第一次見面。

溝通的方式按照有效程度由低到高，大致可以分為：郵件、內部IM、電話、當面約談。去哪兒內部IM用的RTX，可以通過組織架構找到任何人，及時發(fā)起群聊。如果需要找人，而不知道具體誰在負責，直接拉人，通過至多三度關系，就能定位所有相關干系人。電話同樣，隨時查找任何同事電話，打字說不清楚的，電話溝通。當面約談，最有效的溝通方式，說不清楚直接問工位，哪怕是第一次見面。

去哪兒給每個員工都配備的是筆記本，非常開放，你時常會看到有抱著筆記本走動的，和圍著電腦三兩討論的。開放的辦公區(qū)周圍墻壁、走廊、柱子到處都是毛玻璃和記號筆，隨手抄起筆開始畫流程圖十分常見。還有各種放著LED和沙發(fā)的角落，講需求估工時、對case的時候十分好用。

剛開始還不適應這種節(jié)奏，磨不開臉，與其他同事第一次見面還需要自我介紹，想想還太嫩。目前已經鍛煉地十分厚臉皮，說明來意之后，直奔主題，效率第一，因為你時間總是不夠用。

自發(fā)驅動和執(zhí)行能力

所有的工作都沒有人在強迫你，動力基本來自自身。個人還是比較認同，必要地去做自己熱愛的工作。作為一個產品，你需要負責上游到下游整條流程，從運營或客服發(fā)現(xiàn)問題，到與相關產品、開發(fā)定位問題，到自己提出解決方案，到相關產品、開發(fā)、測試評估影響與實現(xiàn)難度，到功能開發(fā)，到與測試提測功能發(fā)現(xiàn)bug，到上線后進行后評估和數(shù)據(jù)分析，都離不開產品，每一環(huán)都需要優(yōu)秀的執(zhí)行能力。

每個人都會很忙，尤其是技術人員，基本是同時負責多個產品的項目，讓開發(fā)同事自發(fā)性地優(yōu)先處理你的問題，很難。所以需要催，但是是有技巧性地催，怎么催，目前還不得其法。實際中往往存在推不動的窘境，或者更改方案，或者實在不行而又必須要上那就升級。

另外，對于自發(fā)驅動地負責任務有一件事印象非常深刻，前些天上線新功能后需要制作運營數(shù)據(jù)日報，在我提到這不是數(shù)據(jù)運營團隊的活時，蔡師傅則告訴我，不要想著把托出去，所有的事產品都應該負責，而且是要會。之后，自己也開始利用各種機會問、看、學。

邏輯思維與洞察力

沒有強大的邏輯思維的確很難勝任這個崗位。處理問題最怕毫無章法，亂序不僅會導致處理事務不分優(yōu)先級，嚴重的甚至會導致溝通不順暢，雙方理解出現(xiàn)偏差。日常的工作中往往接觸到的一手消息是已經出現(xiàn)問題之后的現(xiàn)象，這時候需要洞察問題實質來源，將不同問題歸類處理。

比如說，問題現(xiàn)象1出現(xiàn)之后，需要考慮所有導致這個問題的可能，分不同環(huán)節(jié)逐個排查，判斷是原因1還是原因n？是即有問題還是新出現(xiàn)問題？與問題現(xiàn)象n有沒有相關聯(lián)系？另外，在PRD（產品需求文檔）中非常重要的一節(jié)就是功能流程圖，向他人講述問題配合UML圖例能夠事半功倍。

入職第一天，天舒就是通過UML向我講解業(yè)務流程，讓完全對機票業(yè)務陌生的我短時間有了大致的理解，當時折服于其強大的邏輯不能自已。有同學想學習的話，用visio完全可以，日常任何事情都可以通過流程圖描繪，嘗試去分解對象、動作，如果利用多泳道流程圖更加形象。這里建議可以看蘇杰老師的《人人都是產品經理》，書中的UML圖例很實用。

資源協(xié)調能力

資源，資源，資源，重要的事說三遍。要明白的一點是，資源不夠，這個問題永遠存在，所以提任何需求的時候都需要考慮到實際工作量。這里的資源，主要指技術人員，一般以工作人日來為單位來衡量，有時也包括客服人員或者外包人員。衡量一個需求價值高低，或者說上不上，主要的評判標準是性價比，這從idea產生的初期就得牢記并貫穿始終。

剛入職時，我看待問題比較天真，在寫需求的時候動不動就以用戶體驗、交互設計為出發(fā)點，然而當時的項目是內部服務系統(tǒng)已經出現(xiàn)降低運營人員工作效率的情況下新增功能。理所當然，又被教育一頓，如果這是用戶端的功能，我們花再多錢也得上，但不是，當務之急是花最少的資源最快時間上線，保證業(yè)務線跑通，因為開發(fā)資源很寶貴，系統(tǒng)以不影響業(yè)務為第一位。

數(shù)據(jù)分析能力與商業(yè)頭腦

這個看著較之前面幾者能力在實際操作中運用地少一些，但是千萬不要忽視了它的重要性。為什么把數(shù)據(jù)分析能力和商業(yè)頭腦放在了一起，因為二者缺一不可。只會分析數(shù)據(jù)而沒有商業(yè)頭腦，會淪為計算工人；只有商業(yè)頭腦而不會分析數(shù)據(jù)，那就是大忽悠。

最理想的境界是用數(shù)據(jù)來佐證你的idea，用數(shù)據(jù)說話，說服別人。這里的別人包括你溝通的所有人，尤其是，你的老板！開發(fā)的老大！測試的老大！因為他們是能夠在需求評審當中拍板的人，前期與各方面人員溝通再好，需求自認為多牛，最后也有可能被拍死。戰(zhàn)術上的勤奮不能折算戰(zhàn)略上的空洞。

前兩天，作為新人的我，接手一個特殊情況，這個特殊情況產生的損失公司目前采取承擔的策略，但是由于無法準確評估其影響程度和具體的損失量，被拍死。當時老大曉晨哥說了一句，不說清楚不給改，感概良久。這里面插一句，最好最好會用SQL，用來提取數(shù)據(jù)提高說服力的利器，想做產品的童鞋可以去學習一下，基礎夠用就好，類似條件提取where之類。

三、一個需求的過程

在去哪兒的時間不多，但是也是很幸運地走過了一個需求的整個過程，在天舒這經歷了前半段，在蔡師傅那經歷了后半段，對需求有了一些了解。大致來講，需求的完整過程分為以下幾個步驟：idea產生、idea評審、需求產生、需求評審、需求開發(fā)、功能測試、功能上線、后評估。

idea階段

idea階段真的不只是一個想法，已經是一個可以實行的方案了。不止一次在這里學到，不管是什么任務都要細化，一定要落地，可執(zhí)行！當然idea最核心的是它的價值，增加營收還是減少損失，提升用戶體驗還是加快運營效率等等，記得要用數(shù)據(jù)評估。這時候輸出文檔，基本就是PRD的前身，idea評審基本就是找產品老大過目。

idea的動機基本是彌補缺陷或者發(fā)現(xiàn)不足，很多途徑都能產生idea，主要有：

1. 運營人員的溝通；
2. 自身充當客服人員發(fā)現(xiàn)；
3. 公司相關部門人員的提出問題

……

為了快速熟悉業(yè)務，我臨時充當了客服人員三天，收獲著實不少。有時候我們做的，和用戶感受到的差別會讓你吃驚。去哪兒內部還有一個非常有效的機制，產品人員輪流排班接聽值班電話，一般都是代理商反應的比較嚴重的問題，為優(yōu)化產品提供了不少幫助，甚至許多故障的產品在值班期間發(fā)現(xiàn)。

需求階段

當idea通過了之后，開始進入需求階段，開始撰寫PRD。當然，所有的事務都需要細化，細化到每一步動作，每一個頁面，數(shù)據(jù)的埋點存儲，甚至是按鈕的形狀顏色。在寫PRD時，比較重要的一步是通過流程圖把整個需求描述出來，各種情況考慮周全，注重邏輯順序，需要達到第一次接觸這個需求的人看你的流程圖就大致知道怎么實現(xiàn)的程度。接下來就是需求詳述，逐點敘述，一二三四羅列清楚，配上相應原型（Axure是神器）。

在需求產生的過程當中，很重要的一環(huán)接是找到相對應的技術干系人討論需求，一般在去哪兒內部稱為技術Review。技術Review形式是不拒于形式，大部分時候都是就近找到有顯示屏和沙發(fā)的角落，插上電腦就直接開始。拉上DEV（開發(fā)）、FE（前端）、QA（測試），大家猛烈抨擊你的需求：實現(xiàn)不了，改！涉及面太廣，改！華而不實，改！當所有人都認可之后（這中間可能不止一次技術review，而你的PRD會大變樣），開始打分估工時。

需求評審階段

需求評審（FR，F(xiàn)inal Review），是一場血戰(zhàn)，因為你的需求可能就此戛然而止，之前所做的所有工作就此付之東流。每個禮拜的某一天都會集中安排FR，所有需求的干系人都會到場，評審委員會由各個部門老大組成?；叵氲谝淮螀⒓覨R的情景，心有余悸，因為用毫不留情形容并不夸張。從項目評估開始，需求就會被挑戰(zhàn)，每一個細節(jié)都會被盤問，技術的工時也會被進一步控制。最終，能夠順利通過評審的需求，并不多。

功能開發(fā)階段

功能開發(fā)階段，主要由DEV和FE同學負責，但是產品必須與其保持密切的溝通，已確保功能不走歪變形。同時，這短時間QA頻繁地與DEV和PM溝通，編寫checklist，全方位保證功能質量。之后，開始編寫case（測試用例），一般由PM和QA一起操作，當然免不了增、該、刪，因為PM對自己的需求最為熟悉，需要幫助QA同學考慮一些最有可能出現(xiàn)bug的環(huán)節(jié)。

編寫case真的是一個虐心的過程，細化到每個操作動作描述以及對于出現(xiàn)的結果，一個下午40多個測試case，使我對需求又有了一次新的認識。

功能上線與后評估階段

功能測試與上線，這個階段是檢驗功能的成效與質量的環(huán)節(jié)，借助已編寫case。測試的過程會出現(xiàn)各種狀況，PM與QA及時溝通十分有必要。在提測的那兩天，我就是帶著筆記本搬個小凳在QA同學旁邊，雖然坐在一群QA中間，但是的確我只是個PM。那時才弄懂了如何修改host、各種beta環(huán)境等等對我一個管理出生的學生而言十分神奇的東西。更多地了解所有的業(yè)務功能在上線前，都經歷過怎么的內部迭代和一次又一次的質量敲打。

項目后評估。一般在PRD文檔中會注明項目目標以及后評估的時間，如何檢驗公司花這么多資源上線的功能有沒有用，就看這時候了。當然，還是得用數(shù)據(jù)，最好自己SQL，有時候還要設計運營數(shù)據(jù)日報。問技術同學，問數(shù)據(jù)運營的同學弄清楚各個表字段的含義，取你所需，為你所用。

四、感受

立志從事互聯(lián)網工作的時間不短，但對產品經理這個崗位了解并不多，一個月前的認識就是停留在觀察過以前同事，看過一些產品類書籍和自己在學校鼓搗過的地步，和自己真正去從事這項工作真的兩碼事。想象的都太過膚淺，諸多人對這個崗位有別樣的熱情，甚至非它不可，我覺得的確有些過了。如果有童鞋真的特別想從事，建議動用一切資源機會找一份實習去感受下。在去哪兒的這一個月感受挺多，自我感覺無形中成長不少，在這里總結了一下：

1. 溝通很重要。弄不明白就去問，找最熟悉的人去問，這個成本比你自己蒙頭發(fā)現(xiàn)原因低很多，同時也能避免再次發(fā)明輪子的尷尬。不要磨不開臉，同事都很樂意解答，因為同時他們也在完善自己的工作；
2. 硬技能容易學，但是軟實力不好培養(yǎng)。如果說你覺得自己不會Axure、SQL等等技能而放棄，完全沒必要，這些只要有心都可以學會。真正要重視的是自己的軟實力，比如闡述能力、邏輯思維、商業(yè)感覺、與人相處能力等等；
3. 細節(jié)，注重細節(jié)，任務要細化，思考要全面。任何時候提出方案都是需要可以直接執(zhí)行，說通俗的一點，就是要落地?？淇淦嬲劜]有任何成效；
4. 結果比過程重要。在以結果為導向的互聯(lián)網行業(yè)內，沒人在乎你當中多么艱辛，付出了多少，所有的評判都是結果怎樣。企圖通過任何過程的理由來解釋結果，都是耍流氓；
5. 定位很必要，給自己制定計劃。不能懶惰，逼著自己忙起來。學校生活很安逸，但遲早都得出象牙塔，早早規(guī)劃好到畢業(yè)要走的路。與其找工作是抓瞎，不如笨鳥先折騰。找實習，拋開24h都自由支配的學校生活，像一個正式的職場人士去忙碌，公司沒有實習生，只有員工；
6. 還有幾點不斷提醒自己可以使自己更強大：不要玻璃心、不要薄臉皮、不要牛角尖、不要憤青。

最后，歡迎大家對去哪兒提出任何意見。APP也好，主站也行，意見歡迎，投訴處理。

最后的最后，感謝領我入司的HR璐姐，老大曉晨哥、晗哥，不厭其煩解答我各種問題的天舒、丁晨哥、蔡師傅、老鄉(xiāng)贊姐、京晶姐，以及一眾包容我這個新人的同事們。

本文由 @郭佳冰?原創(chuàng)授權發(fā)表，并經人人都是產品經理編輯。轉載此文章須經作者同意，并請附上出處(人人都是產品經理)及本頁鏈接。