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

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

經(jīng)歷了現(xiàn)實的打擊之后，我重新調(diào)整了需求文檔，將改用Word 模版的需求文檔交付給對應(yīng)的設(shè)計師。

第一次做功能：開發(fā)階段

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

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

自動刷新邏輯

觸發(fā)條件：當(dāng)用戶進(jìn)入該頁面，觸發(fā)自動拉取最新數(shù)據(jù)的操作。

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

圖片展示：未拉到圖片時，需要展示一個占位圖，在一分鐘內(nèi)進(jìn)行多次圖片拉??；如果圖片拉取失敗，則出現(xiàn)一個裂圖；超過一分鐘，允許用戶手動點擊占位圖進(jìn)行拉取圖片的操作響應(yīng)。

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

如果由于網(wǎng)絡(luò)原因數(shù)據(jù)拉取失敗，需要提示網(wǎng)絡(luò)錯誤。

如果由于網(wǎng)絡(luò)比較慢，則在一分鐘內(nèi)多次嘗試?yán)瓟?shù)據(jù)；超過一分鐘則等待用

戶手動觸發(fā)刷新操作。
……

以上只是展示了正常的邏輯，還有許多異常情況沒有考慮，因此產(chǎn)品經(jīng)理在描述需求時，切記把每一個細(xì)節(jié)都考慮到，尤其是異常情況。對于工程師來說，沒有歧義且包含多種場景的需求描述，才是好的需求文檔?！白詣铀⑿隆彪m然是簡簡單單的四個字，卻包含了有可能四百字都描述不完的細(xì)節(jié)。

第一次做功能：產(chǎn)品體驗及改bug 階段

只有真正參與過項目，產(chǎn)品經(jīng)理才會了解人與人之間的溝通是多么重要。如果僅僅依靠需求文檔，產(chǎn)品經(jīng)理可能會發(fā)現(xiàn)開發(fā)工程師實現(xiàn)的功能和當(dāng)初構(gòu)想的功能會有許多差異。先不要擔(dān)心，這些差異的存在是必然的，畢竟開發(fā)工程師不會讀心術(shù)，而文字描述本身就容易出現(xiàn)歧義，這些差異都可以在體驗階段修改。
但這個事情從側(cè)面反映了一個問題：需求文檔還是不夠細(xì)致。

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

先別著急，這些問題幾乎在以后的產(chǎn)品開發(fā)過程中都會遇到。但這些“突如其來”的災(zāi)難的確容易讓剛?cè)腴T的產(chǎn)品經(jīng)理手忙腳亂。有條理地去解決這些問題吧！產(chǎn)品經(jīng)理之路還遠(yuǎn)著呢！

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

●Who：用戶是誰，他們有哪些特征？

●What：這個功能具體是怎么樣的，確認(rèn)需要做哪幾個功能？

●When：什么時候會使用？

●Where：使用場景是什么，功能頁面之間是什么樣的關(guān)系？

●How：用戶如何正常使用對應(yīng)的功能？

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

●用戶的需求是什么？

●這個需求可以分解成多少個小點？

●這些小點有哪些可以滿足，哪些不需要滿足？

●每個需求點可以通過什么樣的功能去滿足？

●這幾個功能之間的關(guān)系是什么？

●整個方案有幾個頁面，和整個產(chǎn)品的關(guān)系是什么？

●功能的入口放在哪兒？

●用戶發(fā)現(xiàn)了這個功能之后，他們會怎樣使用？

●如果用戶中斷了操作，會出現(xiàn)什么提示？

●是否針對功能操作設(shè)置了保護(hù)機(jī)制？

這些只是最簡單的一些問題，接下來我會結(jié)合自己做產(chǎn)品的經(jīng)驗及一些朋友的經(jīng)歷舉出一些常見的問題，希望可以給剛?cè)腴T的產(chǎn)品經(jīng)理提供更多啟示。

常見的問題案例

問題一：沒有分解需求。

每個人對于需求的理解都有所不同。產(chǎn)品經(jīng)理在描述需求的時候，需要盡可能詳細(xì)和無歧義。例如：

●我想在坐電梯的時候可以獲得資訊。

●我想在坐電梯的時候可以獲得關(guān)于股票的消息。

●我想在坐電梯的時候可以了解到公司股票的實時走勢圖和實時價格。

各位覺得哪個描述更容易被理解，而且沒有太多含糊的信息呢？不僅僅是描述容易出現(xiàn)問題，大部分時候需求描述有問題就是因為需求沒有得到有效地分解。產(chǎn)品經(jīng)理還需要注意對需求進(jìn)行分解，像嚴(yán)謹(jǐn)?shù)慕鈽?gòu)主義者，不放過任何一個概念。越是分解細(xì)致，越容易降低含糊信息出現(xiàn)的幾率。

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

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

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

因為剛?cè)腴T的產(chǎn)品經(jīng)理往往缺乏自信和魄力，所以很難得到工程師和設(shè)計師的信任。但由于產(chǎn)品經(jīng)理希望盡快推動功能進(jìn)行開發(fā)，所以會不斷地催促設(shè)計師和工程師動手做需求。

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

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

問題四：容易被忽悠。

不懂技術(shù)的產(chǎn)品經(jīng)理時常會被忽悠。這種情況并非開發(fā)工程師不合作，而是他們在暗示對產(chǎn)品經(jīng)理缺乏信任。

●你自己根本不清楚需求要怎么做。

●你根本不了解我的工作很多，總是打擾我。

●和你溝通很費力，忽悠你趕快走！

剛?cè)腴T的產(chǎn)品經(jīng)理缺乏經(jīng)驗，總是容易被各種術(shù)語忽悠——想要改變這種情況，那就要讓工程師們信任你。我常用的方法可以分享給各位試一試。

●復(fù)雜的功能如果已經(jīng)在其他應(yīng)用上實現(xiàn)了，工程師們二話不說，拼了自尊也會去實現(xiàn)的。

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

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

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

文章來源：騰訊大講堂