關于軟體需求開發和項目的範圍管理

從CMMI到CMM來看其變化

Req從隻有一個PA叫RM，到兩個PA，分别是Reqm、ReqD

目前我們的需求開發就如在一間黑屋子打着手電筒在看你需要裝修的範圍，你看到一個牆角牆上貼着白色的磁磚，鋪着藍色的地磚。你别以為客戶的整個房子的需求就是白磚藍地。那可隻是個廁所。當你把全房子的燈都點亮，你再走一圈，你就會發出“原來如此”的感歎，其時需求的難度不是問題，問題就是當你所有的燈都亮了的時候，項目進入測試階段的，這時候你發現返工很大，客戶不滿意，甚至對無關緊要的事情都在抱怨、惱火。

為什麼燈不能在項目前期點亮？

這盞燈在我看來就是業務專家，對行業從廣度到深度有切身體會的專家。當然對于一些小的項目不需要專家，項目經理應該要扛起責任來。

燈也不是說什麼時候亮就什麼時候亮的，足夠的時間是必須的，為什麼到了測試階段才豁然開朗？大部分的項目經理連需求範圍沒有摸清就開始摸石頭過河，我贊成對某些陌生業務的需求分析可以采用摸石頭過河的政策，但是前提是要搞清楚需求的範圍和方向。就像打帝國時代遊戲一樣，先造幾個兵，然後一人一個方向出去探路，整個地圖都是黑的情況下，可以造農民、士兵一些基本的準備工作。等地圖一步步看清楚了，在決定政策，你靠海就多造船，你周邊物産資源豐富就多造農民、倉庫，物資多了就可以造更進階的武器了。如果你地理位置險固比較容易守，就盡快先更新。

兵法說要先謀而後定，需求開發不就是謀嗎？