小米团队深谙系统分解的要义:完全穷尽、相互独立(MECE),至少要看上去如此。MECE,麦肯锡公司这条闻名于世的原则,实则是一整套严苛的系统分解方法论。在其指引下,我们有可能非常缜密的将难题分解,降
小米团队深谙系统分解的要义:完全穷尽、相互独立(MECE),至少要看上去如此。MECE,麦肯锡公司这条闻名于世的原则,实则是一整套严苛的系统分解方法论。在其指引下,我们有可能非常缜密的将难题分解,降低问题的复杂度,并最大程度地保证分析结果的可靠。但是,我个人认为这种方法有点过于强调表面的逻辑性,而可能部分牺牲了问题解决的实效性。以下几个关键问题需要细细考虑一下:
1 “完全穷尽”对于问题分解来说是必须的吗?
2 “相互独立”对于问题分解来说是必须的吗?
3 分解的根据是什么?或者说,我们基于什么标准、尺度对问题进行分解?
第一个问题。有些时候,过于看重完全穷尽原则,会影响问题解决的实效性。举例来说,对某一产品的用户进行分类(或构建人物角色)时,通常都不要求穷尽所有用户,比如某研究中发现数码发烧友、时尚达人、商务精英对于某产品是三类主要角色,于是,分别深入了解这三类角色就可以满足产品设计的大部分需求。但是如果我们在研究中追求完全穷尽的话,就可以把用户简单地分成:18岁以下、19~23岁、24~29岁、30~35岁、36~45岁、46岁以上,这种分类虽然满足了完全穷尽,但是却对解决问题没有太大的帮助。
同理,对于第二个问题,由于各种现实系统的复杂性,系统之间的各部分之间很少是可以相互独立的。就拿刚才的例子来说,有可能有些用户兼具数码发烧友和商务精英两种角色,但是这并不妨碍我们做如上的划分,因为这样的分类确实是卓有成效的。并且,如果我们真的找到一个角度将原本复杂的系统分解成若干个独立的部分,那么系统复杂度可能只是轻微地降低,因为系统分析中真正令人头疼的部分——复杂交错的相互关联性——并没有消失,而是降到了系统的下一个层级,当我们对下一个层级进行分析的过程中,还是要处理相关的棘手问题。
对于第三个问题,鉴于完全穷尽、相互独立不是硬性要求,所以分解的方式其实会有更多的可能性。分解的根据可以分为两类:一种是通用分解方法,另一种是基于对系统(或问题)的深入理解自行提出的针对性的分解方法。通用分解方法可以理解为是一些思维启发式,例如5W1H、SWOT分析、波士顿矩阵等。思维启发式的效果立杆见影,但是更应把它们作为思考问题的一个突破口,而不要作为最终的问题分析框架,因为越是通用的框架越无法深入地、针对性地逼近问题的实质。第二种则对思考者提出了更高的要求,它逼迫思考者不断地去重新定义问题、分析问题的本质以及尽可能多地掌握问题相关的知识。对于第二种分解方法来说,分解的过程已经接近于问题解决的过程,当分解完成之时,问题其实已经解决了大半。在我个人的观察中,我发现大多数人仅满足于用第一种方式(现成的框架)去分解问题,这种思维惯性阻碍了通向更强大思维能力的道路。
总之,虽然将问题分解是众所周知的最为基本的系统思维方法,但是,软件过程也是需要一个时间段的,如何严谨、有效地分解问题却是一个非常恼人的难题。而努力将分解之惑逐渐消解,正是系统思维修炼中必不可少的一环。