测试流程规范如何推动落地？
昨天知识星球里有同学问了这样一个问题：测试如何反向管理开发遵守开发规范？
问题的背景是这样：这位同学想提升编码和提测质量，制定了一些开发规范，希望开发去遵守。但实际的执行效果并没有达到预期，导致提测质量差，来回验证，测试效率不高。
星球其他同学也提了一些自己的看法，比如：
- 先做好自己，得到团队和开发认可，规范通过评审，再去推动；
- 规范不一定是问题的根因，建议先找到问题根因，再提出解决方案；
针对这个问题，我想聊聊关于流程规范落地和如何解决问题，我的一些想法。
流程规范的目的是什么？
现代社会中，工作的职责和内容越来越细化，很多事情是需要靠团队协作来合作完成的。而流程规范的目的，是为了确保团队中大部分人在同一个正确的方向上前进。
同时通过一些关键指标、日常宣导和定时检查，让偏离方向的人回到正确的途径上。换句话说，流程规范本身是一种对群体的约束，也是团队内各个成员共同认可的一个承诺，约定和约束意义大于管理意义。
为什么需要流程规范？原因有如下几点：
- 团队中的每个人能力、经验、工作习惯不同；
- 每个人对信息的理解、信息的同步存在理解误差和时间误差；
- 人的特质决定了人无法像机器一样时刻保持统一的认知和标准的行动；
流程规范的执行作用大于理论作用。即需要认可和参照规范执行，才可能接近预期的目标；而不是制定了流程规范，就万事大吉。
以星球这位同学的提问为例，流程规范并不是强制动作，团队各个成员之间本质上并不存在上下级的依附和管理关系，只存在合作关系。
如果靠管理流程规范去推动人的行为，本质上已经偏离了流程规范的初衷。而且流程规范并没有解决实际的问题，问题一定是需要去找到根因，用数据和事实暴露风险，然后评估提出方案再去执行，才能解决问题。
在软件研发交付流程中，无论是研发还是测试同学，最根本的目标是一致的，即提高交付质量和效率。
但影响交付质量的因素并不是流程规范，而可能是需求不明确、环境不稳定、基础技术设施建设落后导致的编译构建失败、风险的滞后发现以及人为变更的误操作导致的。
因此，很多问题的根因可能是上述这些原因，而不是流程规范导致出现了问题。
怎样做好团队协作工作？
要做好团队协作，共同为一个目标而努力，其实只需要做到如下几点即可：
预期目标一致
无论是个人还是团队，其行动的本质是为了达成某一个或某些目标。流程规范的目的是通过约束行动来保证团队成员向同一个目标前进。
因此在团队协作过程中，真正要管理的是预期目标，而不是人。所有的行动过程和结果，以预期目标为导向。如果发现行动和目标不一致，逆向去分析是什么因素导致的，然后通过流程规范去约束这些行动。
及时的信息同步
团队协作要管理预期目标，这就涉及到这几个问题：
- 大家对目标的理解是否一致？
- 大家对达成目标的过程行动是否一致？
- 大家对和达成目标有关的信息是否存在理解偏差和传递延时？
管理预期目标，在行动上就是让团队成员对信息的理解、传递和加工处理，保持一致。
比如产品提供的PRD，产品的预期目标是A，研发的理解是实现成B，测试用例要验证的结果是C，这就是对目标和信息的理解以及同步出了问题。
所以我们才制定了需求评审、code review、测试用例评审等很多流程规范，来保证对目标结果和信息的理解是一致的，这样才能确保行动的方向不出现大的偏差。
这里同样体现出了流程规范的作用，为了解决目标和信息不一致的问题，才用流程规范约束行动。流程规范是手段，而不是解决问题的目的。
解决问题而不是提出问题
还是以文章开头的问题为例，这就是典型的提出问题，而不是解决问题。
开发提测的质量不高，这是问题的表现，而不是根因。根因可能是分支管理混乱，需求描述不明确，理解误差和人为误操作。
遇到问题时我们要做的，是发现问题的表象，分析背后的原因，找到痛点，然后再提出可行的方案。
不断思考，不断探寻问题的本质。从更高的维度，寻找更大范围的更优解。有时候跳出问题，后退一步去思考问题，反而能找到更大范围的解决方案。
解决问题的方式不止一种
还是文章开头的问题为例，这个问题背后的根因也可能是需求多工期短资源紧张，这个时候大家最大的痛点是按时交付，而不是高质量交付。
质量保障是有成本的，范围、时间、成本，在不同阶段要做不同的权衡和取舍。测试同学应该学会根据具体情况灵活调整策略。如果是上述的原因，解决问题的策略可以如下：
- 识别并守住质量底线；
- 基于风险制定测试策略，保证核心业务可用；
- 及时暴露风险，寻找应对风险的冗余方案（比如灰度发布或者hotfix）；
- 识别问题背后的原因，制定渐进式的改进优化策略，并持续推动改进落地；
当然，如果资源足够，有较多的成本预算，则可以选择规范流程、提升基础技术设施建设、推动产品明确需求范围、做足够的测试覆盖等策略，来保障交付质量。
一切都是取舍，抓住最核心的问题，解决当前最大的痛点，管理好预期目标。
