软件产品发布后出现重大质量问题，谁来负主要责任？开发人员...

恰恰是项目经理不应该有这样的权利。对于质量的评审和判断，根本就不应该是项目经理的工作。而且这个评审和判断的标准与过程，也不应该是项目经理制定的。

测试组负责人不是应该对质量负责么?

“简直就是没测过”不是在说自己么?

"恰恰是项目经理不应该有这样的权利。对于质量的评审和判断，根本就不应该是项目经理的工作。而且这个评审和判断的标准与过程，也不应该是项目经理制定的。"

质量的评审和判断 不可能由项目经理自己来做 应该是项目经理的上层来做. 但责任是项目经理的.  项目经理应该有权利控制整个项目的测试工作 也必须对项目的进度和质量负全责.

项目质量的评审和判断是综合性的 尺度不可能也不应该掌握在测试人员哪里
性能只是一部分 更重要的是市场的效益 和客户的反馈 很多项目需要经过一段时间才能分出优劣. 这个尺度需要由负责公司运作的人来把握.

顶楼提到的的问题 应该在项目经理那一层 就先解决掉. 不能正确运行的程序 应该没有资格进入质量评审阶段. 质量评估不是给小孩擦屁股的保姆.

哈哈，项目到了最后的收官阶段，才发现质量的重大问题，显然不是做不做测试的问题，而是测试流程的问题。出来这样的严重问题，必然是流程，而流程的制定就不是项目经理的事情了。质量的评审是一个和开发平行的过程，如果只到最后阶段才进行，显然是不可取的。我不怀疑有些bug会在最后的阶段才被发现，但是像功能需求理解错误，显然不应该是最后的最后时候才被发现的。

由于项目经理直接控制测试 对项目的质量负全责 实际的问题反而会少.

很多公司将测试从 项目经理的职权中分离出来 本意是要加强公司的质量控制. 往往事与愿为. 开发人员在开发的时候根本就不考虑质量性能问题 而是将问题留给了测试  这样开始的项目质量都可想而之 而且还会超时和延迟.

其实性能瓶颈 质量问题 都是在最初的设计阶段出现的. 只有让设计者对质量和性能负全责 才能避免这个级别的bug.

这件事的关键是人的问题 不是公司的管理流程. 责权的混淆能让 所有科学的管理流程失效.

哈哈。
开发人员开发的时候根本就不考虑质量性能问题吗？为什么可以不考虑？难道他们公司的管理流程可以容忍这样的事情发生，还不是有问题？
则权利分配不清楚，本身就是管理流程的问题，即便不是流程问题，也是最高领导的管理问题。项目经理只是执行者，而不是政策制定者。

当然是参与人员都有责任。

但在中国，这个责任给谁担，基本看高层的意思了。可能是公司担，可能是个人，可能是几个人。

这个只是表象，最终该是谁的就是谁的，跑也跑不掉。谁受益，谁负责，这个原则永远不会变。

我把这句话阐述一下。“谁受益，谁负责”是风险管理的一个基本原则。每个失败事项，在它没有失败之前都应该被视为一个风险项。如果这个风险项不具现，谁能从中得到利益，谁就应该负责管理这个风险。如果多人受益，那么这些人都对此风险有责任，受益最大的一方责任最大。风险具现之后要追究责任，同样应该根据这条原则。从管理层的角度，事前划分责权利时同样应该考虑这一原则。如果出于某些原因（例如客户专业技能有限，无法对技术风险负责）必须转嫁风险责任，那么相应的利益分配也必须转移。

一个貌似因此也很常见的严重错误是“谁受罚，谁负责”，即用行政手段强行要求一个人对失败/风险负责，否则进行处罚。考虑这种方式的一个极端：总经理可以强行要求扫地的大妈负责管理一个项目的风险，但这位大妈无论如何努力也不可能负起这个责任。但项目真正失败之后，大妈无非是失去一个清洁工的职位，而总经理就必须承担更多的利益损失，从这里就可以看出：他原本应该承担更多的责任。

前面说了这么多，现在我再说说没有说到的部分。
其实我说的最高管理者应该负责，是说他应该负最主要的责。别人并不能因为主要责任在领导身上，就免除了自己的责任。这样的情况出现，绝对不会没有一点征召。而项目中的人，我想有些已经看出了一些苗头，但是可能出于某些原因没有发表自己的看法。这些人自然是有责任的。而项目经理是直接领导者，他如果提前没有一些感觉，这也说不过去，至少说明他的能力有欠缺。而这些问题，其实还是一个企业文化的问题，这又要落实到最高管理者这里。
其实有些事情，并不是没有犯错误，就没有责任。比如你同别人合伙开了一个公司，你的合伙人犯错误造成了亏损，那么按照法律和人情，你都要担负责任。你的合伙人做的事情即使你不同意，但是由于你们的合伙人的性质，就决定了你们是有福同享，有难同当的——他犯了错你自然会受到损失，而他要是冒险成功，你自然也跟着有受益。而责任这个问题在法律上来说一般首先会考虑，谁的受益最大，然后才会考虑谁犯的错误。