>>>  創業先鋒 眾人拾柴火焰高  >>>

簡體     傳統

說服力：從場景化出發的用戶價值

“按鈕應該放在右邊，這符合規范！”

“但是用戶習慣在這邊尋找按鈕，放那邊不夠自然。”

“這個可以做啊，但是用戶會覺得很好用。”

“有沒有更好的方案，為什么一開始就要做那么復雜的操作呢？”

這樣的討論總是在產品經理評審需求的時候出現。大家目標都很一致：為了用戶和產品的發展。但每個人的視角或有不同，這時，產品經理就應該具備上帝視角。什么是“上帝視角”？就是指產品經理不僅可以看到主流用戶的需求，還可以看到其他伙伴各自的出發點，可以和他們進行良好溝通，推動產品實現。前文曾談到為什么需要產品經理這個職位，我認為，產品經理在整個項目中不僅需要對需求負責，更要成為伙伴之間的“潤滑劑”——可以和產品經理PK 需求，也能和開發人員探討技術方案的實現，還可以和設計師聊一聊最新的設計風格，最關鍵的是產品經理需要了解用戶。

但事實上，誰都覺得自己更了解用戶，覺得自己本身作為一個用戶沒有被滿足需求。這種情況時常出現在每次的評審中，這就要求產品經理可以做適當的溝通。前文出現的激烈爭論并非是壞事，對于需求來說，可以越辯越明，但對于決策來說，卻不符合呆伯特會議規則，無法說服其他伙伴同意產品經理的方案。還有一種可能的情況，即產品經理強勢地要求開發工程師或者設計師按照自己的理解去進行，通過“項目時間”和“老板需求”來強迫他們“心甘情愿”地實現需求。這種“狐假虎威”的做法有時候有效，但對于產品開發來說，并不是一件好事。

在產品開發過程中，如果相關人員都沒有被產品經理說服并同意產品經理的方案，就容易產生情緒——而情緒化的結果則是潛伏在產品開發過程中的各種風險都會不斷出現。例如，開發工程師沒有準確地理解需求，馬馬虎虎地完成功能，忽略了相關邏輯和細節實現，或者將這位產品經理的需求優先級放低，不斷拖延……這種情況很常見。我私底下和一些工程師關系不錯，有時候就會問他們，為什么有的需求完成度很低，有的時候需求bug 會特別多？他們會回答：“不想做或者有其他優先級的事情。如果充分理解了需求，我們也是很樂意去做的。但是平時產品經理都不和工程師一起玩，沒有太多的革命友誼，所以大家都是公事公辦，公事公辦的后果就是先做其他事情。”

產品經理們，去施展你們的影響力吧！準確地闡述用戶需求和價值，讓伙伴們認可你的方案，這對于方案的實現有著重大的意義。用戶需求時常被挑戰的重要原因之一就是缺乏場景，大部分時候把自己當作用戶并不能很好地反映客觀情況，需求往往是伴隨著場景而變化的。正如《探索需求》中所言：“除此之外，人們并不經常購買他們所需要的東西，卻常常追求他們并不特別需要的東西，即使這種期望是短暫的。”

場景化需求才會產生“期望”，而不考慮場景提出的需求，雖然客觀存在，卻不一定是最想要和最需要被滿足的。因此，產品經理在面臨日常的方案挑戰時，一定要關注將需求和場景結合起來，如果可以考慮用戶的使用習慣和行為數據，則會更加具備說服力。

第一次做功能——從失敗到成功

第一次做功能，對于許多產品經理來說，意義非凡。但對于一個入門者來說，第一次做功能往往需要人進行輔導。在騰訊內部，導師一般會安排剛入門的產品經理承担一些簡單的需求，并會進行對應的指導。即便如此，看過本書前幾章的產品經理可能依然會有點茫然：“雖然我都知道該怎么做了，但是如何開始第一步呢？”

許多人在產品分析時表現得頭頭是道，但一面臨實踐操作往往就發現，理論再靠譜，也難以應用到現實中來。記得我第一次跟進的需求是做一個閱讀文章的功能。當時我畫了思維導圖，又用PPT 做了幾個線框圖做說明，還寫了Word 版本的需求文檔。但事實上，這幾個東西都沒有起到太大作用——因為每個產品經理做需求的第一步，不是動手去做，而是思考。

第一次做功能：產品設計階段

三思而后行，這是我的個人經驗。如果一個產品經理在接到任務之后，不假思索地就開始要各種資源，拉設計師和工程師討論需求，肯定會受到各種挑戰和不信任。任何一個需求都應該被拿來好好思考，清楚了整個流程，考慮了各種情況都會有哪些效果，產品經理的心里才會有底，才能有效地傳達需求給其他人，才可以更快地推進需求實現。

當時，我接手了閱讀文章的功能，于是馬上找到設計師傳達需求，就遇到了類似的問題。

產品經理：我這邊有一個閱讀文章的需求，你能幫忙看一下嗎？

設計師：要閱讀什么文章，是一個怎么樣的功能？

