问题是在我们日常的工作当中经常使用的词语,部分同学对于这个词比较敏感,不愿意主动提出问题,也不愿意正视问题的存在。客观的讲,问题已经存在了,不会因为没有人提就变成不存在,反而因为有人关注问题,关于问题的产生带来的影响可以较快的感知,及时对于问题进行修正,可以有效的避免问题带来的影响累加,和规避问题的性质改变的可能。
如实的讲在工作中,团队/产品中当下的或将来潜在问题的解决过程实际上就是机会,以系统架构来说,当下的架构一切运行正常,所有的指标达到了极致,业务服务可高效的支持,这种完美的状态是几乎是不常见的,是阶段性的。既便是当下较完美的架构,也会因为外部的环境变化,潜在的问题也会显现。
所以,系统中出现问题并不可怕,可怕的是对问题的忽视,一但确定了问题的存在,想尽一切办法来解决问题是最好的方法。从机会与问题的关系来看,问题的影响面大小和机会的大小,是等比的关系,也就是说问题的大小,决定解决该问题的收益和机会的天花板。从成长的角度来看,解决问题的大小与个人能力范围应该不要有过大的差距,相对于个人的能力,问题过于简单个人的挑战不足,而问题过于复杂团队承担的风险就会增大,间接的来看一但问题失控对于个人的成长也是不利的。当问题与个人/团队的能力范围的差距较大时,问题应该及时的分发,避免问题处于长时间无响应的状态。
一个问题从发现,再到解决,至少分为,1)发现问题的表象;2)确定问题的原因;3)解决确定的问题;这三个过程。
- 发现问题的表像:以架构优化的工作为例,直接的问题主要来自于系统的行为与设计要求不符及系统内的业务需要,比如系统bug,业务依赖的能力架构不支持。而间接的问题来自于业界的相关变化,导致了对于现有系统中的业务的变化,需要进行架构的升级及适配,比如HTTP升级HTTPS,IPV4升级IPV6;
- 确定问题的原因:以问题表象来看,产生的原因是什么。表象是果,表象之后的逻辑是因。原因主要分两种,1)做了什么,产生这个这问题的表像;2)没做什么,产生了这个问题的表象。第一种主要为系统现有能力存在的缺陷,第二种主要为系统的能力的缺失。
- 解决确定的问题:一但问题确定,根据问题的产生的相关信息,进行问题的修复。这里把问题加上了“确定的”进行了修饰。问题修复的重要程度是相对的,基于表象得出的问题的定义仅限于个人的认识范围之内,并不是一个通用常识中的问题的定义,这时这个问题就很难在团队内达成共识,修正问题带来的收益就很难获得认可。
问题应该是符合团队大部分资深人员的认识的,当这个问题是团队需要解决的,并且是在个人能力范围之内可以解决的,这是问题才有可能转化机会。否则的话这个就是风险,或者是团队资源的浪费。常见的如,因个人认识原因,理解错了问题产生的原因,这时团队在解决这个问题的过程就是资源投入的浪费;
并且,一个问题的表象及背后的原因应该可以描述的,现象的存的着背后的逻辑是现象产生的原因,这个原因才是要解决的问题的关键,当这个原因没有确定,必然就会说不清楚,解决问题的思路就不是清晰的,很难一针见血的。解决问题的关键在于是否足够的了解问题的本质,找到问题产生的本质,解决了问题才是有价值的,否则的话,解决的问题仅时停留在的表面,内部的因互同样还会其它的相关的情景下被触发而产生新的问题。
同样,并不是所有问题都是需要架构的优化解决。根据问题的相关因素进行分类,找到合适的解决问题的方案,在合适的机进行问题的修复的推进,才有可能获资源的投入,并解决团队内一致达成的问题,这样问题才是机会。