一个非常宽泛的,没有标准答案的问题,而它的答案却又是个人综合素质中极其重要的一环,直接考验个人思维的清晰和条理性。
1. 前言
数年前完全重构自身的整个思维体系以来,一直保持着对人类认知学这一块的浓厚的兴趣,期间也是阅读了诸如《暗时间》,《刻意练习》,《程序员的思维修炼》,《精进》,《把时间当做朋友》,《如何有效阅读一本书》等经典之作,并与自身的经历进行对比验证和反思,也确实得出了一些比较自洽的逻辑答案并遵循至今。这些答案暂时性地终结了笔者关于"为什么要努力?",“如何努力?”,“如何确信自己的努力最终一定能够有所成就?”等问题多年的探索。
但是这些逻辑答案只是一些指导性规约,属于"道"层面上的技巧,而对其细化而衍生出的一系列问题的答案的追寻却并不见得会轻松多少,本文标题中表明的问题则是比较典型的一个。
2. 中心思想
关于中心思想这块,我们秉承少而精的原则,条目太多将导致大量精力被浪费在记忆上,也会造成使用上的模糊。
- "大胆假设,小心求证"。
- ”小步前进,频繁测试“。
- “无监控,不优化”。
3. 大致流程
3.1 获取问题的上下文( Context )信息。
- 问题是什么?
- 是否可复现?如果不能,能收集到多少相关的信息,以及是否保留了问题现场。
这一步是解决所有问题的起步阶段,也是最重要的阶段之一。
一般情况下,如果这个问题是你本人亲身经历的还好说,因为你对问题产生的背景相当了解,自然能够比较精确地划定出问题可能发生的范围。
但往往你是作为救火队员被指派到一个灾祸现场去协助甚至指导解决某些已经被认证为比较复杂的问题,这个时候你首先要做的是通过观察,少量测试,以及与相关一线人员反复沟通等方式尽量详尽且准确地获取关于问题的第一手上下文信息。
这一步很难,很多人的交流能力属于自说自话的阶段,他们往往只是站在自己的角度去陈诉问题,所提供的信息中经常隐含着大量的假设,因此你需要通过反问,简单地测试等方式来对其提供的信息进行过滤,补充,细化,尽量还原问题的第一现场,为之后问题的顺利解决打下坚实的基础。
这一步要兼顾详实和高效,问题的时效性决定了距离其越近,解决成本越低。
3.2 分析问题产生的原因
在确定了问题的上下文之后,接下来的一步就是确定问题产生的原因,这一步将直接关系到问题的解决,因为往往确定了问题产生的原因之后,问题的解决基本就是顺理成章的事情了。关于这一点也是可以套用经典的二八原则的——我们通常花费80%的时间来确定问题产生的原因,而只用20%的时间来解决问题。
3.2.1 第一步 :从过往经验里找类似的,相关的案例
解决问题的第一步是尝试从过往经验里找类似的,相关的案例,以期获取直接的解决方案。这个极其考验当事人对于问题的抽象能力——将问题由点抽象为面,将遇到的特例问题抽象为一个抽象的系列问题。关于这一点的典型例子是《暗时间》一书中多次提到的"治疗恶性肿瘤与军事攻坚战之间的异同"的例子,其深刻说明看上去千差万别的问题的表象下隐藏着同样的本质,而能够看透这个本质直接决定你解决问题的能力强弱,这需要天分,但也需要大量的刻意练习。
3.2.2 第二步:步步为营缩小范围,最终定位原因。
往往能在第一步解决的基本就是个"活久见"的问题,也就是所谓的工作经验。
而事情一般不会这么顺利,所以接下来我们要借助以往的行业经验进行大量的测试验证工作,以期不断缩小问题的规模,直至定位问题原因,这些经验包括:
- 大范围的修改尝试让问题不再出现并解决。
这一步一般是在把握比较大,或者"专家直觉"比较强烈的时候使用。(注: "专家直觉"这种说法借鉴自《程序员的思维修炼》中的"专家做事靠直觉",感兴趣的读者可以翻阅下这本书,好处大大的、) - 小范围的修改尝试让错误发生变化或解决。
这一步暗暗契合了上面"中心思想"中的"小步前进,频繁测试"这一条。也是主要的问题定位方法。
以上这两种方式要求我们:
- 先对问题产生的原因进行一次清单式的穷举,并针对清单中的条目所要验证的内容以及可能产生的影响和预期的结果进行简要的思考。这一步不可不做,但也不用耗费太多的精力。一来时间宝贵,二来问题的原因是逐渐浮出水面的,我们无法做到未卜先知。
- 搭建快速反馈环境。这一步的重要性如果读者认为只是比较重要的话,笔者可以说下自己的看法:这一步与问题解决本身同等重要,甚至可以更高,得到快速反馈的过程不仅仅是验证你的想法,也是不断刺激你继续探索的动力,这是对于人性的掌控,笔者亲眼目睹很多研发人员以没必要为由,宁可闷口去碰运气,也不愿意停下来把测试环境整理下。这里笔者借用《软技能2》里的一句话:"不要告诉我你没时间/没必要,你要诚实一点对我讲:'如非得以,我并不想解决这个问题!' "。
- 熟练掌握多种工具。以砍树为例,如果你只会用斧子,那相比较于熟练掌握链锯,镰刀等多门工具的人说,效率肯定是不可同日而语的。
- 熟悉一些行业内的基本原理,也就是职业素养。以软件开发行业为例,对于HTTP协议,TCP/IP协议等的深刻理解看似没啥用,但往往在一些诡异或难以解决的问题面前,这些知识能够大幅缩小你所面临问题可能的规模,做到精准打击。
- 每一步行动都要进行记录,如果时间确实比较紧迫那也要简要的提示性信息,方便之后的问题复盘以及通过站在全局的角度审视所有已采取的行动的结论来发掘隐蔽的关联信息。
3.3 解决问题
如果上一小节被完成之后,这一步基本就是顺理成章的事情了,而且到了这个阶段,所有人的心理和精神状态将会得到比较大的放松,这也有助于更优方案的提出。
4. 忌讳
说明了套路的大致流程之后,最后让我们列举下常见的反面行为:
- 无头苍蝇,没有计划。典型的就是东猜一个原因,西猜一个原因,然后就着这个猜测的原因去准备一堆解决方案,并且在该解决方案没有被实际验证的情况下,执行下一个解决方案的实施。对此笔者曾经亲身经历过一个,两分钟一个主意,然后也不测试和验证,又猜出一个方向,继续所谓的优化,结果搞了一个多月所有人人困马乏,军心涣散。
- 反馈时间过长。正如上面所描述的套路中,大量的时间都是在猜想并验证,而如果获取验证结果的时间过长,将极大降低问题定位的速度和人员士气。
5. 范例
参见 实战 - 解决问题的套路
6. 最后
好吧,其实对于本文,笔者很早之前就有尝试总结的意向,但因为懒惰等原因导致迟迟难产,而最近受了一些刺激,仓促之间才给肝了出来,不免有遗漏和错误之处,而且这仅仅是一家之言,非常欢迎沟通探讨。
关于本文相关的示例,笔者目前正在进行整理,有机会的话会在之后进行补充完善。
网友评论