技术人员思维和认知升级(200922)

今天这篇文章准备整理下我原来谈过的和技术人员相关的思维方面的话题，整个内容实际上包括两个方面。其一是我们可以从开发和技术中借鉴哪些思维方式；其二是技术人员本身不要受限于技术中，而应该跳出盒子培养价值驱动下的经营思维。

从编程思维谈起

编程思维的本质究竟是什么？

谈编程不可避免的要谈到编程语言，而编程语言之所以出现，其最终的目的仍然是 提供一种抽象方法来解决现实中的问题 ，问题本身的复杂程度往往取决于抽象的种类和质量。

从汇编语言的出现解决了最初的抽象，而类似c或fortran语言出现则可以看做是对汇编语言的进一步抽象。这一步抽象的完成其实是很重要的一个进步，即我们在解决问题的时候不再需要关系复杂的机器模型或机器码，而是可以更多的关注问题和解决方案本身。

在这个阶段，从 编程本身来说最核心的还是算法和数据结构 。这也是任何程序最重要的两个基本要素。既把问题域本身涉及到的数据映射到合适的数据结构，把通过程序解决问题的过程映射为具体的算法逻辑。

那么编程实际的难点在哪？

不是算法本身或数据结构本身，而是 当你拿到问题域的时候知道如何理解和分解问题，并将其映射到最适合的算法或数据结构上 。这个映射其实本身不是程序解决的问题，还是人脑在思维，程序本身仅仅是在实现自动化的过程。

那么程序在算法实现过程中最基本的是什么？

我们看不同的程序片段可以看到的还是if/else，或者for/while，然后才是数据或数据类型定义。而前者即写任何一个程序中最重要的控制逻辑。那么编程里难的实际上不是控制语句本身，而是在把问题域分解后知道如何理解判断逻辑，如何将问题域中重复的东西抽象为循环，如何从问题域中抽象出数据结构。

一个人编程能力本身的好坏，或者说编程思维能力，重点其实是体现在这种映射能力，也可以称这种映射能力为数学建模能力。

举个例子来说，如果一个问题你已经知道了可以映射到构建二叉树，然后通过遍历的方式来解决了，那么可以说然后一个掌握了语言语法的人都可以写出程序来。那么实际编程思维或能力的强弱则在于前面谈到的映射和建模。

对现实世界的抽象理解，从抽象归纳到演绎泛化

面向对象思想和面向对象编程语言的出现，可以说也是编程思维本身的第二次重大提升。

即原有的编程语言可以看到我们关注更多的已经是抽象后的解决方案，而面向对象的编程语言则首先关注的是通过类，通过继承，通过接口定义等首先对现实世界进行很好的抽象描述，其次才是如何去解决问题。现实世界中所有的一切都是对象，而面向对象语言中的类本身就是对现实世界中对象的很好的抽象。

对于面向对象的核心特征谈的比较多的是封装，继承和多态。这些可能比较偏技术词汇，那么再简单点来说面向对象编程思维其核心则是 找到问题域中的对象，将其抽象为类，识别类应该有的属性和方法特征，同时去理清类和类之间的关联和交互关系，将问题本身的解决过程映射到类和类之间的方法交互上。

如果从这个意义上来说，好像也不是很复杂，那么实际面向对象编程的难点实际在为了保持代码足够的健壮性，可维护性，可扩展性而做出的各种抽象，包括接口的提取和组合，控制或逻辑类的增加等，这些本质已经转换到技术域类本身。

另外编程里面有一个重要的思想即是复用 ，从最简单的函数，到模版库，类库，再到更上层的公共组件等，都在体现复用的思想，而复用本身的目的则主要是提升开发效率，提升可维护性和代码的可读性等。复用可以理解为编程过程中的编程思想更加恰当。

编程的思想是自动化 ，不要简单的理解为编程语言能够帮助你解决建模和映射的难题，编程的自动化更多的还是体现在机器可以自动化的进行大量计算和运算，而这个运算是通过我们的程序进行的。程序中体现的一个重点我更喜欢把它理解为循环，从抽象中去发现一种可自动化的循环，这种循环的处理正是程序的强项。

任何人都应该有这种自动化的编程思维，即懒人思维，重复的事情一定不要手工重复完成。

架构思维

前面谈了编程思维，里面谈到了抽象，复用，自动化等关键内容。

