(七)、通过基于模型的设计提高工作能力

        通常认为成功工作的唯一要求是能力。 然而，一个拥有正确技能但没有动力的人不会表现出色，而没有机会锻炼这些才能的有技能的人也不会表现出色。 三个要素对成功的工作表现至关重要：动机、机会和能力。 此外，管理人员必须提供明确定义的绩效目标。
        以下部分讨论了使用基于模型的设计来提高团队成员的积极性、机会和能力的方法。

 绩效和动力

        在某些时候，大多数经理都在努力寻找保持团队积极性的方法。 与官僚组织中层级组织的团队相比，有机组织中的小型内部管理团队更容易保持动力。 然而，对于任何组织来说，激励员工执行作为任何开发过程一部分的基本但重复的任务都是一项挑战。

        如果经理提供以下内容，他们甚至可以使这些例行任务充满动力：
        独立性，团队成员可以计划自己的工作并影响其结果。
        结果反馈， 团队成员看到他们的任务或项目的直接结果——反馈越直接，动力就越高。
        技能多样性，完成任务需要多种技能。 例如，编写和编译 C 代码只需要 C 编程技能。 然而，当任务还包括测试代码和设计界面时，它需要更多的技能，因此更有动力。
        任务同一性（项工作允许员工执行整个工作并清楚地识别其努力结果的程度）， 每个团队成员都为自己的工作感到自豪，并对其成果投入。
        任务的重要性，几个团队或个人取决于任务的结果。 依赖结果的人越多，任务的重要性就越高。

        通过基于模型的设计提高动机
        基于模型的设计支持并在许多情况下实现上述每个激励因素。

        独立性， 有了整个系统的模型，单个工程师就可以测试想法并试验不同的解决方案。 自动化可以增加单个工程师可以执行的任务数量。 例如，用于快速原型设计的代码生成意味着控件开发人员可以在不涉及软件工程师的情况下在目标上测试控制器。 模型或模型的一部分可以首先在高层次上实现，然后在更详细的层次上实现。 由于模型仍然与系统的其余部分进行模拟，因此开发人员在决定更改什么方面具有一定的自主权。
        基于模型的设计提供了使工作更加灵活独立的基础设施。 例如，使用系统模型，一个团队成员可以实现一个想法，然后通过用整个系统模拟它来测试它。 此外，基于模型的设计支持分散的开发方法，任务组或小团队负责特定的系统组件。

        及时反馈， 仿真几乎可以即时提供有关设计理念或修改的反馈。 例如，假设控制工程师的任务是选择最佳控制器增益。 使用传统方法（更改 C 代码中的参数、编译代码、将其下载到目标并针对硬件运行），工程师几乎没有动力进行实验。 需要更改多少参数？ 在找到正确的参数之前会对硬件造成多大的损害？ 使用仿真模型，可以在几秒钟内更改参数。 工程师可以快速且无风险地尝试许多新想法和参数。

        技能多样性， 基于模型的设计使团队成员可以轻松承担需要新技能的任务。 当所有项目信息都在系统模型中捕获时，更容易提供技能多样性，因为个人可以在团队中的不同位置之间轮换。 例如，通过代码生成，控制工程师等算法开发人员也可以负责软件。
        基于模型的设计支持垂直技能多样性（工作人员对系统或开发过程的不同部分承担越来越多的责任）和水平技能多样性（任务需要一系列技术技能）。

        任务同一性， 系统模拟为团队成员提供了“大局”。例如，模拟显示了他们工作的组件如何融入整个系统。 系统级视图扩展了每个工程师可以处理的区域。 例如，控制工程师可以使用仿真来提出硬件更改建议。 在某些情况下，您可以让工程师跟踪从概念到生产的开发过程。 如果需要专业化，您可以使用系统模型来可视化和演示流程中的后续步骤。
        通过自动化，控制工程师可以编写一个脚本来运行一系列参数并自动找到最佳设置。 找到最佳参数为解决方案增加了自豪感，因此增加了任务的同一性。

        任务的重要性， 仿真清楚地揭示了一个小组件对整个系统的影响。 管理人员可以使用模拟来展示任务或组件的重要性，或者它与其他部分和依赖关系的联系。 允许开发人员使用假设分析和模拟来探索他们的想法，让他们觉得他们的贡献是有意义的。        

表现和机会

        锻炼技能、影响项目结果以及提出或探索新想法的机会可能是最容易被忽视的绩效方面。 缺乏机会可能是组织结构、其他团队成员的技能组合或项目截止日期的限制的结果。 不管是什么原因，经理可以采取几个步骤来为团队成员提供更多表现出色的机会。
        例如：
        • 让他们能够访问关键信息、资源和人员。
        • 积极协商他们需要的资源。
        • 让他们有时间研究特殊想法或改进工作流程。
        • 建立一种共享知识和资源以及交流的文化。

        通过基于模型的设计增加机会
        确保员工有机会存在主要是一个社会和管理问题。 然而，基于模型设计的核心概念使团队成员能够通过探索和测试新想法为自己创造机会。 通过系统级仿真，可以以一种省时且经济的方式评估一个想法。 不需要昂贵的硬件或资源协调。 工程师甚至可以使用系统级仿真来针对整个系统测试他们的想法。 为此，管理人员可以建立一个开放的、可自由访问的存储库，其中包含所有相关模型。 这个存储库可以成为一种捕捉有趣且可行的新想法的机制。

