軟件開發過程非常復雜，有時甚至很混亂。為了減少這種情況，必須對所有階段進行合理的組織，計劃和協商。溝通不暢，缺乏明確性和錯過最后期限將危及任何項目。好在有一個項目經理，其職責是為開發過程的每個步驟定序并將其記錄在溝通計劃中。它可以防止上述問題的發生，并有助于盡可能準確地預測項目的進度。溝通計劃還可以消除開發過程中的誤解，有助于及時解決新出現的問題，并向利益相關者展示您為什么需要所需的資源。溝通計劃沒有任何缺點。但是，如何創建項目管理溝通計劃？

　　什么是項目管理溝通計劃？

首先，讓我們從基礎開始。首先，溝通是一個過程。像任何其他過程一樣，它應該具有良好的結構，并且最終會富有成效。因此，溝通需要戰略和獨特的計劃。

那么，什么是溝通計劃?溝通計劃是一組標準以及商定的舉行和參與溝通活動的順序。

如果遵循得當，溝通計劃將使所有團隊和利益相關者參與一個組織良好的過程。

像任何其他規則集一樣，它必須被記錄在案，并且涉及到的每個人都可以訪問。但是，沒有唯一正確的方法來制定溝通計劃。它可以是包含計劃中的會議和事件的清單，也可以是在線日歷，其中安排了所有會議，并由董事會陪同其所有安排者。

該計劃必須基于在特定時間段內以及每個參與者的共同商定并認可的會議時間表。所有成員都必須準備必要的數據以在會議上共享，以使其具有建設性和生產力。

　　為什么溝通計劃在項目管理中很重要？

結構合理的溝通計劃的主要目的是顯而易見的：使一切正常運行。 溝通計劃可指導團隊實現開發目標：即功能完善的產品。它有助于將溝通計劃的創建過程分為可理解和可管理的步驟。

作為獲得最終結果的一種方式，溝通計劃不僅要定義事件和報告的數量和類型，還應定義事件和報告的數量和類型。它還指定了里程碑。每個交流事件都標志著開發過程中的一個步驟，并且具有特定的目的，例如與客戶交流重要信息，審查已完成的工作或計劃下一步。每次交流活動的目的都定義了參與者，負責人，會議議程和預期結果。

溝通計劃是一個復雜的系統，對于團隊和客戶來說，開發過程都是可理解且有效的。因此，項目經理的職能是進行不同級別的交流。但是，要制定周到的計劃，項目經理必須解構該更廣泛的抽象目標并查看其每個組成部分。

制定完善的溝通計劃值得花費時間和精力的主要原因有四個。

　　消除不必要的溝通

溝通計劃將使團隊擺脫不必要的工作，并節省寶貴的時間。所有不必要的操作都會減慢工作流程。當團隊中的每次會議和互動都有討論主題和議程時，它將減少不必要和重復的動作。

此外，當您有不同的計劃時，它會減少錯過有關開發過程的重要信息的機會。

　　建立更好的關系

溝通計劃安排了會議，使所有團隊成員都能看到他們的工作成果并了解每個人的貢獻的重要性。當團隊成員之間存在良好的信任關系時，團隊將表現最佳。為了建立這種信任，他們所有人都必須討論什么有效，需要改進。

當團隊中存在良好的信任關系時，流程將順利進行，并在問題變得嚴重之前就將其發現。溝通越好，團隊可以更快地確認并解決問題。無法溝通問題往往比問題本身更為嚴重。

　　它可以為下一個沖刺提供更精確的估計

這樣的會議使團隊可以根據團隊的速度來精確估計沖刺中任務所需的時間。他們允許團隊討論開發方法并達成一致。包括產品負責人在內的會議構成了對團隊必須實現的目標的理解，并幫助團隊確定最佳的行動順序和完成任務所需的任務。

反過來，回顧性會議和審查的目的是澄清沖刺期間的復雜性及其管理方法。這些事件的組合有助于團隊獲得可預測的結果并調整產品更新。

　　導致數據及時做出決策

當建立了清晰且組織良好的會議和報告系統時，開發團隊與產品所有者之間的溝通過程將得到優化。這樣，參與者就可以了解業務目標，并根據收到的信息來制定未來的任務，并在此背景下做出計劃決策。

報告和會議系統使企業和產品所有者可以了解團隊的速度，并讓他們知道產品功能的完成情況。它允許設置完成任務的截止日期和發布日期。因此，透明，及時的溝通使企業和團隊都能做出明智的工作決策。