接着再谈下架构思维，对于架构思维本身仍然是类似系统思维，结构化思维，编程思维等诸多思维模式的一个合集。由于架构的核心作用是在业务现实世界和抽象的IT实现之间建立起一道桥梁，因此架构思维最核心的就是要理解 业务驱动技术，技术为最终的业务服务。要真正通过架构设计来完成业务和技术，需求和实现，软件和硬件，静态和动态，成本和收益等多方面的平衡。

分解是最基础的 ，架构的重点就是要对复杂问题进行分而治之，同时保证分解后的各个部分还能够高内聚，松耦合，最终又集成为一个完整的整体。分解核心是定义问题，因此架构首先仍然需要理解清楚需求。

集成是配合分解完成的动作 ，最终分解完成的各个组件或子系统，通过合适的接口设计，最终还能够集成为一个完整的整体，分解仅仅是加速开发和降低问题复杂度，如果分解后的内容无法集成在一起，那么分解就没有任何意义。

分解+集成可以理解为架构最核心的思考方式和方法。

动态+静态： 一直是我强调的重要思维模式，架构思考里面一定要注意这两者的结合，即涉及到流程，用例等动态分析内容，又涉及到数据，类等静态建模内容，而是两者要高度协作起来完成整个架构思考。

复用是另外一个重要的思维 ，也可以理解为SOA参考架构的核心思考模式，包括最近谈的最多的业务能力组件化，组件能力服务化，平台+应用，共享中心建设，共性能力下沉等都是谈的复用的概念。即使你架构设计一个小系统，你也需要将各个模块需要用的共性功能抽取为可复用的共性组件。

分层相对重要，架构在设计中要考虑分层，而核心仍然是资源+服务+应用的三大层 ，分为这三层仍然是SOA参考架构的核心思想。对于平台+应用更多只是上面分层模式的一个变形。分层的目的是通过分层既理清了整个应用的构建过程，又保证了各层之间的独立设计和松耦合。

模式匹配： 可以讲是所有思维模式里面的一个重点，而架构设计中的模式匹配就是要将最终的业务域问题匹配到对应的技术实现上面。即根据业务需求来挑选最适合的技术，而不是用主流和最先进的技术去反推业务。

抽象是架构思维里面的一个重点 ，这里面包括了两个层面的内容，一个是常说的归纳方法，即各种类似场景的实现见的太多了，自然就归纳了一个规则或方法出来供以后的设计用。但是抽象更加重要，即将非类似场景中的共性内容也总结出来，进一步抽象为类似的东西，以更加方便的适应变更和各种变化。

结构化思维是架构思维必须具备的 ，最常用的两种结构就是二维的表格和树模型，通过结构化思维引入了维度和XY概念后，可以帮助我们更好的分析和比对，结构化决策等。对于多维模型，我们也要有意识的将其转换为多个平面二维模型，方便我们进行分析。

迭代思维是架构思考中需要考虑的另外一个重要内容 ，没有最优的架构，只有不断进化的架构，只有最适合的架构。因此架构本身也在随着业务需求的变化不断的迭代和演化，而不是追求用最新的技术一步到位。

最后即我们常说的系统思维 ，系统思维是架构思维中最重要的思维模式，一个架构师必须要有充分的全局思考的能力，做好前面谈到各种平衡，追求整体的最优化而不是单个目标的最优。

从架构思维到大架构观培养

要成为架构师，大量的项目和设计编码积累是必须的，而且这种编码积累还不能是简单重复，还是必须得有抽象，复用等各种思维，不断重构的设计意识。走的路多了，各种业务到实现的匹配方式验证的多了，各种大型项目经历和解决复杂问题多了，你自然就有了这种能力。

一个架构，很多时候并不是说创新或学习能力就有多强，而是他们的实践经验积累的知识库很强大，见多才能够识广，大量的模式匹配库随时可以使用，而对于一般人你经常发出的感慨就是我怎么没有想到那里去？知识经验库很值钱，但是这个是长期大量的实践换来的，投入的是大量的时间和金钱成本。

经验库的积累一定是知识理论到实践，再到总结复盘，再到抽象形成在自己脑海里面的。这个过程本身就是循序渐进，反复迭代，并没有什么捷径可走。

而今天谈大架构观，那么首先还是说的架构思维，对于架构思维即前面谈到的 分解，集成，抽象，复用，组合，系统化等多方面的思维能力 ，这些思维能力都相当重要，但是本质都是我们看待和理解事物的方式。

大架构观本质就是我们如何看待和理解一个产品，那么最终这个产品的实现就是按照你理解或建模的方式进行开发和产出。所有产品后期可能出现的问题都可能是我们理解出现了问题。

