之前有思考过：“懂得很多道理，依然过不好一生”到底是哪里的问题？听过不同的答案，如：停留“知道”的舒服区、别人道理未必适用自己、甚至能力欠缺等诸如此类的回答。
后来发现这是「工程问题」。
把每个道理嚼碎如同把手机拆开了解每个部件一样，若把手机再装回去不能做到了解就够，还要亲自实验一遍。
不过历史告诉我们，就算不懂原理依然可以造出手机，技术和工程都跑在科学前面。
不信你幻想下，几百年前没有优质教育体系时，四大发明如何出来的？
再把视角转向商业，中底层员工往往“经济金融类出身”较多，而核心高管团队总有几个理工科人士；他们思维有什么区别？
文科生逻辑更擅长从原有特征推演分析做决策，理科生更讲究遇到问题客观看待事物、从根本上进行改变，这背后直接影响到“公司的运作效率”。
就连百度创始人李彦宏，在新工科技论坛上也曾说：每个人都要具备工程思维，这也是许多毕业生的短板，要深度了解它不妨从“软件工程”说起。
工程思维是什么
市面PM、开发、测试以及运维所做的工作均属于软件工程「代码080902」，是现在大学主流的专业之一；学习内容包括数据结构、算法、人际交互、需求分析等模块。
在英文环境中，工程（engineering）的档次要比科学（science）低很多，为什么？
主要原因是，软件从诞生之日起一直解决不好「交付问题」，即：项目不能按照履约时间、质量、成本完整交给客户。
为解决此疑难杂症，1968年10月北约科技委员会的专题会上，思考者们才真正提出“软件工程”的概念，它是什么呢？用软件的手段去满足客户需求吗？并非如此。
方便理解，举个例子：
在某工厂包装车间产品线经常出现“漏装问题”，客户收到货后打开包装一看是空的。
于是负责人找专家询问解决办法，专家建议装上监控系统，通过视频识别操作就不会出现此现象。
得知改造下来需要百万费用，厂长当场掀桌子决定「内部开会解决」，有位老师傅说很简单：
我们只需通过测量产品重量，然后在流水线最后装个大型吹风机，把它设定到相关风力即可。
若包装盒被吹跑证明就是空的，若没有则是完整的，众人怒赞得到老板赏识。
据此，工程的目的是客户需求的问题，至于解决的手段，只要在限定条件内是否用软件显得并不是那么重要。
计算机专业中，清华大学出版的教科书《软件工程—理论与实践》开篇谈道：
一位计算机芯片从业者认为代码是解决芯片问题的唯一办法，但一位软件工程师，只不过把软件当做满足客户需求的其中一个办法唯一。
所以，工程学指满足客户需求为目的的一门学科，而非单纯的开发软件。
它需要将客户的需求捕捉、分析、进行定义，并给出整体的系统需求，并分解各子系统；直到每个细节的需求可以由一个现有的组件直接满足，或通过修改满足。
而工程思维最大的特点是“要把事情做成”，也就是可交付、可使用、并做到开源节流”。
换个视角来看定义：
特斯拉、SpaceX创始人埃隆·马斯克（Elon Musk）并非是技术工程天才，从他创业发展史可看出横跨三大领域（互联网、清洁能源、太空）。
似乎三者并没有直接联系，为什么能够如此游刃有余呢？主要有两大要素：1）工程思维，2）第一性原理
在某采访中有人问他，制造火箭降低成本这件事NASA那么多专家都没做到，为什么SpaceX能完成，他回答说“我想，是因为他们资源太多了”。
这如同他优化特斯拉电池组一样，首先思考该目标是否可能，其次从商业和第一性原理出发，再研究电池的材料的组成部分。
进而通过可操作路径想办法找到这些材料，然后逐步压缩每个材料的成本，最后组装完成就拥有更便宜的电池。
也就是说，他认为每件产品（项目）依赖于结构，我们只需在封闭的结构中不断得拆解、类比、优化、模仿就能把它完成。
再比如说：
某航空公司做了一个关于顾客体验的调研，询问他们有什么期待？得到的结果是期望早点儿到达目的地，或提高安检、托运的时间。
几个专家视角给出的答案均不同，空气动力学家认为，前者如何让飞机飞得更快，涉及到动力以及元件的整体改造问题，后者需要优化安检与托运流程。
但系统工程给出的答案是，解决快的问题，要从去机场、找停车位、安检、托运整体进行优化。
对比上述中厂长优化流水线的事件，你会发现也有拥有同样规律，老师傅基于封闭状态节省成本的条件，拆解环节查漏补缺来解决根本问题。
谷歌早期用互联网做地图并没有效仿的人，它也是典型软件工程思维。
在封闭任务中用克服种种困难，把每条段路精确到厘米级别，然后用激光扫描避开路面障碍，以便车子开的过程中了解路况。
说到这里，幻想下那些互联网当红的企业家们，无疑均为工程思维运用的高手，阿里的王坚、今日头条的张一鸣、美团的王兴，甚至华为的任正非。
他们善于预判并在没有结构的情况下「预见结构」，并进行通盘顶层设计，然后从第一性出发来改善根本要素。
明白工程思维，把视角拉高也能理解众多社会问题，比如：
现在可以看到2035年北京地铁规划图，2030年碳达峰的行动方案和能源绿色低碳发展制度；这种可预测能力不正是每个普通人（企业）应该学习的吗？
工程思维三要素
结合中信出版社，经济管理类书籍《转向：用工程师思维解决商业难题》，我总结发现工程思维有三大特点：
1）找到结构，2）约束性设计，3）懂得取舍
首先在没有结构的情况下，第一个特点是工程师能从初步的概念到构想，看到潜在的结构。
也就是说不仅关注看得见的事物，也包括看不见的事物；并非空于幻想，而要结合实际做演绎。
他要考虑系统中各个元素，怎么在逻辑、时间、顺序以及功能方面进行有效链接，并分析元素在哪些条件下能够起作用，哪些条件下不起作用。
例如：牛顿的经典力学理论是建立在“科学观”上。
以若干基本的公理（原理）为基本假设做推导；公理无法佐证部分通过严谨的逻辑分析得到若干定理，从而不断对理论体系进行完善。
假设通过观察、实验等手段得出的证据符合结果，我们对验证越有信心；但若出现结果不符的地方，进而看看是否推导错误然后进行修补。
此类案例有很多：
瓦特基于“经典力学”发明（改造）了蒸汽机，计算机科学之父艾伦·麦席森图灵1936年提出《论数字计算在决断难题中的应用》，多年后工程师基于此发明了计算机和智能手机。
换言之，世界依赖于结构；有经验的工程师能在看似一团乱麻的事物中找到合理性的结构，在产品诞生前预判到成熟的全貌。
其次，正如“无规则的边界的自由”不叫自由，无约束的工程也不能成为工程一样，工程会遇到各种条件性的限制，如时间不够、资金不足等。
那么第二个特点是「在有约束的状态下」也要更好得完成目标，甚至说没有约束状态，也要形成自驱动力。
好比2020年黑天鹅事件（COVID-19），原本正常状态下两年才能完成的雷神山医院，从方案设计到建成交付仅用10天时间，被誉为“中国速度”；该工程最大的约束条件是“时间”。
正因如此，反过来看约束条件是某些创造性项目的动力，运用到企业场景，假设产品开发中拿到一个开放需求，你很难想象出最后产品成为什么模样。
尤其对菜鸟工程师、产品经理来说不懂得自带约束条件，过程中牵扯出来众多杂乱问题，如：
UI设计太差、用户需求没搞清楚、流程有多重方案、任务太多时间不够……..
这造成，永远开不完的会，解决不了的细节让自己身心疲惫；我看到很多个人在做任务时有此类现象，公司也同样，根本原因只怪「不会设计约束性条件」。
再者第三点和取舍有关系，若把约束性比作走钢丝，那取舍便是在可行性、可能性、可期待性的交叉拔河；你也可以把它理解成“鱼和熊掌不可兼得”。
如同：
新能源和电子行业，一款产品研发过程中热设计工程师要和结构、软件工程师以及PM之间相互沟通，多数情况下就不得不做出取舍。
在图纸的具体位置上，甚至牺牲掉软件的散热部分或者压缩电池整体空间，以保证产品系统稳固性。
因此，「取舍什么」是工程师具体的能力体现，建立该关键不仅表现在如何设计重点，还要研究资源分配的问题，甚至将弱目标从强目标中抽丝剥茧出来。
一方面工程师思维的框架我认为是系统思维，而不是单一技术或产品能力。
另一方面他是种「形而上谓之道」的能力，从技术到「找到结构」的建立比单个解决问题的方法论更有普适性意义。
总而言之，结构、约束、取舍三者是工程思维的法宝，在互联网时代它被一些线性的概念蒙蔽，比如：产品思维、项目思维均属于属于此大类。
很多人没有把它用明白的关键要素在“后两者”，若你能在拥有目标、结构的前置条件下，增加约束力懂得取舍，会发现「完成」的效率会大大增加；
这当中对于互联网公司的产品人来说，并不是那么容易完成某个项目的原因是什么呢？
我把它总结为四个字「忽悠思维」，很多软件公司销售为冲刺业绩，习惯对客户“画饼”，承诺些产品本身还未做到的功能。
客户付款后整个交付转移给了研发团队，最终完成的产品缝缝补补、如老人步履蹒跚的样子，客户怎么会满意？
那么全局思考下来，你会发现不论是「预判结构」还是「约束性」的设计，两者本身背后代表的是“组块”创新的能力。
工程本身是组块
此话怎讲？组块（chunk）是人类信息加工中最重要的形式之一；概念是米勒(G．MilJer，1956-1963）提出，主要分为动态和静态两种。
早些年用在工作记忆中，他注意到某一工作记忆未在10秒内复诵便会消退，同时保存容量最多为7±2个单元。
从动态视角看，人通过几个相关的小项目整合成为一个大项目，减少基础块数，从而将信息控制在记忆（物理空间）所容许的范围内。
从静态视角看，它是一个名词，具体指重新编码的结果或输出单位，为便于区别在英文中通常把前者称为“chunking”，将后者称之为chunk。
俄裔美籍作家“弗拉基米尔·纳博科夫”（1899-1977）提出的卡片写作原理与工程师思维的核心“模块化系统思维”均属于「组块」。
他们均指出这不是一项单一的才能，而是技术与原则融合；原因是：
一个系统因各模块之间的关系而成为一个整体，它们不能通过单独的分析各组成部分就能理解的。
人的神经元也是种组块，在光学显微镜下可以看到一个神经元的轴突末梢经过多次分支，最后每个分支的末端呈现杯状或球状。
这犹如，你学习的知识，慢慢形成联结均来源自于「神经元组块」。
另外，早些年美国行为心理学创始人华生基于此概念，曾向政府提出一个训练实验的要求，他说若给我10个健康婴儿，通过训练，我可以将他们培养成优秀学者、艺术家。
人们觉得很荒谬，最终没有完成该实验；若干年后一位匈奴牙的心理学讲师，对他提出的实验非常感兴趣。
然后与他的妻子围绕三个女儿进行培养，最后造就了三个女性国际象棋冠军，这便是著名的「波尔加三姐妹实验」。
如果你了解该原理，进一步看世间万物均存在“组块”的现象；随便举个例子，如拿书架取书的动作就包含四种组块：
1）确认位置，2）手抓书脊
3）控制力度，4）取出路径
每个步骤都是小迷你块，假如要做一个取书的智能机器人，那只需把每一个小组块（活动）编写一个程序，然后整合创新即可。
要知道程序背后是函数，函数是逻辑块，逻辑块是通用代码，用计算机将每个模块标准化，最后串联就能得到想要的结果。
就像学开车，老司机看到“红灯”就自然而然完成一系列相关动作；新手则需一个个动作分解来做。
好比你在工作中遇到的问题看似连贯，实则包含多个部分，对有经验的人而言，他们不会一手抓多个组块，而是整体分析后从某个组块下手。
可见，在认识自然和文明发展的过程中，组块思想与方法无处不在；芯片是组块，谈判策略是组块，笑脸是组块，地铁是组块，地图是组块……..
要是没有组块的思想也不可能制作成每件衣服，建起一座桥梁；当然也不会有家庭，这些组也不过是“形式与内容”的不同结合罢了。
因此，对照自我，你可以思考下自己的工作技能，所需软能力是不是组块呢？除外表部分外，哪些薄弱是不是把它拎出来找到规律刻意练习就能解决呢？
总而言之，工程的本质是实现。
组块化应用是把一个复杂问题自顶而上逐层把“系统”分成若干模块的过程，有多种属性分别反应内部特征。
如，典型的低代码平台把常用的功能都封好，像乐高一样，让使用者快速配置；它追求以价值为导向，并用「建构性的思维以求效率」来创造价值。
工程思维的运用
明白这些原理，如何把工程师思维应用到日常工作或学习上呢？我把它大致分为三个方面：
1）预见未来的结构
它分为「结构力」和「预见」两个层面，也许你会把前者理解成各种思考模型，如5W2H原则、金字塔、黄金圈理论等，其实工程中的结构有部分“科学”元素。
在这里有什么不同呢？
科学家“仰望天空”居多，很少屑于实际运用；主要阐述认识规律，发现规则；好比你经常看到科学发现新地球、海啸、巨大恒星等。
而工程讲究「脚踏实地」，将发现的原理转化并实际干出来。
也就是，在过程中首先要尊重科学规律，考虑多因素实际所存在的结构，再精益求精的持续改进。
对「预见」，最接近的两个词汇是“使命”或“梦想”。
埃隆·马斯克对火星的迷恋我相信绝对不会是因为科幻小说的影响，而是他认为自己聚合顶尖技术人才，然后又懂商业投资，加上使命的火花，才让他走上SpaceX的道路。
据此，作为普通人对我们有什么帮助呢？你不妨思考下自己的使命，梦想是什么？
也许比较天马行空理想主义，尝试把它量化成目标，思考有没有可能变成实际动作；只要勤快，拆分下大概率可以实现。
比如：工作很久的你想成为某个领域专家，也许只需花1-2年的时间深度学习理论知识，然后结合自我最新认知，通过不断分享就会被人发现，不一而论。
2）约束内找到组块
尽可能在具体的时间，约束内交付出明确“规模”的结果，相比科学研究就没有这些限制。
因为在开始，他们就不知道具体方向在哪里？例如：直到到今天，人类也无法统一相对论、量子力学。
结合自身，我觉得拥有清晰的目标后，第一步的困难是「最后期限」原则，很多人的未完成均结束在时间、精力的管理层面。
假设能克服这一步，接下来要考虑「组块」的环节；要尝试找到形成该结构的最小单元，部分人停滞不前是没有找到组块和串联，最后盲目的付出把精力耗尽。
比如：谈钢琴有组块、写作、玩音乐更是相同。
《故事工程》的作者拉里·布鲁克斯认为，写作这类看似有灵感的事情都可以采用工程思维设计，它用工程构建的方式将故事创作分为6大核心技能：
1）立意，2）人物，3）主题
4）结构，5）场景，6）风格
对于普通人所有的一切均可以「公式化」，为保证品质你可以多做几个备份来；查理·芒格在《穷查理宝典》中把它称为冗余模型（Backup Systems）。
3）平衡当中做取舍
取舍的根本是什么呢？在工程思维中讲究“第一性原理”，也就是你基于未来结构的顶层设计。
若说组块是框架中的血液，那取舍关键就是你的「框架」如何设计；这个框架怎么来呢？我把它总结成「旧系统」。
试想下，你想做的事情或达到的状态，以前有没有人完成？找到并把他设计成动态对标品；私下研究三个方面：1）学习路径，2）职业发展，3）成功阶段
美国神话作家“约瑟夫·坎贝尔”在20世纪50年代出版的《千面英雄》把人的经历分为三个阶段，分别是离群所居 ( separation) 、经验考验 ( ordeal) 、复归本源( return) 正是对应此模块。
把发展路线提炼出来之后，要做是「优化旧系统」，如：第二个阶段你看到对标的人用三年经历从经理做到总监，那在此方面自己有没有更快的办法呢？
所以不局限在表面的细枝末节，挖掘背后隐藏的路径和机制才是根本，真正的工程思维是要「解构旧系统」，组合创新「新系统」。
总结一下：
使命的驱动、顶层的框架设计、组块化的SOP。
这种全局观加上约束内的反馈机制，才是普通人值得学习的工程师思维。
回到文章开始，为什么学过很多道理，依然过不好一生？
因为「那个道理」背后的系统你没有躬身入局，所以听了也没用，想想看不是吗？
