阿里巴巴高级技术专家聊工程师思惟

本文整理自至简在团队内部的我的分享，但愿经过对工程师思惟的分析和解读，让工程师能正确对待那些在现实工做中看上去与本职岗位无关，却对团队效能影响极大的一些点和一些事。

至简：阿里巴巴高级技术专家，是集团Service Mesh方向的重要参与者和推进者。曾出版《专业嵌入式软件开发——全面走向高质高效编程》一书，坚信和倡导软件设计是软件质量之根本，并对软件开发的复杂性本质有着深入的认识，对如何高质高效实施软件开发有着本身独到的看法和方法。

在社会分工的背景下，软件行业的工程师群体被划分红了开发、测试、产品等诸多岗位，以协做的方式共同完成价值创造。高度依赖软件的互联网行业正以全新的方式改善着人们的生活，同时在改善的道路上对价值创造的效能提出了更高的要求，而背后是对个体与团队的协做效能有着更高的诉求。

专人专岗的协做模式在进一步改善团队的协做效能时所面临的最大挑战在于“岗位墙”，即岗位间衔接不可避免会出现一些模糊地带，而这些模糊地带又很容易相互忽视，致使失去关注而很大程度地拉低了团队效能。好比，开发工程师会认为保证质量是测试工程师单方面的职责；开发工程师不关注用户体验而只需关注实现需求，等等。此外，这种协做模式也会固化个体的思惟和心智模式，将个体的思惟和心智框定在所处岗位以内，以至对于岗位以外的内容不能很好地理解，使得个体在整个协做活动中会缺少同理心、系统性，从而影响工做幸福感。

相信这些现实工做场景读者并不陌生：

开发工程师对产品工程师所提出的用户体验方面的需求会认为过于吹毛求疵；

产品工程师因不理解技术的实现原理而提出天马行空、不接地气的需求（咱们在此不讨论创新这一特例）；

测试工程师由于不理解工程效率的内涵而将本身的工做变成了体力活；

开发工程师不清楚本身对于软件质量的责任，而将那些本因本身作好的琐碎工做问心无愧地交给测试工程师去作；

辛辛苦苦所开发出来的功能，用户抱怨难用。

这些问题发生的最终结果，必定是团队协做效能的低下。那么在没有找到比专人专岗更好的协做模式的情形下，咱们该如何发挥个体的力量去改善团队的协做效能呢？改善的起点在于全面地梳理工程师思惟，帮助工程师个体在职场和职业发展中创建起更为全面的思惟和视野，以促使每一个工程师在协做过程当中能最大程度地发挥个体能力去推进团队协做效能的提高。

我将工程师思惟分解为产品、技术和工程三大思惟。每一个维度主要关注的内容经过几个关键字去表达，以下图所示。下面针对每种思惟须要关注的每一个词以图中从上至下的顺序去解释。因为解释是基于关键词去展开的，因此段落之间的衔接可能会显得生硬，还请读者见谅。

产品思惟

产品思惟的起源是用户（或客户）价值。用户价值是经过技术手段以产品或服务的形态去解决用户的痛点，或带去爽点。毫无疑问，工程师在平常工做中应时刻关注并厘清本身的工做与用户（或客户）价值的联系，而且应该经过聚焦于用户价值去安排工做的优先级和分配本身的精力。

当用户价值足够时，产品可否在市场中立足并真正收获收益，首先考验的是产品的用户体验。良好的用户体验必定是站在用户的角度，基于用户心智来塑造概念，因为概念存在理解和解释成本，因此塑造的概念应足够轻、少且易掌握。概念一旦塑造出来则概念间的关系也随之肯定，这些关系基本上决定了产品与用户的交互流程。好的产品体现于“易用”二字，其极致在于迎合用户的本能反应并符合各类生活或专业常识。

全部产品都存在演进的过程，所创造的用户价值也在被不断地挖掘与探索，那时不一样的细化价值须要经过产品特性去区分和表达。特性也是产品差别化的一种体现，特性也间接地肯定了软件实现层面的功能模块边界。做为开发工程师，也须要对产品特性有很是透彻的理解，并能将其很好地抽象并转化为软件实现层面的功能模块。特性须要考虑经过售卖license等形式进行开启或关闭去实现售卖，这一点对于2B的产品甚是必要。

为了产品更好地演进，须要经过数据闭环的形式去检验创造用户价值的效果，让产品的开发、运营、营销工做作到有的放矢。在产品价值创造的道路上，最惧怕的事莫过于只顾低头干作加法，作得多却无人关心收效。而咱们经过数据化闭环的形式，不只能让整个产品大团队聚焦于核心价值，还能帮助团队在探索用户价值的道路上理性地作减法。大多情形下，作减法远难于作加法。

技术思惟

技术思惟的源头是需求。需求能够分红市场需求、系统需求、特性需求等不一样层次，回答的是技术层面“作什么”的问题。显然，清晰表达的需求以及对需求的精确理解才能确保将事作对。毋容置疑，需求一旦出现误差所致使的浪费是很是严重的，也正因如此工程师对于需求的质量至关重视。

