選取您的 Cookie 偏好設定

我們使用提供自身網站和服務所需的基本 Cookie 和類似工具。我們使用效能 Cookie 收集匿名統計資料,以便了解客戶如何使用我們的網站並進行改進。基本 Cookie 無法停用,但可以按一下「自訂」或「拒絕」以拒絕效能 Cookie。

如果您同意,AWS 與經核准的第三方也會使用 Cookie 提供實用的網站功能、記住您的偏好設定,並顯示相關內容,包括相關廣告。若要接受或拒絕所有非必要 Cookie,請按一下「接受」或「拒絕」。若要進行更詳細的選擇,請按一下「自訂」。

OPS03-BP04 通訊是及時、清晰且可操作的 - AWS 建構良好的架構

本文為英文版的機器翻譯版本,如內容有任何歧義或不一致之處,概以英文版為準。

本文為英文版的機器翻譯版本,如內容有任何歧義或不一致之處,概以英文版為準。

OPS03-BP04 通訊是及時、清晰且可操作的

領導層負責建立強大而有效的溝通,尤其是當組織採用新策略、技術或工作方式時。領導者應該為所有員工設定期望,以實現公司目標。設計溝通機制,在負責運行由領導資助和贊助計劃的團隊之間可建立和保持意識。利用跨組織的多樣性,並用心聆聽多個獨特觀點。使用此觀點來增加創新、挑戰假設,並降低確認偏差的風險。在團隊中培養包容性、多樣性和可及性,以獲得有益的觀點。

預期成果:您的組織設計溝通策略以解決變更對組織的影響。團隊保持知情並積極繼續彼此合作,而不是彼此對抗。個人了解他們的角色對於實現既定目標是多麼重要。電子郵件只是一種被動的溝通機制,並相應地使用。管理層花時間與他們的個人貢獻者溝通,以幫助他們了解其責任、要完成的任務,以及他們的工作如何為整體使命做出貢獻。必要時,領導者直接在較小的場所與人們互動,以傳達訊息並確認這些訊息是否有效地傳遞。由於良好的溝通策略,組織的表現達到或超出領導層的期望。領導層鼓勵和尋求團隊內部和團隊之間的不同意見。

常見的反模式:

  • 您的組織有五年計畫,可將所有工作負載遷移至 AWS。雲端的業務案例包括所有工作負載的 25% 進行現代化,以充分利用無伺服器技術。會將此策略CIO傳達給直屬員工,並期望每個領導者將此簡報逐級傳遞給經理、主管和個別貢獻者,而不需要任何當面溝通。退CIO一步並期望他的組織執行新策略。

  • 領導層不提供或使用回饋機制,並且預期差距不斷增長,導致專案停滯。

  • 系統會要求您對安全群組進行變更,但不會為您提供任何詳細資訊,說明需要進行哪些變更、變更可能對所有工作負載造成什麼影響,以及何時發生變更。管理員轉送來自 VP 的電子郵件, InfoSec 並新增「讓這種情況發生」訊息。

  • 對您的遷移策略進行了變更,將規劃的現代化數量從 25% 降低到 10%。這對營運組織具有下游影響。他們沒有被告知這一策略變化,因此,他們還沒有準備好足夠的技術能力來支援更多的工作負載平移到 AWS中。

建立此最佳實務的優勢:

  • 您的組織充分了解新的或變更的策略,他們會以強烈的動力採取相應的行動,以幫助彼此實現領導層設定的總體目標和指標。

  • 存在的機制可用來及時通知團隊成員已知的風險和計畫的事件。

  • 組織會更有效地採用新的工作方式 (包括對人員或組織、程序或技術的變更) 以及所需技能,而且您的組織可更快速地實現企業利益。

  • 團隊成員了解溝通事項,他們可以更有效地完成工作。

未建立此最佳實務時的曝險等級:

實作指引

若要實作此最佳實務,您必須與組織中的利益相關者合作,以同意溝通標準。在組織內將這些標準公告週知。對於任何重大的 IT 轉型,與忽略此實務的組織相比,已確立的規劃團隊可以更成功地管理變更對其人員的影響。大型組織在管理變更時更具挑戰性,因為與所有個別貢獻者一起建立對新策略的強有力支援至關重要。如果沒有此類轉型規劃團隊,領導層 100% 負責有效溝通。建立轉型規劃團隊時,指派團隊成員與所有組織領導層合作,以定義和管理各個層面的有效溝通。

客戶範例

AnyCompany 零售已註冊 AWS Enterprise Support,並取決於其他第三方供應商的雲端操作。該公司透過聊天和 chatops 作為其運營活動的主要溝通媒介。特定管道會填入提醒和其他資訊。人們必須展開行動時,他們會明確說明預期成果,且在許多情況下他們會接收執行手冊或程序手冊以供使用。他們可使用變更行事曆來排程生產系統的重大變更。

