起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識讓工程評審會更高效，你需要這么做
作為智力輸出崗位的產研團隊，不能總想著適應環境，而是應該想著如何改善環境。如果你也覺得自家的工程評審會有點“又臭又長”，看完這篇文章后，你或許會找到解決辦法。
那是一個再普通不過的工作日，在昏暗的會議室里，投影放著我們再熟悉不過的PRD。有些刺眼，不過十幾個小伙伴還是“認真地”聽著兩位前后端的主程（主要負責開發的程序員）為了一個細節具體實現爭論不休，一場由PM發起的工程評審會就這樣”自然而然地“江山易主了。
原計劃一小時的會，就這樣……
顯然，這種溝通效率是不能夠接受的。
那么怎樣的工程評審會是比較理想的呢？
還是得先回到我們開始的地方，問問自己：
一、為什么要開工程評審會
我認為只有兩個目的：
1.? 盡快啟動工程開發
從契約精神的角度上來講，會議具有天然的儀式感，是與會人員簽訂的一份虛擬協議，會議結束后雙方就應該履行各自的義務。為此，越早的啟動會議，越會提前上線日期。
?2.? 提高工程開發效率
互聯網公司最大的成本就是溝通成本，這在單人凈值都非常高的產研團隊尤為突出。如果不能充分發揮其杠桿效應，無疑將對公司的現金流造成沉重的負擔。
會議是解決溝通效率的一種有效手段，為此避免開發過程中的額外溝通成本，也是工程評審會的主要目標之一。
二、如何開工程評審會
建議如下：?
1.? 會前
- 會議邀請主程必須參加
- 盡量提前一天周知會議相關方案文檔，推薦發送會議邀請的時候附上文檔地址。
2. 會中
- ?講清楚當前工程對公司業務的量化價值和戰略意義(充分調動RD的主動性)
- ?講清楚PRD每一處細節，同時要不斷地提醒，丑化說在前頭，有問題不清楚的隨時說，會議結束后就不再做任何修改了（除了有爭議的部分）。
- ?仔細收集RD反饋的工程問題（注意：不是業務問題）
3. 會后
- 跟與會人員再次確認是否還有補充，提示會后就要先開發達成一致的部分。
- 有分歧的部分會單獨和主程及相關人員小范圍的開會確認，會盡快確認并周知。
我認為任何這個議程之外的事情都是在浪費時間，是一種低效的表現。??
三、你可能不太認同的幾個點
有的人會說，不對??！工程能否實現也很重要，應該放到會議上討論啊。??沒人說不重要，我說的是不應該在這個會議上討論。?
工程能否實現的問題，在PRD設計階段就應該和主程溝通清楚了（出門左轉見《寫給程序猿的一封情書-PRD》）。
也有的人會說，工期和排期也應該在會上討論出個大概。這個說明要么你遇到的都是很NB的工程團隊，要么就是你被工程團隊坑的次數太少。
一般來說，工期和排期要給研發團隊一些時間（我一般會給一個工作日），這個時間是不能省的，要知道給了時間承諾的工期和沒給時間拍腦袋給的，在工程團隊中的影響力差別還是很大的。
當然更會有人會說，在所有可能的方案中，當前方案是否為最優解，其實也有必要討論一下。
這種討論我是強烈反對在工程評審會上討論的——除非PM并沒有在撰寫方案前主動與主動溝通達成一致意見，否則就是典型的沒有尊重過程的意識和素養。
除此之外，達成目標最重要的兩個因素就是：正確的方向和強大的執行力。
在團隊內部大家有明確的分工，產品對需求的方向和價值負責，研發對工程的質量負責；如果部門之間都互相遇阻代庖的指責對方的不正確性，誰又來保證自己模塊的正確性，又談何具有強大的執行力?
所以綜上兩點，我認為即使在工程評審會上對方案是否最優有質疑，也不應該在會上提出（那就不是那個階段該干的事兒！），必要的情況下可私下反饋。
當然如果真出現這種情況，產品leader應該警惕，考慮現有的產品內審機制是否存在放水現象。理論上來講，PM做方案的時候各種可能性都應該考慮到了。
四、感謝有人“砸場子”
被人“砸場子”（僅指針對方案內容提出的質疑，而不是針對會議流程），當面挑戰你的方案！
這時候該怎么辦？
你應該心懷感激的找時間請他吃飯。
說真的，能提出問題，哪怕是挑戰類的問題，說明他認真看過你的文檔思考過了。另外從某種角度來講，問題在開發前暴露遠好過上線后暴露。
其實最可怕的是：開會的時候什么問題都沒有，會議結束后又各種問題不斷涌現，反反復復的修改、同步，最終嚴重影響了工程的進度。
這里要稍微多說一句：遇到挑戰的時候，能三言兩語解釋清楚的更好；說不清楚的，記下來承諾個時間點會后一般人也都可以理解，甚至是認同（對于提問者本身來說，問題被認真對待是一種被尊重的表現）。
作為智力輸出崗位的產研團隊，還是要有一定的進取心的，不能總想著適應環境，而是應該想著如何改善環境。
如果你也覺得自家的工程評審會有點”又臭又長“，那就趕緊做點什么吧！就像張伯倫說的那樣——“不要因為走得太遠，忘記了我們為什么出發”。
本文由 @吳天 原創發布于人人都是產品經理。未經許可，禁止轉載
題圖來自Unsplash，基于CC0協議
可以看出是實踐總結出的經驗 很有幫助
作者：吳天，微信公眾號：【竹林雜記 】，歡迎關注～