美团|何为工程师思维?( 三 )


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