今天特别想谈谈需求管理这回事！
需求管理跟测试有什么关系？
什么是测试？好的测试，是把产品问题扼杀在需求上，耗费的成本远远小于项目走到需求之后流程产生的成本。是否如此？
有没有遇到过一个版本就在一个需求单上，后面评论区跟着长长一段各路大神讨论需求的留言，需求改动后的样子到底如何，还需要使劲在评论区内找其真身？
有没有遇到需求A在开发过程中，变成了需求A+A.1+A.2……，发布后，过了一段时间回来或者换个人来跟，看到的还是需求A，A.1+A.2不知何处可寻？
有没有遇到需求是测试W负责，跟进期间需求B改动不少成了B.1，同期测试Y负责的功能C和B有关，B的一个小改动直接影响C，然测试Y并不知道有B.1的改动，等到测试遇到了问题，咨询后才知道？
作为新人，或者工作中难免要去负责一个迭代了好几个版本的功能。面对需求输出出口不统一的情况也曾混乱和痛不欲生过:跟进一个迭代了好几个版本的需求A，去找去看不同的文件，还要找不同的人问改动详情……期间沟通，搜索很费时间和心力，还要被产品反问:不是跟你们测试谁谁说过了吗（太囧╯□╰）。
什么是好的需求管理呢？
我希望需求管理能解决以下几点：
1、每个产品对应一个总的需求文档，无论产品经历多少个迭代，看到这个需求文档就能大致熟悉产品现在的情况；
2、哪个版本对应哪些需求，能一目了然；
3、每个需求变更都得到很好的控制，即使小需求小改动，也请好好深思熟虑后，经过审核再纳入版本中并备注修改缘由；
4、每个需求变更，在哪个版本上开发，大概的开发时间，开发完成时间，提测时间；
5、一个大版本拆分多个子需求跟踪，各个子需求能指派给不同的开发，不同的测试跟踪，针对子需求的改动都能从上面了解到；
6、需求变更了，一定知会到相关人员，消息出现断层，就可能会影响项目进度了；
7、需求开发完成，测试验证通过，才算一个需求完成的周期；
8、最后，每个版本迭代后，及时更新总的需求文档，备份在案。
需求管理不止步于产品，也和整个项目相关人员紧密相关，好的需求管理能减少很多不必要的沟通。项目这么赶，何不花点时间规范一下呢？
以上是我的一些体会和看法。
不知道行业内对需求管理是否有个比较好的标准？
大家对需求管理又有什么样的见解呢？期待路过大神们的高见。
PS：
百度了解到的其他需求管理办法：
Excel管理跟踪：（用Excel管理不利于多方相关人员查阅和修改。如果是腾讯文档的Excel，列数多时查看起来不方便）：
https://blog.csdn.net/wangzi11322/article/details/82388175
#有输出，有成长#