架构首先要解决的是 产品内部组件如何高效协同，产品和外围系统间如何高效协同并满足业务和用户需求的问题 。这就是最基本的功能性需求，架构必须要搭建这种业务场景和需求和最终产品实现之间的桥梁。这么多年下来，我们还是发现，很多人对架构的理解有很大的偏差。

即我会用多层框架了就是J2EE架构师，会用SpringCloud了就是微服务架构师，会Hadoop了就是大数据架构师，这是对架构一个巨大的误解。能够基于开源项目或框架来搭建一个基础开发平台确实是一个架构师应该具备的基本能力，但是这个能力仅仅是架构能力很小的一部分，因为技术框架不是业务需求，而实现在技术框架上的业务功能组件才能够满足业务需求。

在业务需求没有最终实现前，技术框架本身并没有得到充分的验证，也没有和最终的业务需求匹配，这种空框架搭建并没有很高的技术含量。

或者说 大部分人将架构理解为技术架构，而忽视了业务抽象和建模能力 ，但是脱离业务的技术架构，连自己都无法验证最终架构原型对现实业务的支撑能力，即架构师最终设计的东西无法自己进行实证，这本身就是一个要命的事情。架构师变成了纸上谈兵，设计的模型变成了空中楼阁，这显然不是我们想要的。

一个好的架构师，应该是给出在当前业务场景和需求下，最合理的架构模型设计 ，而不是什么理想化的模型，什么网上顺手搬来的现成架构模型。架构师追求的不是理想化，而是当下最合理。

我们如何分析和理解产品，这里的大架构观的一个重点就是能够深入细节又能够跳出盒子的双重思维， 既能够宏观全局又能够微观局部，既能够分解又能够集成回去 。既追根究底又不求甚解，置身产品之中又能够跳出产品做用户视角的思考。要具备这种架构能力，需要的是业务建模，业务到技术分解转化能力，随时都是业务和需求导向，技术为需求服务。没有盲目的技术堆积，只有合理的技术采用。没有理想化的模型，只有验证过的技术。

一个好的架构一定是 同时解决功能性架构和非功能性架构两方面的问题 。

而非功能性架构包括了可靠性，性能，高可用性，高扩展性等多方面的内容。这些都需要架构师在搭建模型的时候进行考虑，好的架构就是稳如泰山，灵活扩展，具备弹性的以不变应万变的能力。好的架构就是充分考虑到各种异常边界，并发峰值，安全攻击等场景下，系统仍然能够平稳可靠运行。

不论出现任何的突发情况，产品都能够灵活应对，这往往就是靠的架构师设计产品时候的架构能力。就如建造一座高楼，外部上看上去都一模一样，但是有的高楼刮大风都能够吹倒，但是有些高楼却能够扛住10级地震，这要的就是内功积累，否则就是绣花枕头。

越是复杂的业务，往往构建的业务系统和架构设计也就越复杂，但是对于架构师而言一定要意识到， 任何架构的复杂性都应该作为黑盒，屏蔽在架构设计内部 。即架构的复杂性应该在架构设计的时候被隐藏掉，通过粗粒度的接口将这种复杂性屏蔽在内部。即对于最终的开发人员往往并不需要关心这些复杂性，而只是按照架构原则和开发指南进行开发即可。这本身也是架构设计的一个重要考虑点。

大架构观，本质就是我们分析和理解事物的思维观 。

而架构本身解决的是从业务需求到技术实现间的关键衔接，而这个衔接的呈现是模型，解决的关键问题是抽象。大架构观，既需要我们通过分解和集成来理解事物的组成和内部运作协同机制，更加重要的是需要我们跳出盒子来看待整个事物或产品的运行。

从开发和技术实践中可以借鉴哪些思维？

在前面我一直在强调思维中最重要的是模式匹配，今天接着这个话题展开谈下从开发和技术实践中类似SOA，面向对象等技术思想中可以借鉴的思维方式。

