「產品經理全連線系列2」企業如何開展敏捷或DevOps的研發變革

大家好，我是華為雲的產品經理 恆少：

作為佈道師和產品經理，出差各地接觸客戶是常態，經常和華為雲的客戶交流、佈道、技術沙龍，但是線下交流，覆蓋的使用者總還是少數。

我希望可以借線上的平臺，和使用者持續交流華為在研發效能提升上的思索和考慮。

<恆少出品，必然妥妥乾貨，必定理論聯絡實踐>，因為軟體無銀彈，探索始終在路上。

-----------------------乾貨分割線--------------------------------------

<002 篇> 如何開展敏捷，DevOps，以及其他的研發變革        

      敏捷，精益看板，DevOps..... 技術在發展，研發的流程，方法，理念和工具也在不斷髮展。相信未來也會不斷有新的軟體研發理念，方法出現，因為軟體這個複雜的怪獸，離征服還遠著呢。。。：）

我在和很多企業交流的時候，總是會提到一個最重要觀點： 要把敏捷、DevOps這樣的新研發方法當做變革來做 ，為什麼呢？改革或者變革最困難的是什麼，也是很多變革失敗的原因其實都一條： 破除即有的利益 。熟悉中國這些年的改革，應該很容易理解。

       敏捷，DevOps，甚至新的配置管理工具Git，對於現有的很多企業都是一個巨大的轉型，很多企業在原有的模式下已經形成了自己的組織，流程，文化和工具系統，各方利益已經固化。

     我們引用DevOps（Patrick Dubois ）的一個經典圖，如下圖（Wall of Confusion），來感受一下變革是怎樣觸動即有“利益”的。產品和開發同學希望儘快的上線變更，這是產品和開發的天生訴求，而運維同學卻希望越少的變更越好，因為保證現網的穩定性是他們的天生職責。開發和運維同學的主要衝突：

不同的世界觀： 運維人員要求穩定可靠，認為變更充滿風險，開發人員則被鼓勵頻繁釋出新程式碼，認為運維部門對流程的堅持，阻礙了開發的速度；

它在我的機器上沒有問題！： 常常聽開發人員這麼說，而運維團隊的確遇到了麻煩，因為開發和運維之間的指令碼、配置、過程和環境存在差別；

溝通壁壘： 開發和運維團隊通常處於公司組織的不同部門，通常有不同的管理者，通常是不信任的關係，並且通常工作在不同的地點

      這樣天生的即有利益的衝突，是所有研發變革最大的挑戰，也是導致失敗的最大因素，怎麼辦呢？且聽恆少下次分解。

相關文章：

【產品經理-全連線系列 之001】Epic/Feature/Story/Task/Bug到底是什麼？

【產品經理-全連線系列 之003】華為敏捷/DevOps實踐一點一滴（1）_如何開好站立會議

我會定期在華為雲社群與大家互動交流，感興趣的朋友歡迎到我負責的產品板塊發帖交流：