實作步驟

  1. 在組織內建立一個核心團隊,負責為組織內多個層面發生的變更制定和啟動溝通計畫。

  2. 建立單線程擁有權以實現監督。賦予各個團隊獨立創新的能力,並平衡使用一致的機制,從而實現適當的檢查水平和方向性願景。

  3. 與組織中的利益相關者合作,以同意溝通標準、實務和計畫。

  4. 確認核心溝通團隊是否與組織和計畫領導層協作,代表領導者為適當的員工製作訊息。

  5. 透過公告、共用行事曆、全手會議和面對面或 one-on-one方法,建立策略溝通機制來管理變革,讓團隊成員對應該採取的動作有適當的期望。

  6. 提供必要的背景知識、詳細資訊和時間 (如果可能的話),以確定是否需要採取行動。當需要採取行動時,請提供所需的動作及其影響。

  7. 實作可促進戰術溝通的工具,例如內部聊天、電子郵件和知識管理。

  8. 實施機制以衡量和驗證所有溝通是否都能達到預期成果。

  9. 建立一個回饋迴圈,以衡量所有溝通的有效性,尤其是當溝通與整個組織中的變革抵制有關時。

  10. 對於所有 AWS 帳戶,請建立帳單、安全和操作的替代聯絡人。理想情況下,每個聯絡人應該是電子郵件分發,而不是特定的個人聯絡人。

  11. 建立升級和反向升級通訊計劃,與您的內部和外部團隊互動,包括 AWS 支援和其他第三方提供者。

  12. 在每個轉型計畫的生命週期中始終如一地啟動和執行溝通策略。

  13. 排定可重複動作的優先順序,以便大規模安全地自動化。

  14. 在具有自動化動作的情況下進行通訊時,通訊目的應該是通知團隊、進行稽核或作為變更管理流程的一部分。

  15. 分析來自提醒系統的通訊,找出不斷建立的誤報或提醒。移除或變更這些提醒,使其僅在需要人為介入時啟動。如果啟動了提醒,請提供執行手冊或程序手冊。

    1. 您可以使用 AWS Systems Manager 文件,為提醒建立程序手冊和執行手冊。

  16. 已設立機制,以清楚且可行的方式提供風險或計劃事件的通知,並提供足夠的通知,以便適當的回應。使用電子郵件清單或聊天管道,在計劃性事件發之前傳送通知。

    1. AWS Chatbot 可用於在組織訊息傳遞平台中傳送提醒並回應事件。

  17. 提供可存取的資訊來源,您可以在其中發現計劃的事件。提供來自相同系統之計劃事件的通知。

    1. AWS Systems Manager 變更行事曆可用於在可能發生變更時建立變更時段。這可為團隊成員提供有關於何時可安全進行變更的通知。

  18. 監控漏洞通知和修補程式資訊,了解外部漏洞以及與工作負載元件相關的潛在風險。提供通知給團隊成員,以便讓他們可以採取動作。

    1. 您可以訂閱 AWS 安全公告,以接收 AWS上的漏洞通知。

  19. 尋求不同的意見和觀點:鼓勵每個人的貢獻。為代表人數不夠的群體提供溝通機會。在會議中輪換角色和職責。

    1. 詳細闡述角色和職責:為團隊成員提供機會,讓他們承擔他們可能不會承擔的角色。他們會透過角色,以及與他們可能不會與之互動的新團隊成員互動,而獲得經驗和觀點。他們還將自己的經驗和觀點帶到新的角色,並帶給和他們互動的團隊成員。隨著觀點增加,確定新興的業務機會或者新的改進機會。在團隊成員之間輪流處理其他人通常執行的常見任務,以了解執行這些任務的需求和影響。

    2. 提供安全且友善的環境:制定政策和控制措施,以保護組織內團隊成員的心理和身體安全。團隊成員應該能夠在不擔心報復行為的情況下進行互動。當團隊成員感到安全且受歡迎時,他們才更有可能參與進來並具備生產力。您的組織越多樣化,您就越能了解所支援的人員,包括您的客戶。當您的團隊成員感到安心、可以自在的暢所欲言,而且有信心他們的聲音不會被淹沒,他們才更有可能分享寶貴的洞見 (例如,行銷機會、可及性的需求、尚未有服務的市場區段、環境中未確認的風險)。

    3. 鼓勵團隊成員充分參與:提供員工充分參與所有與工作相關的活動所需的資源。面對日常挑戰的團隊成員會發展出解決挑戰的技能。這些以獨特方式發展的技能可為組織提供顯著的效益。為團隊成員提供必要的便利性支援,將可從他們的貢獻中獲得更高的效益。

資源

相關的最佳實務:

相關文件:

相關範例:

相關服務:

隱私權網站條款Cookie 偏好設定
© 2025, Amazon Web Services, Inc.或其附屬公司。保留所有權利。