2009年的时候写了一篇" 解决问题:心态 原则 方法 ",那么快就3年了,今天继续这个话题,把我解决问题的心得记录分享一下;下面的内容来自我平时的笔记,我按照问题解决的过程,重新整理了一下.
从准确的描述问题开始
问题是什么?形式上/直观上的描述
描述的过程中,发现逻辑上说不过去了,可以发现盲点
排除干扰因素,明确问题关键点和 包含的概念
问题的背景?(这是一个通用的问题还是特定背景下的问题?)
2012-10-7 20:23:36 更新
假期的时候读《人性的优点》其中提到了如何有成效做会前准备:
- 究竟出了什么问题?
- 问题的起因是什么?
- 这些问题可能有哪些解决办法?
- 你建议使用哪些办法?
问题解决过程
不要偏离问题主线,我目前的理解是什么?
我现在有哪些线索?
我们本来就是从一无所知的起点来到这个世界,失败很正常现象
处理失败的积极意义就是一个不断调整,纠正,自我强化的过程
爱因斯坦说愚蠢就是用反复用相同的方法做同一件事情还期望不同的结果
问题解决之后
以前在问题解决之后就感觉如释重负,抛到一边,现在会感觉问题解决了只是一个开始,因为遇到的问题代表着知识上的盲点;解决过程中走的弯路代表思维方法有待改善;
所以我现在的技术文章里面,不仅会记录问题的解决方案,同时也会记录自己的思考过程,看在这个过程中可以改进的地方;下面是我在解决问题之后的" 例行询问 ":
我一开始的思路切入距离正确答案有多大的距离?
我对当前这个答案是否满意?
还有其它方案吗?
这个方案怎么解决的这个问题?
这个问题之前是怎么解决的?
这个技术方案与之前的技术方案相比有什么优势?可以量化对比吗?
能不能按照解决方案出现的时间梳理一下当前这个问题解决方案演变的过程?以前的解决方案受什么制约?
这个解决方案(技术)的最佳实践是什么?
这个解决方案对开发流程,运维部署的影响有哪些?
这个解决方案的上下游技术是什么?
这个解决方案还可以解决什么问题?
这个解决方案遵循了什么样的原则\思想?
更重要的下一步
尝试把解决方案和问题解决的过程进行抽象,抽象之后才有可能完成知识的迁移过程:解决方案和解决过程中涉及到的思维方法抽象出来;这样解决方案就不再拘泥于编程语言,应用类型;
检验自己的成果
你真的有所获么?还是欺骗自己,只是走了一下思考的过场而已?
我是否可以把我解决问题的过程讲给别人听? (知识的输出:解决方案输出和思维方式输出)
在团队内分享,或者是写笔记 写博客都是很好的方法
我们能力的提高,体现在我们能解决什么样的问题
你是怎么解决问题的?有好想法,分享一下?