GJB 5000A二级背景下的沟通管理

董 曦，张瑞玲

（中国船舶重工集团公司第七二三研究所，江苏扬州 225101）

0 引言

美国一项研究表明，商场上的成功 85%取决于沟通，很多企业经理 94%的时间用于沟通[1]，可见沟通管理是项目成功的关键。同样，在软件项目的研制过程中，做好沟通管理也非常重要，如果沟通不畅，会带来很多问题。

GJB 5000A是装备发展部提出的软件研制能力成熟度模型，许多军用软件生产商正在推广GJB 5000A二级。但是在实际推广GJB 5000A二级的过程中，由于软件项目研制和管理生命周期的复杂性，出现了各种各样的沟通问题。因此，如何在GJB 5000A背景下做好沟通管理、提高沟通有效性极为关键。

1 沟通基本介绍

1.1 沟通的概念

沟通是指2个或2个以上的人交流并理解信息的过程，其目的常常是为了激励或者影响人的行为，而不仅仅是传达信息[2]。基本沟通模型如图1所示。从图1可以看出，沟通事实上是个双向的过程，发出者在发送信息之后，接收者要对所接收的信息进行理解并反馈，确保双方就所传达的信息理解一致。

1.2 软件项目沟通方向分类

沟通活动存在于软件研制活动生命周期内的各个时机中。一般以正式与否为标准，可将沟通类型划分为正式沟通和非正式沟通2种。

图1 基本沟通过程模型

GJB 5000A标准原文中明确要求正式沟通的包括里程碑评审、基线评审、同行评审、获得需求、选择供方等内容。本文主要讨论正式沟通。GJB 5000A二级要求下，软件研制过程中涉及到的正式沟通可以从方向上分为自上而下、自下而上、平级沟通、斜向沟通这 4种类型[3]。沟通的形式多种多样，不拘泥于面谈、会议和公文等，有时通过轻松的形式，如茶歇、邮件、电话、微信群聊等，可使信息的交流更加轻松、顺畅。

1.2.1 自上而下

自上而下的沟通就是信息从组织的高层向下层的传递。在软件研制周期内，类似于命令、指示等就是自上而下传达的。例如，SEPG组（software engineering progress group，软件工程过程小组）向全所相关人员发布软件过程体系文件，软件高层验证会上，最高领导向各个中层领导传达推进GJB 5000A的指示。

1.2.2 自下而上

自下而上的沟通形式与自上而下相反，是下级部门向上级部门传达意愿、建议或意见的形式。例如，SQA（software quality assurance，软件质量保证）人员审核项目工作产品时，如果发现不符合项，但在项目组内解决不了，就需要将信息上报；或者项目研发人员需要协调资源，就要自下而上请示部门领导。

1.2.3 平级沟通

平级沟通是指部门内同事之间或不同部门之间水平方向的沟通。一般而言，无需上级协调、只涉及具体技术或事务的平级沟通比较常见。例如软件工作产品的技术评审会就是平级沟通，需召集多部门同行技术专家对特定软件工作产品进行集体沟通和评价。

1.2.4 斜向沟通

斜向沟通为不同部门的非同层级之间的沟通，这种情况存在但不多见。例如，质量部领导和某产品室员工之间关于工作产品进行交流的过程就是斜向沟通。

2 GJB 5000A二级过程域中的沟通

GJB 5000A二级的过程域（process area，PA）分为项目管理和支持2大类，具体划分如图2所示。在GJB 5000A标准中，虽然没有直接对沟通能力做出要求的过程域，但沟通活动本身都含在其各个过程域中。

图2 过程域PA的分类

2.1 项目策划

项目策划过程域首先要求对所研项目进行估计，在估计过程中往往会运用到类似宽带 Delphi等估计方法，这就是项目经理、软件主管设计师和相关领域专家经过几轮沟通最后达成共识的过程。在制定项目计划时，需要与利益相关方充分沟通，确保每个利益相关方都认可项目的推进计划，这样才会获得所有利益相关方对计划的承诺。对于沟通和承诺的结果，可以进行评审形成文档化的记录。

2.2 项目监控

项目监控即对照计划监督项目。在监督项目策划参数、承诺、风险、数据等过程中，项目监控人员需要与项目软件主管设计师、项目组成员等沟通和交流监控的结果，确保监控结果被大家认可。对于监控发现的问题，需进行分析讨论，适当时候做出承诺并进行整改。在实施进展评审和里程碑评审这2个专用实践的时候，一般以会议的形式进行沟通。

2.3 需求管理

