分享

总体设计工程师的几本必读书籍

 汉无为 2023-11-09 发布于湖北

有一个舶来的术语叫'架构师',尤其是在软件开发领域。依我的理解,架构师就是我们所说的总体设计工程师。车辆总体设计,英文是Vehicle Architecture,或者Vehicle Architecturing,不是Vehicle General Design。

图片

这些年的确看了许多书,每年或有一、二百本。于是,不时有朋友让我荐书。前几天向人推荐了一本《追时间的人》,还特地写了篇可供性 | 《追时间的人》的一个主题作为导读。

前文《系统思维》中的思维因子介绍了《系统思维:复杂商业系统的设计之道》的梗概。这本书与《系统架构:复杂系统的产品设计与开发》大致相当,对启迪系统思维很有帮助,知识点很多,也成体系,难读但值得用功。而且,这本书更多的是涉及思维模式培育、商业模式创新,对于随便哪个想有点出息的人,都值得读一下。

产品研发搞了近三十年,一直是负责总体设计。今天且把对总体设计有益的几本必读书(注:是我以为的)汇总一下,不拘哪个行业(只有'后见之明'那本对搞陆军装备的极其有益)。这几本书甚至可以作为手册和案头书,不时翻翻。

这些书都是译著,读者有可能遇到的最大问题是术语、语境理解的问题。这点需要功力来克服,不是一朝一夕的事,最好能够结合自己的工作实践经验来切磋理论。

总体设计的显性与隐性

图片

《犹太人思考术》中介绍了犹太人的四度思维空间:

            显而易见的显而易见领域,比如信息

            显而易见的隐而不见领域,比如知识

            隐而不见的显而易见领域,比如智慧

            隐而不见的隐而不见领域,比如直觉

了解与探索显而易见的显而易见领域,运用理性与证据揭示显而易见的隐而不见领域,以感性、爱把握隐而不见的显而易见领域,以信仰、承诺、行动吻合隐而不见的隐而不见领域。

再举几个犹太人的脑筋急转弯式的俗语,加深下对上面所述概念的理解。

什么是房租?     是一种对穷人的罚款。

什么是钱?        是一种我们喜欢得到,但不喜欢传给他人的疾病。

什么是悲观?     是一根会烧伤手的火柴。

什么是乐观?     是一根为我们照路的蜡烛。

什么是女人?     是一道闪电.它美丽而灿烂,直到击中你的脑袋。

什么是爱?         爱是奶油:只有搭配面包才爽口。

图片

上图来自《第四代研发》。下文摘自《系统架构:复杂系统的产品设计与开发》。

把系统的各个实体组合起来之后,一种新的功能,就会随着由这些实体的功能与实体之间的功能交互所形成的组合而涌现出来。系统是由一系列实体及其关系所组成的,系统的功能要大于这些实体各自的功能之和。

系统的形式领域是显而易见的。把部件A和部件B拼起来之后,形式领域内的结果就是A加B,除此之外没有其他效果。通过形式的聚合而产生的属性,计算起来是相对较为容易的。系统的质量就等于部件A的质量加上部件B的质量。形式是“线性的”(linear)。

然而,在功能领域中,部件A加上部件B的效果,却要有趣得多,也复杂得多。功能并不是线性的,一些功能甚至可能是隐而不见的。当部件A的功能与部件B的功能相交互时,任何事情都有可能发生。系统的强大,正是体现在涌现物的这一属性上。

《产品设计与开发》

图片

前文工程技术的认知层次中第二部分的四张图,全部来自这本书。通过下面这张图,可以大致感觉一下,原型化设计和我们概念中的原理样机有何不同?

图片

《产品设计与开发》是宾夕法尼亚大学沃顿商学院教授卡尔·T犹里齐和麻省理工学院斯隆管理学院教授斯蒂芬·D.埃平格合作编写的一本有关产品开发设计的教科书,将市场研究、工业设计、生产制造三方面有机地贯穿为一体.为产品的设计与开发提供了一条清晰而完整的思路,对全面理解产品的设计与开发的过程有十分重要的意义。书中的每一种理论和方法均用具体的实例来加以说明,使原来枯燥乏味的理论阐述变得生动而自然。


