这两年在测试管理上的工作经验提升对我来说还是有很大裨益的，想着以故事的方式把自己的经历杜撰一把，当中的心得和感受可能从描述和理解上来说更地气。

      在原来公司做了半年不到的测试主管，一次领导找我谈话，问我对公司现在的测试现状和产品质量的看法；当时因为测试团队刚组建，所以就提了一此工作执行中的困难和细节问题，同时也指出现在主要的问题是各职能部门对于项目权责划分不明确，看似项目中可管理的人员有很多，确没有负责的主体人员；加上因为研发流程的缺失，使工作中这种都能过问，却没人主管的情况更显突出；并对规范和执行操作和人员习惯上说了一些执行方向。本来也没当回事，以为也只是领导随意的和执行管理人员了解一下现在底层的工作状况。没有想到的是，没过多久领导再次把我叫去开会，这次会议很正式，我分管的领导、公司中心的领导包括研发后端主要部门各负责人都参加了会议。讨论的就是领导和我上次谈话的关于公司产品质量和研发规范的问题，会议基本很快就达成了共识；第一，必须成立一个独立的部门以保障公司产品的总体质量；第二，这个部门的首要任务就是建立起一套有效的企级的研发流程规范。

      一切来得都很突然，会后，中心领导找我单独会谈，一个就是经中心各分管领导讨论；觉得我比较适合担任这个部门的负责人，一方面我本来就是带测试团队，而对我的工作能力和工作经验，各方也自算比较认可；另一方面我原来在其他公司参与过sqa的相关工作和CMMI评级审核的项目，从公司层面上来说算是对质量保证有经验的人员。所以最终大家觉得与其对外招一个不太了解公司情况的质量经理，还不如直接从公司内部筛选出一个相对容易胜任的人选来主持这方面的工作，当然这个也和我分管的领导大力推荐有关。

      有的人可能觉得幸福来得太突然了，但从骨子里来说，我是个悲观主义者；所以做人做事，我都是未虑胜先虑败。回家后仔细把公司质量问题所面临的现状重新捋了一遍，考虑到现有部门的组织架构，在纸上画了个一新部门的关系图，考虑到现有部门的既得利益，在纸上推演着重新制定一套研发流程，哪部份得益，哪部份可能会成为阻力。重新审视了一下自己，自问一下自己是否适合这样的一个部门负责人的定位。最后想了很久，决定还是要尝试一下，不管怎么说，这样的机会难得，同时也明确了部门如果成立后可能遇到的多方压力和障碍。第二天一大早，把自己的思路和想法，包括可能遇到的现状邮件给领导。这次的汇报并不像前几次约谈和会议一样，只是泛谈或只讨论表象问题（毕竟当时以为只是工作状况的反映）。而是把自己的想法和质量现状系统性的整理罗列出来，并在邮件中要求和中心领导再作一次单独会谈，对于这个新部门的定位和后期的领导想法明确下来。先来说一下公司组织架构和各部门现在负责人的一些秉性介绍吧，作为背景资料，方便后面的描述

      天下大势如下：公司和业务相关的部门大体上可以分为前端和后端两个大块，前端主要包括市场部、主体的运营部门、客服部门等。而后端主要由产品部门、一个超级大的研发部门、项目管理部门、运维部门等。还有一些业务部门因为比较独立不与其他业务相关，它们以自己的一条产品线独立成部，部门内有自己的产品、运营、研发人员等，这些部门相对来说前端人员或客户代表相对独立，而研发部门相对薄弱，所以开发测试运维等还是需要后端的研发服务部门来进行支持的，因为业务量的关系，测试人员也是不固定，统筹管理。我们后端的研发部门又分为前端研发部和后端服务部，前端业务部与所有的业务部门和产品对接，人员众多，后端服务部主要是为主体业务提供后端数据的支持包括主业务的对外服务请求，包括公司一些主要的技术攻坚及储备，对外接口的输出等等，相对来说，这个部门人员较少但主要的开发技术骨干都在这个部门中。还有一个移动研发部门，因为他们相对独立，虽然隶属前端研发部门，但基本自成一体，公司所有对外业务的app研发任务均有这个部门提供。所有产品业务线的测试人员则由我统筹管理。从组织架构上来说，隶属大的研发部门中向中心的一个分管领导汇报，但不独立成部，以组的方式独立于大的后端部门中。主要和前端业务或客户的对接由产品部门负责这个部门相对于公司前后端两大部门的桥梁。我的组内有个leader很形象的把我们的部门机构和古代青楼进行了比较。按他的说法，我们后端服务部门就是一个青楼，前端业务部门就是我们的主顾，产品就像龟公，按客户需求来分配任务；项目经理就是调教嬷嬷，在管理上有一定的权限，但在人员的项目计划上基本没有多大权利（还满符合我们公司上的设定的，哈哈哈）研发团队就是姑娘，按技术能力分头牌花魁等，能力强的可卖艺不卖身，也可挑客。质量保证人员则是护院，保证服务活动顺利并保质进行，而运维则是送客小厮。当时因为分管领导的关系，没有把老鸨这个角色YY进去了（玩笑）。虽然这个对比很胡闹但对于各部门的描述还算贴切。

      最后和领导多次沟通后，基本把我要的权，和他看重的责明确了下来。其实领导的意思很简单，就是近期公司各产品线质量反馈不好，而且问下来，也没一个人对所有产品总体质量情况了解的人可以问，所以想成立一个质量部门持续的加强公司各产品线的质量问题，并规范研发的工作流程，建立一套适用于公司的大而全的研发流程并及时把与产品质量相关的内容和问题直接反馈上来，并且把产品质量作为评价一个对各部门工作情况的侧面指标来看，对部门的绩效起参考作用（当然这是隐形的说法）。而为了让这个部门能顺利开展工作，领导赋予了两个权利，一是部门定位，独立于后端部门，单独成部，汇报对象直接是中心的主要分管领导。二是所有公司产品的质量如果达不到这个部门的标准，有权限对产品的上线保有一票否决权。单从工作权限来看，其实部门的权限已经很大了。也由此可以看出对于产品质量领导也算是下了血本，工作配合方面肯定也会积极支持的。大方向订好后，就开始走流程，从内部竞聘到部门人员组建等等整个过程差不多持续一个月，才算基本尘埃落定。

      部门建立了，工作如何来开展呢？放在我面前的一个个问题在部门确认后浮现出来：领导是希望建立一套大而全的统一研发流程，方便质量管理，但前面我也介绍过，公司现在的情况是组织结构纵横交错，职能性部门和业务性部门兼而有之；每条业务线或产品线质量需求和规范标准也是不统一的，工作方式更是各家有各家的样（最简单来说，公司连配置管理工具都不一样，有的项目用git和有的项目用svn）一套流程把所有项目和业务包起来，施行统一的质量标准，想想就不可能。大家都知道质量、成本、效率是项目管理的三大要素，加强其中一个方面，必然要损失其他两部份内容。而我前面也说过，公司各产品线没有统管人员协调总体的目标；现在把质量作为单独的内容拉出一个新部门来负责，那对应的其他两部从的分管不部门必然成为一个对立的关系。（这当然和我们各部门的绩效没有从业务整体来制定考虑不无关系）当然从部门的角度来考虑，作为质量保证部门完全可以全面导向质量第一的原则进行流程改革和标准制定，但可以预见如果单从自己角度出发，不能协调各方利益，最终可能部门的目标达到了，但项目整体利益是损失的，如何来平衡项目的总体利益和各部门的绩效目标？如何来把握领导对于项目质量的期望和项目总体成本的矛盾是我在工作前必须明确下来的。

      摊案立规，有分有序；于是第一步开始了……

一个测试老鸟的工作总结（3）——质量部门成立之现形记全录（上）