2019年10月26日，由Testin主办的第二届NCTS中国云测试行业峰会在京召开，此次峰会以“AI+未来”为主题，汇聚来自国内外测试领域的知名专家学者、领先企业决策者、高层技术管理者、媒体从业者等，共同探讨高端云测试技术，帮助测试从业者了解最前沿行业趋势，及最新的行业实践。
会上，前海风教育工程卓越中心高级总监吕理伟做《全方位的研发效能管理及提升体系建设》主题演讲。吕理伟指出，“研发效能提升体系，基于组织架构转型助力，工具系统赋能，人才文化为本。一个公司里最重要的是人，任何公司不可能完全依赖系统生存，公司的文化建设很重要，要提升人的主观能动性、团队合作意识、工作能力和意愿以及公司的文化氛围。”
以下为吕理伟演讲实录：
为了让大家安心的待下来，我得先做一下自我介绍，刚才樊老师说数学基础，要算法，也听到很多技术人在讲很多的技术细节的内容。我技术还不错，2003年我数学专业本科毕业，2006年研究生阶段搞算法，所以我的数学基础和算法基础应该都还可以。刚才有一个人提到了“精准测试”，我毕业后刚开始做的是白盒测试，当时同学问行覆盖、条件、语句覆盖，06年我做白盒测试时候测的是飞机软件，当时的白盒测试判定标准是MCDC，修正条件的判定覆盖。
那时候我们说质量意识怎么来？当时我们说质量意识怎么来，我在2006年刚刚毕业时进入公司，带着我们看空难视频，对生命安全对敬畏。如果你前面看《中国机长》那个空难，当然是靠他超强驾驶技巧和意志救回来了，如果是软件Bug，飞机就出问题了，所以06年毕业我们做飞机软件白盒测试，领导说如果你们测的不仔细，某一个Bug可能导致飞机就下来了，所以在我毕业的时候我很耐心的做了两年白盒自动化测试，那时候就是读代码，写代码，做各式各样条件、判定、覆盖，去看覆盖率到底达到100%，99%，某一个没有覆盖到会解释为什么，所有的测试报告都要很全面的来讲清楚。
在2008年，我跳槽去做黑盒自动化，在2009年我又开始做测试架构，测试技术的管理，包括测试流程建设。2015年我做测试总监，但是条件很艰苦的时候，还是要亲自干的。慢慢负责质量管理，负责工程效率，信息安全。在去年的时候，我到海风，我们成立工程卓越中心，部门里包含测试、质量管理、信息安全、基础架构、运维、敏捷教练、工程效率，所以在这里，我会负责全面研发体系的管理，这是我职业发展的经历。其实今天大家听了很多，比如：在敏捷测试中，你什么时候会被开掉，敏捷测试人员在哪里，还有一些技术的测试、算法测试的趋势，从我个人对测试的理解来讲，我从2006年白盒、黑盒、框架、技术管理、研发转型，包括流程和现在的基础架构、运维、工程效率等整体研发管理来讲，测试人员的路是很长的，大家要有信心。
有人说我做两年手工测试不知道我在干什么，也不知道以后我会干什么。其实我刚才强调了手工测试，在业内，可能大家会说我是做功能测试的，我以后要做自动化测试，这句话本身是不对的，不知道大家对这个有没有理解。手工测试对等的才是自动化测试，功能测试对等的不是自动化测试，对吗？功能测试对等的是性能、安全。维度，所以测试分类里千万千万需要注意的一个维度，我希望在座的各位能够对测试有一个很有信心的方向。我做了差不多13年时间，到现在这个位置已经不完全是测试，我做的是一个整体研发中心的支撑和管理。
现在进入正题，我从四个维度给大家讲，第一是研发质量效率，第二是组织架构助力，第三是工具系统赋能，第四个是人才文化为本。因为在任何一个公司都会从组织、工具和人这几个维度来做质量、效率的管理和建设。
质量和效率，看起来是矛盾的，大家做测试的过程中都会说，为了高质量，所以会拖慢研发的效率。还有产品经理说我为了发布，我不需要太高的质量，有时候都会有矛盾的。所以质量效率名字上来看，貌似是有点矛盾的。质量领域咱们提到过不知道有没有听过一个概念“大质量”。咱们说软件有研发过程的质量有需求设计的质量，有交付之后线上的运行阶段的运维质量，甚至还有软件运行过程当中的售后支持的质量，其实这个质量维度很宽，包括你接到一个客户的投诉，怎么对客户进行反馈，其实这也是质量问题。在大质量体系里，我们可以做的有很多，只要你对产品足够熟悉，都会在质量领域做的很好，是有更多贡献的人，而不是说我只能做软件研发过程当中的测试，这是两个概念。所以当你在一个软件研发过程当中做很多测试，你对这个行业足够理解，对产品足够熟悉，你可以做很多，所以在大质量体系里，是从一个需求或者一个诉求产生，一直到这个产品在线上运行的10年20年全生命周期都会存在的一个东西。
说一下研发效率，很多公司这几年都在提我要节约人力成本，提升研发效率，我相信很多公司都有，尤其是这两年经济形势不太好情况下，很多公司会去做一些优化结构的事情，研发效率有很多维度衡量，比如，一个需求上来以后，是一周做完还是两天做完，当然每个人对这个“完”的定义不一样，所以研发效率是要通过一些手段去衡量，也要通过一些手段去提升的。所以刚才提到一个问题，高质量会不会拖慢效率，这个问题在很多公司，尤其在产品经理眼睛里会觉得我是接到死命令的，比如，今天10月26号8点上线，我是接到死命令的，要倒排的，测试人员如果一味纠结质量，会拖慢我的效率的。
然后还会看到一些问题，我们是工程卓越中心，之外其实还有业务部门，业务部门跟我说吕老师我们很忙，我们也很高效，你不要管我们，因为我们是职能管理和支撑部门，很多业务经理是有业务话语权的，人家是业务，我们是支撑管理的，就会说“我很忙”，不要跟我提流程和需要交付的质量，那些东西会拖慢我们，他有时候说我们很高效，你昨天提的需求我们今天就做完了，这些问题在很多公司都会讨论，尤其互联网要快速迭代，跑马圈地，所以业务部门会说我很忙，一直都很忙，我也很高效，但是很忙很高效是需要度量的。很多互联网公司有些招聘的JD，不知道大家会不会关注里有一条“熟悉度量系统”，你怎么度量这个部门，这个研发人员做的好还是不好，所以咱们带着这几个话题往下走。
在研发质量效率的过程当中，我们说要提升质量效率，这两年大家都在提“敏捷”，09年开始，我接触敏捷到现在10年时间，我们一直说什么是“敏捷”？有很都公司说敏捷，来了就改就是敏捷，拥抱变化嘛。敏捷在业内里有这张图，我从2009年保存到现在，我不知道多少人看过这张图，这是非常经典的敏捷的图。这里强调几个概念，第一个这是一个ONE TEAM，所以刚才老师说我们没有很好界定来区分开发测试，是因为在DevOps里，大家是一个TEAM。我们会有一个战略，产品解决什么问题，有产品的战略，有目标，有愿景，要去总部或者向管理部门申请你的预算。然后拆分成计算成若干个发布版本，这是在从产品一层层去切，这是敏捷的一个概念。
在RELEASE里才有迭代，有一些迭代计划和回顾的会议，每天迭代的时候才会拆分成DAILY就是每天，有每天的开发、测试、验收。最中间是持续，CI的过程，这是一个非常经典的图，你把这个图看懂了敏捷就清楚了，就会把一个拆分粒度越小，但是这个图最经典地方在哪呢？就是在这里，说这种圆，它不是同心圆，是有一个交集的一系列的圆环，这个为什么？因为敏捷目的是什么？敏捷目的是随时可以交付的软件，随时可以使用的软件，所以在这张图中，每一个交集的输出都是一个可以工作的软件，这是这个图当中最精华的部分，所以敏捷从拆分、交付、价值，从整个团队的合作模式这张图讲的很清楚。第二个问题，在座的其实更多的是测试人员，咱们说一下测试在哪里，敏捷模型里测试在哪里？其实我想听到的答案是：哪里都有，在敏捷里测试是无处不在的，包括你怎么去提升你在这个team的贡献，以及话语权，对需求的理解，测试人员可以做很多事情，这是原来对测试团队比较常见的期望，我希望他们能够引导产品，引导开发去做出一些真正符合用户需求的产品，而不是说需求设计出来了产品经理说了算，我跟着你走，你告诉我怎么样，我帮助你点点点，那不是我们对测试人员期望，那会让大家的路越走越窄。
在敏捷里面，测试无处不在，所以我们刚才说自己的职业发展轨迹和敏捷里我对测试的理解，我希望大家对测试行业是有足够的信心。
在一个企业里你想让敏捷能够成功，其实要有几个因素，最重要的是人，一个团队里最重要的是人。这个人经验OK不OK，做事情主动不主动，自我管理，刚才说有自我驱动，我今天听很多关键字都差不多，你是不是可信赖，“可信赖”这个词是很高度的评价。我们测试同学曾经收到过开发总监给我发的表扬信，说他是“可以信赖的伙伴”，我说可信赖是值得大家认可的词，是很高度的评价，他认为这个测试人员是一个可信赖的人，我交给你的事情我放心，所以说“可信赖”。
流程是法，强调的是软件研发的一些方法，技术会依托在一些敏捷软件研发的工具平台里，做到人技法的和谐才能够让你的组织敏捷，这是怎么能够让敏捷落地的一些因素。
刚才咱们说敏捷也好，怎么解决质量效率问题也好，怎样让敏捷落地，提升测试人员话语权，让大家对质量有共同的意识。在企业里测试组织到底怎么架构，你到底有没有权力，咱们说权责对等，所以说咱们聊一下组织架构怎么助力大家提升质量和效率，怎么助力提升大家的质量意识。
在敏捷组织转型里，有一些人会把开发测试产品放成一个Scrum团队，这是一个产品化的管理模式，还有一种测试团队是独立的，开发团队是独立的，产品团队是独立的。所以在做人员管理时，我们强调的是什么？矩阵式的，这个测试人员是双向汇报的，要汇报给测试总监、测试经理，也要汇报给产品经理，因为产品负责制，双向汇报。
第二个是作战单位，战舰编制，就是Scrum团队，这个你可以理解成七人组，有一个产品经理，四个开发，两个或者一个测试，这是一个作战单位的模式。敏捷组织转型里还有一条DevOps或者TestOps怎么把开发运维做一些模式。
我们建立了多层质量保障体系，这个我们做的比较细，也就是把一些质量保障工作融合到CICD各个节点里，比如开发人员做什么，提交代码以后做代码扫描会怎么样，打包到自动环境去，自动化测试环境脚本怎么跑，到底UI层还是API层，怎么跑起来，在每一层每一个节点上都会有相应的测试活动或者质量保障活动，包括测试人员测完了还会有集成的测试，怎么把这个推到比较相对来说稳定的环境里做一些大规模回归，做大规模回归的自动化，做多层质量保证体系也是助力敏捷组织转型的一个方法。
我在海风负责工程卓越中心，这里我们的职能包含这些。产品研发并不在我这里，这是业务部门，除了业务部门之外都归我负责。我们会做什么？第一我们做培训我们要提升所有人员技能，你想让大家高效率的工作，你要培训他，因为每个人进来以后，或者进来的那个时间点，每个人的背景也好，工作习惯也好，能力也好，都是不一样的，你需要进行培训，你要能够遵守或者能够更快的融合到这个团队里，能够更快的掌握这个产品需要的技能和后续的一些开发需要的方向上的知识，所以我们会做培训。
工程效率和基础架构在我这里，工程效率可能在一些公司是工程效率部，基础架构部会比较独立。
质量控制，质量控制可能就是咱们大家普通或者常见的理解测试，传统的QC，QA和QC本身是不一样的。还有应用运维，系统发上去要保持稳定的，应用运维也在我这里。外面我们会画一个圈叫“流程优化”，我有一个敏捷教练组，会跟着所有项目发现问题，发现我们研发过程中哪一个节点需要优化，所以外围我们会定流程优化组。
左右两侧，一个是质量管理，一个是项目管理。在我们公司，尤其现在公司这个角色划分并没有那么清晰，项目管理和质量管理本身PMO，功能职责上有一定融合，但是项目更多的是追踪，我这个进展是不是OK。所以每一个公司情况不一样，会做一些调整。
信息安全，我们对所有工程师有一个要求，大家做事情要有安全的标准，如果你不遵守安全标准，你做得再好也是给别人做的，为他人作嫁衣。信息安全组同样归我管，我告诉他们的职责是去保障所有部门人按照咱们定义的安全规范来做，你按照我的规范做事后，检测你的系统是不是OK，所以有信息安全的检测，前期是督导和监控。
除了产品研发这样一些业务部门，那我们为什么会有这样一个组织架构，其实是我们要权责对等。不知道大家在公司里会不会发现一些问题，测试部门和运维部门之间扯皮。出了问题了运维部门说你没有测出来，测试人员说这个很难测，这需要运维手段保障的，比如CPU达到多少要做自动监控，重启。运维说你没有告诉我达到什么指标以后我做监控。还有一些扯皮就是信息安全和测试，信息安全说安全测试到底是测试团队来做还是安全团队来做？很多公司不一样，在我这里，我跟他们说，当然这是一些管理理念的问题，我跟所有的经理说关起门来，你们经理怎么吵我都认，出去了都是我的问题，但是你们今天吵完以后必须要有一个结论，到底是测试团队还是安全团队的问题，如果你们认为这是测试团队的问题，那OK，这个责任和权力已经都是测试团队的，对吗？这次出来一个漏洞没有检查出来，安全人员说我不做安全测试，应该测试团队做，测试人员说我没有这个手段是信息安全团队做的扫描，这就会扯皮。扯皮完以后有一个结论，结论以后谁背责，谁担权。这次我背锅下次我要这个权力，出这个门这个权利就是我的了，你那个做安全扫描的人就可以定位成安全测试了，你就要换部门换小组了，你就要给我了。所以我们会把组织架构做一些优化，来让大家信息沟通更顺畅，让大家权责更对等，让大家能够像同样一个人负责。因为出了那个屋所有锅都是我的。
我们刚才说组织架构是要助力整个研发体系的提升。在这里我们提到了，在这过程当中我们做价值驱动和规则驱动，怎么保障产品，咱们说的产品研发是按照我们定的规则去做，做正确的事，咱们理解成是价值驱动对吗？你在做高价值的事情，因为每个公司的人是最贵的，人投进来以后希望做到的是我这个人做的是最有价值的事情，所以我们说价值驱动是保障人在做正确的事。规则驱动是什么？是保证这些人在正确的做事，所以我们会提两个概念，一个是价值推动，一个是规则驱动，你是不是按照正确规则做正确的事，这是我们部门要去做管理的，这也是授权给我们，我们要做管理的一些手段。
事前会做一些价值评定，事中的看你研发的流程是不是OK，研发之间沟通是不是顺畅，通过你的项目管理，通过你的流程优化，通过你的测试来做事中，事后通过运维、质量管理做分析。通过这样一个维度保证研发质量和效率是能够提升的。
因为咱们叫质量效率，很多公司会提效能，因为我们想把质量效率都提升的时候会有一个效能的指标衡量一个开发人员的效能是不是高，到底是质量高还是效率高，其实我们希望共赢或者找到一个提升点。所以我们怎么去衡量开发人员的效能指标，怎么衡量产品人员的效能，一个产品你设计出来的东西到底有没有用？
你怎么衡量一个产品做的设计，提炼的需求是不是对的，其实也是他的效能，你三番五次改，改来改去自己都不知道做什么，所以我们对产品经理要求很高，尤其是任何一个互联网公司产品的方向是很要命的一个事情。效能体系出来以后每个人都有自己的结果和数据，我们通过数据驱动这个人做一些提升，所以我们希望能够通过数据驱动大家有一种荣誉感去提升自己。我们刚才提到价值驱动，规则驱动和数据驱动。
我们希望有这么多驱动，你肯定不是靠人来计算的，假设一下200个产品研发部门我不可能投200人跟着他们去盯，那样我这个部门就拖慢效率了，我的投入产出比就很低了，老板会说我不要你这个部门，我情愿多加100个开发去干活了，所以提升质量效率的维度里我们希望有工具系统赋能，不光是考核的，还需要赋能的，一味考核大家会反感，所以我们希望大家赋能，提升自己的内功。
“工欲利其事，必先利其器”，没有最佳流程，只有最佳实践和最适合流程，我把Google的流程搬过来一定是好的吗？肯定不是。我希望能够有统一平台，可以让各个部门之间信息沟通能够很顺畅。
第三我们有定制开发工作，互联网公司都会定制自己的系统，基于开源框架也好，基于免费工具做一些插件。这样来辅助我们的流程落地。
第四个咱们刚才说度量，就是我怎么知道这个开发，这个测试到底好还是不好？你不要去考核，你不要说我发现你的数据不好，所以这个月绩效打折吧，只能说我是来督促你提升的，但是我不是考核你的，所以我们说数据是用来赋能的，不是用来考核的，因为你一旦考核人员就会有反弹。我们要的是赋能。
坚持到现在的大家都是有希望成为总监的。公司里我们定制一些工具打通信息流，这个在CICD里概念都差不多，从需求开始，怎么做录入、承接、开发、数据度量，刚才说软件全生命周期，那这伴随的是需求全生命周期，到底做的是什么，这其实是一个需求。
包括你的代码管理，CICD，版本管理，所有的数据要进行收集的，然后流动的，一个数据收过来以后不用去度量，不作为下一个节点的输入，这个数据一点用都没有的。这个产品质量到底好不好？你说告诉你了现在有10个Bug，然后呢？然后不知道了，那这个信息一点用都没有。当然你告诉产品经理说我告诉你现在有10个严重的Bug，所以它会阻塞发布，这时数据是有用的。你怎么阻塞发布需要有流程和工具，不然完全去靠人扯皮，测试总监、运维总监扯，那系统里怎么办？还要发。所以数据输入过来，输出去，这个数据流动起来才有用，像钱存在银行到底有没有用？也有3%左右的利息，钱只有流动起来才有用，还有一个观点钱只有花掉才是你自己的。
所以我们把数据收上来之后到这个需求生命周期管理，那肯定要做一些节点的准入或者是不准入的判断，在系统里要把这个东西做进去，每个节点能够做自动控制才能够提升效率同时保证质量，不然的话你不知道会发生什么，因为有很多人为事情。
这个图是CICD比较常见的，我刚才把多层质量体系已经介绍过了，在每一个阶段到底我们做一些什么样的质量保障活动？比如，代码提交以后怎么做代码扫描，怎么打包，然后怎么做集成测试，怎么去做一些发布包管理，发布包管理也是质量活动，因为你有可能会把一些包误发上去，所以咱们说在敏捷里面测试无处不在，你大质量活动可以做到很多地方。
咱们刚才说需要度量，那度量的时候肯定要分阶段，或者说你需要度量不同维度，因为每个公司都会看我投多少人带多少价值，有资源投入的度量，有交付效率，你这个需求到底是一周交付还是两周交付的，还要度量交付的质量，交付质量有过程质量，在研发过程当中这个开发引入多少Bug，被reopen几次，这个指标很可怕，你提交我测出问题了，reopen标准不一样，当然能收的就收，还有技术做实在太差没有办法测试就测不下去了，我只有把你重新打回去，我扔回去给你了，我们认为开发人员被退回去过多的话，这个开发人员是不负责任的，相信在座测试人员也有这种痛苦，你看你给我一个东西，正常场景我都跑不通，我一报，10来个Bug就上去了，到底修还是不修？我退回给你重新写，把功能自测一遍，那次数多了以后这个开发人员就是不可信赖的了。所以我们要衡量交付过程质量，包括衡量线上质量，线上质量你到底逃逸多少，这个是衡量测试的，我报100个Bug，但是逃逸出100个，这就很糟糕。但如果报100逃避一两个，这一两个也是很不容易被发现的，我觉得他是很优秀的测试工程师。
这些数据都会从各个项目管理系统当中收过来，然后做一些统计做一些展示和大盘分析来度量这个开发、这个测试和这个产品是不是优秀。这是我们做的资源投入的分析，这是我们的需求交付。包括研发过程当中Bug新建，解决和趋势，来看这个团队到底有没有积极响应测试人员的工作。比如，我报了他不管我，看我存量Bug一直上去，积极性都没有了。我报10个Bug你不修，报20个还不理我，那我干什么呢？我不干了，这时候测试人员积极性会被打击，这时候每一个管理者都要去推动这个事情，管理者要做什么，你要让兄弟们有一个舒心的工作环境，不能让兄弟做的没有信心，觉得自己做的工作不被认可，不管任何一个决策，比如运维，觉得我做的工作好象不被认可，信息安全说我定的规则没有人管，我报的Bug没有人修，这时候需要谁来推？不一定指望一线的测试工程师推，你要有管理者，不然管理者的价值在哪呢？
所以，我们通过这些数据给到一些管理者，你说你团队到底在干什么？我测试人员辛辛苦苦报Bug你到底认为有效还是无效，你需要给我理由，你不修的理由是什么？如果无效可以谈，如果有效的话，你就去修，不能拖着，所以会有研发过程的数据度量。我们还会做一些雷达去看这个Scrum团队在哪一个维度做的比较差的，分几个维度，比如需求维度，开发维度，测试维度，运维维度，安全维度和其他。到底哪一个是短板？因为有一个木桶，到底是长板最厉害还是短板决定容量，所以在雷达里面我们可以清晰的看到这一个Scrum团队在这一段时间到底在哪一个地方做的不好，通过数据告诉这个Scrum团队负责人，你这个团队里面产品这一段时间产出很差。你这个团队里面的开发这段时间产出很差，让他及时知道我问题出在哪，然后针对性的来提升质量和效率。
研发效能提升体系，基于组织架构转型助力，工具系统赋能，人才文化为本。一个公司里最重要的是人，任何公司不可能完全依赖系统生存，公司的文化建设很重要，要提升人的主观能动性、团队合作意识、工作能力和意愿以及公司的文化氛围。我们为了解决这些问题做了什么？我负责技术委员会，在很多互联网公司都有技术委员会，怎么做到技术人员能够找到自己的方向，知道测试人员提升的方向是什么。当我测试发现技术上的问题时候我找谁帮助？前端的开发方向是什么？我可以向谁学习。前端、后端、产品、测试各式各样的方向会有自己的一些公司内的大拿来做这个方向上的领头人，给下面小伙伴一些技术指引，这是咱们技术委员会的一些职能。当然还有公司技术架构的评审，做一些技术选型的评审，这也是技术委员会要做的事情。还有培训学院，在刚才介绍我们部门架构时候讲了，培训学院也是，你怎么让大家得到提升，让大家愿意在这个公司接着工作下去，让大家能够觉得我在这边做是能够得到我想要的东西的，当然钱是一方面，你要看一眼半年以后我再走，工资会比现在高很多，因为我在这边学习了半年，所以我们有培训学院，针对我们工作需要的技能，针对这个人想学的技能做一些培训。
当然还有绩效激励，工作不爽有两点，一个是钱没有到位，二是受委屈了。我做了很多事情就是为了让大家开心，影响开心的很多因素就是钱和工作内容，所以我们做了技术委员会来让帮助大家提升技能，培训学院让你觉得我能够学到东西。还有很重要的一块是绩效，怎么看绩效就是看前面数据，这个人绩效效能一直在上升的时候就要给奖励了，不然的话人家觉得我辛辛苦苦在做，我贡献越来越大，我为什么不可以从原来一万涨到一万二呢？可以，月基本工资都有奖金，所以我们有绩效的激励。
考核的时候到底怎么做考核？第一个是把长周期的转成及时的，因为有一些公司会觉得我一年，反正前面12个月都是大家无惊喜，没有任何惊讶的做到年底，然后给一个绩效，说今年得到两个月年终奖还是四个月年终奖，但是这个激励是很晚，因为，在这个过程中，员工不知道年底会得到什么，有些人前面10个月做的很好，第11个月的时候，做考核的时候犯了一个错误，让你忘记他前面10个月的好，很多公司都会这样，我们以前也遇到过这种问题，有些问题跟我们说你看前面做的很好，我们静下心分析的时候，发现真的做的很好，但是由于每年10月、11月他给你印象觉得这个人不靠谱，就是让我做砸了，觉得很伤心，年终绩效就不好，这对于这个人来讲是不公平的。因为人都会有失误的时候，比如失恋了，家里有事了，总之有那么一段时间让你觉得产出偏低了。
所以我们说要有及时反馈和调整，当你发现有问题及时告诉他，当他得到成绩就及时给他奖励，这是第一个从长周期到及时的考核。
从个人绩效团队转移到团队绩效，因为咱们说敏捷是什么？敏捷是一个ONE TAEM，大家不会指责开发人员、测试人员没有做好，所以导致产品质量差，不是测试带来的Bug，是开发人员引入的，但是由于在Scrum里大家是一个团队，这个产品最终的绩效外围因子大家是一样的。在绩效里会有很多考虑的因子，你是Scrum团队里的那个因子至少是一样的，你个人绩效因子可以不一样，但是这个产品的因子一定是一样的，因为大家是对同一个产品负责的。
所以咱们从个人绩效转移到团队成效，然后说不去做这个人和另外一个人的对比，但是我们做这个人自己的对比，你到底现在有没有比入职时候提升这是需要做对比的。做一段时间以后衡量每个部门的数据，看到每一个部门平均数据到底效能有没有上来。
“自己得行”，你自己技术过硬，第二是“有人觉得你行”；第三个是“觉得你行的人也得行”这句话什么意思？比如，某某同学往那一站，一个刚毕业学生说这个人测试技能很好，那有意义吗？没有意义。比如说刚才樊老师陈老师说这个人测试技术很好，有意义吧？有意义，因为他俩也OK啊，所以觉得你行的人也得行，这时候对你认可度是高的，这是一步步来的。
最后，“你身体得行”，因为工作到最后拼的是体力，我2006年毕业，前9年在外企，我在外企看到经理人他们说我们很轻松，我们不要怎么样，但是我也看到很多外企精英很拼很拼，到最后拼的是体力，因为很多人夜里写PPT，第二天去开会，你怎么熬得过呢？到最后大家智商都差不多了，现在信息太透明了，借助于工具可以做很多事情，到最后拼的是你能不能比别人拼得过身体，所以你身体得行，当然大家也要劳逸结合。
所以这四句话是工作这么多年很重要的，我在网上写过一篇文章《测试管理者修身齐家治国平天下》，自己得行就是修身的过程，有人觉得你行，你是齐家，你能够让团队人认可你就是在“齐家”，包括“治国”怎么做测试总监，怎么“平天下”，就像我现在不仅管测试，我还协助老板去管理，怎么让你想做的流程做下去，怎么让你想做的事情被你业务合作兄弟们认可，包括市场，销售，售后支持配合你的工作，大家能够磨合得很好，这是一个“平天下”的过程，这本身需要我们一步步往下走的。
我今天就讲到这里！