產品經理：就類似Google Reader。

設計師：Google Reader 有哪幾個頁面，大概流程你清楚嗎？這個功能的目標是什么？

產品經理：目標就是為了看文章，和Google Reader 一致就可以了。有很多的訂閱文章，然后把文章排個版，加入微博分享、收藏這些功能。

設計師：是需要和Google Reader 一致嗎？但是我依然不清楚閱讀文章是要干什么，是為了收藏？

產品經理：……

很顯然，產品經理對于需求的理解很模糊，沒有具體的目標。雖然從入門開始就一直被灌輸用戶第一的理念，但是一接到需求就什么都忘記了。對于一個需求任務，如果產品經理未能很好地進行分析和界定，一開始就找對應的人員進行溝通，或者簡單地把方案類比為其他產品，是一種很不專業的做法。

在進行了詳盡地分析之后，我重新調整了需求功能點，通過思維導圖展示了基本的需求說明（參見圖3.4）：

圖3.4 閱讀產品的需求列表展示

粗略看起來，好像這個功能點覆蓋得很全面，但讓人很難理解，這個功能究竟是什么樣的？看起來好像有一個目錄頁和一個全屏頁，但頁面內的效果該如何展示呢？目錄頁中的幾個子選項——工具條、文章內容、預加載、翻頁操作和區域操作——究竟是什么關系呢？

當時的我還沒有意識到一個問題：思維導圖并不適合說明需求，而更適合整理需求點——而整理需求點，是產品經理自己的作業，拿出來給工程師和設計師看，誰都會很困惑吧。于是，費盡了功夫的我獲得了兩個教訓：

選擇工具很重要。
羅列功能并不是需求文檔。

經歷了現實的打擊之后，我重新調整了需求文檔，將改用Word 模版的需求文檔交付給對應的設計師。

第一次做功能：開發階段

沒過多久，交互設計師就輸出了基本的交互稿，和我的想法是基本一致的，于是我開心地找工程師評審需求了。然后又遇到了第二個問題：那些輕描淡寫的“自動刷新邏輯”、“頁面排版邏輯”究竟是什么玩意？

工程師對此表示很遺憾，他們找遍了需求文檔也不知道要怎么做，于是我給他們又進行了一次方案宣講，并把對應的內容都寫入了需求文檔中。對于工程師來說，他們的目標就是準確地實現需求文檔的要求。因此越清晰的要求，對于他們來說越省力。所以入門的產品經理需要關注這個案例：盡量用詳盡的文字去描述每一個細節。

自動刷新邏輯

觸發條件：當用戶進入該頁面，觸發自動拉取最新數據的操作。

刷新展示：如果刷新成功，則頁面展示最新內容（漸顯效果）；如果刷新失敗，則彈出“刷新失敗，請稍后再試”的提示。

圖片展示：未拉到圖片時，需要展示一個占位圖，在一分鐘內進行多次圖片拉取；如果圖片拉取失敗，則出現一個裂圖；超過一分鐘，允許用戶手動點擊占位圖進行拉取圖片的操作響應。

每篇文章的摘要顯示及排版：××××××××

如果由于網絡原因數據拉取失敗，需要提示網絡錯誤。

如果由于網絡比較慢，則在一分鐘內多次嘗試拉數據；超過一分鐘則等待用

戶手動觸發刷新操作。
……

以上只是展示了正常的邏輯，還有許多異常情況沒有考慮，因此產品經理在描述需求時，切記把每一個細節都考慮到，尤其是異常情況。對于工程師來說，沒有歧義且包含多種場景的需求描述，才是好的需求文檔。“自動刷新”雖然是簡簡單單的四個字，卻包含了有可能四百字都描述不完的細節。

第一次做功能：產品體驗及改bug 階段

只有真正參與過項目，產品經理才會了解人與人之間的溝通是多么重要。如果僅僅依靠需求文檔，產品經理可能會發現開發工程師實現的功能和當初構想的功能會有許多差異。先不要担心，這些差異的存在是必然的，畢竟開發工程師不會讀心術，而文字描述本身就容易出現歧義，這些差異都可以在體驗階段修改。

但這個事情從側面反映了一個問題：需求文檔還是不夠細致。

災難到這里就結束了嗎？產品經理體驗了產品之后交給測試工程師測試，這才是產品經理發現自己無知的時候呢！測試工程師會根據測試用例提出許多異常情況，而產品經理會發現，怎么這些場景我都沒有考慮到！怎么會有如此多的bug！

先別著急，這些問題幾乎在以后的產品開發過程中都會遇到。但這些“突如其來”的災難的確容易讓剛入門的產品經理手忙腳亂。有條理地去解決這些問題吧！產品經理之路還遠著呢！

雖然第一次做產品需求就像個災難，但后來回首這樣的經歷，可以發現一個有趣的事實：盡早失敗，盡快改正，是產品經理成長的必經之路。而在我往后的產品經歷中，往往都會想起這樣一句話：把功能想透徹。對于產品經理來說，需要想清楚以下幾個問題。

