一、概述
產品經理在開需求評審的時候，如果prd考慮不全面，經常會被研發人員挑戰，如果確實考慮欠周全，就需要改動prd，這個的代價是很大的。一般來說，prd定了就是定了，只能接受非常小的改動。需求評審被及時發現了，調整還算來得及，如果是到開發階段或者測試階段了才被發現，那就是資源的極度浪費，會降低整個團隊的產出。
而正式做需求評審的時候，研發和測試人員就再次核對一下，這個需求評審會中的prd跟之前討論的東西是否一致就行了。
其實產品和研發要配合好，不只是在需求評審這塊，還有很多的地方需要做好配合的，下面簡單闡述一下。
二、研發人員接需求入口要統一
一般來說，公司的組織架構是有職能劃分的，例如中後台的產品負責中後台的需求規劃和管理，對應的中後台研發人員大部分情況下只負責實現【中後台這條線】的需求。研發人員接需求的入口，要保證只有乙個：
那就是對應的業務線的產品經理。比如說，中後台研發人員只從中後台的產品經理接需求。
下面的這種情況一定要杜絕：
其他業務線的產品經理（例如會員線）或者運營人員或者開發人員越過中後台的產品經理直接找到對應的中後台開發談【業務】需求。
本業務線內的研發人員到底在正在做什麼或者將來會做什麼，對應的業務線的產品經理一定要瞭如指掌，方便統一統籌，有利於保持節奏和保證研發人人員足夠專注，進而達到高效產出。試想一下，如果研發人員隨意答應了做某個需求，而產品經理不知道，勢必會影響到本業務線內的需求開發，進而影響到整條業務線的產出。
因此本業務線內的產品和研發在【接需求】這塊一定要【配合】好，對外就是乙個整體，整體的去作業，這樣才能有高效的產出。
三、【為什麼/做什麼】、【做什麼/怎麼做】
產品經理在做需求收集和整理後，會產生乙份prd，因此產品經理肯定是跟業務方對接完了，清楚的知道【為什麼】要做這個東西，而隨之產生prd則是表示要【做什麼】，需求評審的的過程，其實就是將【做什麼】傳達給開發人員，這個是兩個角色之間的【交集】，但是這樣做是不夠的，做的更好的方式是：
產品經理將【為什麼】清楚的告知給開發人員，而開發人員清楚的將【怎麼做】告知產品經理，大家相互體諒，以求理解一致。
產品經理需要告知這個需求的【來龍去脈】是什麼，是解決什麼痛點，你當前有什麼資料可以說明，或者說這個需求是為了哪個指標？使用者增長、提高效率、gmv，還是使用者體驗等，要達到什麼樣的目標，如何用資料證明目標是否達成了。另外一定要將需求的【源頭資訊】準確的說出來，而不是說，產品經理出的需求其實跟需求源頭要做的東西，其實不一致。
產品經理一定要非常清楚，一旦需求啟動，那可是【一大波人】在幹活，會有很多資源投入進去，如果連為什麼以及做完後如何證明有效果都不清楚的話，是很難做到高效執行的，同時也沒什麼成就感。
而開發人員，接到需求後，也需要把技術成本告知給產品經理，例如說：
1、關鍵路徑裡好多還是php的，得做重構； 2、有很多歷史資料需要遷移； 3、原本的系統架構不太好做這個事情； 4、上線風險高，得開發灰度程度； 5、原本的介面，效能不行，也得做優化； 6、這塊得做全量回歸測試；
把這些實際情況告知產品經理，共同商量一下方案。
四、產品往後延伸，研發往前延伸
【研發往前延伸】，意思就是說，研發需要參與到【需求收集】這個比較【靠前】的階段裡，無須等到需求很正式了，才去了解。像很多公司會開【業務方、產品經理、研發每月溝通】的會議，其實也是這個目的。盡量靠前的話，研發能提前有所準備和規劃，同時也能真正的理解產品經理和業務方的壓力，另外呢，研發也不會有【需求從天而降】的感覺，好像被突然襲擊了一樣。
【產品往後延伸】，意思是說，不要prd一出完了，就不管了，產品經理一定要有乙個意識：
prd是你出的，這個產品整個過程到底順不順，跑的穩不穩定，是你一定要去關心的，【你就是不想這個產品出問題】，必須得有這個心態。
像產品上線後出了bug了，有大故障了，產品經理一定要參與進去，盡量想辦法一同解決，而不是只是問：什麼時候修復好之類的，是哪個開發導致的呀。
這兩個延伸都做好了，也會逐漸增加產品和研發這兩個角色之間的信任，從而達到更加高效運轉。
五、文化：只有我們，沒有他們
本業務線內的，不管發生的事情是好事還是壞事，就是【我們】，我們做對了，我們做錯了。做對了，有產出有業績了，就是整條線做得好。做錯了，就是整條線做的不好，那麼就一起背鍋，關起門來一起檢討。
六、小結
產品和研發本質上就是需要【配合】好的，因為這兩個角色對公司來說，實在太關鍵了，一旦有出現不和諧的地方，影響面都是很大的。
如何做好團隊培訓
培訓是讓團隊提公升和發展的重要手段，那在你的團隊裡面，是怎麼做培訓的？課件如何設計？培訓效果知道嗎？我們可以通過一套教學發展的體系去回答這些問題，這套體系叫 eddit，是美國培訓與發展委員會 astd 支撐的一套教學體系。addie 模型 主要包括五階段階段的工作 分析 階段的工作 學習者分析 教...
如何做好團隊技術分享
最近一段時間一直在思考如何將技術分享和內部培訓利用起來，幫忙團隊小夥伴們盡快提公升工作中需要的技術。突然想到其實一次精心準備的技術分享，也算是乙個小小的專案了。作為乙個專案，當然也要經過啟動 計畫 執行 監控和收尾的過程，只不過在這五大過程組之中，根據實際需要具體過程會有所刪減。想要中獎，至少要先買...
管理者如何做好團隊規劃
之前看過一篇文章，講述的是孫正義如何設定目標及如何達成目標，具體的原話忘了，大概的思路是 先設想自己10年後想達成的狀態和目標，之後再分析要達到這個目標，在第8年的時候需要哪些資源，需要達成怎樣的狀態，之後不斷倒推，直到當前 當然，這麼牛叉的目標設定方法，不是每個人都能掌控的。以前也曾經聽乙個goo...