遇到这种情况QA怎么做？

lily_014

案例情况描述：
有一个政府的网站项目，之前首页设计 因为用户老不满意 改过了N版，后来经与用户确认落实了一版 也得到了用户的认可。现在项目在上线阶段了，收集用户意见。其中有一个领导反馈了几个意见。有这么一个问题，要求修改一个地方，但一旦修改了这个，会导致整个首页的布局要重新调整和设计。

存在的问题和风险：
1、增加项目成本和进度延迟就不说了；
2、这只是其中一个领导提出的，如果改完了 其它领导是否会满意？这个我们也可以沟通解决，就是在改的过程中把demo提供给所有的用户作确认。但问题是之前确认过的，现在也提出了修改，要是改完了后再提其它意见呢，没完没了了。。
3、遇到这种情况，QA该怎么做？面临的问题和风险以及潜在的风险预测到外，还能做什么会更能体现QA的价值所在？


上一篇：如何评判BUG引入阶段？
下一篇：敏捷开发和高级别CMMI

fifi_wang

这个问题很经典.很多公司都有遇到这样的问题.这个时候,感觉流程的约束起到的作用有限,更多时候取决于执行流程的执行人了.如果项目经理的沟通能力比较强,让客户走变更流程.找出客户的主要负责人,以主要负责人来负责,而不是根据某个领导的意见来做事.同时,做需求分析的人,要深刻理解客户的需求,想客户之所想,甚至还要想得比客户多和远,去引导客户,就不会出现客户总是变来变去,被客户牵着鼻子了

个人意见,仅供参考.

lona_ma

做政府的项目通常都会有这种根据一个领导的喜好而修改的问题，，，因为一个领导的喜好拆掉上百万的工程的事都有，别说你这一个界面了。方法就是一个领导一个领导去拜访，先去找大的，大的说这个界面没问题了，然后再去找小的，就说这个是某某总看过的界面，已经同意了，请再看看又没什么其他的意见没有~~~ 如果拜访不到大领导，大领导提出的问题一定要修改，然后初始界面加一个realese note，写明啥时候根据啥人的意见修改过，正式的再去掉，，，问题具有中国特色，我们也要利用中国特色解决。

lily_014

是的，这个问题比较普遍。而且是面临的用户，不是老客户。

整理MSN群里RepIns的建议：
让客户 书面提出一个需求变更的请求
你们拿到这个请求 分析可能存在的风险
时间、成本、开发、测试 等等的代价
然后 按照度量 或是你们以往的经验，提出你们的要求。
若他们接受你们的要求，你们就接受他们的变更 ；若不能 就再协商，直到最后。。。。。。

lily_014

整理MSN群讨论：
jd说：这个案例很有代表性.很多公司都有遇到这样的问题.但这个问题的解决不只是过程或流程单方面就能控制的.还要取决于人的经验和能力.也就是项目经理本身的经验和与客户的沟通协调等能力。。
楼主提到的,QA在这个问题上应该怎么做呢?
RepIns说：QA  现在啥都不要做  自己做好自己的事就好啦~若是时间空闲 先理解一下他们的“需求”等需求确认了 才开始。。。。
jd说：嗯,需求挖掘和分析也是出现问题原因之一.那另一解决办法就是尽量好地做好需求,找出客户所有的需求,并比客户想得更深和更远.可这个又取决于需求分析人员的经验了
RepIns说：这个， 我有不同看法~如果做产品的 我们要挖更深 更远的需求~ 但是做项目 我们做多了~ 会加大成本，我们要控制好成本
jd说：这个是当然的啦.我说的是想客户所想,需求做深一些,引导客户,就不会存在被客户牵着鼻子,今天要改这个,明天要改那个了

lee_huo

做政府的项目，通常有一定的背景。这个时候需要商务出来协调。建议可以让商务或PM找对付的主要项目负责人，召开一会汇报会或项目演示的会议，让大家提意见；不过需要提前说明的事得把握住和你确认页面的那个领导。
qa可以把这个作为经验教训放到组织财富库，然后把最好解决的方法也放进去，这样总结出一个方法供以后类似项目借鉴。

lily_014

呵呵，lona_ma提到的比较有意思，确实也挺符合实际的，看来也是做过不少政府项目的哈。

但这又涉及一个问题了，虽然说有大领导，但是他们内部之间的关系我们也不清楚，所以说不管是大领导还是小领导，如果在二级领导面前说大领导同意这样的话或类似这样的意思，会认为是拿大领导来压制TA，他们会非常不爽，很可能会因此来为难你。还有可能被告到公司的BOSS处，以前偶听过类似这样的案例。就算是大领导决定了，他们在没有得到一致的意见之前，他也不敢轻易签字的（毕竟晋升的时候还要得到广大“人民群众”的响应不是^_^），可能只会很口头的同意说我这里可以pass，再看其它部门的意见。因为 实际上他也知道一旦签字就必须要对其负责。。。。很多情况与想象当中的还是差距很大的。

