讓產品經理頭疼的四個難題（上）

前言：所有的產品經理都經歷過讓人生氣到罵髒話的項目吧。雖然書本上的項目管理很有套路，項目管理本身的方法論也很多，似乎只要追尋著這些方法論，就能滿足強迫症患者們的期待一樣，有節奏、有計劃的組織一個項目。但事實卻總不是這樣。今天要討論的，是站在產品經理的角度，在項目管理的過程中會遇到的那些現實且方法論上沒有答案的問題。由於這些問題多數來源於企業文化、社會問題或是人性本身，基本上是無法避免的，我們只能用招數儘可能去破解它。

一、需求確認，永遠的大難題

雖然《啟示錄》這類方法論書中反覆提到過，企業不應該拿正式產品當原型使用，而是真真正正在demo階段把需求打磨清楚。現實情況卻不然，需求方總是在確認原型時不走心、不動腦，仍然習慣在上線以後才拿著正式產品開始提需求。

方法論中教過我們的需求文檔、郵件確認等，坦白說，各種原始方法加無限升級版我都試過，但效果完全取決於我們同事的水平和所在公司的管理機制。也就是說，不取決於你和我本身。我遇到過最無奈的真實場景，是把雙方明確確認過的需求郵件攤在面前，對方也能若無其事的回上一句 「對，當時沒想清楚，現在就是要改，有什麼問題嗎？」

任何沒有獎懲機制的制度都等於沒有制度，需求確認也是如此。如果我們所處的企業本身沒有對需求、項目管理有明確機制，又或者這個機制僅僅有正向的流程指引，而沒有當人們不按流程走時會怎樣處罰的規定，那麼，每個人都一定只會按自己最舒服、最習慣的方式去工作，制度就像一幅蒙娜麗莎一樣掛在牆上微笑的看著我們。

制度不好，就自己提出制度？省省吧，先看清楚自己是誰。並不是歧視底層執行人員，而是就效果而言，不可能有一個至下而上的針對管理層面的改造，所有的管理改進一定是至上而下，且是領導層首先親身表率的。對於基層而言，我們只能選擇適應或者離開。

給參與需求分析的業務方教育、培訓？依然不行，除非你有信心能讓一個不愛學習的人從此愛上學習，否則讓一個不願意提前動腦、系統化總結業務問題的人去思考、去總結，還要負責任的提交確認，這難度可不比改變一個人的價值觀低。

這種情況出現的原因到底是什麼呢？

舉例來說，當我們想買一台電腦的時候，會怎麼做？是先拿支筆、摳摳腦袋、網上學習各種電腦參數的資料，再把自己買電腦的需求、問題分析清楚，最終得出一個採購方案，再去購買嗎？肯定不是這樣的。我們一定是一開始就在電商網站或是商場櫃檯前踱步，看看哪款更適合自己，在選擇的過程中逐步摸清自己的需求，最後選一個綜合來看較為滿意的下單。

這個例子是不是很親切？當一個任務出現時，人們會首先把自己擺在責任人和非責任人的兩個角色之一。當對方認為自己是非責任人時，我們去諮詢他們的意見（其實是在進行需求調研），他們會本能的把自己當這件事情的客戶。這是他們從小到大經歷過最多次、最有經驗的角色，而幾乎沒有任何人受過「需求方」這個角色的訓練。試想，我們的職場中，有這樣的培訓、培養機制嗎？沒有，那既然如此，又有誰會天生勝任一個負責任、專業的需求方角色呢？因此，每個人其實都是在當客戶，提出需求就像是買東西一樣，都是在憑自己的感覺、責任心、性格在做需求方，自然結果是層次不齊了。

* 前面提過的，從個人單方面的去培訓需求方是不太現實的，但如果一個企業足夠強大，是應該對所有需求方進行如何勝任需求方角色的職業培養和設立制度規範的。

解決這種問題的方法是什麼呢？

回到前面的例子，如果需求方是像客戶一樣擅長選擇商品而不能提前設計和思考，我們該如何在投入巨大的製造成本和時間之前，就提前儘可能的確認準確的需求呢？我儘可能窮盡一些方法，來一一討論。

A）製造出成品，讓需求方在成品的使用中提需求

這恐怕是大部分公司的現狀了，雖然誰也不曾希望這種結果發生。也因此，催生了一種「快速迭代」的不合理用法，最常見的，是在0到1的初創階段濫用「快速迭代」思想，以此來狡辯需求方不動腦經或沒有經驗的本質。這種場景下，只有一種破解方法，便是減少製造成本。儘可能的壓低製造所消耗的時間、資源、金錢，也切忌做架構搭建、技術前瞻，可以說濫用場景下的「快速迭代」和擴展性架構兩者本身就是互斥、矛盾的。

B）把原型做到足夠逼真，讓需求方調用大腦中的「買東西」神經

雖然產品經理提前給過原型、UI高保真設計稿，但這些資料與真實產品之間的差距往往是需要技術知識來做判斷的。舉個真實的例子，一個客戶請攝影師給商品拍攝了一套宣傳照，並選出了幾張樣片請攝影師繼續修圖，其中有一張原片非常完美的被客戶淘汰掉了，攝影師便很納悶詢問原因。客戶解釋到，片子拍斜了，沒法用。結果攝影師在ps里旋轉了15度，就解決了「拍斜了」的問題。客戶驚嘆到，怎麼這麼神奇，我還說拍壞了可惜呢。這就是典型的由於缺乏技術知識對判斷產生的影響。項目管理中也是如此，原型、UI在產品經理眼中已經足夠逼真了，不就是差個按鈕點擊能跳轉至下一頁之類嗎。但就是這些非常細微的腦補工作，造成了需求方心理感受的差距，他們無法調用大腦神經中那個熟悉的「買東西」模式，也因此很難認真、走心的去關注這些原型。大部分的經驗告訴我們，原型和UI往往過得很順利，是因為這些地雷會在測試環節或上線後才爆發。