表现和能力

        当然，能力是绩效的重要组成部分，大多数经理都投入大量时间和精力来提高团队的技能。 提高技能的传统方法是通过培训课程。 在许多情况下，培训的重点是改善弱点，这充其量只能达到平均水平。 不太正式的方法，如专注于个人的教练和指导，可能会更有效。 一个关键要求是每个人都意识到自己的潜力，并有一条通往成功的清晰道路。 对于许多人来说，拥有明确的目标是他们开始自学的充分动力。

        通过基于模型的设计开发个人能力
        基于模型的设计的工具、基础架构和核心概念可增强团队成员的能力。 例如，具有仿真功能的图形工具扩展了工程师理解和开发复杂系统的能力。 自动化（例如代码生成）使工程师能够更快、更高效地工作。 它还通过降低工程师在学习过程中可能犯错误的风险来提高工程师的学习能力。 人为错误通常是随机发生的。 诸如自动模型审查之类的自动化使系统化的纠错方法成为可能。 如果检测到错误，它会被修复并且再也不会出现。
        虽然一些工程师通过听或读学得很好，但许多人需要自己尝试。 对于这些人来说，假设分析是了解系统的绝佳方式。 工程师可以试验系统模型并了解其工作原理。 通过这种方式，工程师增加了他或她自己的知识，并为整个团队的知识做出了贡献。

提高团队绩效

        为了提高团队绩效，经理必须制定长期目标并激励团队成员朝着这些目标努力。 当所有成员都朝着同一个目标努力时，团队绩效是最佳的。 让团队成员参与目标的制定可以增加动力和承诺。
        管理团队绩效取决于有效的沟通，尤其是当团队跨职能或地理位置分散时。 模拟环境和模型的引入为整个团队提供了一种共同语言，即使团队成员拥有不同的专业领域并且来自不同的国家。

【案例】提高汽车测试工程师的积极性和表现

        一家大型汽车公司的测试工程师负责在软件平台或应用程序发生变化时实施新的测试用例。 该任务具有高度的任务意义——测试系统具有明确的目的并且是开发过程的重要组成部分。 没有它们就没有系统测试执行和发布，这意味着其他人依赖于此任务。 然而，与此同时，测试用例的实施是重复的和常规的。
          经理可以做些什么来使这项例行任务变得有价值？ 能否将任务转化为激励工程师提升的机会？

        使用传统方法
        使用传统方法，测试工程师会在新版本发布之前收到一份文档。 该文档详细说明了更改并指定了测试用例的数量、要使用的输入信号以及正确的输出。 工程师从配置管理系统中检出测试系统代码，添加新的测试用例，并执行系统以验证更改。 这只是一个虚拟测试，因为对应用程序或平台的更改尚未实施。 实际的测试执行在流程的后期完成。 如果没有编译器或执行错误，工程师检查代码，更新测试系统文档，并将其发送给项目经理。
        传统方法给予工程师非常有限的自主权——启动任务的报告被移交，工作是预先确定的。 只有在出现实施错误时，工程师才会收到反馈。 由于一旦运行虚拟测试，工作就完成了，工程师只能看到工作流程的一小部分，永远不会知道真实测试的结果。 唯一需要的技能是基本编程以及添加测试用例和编译代码的能力。
        因为测试用例创建是开发过程中一个既定的、定义良好的部分，改变它会影响其他部分。 工作的任何部分都不能删除，因此唯一可以进行的更改是添加到任务中。 经理不愿意这样做，担心增加已经没有回报的任务会降低而不是提高绩效。

        使用基于模型的设计
        通过应用基于模型设计的核心概念，可以使实施测试用例的任务更有动力。 它还可以旨在提高工程师的技能组合，并为工程师提供出类拔萃的机会。
        例如，技能多样性可以大大提高。 作为实施测试用例的补充，管理人员可以引入正式的属性证明以及用于验证和验证的附加工具。 工程师可以有一个副项目来开发一个自动化测试过程，每晚构建并自动执行测试用例。
        经理可以创建一个测试设计工作组，其中包括实施测试用例的工程师、运行测试的工程师以及编写测试用例规范的工程师。 该工作组可以定期开会以确定测试过程的问题并讨论改进方法。 成员可以花一些时间来实施改进。
        让测试工程师实施改进并参与任务组会议可显着提高积极性和工作满意度。 反馈得到改善，因为测试工程师是看到测试总体结果的团队的一部分。 任务同一性增加是因为工程师看到了更多的过程并且能够影响结果。 技能多样性增加，因为需要更多技能来开发流程和实施改进。 任务重要性也会增加，因为影响整个测试过程会影响组织的其他部分。
        随着工作组的启动和运行，经理可以从监督团队转变为指导和建议，从而继续提高团队的绩效。