　　項目管理溝通計劃定義和解決的問題

本質上，就項目內的信息傳遞而言，溝通計劃必須回答四個問題：誰？什么？什么時候？怎么樣？

我們的溝通計劃緊密相關，并基于Scrum系統，在該系統中，團隊同意并承諾一定數量的任務要在一個sprint中完成，并確定其中的通信會話順序。如果團隊使用不同的框架，事件和報告，則他們的組織也會有所不同。

因此，溝通計劃將是不同的。項目經理的職責是在春季加入交流，添加通常是會議的Scrum事件。交流事件和報告的結構基于所使用的方法和開發方法。盡管如此，它應該足夠靈活以進行改進并滿足業務需求。

通過回答上述四個問題， 溝通計劃定義了團隊內部溝通和互動的規則。它安排會議的時間，參與者的人數，利益相關者的報告，討論議程，溝通形式以及整個團隊的活動。

例如，與利益相關者舉行特定會議以討論團隊對他們的期望，并舉行回顧性會議以回顧團隊在上一個沖刺中的表現。每種類型的會議都有不同的目的，這就是為什么計劃應定義參與者的人數和類型以及要討論的問題的原因。

下面，我們將仔細研究每種類型的會議。

　　交流方式

每個項目中的溝通方式取決于項目本身，團隊中的人數以及團隊預期的截止日期。在開始該項目的工作之前，團隊討論與客戶溝通的條件，并確定報告的頻率及其格式。

此外，它們定義了如何傳達緊急出現的問題，必須事先同意誰參加會議。例如，并非每次會議都需要整個團隊，因此還必須討論會議中的角色。

每個項目的通信方法都是單獨定義的。在這里，我們將描述我們如何制定溝通計劃。

對于我們來說，一個計劃是基于Scrum系統的。根據框架，會議和報告的設置，數量，順序和其他功能可能會有所不同。框架的選擇取決于產品和團隊的需求。

除任務管理外，在牢記這一點的同時創建通訊計劃很方便。溝通計劃包括會議，報告和聊天消息。根據開發方法，它們的頻率和組織可能會有所不同。我們將詳細說明它們中的每一個。

　　會議會議

會議的每個階段都有不同的目的，并對團隊和參與者有不同的要求，從而標志著工作進度的每個階段。會議標記了所執行工作的檢查要點，闡明了所有問題，并允許團隊向全局展示自己的成就。

在我們的開發過程中，它看起來像這樣：

　　日常會議

也稱為站起來，每天為每個團隊成員舉行會議，以便他們可以掌握過程中發生的一切。與會者都是團隊成員。他們討論當前的任務，進度以及限制工作的因素。如果出現任何技術問題，將在單獨的會議上進行討論。

　　精修前會議

參加者：產品負責人，團隊負責人和項目經理

舉行這次會議是為了闡明下一個沖刺的計劃。每個參與者都有自己的角色。項目負責人概述了業務目標，團隊負責人為未來的迭代準備了技術目標。

當提出了所有期望并且從產品的角度明確了所有團隊的目標時，Pre-Refinement會議的結果就是可以進行梳理的高級范圍。

會議在沖刺開始時舉行，并演示了其范圍。

　　功能修飾

參與者：功能團隊，其中的團隊成員共同致力于相同的功能。成員可能會有所不同，具體取決于功能。通常，它包括BE工程師，FE工程師，QA工程師和UI / UX工程師。

會議的目的是根據團隊成員的能力來分發功能所需的任務。參與者討論最終結果的要求，并就執行方法和集成達成一致。這是一次會議，向產品所有者提出質疑，以提供關于結果必須是什么的單一想法。每個修飾會話都專門針對特定的功能或故事。

　　能力培養

參加人員：BE工程師，FE工程師，QA工程師，DevOps或UI / UX工程師。

與功能修飾會議不同，此會議旨在根據團隊的能力召集團隊。例如，BE工程師或僅UI / UX工程師將參加此會議。當團隊并行聚集時，每個勝任力部門都會討論針對他們的任務。會議的目的是整理任務-即澄清所有不清楚的地方，并討論有關任務的任何問題。

