思维体系---技术思维、业务数据思维、产品思维、复合思维

简介:   工作已有四年有余,从最初的亚信 到现在的 阿里。。总结了下思维模式,以个人的视角,供各位干代码的小伙伴们参考,能够深入无论 技术还是业务还是产品的本质。发现其中的规律,更好地把握自己的方向及未来。那么总的来说,我分为四种思维模式:   一、技术思维  卧槽!干代码!出bug了!没错,这就是你进步的源头。

  工作已有四年有余,从最初的亚信 到现在的 阿里。。总结了下思维模式,以个人的视角,供各位干代码的小伙伴们参考,能够深入无论 技术还是业务还是产品的本质。发现其中的规律,更好地把握自己的方向及未来。那么总的来说,我分为四种思维模式:

 

  一、技术思维

  卧槽!干代码!出bug了!没错,这就是你进步的源头。技术思维中,会对技术异常的热爱,同时会从开发工作中,发现更多的技术,甚至认为,技术是最牛逼的!从技术之中找到无上的成就感。没错,解决一个复杂问题的激动,系统上线后看着流量的注入,那份成就感,以及对于出现error时的那个份紧张,想想都感觉到激动哈哈~那么本文的主题,便是分析纯技术思维的一些优势和弊端,以及如何规避纯技术思维所造成的一些问题。

  在日常系统开发中,一般我们会是一个协作的团体,每个人都会有明确的模块,由架构师去设计、拆解,最终使项目成功上线。等时间长了,很多开发的小伙伴会觉得,就那么回事,会觉得无聊,会觉得迷茫我的职业发展,因为总觉得自己做的只是一些业务逻辑 或是 担心某项技术会不会过时,从而盲目的学习各种新技术。

  那么这里我说下个人的看法,随着时代的发展,技术一定是日新月异的,拿大数据技术而言,从最开始的Hadoop到Hive到Spark,随之商业模式的变换,流处理及中间件的技术成熟,由出现Storm、flink、flume、Kafka。。甚至到现在能看到的区块链、人工智能。。五花八门日新月异,搞的有目标的程序员变得浮躁,都要去接触一下,你不接触,就好像跟时代脱节了一样。其实,这是一份焦虑,一份不安全感,一份压力。那么我们冷静下来想想,技术虽然日新月异,但你仔细研究会发现,其本质并没有改变,无论是分布式技术也好,数据技术也好,系统技术也好,都是在基于其本质的原理,进行顺应时代背景的更新迭代,进行的优化及改造。

  拿Spark和Hadoop为例,曾经2015年的时候有些人会说,卧槽内存计算框架Spark必将代替Hadoop!那么好了,一大波人去学Spark,会用了感觉安全了。那么换个引擎呢?又来了是不是又要重新学?因为时代的发展,内存变得便宜起来,笼统的说,就是不需要MapReduce单条读写了,在计算开始时直接load到内存缓存迭代计算。这样 你是不是就不会很恐惧了?好,然后 你在调优的时候会发现,中间的Shuffle过程是不是跟Hadoop的Shuffle过程很像?也需要将中间Map阶段的结果写入磁盘,再load进行reduce拉取?那么节点和节点之间又是怎么通信的?如何拉取的? 这就是分布式原理,当你懂得了本质原理的情况下,你会发现学什么都很快? 不信? 那区块链,本人也没接触过,但是通过它的基本行为,可以判断出各个节点的全量存储 与 节点的加密运算及通信,不准确的理解是另一种形式的分布式,同时会牵扯更多其他算法领域上的。那么这样,你是不是也会很有针对性的学习,变得冷静,使事务变得可行,可探索。

  那么下来,再拿系统开发来说,很多我遇到的,在JAVA有很高造诣的小伙伴,就会喜欢抱怨,觉得卧槽,不够高大上。那么 我想问下,那你贯穿了整个系统的业务逻辑了吗?通过业务逻辑 抽象出一类的行为,形成这一类行为的技术设计及解决方案了吗?我们能为现有系统进行更好地优化吗? 很多有心的小伙伴,真的会这样做。当你真的这样做的时候,是否有对经验进行总结呢,又是否通过做了这个系统,联想到这个系统产出的业务价值,通过业务价值,再联想到整个业务本身,再通过业务本身,发现我们可以做更好地,更适用于业务发展的系统迭代,那么创新,至此开始。

  还有一种技术思维,我们对底层技术极度的痴迷,到达了狂热的地步,你注定成为此项技术的光辉支柱。你很厉害,很强大,但是可能会出现一种认知的偏差。觉得其他人做的太low,和别人交谈时,第一想法不是思考正确性,而只是因为技术本身是否牛逼,而否定。其实,任何一项伟大,都不是靠某个人去完成的,而是靠一个团队去完成的。那么如何去完成一项伟大的事情,需要的是一棒子能够互相理解、互相融合的、极度痴迷的伙伴,客观的去判断,认真的去打造的,你会发现,我们是一个集体,我们在向共同的目标前进,去做一件伟大的事情。

 

  二、业务数据思维

  业务思维上,更多会考虑到业务本身的价值,具有较强的业务敏感度。很容易从工作中发现问题,再从发现的问题重,进行统计数字化分析,观察其覆盖面或影响范围或共同点,从而抽象成形成一类的问题,进行业务梳理,从而指导产品的建设。当然,在工作中很少有纯做业务的。毕竟业务也跟市场相关。

  那么下来说下数据思维,数据思维更多的是发现数据与数据之间的关联性,事物与事物之间的联系,通过哪一类事物,我们可以通过数据处理、数据分析、算法分析等手段去应证,去推算。我见过跟厉害的数据架构师,他们甚至能说出每一个业务链路的环节及中间层的提取,甚至能从各方面去评估其影响,不得不为之称赞。

 

  三、产品思维
  对于产品思维,很多人会想到,程序员总想砍死产品经理,改来改去哈哈。。但是其实产品思维的核心在于 与人打交道、与业务打交道、与技术打交道 以及 事物的推动作用。 程序员可以很开心的去写代码,可是一个好的产品经理,需要跟业务、技术、事物本身的探索,甚至要从整个铺开的体系中,去发现及探索产品的价值,同时还要去关注产品本身对于用户的体验。这并不是一件容易的事,同时还包含同理心,与不同结构的成员交流的融合。那么产品思维,我们就可以概括为:业务本身、技能专业度、洞察力、心理学、全局观、高情商以及耐心,是一种复合的思维。

 

  四、复合思维  

  毕竟本人也是技术出身,所以对于技术的感官更加强烈哈哈。。但是如果,你能在精通专业技术的基础上,融合 技术 业务 产品 的体系化思维模式,我称之为复合型思维,因为这种思维模式,包含强大的同理心,包含敏锐的洞察力,同时也包含一定的视野广度,需要结合心理学、哲学、技术、数据、业务思维以及极高的情商才能够达到的。那么同时会由于接触的太多从而造成迷茫。那么我只想说,脚踏实地,一专多能,看透一件事物的本质,其他一定,触类旁通。

 

  总结:

  无论小伙伴们属于哪一种思维,哪一种类型,如果我们想从普通 走到 优秀 再走到 卓越。 那么热爱你当下做的事情,乐于分享,专注 去和一群有情有义的小伙伴们,为这个世界带来一些,微小的改变。

