工作之前

角色轉變

從程序員開始

大二起，發現自己在信息技術方向上的興趣，更多地偏向互聯網。說干就干。初中有用 FrontPage 和 Dreamweaver 自制網頁的小經驗，便到圖書館拿 HTML 和 CSS 方面的書讀起來。一天時間通讀，就手工寫出了 Div+CSS 的代碼，整齊美觀，頗為自豪?？焖賹W習的能力是一方面，最重要的地方在于，這份網頁不再是通過 Dw 點來點去、畫表格或者使用層東拼西湊，而是純手工且符合萬維網聯盟（W3C）標準。這意味著我寫的東西不再是玩具；它們進入了可應用的行列；

特長和志向不在視覺設計，我也不滿足靜態網頁。選擇 PHP，因為它使用廣泛，入門容易。有了初中 Basic 和大學 C 語言的基礎，這樣的腳本語言很快可以寫出來。很自然，MySQL 和 Javascript 列入了我的書單。

為了檢驗學習成果，我立了一個博客項目。衡量其好壞的標準在于，能囊括目前博客網站的多少功能。為了檢驗應用能力，大膽獨立外包了一個電商網站，其中的關系、權限的復雜度與支付功能是從未遇到的。網站勉強順利開發到一半，老板突然決定改設計成商品展示網站。這下自己減負很多，項目圓滿完成。

項目經理

做外包項目的同時，我已經把自己定位成 PHP 程序員?？臻e之余，在 PHPChina 網站上撈各種招聘信息。經過多番了解和學習，我發現自己并不適合開發：

1. 數學不好，而且對之深惡痛絕
2. 缺乏復雜邏輯計算的天賦
3. 代碼看多了眼睛疼

綜上所述，恐怕我根本不是開發的料。不過只是借開發之力，完成“項目”。而且，開發也不是我想要的，因為我：

1. 對一個項目（工程、產品）導向感敏銳。不敢稱為“戰略”
2. 執著于產品設計。包括版式、視覺、文案等
3. 要求苛刻，追求完美。對字符、像素級別的單位挑三揀四

我想要：

1. 改變世界。我們的生活糟糕透頂，需要一個東西徹底顛覆
2. 成功。有力量持續改變

我以為這樣的孩子名頭叫“項目經理”，他來決定程序員寫什么。走進項目的流程，進入其涉及的范圍，第一步便是搞清什么是“項目”。這個時候又才了解，相對的，還有“產品”這個概念。

產品經理

產品旨在滿足需求。產品經理的職責是探索和定義產品：探索價值，定義解決方案。

這正合我的胃口。我轉個彎，一方面，廣泛學習請教產品知識；另一方面，也做項目自察。做產品容易“假大空”，為了避免如此，我把在博客園上本來準備為技術沉淀的博客，搬遷到了獨立博客上。使用獨立博客的好處是：

1. 顯得專業
2. 能夠炫耀
3. 要花錢，所以得堅持
4. 本身便是一款產品

自此，開始研習產品的學問，所思所得都記于此。

應聘淘寶

3月8日 投遞簡歷

淘寶是我應聘的第一份正式工作。

去年得知它們有一“產品經理特訓班”。既然專門為咱們這號人打造，自然不能錯過。

22日 參加宣講會

全程很傻很天真地做了筆記。囧。

27日 現場筆試

路癡加上得到了錯誤的指引，硬是在校園里繞了一個多小時。

淘寶筆試的題目分為數學題、邏輯題和論述題，題型為選擇題、填空題和問答題。數學考概率、數據結構和指針；邏輯考推算、解除糾紛和推理；論述考寫字樓電梯設計和淘寶買家產品設計。剛拿到題目還是覺得挺別扭的，畢竟大學里的考試，你懂的。認真做下去之后，不僅發現難度正好，還覺得挺有意思。最后一題因為時間緊張，只剩下5分鐘，答得沒有條理，也不夠細致。

4月14日 現場面試

準備最多的還是“保潔八大問”和群面攻防術。我以為會有多復雜，多緊張，結果到了淘寶面試現場也就那樣。

一面首先自我介紹。根據網上的經驗，一句話結束。然后面試官震驚了，要我說個10-15分鐘，然后我就震驚了。介紹完畢后，主要是詢問自己一個做著玩的項目，重點在商業機會。完畢，面試官叫我直接去二面，我本來以為要等個幾天的。

二面首先自我介紹。根據上一輪經驗，我準備開始滔滔不絕。結果，我說的每一句話都被打斷——這回是盤問而不是詢問了——我也知道，壓力面來了。在交談的過程中，根據學生會的經驗，主要把握三點：線索、成果和收獲。線索是跨話題的潤滑劑（井井有條就免了，能不生硬已經萬幸，又不是演戲），成果是成功的收獲，收獲是失敗的包裝。

