软件工程|何为工程师思维？( 三 ) 使命|芯片

好比2020年黑天鹅事件（COVID-19），原本正常状态下两年才能完成的雷神山医院，从方案设计到建成交付仅用10天时间，被誉为“中国速度”；该工程最大的约束条件是“时间” 。
正因如此，反过来看约束条件是某些创造性项目的动力，运用到企业场景，假设产品开发中拿到一个开放需求，你很难想象出最后产品成为什么模样。
尤其对菜鸟工程师、产品经理来说不懂得自带约束条件，过程中牵扯出来众多杂乱问题，如：UI设计太差、用户需求没搞清楚、流程有多重方案、任务太多时间不够……
这造成，永远开不完的会，解决不了的细节让自己身心疲惫；我看到很多个人在做任务时有此类现象，公司也同样，根本原因只怪“不会设计约束性条件” 。
再者第三点和取舍有关系，若把约束性比作走钢丝，那取舍便是在可行性、可能性、可期待性的交叉拔河；你也可以把它理解成“鱼和熊掌不可兼得” 。
如同：
新能源和电子行业，一款产品研发过程中热设计工程师要和结构、软件工程师以及PM之间相互沟通，多数情况下就不得不做出取舍。在图纸的具体位置上，甚至牺牲掉软件的散热部分或者压缩电池整体空间，以保证产品系统稳固性。
因此， “取舍什么”是工程师具体的能力体现，建立该关键不仅表现在如何设计重点，还要研究资源分配的问题，甚至将弱目标从强目标中抽丝剥茧出来。
一方面工程师思维的框架我认为是系统思维，而不是单一技术或产品能力。另一方面他是种“形而上谓之道”的能力，从技术到“找到结构”的建立比单个解决问题的方法论更有普适性意义。
总而言之，结构、约束、取舍三者是工程思维的法宝，在互联网时代它被一些线性的概念蒙蔽，比如：产品思维、项目思维均属于属于此大类。
很多人没有把它用明白的关键要素在“后两者” ，若你能在拥有目标、结构的前置条件下，增加约束力懂得取舍，会发现“完成”的效率会大大增加。
这当中对于互联网公司的产品人来说，并不是那么容易完成某个项目的原因是什么呢？
我把它总结为四个字“忽悠思维” ，很多软件公司销售为冲刺业绩，习惯对客户“画饼” ，承诺些产品本身还未做到的功能。客户付款后整个交付转移给了研发团队，最终完成的产品缝缝补补、如老人步履蹒跚的样子，客户怎么会满意？
那么全局思考下来，你会发现不论是“预判结构”还是“约束性”的设计，两者本身背后代表的是“组块”创新的能力。
工程本身是组块
此话怎讲？组块（chunk）是人类信息加工中最重要的形式之一；概念是米勒（G．MilJer ， 1956-1963）提出，主要分为动态和静态两种。早些年用在工作记忆中，他注意到某一工作记忆未在10秒内复诵便会消退，同时保存容量最多为7±2个单元。
从动态视角看，人通过几个相关的小项目整合成为一个大项目，减少基础块数，从而将信息控制在记忆（物理空间）所容许的范围内。从静态视角看，它是一个名词，具体指重新编码的结果或输出单位，为便于区别在英文中通常把前者称为“chunking” ，将后者称之为chunk 。
俄裔美籍作家“弗拉基米尔·纳博科夫”（1899~1977）提出的卡片写作原理与工程师思维的核心“模块化系统思维”均属于“组块” 。他们均指出这不是一项单一的才能，而是技术与原则融合；原因是：
一个系统因各模块之间的关系而成为一个整体，它们不能通过单独的分析各组成部分就能理解的。