如何做好需求評(píng)審？

需求評(píng)審之殤

需求評(píng)審這件事，在軟件項(xiàng)目管理的流程上，一直是淪為一個(gè)多余的存在，不少企業(yè)面對(duì)這個(gè)事情，從來(lái)都是得過(guò)且過(guò)。也許是由于技術(shù)人員不足，從產(chǎn)品到設(shè)計(jì)到開發(fā)到測(cè)試，一人包辦，自然覺(jué)得需求評(píng)審沒(méi)有必要；也許是需求主管部門過(guò)于強(qiáng)勢(shì)，搞一言堂，需求草稿即定稿。再有就是，正在各種混亂流程交錯(cuò)中掙扎的成長(zhǎng)型公司，正在歷經(jīng)規(guī)范化的痛，對(duì)于這個(gè)事情正在搖擺。

之所以需求評(píng)審會(huì)淪為眾矢之的，就是因?yàn)樗粌H會(huì)帶來(lái)工作量的增加，瑣事的增多，更重要的是，他需要一個(gè)背鍋的人。軟件需求的準(zhǔn)確性和合理性直接關(guān)系到開發(fā)人員的工作效率和項(xiàng)目工期，而需求評(píng)審本身就是對(duì)需求的再審核，直接決定需求的質(zhì)量，如此重要的責(zé)任做的好自然是功勞，做不好導(dǎo)致項(xiàng)目返工、開發(fā)人員怨聲戴道，那就是罪人一個(gè)。因此，沒(méi)有多少人愿意主動(dòng)背起這個(gè)鍋。

各顯神通

翻開軟件工程和項(xiàng)目管理的教科書，我們會(huì)發(fā)現(xiàn)，理論很精妙。但是一旦付諸于實(shí)踐，很快就會(huì)發(fā)現(xiàn)，情況并不是想象中的那么理想。但理論是方法指導(dǎo)，只是一個(gè)體系框架，實(shí)際的應(yīng)用還需要結(jié)合每個(gè)公司不同的工作流程，各自發(fā)揮。這里就需求評(píng)審這個(gè)環(huán)節(jié)，筆者談?wù)勛陨淼慕?jīng)驗(yàn)。
其實(shí)，要讓需求評(píng)審不淪為形式主義、眾矢之的，可以參考以下的流程方法進(jìn)行，多裁少補(bǔ)。

1、事先界定需求評(píng)審的范圍

在開始需求評(píng)審會(huì)之前，需要事先定好需求評(píng)審的內(nèi)容，界定好本次討論的需求邊界，防止開會(huì)時(shí)由于思維過(guò)于發(fā)散，偏離主題導(dǎo)致討論內(nèi)容無(wú)限制擴(kuò)大，影響評(píng)審目標(biāo)的完成。我們的目標(biāo)很明確，本次討論解決什么問(wèn)題就是什么問(wèn)題，在過(guò)程中發(fā)散出來(lái)的，適當(dāng)做個(gè)記錄，應(yīng)該立即回到主題上。

2、會(huì)議前確定好參會(huì)人員。

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

3、控制會(huì)議時(shí)間

確定會(huì)議時(shí)間、會(huì)議時(shí)長(zhǎng)，提前明確預(yù)計(jì)會(huì)議預(yù)計(jì)多長(zhǎng)時(shí)間，并提前通知大家，讓大家心里有個(gè)數(shù)，方便各自安排手上的工作，如果預(yù)計(jì)的時(shí)間內(nèi)，沒(méi)有將內(nèi)容討論完，那么也應(yīng)該適時(shí)終止會(huì)議，另外選擇時(shí)間繼續(xù)討論，切忌長(zhǎng)時(shí)間作戰(zhàn)。長(zhǎng)時(shí)間作戰(zhàn)到最后只會(huì)讓很多內(nèi)容都草草了之。

4、參會(huì)人員提前預(yù)習(xí)會(huì)議內(nèi)容

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

5、會(huì)前需求確定好需求的決策人

一定要讓其參與會(huì)議，當(dāng)討論過(guò)程不同意見僵持不下的時(shí)候，需要需求決策人來(lái)排版。這點(diǎn)很重要！

6、會(huì)前確定好會(huì)議記錄人。

需求文檔更新負(fù)責(zé)人，讓其認(rèn)真參與，記錄好討論過(guò)程。會(huì)后需要公布會(huì)議紀(jì)要，其實(shí)也就是需求評(píng)審記錄，并納入文檔庫(kù)。

7、明確下次復(fù)審會(huì)議時(shí)間

會(huì)議討論結(jié)束后，需要明確時(shí)間下次復(fù)審是什么時(shí)間，有效率地推進(jìn)工作進(jìn)展。![在這里插

剩余的廢話

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

后記

很多軟件開發(fā)公司需求可能都是老板或者項(xiàng)目經(jīng)理甚至是開發(fā)人員一個(gè)人說(shuō)了算，那么需求評(píng)審做的如何這取決于公司相關(guān)負(fù)責(zé)人的經(jīng)驗(yàn)和專業(yè)能力。