通过流程和规则来管理团队，规则只会越来越多；通过目标和价值观来统一团队，繁文缛节才会越来越少，最终形成团队文化
——xx.仁波切
去看了小龙饭否的日记，心中也有所感，在朋友圈发了这段文字，然而就像奥特曼变身只有1分钟，仁波切的状态只能持续一小段时间，回到现实生活，苦逼的生活还在持续，写测试报告的时候，心中痛苦的思索，哥辛辛苦苦推动了各项流程，加固了各条防线，然而问题还是好多。
现在一般项目来说，总有提测规范，测试规范，上线规范等基本规范，而对于一个新项目来说，规范的建立往往是现实而迫切的，项目组成员背景不同，可能来自不同开发部门；人员组成各异，有开发、QA、前端等角色；大家在一起沟通交流以及做事都需要有一套流程去规范和约束，所以，流程诞生了。虽然有了流程，但是很多人员做事或者交付的产物与标准相差甚远，于是就要制定规范，来保证流水线上每个人都能交付出合格的产品
实行了一段时间，流程跑起来了，规范执行下去了，然而总有一些情况与当初设想有出入，就像代码逻辑写的不够完善一样，我们看着流程和规范在执行，就像看着程序代码在不断执行一样，还是有些成就感的：这套系统终于引导团队正常运转了。有一些不完美的地方，通过改进流程和规范，打一些补丁，让它更符合项目特点。
如同代码跑到了一个没处理的异常分支导致程序崩溃了一样，系统总是会遇到一些处理不了的情况。比如规定了上线版本必须经过QA测试，晚上需要紧急上线的时候，原有流程和规范回答不了这个问题。那就需要再加一套紧急上线的流程在里面。当面临越来越多各种情况的问题的时候，就需要添加更多的流程和规范，同时要维护这么多的流程和规范。
回头想来，其实有很多问题是通过流程和规范解决不了的：
-
流程和规范限制了团队人员的创造力。如果团队里每个人都清楚自己的角色和职责，都能为自己的所做负责，大家相互信任，就不需要什么流程和规范了，然而考虑到少部分人拖后腿而制定了流程和规范，其实也就限制了大家的灵活性和创建性。
-
流程和规范本身不产生价值，比如提测版本质量差的问题，QA通过提高提测准入门槛看起来似乎能让开发去努力提高版本质量，减少测试花费时间，但是却没有回答如何让开发更有效率的去达到这个目的。
所以之前我也对此有所思考：
如果一个项目需要30天，开发每多花一天进行自测，测试的工作量就能少一天的话，或者说开发少在自测上花费一天，测试就要多测试一天的话，那么不管开发自测不自测，项目总时长是不变的，讨论的焦点就是如何分配工作量，由于"公认测试不创造价值"，则开发不自测，而测试时间拉长。
实际情况是需要考虑在哪边发现BUG成本最低，通过代码审查、开发对一些场景进行自测能够花费较少的时间来提高质量以及大大减少整体测试的时间，从上帝的视角来看，项目的交付时间因此缩短，应该是有益的举措。大家都说，有益的事情是原本不需要推动的，但是为什么推动开发改进质量那么困难，是因为从开发看来，自身的效率因此下降，而没有觉察什么益处；而测试则觉得对质量有帮助还能减少测试时间，大力推进。
很多时候QA去审视开发，预设开发是懒惰、易于犯错、意识差的，会制定一些带有防火墙性质的流程和规范，将问题墙在外面，而不是真正去解决，所以很多流程规范虽然在实施，最终只爽了自己，但并未被广泛认同和接受。
未来的工作，必然需要从消极防守转变为主动进攻，为团队灌输质量的意识和价值观，挖掘和培养开发的潜力，让大家能够自由发挥能力去达到提升效率和质量的目标