關於需求評審，網易團隊是這麼「玩轉」的

09-10

關於需求評審，網易團隊是這麼「玩轉」的

4 人贊了文章

作者：網易杭研項目管理/何燕華（本篇文章僅限知乎內部分享，如需轉載，請取得作者同意授權。）

原本覺得需求評審也就那麼回事兒，大家應該都差不多這麼做的，沒啥好說的。不過，前不久有一位同學問起來我們是怎麼做需求評審的，然後發現有一些團隊的做法可能還不大一樣，他們也還踩著我們之前踩過的坑，他們還在探索更好的方式，於是決定將我們的「玩法」寫下來，也許能給困境中的小夥伴一些啟發。

首先，我這裡提到的需求包含了：需求，交互，視覺。

當然，在調整到當前狀態之前我們的需求評審也存在很多問題，之前我們也有探討過需求管理的方法。所以，我這次先來介紹一下比較原始的需求評審的方式以及存在的問題。

以前我們的做法是：

以上這樣的狀態，給我們帶來了幾個困擾：

首先是所有需求都會進入交互設計和視覺設計階段，但是最終有可能因為開發評估之後做不完而被擱置，形成了設計資源的浪費
交互評審全員參與，由於人數眾多，而且分工還未確認，開發並不知道自己負責哪部分，所以參與度很低，一般就是交互在講，開發就在下面聽，也不一定能提出問題，到了後半程，有些同學就開始玩手機，效率很低
視覺評審的缺失，視覺評審由於沒有約定明確的評審流程，所以有一些視覺沒有經過評審就進入了開發階段，直至需求走查的時候才發現有問題

基於以上問題，我們逐步對相關的評審機製做了一些調整，調整後的情況如下：

需求評審

參與人員：策劃，交互，視覺，開發，測試，運營等角色負責人

評審目標：評審需求的優先順序和價值，以及初步判斷可實現性

評審形式：集中會議。需求評審完成後的一天內，開發對需求的大小進行初步評估。從估算和計劃的角度來看，可以認為這是在需求細節還沒那麼明確的情況下的評估，有可能存在50%±的偏差，但是他能將多餘50%之外的需求砍掉，不必再進入交互階段。

調整思路：主要增加了開發的初步評估，將大大超出團隊容量的需求提前砍掉，減少了交互的工作量，使得交互稿可以提前交付，同時也避免了不必要的交互浪費，因為當前版本未能開發的功能，在下一個版本可能優先順序就又不一樣了，或者早已不符合市場需求了。

參與人員：團隊核心成員（交互評審），相關功能的各角色成員（交互說明）

評審目標：評審交互的合理性，以及交互的可行性評估

評審形式：分為交互評審和交互說明。

整體交互稿的交互評審，在交互評審後一天內，參與評審的核心開發針對交互做一個基本的評估。反饋：哪些需求肯定做不完，這些需求就不需要全部進入視覺設計了。

在交互和視覺稿基本確認之後，在當前迭代的後期，再分批跟相關功能的開發和測試進行交互說明。此時，開發的基本分工已經確認，大家會更細緻來聽，並且能夠提出比較細節的問題，當然此時交互稿需要修改的問題會比較少，基本不影響整體的安排。

調整思路：

與需求評審一樣，交互評審之後，基本上就能確認工作量，但是只需要核心的開發在交互評審之後的一天內大致評估工作量，定義是否有一些需求已無需進入視覺階段，減少了浪費。
縮小參與交互評審的人員範圍，讓在場的人能夠充分參與；節約未來參加評審的同學的時間。
縮小參與交互評審人員的範圍，可能犧牲了一部分其他人的意見，為了補充這部分人的意見，所以在新迭代即將開始的時候再組織一次交互說明，不僅引入了這部分人的意見，同時也可以將交互做更細緻的溝通。
最後的交互說明，不需要所有人同時過來，而是分批進行說明，這樣既能讓具體的執行人員能夠了解交互細節，又不會浪費大家時間。

參與人員：相應的策劃，交互，視覺，以及視覺負責人

評審目標：評審視覺稿是否滿足需求，以及從策劃和交互的角度提出建議

評審形式：當面溝通。視覺設計師會將設計稿郵件發給相應的策劃交互，抄送開發，並且邀請策劃和交互當面溝通意見。

調整思路：

視覺稿沒有評審，經常出現在後期策劃交互走查時發現問題。但是視覺稿的評審又不適合做的太重，本身視覺設計是一種無法明確定義好壞的問題，不是越多人參與就越好，所以只定義策劃和交互參與，開發只需看實現上是否有困難即可（一般比較少）。
形式必須定義清楚，否則就會容易執行不到位。

當然，調整之後的模型也有一些限制條件：

交互評審的時候，能夠找得到所謂的「核心開發」，他要對產品整體的業務邏輯都非常清晰，能夠評估新提出的需求大致的工作量。如果團隊中的開發都是獨立負責一塊，項目之間都不了解情況的，那就比較難採用這種方式。
這樣的視覺評審形式其實也是比較依賴大家的主動性。否則就需要一個人，如視覺負責人來監督，是否所有視覺稿都經過評審。

喜歡我們的文章也歡迎看看我們的書《網易一千零一夜》，並關注公眾號：NetEasePM

作者：何燕華，網易資深項目經理，PMP，CSM。先後在網易私有雲、網易用戶中心、網易GACHA、網易LOFTER等項目擔任項目管理工作，積累了豐富的項目管理實踐經驗，並始終致力於項目的成功交付和團隊的健康發展。《網易一千零一夜》主要作者之一。