最近沒有太多想要寫的內容，又是到了一個思考不足的階段了。

作爲產品經理，平時的文章都是來源於每日的工作，發現問題，然後思考解決問題的方法，或是對某些的問題的理解。如果大量重複性的工作，那麼在思考的時候，就會常常停留於表面，因爲快速的解決當前問題纔是最重要的。

最近發現一個問題，那就是評審結束後，進入開發階段，會發現很多沒有想到的技術問題，統統被拋了出來，而我面臨的是要不要去解決這些沒有寫清楚的問題。所以就是這些細節性的問題，處理起來也是頗有門道，選擇處理和選擇不處理，都不會是一個完整的解決方案，我們要思考問題產生的原因，不斷的提醒自己更優的去解決問題。

一、原因

表層：需求評審、技術確認需求、進入開發、發現不同情況下功能需要多種實現方式。

結果：討論不同情況的處理方式，補充邏輯。這就會造成需求的蔓延，以及版本的延期，因爲討論需要時間，補充邏輯也需要時間，當這些確認後，還要給整個項目組同步信息，個別情況還要向上彙報，一個問題用這套流程處理下來還能接受。但是如果每天都這樣，你會如何呢？

其實，這種情況下，如果能提前讓團隊成員查看需求文檔，那麼可以提前減少大部分的邏輯修改；如果能過一遍技術方案，那麼產品的落地將能更加切合實際。

延展：內部聲音

面對這些細節性的問題，有人說要改，有人建議下期實現，你作爲產品經理是如何進行判斷的呢？當然表層次，用戶用的最多的是必須要改的，但這些細節性的問題大部分情況下都是可有可無的，用戶很難會用的這麼深，所以處不處理都是可以的。

而實際我們要面對的是如何決策，你必須要考慮別人的感受。

一個團隊，有願意配合你的（A），有無所謂的（B），有抗拒的（C）。如果一個方案，你無法說服C，最終選擇了C的提議，你覺得A會開心嗎？長此以往的這樣，以後還會有人願意配合你來實現產品嗎？

有人和我說過，用戶爲中心。這我是堅信不疑，可是呵呵，不是每個決策都是圍繞用戶的，方案落地不靠用戶，靠的的團隊。而很多情況下，我們都是去探索，去嘗試，用戶需求不是主要的，這是事實

曾經一個團隊成員和我說過，決定了我們就去做。改來改去，一直沒有個確定方案。這句話我記憶尤深，正如三國裏面一句臺詞，“決策者錯可以改，但是不能說錯；因爲你錯了，你就喪失了主動”，這句話到哪裏都是適用的。

二、行動

隨時記錄問題

當問題出現的時候，我們要在第一時間將問題記錄上，看看問題產生的頻率，這就能知道自己的方案到底是否完善，然後在下個版本的實現中，參考問題，提出優化改進方案，可以不斷的去完善產品的細節問題。

我們每個人都要及時的跟進問題，否則1-2天后，就會忘記這個問題，錯過了最佳改正時機。因爲別人也在等着你的標準，否則就會出現，技術說“你沒有標準，ok，我自己按照理解想一個”，結果事後作爲產品又不認技術的方案。

多思考在決策

面對細節性的問題，我建議大家不要及時的去認可某一個解決方案，臨時去決策，不經過深思熟慮，那麼肯定會被帶着跑。不同的開發，有不同的意見，A說了方案，你認可了，當做了一段時間後，B來說A的方案有問題，你又覺得B是對的，so？懵逼了吧。

所以當問題來了後，記下來思考下相關性的功能，是否有同樣的問題？是否要上報？然後將自己的思考和大家同步下，提出你的改進意見。

避免問題產生

我要說把細節問題完全不產生，那是不現實的，所以我們只能盡力的去避免。

正如前面說的，如果大家對新的需求能夠提前認知一下，多開一會討論方案，那麼很多問題就能提前解決掉。

就比如需求評審，我們只是評需求是否合理，能不能開發。而需求細節，大部分開發都是按照你寫的PRD邏輯思維進行的，很多地方他們也沒有考慮到。

這時，如果能通過一個週會，解決當前的問題，那豈不是很好，關鍵在於產品經理如何主動的去避免問題。

核心就是多溝通。

好了今天分享結束了，大家有興趣的的可以加我，期待你的到來！