质量管理

质量管理的重要目标应在于预防问题的产生，而不在于检验问题的存在；检验问题的手段是测试方法所需要重点关注的。

做任何管理，无论是管人还是管事，都要有一个重要的指导思想，那就是可预期。如果被管理的人无法预期未来的收益，工作上很可能会懈怠或者直接离开；而事情如果不可预期，往往容易失去控制，无论是目标结果还是过程消耗。

任何生产制造都需要进行严格把关，确保产品以合格的状态交付到用户的手上。游戏也是如此，任何一个阻断性的问题都会给玩家带来糟糕的体验，甚至会给玩家带来时间和金钱上的损失，这就是测试存在的必要性。但实际过程中，测试工作常常面临着以下问题的困扰：

1. 无法确保产品无bug。并不是产品经过测试，发现问题后修改，就是没有bug了的。有可能一个bug修改后，暴露出原本被遮挡的另一个bug；或者由于功能模块之间的耦合性，修改旧bug也可能会产生新bug。

2. 测试投入不足。有些团队不重视测试，觉得测试简单，又或者是低估测试工作量，不给测试预留充足的时间和人员。如果上线后出现大量的bug，测试也是要跟开发人员一起担负责任的。当然这其中很关键的一个问题也是测试的工作价值无法做到直观的体现，产品通过测试和不通过测试的差别很难预期，只有发生问题的时候才会被关注。

3. 开发完成度较低。研发过程中的版本计划，都会约定好功能内容和开发完成时间，但有些人将仅仅做完就称之为完成，然后就提交给了测试。但实际上可能逻辑错误，功能无法运行，又或者是前后端尚未联调，数值未配置，美术资源没有到位，这些都会导致测试无法正常进行，又要打回重新进行完善，一来一回都会耗掉不少时间。这种一上来就发现不能测试的情况还是比较好的，最糟糕的是那种测试一半，功能可能因为设计或实现问题要求重做，全部修改，测试的沉没成本是很高的。

4. 测试介入晚，发现问题较为滞后。有些开发团队前期不重视测试，或者还在使用“瀑布式”开发模型，觉得只需要等全部功能开发完成后，一并测试、修改就可以了。低估了问题的影响性，更低估了修复问题所需要花费的时间。导致不断重复“测试-修改-再测试-再修改”的过程，产品上线遥遥无期。等所有问题都改好了，可能已经错过了时机，市场已经转变了风向，玩家追捧的又是其他的产品类型了。

质量管理，不仅可以用来解决上述问题，更重要的是可以提高团队的开发效率，同时起到预防问题的作用。对于质量管理来说，结果很重要，过程更重要，质量管理的核心思想就是将测试行为融入到各个方面、环节当中去，通过加强合作来提升效率，通过目标和结果来推动过程，敏捷测试的底层思想也与此相同。

曾今我在加入一个开发团队的时候，整个开发计划delay了近3个月。然后我在组建测试团队的同时，梳理开发过程中的问题，重新制定开发计划和规范流程，用了半年的时间，不但追回了原本delay的进度，还保障之后每个版本都按期保质的完成。

先说管理

在我看来，管事先管人，管人先管己。想要把事情做好，首先要先能把做事情的人管好，而想好管好别人，首先要能管好自己。很多人对“管理”的理解就是分配任务，让别人做事情。从结果来看，好像是这样，但过程之中有很多问题需要注意：

• 首先我们要理解为什么需要管理？管理的本质是维持一种秩序，一种能够让人把事情顺利做完的秩序。人越多的情况下，维持秩序就会越艰难，因为要做的事情也开始变得复杂了，人在做事过程中的突发问题也变得多了。这其中还涉及到效率、利益、诉求、磨合等等一系列的问题。如果管理不好的话，每一个问题的爆发都很有可能瞬间摧毁当前的秩序。更重要的是，秩序的维持还不能是一成不变的，它还需要不断的改进，适应新的形式，庞大的结构体系如果要发生变动，管理跟不上的话有可能会陷入阻滞，甚至轰然崩塌。既然管理的目的是为了维持秩序，那么好的管理就应该是保证在这个秩序里，事情能够顺利的完成，积极的行为不受到阻碍和压制。所以从我个人的观点来说，管理者更应该像是一个老练的管家，而不是一个甩着皮鞭的监工。

