2019年/11月/02日
设计飞机
这篇文章是我看了一本书之后的笔记和感想,这本书叫《我是怎样设计飞机的》,作者是美国飞机设计师凯利,本书是他的自传。因为工作阅历的关系,我现在比较喜欢看自传,唯传记方可洞察内心。
作者1910年生,1990年去世
凯利家一共九个孩子,人穷志坚,受父亲的影响,从小动手能力极强,有一天他走进镇上的一所图书馆,开始疯狂的阅读关于飞机的书籍,从此迷恋上了它,于是开始立志要做飞机设计师,这一信念让他仅仅在12岁的时候就写了一本关于航空领域的书。
但是命运第一次给他开了玩笑,玩耍时被妹妹射出的一支箭击伤了左眼,失明了,虽然后面慢慢恢复了,可还是影响了他以后的人生轨迹,然后就是二个玩笑,高中时,就患上了胃溃疡,这个病伴随了他一生。
进入大学的凯利非常努力的学习航空学基础知识,和同学一起在风洞里无数次的做实验,在这个阶段凯利身上开始体现出一个素质:如果对于某种观点他于别人不同,他会直言不讳的说出来。
大学毕业了,他和同学开始找工作,可是根本找不到,因为缺钱,有时候晚上睡在了铁道上,差点丢了性命,于是他返回学校,开始继续深造,继续着非常多的风洞实验。取得硕士学位之后,开始继续找工作,好在很顺利,被录用了,录用的最重要原因 是他为这家公司的飞机做过风洞实验,性格使然,刚上班,凯利就直言不讳的说出了这家公司的飞机有着稳定性问题。
有了工作之后,凯利开始了他专心致志的飞机设计生涯,频繁的飞上天空,修正设计,找寻方案,和公司的会计结婚,开始购买房产,购买农场,人生过得非常完满,一度升职到了总裁,获得无数殊荣. 不过生活中会有些滑稽的玩笑,有一次,在自家的农场里,凯利差点被一头牛踩死了,这让他不由得感叹,天空远比地面要安全。
如果工作紧张和出现危机,凯利的胃溃疡就会发作,有时只能靠饮酒来缓解,医生建议他休息,于是很长时间内他只负责高层技术任务,设计飞机是个必须全流程跟踪的工程行为,凯利不是属于那种只站在高层指挥的人,于是再次的投入实干前线, 当然,胃溃疡又会频发的发作,后果就是胃一半被切除了。
胃溃疡是一个折磨,但是起码不会要人命,但是命运开始给凯利开第三个玩笑,他的妻子得了癌症,伴随着五年的痛苦,妻子去世了。
前妻嘱咐凯利你需要再找一个人照顾你,于是上天给凯利派来了一个”甜心”,但是好景不长,”甜心”得了糖尿病,视力,肾衰竭,行动能力都丧失了,于是命运给了凯利10年的痛苦期,他需要忙碌的工作之余照顾不能自理的妻子直到”甜心”去世。
晚年,凯利和他的第三任妻子住在牧场里,和牛群打交道,和孩提时的时光互相辉映,命运总算把安静和美好赋予给了这个老人,在书的末尾,凯利是这样说的:
我生命中的最后一章还没写完,但是,即便今晚上帝召唤我,我也已经享有超过我应该享有的份额了
我经历了贫穷和富有,奋斗成功,默默无闻到声名显赫,疾病和健康,痛苦和喜悦,幸福和爱情。
所有的一切都已经超过我应该享有的份额了。
描述凯利的生活,只是想让你我感知一个有血有肉的人所经历的悲欢,接下来的文字描述的是凯利的工作哲学:”臭鼬工厂”法则, 这个工厂的运转高效,生产的产品质量可靠,其工作法则是很多高科技公司的学习对象,为什么? 飞机是工程作品,需要理论,需要实践,需要人人的协同配合,需要高效的管理。”臭鼬工厂”里,他们能够快速的决定,快速的实施,
管理规则:
- “臭鼬工场”的经理必须有对项目的各个方面都有完整控制权,他直接向部门总裁或更高的领导负责。
- 军方和企业的参与者都应当专业而精干。
- 必须严格控制参与项目的人员。只使用少量优秀人才,大约为所谓的“正常”情况人数的 10%到25%。
- 制图及发图流程必须非常简单,修改必须足够方便。
- 正式的报告应当尽量精简,但重要的工作应当全部有记录可查。
- 成本应当逐月审查,不仅要计算已经花掉或已预付的费用,还应预计整个项目的成本。不允许90天之后才记帐,也不允许拿超支对客户搞突然袭击。
- 充分信任承包商,赋予承包商更大的责任,以便它们找到足够优秀的分包商。民用产品的招标方法往往比军方的好。
- 当前使用的检验制度应当继续沿用。并且要推动制造商做更多的检验,不要为没有用的检验付费,也不要搞太多重复检验。
- 承包方必须有权在飞行中实地检验其交付成品。承包方必须有能力,而且必须在初期就做好检验,否则,剥夺其设计其它飞行器的资格。
- 在签订合同之前就必须对硬件的规范达成协议。推荐使用“预发展型号部”的方式,要有一份规范清楚说明将有哪些不符合军用规范的条款及其原因。
- 在合同签订之前就应当对规格达成共识。在开展工作之前,务必确保在此领域大家互相理解,否则,就要准备成立一个庞大的合规部门来消除混乱。
- 项目资金应当及时提供,不让承包方为政府项目反复跑银行。
- 军方的项目人员和承包方应当有足够信任,密切合作,每日联系,这样才能把误解和文书工作减到最少。
- 项目外的人员要接触项目或者项目成员,都必须有合适的保密措施严格控制。
- 因为只有少数人参与工程设计和大多数其它领域,必须对绩效好的人提供足够的激励,而不能根据人数来确定奖金。
英文版:
- The Skunk Works manager must be delegated practically complete control of his program in all aspects. He should report to a division president or higher.
- Strong but small project offices must be provided both by the military and industry.
- The number of people having any connection with the project must be restricted in an almost vicious manner. Use a small number of good people (10% to 25% compared to the so-called normal systems).
- A very simple drawing and drawing release system with great flexibility for making changes must be provided.
- There must be a minimum number of reports required, but important work must be recorded thoroughly.
- There must be a monthly cost review covering not only what has been spent and committed but also projected costs to the conclusion of the program. Don’t have the books 90 days late, and don’t surprise the customer with sudden overruns.
- The contractor must be delegated and must assume more than normal responsibility to get good vendor bids for subcontract on the project. Commercial bid procedures are very often better than military ones.
- The inspection system as currently used by the Skunk Works, which has been approved by both the Air Force and Navy, meets the intent of existing military requirements and should be used on new projects. Push more basic inspection responsibility back to subcontractors and vendors. Don’t duplicate so much inspection.
- The contractor must be delegated the authority to test his final product in flight. He can and must test it in the initial stages. If he doesn’t, he rapidly loses his competency to design other vehicles.
- The specifications applying to the hardware must be agreed to well in advance of contracting. The Skunk Works practice of having a specification section stating clearly which important military specification items will not knowingly be complied with and reasons therefore is highly recommended.
- Funding a program must be timely so that the contractor doesn’t have to keep running to the bank to support government projects.
- There must be mutual trust between the military project organization and the contractor with very close cooperation and liaison on a day-to-day basis. This cuts down misunderstanding and correspondence to an absolute minimum.
- Access by outsiders to the project and its personnel must be strictly controlled by appropriate security measures.
- Because only a few people will be used in engineering and most other areas, ways must be provided to reward good performance by pay not based on the number of personnel supervised.
书中格言
如果用脑力都无法完成的话,只靠体力加班也是完成不了的
不强迫别人工作,不鼓励长时间工作
我们的目的是应用常识更经济,更快,更好的解决难题,取得结果
如果原本就很好,就没有必要修整
简单点,傻瓜
快速,保密,按时
认真听,而不是说
了解飞机的整个研发过程
不可能找到一种好方法通用与研制所有飞机
设计者和制造者都应该参与测试
委员会设计飞机不见得会有绝妙的结果
早会简短,非正式
这本书看完了,获得了什么呢?对于我来说,我可以用书中的观点来反思我所经历的软件开发项目,我会对比我所经历的人间琐事, 按照凯利的风格,在一个可靠的工程项目中 架构设计者是必须要有代码素养的,是可以在前线解决问题的,而不能仅仅站在高层视觉。
下面这段文字来自于豆瓣:
重要的事是这样一些:
1、信仰上帝。当你处境困难,患病或者遇到危险,设法坚持到光明日子的时候,你的信仰是支持你最重要的思想之一。
2、健康。一个人没有健康的身体,就不可能是真正幸福的人。健康无疑一直是我生活中的重要因素。
3、目标。我们自己想干什么事情的时候,必须有自己的人生目标,而且要达到这个目标。这会给你提供你们所需要的东西——安全、金钱和其他各种报酬。
4、有一个爱你并了解你的妻子或丈夫。
5、...
前不久,波音的737Max坠机了,调查出来是软件问题,这里有一篇别人写的文章,你可以继续阅读,摘录如下
短粗的发动机
什么是架构?
软件架构是有关软件整体结构与组件的抽象描述,用于指导大型软件系统各个方面的设计
记下两个关键词:整体和抽象
架构为什么重要?最简单的答案是:因为它真的很值钱
架构是一种权衡
考虑架构时,要重点考虑它当初做出的权衡,不了解这些权衡就没有真正理解这个架构。不要轻易使用”小聪明”去解决架构级冲突,而应该考虑调整架构,或者选用与架构没有本质性冲突的部件
架构权衡的是整体利益
把整体利益拆分成多个清晰的子目标,深入理解每个子目标的商业利益、风险和代价,在各个子目标之间小心权衡。当你对某个子目标过度狂热时,请先冷静下来想想它会牺牲哪些子目标
架构要不断演化
架构师是技术和商业之间的桥梁,不要闭门造车。架构是随着商业而不断演进的,要抑制技术至上的冲动
架构师的责任和职业精神
如果往简历中写进一个先进的技术,意味着可能给雇主或客户带来灾难,那么,放弃这种冲动。设计经典级架构的机会可遇而不可求
This is a fundamental issue of software. Programmers must not be treated as requirement robots. Rather, programmers must hae intimate knowledge of the domain they are programming in. If you are writing code for aviation, you’d better know a lot about the culture, disciplines, and practices of aviation.
- We have to know the business domains we are coding for.
- We need to have the knowledge and insight to foresee and manage the risks our code might incur.
- We need to employ the practices and disciplines that keep our users, our customers, and our employers safe.
- We need to have the courage to say “No” when we assess that the risk of deploying our code is too high.