什么是结构化思维方式?
结构化思维简单来说就是,面向问题的时候你可以通过某种结构,把它拆解成一个个你能解决的部分。
举个很常见的例子来感受一下,假如你作为一个面试官,面试的时候,让候选人思考一个淘宝购物车功能,需要怎么测试?你可能会得到很多的答案:
比如有些候选人会回答,先添加购物车,后删除,查看数量是否正确;
勾选购物车,看价格是否计算正确;最多可以添加几个商品等等。
计算下优惠券能否正常使用
……
这些答案,可能对,也可能不对,但是大多数时候,都是基于我们的测试经验来分析问题,不一定能保证想清而且想全了。那么如何用结构化思维来更清晰更全面的分析这样的问题?作为测试工程师,其实我们都知道,测试的分类大抵可以分为:界面测试/功能测试/性能测试/安全测试/异常测试/兼容性测试。那如果我们从测试分类上对这个测试分析进行拆解,无非就是这几个测试分类怎么测,然后在各个分类上做细化,直到不能再拆解(如下):
以上就是一个简单的用结构化思维来分析问题的过程,我们在写测试用例或者梳理测试点的时候也可以应用,通过按测试类别进行拆解,不仅能把事情讲全,而且分析的还相对比较清楚。
由此可见,结构化思维是一种从无序到有序的思考过程,这个过程中,你可以建立一个先总后分的立体化分析方式。先看能够解决问题的关键方面,然后往下分析,从而实现从全局到局部的鸟瞰,而不仅仅拘泥在一种细节里面。而这种常见的思维方式,其实就是一张金字塔的树状图,如下:
为什么测试工程师要学习结构化思维方式?
工作中,软件测试工程师需要面对的不仅仅是能够独立承担复杂产品或者模块的测试工作,还需要不断的去横向或者纵向与不同的角色沟通交流,面对复杂项目的时候,甚至会跨角色边界进行项目管理,流程把控,客户对接等等。
比如面对同一个问题,有的人能用三句话直击要害,而有的人可能30min也说不到核心;面对一个复杂业务模块,有的人能够快速有层次的做一次测试点的分析和组织一场高效的测试用例评审,而有的人却在测试分析上归纳混乱,导致用例评审不断在拖堂……工作中这样的例子举不胜数,那这块的思维差异体现在哪里呢?最根本的原因,在于有没有形成快速有效的处理信息的方式,以及对信息逻辑结构的梳理和清晰有效的表达。
举个例子: 在一次处理线上事故中,有一个测试的同事急冲冲的跑过来汇报说:“发现之前的代码有问题,某些数据推动到另外一个平台上了,现在改的话影响很大,是不是找另外的时间去改?”
当你收到这个信息的时候,你可能会产生一些问题,比如影响很大是多大,后面找个时间是多长时间?同时你作为消息的接受者,你可能得到的信息只是你的同事发现了一个问题,但是并没有获得事件来龙去脉的详细信息以及具体的处理方案。
而这样的场景在我们的生活和工作中历历在目,因为没有有效的处理信息以及有效的表达,导致沟通过程中信息的不对称,沟通成本的不断增加。
由此可见,结构化思维在我们的日常工作和生活沟通上显得尤为重要,复杂问题通过金字塔模式的一层一层剖析,可以非常清晰并且有条理的对外展示你的想法和思维逻辑,从而提高我们处理问题的效率同时又降低了沟通成本。
如何提高结构化思维?
当我们逐渐揭开结构化思维以及了解它的作用以后,我们会想,结构化思维能够训练和提高嘛?答案当然可以!当然我们需要更进一步分析金字塔模型。如图:
在金字塔结构中,总体上有两个方向的逻辑关系,即纵向逻辑关系和横向逻辑关系。一个好的金字塔结构,需要在纵向关系上满足结论先行、以上统下;在横向关系上,满足归类分组、逻辑递进这四个基本原则。用一句话概括,就是“论证类比”。
纵向:纵向是层次关系,上一层次思想是对其下一层次思想的概括,下一层次是对上一层次的解释和支持。
横向:横向是关联关系,每组中的思想必须属于同一逻辑范畴,必须按照逻辑顺序组织。
在对金字塔结构的进一步梳理后,我们可以将结构化思维能力归结为如下三点:
1.归纳信息能力--横向类比能力
海量信息的收集并不能完全帮助我们分析和解决问题,归纳信息有助于帮助我们的大脑记忆,梳理逻辑和思路。
下面推荐一个分类法则:
MECE法则(Mutually Exclusive Collectively Exhaustive),即相互独立、完全穷尽。分解问题时运用MECE原则可保证形成的观点最清晰、最完整,不重不漏。
其中常用的方法有6种,我们其实在工作中也经常应用:
1、二分法
这个分类方式在日常生活中比较常见,其实就是把信息分成A和非A两个部分。比如:
国内、国外,他人、自己,已婚、未婚,成年人、未成年人,左右,男女,收入和支出,专业和业余等等。
2、过程法
也就是按照事情发展的时间、流程、程序,对信息进行逐一的分类。比如:
在日常生活当中制定的日程表,解决问题的6个步骤,达成目标的3个阶段,其实都属于过程分类。 过程分类法特别适合用于在对项目进展和阶段的汇报上。
3、要素法
我们在生活当中也经常会使用到要素法,这种分类方法是用于说明事物的各个方面特征的。比如:
说优秀员工的7种品质、公司的组织架构图等等,其实都是把一个整体分成不同的构成部分。可以是从上到下,从外到内,从整体到局部。
4、公式法
公式法就是可以按照公式设计的要素去分类,只要公式成立,那这样的分类就符合MECE原则。比如:
价格=单价*数量,按照公示,单价和数量即为要素
5、矩阵法
比如我们在安排工作的时候,有一种分类方式,是把你的工作分成以下四种:1)重要紧急,(2)重要不紧急,(3)不重要但紧急,(4)不重要也不紧急。
然后可以把它们填到4个象限当中去,这4个象限就是2×2矩阵。 这种分类方式就叫做矩阵法。
6.特定场景的分类法则
对于大部分情况来说,MECE法则是一个较为通用的分类法则,但在某些场景下我们还有更直接的模型,可以把现有的信息,分类放到一些分类模型当中去。
3C(市场战略模型):即公司(Company)、顾客(Customer)、竞争对手(Competitor)三个英文单词的首字母。按照这三个要素进行战略归类的时候,就可以防止公司出现忽视用户需求、市场行情,自顾自去开发产品,导致血本无归的情形。 “7S”(思考组织战略模型):即经营策略(Strategy)、组织结构(Structure)、运营系统(System)、经营风格(Style)、职员(Staff)、组织技能(Skill)和共享价值观(Shared value)。 SWOT模型(竞争力模型):SWOT分析代表分析企业优势(Strengths)、劣势(Weakness)、机会(Opportunity)和威胁(Threats)。 SMART(制定目标的模型):即制定目标要满足确定性(Specific) 、可度量性(Measurable)、可实现性(Attainable)、相关性(Relevant)和时效性(Time-based)等等。
针对以上的分类方法我们不一一例举,那我们如何在我们的职场中应用这些分类法则呢?
举个例子,最近系统不稳定,连续出现了一些比较严重的P1故障,老板让你组织开一个全员大会,提升大家的质量意识。你准备发出一个会议通知:
为了提升质量意识,召集大家在10月22日下午3点在3号楼205培训室召开全员大会。会议议程是首先复盘一下最近故障出现的原因,然后制定策略防止类似故障再次出现。目标是为了在下半年不再出现P1故障,确保线上系统稳定性。
然而,这个内容不够清晰,更好的做法是可以使用5W2H模型对内容进行结构化的表达:
目标:提升全员质量意识,下半年不再出现P1故障。
时间:10月22日下午3点。
地点:3号楼205。
议程:1)故障复盘。2)制定故障防控策略。
对比两个会议通知,不难发现,特定场景下,5W2H的结构让我们的表达更有条理,更加清晰。
2.提炼信息结论的能力----纵向论证能力
当我们归纳到所有信息,我们如何加强提炼信息结论的能力?这个其实就是展示了金字塔模型中纵向论证到能力。
在提炼信息结论的能力中,最常用的有两个方法,这两个方法在很多书中都有介绍,下面简单介绍一下这两类方法。
1.演绎法
演绎是一种线性的推理方式,最终是为了得出一个由逻辑词“因此”引出的结论。在金字塔结构中,位于演绎论证过程上一层次的思想是对演绎过程的概括,重点是在演绎推理过程的最后一步,即“因此”引出的结论。最经典的是亚里士多德的三段论:
大前提:所有人都会死。 小前提:苏格拉底是人。 结论:苏格拉底会死。
在日常工作中我们也经常会用演绎法去总结结论,比如:
已知规则:需求频繁变动容易导致bug
具体事件:快上线了,业务方要加需求,加不加
结论:不加
用演绎法我们需要注意的是:
常常对规则持怀疑态度(规则是变化的,规则不对则结论不成立) 。
需要增加知识量,使其保持“可用状态”(已知规则越多,则越容易得出结论)。
2.归纳法
归纳逻辑比演绎逻辑要难,因为归纳需要我们有很好的抽象能力,抽象出新的概念,去统领其下面的子概念。在归纳的时候,大脑去要去发现事物(思想、事件、事实)具有共性、共同点,然后将其归类到同一个组中,并说明其共性。归纳逻辑不是线性的,它需要在已有信息的基础上,提升一个抽象层次,得到新概念。比如:
苹果和橘子的上一个抽象层次是“水果”,这种抽象层次的提升,可以让“水果”在纵向关系上统领苹果和橘子。“水果”这个新概念的抽象需要我们具备相关的知识背景。
在了解归纳法的逻辑以后,我们应用的时候需要注意:
摒弃思维定势,认真选取样本(样本是否有代表性,数量是否足够多)
需要增加经验,扩大势力范围,多看,多吸收,增加事实。
3.表达信息的能力----自上而下
思考是一个隐形的过程,最终我们要将结论显现出来,这就体现了结构化思维中表达信息的能力。
我们在日常沟通中经常会出现如下的误区,很多人会在毫无意识的情况下把自己的思考过程直接传递给对方,举个例子:
在某一次会议中,你跟你的领导反馈说:“我发现最近技术支持那边提出的登陆问题咨询量有点多,我猜测可能是登陆功能出现了问题,然后我让同事排查了一下,发现是xx 迭代,xx误操作导致了接口登陆报错。因为这个问题很影响用户体验,因此需要尽快让xx去解决。"
咋一看貌似没有问题,把过程中的所有细节都跟你描述清楚了,但是在汇报的过程中看似合理的由依据到结论到输出,使得阐出框架相对比较单薄,重点结论没有突出,信息的接收者不能立马有效的识别你的重要信息。
假如我们用结构化思维去汇报这件事,会变成:
1.先提出结论:目前登陆接口有问题,导致线上bug,已经找到原因,需要xx尽快解决
2.再具体阐述:出现问题的原因是xxx,这个问题已经持续xx天,非常影响用户体验,这几天技术支持已经产生好几个类似问题的咨询。
3.最后总结:因此一定要快速解决,尽量今天把问题解决。
相比之下,自上而下,有结构的表达,从结论到依据再强化结论的过程可以让信息的接收者快速获得你想要表达的信息,并使得你的结论更具有说服力。
那如何训练自上而下的去思考和沟通呢?下面给几个小tips:
我们可以灵活的运用现有的一些模型框架,比如问题-原因-解决方案/SWTO等等,快速的套框架进行逻辑化思考和沟通。
可以将自己的表达逻辑可视化,比如一句话的描述等等不断去强化自己的语言和逻辑输出,提高自己的沟通表达能力。
如果觉得《软件测试之结构化思维方式》对你有帮助,请点赞、收藏,并留下你的观点哦!