此知识领域关注于支持团队能够执行系统工程。一旦使用本文描述的技术完成这些工作，就可以应用第3部分(系统工程与管理)中关于如何执行SE的知识。第5部分，启用系统工程，这个知识领域属于它，探讨了如何在组织的三个层次上启用系统工程(SE):业务或企业、团队和个人。

为了简单起见，在这个知识领域的大部分内容中，术语“业务”指的是“业务或企业”。要了解业务与企业区别的细微差别，请参阅启用系统工程。

主题

SEBoK的每一部分都由知识领域(KAs)组成。每个KA围绕一个与部分的整体主题相关的主题将主题分组在一起。这个KA包含以下主题:

• 团队的能力
• 团队动力
• 系统工程技术领导

概览

产品、企业系统和服务是由系统工程师开发、交付和维持的，系统工程师还协调组成一个程序的多个项目的技术方面。这些活动要求某些个人以合作的方式工作，以实现基于共同愿景的共同目标——也就是团队。并不是每个在一起工作的个体都是一个团队。为了高效和有效地执行SE活动，团队中的能力和动态必须特别适应SE。

虽然个人有时执行SE活动，但是项目团队在提供专业工程能力的同时执行SE活动更常见(参见系统工程和专业工程)。并不是所有执行SE活动的人都被标记为“系统工程师”。因此，IT组织中的电气、机械和软件工程师、服务提供者或企业架构师可能领导或成为执行SE任务的团队的成员。在这个知识领域中，这些人被称为系统工程师，不管他们在组织中的职称是什么。

此知识领域涉及使项目团队执行SE活动的方法、工具和技术。它的第一个主题“团队能力”回答了以下问题:

• 企业如何确定由项目团队执行的SE活动所增加的价值?
• 组织如何确定项目团队执行的SE活动的效率和效果?

它的另一个主题，团队动力，回答了这个问题:

• 团队动态如何对系统工程师执行工作和实现目标至关重要?

SEBoK其他地方的主题涵盖了相关问题，包括系统工程和项目管理之间的关系，以及项目结构和治理对系统工程和项目管理关系的影响，回答了这个问题:

关于管理执行SE活动的系统工程师和项目团队，经理需要知道什么?

团队能力

一个团队执行系统工程(SE)的能力依赖于有能力的人员、充足的时间、充足的资源和设备，以及适当的政策和程序(Torres和Fairbanks 1996)。

团队应该有一个章程。工作人员必须精通所需的能力，并且必须以正确的态度，在正确的组织下，以及使用适当的工具、培训和过程(如配置管理和同行评审)一起工作。

那些负责团队获得期望能力的人需要组织、员工、发展和评估团队。试点项目的技术、事后分析和经验教训也可以应用。

组织团队

项目团队，以及这些团队中系统工程师的角色，取决于项目的性质、规模和范围、组织组织团队的首选方式以及外部约束（例如项目可能在其中的更大的计划）等因素。被嵌入。 选项范围从专门的系统工程师团队到集成产品团队，再到包括执行系统工程的其他类型工程师的团队。

系统工程师和 SE 团队可以扮演技术主管、顾问或顾问的角色； 这会影响 SE 团队的组织方式。 在一些组织中，系统工程师和 SE 团队提供技术领导； 他们执行需求分析和架构设计，进行贸易研究，并将需求和接口分配给系统的各个元素。 此外，他们与组件专家合作，制定集成计划并执行系统集成、验证和确认。 根据工作范围，他们还可以安装系统并培训操作员和用户； 提供持续的服务以维持系统； 并淘汰/更换老化的系统。 系统工程师可能被安置在组织的功能单元内，并以矩阵方式分配， 项目和项目群，或者在该努力期间它们可能永久附属于项目或项目群。 他们的组织可能部分基于他们的专业领域，例如金融或电信。 有关组织选项的更多信息，请参阅 确定企业和企业所需的系统工程能力 。

在其他情况下，一名或多名系统工程师可以根据要求为项目和计划提供咨询或咨询服务。 这些工程师可能从组织内的中央池中派出，也可能从外部机构雇用。

一个 SE 团队可以按工作专业化组织，其中每个 SE 团队成员（或每个 SE 子团队）扮演不同的角色； 例如，需求工程、系统架构、集成、验证和确认、现场测试以及安装和培训。在这种情况下，各种工作专业通常由首席系统工程师协调。

或者，SE 团队可以按子系统组织，其中每个 SE 团队成员（或 SE 子团队）为每个子系统执行先前指定的功能，并与顶级团队协调需求分配、接口、系统集成和系统验证和确认。

理想情况下，将为每个项目或项目群建立角色、职责和权限，并用于确定组织团队的最佳方式。 然而，有时， 先验的 组织、项目或项目群结构可能会决定 SE 团队在项目或项目群中的结构、角色、职责和权限； 这可能是也可能不是最佳的。

在一个项目中，系统工程师或 SE 团队可能担任项目经理下属的工作人员职位，如图 1 所示，或者相反，SE 团队可以向客户提供与项目经理或管理团队的权威接口，服务于人员能力，如图 2 所示。在这两种情况下，SE 和项目管理必须协同工作，以实现产品属性、进度和预算之间的平衡。 Eisner (2008) 列出了组织系统工程师的各种方法。 有关其他信息，请参阅 系统工程和项目管理 。

图 1. 隶属于项目管理的 SE 团队。 （SEBoK 原创）

图 2. 隶属于系统工程的项目管理。 （SEBoK 原创）

在扩大到项目级别时，可以概括图 1 和图 2 中描述的考虑因素，以便顶级 SE 团队在下级项目之间提供协调。 在这种情况下，每个项目都有一个 SE 团队，并且在每个项目中，SE 团队成员可以按照图中所示的任何一种方式进行组织。 当扩大到项目时，图 1 和图 2 中的每个子系统都是独立的、协调的项目。

图 1 和图 2 中呈现的模型可以缩小到较小的项目，其中单个系统工程师执行 SE 活动，无论是在图 1 的从属位置还是在图 2 的上级位置。在这种情况下，只有一个子系统（即系统）和支持功能可以由系统工程师或更大组织的支持元素提供。

SE 团队成员所扮演的角色受到作为团队运营所在业务的组织战略的一部分所采用的结构的影响（请参阅 系统工程组织战略 ）。 例如，在以产品为中心的组织中，为系统分解结构 (SBS) 的每个元素分配了一个集成产品团队 (IPT)。 每个 IPT 都由为该系统元素执行系统工程功能所必需的技术学科的成员组成。

在项目级别有一个顶级 IPT，通常称为 SE 和集成团队 (SEIT)，其目的是监督所有较低级别的 IPT。 一些专家，如可靠性和安全工程师，可能会被分配到一个团队中，以涵盖 SBS 给定级别内的所有元素。 这些团队有时称为分析和集成团队 (AIT)，并根据需要在 SBS 的各个级别创建。

由于N 个工程师 之间的通信路径数为 N(N-1)/2 ，因此在一组系统工程师之间组织沟通和协调应遵循众所周知的 7±2 规则； 即，全连接图中的链接数（Brooks 1995）。 5 名工程师之间有 10 条通信路径，7 名工程师中有 21 条，9 名工程师中有 36 条。 一个 10 人以上（45 条路径）的 SE 团队应该由一个顶级团队 负责 人按等级组织。 子团队可以按产品子系统或流程工作活动（分析、设计、集成）进行划分。

为团队配备人员