有些专家认为需求管理应该纳入工程类过程域，但从该过程域的主要实践来看，笔者更倾向于将需求管理作为管理类过程域。必须做到与需求的提供者共同去理解需求，这就需要研制方与顾客进行反复的沟通确认。获得承诺就是要双方对于沟通的结果给出一份纸质文档，比如研制任务书、接口协议等。变更需求时更需要沟通，研制方与顾客、研制方内部都需要对变更内容、变更影响进行沟通、分析和确定。

2.4 供方协议管理

供方协议管理的目的是管理供方产品的获取工作[4]，是与供方达成协议并且监督协议执行的过程。此过程域实际上就是一个建立合同、履行合同的沟通过程。

2.5 配置管理

在建立和发布基线之前，基线需要经过正式的评审。正式的评审是一种集体沟通的过程，要有组织、有人员、有计划、有目的、有记录。关于跟踪和控制配置项，往往涉及到与利益相关方正式沟通配置项变更对项目所带来的影响。在执行配置审核之后，需要将审核结果告知被审核对象。

2.6 过程和产品质量保证

SP2.1（专用实践）明确提出“交流并确保解决不符合项”的要求[4]。质量保证人员查找不符合项时，要遵循客观性和独立性的原则。对于查找出来的不符合项，要与项目研制人员充分沟通和交流，确保所提出问题的正确性，然后要跟踪问题，与问题的解决人沟通之后，确认是否关闭不符合项。在问题关闭过程中，如果对不符合项有争议，质量保证人员有逐级向上报告的权利。

2.7 测量分析

在项目开始、测量分析人员确定测量目标时，需充分考虑项目主管和其他有测量目标需要的人员的需求，在与之沟通之后，形成项目的测量目标。有必要对指定的测量、存储和分析规程进行评审，形成项目组一致意见。提供测量结果这一专用目标要求交流测量结果，这就要求及时、正确地向各利益相关方沟通测量和分析的结果，使大家认可数据和原因，以便项目的进一步开展。

3 沟通效果的评价

沟通活动为主观活动，但是依然要建立较为客观的评价机制去衡量沟通效果的好坏。沟通效果的评价可分为4个步骤（图3）：

图3 沟通效果评价模式

制定沟通目标、确定效果标准、对照效果标准、纠正沟通偏差。

3.1 制定沟通目标

在项目管理计划中，要制定出项目沟通管理的目标，比如何时以何种形式将信息传递给对方、什么时候以什么方式获得对方的信息、对方将给出什么样的响应等。

3.2 制定效果标准

沟通效果的标准界定比较复杂，这就需要项目经理与软件主管设计师共同参与。最主要的考量标准即为对于沟通目标的完成情况，此外，考虑标准还包括客户对沟通者的满意度、客户对沟通内容的理解程度、对方对于沟通信息的响应等。

3.3 对照效果标准

当项目经理比较实际沟通结果与效果标准时，可以确定结果未达到、达到或超过标准要求。不管对照的结果如何，管理者都有必要对结果进行分析。

3.4 纠正沟通偏差

当实际沟通结果未达到效果标准时，在分析原因后，管理者必须采取措施纠正此类沟通方式。当实际沟通结果达到或者超过效果标准时，可以强化或推广此类沟通方式。

4 沟通的注意事项

4.1 沟通的及时性

由于信息具有时效性，所以需要及时沟通内容。一组信息产生之后，如果不及时与相关方沟通交流，在一段时间之后，信息可能会失效，因此可能耽误整个项目的进展。例如，在项目需求变更时，就要及时与各利益相关方沟通，如果利益相关方未及时得到信息并确认，在项目达到一定阶段之后，利益相关方可能不认可之前的变更，从而导致项目失败。

4.2 沟通的正确性

沟通成功与否的一个关键因素在于沟通的双方对于沟通内容的理解是否一致。由于沟通双方存在办公文化、思维方式、工作环境等诸多差异，所以常常出现双方对于信息理解有偏差的情况，这可能会导致软件研制项目的开展不利或失败。因此，许多项目在实施过程中，对于某些沟通的内容会反复核实确定，可形成正式的会议纪要，或由所有参与的沟通方签字认可结果。

4.3 沟通的成本

需要强调的是沟通作为管理环节的一部分也是需要付出成本的。这里的成本是广义上的成本，不仅仅是金钱。首先，组织各项会议都要消耗一定的人力、物力和财力；其次，对于各种沟通活动都会在一定程度上损耗项目所用的工程类时间。所以在考虑沟通及时性和正确性的同时，也要注意控制沟通的成本，简化沟通流程，不拘泥于某种或某几种沟通形式。

5 结论

有效的沟通活动可以使得整个软件研制过程更加顺畅。本文从项目工程实践出发，根据以往经验，给出了GJB 5000A二级研制要求下的沟通管理过程。在今后的工作中，还需要进一步研究和总结，进行软件工程化的全面推进，最终使得整个组织的软件水平有所提升。