看上去很淡定是么？其實根本就不是這樣，哈哈哈。還好也沒差哪去。

這次面試最大的不足在于，畏懼權威，依據不嚴謹，導致說服力度沒有到預期的檔次。另外，我不推崇繁復的自我介紹，因為簡歷上已經寫得明白；我推崇相互尊重。

18日 收到錄用書

進入淘寶商城

開始

紙上談兵

初來乍到，第一反應就是和所閱相比完全不是一回事——這些書還都是有關互聯網、大產品部門；和學校更是風馬牛不相及。具體說來，就是和預期各種不符。根據我的理解：

• 產品經理無授權領導，交換意見后拍板決定
• 產品需求文檔保持更新，有據可查
• 項目經理負責掌控項目進度
• 開發不受到打擾，專心進行編碼工作
• 運營負責提供數據，供產品經理決策
• 用戶體驗部門充分獨立，為用戶體驗提供捷徑
• 會議有了邀請制、預告和紀要，因此高效
• 經過充分討論 / 思考，得出問題最佳突破口
• 最終產品功能好用，途徑從簡

事實并非如此。

方向、目標、途徑

當一套知識體系不夠用的時候，捷徑是獲取并切換成另一套，比如公司對員工技能的定義。這一套概念非常有效，因為它努力避免了套話，把具體的能力細化成可以考量的規范；最重要的是，經過證明，它行之有效。好比同樣是《小學生守則》，中國講“誠實守信”，美國講“考試不許作弊”。

達成目標最好的技能是主動，但有一股勁使不出也不是個事。這個時候，我發現《啟示錄：打造用戶喜愛的產品》當真是葵花寶典啊啊啊，尤其是第28-30章，一條一條地講碰到什么問題，怎么去做。比如：會議太多，導致產品毫無起色，怎么辦？

我開始的做法是，抱著本本去開會。如果內容無關緊要，我就可以做自己的事。但這樣明顯會有幾個問題：

1. 做事分心
2. 會議上的內容沒有聽好（特別是當別人問起來，自己一無所知時，就悲催了）
3. 顯得（也確實是）效率低下，做事不專心

書里介紹的辦法是：直接劃去（借口推辭）不重要的會議。比如，有的會是討論背景，有了結論（做不做，做什么樣的需求）后才能和產品經理討論具體需求。曾經出現這樣的狀況：討論了一個上午，把這樣的需求刪了，或是歸并到另一個部門里，自己白白犧牲。

在橫沖亂撞（很能導致瞎忙活）前，看看有沒有好辦法；但不論怎樣，做，總有收獲，錯誤的路徑劃去一個是一個，就像愛迪生那樣。

工作

工作環境與同事

工作起來比較輕松、開朗、活潑；既很黃很暴力，也很悶騷。好吧，最后兩句是我自己加的。大家干起活兒，會碰到各種狗血。比如，教師節，周圍會有淘寶大學的同事拿著垃圾桶敲鑼打鼓，旁邊還掛著牌子：嚴肅&回避。

休閑吧的桌上足球不用說，免費的咖啡和奶茶不必說，22點半以后送上門的宵夜自不必說，周六周日來公司可以蹭兩餐飯也不必說，最讓我覺得有意思的是咱們的衛生間。其間會掛有宣傳畫，也就是廣告，像出什么產品啦，有什么相親活動啦，做什么折扣啦，用詞極為忐忑。比如：二十一世紀最缺什么？老濕！歡迎各位小二來××為大家講解××。來就有獎品贈送，至于你信不信，反正我是信了。地球再也無法阻止你濕了，快來報名吧！

咳咳，接下來是重點：一次在男生小便池前看到的宣傳畫是：衛生巾在聚劃算打7.5折，于是各種蘇菲彈力貼身。男生的大便的隔間里，除了有貼心的卷紙、掛鉤和肥皂盒（放手機用）外，還有一塊紙板一支筆。我俗稱為吐槽板，因為咱們會在上面進行各種吐槽，什么找不到女朋友啊，月光太冷啊，等等。不僅如此，還會整整齊齊地蓋樓，各種苦屄你傷不起。

辦公桌之間的隔板低到相當于沒有。我的師兄在我左側，老大在后面，整個產品技術部的領導就在我對面，囧。同事都很年輕，所以都 hold 住。好吧，正經一點，總的來說就是：團結緊張，嚴肅活潑。

每天出入大門，保安同學都會親切地微笑，道聲好。一次周末因事趕去公司，15點多才買了泡面當午飯，掃地的阿姨很溫馨地和我講：小伙子，再忙也要吃好飯。

認真工作的人，真美。

需求文檔與原型