一旦了解了 SE 团队的组织结构，就可以为团队配备人员。 正如在使 个人 中提到的那样，个人的能力体现在个人有效和有效地执行特定任务所需的知识、技能、能力和态度上。 在不同的情况下可能需要不同级别的能力。 胜任力包括职业胜任力、社交胜任力和沟通胜任力。 例如，称职的系统工程师具有 SE 知识、技能和能力； 进行 系统思考 ; 拥有情商； 并具有良好的沟通和谈判技巧。 此外，胜任的系统工程师通常胜任特定领域（例如航空航天、医学、信息技术）和系统工程的特定过程领域（例如，需求、设计、验证和确认）。 （有关特定过程领域的更多信息，请参阅第 3 部分， 系统工程和管理 。）关于 角色和能力的文章 包括 SE 能力模型的摘要。 根据上下文，这些能力模型被定制以匹配每个项目的需求。 定义了团队中的角色，并将能力与角色相关联。 这些模型中给出的能力列表通常分布在 SE 团队的成员中。 一个人通常不会拥有这些模型中给出的完整能力列表。

除了执行 SE 角色的个人能力之外，团队所需的集体 SE 能力还取决于其他因素，包括领域、利益相关者、工作范围、结果的重要性、新举措与增强以及分配的职责和权限到团队。 例如，为一家小公司开发 IT 企业架构所需的集体 SE 能力与开发在世界各地以分布式方式设计和制造的飞机架构所需的集体 SE 能力完全不同。

要确定 SE 团队执行项目或项目群所需的综合能力集，请执行以下步骤：

1. 识别上下文，包括：
   1. 领域
   2. 利益相关者
   3. 组织文化
   4. 努力范围
   5. 产品、企业努力或服务的重要性
   6. 新的倡议或维持项目
2. 明确系统工程团队的职责、权限和沟通渠道
3. 根据上下文、职责和权限确定系统工程师和其他项目人员所扮演的角色
4. 确定填补每个系统工程角色所需的能力和能力水平
5. 确定为每个角色提供能力和能力级别所需的系统工程师数量
6. 确定所需系统工程师的可用性
7. 根据所需系统工程师的不可用进行调整
8. 以促进 SE 团队内部以及整个项目或项目群的沟通和协调的方式组织系统工程团队
9. 咨询利益相关者，询问“我们缺少什么？”

胜任力模型和技能清单，例如 INCOSE (2010) 和 Curtis 等人。 （2001 年），可用作清单，以帮助确定产品、企业或服务所需的能力和能力水平。 （请参阅 角色和能力 。）

确定所需的能力、能力水平和能力后，将出现以下两种情况之一： 或者，由于资金不足，它们将无法使用或无法提供。 例如，一项新计划可能需要一名首席工程师、一名需求工程师、一名系统架构师和一名系统集成测试员来完成系统工程任务。 预算限制可能表明只能支持四个角色中的两个。 必须做出妥协；

发展团队

在执行 SE 的团队有效之前，它需要建立自己的身份、规范和文化。 众所周知的 “形成、冲击、规范、执行” 四个阶段（Tuckman 1965, 384-399）表明，一个 SE 团队需要时间来形成，以便成员相互了解和理解以及任务被执行，并找出如何最好地一起工作。 同样重要的是要注意确保最大程度地分配角色和职责，使 SE 团队成员能够满足他们的个人目标（Fraser 2010）。

凝聚力的 成本和时间 可以通过对 SE 团队的良好选择和管理、对整个业务的持续培训、支持团队成员有一个共同的理解框架和工作语言、良好的“信息结构”来实现轻松和有用的共享来最小化信息，以及共享的行为规范和价值观。 相反，在跨站点、跨公司和国际 SE 团队中，必须为团队组建留出更多时间。 如果注意确保每个成员的工作满足他们的个人目标以及团队和组织目标，SE 团队会更有效（Fraser 2010）。

根据 Stephenson 和 Weil (1992)，有能力的人是：

懂得学习的人； 有创意； 具有高度的自我效能感，能在新奇和熟悉的情境中运用能力； 并与他人合作良好。 与涉及获取知识和技能的能力相比，能力是一个整体属性。

Steward Hase (2000) 的一项调查结果得出结论，以下因素是能力的人为因素的重要贡献者：

• 有能力的人
• 在团队中工作
• 可见的愿景和价值观
• 确保学习发生
• 管理变革的复杂性
• 展示领导力的人性方面
• 充当变革推动者
• 让人们参与变革
• 培养管理人才
• 致力于组织发展

人类能力的这些属性适用于组织的所有成员，包括系统工程师，无论是作为个人还是作为项目团队的成员。

DeMarco 和 Lister (1999) 讨论了“团队杀戮”技术，管理层可能在无意中通过这种技术来实施 可靠的射击技术来杀死团队 。 团队杀戮技术包括

• 团队成员的物理隔离
• 时间的碎片化
• 不切实际的时间表
• 过度加班

在团队中开发和提高 SE 能力的方法包括建立有凝聚力的团队、开展试点项目、参与和研究事后分析，以及准备和检查经验教训。 有凝聚力的系统工程团队的成员对工作和其他团队成员有强烈的责任感。 承诺会产生协同效应，从而导致绩效大于单个团队成员绩效的总和。

有凝聚力的系统工程团队（Fairley 2009, 411）的一些关键指标是：

• 清楚地了解系统工程的角色和职责
• 系统工程工作产品的共享所有权
• 系统工程师相互帮助和帮助其他项目成员的意愿
• 系统工程师之间以及与其他项目元素之间的良好沟通渠道
• 一起工作的乐趣

对这些指标的否定——功能失调团队的标志——是：

• 系统工程角色和职责的混淆
• 系统工程工作产品的保护性所有权
• 不愿互相帮助
• 系统工程师之间以及与其他项目元素之间缺乏良好的沟通
• 个人不喜欢一名或多名其他系统工程团队成员

构建和维护有凝聚力的系统工程团队的技术包括：

评估团队

绩效评估最常针对个人进行。 Robbins (1998, 576) 陈述了一种历史信念，即个人是构建组织的核心组成部分。 然而，评估团队的能力和绩效也很重要。 为了设计一个支持和提高团队（包括 SE 团队）绩效的系统，Robbins 提出了四个建议：

1. 将 SE 团队的绩效和整个项目团队的结果与组织的目标联系起来
2. 从团队的 客户 和团队为满足客户需求而遵循的工作流程开始
3. 衡量团队和个人绩效，并将其与组织规范和基准进行比较
4. 训练团队制定自己的措施

Robbins 的方法可以应用在 SE 的上下文中：

1. 将 SE 和整个项目团队的结果与项目和组织的目标联系起来。 使用适用于团队必须实现的目标的措施。 特别是对于 SE，团队努力应该与组织寻求交付的产品或服务联系起来。 SE 团队的最终产品不应该只是 SE 工作产品，而是项目提供的交付产品和服务。 有关一般 SE 评估的更多信息，请参阅系统工程 评估和控制 。
2. 考虑 SE 团队的客户以及更广泛的关键利益相关者以及 SE 团队为满足客户需求而遵循的工作流程。 SE 客户和利益相关者可以是内部的或外部的； 系统工程的内部客户是依赖于系统工程工作产品和服务的其他项目要素，可以评估其按时交付的数量和质量。 可以评估工艺步骤的浪费和循环时间； 即效率和有效性。
3. 评估个人和团队的表现。 根据生产团队工作产品必须完成的任务来定义每个 SE 团队成员的角色。 有关个人评估的更多信息，请参阅 评估个人 。
4. 最后，让团队定义自己的目标实现措施。 这有助于团队的所有成员了解他们的角色，同时也可以建立团队凝聚力。

