fairylv2lv2

感谢分享！

谢谢分享

谈谈我的看法：
[color=Blue]1、试验发现了一些问题，但RD人员认为这不是bug或者他们认为这个bug不严重不需要解决，这种情况怎么办？
我在一家可靠性咨询公司工作，公司要开发一个可靠性方面的软件，团队由开发人员、测试人员和我共同组成。我的主要职责是负责确定软件应有的功能，就是向开发人员提需求。
由于毕业时间不长，还处于意气风发的阶段，有的时候提的一些需求开发人员不认可；有的时候工作得太忘我了，直接就去抢了测试人员的行，冲过去告诉开发人员软件哪些地方有bug，争执之后大家都不是特别高兴。
后来做的时间长了，慢慢的有些体会。软件/产品就像那些研发人员的孩子，即使真的有什么问题也需要委婉得说，并且要证据确凿；测试人员正好和开发人员相反，工作一天下来要是测不出bug来总会觉得过意不去，测出来之后还挺激动，觉得一天没白干；我呢，就是个提需求的人（怎么想起来《心急吃不了热豆腐》，我不，就是个卖菜的），需求提得不够，老板那交待不了；太多，影响人家开发的进度。怎么办了，后来看了个P图，把初始的需求都提出来和大家一起商量，得到大家认可之后对需求分阶段，每个阶段完成相应的需求，而不是逼着人家一次开发完；需求确定之后就描述错误状态，这时候一定要考虑完善，等到bug出现之后，只要拿错误状态一对，他们想不认帐都不成:)，当然有时还是有遗漏的了...

说了这么多，其实归根结底就是这么三条：
[color=Blue]1、得有判别的标准，就是咱们大家常说的故障判据，这样大家就没有那么多是不是bug的争执了；
2、同时还要多做换位思考，站在对方的角度思考问题有时会豁然开朗的；
3、要有沟通，其实研发和做可靠性的人都是有一些“臭脾气”的，所以沟通很重要。而且个人觉得做可靠性除了专业的知识以外，更主要的就是沟通和协调，因为要打交道的人真的是个方面的都有啊。

不知不觉写了这么多，看来两年的工作真不是白干的，感觉自己有点成熟了:$

[[i]本帖最后由fairy于2008-9-2711:34编辑[/i]]

不能下，为什么要设置阅读权限？