作為產品經理，如何培養考慮周全的思維？

01-08

作為產品經理，如何培養考慮周全的思維。就是儘可能讓測試與開發少提出bug。包括新功能需求的邏輯漏洞，與優化需求牽扯到的細節。我是說思維模式，當然人性的惰性也要知道如何客服。
我想不單單是工作，生活中也要有周全的思維，才能更好地生活。

找別人 critic，問別人要 feedback。用中文說，就是「批評與自我批評」中的「批評」。如果一個潛在的問題你身邊跟你一樣聰明並擁有不同專業背景和經驗的人都找不出來，那就是真找不出來的了。

這事情說起來簡單，但其實做起來有很多細節，本質上都是因為人類不喜歡被別人批評，尤其是當眾批評。一個團隊或者說一個公司內否培養好的文化來做好這件事很重要，如果這事情表面上說得很好聽但實際上做不到，那相當於沒有用。

首先，作為接受 critics 的人要能夠主動接受和改進。如果只會為自己辯護，很快別人就懶得跟你說了。如果把別人說的聽進去但不改變，別人也會慢慢發現跟你說任何事情都是浪費時間。

其次，要對改進主動負責。別人告訴你要做這樣的改動，你覺得你聽明白了，你實際聽明白了嗎？別人不會對這件事情負責任的。你沒有聽明白，別人覺得你聽了也不會改，或者心裡默認「這個人是傻逼」，那你就完了。所以你要主動追問別人你改進後的結果是否達到別人期望。如果你的一份設計評審後你自己改完了就叫別人去做，別人可能看到改過的設計後就會說「這傻逼連我的評審意見都看不懂」，所以必須先虛心地問別人你這樣改是不是對的。

最後，對最終結果負責，不要把責任攤到給你 critic 的人頭上。永遠不要說「如果我當初不根據你評審建議做改動可能就成功了」。別人給你的所有建議都僅僅是建議，一方面你要做到尊重這些建議（否則日後就不再有建議），另一方面建議可能是錯的，多個建議之間可能有衝突，你要想辦法處理好。最終的決策權在你手上，最終的結果你要負責任。不要在項目失敗後把責任推給參加評審的人。（但如果項目成功，你還是要感謝大家，因為大家不理你的話你也做不成功。）

我是個半歲的產品，隨著慢慢開始承接文檔的撰寫，也踩了很多很多的坑，在這裡和你分享一下我的一些想法和努力。

流程圖一定要畫，隨便貼一張最近的流程圖

不要一上來就開始畫原型，請先把流程圖畫好，流程圖可以不用特別細緻，甚至可以不是那麼對，只把業務畫出來是可以沒問題的，但是隨著你梳理業務的時候，你自己就會慢慢發現問題，然後把問題記錄下來，這樣就能先埋一些坑。

數據守恆定律，數據不會憑空消失，也不會憑空產生

這是我們的開發千叮嚀萬囑咐我的一句話，原型中的每一個數據，都是要有來源的，請把數據是從哪來的，都要一一寫清楚想明白。

結構化的思考文檔可以節省你的腦力

寫文檔的時候最好按照固定的套路來寫，這樣一來二去，開發也明白了你的套路，你也不會自己亂掉，忘記寫到哪裡了，這裡在貼一個看文章和自己總結下來的文檔注意項腦圖，每次寫文檔按照這個順序來考慮，寫起來會省心很多，也能避免遺漏。

碰到拿不準的，趕緊去找開發（爸爸）

在寫文檔的時候，很多問題的處理作為一個略（臭）懂（不）技（要）術（臉）的產品小白，如果自己閉門造車，想出來的處理方案是吃力不討好的，可能開發爸爸很簡單就能解決的一個問題，你寫出來的解決方式又臭又長，所以別給自己找事兒，多動腿多動嘴。

寫完了以後一定不要覺得萬事大吉，要反覆檢查排版和表達是否有歧義，有沒有遺漏，最好再想想過需求的時候怎麼樣才能表現的不要像一個智障

這一點至關重要，你前面做了那麼多努力，結果過需求的時候因為一點小失誤和不知道該怎麼說，而讓眾人覺得你像個智障，相信我，體驗很差（別問我為什麼！媽的）