例如，NASA 的计划/项目和工程领导学院 (APPEL) 提供了一项服务，其中评估团队绩效，并为团队提供针对特定绩效差距的干预措施 (NASA 2011)。 这种性能增强服务通过在正确的时间向项目团队提供正确的支持来增加项目成功的可能性。 APPEL 提供以下评估：

• 项目/团队有效性——衡量团队行为规范的有效性
• 个人有效性——衡量个人行为规范的有效性
• 项目/团队流程利用——衡量团队对关键流程的利用程度
• 项目/团队知识——涵盖 NASA 项目人员在工作中应了解的主题

APPEL 方法可用于评估 SE 团队和单个系统工程师的绩效。

建立团队能力的进一步技术

在团队中开发 SE 能力的其他技术包括开展试点项目、准备事后分析以及参与和学习经验教训。

试点项目

试点项目是一种有效的机制，社企团队可以借此建立团队凝聚力，获得新技能，并练习将新获得的技能应用于项目和计划。 试点项目可以仅出于获得技能的目的而进行，也可以用于确定解决问题的建议方法的可行性。 可行性研究和新团队技能的获得可以结合在概念验证研究中。 进行 SE 试点项目的主要障碍是所需的时间和人力资源的转移。

验尸分析

事后分析确定了未来项目和计划中 SE 绩效改进的领域。 事后分析的输入包括：

• 项目人员和其他利益相关者的个人反思和回忆；
• 在项目或计划期间收集的电子邮件、备忘录和其他形式的通信；
• 采取的成功和不成功的风险缓解措施； 和
• 变更控制委员会处理的变更请求和缺陷报告的趋势和问题。

团队参与事后分析可以让 SE 团队成员反思过去的努力，这可以提高团队未来项目的能力，或者，如果当前团队正在解散，则可以提高个人参与未来系统工程团队的能力。

有效的事后分析的阻碍因素包括未能分配时间进行分析、未能有效地汲取经验教训、未能充分记录结果、人员不愿坦诚其他人员的表现以及消极的社会和政治方面的一个项目或计划。 对 SE 项目进行有效的事后分析的机制包括使用第三方促进者、头脑风暴、强度-弱点-机会-威胁 (SWOT) 分析、鱼骨图 (Ishikawa) 和思维导图。

得到教训

在 SE 中学到的教训既可以是正面的，也可以是负面的。 从过去的项目和计划中获得和记录的经验可以成为开发和提高执行 SE 任务的团队能力的有效机制。 研究过去的经验教训可以帮助在新项目的启动阶段形成团队。 在当前项目或项目群中吸取的经验教训可以提高当前项目剩余部分和未来项目的能力。 用于开发和记录 SE 经验教训的输入包括过去的事后分析结果加上团队成员的个人回忆、非正式的 战争故事 ，以及分析电子邮件、状态报告和风险管理结果。 开发和使用 SE 经验教训的障碍包括在项目启动阶段未能研究从过去项目和计划中吸取的经验教训，未能分配时间和资源来开发和记录从当前项目或计划中吸取的经验教训，以及不愿讨论问题和问题。

团队动力

系统工程 (SE) 团队 是一 组个人，他们基于共同的愿景和一组共同的工程目标合作执行一系列 SE 任务。 应用小组动态的实际考虑对于使 SE 团队成功执行 SE 活动至关重要。 群体中人类行为的相互作用是多种多样的、变化的和不可避免的。 然而，对这些行为的研究已经对群体内个体的动态产生了宝贵的洞察力和知识。 群体动力学的认识和应用对于促进系统工程师的工作表现和实现他们的目标至关重要。

群体动力学的研究最初属于心理学范畴，后来属于社会学范畴。 团队动力对成功团队的重要性已导致其他学科（例如业务管理）研究和应用团队动力。

历史

群体动力学研究的起源始于 Gustave Le Bon。 勒庞在 1895 年写了 《犯规心理学》 ，一年后被 翻译成英文 《人群：大众思想研究》 。 西格蒙德·弗洛伊德（Sigmund Freud）在 1922 年写了《 群体心理学和自我分析》， 以回应勒庞的著作。 库尔特·勒温（Kurt Lewin）被公认为“社会心理学的创始人”，创造了 群体动力学一词 . 他于 1945 年在麻省理工学院创立了群动力学研究中心，并于 1948 年迁至密歇根大学。 Wilfred Bion 从精神分析的角度研究了群体动力学。 1947 年，他帮助创建了塔维斯托克人际关系研究所。同年，集团动力学研究中心和塔维斯托克人际关系研究所共同创办了《 人际关系 》杂志。 群体动力学的研究现在是世界范围内的、活跃的和成熟的。

团体性质

群体是人类生存和经验的特有种； 人是天生的社会动物。 因此，对群体性质的知情理解对于支持团队能够执行 SE 非常有用。 对群体行为的研究表明，群体的性质可以用互动、目标、相互依赖、结构、统一和阶段来描述。 (福赛斯 2010, 5-10)

相互作用

群体内成员之间的交流（口头和非口头）会产生不断变化和多样化的互动。 群体动力不仅仅是个体成员之间相互作用的总和； 群体互动产生协同行为和结果。 交互可以分为两类（1）社会情感交互和（2）任务交互（Bales 1950, 1999）。

目标

所有团体的存在都是为了实现一个或多个目标。 这些目标为小组的任务提供了基础。 小组完成的任务可以分为活动，并以 Circumplex 模型 (McGrath 1984, 61) 为特征，该模型建立了四个象限，其中 X 轴是 选择 与 执行 ，Y 轴是 生成 与 协商 。

相互依存

相互依赖是 在某种程度上依赖他人的状态，例如当一个人的结果、行为、思想、感受和经历全部或部分由他人决定时 。 依存关系可分为五种类型（1）相互的、互惠的； (2) 单方面的； (3) 互惠的，不平等的； (4) 串行； (5)多层次。 (福赛斯 2010, 8)

结构

结构包括一个群体的组织和模式化的行为。 结构可以刻意设计和/或紧急观察。 大多数群体都有这两种结构，这体现在群体的角色和规范中。 领导者和追随者的角色是许多群体的基本角色，但其他角色——信息寻求者、信息提供者、阐述者、程序技术员、鼓励者、妥协者、协调者——可能出现在任何群体中 （Benne and Sheats 1948; Forsyth 2010, 9） . 规范是管理团体成员行为的规则； 规范可以包括正式规则和非正式规则。

凝聚

将 成员结合在一个单一单元中的人际力量，其界限标志着谁在团体中，谁在团体之外， 构成了团体的凝聚力（Dion 2000）。 凝聚力是团队的基本素质； 它可以从弱到强。 没有强大的团队凝聚力，团队就无法有效地执行。

阶段

团体表现出发展阶段。 作为由人组成的，团体集体展示构成团体成员的个人的动态和成长也就不足为奇了。 布鲁斯·塔克曼（Bruce Tuckman）开发了最广为人知的群体发展阶段模型。 最初的模型将团体发展的顺序确定为（1）形成，（2）风暴，（3）规范和（4）执行（Tuckman 1965）。 他后来在模型中添加了最后一个阶段：(5) Adjourning (Tuckman and Jensen 1977)。 虽然 Tuckman 的模型是顺序的，但其他人观察到，组实际上可能在不同的阶段递归和迭代地进展 (Forsyth 2010, 20)。

实际考虑

