问题描述：
ericzhangali：
用三个角色来描述：开发部门，测试部门，客户。
公司和客户合作的方式是根据客户一个模糊的需求做出原型，由客户使用后一次次提出修改意见，一次次修改后由客户决定何时可以量产。
目前的流程是：
1）开发人员有新版本直接release给客户，以改动大小和多少决定是否送测试部门测试。
2）客户收到版本后评测，把修改意见反馈给开发人员。
3）测试部门收到测试需求后测试，并把测试结果反馈给开发人员。
出现的问题是：
1）如果开发人员决定需要送测，往往也是在送测的同时已经release给客户。测试是否失去了部分意义。
2）开发人员只关注客户反馈的需求和bug，并不关心测试部门反馈的bug。测试是否失去了部分意义。
3）测试人员不了解客户需求，测试工作无法把握重点。
4）如果流程管理认为测试部门应该把握release产品的质量，要求每次release前都要送测，是否合理。（背景是经常客户要求很急，上午的电话或mail，下午就要新版本。）
希望讨论的问题除了上面的之外还有，
1）项目经理/产品经理如何协调这三者的关系？
2）与客户打交道的窗口是在开发部门合适还是在质量部门（测试部门）合适？
（虽然与测试紧密相关，但揣测一下，觉得还是发在项目管理区。）
精彩回复：
AlexLJM：
1）如果开发人员决定需要送测，往往也是在送测的同时已经release给客户。测试是否失去了部分意义。
这种是Alpha和Beta测试同时进行。其实关注点不同，不能就说就没意义。
2）开发人员只关注客户反馈的需求和bug，并不关心测试部门反馈的bug。测试是否失去了部分意义。
如果开发不关心测试的意见，那按照我们这里的话来说就是瞎忙活。测试最终的目的是为了更好的为产品质量服务。其实我们有时候的角色也有点Client。把1）和2）和起来看。这产品就根本不需要测试跟进。
3）测试人员不了解客户需求，测试工作无法把握重点。
没有需求的测试是盲目的。盲目的测试有时候不仅提高不了产品质量还会给整个产品带来副作用。不过很多公司都没有书面需求的习惯。这个时候就要测试人员具有需求分析的能力甚至要亲自收集客户的意见。
4）如果流程管理认为测试部门应该把握release产品的质量，要求每次release前都要送测，是否合理。（背景是经常客户要求很急，上午的电话或mail，下午就要新版本。）
按照我公司的流程。这个版本是不可能出去的，除非研发自己承担后果。（我公司产品release一般需要QA部门的签字）
1）项目经理/产品经理如何协调这三者的关系？
项目经理更多的是要对产品负责，产品经理则要对客户负责。项目经理负责研发/测试的梳理和协调工作。产品经理负责客户的说服/说明以及协调工作。这里面其实就是项目经理和产品经理之间沟通问题。
2）与客户打交道的窗口是在开发部门合适还是在质量部门（测试部门）合适？
不知道其他公司怎么处理。我公司基本上研发/测试都有与客户打交道的机会。测试部门甚至以后会成半个客服部门。我觉得无论研发还是测试，都应该多了解市场，多了解客户的想法。具体到打交道，一个项目的研发/测试主要负责人一起出发。呵呵。
鹿鸣：
按照标准的开发流程，任何不经过测试的产品，都不能发给客户。
没有测试部门的确认，软件产品的质量问题由项目组负责，测试部门不承担任何的责任。
如果开发部门不支持测试部门的工作，测试部门有权利不测试产品。
“测试人员不了解客户需求，测试工作无法把握重点。”这个问题问的很好，每一个测试人员对此都会迷茫，主要是时间和经验的关系，小软件好把握，但大的系统，如果没有经过系统的培训是很难了解软件过程的。所以真正测试行业软件的时候，都需要有相关行业经验的参加测试小组或做为顾问。测试小组也需要进行一定 的培训。（我测试过很多比较大的家伙，了解那些东西就要花费很长的时间，实际很多的项目，测试3、4次才知道里面的东西具体是怎么运作的）。
上面是测试部门的一些事情。下面说说管理方面的。
在实际过程中，测试部门一般都比较的弱势，除非公司特别重视产品的质量。很多的时候，留给测试的时间都不够，在软件行业的都知道，项目很少有按时完成的， 基本都会拖期，这个时候影响最大的其实就是测试。如果客户急着要，即使产品没有经过严格的检验一般也都发出去了。
项目经理的责任就是严格的掌握开发时间，了解客户的需求，和测试部门进行协调，准备好一切测试部门的相关资料。（现在程序员都在赶进度，基本没有文档，所以在测试前写测试用例是基本不可能的，反正至少在我工作过的公司，无论是程序员的设计还是测试人员的用例等，都是事后补的，这是没有办法的事情）。
在很多的时候，测试部门可以说是代表客户利益的，但真正成熟的软件公司，分工都很详细，比如有专门的需求设计人员，负责和客户打交道；还有专门的售后服务技术支持人员；通常测试部门只负责产品的质量，不会和客户发生关系。
AlexLJM：
在很多的时候，测试部门可以说是代表客户利益的，但真正成熟的软件公司，分工都很详细，比如有专门的需求设计人员，负责和客户打交道；还有专门的售后服务技术支持人员；通常测试部门只负责产品的质量，不会和客户发生关系。
我们公司以前就是这样做的。可惜在定位一些问题要不要改善的时候，经常要经过一个流程才能反馈回结果，有时候这个结果根本就不符合我们的需要。后来痛定思痛，决定减少这个流程。
鹿鸣：
测试部门测试完毕签字确认后，实际就已经和项目没有什么关系了。除非有太大的质量问题出现，表明是测试部门的责任，这个时候会由公司给予测试部门相应的处罚，与客户或项目组无关。
至于客户的问题，应该有技术支持人员（通常由开发人员兼职或转职）解决。
技术支持人员解决不了的问题，如果原项目组还存在，反馈给项目组；项目组解决不了的，就告诉客户下一版本解决，能拖则拖，拖到客户忘了为止。
如果项目组不存在，而问题真的很多，客户还必须使用这个软件。那真是太好了，赶紧重新组织项目组，开发2.0，又能挣一笔钱，哈哈。
AlexLJM：
技术支持人员解决不了的问题，如果原项目组还存在，反馈给项目组；项目组解决不了的，就告诉客户下一版本解决，能拖则拖，拖到客户忘了为止。
如果项目组不存在，而问题真的很多，客户还必须使用这个软件。那真是太好了，赶紧重新组织项目组，开发2.0，又能挣一笔钱，哈哈。
ericzhangali：
同意楼上两位说的流程。但是感觉目前的情况是把测试工作划分一部分到客户的相关部门。客户认同的方式似乎就是发版本给他，他测试，提交bug list和修改意见，修改后再发给他，他再测试。。。直到他满意，这里面的一次次release我个人觉得不是很正式。在时间压力大的时候或改动很微小的 时候，这种不是很正式的release是不是一定要送测，在VSS上打label，然后得到一份不是很关注的测试报告呢？因为同时版本也已发给了客户，也 许很快，客户也反馈了报告。
往往有一个现象就是客户提交的bug list和测试部门提交的差别很大。倒不认为这是alpha和beta同时进行。
这种方式确实测试部门不承担责任。由开发部门/人员承担。
至于测试人员了解需求的问题，情况是，对每个客户，产品的功能大致是相同的，测试人员也是比较了解的，也有老手写好的full test用例和simple test用例。但每个具体的客户可能外观要求不同，有的功能细节有不一致，甚至不同客户关注的问题点也不同。我是指这个情况测试人员不了解，这个情况只有 直接和客户联系的开发人员了解。但开发人员又没有太多时间跟测试人员详细说。
如果把窗口转移到测试部门，不知道客户会不会有意见。他们可能更希望和直接的开发人员联系，提出需求。
ericzhangali：
两位可能不太了解我的情况，我口才有限，觉得有些表达不清楚。呵呵。
我觉得可以理解成原型法的一个挖掘需求阶段，但又不完全是挖掘需求。
大致的过程是：
当接到一个新的客户时，我们按照他们要求的功能和UI大致做一个实现，砍到我们认为我们的solution暂时做不到的，或行为和我们的solution差别比较大的就劝说按我们的方式做。得到这个实现后，客户就不断地测试，递交bug list和需要修改的需求，我们就不断地给他新版本。
这个过程可能超过一个月，频率可能一两天或两三天就发出一个新版。同时我们自己的测试部门也做测试，发现的问题，优先处理严重的。直到客户觉得基本达到其要求，他才会量产、小批的给他的客户试用。然后反馈试用出的问题和需求，我们再做修改。这个频率一般不高。再然后，他才正式量产。
我觉得，小批生产前的是不是属于正式的发布？是否一样地需要严格按流程管理？
AlexLJM：
我觉得，小批生产前的是不是属于正式的发布？是否一样地需要严格按流程管理？
当然不算正式发布，顶多算个验收测试。看你说的情况，严格按照流程管理只会增加管理成本，导致项目延期。
鹿鸣：
现在规模软件开发，重视的是开发流程，努力找到一种适普和容易控制的开发方法。但理论和实践是有差别的，所以才有一个不断调整的过程。这样，根据不同的实际情况，可以对软件开发流程有自己的理解和方法。
现在流行的剪裁rup就是为了适应各种不同的情况而实施的。所以很难说哪个好或不好。但通常情况下，流行的方法都是经过理论和大量实践，所以一般都适合于各种情况。
至于你们公司，是否有修改的可能和必要？如果没有，那么当前这种开发情况就是最合适的。否则可以找咨询公司，为你们公司的实际情况设计一套开发方案，这涉及大量的细节，这里简略的讨论实在不是很合适。
ericzhangali：
呵呵。质量流程部门坚持要每次release前都送测，他们好象不在乎送测的意义有多少。看你说的情况，严格按照流程管理只会增加管理成本，导致项目延期，说服不了测试部门。
我觉得对release的定义模糊。
客户工程师一个电话打来说改一个bug，马上发个新版，是不是一次release。
如果只要有送出就要经过测试的话，我觉得还是由测试部门和客户打交道吧，接收需求，研发修改，提交测试，再送出。至于时间，由测试部门去和客户协调。
wbsndts：
按照这样的现实情况，谈需求的窗口不应该是研发部门了。
ericzhangali：
唉，规则都是人制定的，也都是人执行的，混吧。
由于测试的人远离客户，他们不清楚客户的需求的关注的权重，往往他们报来的bug和客户提出的bug相差很远。我们只能优先考虑客户的bug，而渐渐疏远公司流程中测试活动的产物。
这日子只能先这样过了。。。