关于软件需求开发和项目的范围管理

从CMMI到CMM来看其变化
Req从只有一个PA叫RM，到两个PA，分别是Reqm、ReqD
目前我们的需求开发就如在一间黑屋子打着手电筒在看你需要装修的范围，你看到一个墙角墙上贴着白色的磁砖，铺着蓝色的地砖。你别以为客户的整个房子的需求就是白砖蓝地。那可只是个厕所。当你把全房子的灯都点亮，你再走一圈，你就会发出“原来如此”的感叹，其时需求的难度不是问题，问题就是当你所有的灯都亮了的时候，项目进入测试阶段的，这时候你发现返工很大，客户不满意，甚至对无关紧要的事情都在抱怨、恼火。
为什么灯不能在项目前期点亮？
这盏灯在我看来就是业务专家，对行业从广度到深度有切身体会的专家。当然对于一些小的项目不需要专家，项目经理应该要扛起责任来。
灯也不是说什么时候亮就什么时候亮的，足够的时间是必须的，为什么到了测试阶段才豁然开朗？大部分的项目经理连需求范围没有摸清就开始摸石头过河，我赞成对某些陌生业务的需求分析可以采用摸石头过河的策略，但是前提是要搞清楚需求的范围和方向。就像打帝国时代游戏一样，先造几个兵，然后一人一个方向出去探路，整个地图都是黑的情况下，可以造农民、士兵一些基本的准备工作。等地图一步步看清楚了，在决定策略，你靠海就多造船，你周边物产资源丰富就多造农民、仓库，物资多了就可以造更高级的武器了。如果你地理位置险固比较容易守，就尽快先升级。
兵法说要先谋而后定，需求开发不就是谋吗？