• 不要享受高高在上的感觉。不少人喜欢做管理，是因为喜欢那种指点江山，激扬文字的感觉，只用说不用做。团队有了成绩，自己占据首功，如果出了问题可以让员工背锅。这些职场阴暗面简直快成了“客观规律”，最终只会导致团队解散，误人误己。还有的管理者有很强的控制欲，喜欢别人对其唯命是从的感觉，那他管理的人只会做更多讨好他的事情，而不是真正有利于团队和业务发展的事情。

• 不要以为制定计划就是在做管理。计划确实是管理过程中很重要的一个环节，但最终事情能否按计划执行，才是重中之重。有的管理者安排完计划，不了解进展，不跟进问题，只等着最后结果的汇报，然后发现跟预期不符，就大发脾气，没有考虑过是否是计划安排不合理。管理是为过程服务的，而不是只追求结果，计划只是个参照物，过程中出现的问题才是管理者真正要关注解决的。

• 分配任务要沟通明确，有预先判断。有的管理者分配任务，就是把事情告诉别人，对于这个事情的目的交代不清，要求结果不明，自己心里也不清楚究竟应该做成什么样，只等着别人做完后再高谈阔论，发表意见，彰显自己的水平。时间久了，做事情的人只会越来越敷衍，管理者本身也会慢慢失去准确的判断力，最终一起面临淘汰。分配任务前，管理者自己要清楚这件事应该如何做，以及可预见的结果是什么，这样才能够确保整体的协同性。当然，管理者也是人，不可能面面俱到，什么都知道，那也可以通过找有经验的人来帮忙，而不是以此为借口就直接把事情丢出去了，这是不负责任的表现。

• 做出的管理决定要实际跟进是否真的有用，而不是自以为是。管理者做出的每一项决定，都会影响到整个团队里的人和事，如果决定不能带来好处，它就只会浪费大家的时间和精力。有的管理者自身缺乏洞察力，随意下达指令，甚至朝令夕改，破坏团队协作的同时，也在不断削弱自己的影响力。这样的团队表现出来就是没有执行力，看似动作不断，但事情一点都没有进展。

• 要懂得分享信息。有的管理者很少分享信息，甚至故意制造『信息不对称』来维持自己的权威感。殊不知，信息总会以各种渠道流出，甚至会越传越乱，影响团队安定。还有的管理者喜欢“单对单”安排任务，导致团队里的其他人根本不知道别人在做什么。从执行层面来看，做事情的人只是需要做好自己的事情，不需要关注其他人在做什么，但不需要关注不等于不需要知道。人总是有好奇和猜疑的，与其被各种流言蜚语引起误会，倒不如坦诚大方地跟大家说清楚，既能提升沟通，也能加强信任感，增强团队凝聚力。

总的来说，管理有这么几个方面的内容和评判标准

没有这些效果进行对比，管理者就不能说自己的管理是有成效的，是付出了努力的。其实管理不是一件靠努力而达到的事情，管理更考究的是经验、洞察和判断力，甚至还要带一些运气。真正在付出努力的是那些接受你管理的人，如果你不能带领他们走向胜利，最该接受惩罚的就是管理者。

再谈质量

既然要管理质量，那么就要先明确要管理的对象具体是什么：

• 首先，需要树立明确的标准规范。这个标准不能简单用“好、坏、高、低”这样的主观标准，而应该是尽可能的量化，客观具体。比如最好量化的就是性能测试数据指标，各大发行渠道每隔一段时间都会发布自身渠道的产品调研，可与各个类型的产品的数据进行对照。或者至少可以与产品自己的历史版本进行对照。

• 其次，就是建立完善的流程。比如是先做功能测试还是先做性能测试，先修改bug还是先优化体验等等。在实际的开发过程中，时间总是有限的，而要做的事情却是无限的，如果不能有一个良好的流程来进行推动，很容易导致手忙脚乱，错乱百出。

而质量管理的『标准』和『流程』之所以重要，主要的原因是，它是团队经历过多次摸索尝试后，最终才确立下来比较适合自己的，可以为后续的设计开发和成员沟通，节省很多时间和精力。研发过程中最难解决的其实不是突破什么技术难点，而是反反复复、犹犹豫豫的情况下，浪费时间，白费精力，最后错过了市场时机，如果团队也坚持不下去。没有足够的积累，团队很难走的长远，产品研发也很难获得成功。