《再论项目研发后见之明》

图片

前文科技没有弯道中解读了书中的一张图(见下)。

图片《再论项目研发之后见之明》书中介绍了美国陆军重要武器系统研发中的关键技术事件,也就是重大技术问题攻关的简况。武器系统有四个:M1系列主战坦克、阿帕奇直升机、标枪、毒刺导弹。




《第四代研发》

图片

以下摘编自百度百科。

本书介绍了研发(R&D)的发展历程,并用大量的事实和数据阐述了第四代研发的定义及其重要的现实意义,以及第四代研发的关键问题:

  • 怎样掌握策略、革新和研发之间的联系纽带;

  • 为什么传统的市场研究并不够,以及怎样才是足够的;

  • 怎样把网络用于革新过程;

  • 隐含知识和明确知识之间至关重要的不同,以及为了有效的知识管理而将它们结合;

  • 新的组织模式对成功来讲是多么关键;

  • 连续革新和断续革新之间的不同,以及怎样使你的组织在这两方面都有效。

书中并没有对这些问题给出明确的答案,而是给出了一些丰富的、相互关联且逻辑严密的实例和论点,读者可以通过这些实例和论点自己得到答案。

图片

本书使用了近百幅图表,以流畅的文笔将论点深入浅出、循序渐进地介绍给大家,使读者对作者的观点有了形象而直观的认识。相信读者在看过本书以后也会对自己的思维模式有一个全新的认识。

图片

从本质上来讲,这是一本专业化很强且很有针对性的书籍,专门针对那些从事研究与开发、企业战略管理和产品开发设计的专业人士,对于正经历着改革和发展的关键时期的中国企业家来讲是不可多得的战略参考书。




《系统架构:复杂系统的产品设计与开发》

图片

《系统架构:复杂系统的产品设计与开发》由系统架构领域3位领军人物亲笔撰写,Amazon全五星评价。前文再论'边界条件制造'中已有转述。全书共分四部分。

第一部分(第1~3章)的重点是引出系统架构。第1章通过一些范例来展示架构理念,指出良好的架构,并给出本书的概要;第2章列出进行系统分析必备的思路;第3章给出分析系统架构所用的思维模式。

第二部分(第4~8章)着重对架构进行分析。第4章讨论系统的形式;第5章讨论系统的功能;第6章讲解形式与功能之间的映射,并以此给出系统架构的定义;第7章研究如何从独立于解决方案的功能陈述中衍生出系统;第8章演示怎样把这些概念汇聚成一套架构。

图片

第三部分(第9~13章)讲解如何为复杂的系统定义架构。第9章从任务和可交付成果这两方面来概述架构师的职责;第10章探讨如何把组织机构方面的接口当成在架构中减少歧义的契机;第11章讲述如何用系统化的方式来捕获利益相关者的需求,并把它们转换成系统目标;第12章提出一些能够帮助架构师更有创意地构思并选择概念的手段;第13章讲述在开发系统时管理复杂度的一些办法。

第四部分(第14~16章)探寻帮助架构师做决策的各种计算方法及工具所具备的潜力。第14章把系统架构的过程当成一种决策制定的过程来进行讲解;第15章讲解如何对架构权衡空间中的信息进行综合;第16章演示怎样把架构决策编码成一套模型,使计算机可以根据该模型自动生成权衡空间并对其进行探索。

不过,这本书很难读,一则是英文语境的表达方式很不相同,二则是专业术语翻译虽然中规中矩,但比较别扭。

比如,operand,指得是其状态会在过程中发生改变的事物,译成'状态参数'、'运行单元'要远比'操作数'逻辑表达通畅得多。

书中给的定义:

操作数(operand)   操作数是一个对象,因而有可能会在某段时间内稳定且无条件地存在。这种操作数对象,不需要先于功能的执行而存在,且会以某种方式为功能所操作。操作数可能会由功能中的过程部分来创建、修改或消耗。