从紧耦合到松耦合(解耦的最终目的是灵活组装和匹配）

在软件设计开发里面，我们经常会谈到松耦合和解耦，其原因就是今年保证各个模块充分自治，受外部其它模块影响最小。而在SOA架构里面如果谈到松耦合，其核心的原因是松耦合是进行灵活组合和编排的基础。

思维的最终目的是解决问题，当我们面对一个具体的问题解决后，就有了问题和解决方法：

问题A-》解决方法A

那可能在我们头脑里面就存储了这么一个关系，即遇到问题A用解决方法A去解决。

如果我们头脑里面都是去存储这种信息，那就是我们说的紧耦合，试想一下问题成千上万，我们得存储多少解决方法和知识点？这种穷尽和大量记忆存储的方法显然是不现实的。那我们实际要做什么呢？即将解决方法分解为细粒度知识点。

问题A-》解决方法A（知识点A1, 知识点A2,知识点A3）

即任何问题的解决都是已有的知识点的组合和组装。问题和知识点之间是完全松耦合的，而解决方法只是知识点的灵活组合而已。我们只要有了最基本的知识点，就不怕任何形式的问题。

就类似我前面谈售前技术建议书一样，客户的招标要求千差万别，但是你只要有了（业务方案，技术方案，部署方案，实施方案，运维，人员，案例，报价单模板）等基础知识点，你就可以应对所有的售前方案，你唯一需要做的就是将客户的招标要求或需求分解为一个个的需求点，同时将这些需求点映射到你已有的知识点上。

通过解耦，我们没必要去存储和记忆大量粗粒度的解决方案内容，我们只需要关系问题能否分解到已有的知识点上，只需要培养知识点如何根据问题进行组装和编排的能力即可。也正是这个原因，任何一个问题解决后，你都要思考有哪些可复用的知识点可以入你的知识库，而不是将该问题的解决方法入库存储。

从静态到动态（动态的目的是知其然并知其所以然）

第二点我们想谈的是从静态到动态，因为最近我们在做PPT汇报材料评审的时候发现一个关键问题，即静态内容多，而动态内容少，讲最终结果多而讲分析过程少。

在讲PPT制作的时候我曾经谈到过，对于PPT的呈现只有两类，一类是动态呈现（阶段，流程，活动，演进），一类是静态呈现（组成，架构）等。而这两类呈现必须相互结合，相对来说动态呈现更加重要，只有动态呈现能够说明一个事物实际内部各个组件之间是如何运作的，而只有了解了内部运作你才可能洞悉事物内部机理。

从PPT的呈现回到我们思维逻辑上也是同样的道理。

当我们去了解任何一个事物的时候，一定要注意前期我们可能只是了解下事物的结构和组成，但是如果你真想去深入了解事物，那么就必须从这种静态的组成转变到对动态的组成过程的研究。即事物是如何动态发展演进到当前这个结构的？只有这样你才能够洞悉事物内部各个组件之间是如何协调运作的。

我们平时太注重结果，而忘记了对这种科学思考过程的关注。而实际上再好的结果本身都不具备可复制性，而只有科学的思考过程和方法本身是可以复制的。你得出一个好的结果不代表你就很牛逼，中间有很多偶然性；但是当你自我论证是通过很好的方法和过程，得出了这么一个结果，那这种过程本身就具备了举一反三能力。

原来我写过一篇文章，谈搜索引擎之毒，为啥这样谈？所有千奇百怪的问题，你到互联网一搜马上就搜索到答案并解决掉了，那么这个时候你不会再去深究回答者是如何进行问题分析和思考而得出答案的，即你随时搜索到了答案，但是你没学会是思考和解决问题的方法。

从静态答案到去寻找答案是如何分析出来的，本身也是静态到动态的过程。

从泛化到抽象（抽象的目的是最小化记忆，并提供为了演绎的入口）

在互联网时代，当前人和人比较的一定不是记忆能力，而是问题分析和解决能力。而这个能力里面最重要的一点就是 当你拿到问题后，你知道从哪里入手去解决，即问题的入口在哪里。

我原来谈到过，互联网是一个海量的知识库，每个人都可以获取到，你自己的电脑里面可能也有一个你自己归纳整理好的大的经验库。这么多信息一定是不需要记忆的， 需要记忆的仅仅是能够通达知识的索引。 通俗点来讲就是当问题来了的时候，你知识在哪里拿到最能解决问题的资料。

泛化和抽象，实例和类都是偏IT领域的一些词汇。但是这些词对于思维领域同样适用。你平时看到的东西，实践的东西，学习到的知识都很多，你需要做的就是进行归纳和抽象，形成你自己的概念模型，形成自己能够记忆的最小知识集，这个知识集最后就是索引信息。

有了索引我们就能够按图索骥。

索引类似于软件设计中最高的抽象层次，即接口的定义。接口中只有方法，没有具体的实现。而索引就是这个道理，我们只需要知道不同的问题究竟应该用什么的方法来解决，这个方法究竟是怎么解决的？我们不需要记忆，我们只需要找到我们存储或网上存储的资料即可。

不同场景下不同的问题究竟应该用什么样的方法解决，正是我们在思维里面谈到过的，对于一个人最有价值的能力，即模式和方法论。所有的实践我们都在积累我们自己的模式库和匹配库。

比如你原来做开发工作，转到做软件需求和业务顾问工作，你的模式库做一次更新。你从做财务域的顾问，转到做供应链域的顾问，你的模式库做二次更新，后续再转域无任何问题。

一生二，二生三，三生万物，但是万物没法全部穷举和了解，我们要做的是记忆1这个索引。

横切思维-聚合本身带来价值

对于AOP即是指可以通过预编译方式和运行期动态代理实现在不修改源代码的情况下给程序动态统一添加功能的一种技术。AOP实际是GoF设计模式的延续，设计模式孜孜不倦追求的是调用者和被调用者之间的解耦,提高代码的灵活性和可扩展性，AOP可以说也是这种目标的一种实现。

AOP编程的核心意图是将日志记录，性能统计，安全控制，事务处理，异常处理等代码从业务逻辑代码中划分出来，通过对这些行为的分离，我们希望可以将它们独立到非指导业务逻辑的方法中，进而改变这些行为的时候不影响业务逻辑的代码。

对于横切思维，我们还是给一个简单的定义：

即在分析诸多事物的生命周期发展过程中，分析端到端流程业务的流转过程中，在关键的阶段点进行拦截形成有价值的聚合点，通过聚合点来实现各类统一管控和增值服务。

横切思维需要彻底打破我们传统动态单事物动态发展观察视角，从单事物到事物群，充分去识别共性，将共性进行抽象和聚合，形成有价值的服务能力。

我们可以来看下横切思维模式具体有哪些实践

01-在项目型或强矩阵型组织中的横向管理协同

在一个强矩阵管理下，可以看到对于UI，架构，测试等各种资源全部归属到产品线和项目，这些资源完全是按照产品生命周期进行联动也最敏捷响应客户需求。但是也可以看到容易导致的就是各个产品线的UI不统一，架构和设计标准不统一等各类问题。因此需要考虑横向建立各类跨产品线贯通的工作小组，类似UI工作组，TPG工作组等来实现共性资源的整合和复用，一个是标准化，一个是避免各类重复投入。

02-全生态链的运营服务类平台构建和运营

在互联网里面，我们可以看到很多全生态链构建和运营的平台，类似的供应链端到端服务平台，电商类平台，二手车交易平台等。而这些服务平台里面可以看到在对各方资源进行整合后，其核心不再是简单的赚取简单的交易或服务费用，而是在资源整合后，横向切分后充分挖掘有价值的能力聚合点。

类似你做供应链运营服务平台，你可以推出统一的大宗交易集采，你做58同城你可以推出你自己的58到家自营服务。你做二手车交易，你可以推出你自己的信贷或保理平台等等。即通过资源整合后，充分去发掘整个生态链里面的关键节点并进行横切，来聚合和形成自营的服务能力。

03-企业各种类型的服务共享中心

对于企业来说，各类共享服务中心是一直以来的一个热点，类似人力资源共享中心，财务共享中心，采购共享中心等，而所有共享中心建立本质就是将原来企业类的涉及到的各类流程中的共性资源抽取出来，充分分析后形成可共享的服务能力再开放出去提供服务。

共享可以是简单的对已有能力的聚合，但是更多是类似云化的思路，即对已有能力进行彻底剥离，在剥离后充分重构形成完整的统一能力提供。这才是共享中心最终的价值体现。

思维转变-从技术驱动到经营和价值驱动

最后再谈下技术人员思维转变，或者说叫从技术到管理，从技术走到项目经理或产品经理的时候你应该有的一些思维转变。对于技术人员在技术上专注和精进本身是没有问题的，但是如果技术人员沉迷在技术里面那么很难真正走向管理或成为一个打造好产品的产品经理。

培养客户驱动和经营意识

个人理解首先要培养的就是客户驱动和经营意识，做任何东西首先要考虑的是是否是真正客户想要的，还是说为了自己的技术兴趣要去学习和研究。

对于我们经常看到的一个情况就是，我们的技术组件和技术开发框架选择不断的在追逐新技术不断的在变化，但是客户需求或并发往往并没有到必须使用这些先进技术框架的程度。同时由于技术框架不断的变化，导致我们的业务系统稳定性反而下降，这就是我们常见的一种技术驱动。

客户需要的产品没有做好，但是技术人员自己新技术学了不少，公司出现啥问题了自己反而可以很容易跳槽到新的好公司。这种技术人员总结来说完全是为了个人利益而损害了公司本身的产品和经营。

其次是我们说的经营意识，如果你要转产品经理或项目经理，你一定要有经营意识，就是我们研发的产品究竟有没有客户买单，究竟能不能赚钱，你研发的产品技术再先进，功能再强大，如果没有最终的客户，没有订单，那么仍然是没有任何产品价值可言。唯一的用处仍然仅仅是研发人员自己获得了技术经验和技术积累。

所以我们研发的功能一定要去思考是否真正是客户需要的，是否有真实的客户需求。所有功能的新增和改进，都不能为了技术而技术。包括我们经常谈到的微服务架构转型也一样，及时做架构转型也是实际企业业务发展情况下传统的IT架构无法满足，需要我们技术架构做出改变，而不是为了迎合新功能，新技术。

完全自研和拿来主义

对于技术人员，最容易犯的毛病就是为了体现自己的技术能力，总是希望所有的东西都要自己从头到尾做一套，很多时候不屑于采用已经的成熟的开源解决方案或已有的一些成熟产品。

在一个稍微大型一点的公司我们经常就会看到，技术同样一个技术，类似消息或缓存，往往不同的开发团队都有自己的解决方案和定制化技术组件。为何出现这种情况？技术人员最常说的就是其他团队的技术组件不能满足我们的个性化需求，因此我们要重头自己搞一套。

那么为何不能是提出个性化需求，然后由对方进行优化和改进呢？

实际上如果真正能够做到技术平台和组件的通用化和复用，一个公司必须由类似TPG的平台型技术组织和团队，专门来做这件事情，构建企业组织范围内共享的技术平台和组件，而且在企业内给出强制性的要求和约束，对于技术组件选择必须从公司组件库中选项，对于技术组件类需求必须提交到TPG进行统一评估等。

技术人员思维的另外一个转变就是我们说的拿来主义，有现成的东西一定不要去从头到尾去搞，特别是技术走到后期更多的能力应该是在架构和技术组件整合上面，而不是单个技术组件的研发。因为这样是最快，最敏捷的能够交付技术平台和产品的思路。

市场机会往往稍纵即逝，技术团队需要的就是在最短的时间拿出对应的可用产品，然后在可用产品的基础上不断的迭代和优化。而不是用很长的时间才交付一个客户已经跑掉的，无人问津的自认为完美产品。比如我们提出要在1个月内给出一个快速上线的迭代产品，那么这个就是业务目标的强约束，没有任何可以商量的余地，那么技术人员要思考的就是在这个约束下进行研发和交付。

做好研发和市场的协同

技术人员需要做好研发和市场的协同。当有了经营意识的时候我们就需要考虑我们的产品如何进行市场策划和推广，如何进行新功能和亮点的宣传，如何拓展相关的渠道和合作伙伴，在这个过程中需要准备哪些产品介绍，宣传材料，售前PPT等文档材料等。

市场工作实际和研发工作本身也是迭代交替进行的，任何一个产品都不可能是完全研发出来后我们才去考虑如何进行市场推广。因此市场策划推广和产品研发工作必须并行，而且需要市场和策划宣传先行，从市场项目机会到最终落单本身也有一个比较长的周期，因此只有这样两者才能够配合协同起来。

而我们的技术人员往往有时候很难理解，为何产品没做出来就开始进行市场宣传已经具备这个功能，这也是典型的没有市场和经营意识的表现。

用最适合的技术来解决问题而不是最好的技术

一个好的技术人员，或者说技术走向管理的时候一个重要的思维变化就是不能还是原来的技术狂热型，技术本身是没有价值的，技术的价值一定是附属在产品上，让产品产生了价值。但是产品是否真正有价值并不一定体现在技术先进性上，而是体现在功能是否满足客户需求上面的。

任何一个产品运营或者售卖，首先考虑的是在满足客户需求的情况下赚取最大化的利润，技术发展太快，不存在最先进最好的技术，只存在面对当前客户需求和场景最适合的技术。

任何选择技术上的超前性往往带来的问题都是投入更大的研发成本和精力，其次就是新技术往往并不是最稳定的技术反而导致产品不稳定，这些都是技术人员需要思考和综合衡量的地方。