●Who：用戶是誰，他們有哪些特征？
●What：這個功能具體是怎么樣的，確認需要做哪幾個功能？
●When：什么時候會使用？
●Where：使用場景是什么，功能頁面之間是什么樣的關系？
●How：用戶如何正常使用對應的功能？

什么叫作“想透徹”？不如請各位產品經理先想一想如何用一句話準確地表達手頭的需求，如果不需思考就能脫口而出，那說明你已經在思考，反之則需要捫心自問，自己是否已經了解該需求。如果想要檢測自己是否想透徹了，還可以通過以下的幾個問題進行自測：

●用戶的需求是什么？
●這個需求可以分解成多少個小點？
●這些小點有哪些可以滿足，哪些不需要滿足？
●每個需求點可以通過什么樣的功能去滿足？
●這幾個功能之間的關系是什么？
●整個方案有幾個頁面，和整個產品的關系是什么？
●功能的入口放在哪兒？
●用戶發現了這個功能之后，他們會怎樣使用？
●如果用戶中斷了操作，會出現什么提示？
●是否針對功能操作設置了保護機制？

這些只是最簡單的一些問題，接下來我會結合自己做產品的經驗及一些朋友的經歷舉出一些常見的問題，希望可以給剛入門的產品經理提供更多啟示。

常見的問題案例

問題一：沒有分解需求。

每個人對于需求的理解都有所不同。產品經理在描述需求的時候，需要盡可能詳細和無歧義。例如：

●我想在坐電梯的時候可以獲得資訊。
●我想在坐電梯的時候可以獲得關于股票的消息。
●我想在坐電梯的時候可以了解到公司股票的實時走勢圖和實時價格。

各位覺得哪個描述更容易被理解，而且沒有太多含糊的信息呢？不僅僅是描述容易出現問題，大部分時候需求描述有問題就是因為需求沒有得到有效地分解。產品經理還需要注意對需求進行分解，像嚴謹的解構主義者，不放過任何一個概念。越是分解細致，越容易降低含糊信息出現的幾率。

問題二：缺乏對用戶的了解。

雖然在前面一直提到以用戶為中心的產品理念，但因為某些原因，大部分時候產品經理不得不盡快明確需求，而等不及對用戶進行了解。這種閉門造車的需求很容易產生一個可怕的后果：用戶不買賬。歷經千辛萬苦做完一個功能，產品經理沒有功勞也有苦勞，但用戶不買賬。這就是缺乏對用戶了解的后果，即使產品經理耗費大量資源和時間，但是做出了用戶不喜歡的產品，那么一切都是在做無用功——即使產品經理自己覺得在做創新，用戶不買賬是因為他們視野不夠，但不被用戶接受就失去了產品的使用價值，不符合市場的供求機制。

問題三：急于推動方案，而非獲得支持。

因為剛入門的產品經理往往缺乏自信和魄力，所以很難得到工程師和設計師的信任。但由于產品經理希望盡快推動功能進行開發，所以會不斷地催促設計師和工程師動手做需求。

做需求本身是一個合作的過程，如果忽略溝通，不管需求的背景和目標，而僅僅是傳達任務，那么對于設計師和工程師來說，這是一種缺乏合作精神的行為。雖然產品經理是無授權的領導，但在日常需求合作的過程中，產品經理更重要的角色是“潤滑劑”，即溝通各方人員，確認他們都了解需求的背景和目標，保持信息一致。

得道者多助，失道者寡助。獲得了設計師和工程師們的支持，對于產品經理來說是好事，因為這意味著你們在同一條船上，可以一起朝目標前進。而失去支持的產品經理，時常會遭遇到不合作，或者不認真的合作，這種情況下,需求在實現過程中常常會出現惡性循環，導致需求總是返工，每個人都不好受。

問題四：容易被忽悠。

不懂技術的產品經理時常會被忽悠。這種情況并非開發工程師不合作，而是他們在暗示對產品經理缺乏信任。

●你自己根本不清楚需求要怎么做。
●你根本不了解我的工作很多，總是打擾我。
●和你溝通很費力，忽悠你趕快走！

剛入門的產品經理缺乏經驗，總是容易被各種術語忽悠——想要改變這種情況，那就要讓工程師們信任你。我常用的方法可以分享給各位試一試。

●復雜的功能如果已經在其他應用上實現了，工程師們二話不說，拼了自尊也會去實現的。

●如果他們冒出大量術語，你可以試一試請教他們這些“牛逼哄哄”的術語都是什么意思，他們愿意介紹這些“牛逼哄哄”的術語。

●不管如何，確認他們對需求理解到位，必要的時候可以讓他們重復表述一遍。

其實以上幾個問題都非常容易出現，但大部分時候都可以歸結為一個概念：含混性。什么是含混性？產品經理對用戶的需求理解出現偏差，工程師對產品需求理解出現偏差，設計師對產品需求理解出現偏差，這些都是含混性的表現。

GameRes游資網 2015-08-23 08:41:55