与创建、培养和领导将成功实现团队目标的团队相关的动力是重要且具有挑战性的。 尽管心理学家和社会学家已经并继续进行研究以了解团队动态，但企业管理专业还寻求开发实用指南，以利用和应用这些知识来培养高绩效团队。 因此，企业管理通过出版实用指南来分析问题并专注于开发团队动态问题的解决方案，从而将其贡献集中在团队动态领域（参见其他参考资料）。 世界各地有许多咨询公司帮助组织将实践知识应用于团队动态。

多样性、公平性和包容性

多样性、公平性和包容性(DEI)促进组织的参与度、生产力和创新。

系统工程中的 DEI

系统工程师在将多样性、公平和包容性概念整合到他们工作的团队中以及系统设计和开发中发挥着关键作用。 特别是，系统工程师应该：

1. 确保系统工程团队及其领导层具有包容性，并欢迎多元化的人才，并在必要时采取慎重的行动以提供公平。
2. 确保我们实现的系统尽可能适应整个利益相关者社区内的差异。 这被称为“包容性工程”。

未能解决任何一个方面都可能导致次优结果，无论是错过解决方案、降低生产力，还是交付一个不能完全满足整个利益相关者社区需求的系统，即未能满足交付一个总体目标的最终目标最优系统解决方案。

系统工程师负责有效地传达多样性、公平性和包容性在支持、促进和推进系统工程和系统方法以应对复杂的社会和技术全球挑​​战的重要性和价值。

图 1 显示了包容性发展方法如何有助于在人类系统的背景下（无论是在组织、国家或世界范围内）实现包容性解决方案，而人类系统本身则设置在自然世界的背景下。 由于工程产品的整个生命周期（从概念到处置）与可持续发展之间的紧密联系，自然世界得以展示。 例如：

• 工业厂房造成的水污染影响附近居民
• 汽车造成的空气污染影响行人和居住在主要道路附近的人
• 产品报废/处置影响，例如有害物质，对垃圾填埋场的贡献

图 1. 包容性方法与包容性产品之间的关系。 （SEBoK 原创）

多样性、公平性和包容性的定义

以下定义取自工程和技术认证委员会 (ABET 2020)，它们为关于多样性、公平和包容性的对话和材料提供了参考点。

• 多样性 是人类差异的范围，包括使一个个人或群体与另一个不同的特征。 多样性包括但不限于以下特征：种族、民族、文化、性别认同和表达、年龄、国籍、宗教信仰、工作部门、身体能力、性取向、社会经济地位、教育、婚姻状况、语言、外貌和认知差异。
• 公平 是对所有人的公平待遇、访问、机会和进步，通过有意识地关注他们不同的需求、条件和能力来实现。 实现公平需要了解差距的历史和系统模式，以解决和消除障碍，并消除参与差距，作为实现公平结果和社会正义的综合战略的一部分。
• 包容 是所有成员尊重、支持和重视他人的有意、主动和持续的努力和实践。 一个包容的环境提供了对机会和资源的公平获取，使每个人都能平等参与，并在言行上尊重所有人。

通常，复合术语“多样性、公平性和包容性”（缩写为 DEI）用于指代广泛的学科领域。 所给出的多样性定义涵盖了广泛的特征。 例如，图 2 显示了国际系统工程委员会 (INCOSE)（Harding 和 Pickard 2019）认可的其中 28 个特征，分为五个领域：内在、就业、环境、互动和家庭。 该图显示了这些特征与 INCOSE 系统工程认证计划的相关性。

图 2. 多样性的分类维度。 （SEBoK 原创，改编自（Harding and Pickard 2019））

多样性、公平性和包容性与工程的相关性

工程师运用独创性、创新性和系统性方法来解决具有挑战性的问题。 生活经验和学术研究表明，运用广泛的技能、知识和思维方式来解决问题是加速和改善预期结果的最有效方法。 这些成果包括改善“……财务绩效、更大的创新和创造力、提高员工生产力和保留率、改善客户或客户导向，以及提高客户或客户满意度。” （皇家工程学院，2015 年）。 亨特等人。 (2018) 发现，在领导层中处于性别和种族/文化多样性前沿的公司在财务上表现更好。

相比之下，一个具有相同文化背景、生活经历、教育和思维方式的人的团队可能会相对不那么有效，并且更容易找到可预测的解决方案。 美国国家工程院 (2002) 指出在“没有想到的设计，没有产生的解决方案”方面缺乏多样性的机会成本。

包容，或确保每个人的包容感，对于确保所有团队成员真正感受到并相信他们的归属感是必要的，因此能够最大限度地发挥他们的才能和独特的视野。 相比之下，缺乏包容性可能会使某人感到在场，但没有参与或重视，从而导致整个团队无法实现最佳结果。

公平不等于平等，也不等于不平等。 它只是给需要的人更多，这与他们自己的情况相称，以确保每个人都有相同的机会。 在工程环境中，这可能意味着为处境不利的学生提供更多支持，以便他们充分发挥潜力，或者为患有阅读障碍等疾病的团队成员提供额外的支持或时间。

多样性、公平性和包容性与系统工程的相关性

DEI 对于成功的系统工程至关重要，因为它的应用范围很广，并且在方法的核心考虑了多个利益相关者的观点。 系统工程应用于各种环境中的各种系统类型——工程系统范围从微电子到飞机，从抽象系统到智慧城市。 系统工程师可能与客户、主承包商或集成商、供应商或产品制造商、研究/技术组织或政府机构合作。 这些活动在全球范围内进行，通常作为涉及多个组织、国家和文化的联盟或复杂合作计划的一部分。

应用系统工程需要考虑多个观点（如用户、维护、安全、安保），以实现对问题和解决方案的正确整体视图。 这意味着系统工程团队必须能够理解并与广泛的利益相关者合作。 系统工程跨其他学科和活动的跨学科和综合性质再次意味着系统工程团队需要理解并与实现系统所涉及的所有学科和专业良好合作（INCOSE 2020）。

鉴于环境和工程系统类型的多样性，以及他们需要与之合作的广泛利益相关者，系统工程劳动力和文化应该处于 DEI 的最前沿。 通过这种方式，我们可以在团队中尽可能多地代表多元化社区及其需求，而团队的多元化性质也创造了创新，我们可以从中实现最佳解决方案。

像大多数工程一样，系统工程在历史上并没有被不同的人群实践。 因此，有必要应用公平的概念（如定义的那样），以确保最广泛的人能够并被授权成为和发展为系统工程师。

包容性（定义）是为了确保整个（多元化）团队参与、支持并感到安全，并能够为团队的活动尽最大努力。 一个具有包容性的团队将比其他团队产生更高的生产力和更好的结果。 由于团队中利益相关者的观点范围更广，它还为包容性产品提供了更大的潜力。

包容性工程

包容性工程 (Inclusive Engineering, nd) 是一门确保工程产品和服务可供所有用户使用和包容的学科，并尽可能避免歧视和偏见。 这应尽可能考虑所有人类差异（多样性的特征）。 这是一种确保工程是适当的、合乎道德的、可访问的和尽可能无风险的方法。 工程系统的包容性降低了为满足不同人群的需求而必须应用的适应程度，例如不同的视力、不同的力量或运动功能。

在他们对解决方案的热情中，工程师通常不会停下来思考他们是否考虑了影响其设计的所有因素——尤其是客户或潜在受益人未指定的所有非技术要求。 因此，提出的解决方案往往缺乏未参与其发展的人的观点——而且在一个以缺乏多样性而闻名的行业——这通常意味着他们未能纳入女性、残疾人、人口老龄化，以及其他代表性不足的人群。