會議的結果是，必須估計所有任務并將其分配給團隊成員。之后，項目經理將清楚地了解團隊如何在其范圍內完成任務。然后，他們可以根據任務估計和每個任務所需的時間，討論如何在即將到來的sprint中處理需要多種能力的任務。

規劃

參加者：所有團隊成員

當前沖刺結束的前一天或新沖刺的第一天，團隊聚在一起致力于下一個沖刺的范圍。本質上，會議提供了一個計劃下一個工作的機會。團隊審查要完成的任務，并與產品負責人一起確定要包括在沖刺中的內容以及要留給以后的內容。

根據業務需求，產品負責人確定任務的優先級，然后團隊決定可以管理多少任務。沖刺中未包括的所有內容都進入待辦事項列表。沖刺范圍完成后，團隊將為沖刺寫下承諾書，這是此類會議的目的和結果。

稍后我們將更詳細地討論承諾書。

　　Sprint審查會議

參加者：所有團隊成員

Sprint審查發生在當前Sprint的最后一天。項目經理總結了在sprint中完成的工作，團隊成員介紹了他們所從事的功能。團隊將沖刺的起伏向產品負責人報告，產品負責人通常在線參加會議。

這是所有事件應該有固定時間表的另一個原因：這樣，每個參與人員都可以彼此同步。

項目經理與團隊一起，根據Sprint承諾書中概述的目標評估彈簧是否成功。

審查之后，項目經理將沖刺報告和測試報告發送給產品所有者。使用這些文檔，產品所有者可以做出有關發布的決定。

　　沖刺復古會議

參加者：所有團隊成員

在這次會議上，團隊回顧性地查看了上一個沖刺中已完成的任務，并將結果與他們在計劃會議中承諾的任務進行了比較。所有參與者都分享他們面臨的局限性因素，以及是否，如何以及為什么出了問題。

會議的結果是，項目經理創建了一個在線董事會，顯示所有行動要點。行動要點是團隊需要解決的事情，包括溝通問題。確定所有問題并將其添加到董事會后，項目經理會將其分配給將要解決的團隊成員。必須在演示會議上確認并討論sprint中的所有問題，以便下一個sprint可以更有效地進行。

例如，如果問題是組織性的，并且可以使用Jira中的便捷過濾器解決，則項目經理將承擔任務。開會是討論任何可能的問題的時間，即使有人需要燈，鼠標或新的椅子。團隊描述了他們在沖刺期間遇到的障礙，以減少并防止它們在未來發生。

本質上，所有會議類型都在Scrum中進行了標準化。我們所做的唯一更改是舉行了兩個單獨的梳理會話。如果您的團隊較小，則只需進行一次功能和能力培訓即可。

　　安排會議

每次會議在sprint中都有自己的位置。例如，如果沖刺在星期四開始并且持續兩周，則Sprint審查和Sprint Retro將在每兩周的星期三進行一次。每日會議必須在一天的同一時間，同一地點或同一房間舉行。

每次會議的標準程序都會增加工作流程的一致性。每次會議的商定時間僅添加到日歷中，因此所有相關人員都可以看到并跟進。

　　滿足要求

每次會議的程序必須透明且所有團隊成員均可訪問。我們將所有滿足要求和規則存儲在Confluence中。每個參與者都清楚在會議之前需要準備什么信息以及每次會議的預期結果是什么。例如，計劃會議需要滿足以下條件：

· 功能團隊對下一個沖刺中的任務有明確的要求和接受標準。

· 功能團隊已經討論并就實現功能的細節和方法達成了一致。

· 功能團隊已經創建，描述并同意了子任務。

· 子任務已分配給功能團隊成員。

· 團隊已同意在以下sprint范圍內完成任務的估算。

　　電子郵件和報告

電子郵件是一種正式的通信方式，也與Scrum密切相關。 每個Scrum事件后都會有一封電子郵件報告，其中包含會議，測試或部署的結果。

以下是沖刺中的報告類型。

　　承諾書

這是項目經理在每次Sprint計劃會議之后發送給團隊的信。它列出了團隊同意在下一個沖刺期間完成的功能。它還包括該過程中涉及的人員，他們的工作量，在工作上花費的記錄時間量以及sprint的目標的列表。

　　沖刺報告

該報告必須描述團隊的成就，花費的時間以及團隊是否達到了其承諾的目標。它在每個Sprint的末尾發送。

　　測試報告

