性能驱动设计 Performance-driven 之三

Druck · 发表于 2020-5-12 17:05

EDA365欢迎您登录！

您需要登录才可以下载或查看，没有帐号？注册

x

本帖最后由 Druck 于 2020-5-12 17:10 编辑

性能驱动设计 “PeRFormance-driven” Design 之三

性能设计，不是一下子能够揭示出其内涵。因为很多人的惯性认知并不相同，层面也不同。还是举例来比较，解释一下。

性能设计 vs 功能设计 vs 系统设计
! d& v+ l7 f& N, I
例如，做这样一个产品 - 适合多种设备的便携式快速充电器。

这个产品的系统设计、功能设计，基本都是明白了。一旦产品定义确定下来，系统设计、功能设计相对都比较简单。

对于这样的一个产品来说，系统设计和功能设计都是可抄袭的、可模仿的，而真正的设计挑战是在“性能设计”上，或称“工程特性”设计上。
这个时候，不是功能设计主导，而是性能设计为主导。功能设计、系统设计，谁都可以做得出，但要达到性能的pk，就远远不是那么简单了。

很多人，对性能设计都不清楚，以为功能设计、系统设计都很OK，性能怎么会不行呢？  有这种想法的人，不在少数，也是正常的。但处于的层面是比较low的。

系统设计和功能设计者，往往从比较高的层面出发，堆砌出不胜繁复的设计，看似完美，其实没有现实可行性；另外一方面，往往还造成过设计。这样看似完美的系统设计和功能设计，往往会成为头重脚轻的空中楼阁。只是想的好。

上个世纪，以IBM、波音这些大企业的实践证明，系统设计做得相当好、相当完美，但最后设计实现的时候，会陷入：
“解决了一件事情的一个方面，另一方面脱节了。当改正了其中一个问题，其他的方面又出错了。团队不停地转来转去，无法搞定一个完全正确的方式，而且难以决定往哪个方向修改。”  从而导致系统性能远达不到设计要求。

最后经过漫长的攻关、延期，勉强工作了。整个项目所花费的时间和金钱是原来预算上百倍之多！

那么，比原先预算多得多的这么巨大的花费，跑到哪里去了？这是中间失败、走弯路的代价，被称作：是“人狼”吃掉了。

那么是系统设计做得不够好吗？不完全是。除了系统设计存在上面两大类问题，还有项目管理问题，更为重要的是一个后来被称作“复杂性灾难”的问题。

简单来说，“复杂性灾难”问题，是软件、硬件工程化设计问题。更为直白的说，软硬件工程设计特性问题。那个时代，“工程设计”还没有形成。

工程设计有其内在的规律和逻辑。复杂性灾难是由工程设计的高复杂度、一致性要求、可变性和不可见性等不确定性引发的。
规模越大的项目，不确定性越高，复杂性灾难会越大，被人狼吞噬（大大增加开发成本、拖延开发周期、甚至失败）的可能性就越大。

因此，系统设计和功能设计的时候，要对提防这些“复杂性灾难”。

解决“人狼”陷阱的方法，有：

1、注重性能设计，从工程特性设计出发，先寻找到系统设计的边界，不让系统设计、功能设计“裸奔”。

2、采用适合的开发工具、评测技术能有事半功倍的效果，切合实用的工具和技术是项目团队的重要财富。

3、更好的专业分工，性能设计、项目管理等等都需要各尽其职、各展其能。尊重专业设计，协同作业！

今天的电子产品设计，其工程特性设计越来越复杂，系统设计和功能设计的合格的区间越来越小。

而很多公司在理念上，还没有认识到性能设计已经成为系统设计、功能设计成功的条件。正由于此，很多开发公司很难上一个台阶。

只做系统设计、功能设计，这往往是Research的工作。优先完成技术性方案，可以先不管整体可实现性和成本等。

作产品开发，性能设计是优先的，成本和制造，甚至可维护性都成为产品竞争力要素之一。这时候的系统设计、功能设计是要以工程特性设计为边界的。
这样的团队作的工作是“Product Development” - 即产品开发工作。

换句话说，产品开发，是以性能设计、工程设计为边界条件的。

现在大多数企业的开发团队，都是以功能设计、系统设计为主要成员的。性能设计人员或者工程设计人员缺乏，甚至设计工具和平台都没有，只是凭经验来作性能设计。

性能设计可以凭借经验来做，但是经验是有限的。

新的设计环境下、竞争激烈，使得设计的复杂度、不确定性，有很大程度提高。靠经验是不可靠的。经验并不是持续成功的有效向导。

必须注重性能设计，才能够避免被人狼吞噬你的有限的宝贵资源。