踩多少坑都不怕，只要你記得抽空進行問題總結，以及接下來的計劃安排，下次總會做的更好。

距離我上一篇文章，整整隔了一年，由于換了公司忙的飛起，每個月的一篇文章被加班取代了。針對17年的工作，不反省自我，總結經驗，對不起那些想殺我祭天祈求2018年風調雨順國泰民安的開發啊~這周抽出了時間總結了2017這一年遇到的問題，以下總結10點：

1、需求評審粗糙或缺失

答：

（1）注意好會議前

召集好相關人員參與會議。定好時間、會議室、記錄人。

（2）會議中講解需求流程

• 需求背景：概述需求從哪來，為何要做這個需求。
• 用戶與需求概述：描述解決用戶什么痛點難點，將產品做成什么樣。
• 功能模塊：需求涉及相關的重點大的功能點，按照主流程重點先講，再講分支點。
• 原型與交互：講解原型內容和交互，注意異常流程要提及。
• 數據指標：講解本次需要哪些關鍵性的指標。
• 任務分配：需要其他部門、其他崗位配合的資源羅列出來，提前安排資源支持。

（3）在會議住中找個同事幫幫你做會議紀要，把爭論點疑問點都記錄下來。

（4）會議后，將變更點、變更范圍都記錄清楚，將會議紀要發給大家評估。

2、需求宣講太草率

今年由于項目任務重，時間緊，自己沒有主動發起嚴格的需求宣講，有的開發需求都沒有聽過直接開干了。導致有些需求不太合理，且有些場景細節漏掉了，開發有些需求不理解，因為他們沒有實際操作過業務，中間要廢很多時間精力來給開發測試答疑溝通，一來二去開發想在年底殺我祭天了，我也很痛苦，愧疚又羞愧，還要花時間補充、修改。同時耽誤了其他事情的進程。

答：從下一個新需求開始，我要按照我整理的方法進行宣講，所謂開頭開得好，產品返工少~~

（1）自己先講需求：先介紹業務——達到什么目標存在什么價值意義——實現的思路。

（2）給出1-2天時間，給開發自己去閱讀文檔自己理解，再指定開發反述。

（3）在測試發問，注意前端正常流程、異常流程怎么操作，后臺正常流程、異常流程處理的細小邏輯。

（4）注意事項：

• 確保會議時間充足：提1-2天發好通知，讓開發和測試安排好工作確保不缺席，時間點最好定在離吃飯時間間隔遠，反正我司程序猿吃飯是天大的事，不能耽誤一絲一毫。
• 會議中的疑問記錄好：由于對需求的理解不同崗位考慮的問題不同，在會議中會經常打斷你，會問實現的問題，也會問到你沒想到的異常場景，當你能馬上解答的你可解答一下，若無法現場及時給出答案的需要記錄下來會后再解答，不要耽誤會議時間。

3、需求場景遺漏

需求分析時會漏掉場景想不全，導致需求變更的時候愧疚和害怕，所以會考慮到開發的成本，不敢對需求大動干戈。而選擇折中。而這種折中會影響到用戶體驗。

答：

所以，我分析需求時，為了避免遺漏一些細節，邏輯不嚴謹。從以下幾個維度去思考：

（1）用戶是誰—解決什么難點—產生什么需求

（2）腦圖結構化，每個功能點，思考影響節點和分支場景。

（3）每個頁面從開始-發展-結束的情況（有無數據、正常異常情況），放空自己，把自己想象成用戶，實在做不到，可以找到對應的朋友看他們怎么操作，會有什么讓你想象不到的問題。

4、離用戶不夠近

需求做的沒底氣，做了一個地區去趕另一個場子，已做的地區后續需求不明確，也不知道自己做的需求到底能不能符合市場貼近用戶，這個是時間的問題，先統一做幾個地區，再做需求優化。

答：

（1）今年用戶現場去的太少，需求開干前就應該去收集需求。

（2）產品設計后，再去用戶現場驗證，種子用戶圈起來。

（3）產品上線后，持續維持和用戶的互動，收集用戶的意見，持續優化迭代產品。使用戶畫像清晰化，產品價值和產品定位明確化。

（4）競品分析，緊盯競品：2周瀏覽一下競品。1個月寫一下競品發展情況。

