业务是什么
https://www.cnblogs.com/kiba/p/9207055.html
技术思维、业务数据思维、产品思维、复合思维
https://www.cnblogs.com/yangsy0915/p/9238009.html
一个团队的成员有很多人，其中包括项目经理，架构师，组长，组员等等其他人员。就纯开发而言，编写代码的人员只有架构师和组长、组员三个角色。要完成架构，就要利用好三种角色的关系，并且使用正确的人。架构师的责任是架构，构建出框架的摸样，而架构在实际应用中包含着两个概念：业务和开发。
业务是什么？
业务是架构设计的重要依据，在设计时必须要有一个业务管控的角色和架构师一起进行，而这个业务管控的角色即可以是一个人也可以是多个人。
举个例子，我们在实际开发中经常遇见开发人员说设计不合理，从而产生反感情绪，有甚者拒绝开发。为什么？因为设计违背了开发人员对项目的理解，这些设计指什么？可以是数据库设计，可以是流程设计，也可以是其他。但如果在设计时和对应的业务管控角色一起进行，那么会很大程度的降低这种现象。
开发是什么？
开发就是实际编码，实际编码分为两部分，框架编写和项目实现编写，框架编写时很多人有个误区，框架要由架构师完成。实际上框架编写架构师应该只参与一部分，那么就需要在团队中找到一个技术优秀的人和你一起完成框架，这里就是一个人而不是一个角色了，而之后其他组员的疑问，和框架的扩展就由这位成员来解答和完成，这样不但是对这位组员技术的一种锻炼，也节约了架构师的时间。
为什么需要这么一个人呢？举个例子，我们在实际开发中经常遇见开发人员抱怨框架设计不合理，不够细节，这时架构师做的任何解释其实都是惘然，因为一个人的话语永远是苍白无力的，而开发人员对技术的质疑和对业务的质疑对项目进行速度的影响是截然不同的，前者远远大于后者，但如果加一个开发人员和你一起去解释就不同了，它会保证项目顺利的进行。
理论中的架构和实际中的架构差距太大，在理论中，它没有人员的矛盾预测，没有成员的技术能力的预判，也没有人类情绪的设定，理论从来不会告诉你如何实现一个任何人都不理解的框架需要哪些谈判和沟通，他只会告诉你如何制作。而现实中，我们需要谈判，需要沟通，需要技巧，而这些不是一个人能完成的，它需要有人支持，有人理解，我们不能期盼每一个项目都有完美的领导和技术团队，我们只能通过沟通引领一部分人站到我们的身边，在面对困难的时候，能够屹立不摇。
-技术思维、业务数据思维、产品思维、复合思维
工作已有四年有余，从最初的亚信 到现在的 阿里。。总结了下思维模式，以个人的视角，供各位干代码的小伙伴们参考，能够深入无论 技术还是业务还是产品的本质。发现其中的规律，更好地把握自己的方向及未来。那么总的来说，我分为四种思维模式：
一、技术思维
卧槽！干代码！出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,和别人交谈时，第一想法不是思考正确性，而只是因为技术本身是否牛逼，而否定。其实，任何一项伟大，都不是靠某个人去完成的，而是靠一个团队去完成的。那么如何去完成一项伟大的事情，需要的是一棒子能够互相理解、互相融合的、极度痴迷的伙伴，客观的去判断，认真的去打造的，你会发现，我们是一个集体，我们在向共同的目标前进，去做一件伟大的事情。
二、业务数据思维
业务思维上，更多会考虑到业务本身的价值，具有较强的业务敏感度。很容易从工作中发现问题，再从发现的问题重，进行统计数字化分析，观察其覆盖面或影响范围或共同点，从而抽象成形成一类的问题，进行业务梳理，从而指导产品的建设。当然，在工作中很少有纯做业务的。毕竟业务也跟市场相关。
那么下来说下数据思维，数据思维更多的是发现数据与数据之间的关联性，事物与事物之间的联系，通过哪一类事物，我们可以通过数据处理、数据分析、算法分析等手段去应证，去推算。我见过跟厉害的数据架构师，他们甚至能说出每一个业务链路的环节及中间层的提取，甚至能从各方面去评估其影响，不得不为之称赞。
三、产品思维
对于产品思维，很多人会想到，程序员总想砍死产品经理，改来改去哈哈。。但是其实产品思维的核心在于 与人打交道、与业务打交道、与技术打交道 以及 事物的推动作用。 程序员可以很开心的去写代码，可是一个好的产品经理，需要跟业务、技术、事物本身的探索，甚至要从整个铺开的体系中，去发现及探索产品的价值，同时还要去关注产品本身对于用户的体验。这并不是一件容易的事，同时还包含同理心，与不同结构的成员交流的融合。那么产品思维，我们就可以概括为：业务本身、技能专业度、洞察力、心理学、全局观、高情商以及耐心，是一种复合的思维。
四、复合思维
毕竟本人也是技术出身，所以对于技术的感官更加强烈哈哈。。但是如果，你能在精通专业技术的基础上，融合 技术 业务 产品 的体系化思维模式，我称之为复合型思维，因为这种思维模式，包含强大的同理心，包含敏锐的洞察力，同时也包含一定的视野广度，需要结合心理学、哲学、技术、数据、业务思维以及极高的情商才能够达到的。那么同时会由于接触的太多从而造成迷茫。那么我只想说，脚踏实地，一专多能，看透一件事物的本质，其他一定，触类旁通。
总结：
无论小伙伴们属于哪一种思维，哪一种类型，如果我们想从普通 走到 优秀 再走到 卓越。 那么热爱你当下做的事情，乐于分享，专注 去和一群有情有义的小伙伴们，为这个世界带来一些，微小的改变。