图 3 显示了一个包容性工程框架（参考文献 8），它有 8 个元素，所有这些元素都是系统工程师需要解决的重要因素，即使规定的要求没有涵盖它们。

图 3. 包容性工程框架 （经许可使用，（Bonfield 2021）， http://www.inceng.org/inclusive-engineering-framework.html ）

系统工程师可以最大限度地发挥包容性和可持续解决方案的潜力的一种方法是确保通过应用 ISO/IEC/IEEE 15288:2015 技术流程来考虑 DEI。 表 1 说明了包容性工程在这些过程中的应用。

系统工程技术领导

在技术项目和计划中，领导力是一个重要但经常被忽视的组成部分。它涉及人们的表现:他们的行为，他们独立思考和集体思考的能力，以及他们的动机和能量。系统工程的技术领导创造了有利于良好绩效的环境条件:共享理解、创新、问题解决、弹性和学习的支持。因此，领导与管理是互补的，管理指导具体的活动来实现产出。系统工程负责人可以为一个项目或程序领导一个由系统工程师组成的团队，也可以是参与项目或程序的不同成员组成的团队中唯一的系统工程师(例如，其他工程师、IT人员、服务提供商)。有各种各样的领导模式和风格，成功的关键是使领导能力与情况的需要相匹配。领导力的“模型”描述了领导力产生和运作的机制(例如，情境驱动或由一个有魅力的个人引起)。“领导风格”描述领导者(或领导团队)领导的方式(例如，以任务为中心或以人为中心;专制、民主或“自由放任”(Lewin et al.， 1939))。

有大量的文献从多个角度解决领导力问题，包括哲学、心理和情感考虑(Yukl, 2012)。这篇文章强调了领导理论的关键方面，以帮助系统工程师了解他们可能如何影响他们的团队和组织的成功。领导理论为适应工作中的领导行为提供了基本的构建模块。领导团队成员参与系统工程的实用方面在第1.11节中进行了总结。本节强调了在系统工程环境中使用不同的领导方法的需要，因此能够理解并采用在前面章节中讨论的领导行为是很重要的，如果判断合适的话。相关的知识领域和文章在第5部分知识领域，第5部分使能系统工程和第6部分知识领域系统工程和项目管理中。

有效领导者的特质

对技术领导的传统态度

工程环境中对领导力的需求尚未得到广泛强调或理解。 传统的学术工程课程不涵盖领导技能的发展，行业专业人士往往以任务为导向，项目负责人被认为具有权力和权威（Toor 和 Ofori，2008 年）。 在许多情况下，技术组织专注于管理而不是领导。 “管理者是做正确事情的人，而领导者是做正确事情的人”（Bennis 和 Nanus，1985 年）。 做正确的事不仅仅是首先确定正确的方法； 它还涉及以持续的方式理解和挑战项目或计划的进展的责任。

伟人理论：领导的特质和魅力模型

领导力的早期概念是由将领导者视为英雄人物的观点驱动的，具有使他们与其他人不同的特殊品质。 “魅力”的概念被用来描述吸引和影响追随者的能力。 已经进行了大量研究，试图定义使某人成为天生领导者的特定人格特征。 研究结果并不明确，部分原因是有许多不同的人格模型会产生不同的结果（希波克拉底在公元前 5 世纪首次确定了 4 个人格维度，此后设计了许多不同的概念化）。 性格测试应该非常谨慎地使用，因为每个测试都是为特定的目的和环境而开发的，并且只在这些参数范围内有效。 为了使测试有效，它们必须经过一系列严格的测试，包含大量数据集，然后必须完全按照验证过程的规定使用它们。 目前最好的证据共识是人格有 5 个主要维度：“外向”（健谈、善于交际）； '''宜人的'''（善良，合作）； '''尽责'''（负责，整洁）； '''神经质'''（一般程度的焦虑或镇静）； 和“开放”（对新体验）。 这个 5 因子模型在有文化的人群中具有良好的有效性，但即使这个模型也可能不是通用的（Gurven 等人，2013 年）。 有一些证据表明外向性与领导角色有关，但这并不总是成功的预测因素， 并且可能反映了一种文化刻板印象，这种刻板印象导致表现得像领导者的人更有可能获得领导角色。 不同的环境会改变领导者外向性（和其他特质）的价值。 （有关文献的荟萃分析，请参见 Judge 等人（2002 年））。

在商业环境中，Myers-Briggs 类型指标 (MBTI) 人格测试通常被用作引导讨论的一部分，以帮助自我发展（尽管它缺乏“神经质”这一重要的人格维度）。 人们可以使用他们的 MBTI 档案来帮助他们更有效地发挥自己的优势。 有时，MBTI 被误用作选择的基础，尤其是领导角色。 证据表明这是不合理的（国家研究委员会，1991 年）。

交易型和变革型领导风格

某些行为与成功的领导力有关。 这些行为源于领导风格，尤其是与团队关系相比对任务的关注。 这种差异被描述为交易风格和变革风格（Burns，1978）。 交易型领导与管理密切相关，专注于确定的任务输出，并通过奖励和惩罚来激励人们遵循指示。

变革型领导关注通过人员发展（团队建设）、建立信任、发展共同愿景、激励、培养关系和分享知识来实现​​成果。 两种类型的领导都具有价值，但变革型领导对于发展组织文化以及确保安全、适应性、学习和改进等品质是必要的。 它通常被认为是最有价值的领导形式。

了解不同的风格对不同的情况有价值，这为识别风格和情况之间相互作用的领导模型提供了基础。 Fiedler 的权变模型、Hersey 等人的情境模型和 House 的路径-目标理论（均在下文中描述）为这种方法提供了有用的变体。

领导权变模型

菲尔德的权变模型（1964）指出，没有一种最好的领导风格。 有效性是关于领导风格（定义为以任务或关系为导向）与情境（定义为：领导者得到团队支持的程度；任务结构清晰的程度；以及领导可以奖励和惩罚团队成员）。 Fiedler 设计了一种评估领导风格的方法，方法是衡量他们对“最不喜欢的同事”或 LPC 的态度。 一般来说，对 LPC 持消极态度的领导者是任务导向型的，专注于组织。 对 LPC 更积极的领导者更能避免冲突、促进创新和学习，并且更擅长做出复杂的决策。 在温和的情况下（在三个情况维度中的任何一个都不是极端情况），更积极、以关系为导向的领导者似乎更成功（Valle & Avella，2003）。 发现这种领导权变模型可以预测信息系统工程环境中的领导风格，其中领导职能分布在技术专家和最终用户之间（Franz，1985）。

情境理论

情境理论提供了一种领导模式，在这种模式中，任何领导者都可以根据情况的需要调整他或她的风格。 例如，他们可以学习从以任务为中心转变为以关系为中心。 他们也可以根据自己不断变化的状态进行调整。 Hersey、Blanchard 和 Johnson (2001) 根据团队或组织成员的性质描述了领导者可以在其中适应的四种模式：授权、支持、指导和指导。 在这种情境模型中，领导力是一种基于理解背景​​和自我意识的学习技能。

路径-目标模型

路径-目标理论将领导者的角色描述为帮助追随者发展行为，使他们能够实现目标（House 和 Mitchell，1974）。 领导者是他人成就的促进者，例如提供资源、协会、知识和支持。 领导者是一个实践社区的成员，他们团结在一个共同的企业中并分享共同的文化：历史、价值观、做事方式和谈话方式（Drath 和 Palus，1994 年）。 在技​​术领导中，这意味着帮助技术追随者有效地完成他们的任务，而在系统工程中，这意味着促进不同领域之间的沟通途径，鼓励促进综合观点的态度和行为。

