今天想和大家说的，其实无非是和我们如影随形的需求边变更。似乎自我入行一来一直听到这个词语。先说何为需求?我按照广义和狭义简单的区分了下。

　　所谓广义需求，及时一切和项目有关的想法，建议反馈，都叫做需求。所以狭义，就是产品经理提出的需求文档。其实一定时期内，我们不得不承认，广义需求是相对稳定的，并且有一定的经验可谈。何意?广义需求可以是用户的一个反馈，可以是今年流行的一种设计风格，可以是近几年流行的聚焦区域。再具体点说，就是，用户可以希望音乐播放软件提供高品质，免费，且海量的搜索结果，这个要求可能是几年不变。或者，近几年流行扁平设计风格，再或者这几年移动支付比较火热。这些都是需求，这些需求有共同特点就是相对稳定。

　　与之相较，所谓狭义需求，就是产品经理提出的需求，很可能朝令夕改，很可能半途而废，很可能浅尝辄止。比如做一个按钮，可能今天要求放在屏幕中间，明天要求放在底部。再比如今天设想了一个定位功能，做到一半可能就放弃了。

　　说到这里大家不禁有个疑惑。我们姑且关起们来说话，既然外界的需求相对稳定何故内部的需求变更频频?我自我总结，目前所处的项目中需求变更重要有三种类型：

　　1)老大看着不爽强制要求改。

　　2)产品经理自作主张朝令夕改。

　　3)业界有竞争对手新出一个功能不得不赶超。

　　好吧，我们从这开始抽丝剥茧，首先老大的需求我们稍后再议。竞争对手的变更就真的这么紧迫?这么巧?恰好非要插在本来周期不长的互联网项目中?互联网的一次版本迭代周期也就一两周，甚至好多一周，有多少猝不及防的竞争对手总能在你开展一期需求的时候，让你不得不顾及他们的新功能?我想很少，甚至可以说没有。除非自己公司请来的产品经理都是脑残什么都要等着别家出来功能，慢慢抄袭。这种假设一般是不成立的，两个公司之所以成为竞争对手，是因为实力相当。即便是抄袭也是互相抄袭，不会不给喘息的机会。如果需求因此而乱恐怕是自乱阵脚!

　　顺便提下，老大的强制需求，首先肯定老大直接干预的并不多，即便有这么事必亲躬的CEO，何不先问问为何要这么要求?何不想想变更后的利与弊，如果你说的客观合理，老大不会糊涂到即便错了也要坚持吧。再者就是，事实上来自老大，和竞争对手的层面导致需求变更的情况概率相当小，如果一个产品经理常常把这些挂在嘴边，恐怕是不称职的一种体现。

　　最重要的原因，似乎已经发现了，就是产品经理自作主张朝令夕改。既然知道病因，就不难医治。但是需要对症下药。对此我总结的集中典型情况如下：

　　1)病情一：产品经理自己缺少经验，说白了就是还没真的想好就说设计已经完成。就开始开发。

　　症状：开发过程中研发常常询问细节逻辑，产品经理常常改变原有需求。

　　危害：让所有的评审工作的成果付之东流，让测试参考的依据化为乌有，实在百害无一利，这就是典型的欲速不达

　　对策：客观的放映情况，如果您再公司有足够的权利，把这些稚嫩的产品经理调到不足轻重的小项目中去磨练。

　　诸葛亮尚且可以挥泪斩马谡，我们也不愿意看到长平之战的赵括毁了一个项目。

　　实在没办法，我们只能强制要求评审需求，多问问几个“你确定嘛”

　　2)病情二：当初设计太多完美，以至于提出了很多研发技术不能实现的炫酷效果。

　　症状：产品经理为了成品高大上，设计很理想的效果，但是实际的情况不理想，导致一直僵持PK，需求不断调整

　　危害：可能消磨团队的斗志和信心，有很大的延期风险。

　　对策：诚知，毕其功于一役乃产品大忌，其实凡事讲究实事求是，硬要在现在安卓手机上实现iPhone类似的指纹 识别功能似乎不太现实。其实软件设计大多是带着镣铐跳舞。即便是所谓的研发大牛，也是用人家的API吧。

　　我们测试人员，要合适的时候晓以利害，让产品经理明白，快速迭代积极改进，才是互联网的制胜之道。

　　此外，可以加强概要设计评审，以加强需求能实现的评估。

　　3)病情三：产品缺少主见，觉得这样也行，那样也行。设计出多套方案相对比，选取更好的。

　　症状：一次设计出多套方案，让研发测试都实现，最后选取效果最好的一套。

　　危害：有目的的尝试是好的，盲目的尝试大多徒劳无功。

　　对策：我挺多有很多人鼓吹，我们的产品多么精致，我们的图标是从一百张里面一张张的筛选出来的。

　　我承认精益求精的品质。但更相信中庸之道，过犹不及，所有的事情都要因地制宜，因时制宜。

　　对此我们可以强调项目的实际情况，可以综合考虑时间，人力，技术经验等因素，制定出合理方案。

　　实际工作中可能还有各种各样的情况，只要我们勤于总结，勤于思考，总能找到一条适合自己的应对之策略。其实还有个大前提就是传统互联网和移动互联网，传统互联网项目周期长，可以凭借强有力的评审制度，有效的控制需求变更。移动互联网求快为主。这只是希望大记得磨刀不误砍柴工的道理。与此同时也要不断的革新。比如你身处移动互联网公司，可以将传统的几个小时的需求评审，压缩到晨会的十几分钟。当然这也提出了对人员的要求，要求你对需求足够敏感。能及时的提出问题，切莫让敏捷流于口号，切莫让晨会流于形式。

　　关于应对需求变更，其中的技巧和经验还有很多，相信只要大家有心，也能积累更多的经验。

　　版权声明：本文出自 qishaorain 的51Testing软件测试博客：http://www.51testing.com/?15050050