簡單的花點時間做出接近於真實產品的demo是十分有必要的，這些模擬的點擊感、高保真UI的親切感，都能讓需求方彷彿置身於測試環境，像是在把玩一個即將上線的產品，他們一定會卯足精力的提出各種想法來。

C）多讓需求方做選擇題

這種方法需要產品經理自身的經驗和能力都足夠高，能夠提出好的問題，引導需求方思考和給出答案。想要坐享其成的等需求方把流程圖畫出來？算了吧。需求方往往並不知道產品經理想要設計什麼，也不知道思考的方向和關鍵的判斷點，讓對方整理的需求往往丟失了很多關鍵性細節，又或是多了很多無用的信息。與其把需求分析交給需求方自己，還不如產品經理多花些精力自己來尋找答案，這些時間看似費時，但收穫卻巨大。

二、那些讓人瞬間憤怒的話

很多需求方在測試或驗收時，總是會順口的說一句「這不很顯然應該是……」、「這還用說嗎，肯定是……」之類的話。在他們眼中，那些錯誤犯得是那麼可笑和低級。這時候，產品經理很容易瞬間憤怒，心想著，你倒好，不僅不給我明確需求、自己總結問題能力差，還倒怪我是傻子。

第二種場景，是需求方或產品經理在變更需求時，常常脫口而出「你們改一改嘛，應該很簡單的」、「這個我覺得很簡單呀」。我相信聽到過這種話的研發肯定不少，沒有一個不生氣、不憤怒的，心想著，你自己需求想不清楚、頻繁變更，你也不懂技術、也不是你開發，有什麼資格說這個事情簡單呢，YOU CAN YOU UP啊。

第三種場景，最容易出現在項目的瓶頸期，例如聯調阻塞、測試階段發現較重大的BUG一類，往往領導處於偶然的原因，會突然關注某些具體的問題來。這時候的領導，很容易對這個具體的問題極為關注，組織會議討論、緊急推進進度，並且發出了「你們平時都是怎麼幹活的，這個問題今天要不是我發現了，你們都沒法解決嗎」的感嘆。這些平時已經加班連連的同學們，往往會特別鬱悶，心想著平時的那些苦勞、功勞難道你們領導都瞎嗎。

這種情況出現的原因到底是什麼呢？

People believe what the want to believe，我們每個人都是通過自己的視角去理解問題，進而得出一個永遠都不可能全面，也幾乎不可能正確的結論。在每個人腦中，都有一套對這個世界的解釋。正因如此，沒有做過技術的人，往往會說出修改個代碼很簡單的話，總認為自己知道的事情別人也理所應當知道，而自己不知道的事情，就像是不存在這個世界一樣。

例如，你可能花了一周非常辛苦的忙於市場調研，而你的領導卻突然冒出一句「你應該去做市場調研了」這樣的話，或是當你已經在客戶那裡周旋了很長時間了，領導卻開會時講「我們幾乎不去管理你客戶，這是不行的」。是不是覺得很無語？難道我做的這些事情都等於沒做過嗎？當然不是，客觀來說肯定是做過了，甚至做得很好，但問題是領導不知道，所以從ta的視角來看，這個事情在ta的認知里是等同於沒做過的。

再舉個例子，Trump上台的第二天，有一則新聞標題為「多人上街遊行抗議，Trump不受美國人民支持」。這則新聞的邏輯問題在哪裡呢？上街遊行抗議的，一定是不支持Trump的，而支持Trump的人，肯定不會上街遊行抗議。所以這就相當於1=1一樣，是一個邏輯的陷阱，用這個固然成立的視角去誤導觀眾，得出一個不真實的觀點。

解決這種問題的方法是什麼呢？

和第一則相同的觀點是，我不認為可以去培訓一個人達到理解事務的能力，如果一定要人本身的素質達到這種狀態的話，也應該是在招聘把關，而不是招聘錯誤的人再慢慢改變ta。

真正可行的方法是，首先，儘可能的把信息提供給對方，而不是幫對方下結論。例如，產品經理可以盡量告訴研發需要調整需求的原因，或是告訴需求方自己現在很難接受需求調整的原因，讓這個告知的過程儘可能的豐滿、完整、充滿代入感。只有這樣，對方才能真正理解你的思路、支持你的決定，甚至給出你意想不到的好建議。

其次，是巧妙的利用人們的「視角」。你的領導誤以為你沒有作為，是因為你沒有讓ta感受到你的作為。讓對方適當的參與到一些過程中來，和你一起經歷一些決定和思考，讓這件事情更加豐滿的在對方心中留下烙印。就算不能如此，也至少要做到適當的把過程、節點反饋出來，讓對方了解這個事情的進度。有時候，我們管理的可能並不是一件事情的結果，而是人們對這件事情結果的一個感受。

最後，是智者本身。普通人只能通過「視角」理解事物，那麼誰能夠突破自己的視角去儘可能理解事物的全貌，誰就獲得了更高維度的視角、理解力、甚至是世界觀。

to be continued...
推薦閱讀：