軟體行業從業十年的產品經理的得失雜談

標籤：產品經理   軟體   市場   測試   

所謂時間飛逝、日月如梭，暮然回首，猛然發現自己出道伊始也將近十年了。回顧此前自己曾經擔任過的角色，不可謂不繁雜。曾經做過翻譯員、測試、開發、測試主管、專案經理、產品經理，甚至還做過銷售，徒步的大街小巷的去拜訪潛在客戶。此間我覺得最讓自己慨歎的是當年做產品經理的時候的一些得失。所以這裡就打算寫下來，與同行們共勉。

其實之前所做的“產品經理”這個角色，我認為是應該打個引號的。因為真正去跑市場、去全世界到處飛、去挖掘需求的是德國那邊的一個同事，只是Team Dev在珠海這邊，而我剛好英語溝通能力還算可以，所以就把我安排到這個所謂的“產品經理”的角色上來了。

所以，如果把客戶這個概念給抽象封裝一下的話，我們也可以說德國那個同事其實就是我們這個產品的客戶了。所以說，其實產品經理這個概念是比較泛的。你可以是一個產品型的產品經理，一個產品的創意的誕生到最終實現推向市場交到客戶的手上，整個過程你都必須把控；你也可以是一個市場型的產品經理，針對已經在賣的產品，發掘市場的需求，然後交給Team Dev來不斷的迭代；等等等等。

技術債務

這可能跟當時我做的這個“產品經理”的特殊性有關係吧，我當時花的絕大部分時間都是在我們的產品backlog和每個sprint的backlog上面，不斷的跟德國那邊進行需求的討論，不停的和團隊進行需求的細化，再緊張的去將功能進行優先順序排序並和各路人馬進行討論，然後投放到相應的sprint backlog上面去…

在一開始的一兩個sprint裡面其實整體狀況也都還好，燃盡圖 (burndown chart)也不算太難看。但是做到後來那條曲線就開始翹得越來越高，遠遠偏離了理想曲線了。最終不得不由原來計劃的7個sprint調整成10個sprint。
後來對這個問題有進行仔細的反思，究其原因，我覺得有好幾個，但是其中最重要的應該就是沒有及時的去對”技術債務“進行清理。

其實這個道理看上去很簡單，基本上跑過敏捷開發的人都知道技術債務給項目所帶來的傷害。但是在真正項目開始的時候，我們往往又會因為趕時間而匆忙將新的功能進行實現，而忽略了代碼的可擴充性和魯棒性等，最終這些“技術債務”越累越高，越到後面越發覺尾大難掉，修改一個地方可能都會牽一髮而動全身。

這裡看上去只是跟程式員有關係，事實上並非如此，這個更多是跟產品經理的理念有關係。像我之前，一心只想團隊快速的把產品backlog裡面的功能快速完成，而沒有花足夠的心思去思考產品表層下面的東西，沒有去認真去抓實現的品質的問題。如果是將一個產品描述成一個建築的話，那我覺得功能就是客戶所看到的地面以上的這一部分，而品質就是隱藏在地底下的這個地基這一部分。也許你現在看到的這棟房子外觀宏偉功能齊全連廁所都實現了自動化，但是一旦碰到大點的風吹雨打，或者說想要加建一兩層的話，可能整棟樓立刻就坍塌了。

所謂欲速則不達，一個產品經理不應該只是把眼光盯著那份功能列表，還應該多花點時間在解決“技術債務”這些事情上面來。

使用者體驗

我相信沒有哪個產品經理會忽視使用者體驗的重要性。使用者買你的產品/軟體的時候，其實他們真正買的是解決他們的痛點的方案。如果用了你的產品之後，原來的痛點解決了，但糟糕的使用體驗卻成為他們的新痛點，那使用者的逃離也為時不遠了。

根據本人之前做產品經理的經驗以及後來在一家創業公司的經曆，我發現我們在使用者體驗方面很容易犯的錯誤主要有以下幾個：

• 錯把自己當使用者：這特別容易發生在一個初創企業裡面，因為企業自身的經驗不足，以及產品經理的過於自負，同時也由於創業早期並沒有把勘探過早的關聯到項目中來(其實在Scrum裡面是很強調使用者的參與的)，所以一個sprint下來開始demo的時候，往往demo的對象就是項目的同一幫人。而產品經理在考慮下一sprint的使用者體驗的時候，又往往覺得自己能夠像周鴻禕一樣能瞬間變小白。所以周而復始，幾個sprint下來，產品拿出去一試水，發現就是石沉大海，結果就是再也沒有結果了。這個錯誤在敏捷團隊裡面也可以叫做是“小瀑布”錯誤，這就是沒有讓使用者過早參與進來的後果。看上去是在跑Scrum，事實上確是將原來的瀑布模式分解成幾個小瀑布，然後套用了Scrum的概念，有名而無實。
• 忽視了首次使用體驗：其實使用者是很沒有耐性的，特別是互連網產品使用者。你的產品可能功能很強大，UI呈現也很惟妙惟肖，但使用者卻要花大時間，甚至要閱讀你幾十頁的使用者使用手冊才能搞清楚怎麼使用你的產品來解決他們的痛點，最終發現解決他們痛點的那個功能竟然埋藏在三級菜單甚至以下，那你還預期他們會愛上你的產品嗎？

要解決這些問題的方法我認為也很簡單：

