變革管理經常被視為數字化轉型之后的附加任務，相反，應該通過將以用戶為中心的變革實踐融入數字開發和交付流程中，來預先推動變革。

在過去的十年里，CIO大力投資于數字化轉型計劃，旨在改善客戶體驗、構建數據分析能力，并通過自動化實現生產力提升，這些計劃的基礎是一系列旨在加快交付周期的技術能力和策略，如建立產品管理紀律、構建云架構、發展DevOps能力和培育敏捷文化。不幸的是，許多數字化轉型的商業影響仍然未能達到預期。例如，KPMG報告稱，51%的技術高管表示他們并未從數字化轉型投資中看到性能或盈利的提升。哈佛商業評論的《數字化轉型的價值》報告指出，“雖然全球有89%的大型公司正在進行數字化和人工智能轉型，但他們僅實現了預期收入提升的31%和預期成本節約的25%。”詢問CIO們關于他們面臨的最大數字化轉型挑戰時，他們可能會提到人員問題，或者專家認定的變革管理實踐中的缺口。當CIO無法推動變革時，新的數字產品和技術能力可能會變成擱置的產品，商業價值也會因此延遲或減少。Dunelm Associates的CIO兼管理合伙人Martin Davis表示，不要過早宣布成功：“許多項目在流程或系統實施時過早宣布成功，卻未意識到變革管理工作必須在實施后繼續一段時間，以實現其全部價值。”

協調變革

數字化轉型計劃中的變革管理包括吸引利益相關者參與規劃，幫助員工易于采用，以及改善客戶和所有參與計劃的人的體驗。在任何轉型計劃的開始階段，規劃階段會出現動力下降，這時需要說服高管投資于數字化轉型，并與業務利益相關者合作，制定優先級路線圖。由于高管和利益相關者協調問題導致的長時間、復雜和昂貴的前期規劃過程可能會錯失機會，尤其是當競爭對手更快地將能力推向市場時。但更大的挑戰通常出現在下游，當負責領導數字化轉型計劃的數字先鋒們必須與終端用戶一起處理流程變化和技術采納問題時。當DevOps團隊發布對應用程序、儀表板和其他技術能力的更改時，終端用戶會在有效利用新能力之前經歷生產力下降。這種下降延遲了業務開始實現所交付價值的時間。雖然有許多變革管理框架和認證，但許多框架將變革視為與CIO用于規劃和交付數字化轉型計劃的產品管理、敏捷和DevOps方法論不同的學科。這是一個問題，因為術語、哲學和職責之間的不匹配可能導致流程缺口，或更糟糕，不同領導者推動不兼容的方法論之間的流程戰爭。智能制造公司Connektedminds的首席執行官及主要負責人Joanne Friedman博士表示，數字化轉型的成功協調需要跨學科的整合交響曲：“CIO面臨的挑戰是調和不同的學科，如設計思維、產品管理、敏捷方法論和數據科學實驗。這就像試圖讓爵士四重奏、搖滾樂隊、古典樂團和DJ和諧演奏。”因此，減少生產力下降和簡化終端用戶采用實踐必須符合數字化和轉型運營模型。讓我們考慮三個領域，CIO和數字化先鋒們可以將變革管理注入他們的數字化轉型計劃中，這種方式比將變革管理作為單獨的附加項更有效。

產品經理必須從“為什么”開始

