最近在看麦肯锡工作法系列的书籍, 看完之后, 有一些感触, 这类书都不厚, 随便看一本就能了解, 我也就不累述.
不过, 麦肯锡工作法实践的工作, 都是针对商业咨询类的工作, 这里, 我尝试将它应用到我们码农的工作中来. 麦肯锡工作法最大的特点, 就是善于使用框架思考工具, 其中我最有感触的有两个, 一个是四象限工具, 一个是金字塔模型, 这两个都可以作为商业决策的辅助工具.
我们的日常工作, 通常大脑都是简单线性思考模式, 我们所采取的决策, 都是根据某一个单一的变量来定, 而四象限工具则是通过两个方向的变量来做决策, 这两个变量, 至少一个是跟效益有关, 一个跟成本有关, 通过互相博弈来做效益成本比最大的决策. (事实上, 我们还能通过更多维度来做决策, 但事实上, 人脑关注度有限, 太多的思考维度, 其实会顾不过来)
这里是我定义的进行开发方案选择的思考工具, 一个方向是复杂度/难度的判断, 一个方向是效用的判断, 指的就是开发的产品成果. 开发中遇到某个特别复杂的功能, 那么, 就会有几种参考方案: 比如找第三方库, 自己从头开发, 在已有的功能中补充, 甚至于放弃这个功能也是一个选项. 将这些选项填入4个象限中, 然后根据自己的实力和项目需求选择一个方案. 随着项目的不同, 可能不同的方案, 都会是不同的定义, 比如使用第三方库, 如果在时间紧急的情况下, 是一个相对比较优的选项, 但是, 如果在代码统一性要求很高的项目, 使用第三方库可能就是一个相对比较差的选项. 同样的, 很多开发过程的决策思考时刻, 都可以采取四象限工具进行快速的判断工作.
另外一个工具, 就是金字塔工具, 将信息通过金字塔模型明确的展示出来, 而非简单的通过主观对比来思考. 金字塔工具, 其实未必需要仔细画出来, 自己在草稿纸上简单写一下即可, 有时候大脑过一下即可, 这其实是一种工具, 让人从最初的思考里就觉得问题可能不会只有两个方向. 要画出金字塔, 至少有三个可能的判断, 这样, 通过金字塔, 会更加让自己的思考变得完备起来.
比如上图就是我在开发过程中发现的Bug来源判断, 我们在遇到Bug的时候, 有时候会陷入不知所措状态, 因为这个错误可能我们是意想不到的, 找不到根据也找不到网络参考, 这时候, 对Bug的分析, 就得自己进行判断. 那么, 我会根据自己日常的经验, 判断最多Bug发生的可能性, 比如, 最多概率的是入口的数据有错误, 那么, 我的第一反应应该是assert判断不够之类的决策; 然后发现数据是正确的, 那就判断数据处理是否有错, 比如本来a=b+1的代码写成了a=a+1这样的失误; 然后是逻辑结构错误, 看看自己的算法是否有逻辑上的漏洞, 比如漏判断某些极端情况, 或者逻辑本身就不够完备等等; 再然后就是依赖错误, 问题的产生不在当前的代码中, 而在某个其它的依赖代码段中, 这在一些不完善的第三方库引用的包造成的错误是常有的; 最后就是原生错误, 可能是系统或者语言本身的bug造成的, 这种错误概率比较小, 放在最后判断.
通过这样大概形式的表达上, 心里就会有一个底, 再次遇到不可理解的Bug的时候, 知道先从哪个方面判断, 再去哪里, 可以减少判断的时间成本.
上面只是两个使用麦肯锡工作法的两个例子, 仅供参考, 因为对我自己有帮助, 所以写出来, 也许会帮助一些人, 没有绝对对错意见.