需求一旦确立，会基于模块化的思想拆分红多个功能模块去下降实现的局部复杂度，最终将全部功能模块“拼接”在一块儿去实现总体需求。每一个功能模块会安排给一我的或一个团队负责，因为功能模块是需求分解后的产物，容易致使工程师在实现的过程当中只看到“树木”而忘记了“森林”。

性能是工程师在实现一个功能模块时不得不关注的，特别是当功能模块被运用于高频、时效性敏感、算力有限的场合时性能将尤为被关注。在现实中有时会存在工程师乐于追求性能的极致去体现本身的技术实力，甚至出现过早追求性能而滑入过分设计的误区。

毫无疑问，一个正规的团队，对于功能模块的开发工做多会以项目制、多个迭代的方式去完成交付。很多工程师这里会有一个误区，忘记了敏捷思想所倡导的“项目计划的目的是为了适应变化”，而是将“按时交付”看成是天职，各类赶工爬到终点时却绝不意外地看到了“一地鸡毛”的景象。

在迈向第四次工业革命的道路上，人工智能、大数据、机器学习，Kubernetes、Istio、Knative、Go、Dart、Flutter等新技术不断冲击着工程师已掌握的技能。快速跟上技术的迭代步伐是每一个有追求的工程师不断提高本身专业素养的表现之一。工程师的心里必定不缺少对新技术的追求，憧憬本身所掌握的技术具备必定的先进性。

工程思惟

工程思惟的起点是流程。流程的背后是科学，以既定的步骤、阶段性的输入/输出去完成价值创造，经过过程控制确保最终结果让人满意。因为流程涉及每个工程师的工做质量与效率，其含义不仅在于定义、工具化、检查等内容，而是应基于工程师的平常工做习惯，将流程与工程师的工做环境无缝整合。“无缝”体现于流程中的概念与工程师群体已创建的专业常识相一致、没有增长毫无价值的负担，根本还是确保易用性。

机制的含义是经过对所需解决问题的分析，以一种模式去解决同类问题。机制应体现必定的系统性，而非“头痛治头，脚痛治脚”。系统性不是一开始就能被洞察到，可能在演进的过程当中逐步发现和完善的，于是须要工程师在工做的过程当中不时回顾并付诸实践去落实。对于工程师来讲，机制是经过系统性的软件设计去达成的。

能够说产品质量直接决定了工程师的工做和生活幸福感。一个质量不可靠的产品必定会给用户和工程师本身带去麻烦，甚至形成没法挽回的经济损失并形成负面的社会影响。对于工程师来讲，那势必打乱个体的工做与生活节奏。为了让产品的质量作到可靠，单元测试、静态分析、动态分析等确保工程质量的手段应成为工程师的基本工做内容，经过将这些手段与CI（Continuous Integration）流程进行整合去持续构建起对软件产品的质量信心。

在互联网行业，除了软件产品的质量得可靠外，风险可控是另外一个不能忽视的内容。而风险可控是创建于系统性机制和质量可靠之上的。对于服务端软件来讲愈是如此。风险每每出现于资源使用的极端场景，当从外部涌入的过多事务远超软件产品的处理能力时，须要有必定的机制让整个产品能相对平滑地应对，或是扩充资源、或是限制涌入事务的流量。

软件所需的机器成本是比较容易忽视的话题，软件成本不仅与软件性能相关，还与软件之间的依赖、技术方案等因素相连。当一个软件须要从公司的内部对外输出时，平时忽视对成本的关注就会暴露出成本问题。好比，为了运行某个软件须要数量庞大的计算资源，所致使的资金开销对于客户来说极可能是没法接受的。

至此，大体介绍完了本身所理解的工程师思惟。

延伸

了解工程师思惟的价值在于，工程师个体须要在工做中逐步创建起产品、技术和工程三大思惟，以便用更为全面的视角去看待平常工做中所面临的困境和困惑。当站在单一的思惟去看待所面临的问题时可能以为不合理，但从三大思惟层面去审视时所获得结论可能彻底相反。从团队协做的角度，只有团队中有更多的个体从多维度去进行思考，才容易发现岗位间衔接的那些无人问津的灰色地带，进而经过补位、助攻去更大程度地发挥团队的效能。

显然，不一样岗位、不一样职责的工程师对于这三大思惟的深度要求是不同的，但从多维度去思考却应是每一个工程师都应该具有的素养。

欢迎工做一到五年的Java工程师朋友们加入Java填坑之路：860113481

群内提供免费的Java架构学习资料（里面有高可用、高并发、高性能及分布式、Jvm性能调优、Spring源码，MyBatis，Netty,Redis,Kafka,Mysql,Zookeeper,Tomcat,Docker,Dubbo,Nginx等多个知识点的架构资料）合理利用本身每一分每一秒的时间来学习提高本身，不要再用"没有时间“来掩饰本身思想上的懒惰！趁年轻，使劲拼，给将来的本身一个交代！