如果產品需求文檔不靠譜，或許有這些解決辦法：

1. 冗長。像寫散文一樣，精煉語言；按功能點 / 場景撰寫，使用有序列表；重要的廢話放在附錄里
2. 不直觀。繪制高保真 Axure 原型
3. 容易過期。任何改動，都更新到文檔里，口頭除外
4. 存在版本控制偏差。嚴格標明版本（包括文件名和文檔內部），每個版本都輸出 .pdf 文檔

原型也有：

1. 非高保真。高保真意味著生成的是 .html 頁面，而不僅僅是截圖。菜單是能彈出的，下來列表是可以下拉的。直觀，可以簡單試用
2. 交互復雜。原型是為了演示逼真；復雜交互由于藏得太深，容易忽略。對于復雜的交互，不如拆開成場景。以注釋的形式附在交互處旁邊，標注其將進入什么場景?！白⑨寘^域”必須一看就知道是注釋
3. 無法精確還原功能點 / 場景。精確還原需求文檔所寫是原型的意義。對于一個場景，能對用戶的所有行為做出響應。為了避免使用者漏掉某個行為，以注釋在形式在空白處窮舉

重要的是執行。最重要的這一步，我還很欠缺。

溝通，還是傳話筒？

一款產品通常這樣經過：需求（來自運營）→產品→開發+用戶體驗→安全+測試→發布→反饋（來自運營）。產品只是傳話筒嗎？如果去掉產品環節，讓他們直接溝通，會不會更好呢？

不會。因為：

1. 提需求的同學精于運營，缺乏可行的概念。他們知道自己有痛處，但不知道什么可以做（不知道所以想不到點子），什么不能做（想到了點子卻做不到）。于是局限了滿足需求的方式，更重要的是，隱藏了深層需求
2. 開發和用戶體驗的同學精于實現（可行+可用），缺乏對價值的把握。運營和開發同學直接溝通的成本非常大，一是語言不通，二是難以對需求進行有效挖掘

產品可以做的事有：

1. 掌握現有產品 / 工具 / 技術 的實現范圍，跟蹤其外延。做決策時便有確鑿的依據，什么功能能實現，什么不行。不行的話，可以做到怎樣的程度，需要多少成本
2. 深度挖掘需求。運營同學有了需求后，往往會告訴產品他們想要的，卻鮮說（或說不出）真正渴望的東西。如果是這樣，一來沒有滿足真正的需求，導致需求變更頻繁，二來，體現不出產品的價值。比如，他們想要一瓶可樂，我們給了，他們又覺得不行，想要一杯橙汁。而他們的實質是口渴了，需要一杯白開

在實際溝通中，某些開發和運營同學明顯比我考慮得周道；再加上開發更懂技術，運營更諳運籌帷幄之道，作為產品新人，我表示壓力很大。

說“不”與責任心

對產品負責，就是產品在大產品團隊合力的情況下，平穩地向積極的方向迭代，有數據和指標可查。在迭代的路上，總會半路冷不丁殺出來一個坎坷，躲都躲不掉。說說我遇到的情況：

• 更多需求（產品）
• 更多需求（功能）
• 需求變更
• 缺乏開發人手
• 會議太多
• 郵件太多
• 缺乏思考時間

對于以上的種種問題，步驟有二：

1. 說“不”。很多情況（≈麻煩），直接拒絕，會省下很多精力做真正該做的事。做產品要精，但不代表事必躬親
   1. 對于非一條產品線（部門）的需求，大部分直接回絕
   2. 同一條線，則根據其價值、開發人手、關系有選擇地考慮。需求的緊急程度永遠不在考慮的因素范圍內，因為所有的需求都自稱最急迫。其重要程度則有明顯的區別，比如能帶來多少交易額，提高多少轉化率、流量等
   3. 對于一款產品本身功能的多寡，則逐個砍，砍到除非確實不能滿足需求或嚴重影響用戶體驗。這里存在兩點，一是有的需求不可避免，比如為了應對政治、營收和競爭對手需要；二是“用戶體驗”的概念泛化，每個人嘴里都在說這四個字，成為各種擋箭牌。產品的好壞，取決于其核心競爭力。做不好核心，邊邊角角再漂亮都沒用
   4. 不少會議可以推掉，如前所述。推不掉的會議可以參加需要自己參與的部分。會議紀要非常重要，未出席的會議，主要靠它來了解情況
   5. 絕大多數口水郵件都可以忽略。MS Office Outlook 2010 就有這個功能，單擊一下，自動忽略指定話題
