优秀工程师的三大思维

在社会分工的背景下，软件行业的工程师群体被划分成了开发、测试、产品等诸多岗位，以协作的方式共同完成价值创造。高度依赖软件的互联网行业正以全新的方式改善着人们的生活，同时在改善的道路上对价值创造的效能提出了更高的要求，而背后是对个体与团队的协作效能有着更高的诉求。
专人专岗的协作模式在进一步改善团队的协作效能时所面临的最大挑战在于“岗位墙”，即岗位间衔接不可避免会出现一些模糊地带，而这些模糊地带又很容易相互忽视，导致失去关注而很大程度地拉低了团队效能。比如，开发工程师会认为保证质量是测试工程师单方面的职责；开发工程师不关注用户体验而只需关注实现需求，等等。此外，这种协作模式也会固化个体的思维和心智模式，将个体的思维和心智框定在所处岗位之内，以致对于岗位之外的内容不能很好地理解，使得个体在整个协作活动中会缺乏同理心、系统性，从而影响工作幸福感。
相信这些现实工作场景读者并不陌生：

开发工程师对产品工程师所提出的用户体验方面的需求会认为过于吹毛求疵；
产品工程师因不理解技术的实现原理而提出天马行空、不接地气的需求（我们在此不讨论创新这一特例）；
测试工程师因为不理解工程效率的内涵而将自己的工作变成了体力活；
开发工程师不清楚自己对于软件质量的责任，而将那些本因自己做好的琐碎工作心安理得地交给测试工程师去做；
辛辛苦苦所开发出来的功能，用户抱怨难用。

这些问题发生的最终结果，一定是团队协作效能的低下。那么在没有找到比专人专岗更好的协作模式的情形下，我们该如何发挥个体的力量去改善团队的协作效能呢？改善的起点在于全面地梳理工程师思维，帮助工程师个体在职场和职业发展中建立起更为全面的思维和视野，以促使每个工程师在协作过程中能最大程度地发挥个体能力去推动团队协作效能的提升。
我将工程师思维分解为产品、技术和工程三大思维。每个维度主要关注的内容通过几个关键字去表达，如下图所示。下面针对每种思维需要关注的每个词以图中从上至下的顺序去解释。由于解释是基于关键词去展开的，所以段落之间的衔接可能会显得生硬，还请读者见谅。
 

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



当用户价值足够时，产品能否在市场中立足并真正收获收益，首先考验的是产品的用户体验。良好的用户体验一定是站在用户的角度，基于用户心智来塑造概念，由于概念存在理解和解释成本，所以塑造的概念应足够轻、少且易掌握。概念一旦塑造出来则概念间的关系也随之确定，这些关系基本上决定了产品与用户的交互流程。好的产品体现于“易用”二字，其极致在于迎合用户的本能反应并符合各种生活或专业常识。
所有产品都存在演进的过程，所创造的用户价值也在被不断地挖掘与探索，那时不同的细化价值需要通过产品特性去区分和表达。特性也是产品差异化的一种体现，特性也间接地确定了软件实现层面的功能模块边界。作为开发工程师，也需要对产品特性有非常透彻的理解，并能将其很好地抽象并转化为软件实现层面的功能模块。特性需要考虑通过售卖license等形式进行开启或关闭去实现售卖，这一点对于2B的产品甚是必要。
为了产品更好地演进，需要通过数据闭环的形式去检验创造用户价值的效果，让产品的开发、运营、营销工作做到有的放矢。在产品价值创造的道路上，最害怕的事莫过于只顾低头干做加法，做得多却无人关心收效。而我们通过数据化闭环的形式，不仅能让整个产品大团队聚焦于核心价值，还能帮助团队在探索用户价值的道路上理性地做减法。大多情形下，做减法远难于做加法。
技术思维
技术思维的源头是需求。需求可以分成市场需求、系统需求、特性需求等不同层次，回答的是技术层面“做什么”的问题。显然，清晰表达的需求以及对需求的精确理解才能确保将事做对。毋容置疑，需求一旦出现偏差所导致的浪费是非常严重的，也正因如此工程师对于需求的质量相当重视。

原文转自：https://www.jianshu.com/p/47b5b7cf27f3