系统工程师
Since death is the destined terminal of human beings, how to finish the life road will really matter. 既然人总是要死的，那就得讲究活法了。——《金山词霸》每日一句研发团队里作用互补的两类成员今天把SYSTEMS ENGINEER VS DESIGN ENGINEER——FUNDAMENTAL DIFFERENCES(发表于2017年9月22日)全文翻译过来。论文作者是卢伦斯·蓬特(Louwrens Punt），Pronex工程管理咨询公司的执行经理。前文系统设计师：主导从需求到产品的全过程，翻译的是该作者的另一篇文章。而这两篇文章，在团队建构与研发供给中曾有过概述。在我看来，错误地把一个设计工程师任命为系统工程师，可能会使项目的成功面临严重风险，反之亦然。在本文中，我将根据在各种重大采办项目中取得的实践经验，为这一观点提供简明的论据。下图作我关于这个主题讨论的支撑。原则上，系统工程师负责系统的”什么”部分，即系统所需的部分。设计工程师原则上负责系统的”如何”部分，即满足需求的解决方案。系统工程师系统工程师的核心任务是开发高级系统架构，以响应用户或客户的要求。这包括以下内容：??系统功能体系结构（功能分析）?? 系统概念设计和与特定物理结构无关的解决方案（设计和集成）?? 系统接口??? 分配给上述系统体系架构的系统需求系统工程师的心智模式是”打一套他能够处理的牌”。他必须在所设定的项目范围内优化系统。他的注意力主要集中在与特定物理结构无关的解决方案上。他不去关注硬件解决方案的细节，因为硬件解决方案是设计工程师的领域。设计工程师设计工程师的核心任务是找到满足系统工程师要求的解决方案。该解决方案是实际产品，可以是货架产品，也可以是要研制和验证的新设计。系统工程师与设计工程师之间的另一个基本区别，在于他们的思维方式和运作项目的方法。设计工程师的心智模式是技术卓越和对细节的关注。他希望提供最好的技术解决方案，他将努力实现这一点，很多时候，不顾忌计划日程和成本。需要外部能量（来自项目主管和系统工程师）来约束设计工程师，以保证其在进度要求、成本费用以及技术需求的范围之内。如果用反了如果您错误地任命了一位设计工程师担任系统工程师，而设计工程师的行为模式是追求技术卓越，这将导致以下两点：? 由于过于强调技术解决方案，进度拖延和成本超支。? 技术需求逐渐蠕变（由于关注技术而希望提供更多投入），同样导致进度拖延和成本超支。如果你错误地任命了一名系统工程师担任设计工程师，他会将工作重心放在与特定物理结构无关的解决方案上，在细节设计层次上可能缺乏技术专业知识。这也将导致项目费用超支和进度拖延，并且可能根本不找到可实现的技术解决方案，或者解决方案不能满足用户需求。项目经理负全责显而易见，对设计工程师与系统工程师的恰当任命对项目的成功至关重要。考虑到项目的规模和复杂性，成功的开发团队需要系统工程能力和设计工程能力之间的适当平衡。项目经理最终负责该项目。但是，他将项目技术方面的责任委托给系统工程师，系统工程师应牵头确保系统技术能够满足用户相关需求。技术协调全局统筹的”60/80”准则在前文?80分万岁中简略提到过技术协调全局统筹的“60/80”准则，和蓬特的观点有相通之处：在整车任务分解制订研制任务书时，对于各分系统和总成部件技术性能的先进性要求，要明确60分和80分两个分数线，一定要及格，达到80分就算了，否则，整车承担不起。另外，与蓬特先生的认知有点区别，以笔者自身的体会，杰出的系统工程师要具备能做设计工程师的能力，在技术管理中做到“罩得住，兜得起”：确保设计工程师受到有效约束，并且能够进行与特定物理结构有关的解决方案抉择；在具体总成部件发生技术问题时，能够解决设计工程师无法解决的问题——毕竟，只有系统工程师才有“乾坤大挪移”、“头疼医脚”的功夫。当然，要意识到蓬特先生所谈及的两种心智模式：做过设计工程师的系统工程师，只要用系统工程师应有的心智模式思考，一定会很杰出。换种说法。笔者曾经经常强调：设计工程师是厨师，系统工程师是美食家。?每日一文——第746篇。
