产品设计和研发的心理学基础——模块和接口设计原则

llbnmo

4 J( J. U+ u6 h- M& r

在前四篇文章中，讲到三个相关的心理学概念：掌控感、舒适区、自我承诺。以及由这些概念衍生出的产品设计原则。第五篇文章讲述了在组织活动中遵循设计原则最大的障碍是客户研究，本文着力于在研发管理方法层面如何实现这些设计原则。这个主题的系列文章写的有点多了，计划中只有四篇，但是一写就收不住了，是请各位耐心看我写完。本文中涉及到的设计原则会以粗体斜体字表示，请大家留意。

在实际的研发设计中，设计人员倾向于把一个复杂的系统分成简单地模块。每一部分都是具有独立功能，具有一致的几何连接接口和一致的输入、输出接口的单元，相同种类的模块在产品族中可以重用和互换，相关模块的排列组合就可以形成最终的产品。模块的划分可以使整个产品生命周期中的采购、物流、制造和服务资源简化，也可以在促进设计过程中的并行化。复杂系统广泛使用模块化的设计方法。

在实际设计中怎样划分设计模块呢？结合上文的设计原则，这里提出几条模块划分和设计原则。复杂产品的每个模块应该是“可感知和可转换的”、“自治的”、“弱耦合的”、“安全地”。下面为大家一一阐述：

“可感知和可转换的”指的是模块或者产品的状态是能够被明确定义的，并且这种状态符合MECE(相互独立、完全穷尽)原则的，对于外部系统而言，这些状态的状态可以被感知，也可以随意转换这些状态。比如，一个墙壁开关定义一般定义了两种状态：ON、OFF，外部可以知道开关状态，也可以操作这两种状态。作为民用品的开关这两种状态直接作为使用的状态控制电路，其“可被感知性”被定义为“清脆的声音”、“舒适的手感”（反馈原则、人体工学）“明显的ON、OFF指示”，甚至再进一步考虑到深夜使用的便利性，当开关处于OFF状态时其可被感知性被设计成“夜里会发光”（防错设计、可视性）。其“可操作性”被定义为可以利用开关对ON，OFF状态进行转化。

作为工业品的开关的“可被感知的”的原则应该做到开关时ON状态时会亮灯提示（反馈、可视），在开关的监测电路上上也会有其ON或者OFF的状态的检测接口供上级系统使用。模块的可感知性意味着设计人员应该事先规划好模块的符合MECE原则的状态树，并且能够把所处的状态呈献给上级系统。

$ U, Q+ U9 D. Q1 f! g. l

“自治的”、“安全的”指的是模块应该能够独立的完成一定功能或者任务。这个任务在没有输入的状态下，应该是“功能齐备的”并且“安全的”。举例：把现在自动驾驶汽车分为周围环境监测和决策的“控制模块”和汽车的驱动部分“行驶模块”。可以把驱动模块视为传统意义上的一辆全功能汽车。考虑一种极端情况：汽车正在高速公路上高速行驶，突然控制模块突然发现故障导致其停止运行。此时，驱动模块应该是什么反应呢？首先它应该做到，尽快的将控制权交给手动驾驶模式——手动驾驶的功能不能受到控制模块失效的影响，这种模块设计方法称为“模块自治性”（状态感知、反馈、防错）。

8 J+ t3 Y* f0 p' {

接上例：在控制模块切换时，车辆还在高速行驶，在控制权移交的过程中也应该体现安全原则。为了保障控制安全原则行驶模块应该做到如下安全措施：

• 检测安全带的状态后，计算最佳的制动距离（状态感知）；
• 打开合适的指示灯状态（双闪指示灯）来提示后面车辆不要跟车过紧，防止刹车中的追尾（防错、可视性）；
• 无论以前方向盘处于什么位置，要把方向盘打直，最大可能防止出现碰撞（防错、状态感知）；
• 发出声音、视觉、振动等一切能够提醒司机的手段通知控制模块失效，模式将要切换到手动操作（模式匹配、反馈）；
• 检测控制模块的失效程度和原因，给驾驶人以足够的维修支持（反馈、状态感知）；
• 使用各种手段通知司机马上将车手动驶离主干道，防止影响其他车辆行驶（防错、反馈）；
• 如果有远程通信模块，第一时间向车辆厂商、交通部门自动汇报，方便及时关注处理。（防错）；
  

! r0 G# B' ?) b- Y4 C8 @  V

. J) b+ h' `4 H' D& J& K