2. 推動。以前我用的詞是“跟進”，被老大否了；以前我說“他們”，老大要我說“我們”。別小看詞匯，反映的是態度
   1. 需求一定是可以變更的，控制好變更頻率是王道。我的實例是，每周四提變更需求，周五確認需求，評估可行性和開發周期。在開發周期內，凍結一切需求（1%的緊急需求除外）。下周一開工，周三發布上線，拉取運營數據，周四評估是否提新需求還是變更
   2. 缺乏人手非常普遍。首先，提需求前考慮人手狀況；然后，確認需求時確認開發資源（人手、服務器狀況）；最后，開發周期內，定期向開發同學詢問是否需要幫助，順便掌握進度和人員情況。如果在立項之初就爭取不到人手，辦法有：讓需求方排優先級；證明需求的價值；向老大請求支持；找朋友幫忙；自己頂上；砍掉該需求
   3. 利用個人時間思考。我們都笑說產品一天的工作是：白天開會+晚上寫文檔。時間擠一擠，總是有的。有意思的是，做產品不存在工作地點和時間的局限，很多好的點子就來自生活

感悟

對人尊重。大多數同事都平易近人。養尊處優慣了，遇到不對板的就顯得手忙腳亂。一次營銷活動，運營的同學非常強勢，沒有好臉不說，語氣還咄咄逼人。經常會說，“哦，你把這個給我做了”，“那個怎么又出問題了，你是怎么搞的”。而我又是個暴脾氣，一兩回還行，次數多就非常受不了。

后來師兄問我是不是覺得很委屈，我一個勁點頭。他告訴我，要學會看人，這也是尊重人。尊重，意味著考慮其人的性格、辦事風格以及當時的環境。那位運營同學平時就是這個樣子，辦事也比較容易激動。當時她負責的活動別人不大看好，她一攬全局接下來，想做出成績。更重要的是，她并不是對我一個人這樣，而是所有人。將心比心，誰都可能有這樣的時候。

其次是對“尊重”二字的理解。尊重體現的是修養，而非“交換”。好比，橫穿馬路就像一百人對自己罵娘一樣感到恥辱。這是自發的。笑笑，說幾句好聽的；或是有確鑿證據時指出對方的錯誤，再來一起解決，都有助于合作，最后達到產品預期。

對事認真。不做就說“不”，做就做好。做出來的東西怎樣，和別人沒關系，是對自己水平和能力的表現。字如其人可能玄乎，但產品如其人，就實實在在了。做不做得了，做得怎樣，體現了自己多少價值，團隊凝聚力何如，評論怎樣，都凝結在產品里。

做好是底線。做產品非常重視積累。若立志做一款改變世界的產品，那么每一塊鋪路石都必須做到最好。

參考資料

1. 丁宇 《面試時的三個問題 – 我的招聘方法2》?http://feed.feedsky.com/felixding
2. MarsCn 《寫在創業的路上：如何從無到有的打造一個產品》?http://www.marscn.net/?p=962
3. 丁宇 《從“產品需求文檔”（PRD）到“產品設計文檔”（PDD）》?http://feed.feedsky.com/felixding
4. 馬蒂 《啟示錄：打造用戶喜愛的產品》?http://book.douban.com/subject/5914587/
5. 蘇杰 《人人都是產品經理》?http://book.douban.com/subject/4723970/
6. kentzhu 《基于 Axure 的 PRD 寫作思考》?http://www.ikent.me/blog/3042
7. 傅路鑌 《寫給想做互聯網產品經理師弟師妹們一些話》?http://www.fulubin.com/?p=483
8. 知乎 《這樣現狀的產品經理如何調節》?http://www.zhihu.com/question/19853148
9. 默契 《你憑什么說你的網站用戶體驗好》?http://hi.baidu.com/mooqii/blog/item/20c2772253b685e6d6cae23b.html
10. 匿名 《還能再負責一點？》?http://www.alibuybuy.com/posts/62324.html

延伸閱讀

1. 搜狐 IT 《喬布斯經典語錄精選：對產品、對手和生死感悟》?http://it.sohu.com/20110825/n317358248.shtml
2. 吳軍 《浪潮之巔》?http://book.douban.com/subject/6709783/
3. 蘇杰 《推倒產品團隊里的那堵“墻”》?http://iamsujie.com/8000/8032/
4. 林建峰 《流程、產品和人》?http://sofish.de/1731
5. 董釋德 《互聯網公司混的十大真相》?http://ucdchina.com/snap/10021
6. 知乎 《網站頁面設計怎么平衡簡潔和復雜的關系？》?http://www.zhihu.com/question/19828763
7. 標點符 《谷歌用戶體驗設計準則》?http://www.biaodianfu.com/google-user-experience.html
8. 匿名 《學習重要，還是經營人脈重要？》?http://site.douban.com/widget/notes/175122/note/173851947/

來源：http://cuikai-wh.com/blog/1406