大的互聯網公司，產品需求文檔的評審工作是怎麼進行的？

---

大的互聯網公司，很多都是周期版本化的上線節奏，這樣方便做需求的todolist管理，也能有效地控制資源。也有像去哪兒美團之類的加班到死的。

我就說說正規的節奏化的管理吧！

小的優化feature就無視了，只說需求。

1、業務需求確認

一般是業務給出了問題，產品就問題給出了解決方案，從而產生了第一稿的需求（或者自發挖掘的，反正你得跟用的人溝通），需求出來後，需要和業務（直接關聯人員）進行需求確認與溝通，這算是第一次review，你也可以理解成需求確認，確認你做的能解決問題。同時優先順序的確認，很多在這裡也得完成確認；

2、內部需求review

為什麼要做內部review呢？一個前台的網站pm變動的一個戰士邏輯，可能需要一個後台的B端PM給予支持，內部review就是為了保持需求的一致性。一個體量足夠大的公司，單一的一個人並沒有辦法覆蓋整個公司的架構，這個時候，規避掉需求中存在的溝通問題，一次內部review就能很好的降低後期的溝通、乃至上線後的回滾風險；

3、rd初步評估

主要不是針對某一個需求而言，更多是list。

研發會根據初步確認的需求list及資源情況，對需求/list做一個評估，比如你優先順序由上到下，列了十個，但是只有三個rd人員，一個開發周期（版本）內最多完成6個，那麼其他的怎麼辦？這次評審，就是為了告訴你，資源情況，和預估的情況，讓pm對自己的需求list有一個良好的量化管理；

4、需求宣講（rd、測試、業務、運營及其他相關人員）

這裡就是細節了，測試的介入就是為了把需求細化細化再細化，而pm需要完成需求的講解的同時，開始做項目經理的職責：項目管理。

這裡涉及到每一個里程碑/節點的確認，buff的把控，業務人員的協調，及上線後後續的跟進等。

如果你做的足夠專業的話，其實後續還會有一次分享，是在需求完成上線後的：一次數據的評估彙報。總結這個項目的成果、反思存在的問題、規劃後續的迭代方案等，至此一個需求也就算完了。

謝邀，隨便寫點意思一下。

---

推薦閱讀：