“弱耦合的”指的是模块间的联系尽可能的简单，“模块自治”和“弱耦合”的要求可以简单归纳为模块应该具备“高内聚低耦合”的特性。如果某两个模块间的关系比较复杂的话，最好首先考虑进一步的模块划分。高内聚低耦合的原则特别适用于软件领域，比如在代码而言，低耦合是降低你的代码的依赖，高内聚是能说清楚你的代码做什么用的；比如在面向对象的编程领域，低耦合，是指不同的类之间应尽量独立，使得代码的复用和扩展更为容易。高内聚，是指一个类实现的所有方法都围绕一个单一的功能展开。这方面深入的讨论参加知乎中的内容：https://www.zhihu.com/question/21386172?sort=created。高内聚、低耦合的模块、接口设计原则，在硬件领域和复杂系统领域也是适用的。

" p! p; G; s! B2 W+ r% s; D

8 _5 m" D- ^" Z! x% |0 I$ b

以上，介绍了模块设计的方法。在管理上谈大道理容易落地难，这是共识。在研发管理中这些原则怎样落地呢？在第五篇中已经谈了用户研究的落地方法，在本篇中，也同样要谈模块设计原则的研发管理。

) P1 X# M2 g  h' _) ^! Q' C* Z. {  O

9 ]1 u) x; g# s6 u! W  S: n; H% g

一般制造业企业在研发管理中特别容易犯的错误就是所有研发人员做同样的工作，这一群做同样工作的人中，做的时间长的厉害点的那个就是管理人员、主任工程师或者总工程师。比如，一个建筑设计院，每个工程师都是承担设计任务，每个工程师都是从头设计到尾端，对于利润丰厚的客户企业配置有经验的老工程师承担任务，对于利润较低的客户，企业让新工程师练手。

研发管理中应该认识到下面几个角色的主要职责是不一样的：

一般工程师：做某一个专业的设计工作，一般由企业新兵承担，需要经验方面需要老工程师指导（新手村）；

主任工程师：做某个专业设计工作的专家，是工程师发展的第二个阶段，其代表性的能力是能够独立开展本专业的设计工作（基础职业）；

专家级工程师：在工程师的第二阶段就可能之后工程师的道路就有了可以选择的余地（可以转职），专家工程师就是其中一个分支的第三阶段（一转）。其代表能力是在某个专业有专家级别的专业知识。

系统级工程师：做系统设计的工程师，系统一般涉及到多个设计专业。一般是由某个专业的主任工程师发展而来，与专家级工程师一样是主任工程师发展的第三个阶段（一转）。他的主要职责是完成概念阶段之后的总体设计阶段；

研发管理人员：工程师发展的第四个阶段（二转），一般侧重于负责研发项目管理和研发团队建设。

总工程师：工程师发展的第四个阶段（二转），其在不同的企业定位差异比较大，一般侧重于研发流程管理，负责研发平台、技术平台的建设。

今天文章中讨论的模块划分的原则和知识应该是哪一级别工程师应该具备的能力呢？一般在工程师第三个阶段（系统级工程师、专家级工程师）就应该具备这种能力。工程师队伍的建设一般由第四级工程师策划并实施，研发管理人员或者总工程师应该认识到，由主任工程师转职成为第三级别工程师的时候应该开展模块设计的相关培训和考核。反过来讲，没有经过这方面训练的工程师是不能从事系统设计的。

: i5 p6 g7 r7 s

工作都是从源头开始发力才会最省力。举例来说：产品经理是让企业作对的事，研发管理是按照正确的方法做事；儿童的教育比监狱教育更加有效；战略定位作用大于运营效率。在研发流程中，好的系统设计能够极大的降低后期模块的开发难度，糟糕的系统设计流毒深远（影响到模块设计、产品易用性、质量、可维修性、可测性、可维护性、生命周期…）而且系统设计一定成为定式后非常难以修改。最出名的例子是Qwerty键盘布局的设计，直到今天仍在沿用，被广大的外设厂家广泛采用。在键盘的历史上有过无数的才华横溢的设计试图改变这个糟糕的设计，结果都以失败告终。大家如果有兴趣可以参见文章：https://www.zhihu.com/question/20121876。

一个随意的、低效的或者糟糕的系统设计的更改成本可能高到企业无法承受，在最初的系统设计时就要正确是非常重要的。

( V) B$ ]6 A7 q( K
3 M5 o6 r. }# m" d# u

Uifhjvv

每一部分都是具有独立功能，具有一致的几何连接接口和一致的输入、输出接口的单元，相同种类的模块在产品族中可以重用和互换，相关模块的排列组合就可以形成最终的产品