写于2018-5-4
丰田生产线上遇到故障会使用五问法，追溯问题源头。
为什么车门出现这种缺陷？因为螺丝没有拧紧？
为什么螺丝没有拧紧？因为工人不敢用太大的力气。
为什么工人没有用太大的力气？因为没有扭力扳手，力度没有明确指示。
为什么没有扭力扳手？因为五个人只配备了两把扭力扳手，没有机会使用。
为什么五个人只配备两把？因为扭力扳手很贵，生产部门不知道会出现这种故障，从节省成本的角度考虑，没有给每个人都配备。
最终的解决之道，就是明确向生产部门提出需求，要求给每个人都配备扭力扳手。
在这之前，无论是要求工人拧紧螺丝，还是要求工人每次用适当的力气，或者是要求大家轮换用扭力扳手，都没有解决问题的根源。
5w很关键一点是问题的定位。
以下是真实例子引用
第一版本：
为什么交易状态获取失败？
因为爬虫失败了，没有结果返回
为什么要自己做爬虫？
因为找不到更好的交易状态数据，网上没有开源接口少。
为什么api少？
因为行业早期少，人才涌入少，节点需求少。
为什么不自己做节点？
因为节点需要go语言的程序猿，需要花时间专研。所以目前只能用爬虫。
版本二：
为什么客户端交易详情获取失败了？
因为爬虫失败了。
为什么爬虫失败了？
因为对方反爬虫机制识别了ip。我们不是专业做爬虫的。
为什么要做爬虫？
因为用户需要在客户端查看详情，而我们自己暂无资源做数据节点。
为什么客户端详情要自己提供数据？
因为产品设计稿是这样的。
那么为了满足用户的查看详情需求，我们分析几个技术实现方案的利弊，最终回到用户根本需求上去解决问题。
而版本一的问题定位在技术上实现上。版本二的问题定位在方案的方向上。
所以此处五问最终要回归到问题的本质上，利用最合适的方法解决问题。
跟设计、程序猿沟通时要通过多问几个为什么，了解实现人员的能力和方案限制，再去解决根本问题。
不同的实现方案，可能实现同样的结果。
所以需求功能，要的可能是用户指标和营运指标，假如用其他已实现的功能已经可以实现了他要的指标，那就暂时可以缓下。
网友评论