5、需求文檔能力待提升

需求文檔寫的不好。重慶第一個版本那樣寫太麻煩太啰嗦費時間 福州第二個版本又太簡單，需要尋找一個平衡點來寫文檔。打算山西的好好思考怎么寫的需求文檔易讀性更好，讓開發覺得我還可以再留到19年底再殺。大致羅列了一個大綱：

答：

（1）產品簡介：簡要的說明產品使用價值。

（2）版本管理：寫好版本時間，需求變更點，變更原因。

（3）功能模塊：

• 功能描述：寫好目標用戶和使用場景，在寫每個功能模塊的時候，簡要的暢敘一下，自己能夠試著去變成用戶，也讓開發測試有帶入感。
• 頁面原型：頁面狀態加圖示且說明。
• 操作流程：正常、異常流程說明、及主要業務流程圖。
• 業務規則：前置條件、加載機制、數據處理。
• 交互說明：正常交互、異常交互、頁面跳轉。
• 字段說明：字段、說明、數據來源。

6、需求驗證不到位

需求驗證，這點沒做好，開發完成后沒有去驗證是否符合需求。沒有很好的和開發團隊配合?，F在做的B端產品，測試環境準備相當復雜，自己也不會弄，每次環境配下來要花很多時間，所以每次就測試測完不管了。

答：

和測試團隊制定了新的計劃，需求單子增加一個要求：是否需要需求驗證。如果需要，在測試結單前，測試將產品需要驗證的點，把產品叫過來，演示一遍。

7、產品運營設計太薄弱

產品做了，價值點怎么傳遞給用戶，對于B端產品，專業性較強，不像C端用戶自己去探索發現，B端用戶只要能夠保證完成自己的工作，很難去改變工作習慣，也很難去主動挖掘潛在價值。如何很好的把價值傳遞顯性的給用戶，同時改變用戶的習慣。目前我做的產品是很欠缺的，這題太難了~超綱??！比五年高考三年模擬還可怕對于我來說~

答：今年好好總結思考，再整體總結出一篇文章。

8、文案功底欠缺

文案功底欠缺，由于之前文案自己寫了之后，都有專業的團隊人員負責修改優化，導致我對文案無法做到字字珠璣，從各個方面來看，文案真的太重要了~

答：

（1）一個功能頁面選取一個文案點，平時反復打磨，邀請同事探討，怎樣的文案達到最佳表達效果。

（2）多看書多學習，平時自己花時間和功夫利用其余時間累積?？梢栽谏钪卸嗳ニ伎?。

（3）每個月底的周六去看一些業內的分享講座并出自己的心得。

9、產品深度欠缺

缺乏行業大局觀。不知道行業發展趨勢未來在哪里，這樣也就無法把控產品的深度，和市場上哪些妖艷貨沒什么區別了~

答：

其實這個問題，作為一個入行不到5年的產品來說，是普遍的通病了，也是個大難題。這個沒有什么捷徑，除非你是才智過人天賦異稟，作為凡人的我，知道只有在這個行業沉淀下去，經歷得多了，思考得多了，慢慢積累，自然也會變成一個有高度有深度的產品人。

10、時間管理

公司大，事情多又雜，時間上管理不當，導致時間花了，不知道干了什么事。而且每天加班，每天忙到連自我提升的時間都沒了~

針對這種情況列了管理表，結果寫著寫著就遺忘了。我覺得管理表作用還是挺大的，對于自己的工作安排，時間節點都清晰明了，不會造成事情丟三落四，但是但是?。?！每次都沒有堅持下來。

答：

（1）一定要堅持列好管理表。將年度計劃、半年度計劃，細化到月度計劃、周計劃、天計劃。

（2）按照計劃事情一定要一件一件做。遇到計劃有變及時更新計劃表，制定新的計劃。

月度計劃、周計劃工作表

需求點清單表

自己每天工作計劃表

以上只是羅列了一些問題和如何解決問題的一些點，真正的要解決這些問題遠不止我回答的那么簡單，這些都是需要我們在平時的產品工作中慢慢積累，認真思考的。我們要學還很多，路很長~如：產品經理如何正確撕逼？

本文由 @李大發?原創發布于人人都是產品經理。未經許可，禁止轉載。

題圖來自StockSnap.io，基于 CC0 協議