浅谈测试管理—应对需求变更

发表于:2014-7-24 10:52

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:qishaorain    来源:51Testing软件测试网博客

  今天想和大家说的,其实无非是和我们如影随形的需求边变更。似乎自我入行一来一直听到这个词语。先说何为需求?我按照广义和狭义简单的区分了下。
  所谓广义需求,及时一切和项目有关的想法,建议反馈,都叫做需求。所以狭义,就是产品经理提出的需求文档。其实一定时期内,我们不得不承认,广义需求是相对稳定的,并且有一定的经验可谈。何意?广义需求可以是用户的一个反馈,可以是今年流行的一种设计风格,可以是近几年流行的聚焦区域。再具体点说,就是,用户可以希望音乐播放软件提供高品质,免费,且海量的搜索结果,这个要求可能是几年不变。或者,近几年流行扁平设计风格,再或者这几年移动支付比较火热。这些都是需求,这些需求有共同特点就是相对稳定。
  与之相较,所谓狭义需求,就是产品经理提出的需求,很可能朝令夕改,很可能半途而废,很可能浅尝辄止。比如做一个按钮,可能今天要求放在屏幕中间,明天要求放在底部。再比如今天设想了一个定位功能,做到一半可能就放弃了。
  说到这里大家不禁有个疑惑。我们姑且关起们来说话,既然外界的需求相对稳定何故内部的需求变更频频?我自我总结,目前所处的项目中需求变更重要有三种类型:
  1)老大看着不爽强制要求改。
  2)产品经理自作主张朝令夕改。
  3)业界有竞争对手新出一个功能不得不赶超。
  好吧,我们从这开始抽丝剥茧,首先老大的需求我们稍后再议。竞争对手的变更就真的这么紧迫?这么巧?恰好非要插在本来周期不长的互联网项目中?互联网的一次版本迭代周期也就一两周,甚至好多一周,有多少猝不及防的竞争对手总能在你开展一期需求的时候,让你不得不顾及他们的新功能?我想很少,甚至可以说没有。除非自己公司请来的产品经理都是脑残什么都要等着别家出来功能,慢慢抄袭。这种假设一般是不成立的,两个公司之所以成为竞争对手,是因为实力相当。即便是抄袭也是互相抄袭,不会不给喘息的机会。如果需求因此而乱恐怕是自乱阵脚!
  顺便提下,老大的强制需求,首先肯定老大直接干预的并不多,即便有这么事必亲躬的CEO,何不先问问为何要这么要求?何不想想变更后的利与弊,如果你说的客观合理,老大不会糊涂到即便错了也要坚持吧。再者就是,事实上来自老大,和竞争对手的层面导致需求变更的情况概率相当小,如果一个产品经理常常把这些挂在嘴边,恐怕是不称职的一种体现。
  最重要的原因,似乎已经发现了,就是产品经理自作主张朝令夕改。既然知道病因,就不难医治。但是需要对症下药。对此我总结的集中典型情况如下:
  1)病情一:产品经理自己缺少经验,说白了就是还没真的想好就说设计已经完成。就开始开发。
  症状:开发过程中研发常常询问细节逻辑,产品经理常常改变原有需求。
  危害:让所有的评审工作的成果付之东流,让测试参考的依据化为乌有,实在百害无一利,这就是典型的欲速不达
  对策:客观的放映情况,如果您再公司有足够的权利,把这些稚嫩的产品经理调到不足轻重的小项目中去磨练。
  诸葛亮尚且可以挥泪斩马谡,我们也不愿意看到长平之战的赵括毁了一个项目。
  实在没办法,我们只能强制要求评审需求,多问问几个“你确定嘛”
  2)病情二:当初设计太多完美,以至于提出了很多研发技术不能实现的炫酷效果。
  症状:产品经理为了成品高大上,设计很理想的效果,但是实际的情况不理想,导致一直僵持PK,需求不断调整
  危害:可能消磨团队的斗志和信心,有很大的延期风险。
  对策:诚知,毕其功于一役乃产品大忌,其实凡事讲究实事求是,硬要在现在安卓手机上实现iPhone类似的指纹            识别功能似乎不太现实。其实软件设计大多是带着镣铐跳舞。即便是所谓的研发大牛,也是用人家的API吧。
  我们测试人员,要合适的时候晓以利害,让产品经理明白,快速迭代积极改进,才是互联网的制胜之道。
  此外,可以加强概要设计评审,以加强需求能实现的评估。
  3)病情三:产品缺少主见,觉得这样也行,那样也行。设计出多套方案相对比,选取更好的。
  症状:一次设计出多套方案,让研发测试都实现,最后选取效果最好的一套。
  危害:有目的的尝试是好的,盲目的尝试大多徒劳无功。
  对策:我挺多有很多人鼓吹,我们的产品多么精致,我们的图标是从一百张里面一张张的筛选出来的。
  我承认精益求精的品质。但更相信中庸之道,过犹不及,所有的事情都要因地制宜,因时制宜。
  对此我们可以强调项目的实际情况,可以综合考虑时间,人力,技术经验等因素,制定出合理方案。
  实际工作中可能还有各种各样的情况,只要我们勤于总结,勤于思考,总能找到一条适合自己的应对之策略。其实还有个大前提就是传统互联网和移动互联网,传统互联网项目周期长,可以凭借强有力的评审制度,有效的控制需求变更。移动互联网求快为主。这只是希望大记得磨刀不误砍柴工的道理。与此同时也要不断的革新。比如你身处移动互联网公司,可以将传统的几个小时的需求评审,压缩到晨会的十几分钟。当然这也提出了对人员的要求,要求你对需求足够敏感。能及时的提出问题,切莫让敏捷流于口号,切莫让晨会流于形式。
  关于应对需求变更,其中的技巧和经验还有很多,相信只要大家有心,也能积累更多的经验。
版权声明:本文出自 qishaorain 的51Testing软件测试博客:http://www.51testing.com/?15050050
原创作品,转载时请务必以超链接形式标明本文原始出处、作者信息和本声明,否则将追究法律责任。
版权声明:本文欢迎转载,转载时请务必以超链接形式标明文章原始出处、作者信息和本声明,否则将追究法律责任。
《2023软件测试行业现状调查报告》独家发布~

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号