如何做好需求評審？

需求評審之殤

需求評審這件事，在軟件項目管理的流程上，一直是淪為一個多余的存在，不少企業面對這個事情，從來都是得過且過。也許是由于技術人員不足，從產品到設計到開發到測試，一人包辦，自然覺得需求評審沒有必要；也許是需求主管部門過于強勢，搞一言堂，需求草稿即定稿。再有就是，正在各種混亂流程交錯中掙扎的成長型公司，正在歷經規范化的痛，對于這個事情正在搖擺。

之所以需求評審會淪為眾矢之的，就是因為他不僅會帶來工作量的增加，瑣事的增多，更重要的是，他需要一個背鍋的人。軟件需求的準確性和合理性直接關系到開發人員的工作效率和項目工期，而需求評審本身就是對需求的再審核，直接決定需求的質量，如此重要的責任做的好自然是功勞，做不好導致項目返工、開發人員怨聲戴道，那就是罪人一個。因此，沒有多少人愿意主動背起這個鍋。

各顯神通

翻開軟件工程和項目管理的教科書，我們會發現，理論很精妙。但是一旦付諸于實踐，很快就會發現，情況并不是想象中的那么理想。但理論是方法指導，只是一個體系框架，實際的應用還需要結合每個公司不同的工作流程，各自發揮。這里就需求評審這個環節，筆者談談自身的經驗。
其實，要讓需求評審不淪為形式主義、眾矢之的，可以參考以下的流程方法進行，多裁少補。

1、事先界定需求評審的范圍

在開始需求評審會之前，需要事先定好需求評審的內容，界定好本次討論的需求邊界，防止開會時由于思維過于發散，偏離主題導致討論內容無限制擴大，影響評審目標的完成。我們的目標很明確，本次討論解決什么問題就是什么問題，在過程中發散出來的，適當做個記錄，應該立即回到主題上。

2、會議前確定好參會人員。

參會人員分兩類，一類是必須參加的人，一類是選擇性參加的人。必須參加的人包括：需求評審會主講人和項目直接相關的人員。一般情況下，參加需求評審會的項目直接相關人必須是多角色的，因為無論多牛逼的人，也無法做到全才、想法360度全方位無死角，這就需要包括：需求人員、交互設計師、UI設計師、架構師、后端開發人員、前端開發人員、測試人員。這些項目直接相關人，也是工作任務上跟需求緊密相關的人，他們的評審意見至關重要。小公司可能“架構師、后端開發人員、前端開發人員”是同一組人甚至是同一個人也有可能。安排不同角色參與評審，就是需要這個人或者這些人從不同角度評估需求的合理性和開發的代價，從不同角度考慮需求可能存在的問題和需要改進的地方，盡最大程度在前期發現需求本身的問題，防止需求發生過大的偏差。

3、控制會議時間

確定會議時間、會議時長，提前明確預計會議預計多長時間，并提前通知大家，讓大家心里有個數，方便各自安排手上的工作，如果預計的時間內，沒有將內容討論完，那么也應該適時終止會議，另外選擇時間繼續討論，切忌長時間作戰。長時間作戰到最后只會讓很多內容都草草了之。

4、參會人員提前預習會議內容

提前一小時（半小時太短了）分發討論內容稿給參會人員，讓參會人員提前閱讀并組織內容意見，到會議上直接拋出各自的意見，提高會議效率。

5、會前需求確定好需求的決策人

一定要讓其參與會議，當討論過程不同意見僵持不下的時候，需要需求決策人來排版。這點很重要！

6、會前確定好會議記錄人。

需求文檔更新負責人，讓其認真參與，記錄好討論過程。會后需要公布會議紀要，其實也就是需求評審記錄，并納入文檔庫。

7、明確下次復審會議時間

會議討論結束后，需要明確時間下次復審是什么時間，有效率地推進工作進展。![在這里插

剩余的廢話

其實，需求評審的流程真正用心落實，不會多花太多時間，反而對于軟件項目的質量、效率的提升有著非常重要的作用，上面說到的并不是教科書上的內容，而是筆者實際工作中的心得體會。要想成為一棵大樹，必須要知道大樹的成長歷程，一枝一葉的生長，并不是需求評審的流程多余，而主要是大家習慣的現有的流程，不愿意進行改變。

后記

很多軟件開發公司需求可能都是老板或者項目經理甚至是開發人員一個人說了算，那么需求評審做的如何這取決于公司相關負責人的經驗和專業能力。