2011.10到2012.2，小圈在百度做翻譯產品的產品經理實習。這份實習是小圈的第一份產品經理實習，更是人生中的第一份實習，所以，這次實習的體驗和收穫是雙重的。雖然整個過程很磕巴，但小圈也盡了全力，最終順利離職。
這份實習完成後，只寫了一個PPT對自己經手的案例進行了歸納。而關於實習這一百五十天的點點滴滴，還一直沒有找到機會來寫。今天就和大家一起來分享。
面試這件小事兒
在沒有進入公司實習前，總覺得面試是一座讓人難以逾越的大山。如果能跨過這道坎，後面就容易了。直到開始實習後才發現，面試相對於實習本身，真的只是一件小事兒而已。
小圈理解的產品經理面試，是在有限的時間之內，通過交流，考察你的溝通能力和產品感覺。你只要向面試官展示一個真實的自己即可。你的想法可以天真，也可以縝密，因爲它們不是需要完成的任務，沒有期限，沒有對錯，只要你有想法並且能夠自圓其說就可以。
而真正開始實習後，你就成了團隊中的一員。你需要爲每個目標設定期限，要爲每句話負起責任，那份焦慮，那份沉甸甸的滋味，早已不是一個在面試官面前侃侃而談的應聘者所能體會的了。
回到面試來說，要應付產品的面試，需要理解開發產品的整體流程以及其中的要素，緊緊把握用戶的需求。同時，需要對互聯網產品市場有所瞭解，能夠對市場中的熱門產品從設計、運營的角度給予合理的評價。
小圈認爲，可以從兩個方面準備產品的面試。首先，適當的看產品方面的書籍，做好積累和沉澱。再者，要關心互聯網產品的動態，對產品的設計、運營等積極思考。只要做好了這兩個方面，再加上一點好運，面試應該能夠搞定。
當小圈遇到實習
當小圈遇到實習，本以爲是情投意合，你儂我儂，沒想到，一頭栽進了艱難的磨合期，差點撐不過蜜月就分道揚鑣了。好在小圈有顆強大的心臟，總算堅持了下來，收穫了甜蜜的結尾。
對於完全無實習經驗的小圈來說，實習實在打破了太多的舊習慣，一時間讓人無比痛苦。實習前，早上刷會兒微博、看會兒資訊；實習後，早上一坐到位置上，看着滿滿的to-do-list，心理就無比着急。實習前，中午都會小睡一會兒；實習後，中午大家都在熱烈討論，實在不好意思趴下。實現前，吃過晚飯，基本處於半休息半工作狀態；實習後，晚上八九點收工是家常便飯，而這個時間已經比正式員工要早，因爲得趕回學校洗澡。
可是，這些辛苦都不算什麼，最最痛苦的事情是，每週五臨到週會時，你都發現，這周安排的任務又有delay！在公司裏，deadline是一件很重要很正式的事情，因此在週會上報delay很尷尬，很丟臉。
實習初期，造成delay的原因無非就是效率低、專注度不高，這很好理解：客觀上，每次接受的任務對新人來說都是全新的，需要一個學習過程，效率低是很正常的；主觀上，平時在實驗室的工作節奏太散漫，到了公司，就難以保持長時間的專注。於是，剛開始的幾個星期，週週都有delay。指導人和阿拉丁組的帶頭人分別跟小圈談了這個問題之後，小圈意識到了問題的嚴重性。開始積極的調整和改進。可是，事情沒有變得更好。反倒是在某一天，由於實在無法完成手裏的任務，不得已熬了通宵。
那個夜晚，男朋友陪着熬到了三點，被催去睡覺了。小圈坐在電腦前迷迷糊糊的處理着文檔，腦子基本處於停滯狀態。只有一個想法，要把事情做完。所幸，熬了一夜之後，狀態還不算太差，總算趕在deadline之前提交了報告。那段時間，身體和精神狀況到了一個極限。小圈告訴自己，如果再有這樣需要熬夜的情況，就退出。所幸，後面一切順利。雖然辛苦，但再也沒有讓人如此爲難的時刻了。
現在來看，或許世界上大多數事情都是這樣的，會有一個艱難的適應期，將你壓榨到極限，過了極限，就能看到勝利的曙光了。
需求，需求
在進入這一小節之前，先介紹一下小圈所在的阿拉丁組。這個組的成立時間不算太長，應該不會超過五年，裏面的二十幾個員工，資歷都不算深。阿拉丁是幹什麼的呢？舉個簡單的例子，在百度搜索裏輸入“天氣”，出來的第一個結果就是阿拉丁。它不僅使用了權威的天氣數據，還將它圖形化展現，讓用戶非常直觀的獲得了自己想要的結果，甚至不需要傳統搜索中必須的二次點擊。這就是阿拉丁組在做的事情：對於部分搜索請求，會把最好的數據以最好的形式展現給用戶，實現了“即搜即得”。現在，阿拉丁的結果覆蓋了出行、旅遊、娛樂、招聘等生活的方方面面。在百度搜索中，大大的提升了用戶的體驗。
作爲一個新人，進入這個組的第一堂課就是，如果從用戶的搜索關鍵詞（query）和點擊行爲，判斷出用戶的需求。新人訓練爲期一週，通過一個星期的練習，漸漸的，就對用戶需求有了比較明確的概念。一個產品，說到底，就是爲了滿足用戶需求，因此，如何精準的把握用戶需求、如何找到資源滿足需求就是PM要思考的事情。
雖然在阿拉丁組，但是小圈負責的並不是阿拉丁的產品，而是百度翻譯。百度翻譯是阿拉丁組中唯一一個獨立產品，基本和阿拉丁組做的東西沒有關係，PM也是變來變去，沒有定數。做翻譯產品最大的好處在於，比阿拉丁組的產品容易上手。
指導人給小圈佈置的第一個任務是，對百度翻譯的需求滿足度進行評估。這樣的評估在一個產品的生存週期中，是會經常發生的。在真正接觸一個產品前，大家可能經常會問，如何瞭解現階段用戶的需求是什麼呢？這樣的評估就是了解用戶需求最好的辦法。通過這次評估，得出的幾個比較重要的結論，比方說，英文詞組翻譯成中文時，經常只有一個結果，這顯然無法滿足用戶的需求，需要改進，等等。
接着，小圈又做了百度翻譯與競品的需求滿足度對比評估、百度搜索中翻譯阿拉丁的需求滿足度的評估，發現了不少的問題。這些問題會被記錄下來，排出優先級，寫入產品的季度計劃當中。一些比較緊急的問題，可以立即和開發人員聯繫，進行處理。
在實習的第一個月，小圈每天打交道的，都是用戶的query。看着那些活生生的query，彷彿看到了用戶那鮮活的需求。它們有的已經被滿足，有的還做得遠遠不夠，等待PM去解決。
產品設計的美麗傳說
在做完一系列評估之後，指導人開始佈置新的任務：產品設計。產品設計的工作是準PM們對於產品經理這個職位最美好的設想：在圖紙上，從無到有，設計出一個全新的產品或者新功能。多麼讓人興奮的事情啊。現實呢，比想象中差一點點，但是也還不錯。
小圈的第一個任務是給翻譯產品設計分享、收藏功能。作爲一個新晉的PM，該如何着手進行設計呢？
首先，要了解自己做需要做什麼事情，做這個事情的原因和背景。接着，從用戶角度進行思考，設計出這個功能的基本形態和基本的邏輯；最後，從多方面進行細化，完善這個功能。
最終，所有這些想法，會落實到一份文檔上，那就是偉大的MRD（Market Requirement Document）。這份文檔是對所設計產品的詳細描述，它的閱讀者是開發人員（RD）和測試人員（QA），他們會依據這份文檔進行產品的開發。
就以小圈的第一個任務爲例，來講解一下一份MRD是怎麼寫出來的。
第一步，任務是什麼？背景是什麼？
這個任務聽起來很簡單，無非就是加一個收藏的按鈕，再加幾個分享的按鈕就行了。也就因爲看起來簡單，指導人才把這件事情交給了小圈，而事實，並非如此。至於開發新功能的背景呢，翻譯產品的用戶對分享和收藏功能的需求應該不算太大，但是，這個功能可以增加用戶黏性、同時藉助用戶力量推廣產品。所以，組內決定加入這個新功能。
第二步，設計功能的基本形態和邏輯。
分開來看，需要的實現功能有兩個：收藏功能和分享功能。
收藏功能相對簡單，只需要在頁面上加一個收藏的鏈接。剛開始，希望加一個收藏到百度個人首頁的按鈕，指導人覺得這個功能設計起來太過複雜，技術上也未必可行，早早就被砍掉了。這是小圈學到關於產品設計的第一課：學會tradeoff。
分享功能則複雜很多，好在百度有一個組在負責分享這件事，可以使用他們提供的服務。分享的基本邏輯是：用戶點擊了某個站點的分享按鈕後，會根據用戶的輸入，確定分享詞，在站點上發佈出去。
這樣一來，MRD的基本框架就搭好了。
第三步，進入細化階段。
這個階段就是對剛纔設計好的功能進行細化，需要考慮的東西非常多。比如，對於分享功能，需要考慮分享到哪些站點、分享詞的長度、是否帶圖片等等。同時，每次增加新功能，都不要忘記修改產品的幫助文檔，這個也需要寫到MRD中。
最終，就形成了一份長達7頁的MRD。
寫MRD有幾點特別需要注意：
首先，語言要清晰，因爲MRD是開發人員、測試人員進行項目開發的主要依據，語言模糊是最忌諱的；
第二，思考要完備，一定要儘量考慮到各種稀奇古怪的情況，將它們都納入文檔中，比如用戶輸入錯誤啊，用戶輸入超級長啊等等；
第三，設計圖要明瞭，詳細的設計圖是由UE（界面設計人員）完成的，但是在MRD中，也需要有一個簡單的設計圖，以做參考，設計圖需要儘量明確，重點突出。
那些年跟過的案例
項目管理是PM在公司一部分職責，對於這部分工作，每個公司都有不同的定義。在微軟、hulu這些外企中，PM的全稱就是program manager，主要的責任就是項目管理而非產品設計，而在百度、騰訊等國內公司，並沒有專門的項目管理職位，項目以開發人員爲核心，產品經理作爲項目的發起人，會站在用戶的角度參與項目的管理。
在小圈看來，項目管理從發起MRD評審那一刻就開始的。
MRD評審是什麼呢？PM完成MRD之後，需要預約開發人員進行評審，在評審中，PM會帶着大家一起討論MRD，開發人員會就每一項功能進行評估，看是否能實現。如果能實現，難度有多大，時間需要多少。之後，會根據評審的討論修改MRD，而這份MRD就可以作爲項目的發起文檔了。之後大部分時間內，項目相關的人員都會按照這份文檔來進行開發。
從評審開始，你就作爲這個項目的發起人，開始爲整個項目負起責任。在這個由PM、RD、UE、QA組成的團隊中，你所代表的就是用戶，你需要從維護用戶利益的角度出發，與其他人進行交流。
MRD評審之後，開發人員會確定排期以及人員分配。因此，在正式進入項目之前，有一段空閒期。在這段時間裏，PM可以將設計草圖交給UE進行細化設計。同時，PM還可以和開發人員進行適當的溝通，儘早預測出開發過程中可能出現的問題。可惜的是，由於小圈經驗的不足，這個前期準備小圈做得很少，基本都是在開發開始之後，才進行跟進。
項目開始後，主要由開發人員負責，PM當然也不能閒着，總會有這樣那樣的問題，需要PM來敲定。就拿跟進過的分享收藏功能來聊吧。在項目進行快一個月以後，開發人員突然告訴我，無法實現在開心網上的分享。原因比較複雜，導火索是公司提供的分享接口存在人人網無法上傳分享圖片的問題。於是，RD自作主張，改用了自己寫的後端接口。結果，在開心網上始終無法正常分享。於是，緊急聯繫負責分享的人員進行討論，確定了方案A和B。方案A，改後端接口，但需要分享組解決人人網無法上傳分享圖片的問題，同時，能夠滿足我們的上線時間。方案B，用開發人員現在這一套接口，放棄開心網上的分享。評估之後，最終採用了方案A。
從小圈經歷的那些大大小小的案例，總結出一句話：做項目時，PM很忙！
兩杆大煙槍
說了這麼多，最後的最後，小圈用兩個關鍵詞來總結一下在百度的這150天實習：執行力與溝通。
大煙槍一：執行力。互聯網公司的競爭非常激烈，時間永遠是第一位重要的事情，因此，deadline一定要放在心中。尊重deadline就是尊重這份工作。而影響執行力最重要的因素，一個是專注度，一個就是做事的方法。在做事方法上，注意目標導向一定沒錯。每做一件事情，一定要清楚目標和原因。否則，在這個過程中，遇到各種問題，你都無法解決。最終，你一定會花很長時間，做出一個遠遠偏離你目標的結果。
大煙槍二：溝通。作爲一個PM，團隊裏的任何人遇到任何事，都會跟你溝通，誰叫你是項目發起人呢。溝通中，也要注意目標導向，知道預約這個溝通的目的是什麼，是不是需要提前做功課。再者，溝通的基本技巧也很關鍵啦，這些就由自己去積累比較好。