软件质量是软件公司关注的核心指标之一，但是如何保证软件质量确实是一个头疼的问题。每一个软件公司都有研发管理部门，一般他们的职责就是软件开发过程管理和软件质量保证，但是在不同的公司，这个部门的定位不同。有的公司研发管理部门是一个代表管理层的监督和管理控制部门，他们制定各种看上去无懈可击的考核和管理制度，要求开发人员严格按照流程进行软件开发，并根据制度进行考核；有的公司研发管理部门是一个服务部门，他们为研发部门提供开发环境，质量控制工具，流程控制模版，软件开发license检查等共享服务，但是不对研发进行管理和控制；也有的公司的研发管理部门承担了管理和服务双重角色。给研发管理部门赋予管理和控制角色的公司往往认为没有规矩不成方圆，过程管理是质量保证的必要手段，依靠研发部门自己进行质量控制存在管理漏洞，特别是一些公司比较看重一些质量体系认证，希望通过认证在招投标的时候增加一些资质，但是这些质量体系认证往往都是在瀑布开发模型的基础上定义的一些质量控制点和研发过程管理规范。另外一些公司则把研发管理部门定位为一个服务部门，他们会提供QM进行质量管理的指导，根据PO的请求，进行测试管理相关的质量标准设定，提供开源框架的license是否有知识产权风险检查，提供accessibility测试服务，security测试服务，开发服务器的搭建，central的集成测试环境，代码静态扫描等质量管理服务，然后PO根据自己产品的特性，选择使用哪些服务进行质量控制，产品质量完全有PO进行管理和控制。站在研发管理部门的角度，我们来看看下面几个问题。
- 研发过程管理能够帮助提高质量吗？
在IEEE 1983 of IEEE Standard729 中对软件缺陷下了一个标准的定义:从产品内部看,软件缺陷是软件产品开发或维护过程中所存在的错误、毛病等各种问题。基于这个定义，过程管理希望通过管理规避开发维护过程中的错误导致的软件质量问题，从而提高软件质量。比如说需求定义不清楚导致的bug，可以通过需求文档评审来这样的过程管理来保证质量的。软件维护过程中，新人操作不当在软件维护中带来更大的错误也可以通过过程管理来避免。但是如果我们仔细分析我们的bug，发现多数的bug不是因为有需求文档上定义了的需求但是没有实现引起的，或者是需求定义和实现不一致带来的bug。绝大多数bug都是因为需求文档中无法穷尽的，或者需求定义认为自己也没有想到的边界条件导致的bug，这种bug再多的评审都是没有用处的。过程控制同时也会带来无谓的会议，文档，形式主义，并且降低了员工之间的信任。同时过程管理制定的那些刚性标准其实并不适合所有的项目，如何保持标准的柔性也是一个难题。所以研发过程管理是一种手段，但是不是万能的。个人比较认证研发过程管理必须转变角色从管理者和监督者变成服务者，将质量的责任主体变成开发团队。
- 软件质量不靠开发模型
SCRUM作为最流行的开发模型，能够帮助公司提高产品质量吗？答案也是否定的，不要指望采用了SCRUM产品的质量就可以提高。SCRUM把质量的控制权和责任主体留给了开发团队，SCRUM并不能保证开发团队能够把质量控制的责任落实到位。所以开发模型只是一种工作方式，一种工作文化，软件开发如何执行以及执行的效果还是要靠人的能力和态度。
- 软件质量不需要传统的测试工程师
一些公司有专门的测试人员，他们会根据产品经理的需求文档，设计测试用例并进行测试。这种配置如果测试人员和开发人员能力相当，能够在理解需求的基础上自己编写代码进行测试，就类似结对编程的思想，这样的话确实是能够保证质量的。但是如果测试人员只能进行功能测试，并不具备和开发人员相当的编程能力，则测试人员的测试覆盖度是不够的。现实是很多单独设置测试部门的国内软件公司，都是把一些不愿意在coding上有所建树的女生或者编程经验不足的新员工安排到测试部门。在这个情况下，测试的效果是大打折扣的。反过来说，如果测试工程师和开发人员具备同等的开发能力，为什么不能让测试工程师和开发工程师一样从事开发呢？所以传统上那种只能进行功能测试的专职测试工程师只是满足了瀑布模型的流程要求，对于提高软件质量意义并不显著。
我们可以看出，过程管理，开发模型和专职的测试工程师都不是最好的办法。质量核心在人的技能，态度和团队的文化，只要开发团队的编程技能和编程经验足够，团队具备质量意识，完全可以把质量交给PO，并辅以需要的过程指导和工具服务，质量问题一定能过保证。