图片

上面这张图叫轴辐图,大致可以直观理解;如果知道hub的另一个术语是路由器,大脑中的形象化理解是否更清晰呢?

这些困难,大家自己克服吧,毕竟这是非常有助于总体设计工程师提高内在功力的一本书。


《系统架构》给的架构与健壮度定义

转述一下《系统架构:复杂系统的产品设计与开发》给的架构和架构健壮度定义。

下面这两个关于架构定义的共同之处,在于它们都提到了系统的关键元素,也就是形式和功能、部分和整体、关系,以及涌现物。

(架构是)把功能元素组合成物理块时所用的编排方法。

   ——Ulrich及Eppinger

(架构是)一个由部分所组成的整体,这些部分之间具备某种关系,当把这些部分拼接起来时,这个整体就会表现出预先设计的意图,并满足某种需求。

   ——Reekie及McAdamt

架构一词还有很多种不同的定义,这些定义有的强调形式,有的强调功能,而且各自所要求的细节程度也有所不同。比如:

(架构是)系统的基本组织方式,它体现在系统的组件、组件与组件之间的关系、组件与环境之间的关系,以及决定系统的设计与进化的基本原则上。

    一ISO/IEC/IEEE Standard 42010

架构健壮度原则(Principle of Robustness of Architectures )

有三分之一的成本和三分之二的问题,都是由于非要去追求最后那10%的性能而引发的。

   ——Norm Augustine 第15 定律

“有九成的事情都比你预想的更糟,剩下那一成根本轮不到你来想。”

   ——Norm Augustine 第37 定律

好的架构要能够应对各种各样的变化。能够应对变化的那种架构,要么是比较健壮的架构,要么是适应能力比较强的架构。前者能够处理环境中的变化,而后者则能够适应环境中的变化。在帕累托效率方面最优的架构,通常都不是最为健壮的架构。因此,在选择架构时,要同时考虑帕累托最优性、健壮程度以及适应能力这三个因素

  • 在进行架构的过程中,我们对输入值所做的假设可能会发生变化,此外,设计方案的下游执行过程和/或系统的操作环境,也有可能发生变化。

  • 位于帕累托前沿中的那些架构,有时未必能够最为稳健地应对各种变化。比方说,帕累托最优架构可能依赖于一项能够改变行业规则的技术,但这项技术的成熟程度却相当低。万一这项技术在开发系统时还没有准备好,我们应该怎么办?架构是否能够较为灵活地与另外一种技术相适配?在帕累托最优性和健壮性之间所做的权衡,对于这个行业来说是否特别合理?可能有少数几种架构具备相当高的性能,但这些架构是否可行,则是架构师必须要决定的问题。

  • 为了评估健壮性,我们可以分析架构在多种技术场景和市场情境中的表现,然后选出在很多情况下都有着良好表现的那些架构。在对架构进行优化时,应该像本章所说的这样,用模糊的帕累托前沿来代替普通的帕累托前沿,因为这样做能够发现更为健壮的架构。

'大包大揽”是总体设计工程师的天职

函数只在定义域上才有意义——人若扭曲了环境条件,然后通过这种扭曲去理解现实,无知的程度甚至可能比一无所知或没有理性的人更严重。 犹太人有言云:一只已经停了的表,比或快或慢的表要好——因为每天它可以至少两次正确报时!

就目前的社会形态来看,无论如何标谤,行政系统管理者的整体行事倾向是大权独揽,而研制体系的技术管理则是努力把责任分担。根本原因,趋利避害是人的第一本能;因为运行规律的不同,不同系统中的人的应对策略必然不同。

按老子的说法,反者道之动。如果要达到'道'的境界,行政系统需要分权,技术系统需要集权。

    本站是提供个人知识管理的网络存储空间,所有内容均由用户发布,不代表本站观点。请注意甄别内容中的联系方式、诱导购买等信息,谨防诈骗。如发现有害或侵权内容,请点击一键举报。
    转藏 分享 献花(0

    0条评论

    发表

    请遵守用户 评论公约

    类似文章 更多