可能你会觉得疑惑：为什么没有提到“人”，难道人不是要需要具体管理的对象吗？人是需要管理，但人不是通过直接的思想或言语来进行管理的，那种属于『洗脑』。人是通过做事情本身来管理，或者叫做跟随着事情的发展形式而被管理的，从而达到一种『自我管理』，具体的解释在之后会提及。这里要先提及一些质量标准和流程方面的误解：

• 制定标准的目的是为了不让质量低下的内容流入下一个环节，起到『缺陷预防』的作用。产品开发是一个分工合作的过程，如果某个环节做得不好，越往后越难补救。设立标准的目的不是为了设立关卡，而是提醒大家做好负责的内容，减少对后续流程的影响。

• 标准是一个衡量参照，并不是生产过程中追求的目标。我们常听说产品上线要次日留存达到多少，人均付费达到多少，还说通过什么运营活动或优化方案提高了多少数据。这些数据确实是很重要的商业化指标，也盈利能力的体现。但对于做研发的人来说，标准和数据只能作为一个参考，游戏好玩才是关键，而不是为了数据达标。这就好比开饭店，你可以通过打折促销吸引大量顾客，看似十分热闹，但如果你的菜本身不好吃，很难让顾客下次再来。总不能为了数据好看，一直这么打折促销下去吧，这样迟早开不下去，改进饭菜的口味才是关键。

• 标准不是确立之后就一成不变的，而是循序渐进，逐渐提升的。标准一开始定太高，会让执行的人迷茫，不知所措；如果标准定太低就起不到把关的作用，不如不设。标准跟目标一样，也要结合当前阶段进行合理设置，之后再不断提升，推动发展。不是说设立一个高高的标准，要求大家像“鲤鱼跃龙门”那样，一步跨过就能成功，万事大吉，那只会导致事情很难推动。

• 流程并不是死板的按章办事，流程的重点是能够给予引导。很多人，包括曾经我自己，都以为流程就是应该要完全遵从的，但那样很容易陷入机械式操作。到了后来我自己制定流程的时候，我发觉，流程的目的并不是想要大家完全照做，对于新人来说，流程是起到引导作用的，帮助其上手工作，而对于老手来说，流程可以帮助其查缺补漏，力求完美。所以很多流程一定要文档化，能够长期保存，方便查看。为了最好能够做成工具，促使人们自觉遵循，同时还能提高效率。

• 标准和流程是要全员遵守的，并且要有不遵守时的应对方案。制定好标准流程后，往往不遵守甚至破坏的是两类人：一类是觉得自己十分熟悉的老手，另一个类就是管理者本身。老手是觉得自己轻车熟路了，可以不遵守流程按自己意愿来干，一般是自信的体现。遇到这种情况，我觉得可以让他去尝试一下，如果他碰到了钉子，工作上出现了岔子，那么按照不遵守流程进行处罚就好了；如果他能够一直很好地做下去，不出问题，那就说明他发现了流程可以改进的地方，反而值得鼓励。而管理者本身打破规则，说到底是觉得自己有特权，这个时候也并非是要限制他，而是让他陈述清楚理由，大家商定好预期结果和风险，还有如果达不到预期结果要如何负责补救等，一定发送邮件备案。

前面也提到过，测试包含的内容大概有：功能、性能、兼容、安全，以及自动化测试手段。具体到每个部分的测试标准很多，从玩法设计到程序架构，乃至美术表现和数值配置都会涉及。不同的团队或公司会有所不同，但大同小异，比如腾讯WeTest手游质量标准和百度MTC移动应用质量标准都可以参考学习下。将这些标准按类型划分，再加上对应的测试方法，形成的也就是我们常说的『质量体系』了。

而游戏从研发完成到上线运营，中间要经历很多个阶段，什么试水测试，删档测试，收费测试，公测等等，其实也是在每个阶段去不断验证产品的质量在真实的市场环境下能否经受住考验。每个阶段都有着重点验证的目标：小范围验证的是玩法和美术表现的接受程度，删档免费重点验证的是技术稳定性，删档收费验证的是营收能力；最后公测才是真正大面积宣传。

如何做到

如何做到是个比较复杂的问题，我得好好想想总结下。 我要介绍的质量管理方法，主要是敏捷开发中的观点，主要包含三个目标：持续集成、持续部署，持续交付。