真正的领导

与通过适应风格来领导的原则有所不同，因此实际上是“扮演角色”，关于“真实”的领导者的研究评估了保持自己自然风格的有效性。 成功的、真诚的领导者被描述为积极的、发自内心的领导、关注道德、建立信任、激励人们完成具有挑战性的任务。 根据真实的领导文献（例如，Gardner 等人，2011；Walumbwa 等人，2008），真实的领导者表现出四种类型的行为。 这些包括平衡处理（从各个方面获取证据）、内化的道德观点（更多地由道德而非外部压力驱动）、关系透明度（公开分享思想和感受）和自我意识（了解自我以及他人如何看待他们）。加德纳等人，2011）。

在行为方面与真正的领导力相关的是仆人式领导的概念，被描述为具有七个关键实践：自我意识； 聆听； 倒置金字塔（领导层级）； 发展你的同事； 指导，而不是控制； 释放他人的能量和智慧； 和远见。 Keith (2012) 和 Sipe 和 Frick (2009) 有类似的列表：仆人式领导者是有品格的人，以人为本，是熟练的沟通者，富有同情心的合作者，具有远见，是系统思考者，并行使道德权威。

授权、支持/分享信用、勇气/冒险、谦逊、真实性和管理等仆人式领导要素在应用于一线团队领导层时，与工程团队的创新产出具有统计学显着相关性（McCleave 和 Capella , 2015)。

复杂性领导和领导过程

真实和仆人式的领导风格将领导者置于促进者而不是董事的角色； 可以利用团队的能力并创造协同效益的人。 这一观点在来自复杂性理论的领导模型中更进一步。

复杂性领导力将领导力描述为促进组织出现的适应性成果（例如学习和创新）。 组织被认为是复杂的适应性系统，领导力可以采取三种形式：行政、适应性和赋能。 每种形式都会根据其在组织层次结构中的位置而有所不同。 复杂的适应职能提供适应能力，而官僚职能提供协调结构。 领导力应该以提高组织效率的方式区分这两种职能（Marion & Uhl-Bien, 2001）。 在这个模型中，领导力主要是发展互动。

复杂性领导不同于作为个人的领导，因为在某些情况下，领导是关于一个职能而不是一个人。 在系统工程团队等技术环境中，这将是一个重要的考虑因素，因为不同的人将拥有技术专长，并且需要在理解、挑战和沟通等领域提供领导。 系统工程团队由来自不同学科、具有不同兴趣的成员组成。 必须打破自我利益的孤岛（或者至少必须在孤岛之间建立有效的沟通，并且必须保持全球系统关注和省级学科利益之间的平衡。）

Manz 和 Sims (1989) 也将领导视为一个过程，但他们更关注每个人的自我领导，而不是少数被指定为组织中正式领导者的行为和行动。 从这个角度来看，大多数人对领导力都有一定的贡献。

追随者

同样重要的是追随者的概念。 领导者只能与有效的追随者一起领导。 在可能需要分布式领导过程的技术情况下，这一点尤为重要。 追随者的研究远不如领导力的研究发达，尽管它们是同一枚硬币的两个方面。 Uhl-Bien 等人。 (2014) 对迄今为止的文献进行了回顾，并确定了两种理解追随者的理论框架：基于角色的方法和过程方法。 他们警告不要过分关注领导角色而对领导过程关注不够，并建议了解追随者可以帮助：

• 认识到追随者角色、追随行为和领导过程的重要性
• 将领导过程及其结果理解为领导者和追随者的功能
• 识别有效的追随者行为
• 在领导过程中嵌入环境
• 认识到领导力可以向各个方向流动
• 了解管理者为何以及如何不总是能够与下属共同构建领导力
• 发展追随者

这种观点支持分布式领导职能，并有助于支持由于技术知识而不是他们领导或乐于这样做的愿望而担任领导角色的人。

与追随者发展相关的是领导者希望影响的个人内部动机的性质。 “动机”一词已被用来描述一系列可能的行为原因，没有单一的理论可以解释所有情况。 然而，一个有用的区别是“内在”和“外在”动机之间的区别。 前者涉及个人的情绪、抱负、期望和其他内部状态所产生的因素，往往是变革型领导者关注的焦点（见 第 1.3 节 ）。 后者与威胁、奖励和社会压力等外部因素产生的因素有关，往往是交易型领导者关注的焦点（也在 第 1.3 节中） ）。 重要的是要认识到内部动机和外部动机的强度存在文化和专业差异。 马斯洛 (1943) 提出的一个著名的动机模型“需求层次”可用于评估一系列潜在因素，但不具有科学有效性，并且是基于西方 20 世纪相当狭隘的观点。 例如，它没有解释为什么人们愿意忍受身体上的困难来征服更高层次的挑战； 或者为什么有些文化是集体主义的，而另一些是个人主义的。 （可以在 Triandis 等人，1988 中找到对这些文化差异的有用回顾）。

一种更可行的激励方法强调个人的心理模型，即什么是重要的（效价），他们自己在实现它中的作用是什么（工具性），以及他们实现它的能力（期望值）。 这首先由 Vroom (1964) 描述，并导致了“授权”个人的概念（例如 Conger 和 Kanungo，1988）。 领导力的路径-目标模型（ 第 1.6 节 ）旨在通过解决动机的这些方面来促进绩效。 这种被称为期望理论的激励方法可以帮助领导者了解如何通过挑战和自信来激励员工（Isaac、Zerbe 和 Pitt，（2001）。

在组织层面理解动机的尝试导致了“组织能量”的概念（Cole、Bruch 和 Vogel，2005 年）。 根据组织中现有的整体能量类型，领导者应该采取不同的激励策略来实现最佳的“生产性”能量，这被描述为高强度和积极的。 一种顺从的能量（低强度、消极的）需要发展愿景、赋权和挑战。 腐蚀性能量（高强度，负面）需要更好的沟通和信任的发展。 舒适的能量（低强度，积极的）需要识别外部威胁。

能力

领导能力是个人和团队为使领导有效而所需的知识和技能。 有时，特质和其他个体差异会被添加到技能和知识中，以创建一个角色所需的领导特征的“能力框架”。 沟通、通过支持和提供反馈来管理员工以及情感能力通常是这些框架中的特色。 区分那些习得的特征和那些基于特征的特征是很重要的。 学习能力可以通过个人发展得到增强； 一个角色可以通过人员选择获得与生俱来的个体差异（尽管不建议基于个性进行选择：参见 第 1.2 节 ）。 如上所述，领导力取决于许多行为，包括与情况相匹配的风格、有效的追随者和个人领导力。

团队中需要多个角色，理想情况下，这些角色可以分配给具有适当能力的个人。 情绪能力一直是最近许多研究的焦点，一些研究表明与有效领导有很强的相关性（例如，Cavallo 和 Brienza，2006，他们使用了情绪能力量表©）。

丹尼尔·戈尔曼（Daniel Goleman）扩展并宣传了情商（一种与生俱来的特征）的概念以及将其付诸实践的能力（可以学习的技能）。 他描述了情感能力如何能够维持人际关系、保护我们的健康并提高我们在工作中的成功率（戈尔曼，1998 年）。

戈尔曼区分了 5 种主要的能力类别。 前三个是关于自我管理的，后两个是关于在人际关系中有效的。

