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二級研制要求下的溝通管理過程。在今后的工作中，還需要進一步研究和總結，進行軟件工程化的全面推進，最終使得整個組織的軟件水平有所提升。