暢銷書作家西蒙·西奈克（Simon Sinek）建議偉大的領導者從“為什么”開始，這是有充分理由的。Clear Skye的首席執行官約翰·米爾本（John Milburn）說：“與同事合作時，要關注‘為什么’而不是‘做什么’。雖然CIO看到了大局，但他們的同事需要知道這種變化將如何使他們受益。”CIO必須采取措施確保他們的同事理解數字化轉型計劃的重要性，他們也必須依靠他們的數字化先鋒對其利益相關者和團隊做同樣的事情。我們要求員工實施許多變化，并持續改善結果。除非員工理解一個計劃的重要性、它將在哪里產生商業價值以及為什么他們應該關心，否則他們會將此視為額外的工作和壓力。StarCIO的變革顧問和教練Janette Gleyzer表示，數字化先鋒應該通過回答反思性問題來解釋“為什么”，例如什么定義了成功以及過去的失敗中出現了哪些模式。數字化轉型中變革管理的最頂層由產品經理或某些組織中的項目經理負責。他們必須通過傳達一個簡單易懂的愿景聲明來開始這一過程，該聲明定義了目標客戶、價值主張和戰略重要性。大型組織將超越創意工作流程、愿景聲明的編寫和制定路線圖，進行價值流程繪制以幫助將戰略與執行、交付和變革管理聯系起來。價值流程繪制可以成為幫助員工了解其工作價值的重要工具。ExpandAP的創始人兼首席執行官保羅·文克（Paul Wnek）表示：“精明的數字化轉型領導者會依靠價值流程繪制來使每個決策者和利益相關者熟悉技術在每一步的工作方式，展示它對企業和個人能做什么的清晰愿景。當數字化先鋒考慮到他們將接觸的所有利益相關者，并分別解決每個利益相關者的關切時，成功的機會最大。”

敏捷團隊必須在沖刺期間承諾進行變革管理

變革管理不僅僅是產品經理的責任。他們應該為其敏捷團隊設定期望，簡化最終用戶的采用過程。敏捷和Scrum方法論大多強調交付活動，當團隊專注于每個沖刺完成用戶故事時。產品負責人和Scrum主管還必須使團隊參與規劃活動，包括編寫用戶故事、估算工作量和整理待辦事項列表。Solix Technologies的執行董事約翰·奧特曼（John Ottman）說：“除了推動Scrum的節奏、協調和儀式之外，Scrum主管需要與產品負責人緊密合作，驗證史詩、用戶故事和任務是否都清晰且得到適當記錄，以確保每次沖刺的預期結果符合期望。”文檔和精心編寫的用戶故事指導團隊完成工作并滿足要求。當產品負責人與利益相關者、主題專家和參與用戶驗收測試的員工分享要求時，它們也可以用于變革管理活動。向最終用戶展示用戶故事中的所有細節可能會讓人不知所措，因此敏捷團隊應該尋求簡化它們以支持變革管理活動。例如，Atlassian Confluence等工具可以從Jira Software中提取用戶故事的部分，以便產品負責人簡化展示。另一個選項是使用生成式AI工具來總結一個沖刺中完成的用戶故事，并幫助編寫發布說明。最佳選項是當產品團隊在開放的沖刺審查會議中審查要求，邀請關鍵利益相關者和最終用戶參加。更進一步，我希望看到敏捷團隊將變革管理活動作為他們每個沖刺承諾的另一種工作形式。這應該包括參與培訓活動、訪問最終用戶、審查性能指標以及捕獲他們可以用來改進工作的其他形式的反饋。

DevOps不應該破壞變革管理

敏捷團隊多久應該將代碼發布到生產環境中？許多采用 DevOps 最佳實踐的團隊已經使用 CI/CD 自動化了他們的部署流程，實現了持續測試，并對他們的安全和操作有足夠的信心來實施持續部署。自動化提高了質量并減少了工作量，但頻繁的部署可能不適合最終用戶，并可能加重變革管理活動的負擔。DevOps 團隊必須考慮對最終用戶的影響，并且他們有幾個選擇來減少對最終用戶的影響。

以下是四個 DevOps 建議，以增加部署頻率而不復雜化變革管理并對最終用戶產生負面影響。

1. 僅對影響最終用戶較小且變革管理要求最低的小修補和微小更改自動化持續部署。

2. 當部署更改工作流、用戶界面和新功能時，實行更加受控的發布管理流程。

3. 創建功能標記并決定哪些用戶可以對新功能提供早期反饋，然后再向更多人推廣。

4. 利用金絲雀發布和控制將新功能推出給小部分用戶群體。奧特曼補充說：“首先向選定的少部分用戶實施新功能，讓他們進行測試并提供反饋，可以確保一旦變更被接受，更新對整個用戶群體來說都將是成功的。”變革管理實踐是從數字化轉型舉措中取得商業成果的不可或缺的部分。