最後的最後，

只收圖不點贊的，我詛咒你們吃速食麵沒有調料包！

補充一點，如果有空，多跟測試溝通，學學怎麼寫測試用例，也很有用

多和技術撕逼，產品經理是動腦，技術開發是動手，只有動手的人才知道實現起來的那些種種坑。

比如我要在APP里添加一個用戶間可以發私信的功能。

不是很簡單嗎？一個發信，另一個收信。

寫信界面，收件箱界面，閱讀界面，3個東西連起來over了。

需求一到開發，立即被懟：「發送失敗提示什麼？接收者賬號不存在提示什麼？提示框模板有嗎？發送失敗後怎麼辦？」

產品：「呃……發送失敗後存到草稿箱吧」

開發：「那你是不是少個草稿箱的功能？草稿箱是本地保存還是網路同步？」

產品：「本地保存吧」

技術：「那用戶換手機了咋辦？那未寫完的草稿全丟了。」

產品：「那就網路同步」

技術：「用戶發送失敗說明網路都不通，同步個毛線啊」

產品：「那我們先本地保存，如果當時沒網路就等到有網路時再同步！」

技術：「程序怎麼知道網路恢復了？」

產品：「定時連一下伺服器，連上了就表示通了啊」

技術：「那我app不就要後台定時喚醒？到時被系統耗電排行揪出來了咋辦」

產品：「我們可以設定後台喚醒時間間隔」

技術：「如果草稿箱里的內容在另一台手機里登陸賬號改了呢？我怎麼知道網路恢復之後是同步上去還是同步下來？」

產品：「每次同步提交總有個先來後到吧，記錄下時間戳，以最後的為準唄」

技術：「得，為了搞個草稿箱，我們把整套雲筆記的方案都搬過來了，你這個坑太深了吧」

產品：「kao，當初換手機丟草稿的問題還不是你提出來的。算了算了，草稿箱我們只本地保存，換手機的，丟了就丟了，我們不管！」

整個就是原點——發散——裁剪的過程，任何一個小問題如果想考慮周全了都會變成馬里亞納海溝。

整個撕逼過程也會讓產品經理知道很多技術細節，但到最後都不得不以快刀斬亂麻把需求簡化收場。

我不知道產品經理如何可以做到考慮問題周全，因為我不了解這個職業。但我知道如何讓一個人考慮問題更周全：閱讀。

一個人的思想如何走出眼前的苟且，了解一件事物的多個方面，明白世界的多元性，學會從別人的角度考慮問題，讀不同的書是最容易最不需要創造機會的方法。

首先，沒有100%的周全，所以不要寄希望於自己搞定一切，然後就萬事大吉了。活到老學到老，一定會有沒有想全的部分，所以要保持謙卑的心態。

其次，推己及人，換位思考，把自己還原成小白用戶，或者把自己當成數據，有點計算機基礎把自己當成比特，多自己過過流程，在任何一個分支節點都想想可能性。拆解並抽象可能性，補充到自己的經驗池。

最後，看到有人說流程圖的，其實只是整個產品實現流程的一環，稍微全一點的流程是：需求分析&>場景用例&>功能列表&>頁面遷移&>PRD，當然，各種分支流程還有一堆，慢慢累積吧。

最最後，提醒一句，初級產品經理到高級產品經理，不是思維周全的經驗累積，所以別捨本逐末了~

曾經我們學院一個教廣告的老師上課從不教廣告，而教哲學，教哲學是教給學生屠龍之術。如今這個老師順利地轉到了哲學系，業餘教經濟學。

學習技術，以及和人溝通的能力

請多找coder，產品一拍腦門出的需求，在我們眼裡看起來就是另外一個東西

其實這個靠天生性格。就算別人總結出很多的方式方法來，但其實也只是一個表象的總結，歸根結底應該從小就思考問題就按相對完整的邏輯方法去思考，久而久之就形成了一種性格。如果成年後踏上工作再去鍛煉這種思考方式是非常難的。這也是一個合格產品經理應該具備的基本條件吧。所以說產品經理並不是人人都適合做的。這也是現在產品這個行當里魚龍混雜的原因之一吧。

當然只具備性格不具備後天知識肯定也是不行的。