从根因入手，更有效率，效果也更好
在互联网产品研发过程中，经常遇到一些看似严峻的问题，但最终其实是可以轻松解决的。关键在于是否找到了“根因”，并且从根本上解决这个问题，而不是仅仅局限于问题表象，结果看似解决了，但其实并没有根治，某一天这个问题再次复发了。
最近负责了两个比较大项目的交付，过程中有做的好的，也有做的不好的，但能暴露问题总是好事，这样可以有个思考的抓手去思考。
第一件事是稳定性的事情。老板说让我背部门P2级以上故障的KPI，P2以下不背，也就是起码不能出现高级别的故障。截止到Q3为止我们部门整体的稳定性是可控的，但总会有些低级的问题出现，如果不能根治这些低级问题，说不定哪天就会酿成一个大的问题，必须重视起来。
两个case表面都是流程类问题，线上测试环境访问了线上真实资源，代码有bug触发了数据被错误修改。
这个case其实非常可怕，因为你都不确定这个bug怎么触发，而且不能通过发版记录找到并快速恢复，影响较小算是万幸。
如果把这两个case视为流程类问题的话，能做的就是流程强约束。但也有副作用，就是无形中增加了研发成本，降低了交付效率。
这两个case会不会出现在我身上呢？
我想一定不会，因为我脑中就不会想到在测试环境连接到真正环境去做数据处理，哪怕要做也会有开关。
所以我想这可能是个意识问题。但究竟是不是意识问题呢？
后来想了下两个同学经验都比较少，可能是经验和能力问题，有心无力确实考虑不全。
解法也比较干脆直接，收敛权限，没经过cr和评审的代码没机会上到线上。能力匹配，个人能力要和负责系统相匹配，杜绝不胜任系统的人负责系统。
还有一些常见的问题，比如我们经常遇到研发质量不过关、大量bug出现、导致测试时间不够、研发进度不符合预期、最终产品质量不理想、上线之后被用户触发了bug影响了用户体验，然后产研团队紧急修复bug，导致产研团队处于被动的状态。
很多人认为解决这类问题有以下几种方法：
- 增加测试时间，3天不够5天，5天不够8天，总之测试时间一定要给足；
- 增加测试人手，尽可能确保能在上线前测出更多的bug，让团队有时间来修复bug；
- 上线前严格对产品质量把控，测试用例尽可能完整，测试过程尽量完备，测试用例覆盖率达到100%，且不存在P0、P1、P2级的bug时才允许上线。
以上三种方法在一定程度上可以缓解这个问题，但只是解决了表象问题，没有从根因上真正解决这类问题。
有效的方法可以从以下两个方向入手：
- 在开发阶段不断加强代码质量管理，每天做CR。这些CR工作需要一线的开发组长亲自去给组员去做，每天下班前花半小时看组内工程师今天提交的代码，可从代码逻辑实现上评审是否有更好满足产品需求的空间。同时从代码规范上评审是否满足团队制定的编码规范，通过CR可以发现并解决潜在的问题。
- 在系统研发中，需要找到变与不变的边界，不断抽象、沉淀核心功能，保证这部分功能不会被轻易触达和修改，以扩展和插件的方式提供给新同学做业务扩展，这样既可以交付产品的需求，也可以不动核心功能，起到了稳定性和效率的完美平衡。
因为系统的效率和稳定性问题的根因在于系统的技术债，如果可以很好的解决这些债务，其上面的表象问题也就迎刃而解了。
