眾所周之，產品的缺陷發現得越早代價越小，十乘十乘十法則說的就是這個道理：需求階段的缺陷遺留到設計和開發階段，其代價會增加十倍；如果遺留到測試階段，其代價會增加百倍；如果遺留到客戶那里，則代價會增加千倍。因此，產品研發過程中，人們都盡可能地在早期把缺陷發現了。

產品測試是發現缺陷的重要手段，然而，只有當產品構建出來，才可能執行產品測試活動。產品研發的前期如需求、設計階段如何發現問題呢？其實，廣義的測試包括靜態測試和動態測試，我們通常所說的測試是指動態測試，即產品構建后讓其運行起來從而發現產品缺陷的過程。靜態測試又被稱為交付件評審，在產品交付件不運行的情況下通過查找的方式發現產品缺陷。技術文檔、圖紙等研發項目交付件因為無法運行，只能通過評審來發現問題，往往這些技術文檔、圖紙又是項目前期產生的，其中的缺陷如果沒有被及時發現，流入了下一階段，不僅會帶來數十倍、百倍的返工成本，還可能嚴重影響項目工期和團隊士氣，因此有效的交付件評審對產品研發的成功至關重要。十多年前，華為引入IPD、CMM方法論和模型進行研發過程變革，被大家最先廣為認可的一項變革領域就是交付件評審，所以當時在華為有一句話深入人心：凡事必review。評審如同洗臉刷牙一樣，成為了華為研發人員的習慣，甚至軟件代碼寫完了，可以運行了，都不允許立刻測試，只有經過了有效的評審才能測試，因為聰明的華為人發現，通過評審發現缺陷遠比測試效率更高、效果更好。

然而，作為漢捷咨詢顧問，接觸眾多的國內研發企業，發現能夠有效開展交付件評審的企業真是少之又少，一項簡單而非常有效的活動居然沒有普及真是非常遺憾，難怪大家都去買日貨！下面一個交付件評審場景是否也在您的企業里發生？

產品需求分析人員在周五上午完成了需求文檔，并匯報給項目經理，項目經理要求下午先組織一次內部的需求評審（客戶不參與），要求所有的開發人員和測試人員都參加，項目組之外的幾位技術專家也要盡可能邀請。

下午的評審會上，項目經理和十名項目成員都到了，但項目之外的專家只來了一位，而且評審中途又被電話叫走。需求分析人員用投影儀把需求文檔顯示在會議室的屏幕上，然后從頭到尾開始講解需求文檔，過程中有人對需求不理解或者有質疑，需求分析人員會停下來解答、討論，如果確認是需求文檔的問題，則由需求分析人員會做一個簡單的問題記錄，以備下來修改。評審過程中，發現7、8處錯別字，有3個需求點，需求分析人員也沒有搞清楚，經過會議上的討論，基本搞清楚了。該會議一共持續了3個小時，一共發現10個非錯別字類需求問題，其中有7個問題是由項目經理提出的。

評審會結束后，需求分析人員根據評審會所發現的問題對需求文檔進行修改，然后發給項目經理，項目經理進行簡單的復查后發給客戶，準備進行需求外部評審。

很多企業的交付件評審狀態與上述案例所描述的非常類似，以至于有時為企業做培訓時使用此案例，有學員會驚訝的說：“老師，你怎么用我們公司的案例！”這樣的評審實在低效，耗費了大量工時，而收效（發現的技術問題）并不大。因此，大部分企業的研發項目并不歡迎交付評審活動，他們通常以項目進度急迫為由，根本不組織交付件評審，即使組織了評審也就類似上面案例所描述的那樣，耗費了大量了人力，發現的有效問題并不多。這樣的評審方式，也驗證大家普遍存在的“評審效率不高”這樣的信念，如此便陷入惡性循環，下次的評審更加難以組織。

真的是評審活動本身效率低嗎？顯然不是，既然交付件評審能夠在優秀的企業里被制度化，就很可能說明交付件評審是個“好活動”，只是我們沒有把它執行好。那么問題到底出在哪兒呢？顯然案例中的評審過程存在很多問題，比如，文檔并沒有提交發出來，給各個評審專家預留充分的時間會前閱讀資料；作者沒有做好自檢，甚至明知有些地方沒有搞清楚，把問題帶到了評審會議上浪費了大家的時間；作者修改后的文檔也沒有發給各位評審專家做確認，有可能問題漏改或改錯......那么正確的交付件評審過程是什么？請關注下期。