最近有几次关于企业内部软件开发与测试人员部门设置与角色关系的讨论。
第一种思路是，软件测试一定要与开发人员独立，软件质量的最后一道关口在测试这里，测试人员最主要的工作成果就是他发现了多少问题。
第二种思路是，测试人员也是开发团队的一员，测试人员的绩效并不由他发现的问题数量决定，但要统计系统上线后发现的问题数量，作为对整个团队质量（包含测试）的判断依据。这两种思路，会造成具体的软件开发过程的不同。
第一种开发过程：测试人员依据需求与设计进行测试用例设计，开发人员完成所有开发工作后提交，测试人员依据测试用例进行测试，报告问题。然后开发与测试开始＂打架＂，就测试报告的问题进行讨论：是否真的是问题？是需求与设计的问题，还是开发的问题？如果开发的问题多了，说明开发的质量不行。如果不作为问题，测试的工作成果得不到体现。于是就开始＂内卷＂了，不能达成一致的需要找双方的头目出来协商，如果还不能达成一致可能需要更高级别的＂仲裁＂。
第二种开发过程：测试人员依据需求与设计进行测试用例设计，拿出测试用例与需求和设计人员、开发人员一起进行讨论，确认大家的理解是否一致。开发人员进行开发，完成后提交。测试人员完成测试后提交发现的问题。开发拿到问题报告完成修改再提交测试。在这个过程里，开发和测试并不需要为测试发现的问题如何统计进行多轮次的争论，他们关心的是如何更高效的消灭这些问题，确保上线后的问题尽可能少。
显然第二种模式能够避免＂内卷＂，让整个开发团队协同起来，更高效的为最终的目标工作。
其实避免开发与测试的＂内卷＂只是如何让软件开发组织更高效的一个微小的案例。在这个案例中，包含了一个核心思路，就是首先将一个组织看作一个整体，要为这个整体设定一个目标，组织内部的不同部门、不同角色都是服务于这个整体目标的，围绕整体目标的实现，拆掉“部门墙”，让内部更高效的协同。
由微而著，其实在我们更多的地方都可以遵循此原则进行优化改进。
现在互联网软件公司逐渐盛行的OKR（Objectives and Key Results，即目标与关键成果法）、敏捷软件开发方法给出了如何打造一个具有创造性、充满活力的组织的具体的思路、方法与实践，值得我们研究和学习。
由一个故事说起．
我们部门从事企业管理信息化软件开发工作．去年年中开始，为了提升开发效率与质量，开始推进一些过程改进措施，如项目团队按照双周进行迭代，每天开1个几分钟的站会，迭代结束对完成情况进行一个演示复盘．每月开展绩效评价，每月部门负责人选几名员工进行面对面沟通，了解员工的想法．
首先说下我理解的＂内卷＂。
百度百科的定义：内卷化，指一种社会或文化模式在某一发展阶段达到一种确定的形式后，便停滞不前或无法转化为另一种高级模式的现象。
我理解这个词包括了两种现象：１，一个组织缺乏创新，面对外部竞争环境，只通过内部高压态势的＂挖潜＂来获得生存机会。２，组织内制定了一定的竞争规则，使得内部的部门或个人为了有限的资源陷入非良性竞争，这种竞争并不能为组织带来价值，甚至形成内耗。
