什么是科学的思考
- 发现问题
- 分析问题
- 得出假设
- 进行证明(收集证据,实践调查)
- 得到结论
这个过程看起来,感觉清楚明白,但是大部分人没有做到,因为有很多误区
对思考认识的误区
思考就是脑子里的想法
这种情况是说话不带脑子的表现,比如
问题:大家最近迟到比较多
结论:应该严格要求大家减少迟到
根本没有思考大家为什么迟到,所以严格要求的效果不一定好
现象就是原因
某种现象只是问题的表象,而不是真正的根源.
比如生病发烧,高烧是病的表象, 而不是原因,仅仅吃退烧药是不会治好病的
假设就是结论
假设只是我们对问题原因的猜测,是否准确,就不一定了.可能很多时候,我们会说,自己的假设都是根据历史经验得来的,但是面对未知的问题,我们的经验未必有效.
书中思考的例子
问题: A公司的市场占有率太低14%
收集数据分析: 市场覆盖率70% 得标率20%
得出原因:得标率太低 (错误, 此时,得标率太低是一种现象,并不是原因, 妄图通过各种方法提高得标率,是不可行的,因为并不知道为什么得标率低)
问题:为什么得标率低
收集数据和不同业务的业务员沟通 分析: 部分业务员得标率80%, 业绩好的业务员随机应变的沟通能力强
得出结论: 业务员销售方法不对,需要培训(错误, 销售方法不对目前仅是假设, 不是结论,销售方法是充分条件,而不是必要条件,盲目的培训销售方法不一定可行. )
印证假设: 跟随业务员实际销售流程, 发现业务员还有谎报业绩,偷懒
得出结论: 需要加强业务员管理
解决方案: 淘汰末位业务员, 取消固定薪酬, 根据销售情况奖励业务员
应用总结
要充分掌握这个方法,需要在思考实践的过程中不断的问自己以下问题
- 得出的结论是现象,还是原因?
- 得出的结论是假设,还是真的结论(有充分的证据吗)?
- 解决方案是什么?
随便拿个问题尝试一下
问题: 延期bug太多?
分析: 延期的bug大概有3类
1. 和本次上线功能无关的其他功能模块bug, 因为之前的项目未测试出来或者已经延期过
2. 是本次上线功能bug,但是偶现,且不太影响功能使用
3. 最后发现没时间处理,且不影响功能
第一类最多, 所以第一感觉就是我们应该减少第一类bug, 但是第一类bug多只是现象,不是原因,所以我们需要继续分析为什么第一类bug多
问题: 为什么第一类bug多?
分析: 未测出来的bug都是没有按标准流程进行操作,这些过程没有记录在测试用例里,大多是QA以用户角度模拟操作产生的,
从QA的角度看,不可避免,因为测试用例不可能包含所有可能的操作.所以就无法一次就把所有问题都测试出来.
这些问题,大多是代码部分逻辑不完备造成的,即有漏洞
得出结论: 第一需要完善测试用例,避免遗漏用户的可能操作习惯, 第二 完善代码的评审和测试,减少代码漏洞.
这个结论是假设还是结论呢? 我觉得是假设, 我没法证明采用这样的方案可以有效的减少延期bug
接下来应该是印证阶段, 考虑做以下几件事
1. 复盘测试用例和延期bug,是否真的有完善的空间,足以增加bug的曝光率
2. 完善某些bug相关代码的评审和测试,确认是否可以减少bug的产生
3. 分析多个项目延期bug的具体情况,看是否有其他问题没有发现
如果觉得不足以降低延期bug,就需要在上述过程中,继续分析为什么不能降低,反复进行 假设 印证 结论的过程,最终得出结论.
如果假设成立, 则还需要继续分析为什么测试用例不完善?为什么代码有漏洞? 最终得出如何完善和如何减少漏洞.
感觉有点像我们常说的,凡事多问几个为什么? 但是更加具体可行,因为加入了现象和原因的区别 假设和结论的区别