1. 自我意识：准确的自我评估、情绪意识和自信
2. 自律：创新、适应、认真、守信、自制
3. 动机：乐观、承诺、主动和成就、驱动
4. 同理心：发展他人、服务导向、政治意识、多样性、积极倾听和理解他人
5. 社交技能：沟通、影响力、冲突管理、领导力、建立联系、协作、合作和团队能力

情商与变革型和情境型领导最相关。

大多数领导者能力框架也强调沟通技巧。 这些技能是关于与他人交流以及倾听和被他人交流。 有些技能是关于参与的，有些是关于分享理解的。 特别是，避免隐藏的假设和理解他人的观点很重要。 沟通可以通过多种方式进行，尤其是在 IT 和社交媒体的帮助下。 每种沟通方式都有优点和缺点。 应该考虑面对面交流的重要性（通常更好，但特别是对于复杂的事情和涉及情绪的时候）。 虽然这需要更多的时间和精力，但从长远来看，它通常会通过减少误解和负面情绪来节省时间和精力。

通信可以是同步的或异步的、广播的或个人的、对话的或单向的。 Bowman (2004) 对不同沟通渠道的优缺点进行了有用的总结。

表 1 列出了文献中经常与优秀领导力相关的一些能力。这些能力的相关性取决于风格和情况/背景。

下表 1 列出了有效领导者的一些常用属性。

表 1. 有效领导者的属性（Fairley 2009）。 经 IEEE 计算机协会许可转载。 所有其他权利均由版权所有者保留。

导致系统工程活动有效领导的特征包括行为属性、领导风格和沟通风格。 此外，系统工程项目或项目群的团队负责人具有管理职责，包括但不限于：开发和维护系统工程计划，以及建立和监督项目/项目群经理与项目/项目群管理之间的关系人员。

对系统工程技术领导力的影响

领导力可以对工程绩效（Kolb，1995）和弹性（Flin，2006）产生重大影响。 上述领导模式和风格强调社交技能的力量：与他人建立联系和联系的能力。 对于系统工程领导者可能会遇到的各种情况来说尤其如此：与其他愿意效仿但需要对领导者的技术技能和可信度充满信心的专业人士一起解决复杂的问题。 技术领导者不仅应具备必要的技术知识，还应具备积极的价值观、高水平的道德、道德、发自内心的领导能力、个人能力、开箱即用的思维、人际交往能力等。（Lloyd-Walker和沃克，2011）。

在系统工程环境中，认识到不同的领导职能可能分布在一个团队中是有用的。 一些领导职能将以知识为重点，但可能需要有一个“促进者”（复杂性）领导者，以确保团队在任何时候都遵循最合适的领导。 每个组织都有特定的领导力要求，应在行为框架中阐明这些要求，以确定最有效的领导风格和能力，以及应在何处以及如何应用它们。

因此，系统工程师的领导能力应被视为工程师之间开发的分布式能力。 NASA 采用系统方法在其系统工程领导力发展计划 (SELDP) 中培养领导力。 他们将技术领导力定义为系统工程的“艺术”。 技术领导力包括广泛的技术领域知识、工程直觉、解决问题的能力、创造力以及开发新任务和系统所需的领导力和沟通技巧。 它侧重于整个生命周期的系统设计和技术完整性。 系统的复杂性及其约束的严重性推动了对系统工程领导力的需求（Williams 和 Reyes，2012 年）。

通过提拔最优秀的技术人员或最雄心勃勃的候选人来选择领导者并不是确保组织或计划中良好领导力的有效方法。 出于这个原因，通用电气、摩托罗拉、丰田、联合利华、雷神和诺斯罗普·格鲁曼等公司使用内部领导学院来根据他们的需要发展他们的领导能力（丹尼尔斯，2009 年）。 只有当合适的角色模型与候选人配对时，角色模型方法才可能有效，候选人具有适合该情况的良好领导特征（Yukl，2012）。

更有效的方法包括培养可以通过榜样、经验和反思来学习的能力。 最有效的方法将取决于所需的能力、组织的类型和机会。 它们可以包括指导、指导、跟踪、“助理”试用期和提供经验的职业管理（例如快速通道）。

还必须有一个自我发展的元素：系统工程师应该认识到人（或“软”）问题对技术团队和组织的绩效的影响，并学习如何调整自己的行为并促进他人的行为.

行为属性

行为属性是随时间保持稳定的行为、思想和情感的习惯模式（Yukl 2013）。 积极的行为属性使系统工程领导者能够有效地沟通并做出合理的决策，同时也考虑到所有利益相关者的关注。 系统工程领导者理想的行为属性包括以下特征（Fairley 2009）：

• 能力——这体现在有效领导团队的能力上。 领导才能与知识或技能不同，而是表明影响他人的能力（直觉或学习）。 领导才能有时被称为魅力或引人入胜的风格。
• 主动性——这体现在热情地开始和贯彻每一项领导活动。
• 热情——通过表达和交流对项目、产品和利益相关者的积极但现实的态度来表现出来。
• 沟通技巧——这些通过以清晰简洁的方式、口头和书面形式表达概念、想法和想法，同时与同事、团队成员、经理、项目利益相关者和其他人互动来展示。
• 团队参与——这表现在与团队成员和其他人在共享工作活动上合作时热情地工作。
• 谈判 - 这是调和不同观点并达成令相关利益相关者满意的共识决策的能力。
• 目标导向——这包括为自己、团队成员和团队设定具有挑战性但并非不可能的目标。
• 可信度——随着时间的推移，这通过在采取影响他人的行动和做出决定时表现出道德行为、诚实、正直和可靠性来证明。

另一方面，弱点是可能限制系统工程团队领导者有效性的行为属性的一个例子。

人格特质

“人格特质”的概念最初是由卡尔·荣格在 1900 年代初引入的，他发表了基于三个连续体的人格理论：内向-外向、感觉-直觉和思维-感觉。 根据荣格的说法，每个人都有一种主导风格，其中包括三个连续体中的一个元素。 荣格还强调，个人在不同情况下会改变自己的性格特征； 然而，个人的主导风格是首选风格，因为它是个人表达压力最小的风格，也是个人在压力下会诉诸的风格（Jung 1971）。 由 Katherine Briggs 和她的女儿 Isabel Myers 开发的 Myers-Briggs 类型指标 (MBTI) 包括 Jung 的三个连续统一体，以及第四个判断-感知连续统一体。 这四个维度表征了由字母指定的个人的 16 种人格风格，例如 ISTP（内向、感觉、思考和感知）。 个人的性格类型指标是通过个人在问卷中提供的答案（Myers 1995）结合个人的自我评估来确定的，该自我评估是与合格的从业者或在小组环境中进行的一对一的。 MBTI 档案被教练和辅导员广泛使用，以帮助个人评估他们的性格类型将如何影响他们在特定职业中的反应，并就哪些职业可能适合他们的个人喜好提出建议。 因为 MBTI 衡量的是偏好而不是能力，所以它永远不应该用来决定哪个职业“最舒适和最有效”。 MBTI 也被应用于团队动态和领导风格。 大多数研究表明，当多种个性风格共同作用以提供不同的观点时，团体的表现会更好。 一些研究人员声称，有证据表明，领导风格与个人在 MBTI 档案的判断-感知量表上的位置密切相关（Hammer 2001）。 那些在量表判断方面的人更可能是“书本”的管理者，而在量表感知方面的人最有可能是“以人为本”的领导者。 MBTI 模型中的“判断”并不意味着判断； 相反，判断偏好表示数量取向，感知偏好表示质量取向。 MBTI 有其批评者（Nowack 1996）； 然而， MBTI 人格风格可以提供洞察团队成员和团队领导者之间有效和无效的互动和沟通模式。 例如，具有强烈内向、思考、感觉和判断人格指数 (ITSJ) 的个人可能难以与具有强烈外向、直觉、感觉、感知人格指数 (ENFP) 的个人互动。

