需求評審會如何作纔不會淪爲形式主義

需求評審之殤

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

之因此需求評審會淪爲衆矢之的，就是由於他不只會帶來工做量的增長，雜事的增多，更重要的是，他須要一個背鍋的人。軟件需求的準確性和合理性直接關係到開發人員的工做效率和項目工期，而需求評審自己就是對需求的再審覈，直接決定需求的質量，如此重要的責任作的好天然是功勞，作很差致使項目返工、開發人員怨聲戴道，那就是罪人一個。所以，沒有多少人願意主動背起這個鍋。

各顯神通

翻開軟件工程和項目管理的教科書，咱們會發現，理論很精妙。可是一旦付諸於實踐，很快就會發現，狀況並非想象中的那麼理想。但理論是方法指導，只是一個體系框架，實際的應用還須要結合每一個公司不一樣的工做流程，各自發揮。這裏就需求評審這個環節，筆者談談自身的經驗。
其實，要讓需求評審不淪爲形式主義、衆矢之的，能夠參考如下的流程方法進行，多裁少補。

一、事先界定需求評審的範圍

在開始需求評審會以前，須要事先定好需求評審的內容，界定好本次討論的需求邊界，防止開會時因爲思惟過於發散，偏離主題致使討論內容無限制擴大，影響評審目標的完成。咱們的目標很明確，本次討論解決什麼問題就是什麼問題，在過程當中發散出來的，適當作個記錄，應該當即回到主題上。

二、會議前肯定好參會人員。

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

三、控制會議時間

肯定會議時間、會議時長，提早明確預計會議預計多長時間，並提早通知你們，讓你們內心有個數，方便各自安排手上的工做，若是預計的時間內，沒有將內容討論完，那麼也應該適時終止會議，另外選擇時間繼續討論，切忌長時間做戰。長時間做戰到最後只會讓不少內容都草草了之。

四、參會人員提早預習會議內容

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

五、會前需求肯定好需求的決策人

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

六、會前肯定好會議記錄人。

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

七、明確下次複審會議時間

會議討論結束後，須要明確時間下次複審是什麼時間，有效率地推動工做進展。![在這裏插

剩餘的廢話

其實，需求評審的流程真正用心落實，不會多花太多時間，反而對於軟件項目的質量、效率的提高有着很是重要的做用，上面說到的並非教科書上的內容，而是筆者實際工做中的心得體會。要想成爲一棵大樹，必需要知道大樹的成長曆程，一枝一葉的生長，並非需求評審的流程多餘，而主要是你們習慣的現有的流程，不肯意進行改變。

後記

不少軟件開發公司需求可能都是老闆或者項目經理甚至是開發人員一我的說了算，那麼需求評審作的如何這取決於公司相關負責人的經驗和專業能力。