• 讓使用者儘早參與進來：比如我們當時在創業公司的做法是，因為我們當時做的是一個適合個人和小企業的私人雲端產品，所以我們就到附近大學裡面找了些學生過來進行試玩以及給他們做demo，然後收集反饋。在他們試玩的過程中要有專人進行追蹤記錄，且紀錄人不能給對方任何提示。當然，最後別忘記了給學生們一些報酬，我們當時是送學生們100塊左右的話費儲值卡。
• 競品研究：除非你在做的這個產品是非常有突破性的，業界還沒有同類產品出現，不然你肯定可以在海內外找到一些部分功能相近的產品出來的。這裡也許你會說抄襲可恥之類的話語，這裡我只能低調的說句，你丫少在我面前裝聖人，有本事你現在別用QQ別用，再來跟老子談抄襲可恥的問題！這裡我們聽下傳奇人物史玉柱是怎麼說的：“抄襲不但要厚臉皮，還要發展和最佳化。如果你抄後，還超越了對方，別人就不會說你抄了。“ 所以作為產品經理，你經常要做的事情還要是不斷的去研究別人的產品，而不是只盯著產品backlog這一畝三分地，而這裡說的還不僅僅只是使用者體驗上面，還包括其他功能點的調整，因為現在資訊瞬間萬變。關於這一點，下面還會有所闡述。

支援銷售團隊

這裡還要由我們當時做的另外一個面向二手房的房源管理系統說起。當前二手房中介用的比較多的房xxx等商用房源管理軟體(這裡就不點名了)，會把他們的房來源資料上傳到軟體供應商自己的資料中心上面去。而房源資訊其實一個中介的命脈，所以他們更希望是這個資料中心放在自己公司裡面。所以我們當時做的就是提供一個資料中心伺服器，以及相應的一套房源管理軟體，管理軟體支援PC端和移動端。

MVP出來後，開始去跑各種二手房中介進行demo以收集進一步資訊。問題來了，正如上面所說的，使用者是沒有耐心的，無論你說的天花亂墜，還是眼見為實。但是將整個伺服器架起來還是需要不少時間的，別人還需要特意給你騰出空間和提供網路接入等，且更尷尬的是，因為這還是很初期的產品，在你公司裡面跑的時候一般很正常，跑到人家環境裡面一跑的時候，不是這出問題就是那出問題。最終很多客戶都是以有事忙為由，中斷了該次示範。

其實這裡完全沒有必要在初次demo的時候就把整個環境給架構起來，完全可以在資料控制層下面嫁接一個伺服器模擬器，這樣你的資料就不用非要通過網路和資料中心進行互動了(這裡涉及到了MVC 分層架構-模型/視圖/控制，如有不清楚的請自行百度)。這樣做了之後，銷售人員去demo的時候只需要給對方看下伺服器的外觀，就可以在不接入伺服器的情況下直接在電腦上把軟體裝上進行示範了。過程只需要向對方表明真實情況下資料是通過網路儲存在資料中心的，只是現在為了方便demo而臨時存在本地而已。

所以這裡產品經理要考慮的不僅僅是真實的產品出來的情況，還需要考慮如何方便銷售團隊在外進行示範，特別是在產品早期擷取使用者反饋的時候。不然你沒有足夠的使用者反饋支撐的話，最終還是走回了閉門造車的老路。

別預設架構師或者專案經理會幫你考慮好銷售團隊遇到的這些困難，這個產品是你的(其實在Scrum裡面，產品經理的名字叫做Product Owner，也就是產品擁有者)，專案經理和架構師等團隊成員只是負責將你交給他們的產品backlog在預期時間內實現出來而已。

競品分析

上面在談使用者體驗的時候有談到過這一點，一個產品經理要時刻注意著市場的動態，留意著競爭產品的動向。比如我們一開始做的雲產品就犯了這樣的錯誤，一開始市場上難覓競爭者，戰線開始拉得太長，功能不斷疊加，產品遲遲沒有推出市場。某一天忽然跳出了個新聞，“百度雲1T永久容量 率先進入雲空間T時代“，我們的心幾本上就已經涼了半截了。

當然，事實上我們當時的產品遲遲沒有推出市場的原因錯綜複雜，但是，毫無疑問，對市場動態和競品的分析力度和把握的不夠是其中一個不可忽視的原因。

所以作為產品經理，要時刻的眼觀八路耳聽四方，也許競品新版本的一個新功能的出現，你就需要立刻有針對性的調整自己的產品的實現策略。

要知道，一個產品經理不應只是知道不停的往產品backlog中增加新的功能，更重要的是你要知道不停的為公司增加新的增值。

除了上面說的這幾點，其實我覺得以前做產品經理的時候還有很多地方值得最佳化的，比如功能點優先順序排序的把握(這裡特別要提到的事三個木桶原則，具體請查看本人之前翻譯的一篇文章《如何打造一個偉大的產品》)，功能點最佳化，產品可擴充性的掌控，團隊的互動，與專案經理的合作等等，但是限於篇幅和時間，暫時就先說這麼多吧，也許今後會另外開篇繼續進行闡述。當然，也希望各位看官能在評論中說出你們的觀點。

提醒:更多文章請關注公眾號:techgogogo或官網www.techgogogo.com。當然，也非常歡迎您直接(zhubaitian1)勾搭。歡迎轉載，轉載時敬請保留公眾號等資訊。

著作權聲明：本文為博主原創文章，未經博主允許不得轉載。

軟體行業從業十年的產品經理的得失雜談