[ 本帖最后由 lily_014 于 2008-8-22 12:56 编辑 ]

xixiaojing666

QA在这个问题上怎么做?
感觉QA没有能力引导项目执行方向，只能由项目经理出面和客户进行沟通，并产生一个好的解决办法，不管采取什么方式，新需求一定要有书面文档以及客户的确认，同时新需求带来的额外工作量以及成本分析、进度延迟，都要得到用户的认可和确认，这样以后的工作就好做点了，QA在这个过程中，尽量使项目工作都遵循组织规范。使项目在每个过程中都能按照组织规范执行。

lily_014

恩，lee_huo和xixiaojing666两位的意见比较中肯:)

期待更多不同的见解。。。。:lol

timlq

问题很普遍。
需求的问题，简单来说客户根本不知道自己想用什么东西，因此让首先做个界面出来，也确认了。（但并不意味着以此为准了，政府类项目就不用说了，一个人一句话的事）。辛辛苦苦做出来了，再一看，不满意，改（变更，不走不行）。这个时候再让他确认的话与之前的效果一样。改完之后，再看看，满意就OK了，不满意就继续改。
如果有可能，在出现改动时，就是一个领导对界面不满意，先根据他的意见做了一个新的出来，让其它领导也看看，最好让这些领导大爷们开个讨论会什么的，问题由他们自己解决，来确认出一套方案来。方案出来后，碍于情面，就是有意见一般也不会再提了。需求也最基本上“稳定”了。
如果有一个强势的大头，这类问题会少很多。
如果这类项目有一个明确的上线日期，关系到分管此事的某一领导的头上，年度有一个考评什么的，出现这样的问题可找他协助解决，比重新修改设计快多了，成本什么的也会省很多。

lily_014

呵呵 是的。非常同意楼上的意见阿。。可问题是 现在没有他们没有一个压力。。这也不是偶方能努力就能成的事儿阿。。:Q
如果 他方有一个明确的期限的话，如，上头发话了，必须什么时候之前给我上线，否则年终奖就没了。。那他们会比我们还急着上线验收的。。。那个时候 他更多的心思就不会放在 看着这个按钮碍眼，那个文本框不适了。。:)

timlq

准确的来说，这样的项目就是一个无底洞。根本不可能知道什么时候是一个终点，怎样的实现才是他们需要的。
如果可能，先把它上线了，当然，需要实现他们想要的大部分功能。把这个当作是项目的一期，他们再提的需求划分到二期中去实现。然后就是要钱，可能会有一个尾款不会支付，留着就留着了。项目的人员就可以撤了，留上两个人维护，跟踪需求，实现，最好不要影响系统的整体构架。到这一步，项目基本上可以说是结束了。

[ 本帖最后由 timlq 于 2008-8-23 22:35 编辑 ]

gn0350

领导的意见以项目负责领导或者官最大的、说话权威的那位为准，若要修改，修改需要的时间、人力、另外附加的费用要讲清楚，如果客户几位领导之间协商未果，暂不动手做。如果有二期，可以协议放在二期讨论后实现。

cecilia

确实是一个普遍的问题，项目需求老是更改，需求管理做的也不到位，一点也不规范，整个被客户牵着鼻子走，一直得不到客户真正的确认，即使给了需求，也是模糊的。
好像一直都是在项目经理与客户进行沟通，QA应该怎么去介入呢？按需求管理规范要求项目经理提供资料？可之前整个需求并没有去按规范去做，需求最多也就是通过内部项目组成员的评审认可。关于这一块，后期QA应该如何去介入呢？怎么去管理整个需求呢？至少对项目本身是有帮助的，而不是为了规范而规范。:o

fishred

前段时间参加项目管理的培训，听到了一个案例，觉得那个公司的做法真的很好，事情是这样的：
有一个跨国公司想做一个人力资源系统，就公开进行招标，很多公司来了，有很多公司也做了原型，但是不符合贵公司的要求，有一家公司，以前也帮此公司做过系统，就提出为了反馈客户，觉得派公司20个年轻小伙帮此公司做苦力，以此名义调研需求，2个月过去了，此公司重新做出了原型，客户对他们这次的原型很满意；

通过这个案例也许对你有点启发吧，呵呵！
要做到也挺难的，客户是否愿意等！