該報告由質量保證團隊創建。該報告必須列出所有錯誤，并闡明已修復的問題以及仍需要修復的問題。它還必須提供有關項目狀態以及在創建報告之時所遇到的任何問題的最新信息。

它總結了對測試項目的評估，確定了測試項目，并指出了它們的版本/修訂級別以及進行測試活動的環境。它描述了在回歸測試期間發現的問題，當前沖刺中受影響的錯誤，建議等。

　　發布報告

該報告提供了某些功能開發的最新信息。它必須包括列出的所有功能及其狀態。

　　聊天訊息

作為書面交流方式，電子郵件用于向客戶或產品所有者報告。與報告和會議相比，聊天消息是非正式的。但是，仍然有適用于它的過程。

聊天用于團隊內部的即時交流。我們的開發團隊將Slack用作公司的使者。 擁有一個單獨的使者上班既重要又方便，這很重要-因為它仍然是進行工作討論的空間，而且很方便，因為您可以為不同的事務創建渠道并將參與的人員添加到聊天中。

有不同的溝通渠道，具體取決于參與任務的團隊成員。聊天提供了一種快速的方式來討論新出現的問題或任務的特殊性。這樣的渠道非常適合及時更新進度。此外，有關特定任務的問題在Jira中進行了討論，它使團隊成員可以查看任務的規格和任何已完成的更改。這樣，與特定任務相關的任何問題都更易于跟蹤，從而消除了不必要的溝通。

　　如何制定項目管理溝通計劃

既然方法及其含義已擺在桌面上，就可以開始將它們放在一起。首先，沒有用于溝通計劃的標準化模板。您可以找出對您和您的團隊最方便的方法，并將其作為您計劃的基礎。以適合所有人的方式確定計劃導航的優先級，并且不要忘記執行以下步驟：

　　溝通計劃需求：

· 項目規模

· 參與人數

· 勝任力

· 客戶偏好

　　溝通計劃的方法：

· 會議類型

· 會議次數

· 報告類型

· 聊天頻道

· 分配的職責

　　溝通計劃要求：

· 時間表對每個人都方便嗎？

· 產品負責人需要參加哪些會議？

· 什么是標準報告模板？

· 您是否已將Scrum事件與所有利益相關者的日程同步？

　　列出您的項目的溝通需求

每個項目都不相同，每個項目的通信需求也將不同。您需要考慮項目的規模，從事此項目的人數及其規格。另外，重要的是要注意客戶在交流方面的偏好，因為這是使工作過程對所有人都方便的唯一方法。然后，根據您的溝通需求，選擇最合適的溝通方式。

　　在開發過程的基礎上定義溝通方法

Scrum框架建議所需的通信事件，并幫助組織開發過程。由您決定過程的階段并創建沖刺，選擇團隊需要的會議，每次會議需要多少時間以及如何跟蹤它。您可以方便地將所有這些事件添加到日歷，并為團隊成員分配角色和職責。

確定并安排了所需的會議類型后，請列出每種會議的必要數據和預期結果。例如，為進行梳理，您需要任務的范圍，這些任務的范圍將根據會議的結果進行估計，討論，闡明和分配。

　　定義溝通要求

您的溝通計劃將需要一系列要求。這將幫助您安排所有的交流環節，并最終評估流程的有效性。

· 溝通要求必須基于對項目和團隊的最佳選擇。討論并就項目信息的流程和可訪問性達成共識非常重要。另外，您還需要知道企業所有者何時需要報告，因為他們將不得不向擁有自己時間表的利益相關者報告。因此，時間表必須一致。然后，您需要弄清是否擁有開始或繼續工作所需的一切。

· 討論產品負責人是否需要參加會議。如果是這樣，請確定哪些。

· 標準化項目的報告模板，并確定其數量和頻率。

· 安排會議日期，同時要記住企業已經有自己的議程。例如，產品負責人必須向利益相關者報告。這些計劃必須同步。在日歷中可以最好地看到所有會議的全景圖。但是，Scrum具有規則，例如，復古會議必須每兩周召開一次，而每日會議必須在同一時間和地點舉行。本質上，該框架在sprint中包括每次會議和報告的位置。

為您的項目制定可靠的溝通計劃將需要一些時間和一些嘗試。制定完善的計劃將需要更多的工作。但是，每次迭代都會使通信過程變得更加舒適和高效。需要記住的事情是每次會議，檢查點和報告的目的。好了更多關于項目經理的信息，請繼續關注中培偉業。