目录
相关文章
|
6月前
|
设计模式 算法 C语言
技术进步与个人成长:从代码到思维的演变
技术不仅塑造了我们的工作方式,更深刻地影响了我们的思维模式。本文探讨了在编程实践中,个人技术能力和思维方式如何相互影响和提升,重点讨论了一些关键的经验和感悟,以及这些经历对职业发展的深远影响。
61 0
编写s=1+2+3+...+n思路打破认知
最近在和领导讨论架构设计,其中涉及到如何通过代码来体现面向对象?通过一个例子来打破了原有的认知,以此总结记录自己的提升和成长
|
安全 数据可视化 测试技术
【设计思维框架】为现代企业重新设想的设计思维(下)
【设计思维框架】为现代企业重新设想的设计思维
|
架构师 UED
【设计思维框架】为现代企业重新设想的设计思维(上)
【设计思维框架】为现代企业重新设想的设计思维
|
安全 数据可视化 测试技术
【设计思维框架】框架 :为现代企业重新设想的设计思维(下)
【设计思维框架】框架 :为现代企业重新设想的设计思维
|
架构师 UED
【设计思维框架】框架 :为现代企业重新设想的设计思维(上)
【设计思维框架】框架 :为现代企业重新设想的设计思维
|
数据采集 存储 编解码
在架构师的角度去看大型网站架构面临的挑战:技术架构的基本思路
技术架构的基本思路 技术架构既要清晰地划分功能模块或子系统,又要对整个网站系统的技术逻辑有清晰的认知。庞大的技术架构确实会让人望而却步,架构设计也变得无从入手。 如果把一个庞大的技术架构分成独立的几部分,然后再逐一深入的话,那么一个庞大的技术架构也不是不可理解的
|
敏捷开发 架构师 项目管理
架构师才能看懂的大型网站架构面临的挑战:业务架构的基本思路
业务架构的基本思路 大型网站系统有很多功能,一次性明确所有的功能需求并设计出一个庞大的业务架构是一件费力不讨好的事情。因为在项目前期,难免会忽视一些琐碎功能,而随着开发的进行,也会有很多新的想法产生,基本上不会存在完全按照最初的业务架构设计完成的软件产品。因此,业务架构不仅要做到“规整功能模块,厘清产品业务逻辑”,更重要的是如何做到“有规划性地应对项目过程中的需求变更”。
|
存储 监控 安全
【组装式架构设计】“有机”架构思维的探寻-交付那些事
软件架构本身是一个宏大的概念或命题,但历经过往种种,开始有些思考在脑海中,挥之不去,在此整理出来,和大家一道探寻,这是一篇关于“类比”的探寻。
585 0
【组装式架构设计】“有机”架构思维的探寻-交付那些事
|
架构师 算法 搜索推荐
直击架构本质:优秀架构师必须掌握的几种架构思维
直击架构本质:优秀架构师必须掌握的几种架构思维
264 0
直击架构本质:优秀架构师必须掌握的几种架构思维