產品經理踩坑後的吐血總結
在專案中不止技術人員會踩到許多的坑，對產品經理來說也會踩到不少的坑。
就在這裡總結工作多年來所踩到的坑，給剛剛進入產品的新人一些經驗，可以少踩一些坑或者在踩中時如何去應對。
一、各種評審會議，該如何優化縮減會議時間？
當今網際網路都提倡著敏捷開發，減少過多的會議或開發流程，降低成本加快版本更新迭代，但很多時候一些必要的會議和流程我們還是要去走的，這樣才能在專案的各個階段更加清晰有據可依。
而我們都知道產品經理在專案之初到專案結束都需要開各種的會議，需求收集、產品內部評審、與UI和開發評審，到最後的產品上線宣導和專案覆盤。我們的工作很多時候都是在會議上度過的。所以如果在允許範圍內，我們可以與上級討論優化開發的流程，減少會議的次數，這樣就能減少佔用運營、UI和開發的工作時間。如果他們的工作時間被佔據了，那他們只能通過加班來完成手頭上的工作。所以在需求設計的時候要把問題想清楚，減少在會議上有較大的改動，避免修改後需要重新召開會議。
有時候可以把幾個會議合併成一個，但這一個適合一些小的功能或專案中，大家一起過一遍需求和功能。這時候就需要產品經理的一個控場能力，畢竟人越多問題也會越多，這時候會把會議的時間無限延長，所以最好在召開會議時制定好流程，控制好每個環節的時間，提前把會議安排發到每個參加會議的人手上，讓他們瞭解清楚，也可以把已經整理好的需求和設計原型先發出去給他們看，讓他們把問題記錄下來。在會議最後統一把問題丟擲來一起商量討論。有的時候會議上可能會討論到技術實現的問題，這時候產品需要控制好，把問題記錄下來，在會後再詳細討論，畢竟在會議上不止有技術人員，其他人會聽得糊里糊塗，所以原則就是不耽誤大家的時間，大家達成一致共識。
二、專案為什麼會延期，延期了怎麼辦？
眾所周知，在開發一開始就有各種未知的因素影響著整個開發過程，對於一個專案來說很難百分百預估不同階段的時間。而當我們的專案出現了延期，那該怎麼辦呢？
1、開發前評估時間沒有細化，需求理解錯誤
需求應該提前發出，給相關人員在技術評審前大致檢視接下來需要完成的功能，或者需要準備的技術。也可以前期與技術負責人進行溝通，分配了哪些人員參加到該專案中，提前與他們溝通了解實現的可能性。
那在會議前就能進行有效的分工，每個人著重檢視自己負責的部分，及時發現問題，提出難點，與產品經理進行溝通。會後，產品經理也可以找到對應的技術同學仔細講解需求，讓技術同學儘量理解透徹。這樣就能合理評估時間，不會只是一個粗略的時間。同時可以把一個大功能細化成一個個小的功能點，這樣可以讓我們很好的跟進進度，不只是一個大功能點的完成時間。
2、需求的改動
技術大大們敲程式碼的時候都喜歡沉浸式，中間被打斷不僅影響心情影響更會影響效率。因此臨時提出的需求應該統一提到產品經理這裡，然後統一安排。不是重大問題、線上bug、節日營銷等，都另行排期版本。插入該版本的需求也得開會評審，做好記錄。根據優先順序是否安排在這一次版本上。如果是設計方案產品經理沒有考慮清楚或功能的改動，這時候就要及時更新文件並且與技術說明情況，自認錯誤，讓技術按照新的方案進行開發。
========================================華麗的分割線========================================
剩餘50%的內容通過訂閱以下專欄閱讀文章完整版，並且能夠及時獲取最新產品資訊。