作者介绍：曾永洪(sea)， 研发信息中心支付金融测试团队TL， 从业十多年，经历过创业公司，上市企业，从工程师到高级测试工程师到资深测试工程师，到测试专家，中途做过人力资源经理，负责HR运营管理与企业战略运营，人力成本与编制管理，参与招聘、绩效、流程优化等体系建设，2018年底回到长沙担任兴盛优选测试专家岗位至今。 作为移动互联网领域的老鸟，Testner测试社区创始人，工信部 ITSS工作组DevOps专家组成员，OWASP国际安全组织中国区高级会员，BAT等大企业测试行业公益服务组织金阳光测试深圳区负责人，热爱软件测试，热衷公益事业，践行 “穷则独善其身，达则兼济天下”，一直在软件测试的领域默默耕耘。
在我看来我们研发中心今年提出降本增效是个很好很务实的目标，提高交付效率开源节流也是一个企业要生存与提升市场竞争力必须常抓不懈的。之所以说降本增效是个目标，而非运动，我是这么认为的： 运动是某些人策划组织，然后其他人按照规则参与即可，参与完了也就结束了。但是目标不一样，可能是长期的过程，要不断去挑战与突破，更重要的它不是某几个提出人的事情，而是整个团队的事情，必须全员都行动起来，坚持不懈，从每个人日常工作做起，才能量变引起质量。一定要走出这个误区，光靠几个管理者提出口号，远远不够，目前降本增效已经真正应用到OKR目标中。目标确定了，那么我们如何去落地？ 我认为这个问题必须我们每个人从自身工作去思考，我相信管理层无法给出标准答案。作为技术leader的视角，我最近思考了一些降本增效最佳实践途径，希望能抛砖引玉与大家一起共同完善！
第一部分： 降本增效之技术在行动
作为研发中心，技术是我们强项，如何用好我们手中技术武器去降本增效，提升我们公司利润与市场竞争力，这理应是我们技术人擅长之事。 当然，并不是越多越好，而是应该充分的根据日常工作情况，找出可以降本增效的痛点，机会点，进行优先级与ROI评估后，择优而动！
作为自动化而言，提升效率是最容易考虑的，但是以我的经验来看，不是所有自动化都能增效，任何自动化实践一定要提前进行ROI科学评估，比如UI测试自动化，变更频繁且不是核心功能逻辑，脚本维护工作量巨大，但是价值与产出非常非常低，一般不应该轻易去考虑。
而接口（API）自动化测试应该是很高的，接口自动化测试目前大中企业都做得比较成熟，我不多说，只是提醒一句，我们不要为了自动化而自动化，我们要不忘初心做自动化的目标是降本增效，因为自动化的实践方案一定是够用即可、经济实惠，高性价比。做平台级的产品同时，多做些小而美的自动化创新实践快速增效。
单元测试理论上来说ROI应该是最高的，但是它的成功条件人的因素很大，这个人是否真正理解单元测试的目的与技巧，能否用最少的代码做到最佳的分支覆盖等，都会直接影响到单元测试的有效性。我经过一些团队，单元测试的代码行很多，每次花和编写业务代码差不多的时间去做单元测试编码，但是还是带着实现业务时的开发思维，单元测试case的覆盖与质量很不理想，这样的单元测试实践不但起不到降本增效，反而增加项目成本和延长开发交付周期。
脚本化的话，我个人和团队会形成不断沉淀和整理的习惯，将日常要用的输入经常沉淀，比如验证测试某某金额的准确性、去配置一些东西，整理成SQL脚本、BAT脚本\SHELL脚本等等，这样用的时候可以大大提高效率，也可以提高测试质量，规避因为个人测试输入不正确引起的测试结果错误。其实说到底，也属于复用的一种，复用是我想重点推荐的，复用本身很好理解，大家也都知道，但是真正形成最佳实践，从各个层次各个角落去最大程度复用和减少重复发明轮子，这个既要有研发中心自上而下 的组织布局、又要有每个人日常工作中自下而上的轮子贡献。这句话也许很绕，但是我相信开发同事都能理解，关键是能否有意愿去做，并且愿意和敢于多跨一步去贡献。
复用率的高低一定程度决定了组织能力成熟度的高低，一些新的功能与技术不断沉淀，伴随着不断的迭代验证与PDCA，这些沉淀的轮子质量越来越稳定，后续开发者可以高效的基于API引用，真正的做到高质量高效率，降本增效是非常显著的。我这里想补充的是，复用一定不能停留在代码复用一个层面，业务解决方案的复用、技术方案的复用、开发思维与测试思维的复用，这些都可以形成最佳实践。比如连接池的使用，有些同学可能会基于自己习惯去引入一些新的连接池，有些同学可能会基于个人经验或者网上文章初始化最小与最大连接数，这些都是未经过我们研发中心项目匹配和长期验证，质量风险是很高的，这样的拿来主意不丢人，我们业务研发与测试不同于搞科研，一定是如何快速高效如何最低成本实现为前提！当然，这个与业余时间去探索新的思想与方案不冲突，一个是工作需要，一个是专业兴趣。
对于测试而言，之前我的做法是基于面向测试对象的思维模型，首先梳理出我们研发中心的测试对象，然后基于各个测试对象进行测试思维的沉淀与PDCA，可以把一些优秀的个人思维形成组织思维，这对于提升测试组织能力成熟度是非常有效的，当然，复用到日常测试中测试用例设计与测试执行中，在降本增效方面的复用收益也是显而易见的，在测试质量稳定性方面也是我比较推荐最佳实践。有点劫富济贫的感觉，这样可以规避因人而异的测试输出，同时真正做到位，可以一定程度上降低用人要求与成本。
coc（convention over configuration）实践 ，比如参考springboot的零配置思想，用约定代替繁琐的配置，可以一定程度上减少配置文件和配置工作量，同时减少大量配置开发与维护带来的质量问题。类似改善应用未尝不是一种降本增效的实践。 比如研发中心内部系统见的接口数据传输，如果有固定的前缀和参数，比如http://produce.xsyx.com/xxx/xxxx/xxxxxxx?param1=value1¶m2=value1, 我们能否直接传递元组(value1,value2)，这样对于减少网络带宽数据传输，降低带宽成本，当然，这个与自动化实践一样，一定要具体情况具体分析，评估可行性！
第二部分： 降本增效之管理在行动
管理行动之一就是所有人足够聚焦项目业务，只有项目才是直接输出和可以衡量业务价值的，我们每个人每一分钟都是成本投入，一定要聚焦在业务项目目标本身，或者是为项目服务，减少一些纯管理事务，尤其让项目成员去花时间做些管理事项，也要尽可能减少。 
一些公司要求全员写日报，周报，月报，大家都认为正常，其实不是，这些都是为了满足管理者需要，并没有直接的业务价值；相反，如果这个管理者过程中能及时根据，这些汇报必要性不大，即使要有汇报，应该也只是聚焦业务风险、问题、困难求助，但是即便这些也最好实时同步沟通，不应该等到固定的期限来以报告反馈。要强调的是我说的都是项目组内成员，纯管理人员除外，项目组成员应该让他们为研发中心更加高效高质创造更多输出。
容易忽视的就是日常最多的沟通成本了，比如会议沟通、非正式沟通等。一般而言，互联网文化追求的是扁平化，小步快跑，信息快速同步，所以项目事情应该邮件与IM群尽可能同步所有干系人，
但是会议上，应该尽量缩小范围与时间，每多一个人多一分钟都是成本，试想一下， 10个人或者20个人，里面有工程师、高级工程师、专家，一开会就是两个小时四个小时，按人均直接成本与机会成本去估算，成本还是很惊人的，我们的效率就在会议中溜走了。我个人一般不喜欢参加1H以上的会议，在团队也极力提倡半小时会议文化。 比如原来我们的测试用例评审经常要2H，现在同样的效果，30分钟以内大多数可以结束，办法总比困难多，事在人为，降本增效的机会就在我们的身边。
此外，应该减少职能型会议，减少汇报性会议，这些会议不仅直接产出低，而且时长往往比较长，涉及人员也多。 而决策会是我最鼓励的，带着方案来决策，效率是很高的，而且产出很直接； 此外，评审会也是我们可以重点优化的点，现在各种评审会占据的时间非常多，在此我也建议后续研发内部的评审，尽量安排到下午，上午大家精神最好的时候应该聚焦业务输出，这个时候不仅效率高质量也高。
头脑风暴会，在我们支付金融测试团队也是比较多的，有些时候我会当做是决策会之前民主补充，这样往往大家都能提前参与，决策后能心甘情愿的快速去执行落地，不至于一边被动执行一边还不理解或者不太认可，过程再反复沟通与变更，这样的效率与质量可想而知。
第三部分： 降本增效之质量在行动
最后推荐大家看一本书： 《质量免费》，《质量免费》是管理学的经典名著，也是哈佛、沃顿、耶鲁等商学院MBA的必读物。克劳士比在书中阐释了质量管理的错误观念，以及ITT公司如何在全球实施质量过程改进的成功故事。对于降本增效最佳实践也是有很大参考意义，之所以说是参考，是为了防止一般公司习惯性的全盘照搬，任何对标的理论一定要结合本企业实际情况进行微创新和改进，否则很容易水土不服（别人的问题未必是你的问题，别人的钥匙未必能完全打开你的锁，别人的起点和你不在一个水平线，别人的产品和你不一样）。我提倡对标的是思想，而非行为。