领导风格和沟通风格

有大量关于领导风格的文献，并且有许多领导模式。 这些领导模式中的大多数都是基于荣格心理类型的一些变体。 其中一种模型，威尔逊社交风格，整合了领导风格和沟通风格（Wilson 2004）。 威尔逊模型描述了四种领导风格：

• 驾驶员领导风格 - 当领导者专注于要完成的工作和

指定其他人必须如何做他们的工作。

• 分析型领导——强调收集、分析和共享数据和信息。 一个

分析型领导者会征求其他人的意见和建议以收集信息。

• 和蔼可亲的领导风格——其特点是强调个人互动和询问他人

他们的意见和建议。

• 富有表现力的领导风格——与和蔼可亲的风格一样，这也注重个人关系

富有表现力的领导者告诉别人而不是征求意见和建议。 当走向极端时，这些风格中的每一种都可能导致领导力的弱点。 如果过于专注于工作，“司机”可能会提供过多或过少的指导和方向。 当个人全神贯注于她或他的个人工作时，就会出现指导太少，而指导过多会导致微观管理，从而限制了团队成员的个人决定权。 司机也可能对与团队成员和其他人的人际关系不敏感。 分析型领导者可能会提供太多信息，或者可能无法提供对他们来说显而易见的信息，但对他们的团队成员却不是。 他们不喜欢讨论他们已经知道或与手头任务无关的事情。 像驾驶型领导者一样， 他们可能对与其他人的人际关系不敏感。 和蔼可亲的领导者专注于人际关系以完成工作。 他们可能不喜欢那些无法在个人层面上与他们互动的人，并且可能对那些对他们没有兴趣的人表现出很少的关心。 富有表现力的领导者也关注人际关系。 在极端情况下，富有表现力的领导者可能更愿意表达自己的意见，而不是倾听他人的意见。 此外，他们可能会玩最爱而忽略那些不喜欢的人。 虽然这些特征过于简单化了，但它们有助于说明系统工程团队领导者可能表现出的领导风格。 有效的团队领导者能够改变他们的领导风格，以适应特定环境和支持者的需求，而不会走极端； 但正如荣格所强调的那样，每个人都有一个压力最小的首选舒适区，并且在压力增加时个人会求助于该舒适区。

沟通方式

威尔逊模型的另一个特征是不同领导风格的首选沟通方式，这可以通过自信和响应能力的维度来说明。

图 1. 沟通方式的维度（Fairley 2009）。 经 IEEE 计算机协会许可转载。 所有其他权利均由版权所有者保留。

以任务为导向的自信体现在强调要完成的工作而不是要完成工作的人的沟通方式中，而以人为本的沟通方式则首先解决人事问题，然后再处理任务。 以告知为导向的沟通方式涉及告知而不是询问，而以询问为导向的自信强调询问而不是告知。 电影、戏剧和小说通常包含对威尔逊沟通风格的自信和反应维度的极端讽刺。 个人的沟通风格可能属于自信和反应连续统一体中的任何地方，从极端风格到较为温和的风格，并且可能因情况而异。 示例包括：

• 驾驶员沟通方式表现出以任务为导向的响应能力和以诉求为导向的自信。
• 富有表现力的沟通风格与司机风格共享以讲述为导向的自信，但更倾向于以人为本的响应能力。
• 和蔼可亲的沟通风格包括询问而不是讲述（分析风格也是如此），并强调人际关系而不是任务导向（表达风格也是如此）。
• 分析型沟通风格表现出以任务为导向的响应能力和以提问为导向的自信。

当个人共享相同的交流方式或共享图 1 中的相邻象限时，最舒适的交流发生。当个人处于对角象限时，可能会发生困难的交流； 例如，极端和蔼可亲的风格和极端的司机风格之间的交流。 技术领导者和其他人可以通过了解不同的沟通方式（他们自己的和他人的）并通过修改他们的沟通方式以适应他人的沟通方式来改善沟通。

管理职责

领导系统工程团队涉及沟通、协调、提供指导以及保持进度和士气。 根据 PMBOK® 指南（PMBOK 2013），项目管理涉及项目管理的五个过程组的应用：启动、计划、执行、监控和结束。 通俗地说，系统工程项目/项目群管理涉及制定和更新计划和估计，提供资源，收集和分析产品和过程数据，与技术领导一起控制工作过程和工作产品，以及管理整体进度和预算。 好的工程经理不一定是好的技术负责人，好的技术负责人也不一定是好的工程经理； 需要表达不同的个性特征和技能组合。 那些作为管理者和领导者都有效的人具有分析和人际交往能力，尽管他们的舒适区可能是管理或领导之一。 通常由系统工程团队负责人负责的两个管理问题是：

• 在他或她自己、系统工程团队领导和项目/项目经理之间建立和维护责任分工。
• 制定、实施和维护系统工程计划 (SEP)。

系统工程和项目管理之间的关系在 SEBoK 的第 6 部分知识领域 (KA)， 系统工程和项目管理 中进行了讨论。 另请参阅第 5 部分知识领域 支持团队 ，以讨论项目/项目经理与系统工程技术领导者之间的关系。

系统工程计划 (SEP) 是或应该是管理系统工程工作和项目或计划的技术方面的最高级别计划 。 它定义了项目将如何组织和实施，以执行和控制满足项目系统要求和技术内容所需的系统工程活动。 它可以有许多辅助技术计划，提供有关特定技术领域和支持流程、程序、工具的详细信息。 此外，请参阅第 3 部分中的 规划 文章，其中包括关于 系统工程规划过程概述 的部分。

在美国国防部采办计划中，系统工程计划 (SEP) 是政府制作的文件，它协助开发、沟通和管理指导计划的所有技术活动的整体系统工程 (SE) 方法。 它为开发人员提供了程序执行的方向。 开发人员使用 SEP 作为制定系统工程管理计划 (SEMP) 的指南，这是一个单独的文档，通常是与 SEP 一致的合同可交付成果。 由于 SEP 是政府制作和维护的文件，而 SEMP 是开发商/承包商开发和维护的文件，因此 SEMP 通常是独立的、协调的文件。

以下来自 (ODASD 2011) 的 SEP 大纲作为示例。

1. 简介 - 目的和更新计划
2. 程序技术要求
   1. 架构和接口控制
   2. 技术认证
3. 工程资源与管理
   1. 技术进度表和进度风险评估
   2. 工程资源和成本/进度报告
   3. 工程与集成风险管理
   4. 技术组织
   5. 与外部技术组织的关系
   6. 技术性能测量和指标
4. 技术活动和产品
   1. 上一阶段 SE 活动的结果
   2. 为下一阶段计划的 SE 活动
   3. 需求开发和变更过程
   4. 技术评论
   5. 配置和变更管理流程
   6. 设计注意事项
   7. 工程工具
5. 附件 A – 首字母缩略词

SEP 模板通常通过添加所需元素以及修改或删除其他元素来定制以满足单个项目或项目群的需求。 系统工程团队负责人通常与其他团队成员、项目/项目经理（或管理团队）和其他利益相关者一起开发 SEP 并随着项目的发展保持计划的通用性。 一些组织提供一个或多个 SEP 模板，并为开发和维护 SEP 提供指导。 一些组织有一个职能小组，可以为开发 SEP 提供帮助。