敏捷轉型系列之敏捷轉型不是全盤否定

敏捷轉型系列之敏捷轉型不是全盤否定

敏捷轉型系列之敏捷轉型不是全盤否定

敏捷,近幾年是火出圈的一個詞,以前是軟體開發或者往大點說是IT圈的名詞,現在已經是各行各業爭相追捧的熱詞。姑且不說此敏捷非彼敏捷的事情,但就這個現象來說,敏捷是有可取的地方,值得去研究。

咱們還是說回老本行-IT圈吧,敏捷轉型是很多IT企業尤其是軟體企業面臨的實際的問題。企業市場規模不斷增大、客戶越來越多、員工越來越多,隨著而來的問題也就越來越明顯,市場競爭越發激烈、客戶的需求總在變化、員工的墮怠導致效率降低,總是聽說敏捷,感覺是根救命稻草,但是一想到敏捷轉型,就感覺是要像推翻舊社會三座大山一樣困難,而且結果難料,總之是困難重重、風險大大。

敏捷轉型就真的是要全盤否定麼?傳統專案管理方式就真的一無是處麼?我要肯定地說“不是”。敏捷轉型決不是全盤否定、推倒重來,如果真的是執行全盤否定、推倒重來,那才真的是災難的開始;敏捷轉型一定是潤物細無聲的滲透,而且是和傳統專案管理方式融合、互補的。

我們先來說說敏捷的由來吧。敏捷的起源普遍的共識是2001年2月13日發表的敏捷宣言為標誌的,敏捷宣言是由17位軟體開發領域的領軍人物經過兩天的時間討論形成的,這17位參會者分別來自於極限程式設計、Scrum、DSDM、自適應軟體開發、水晶系列、特徵驅動開發、實效程式設計的代表們,還包括了希望找到文件驅動、重型軟體開發過程的替代品的一些推動者。其實仔細分析一下,敏捷就是來自於經驗和實踐,是對傳統軟體開發方式的補充、改進的方法的總結,形成了敏捷的普適性的理念-敏捷宣言。也就是敏捷從誕生開始就是在傳統軟體開發理論或者說傳統的專案管理理論的改進和實踐,敏捷誕生的過程就是發現問題-制定改進計劃-實踐改進方法-檢查改進效果-再總結改進的過程,這就是樸素的管理理論PDCA迴圈。由此可以看出敏捷也是要遵從基本的管理理論的,是在此基礎上的實踐,是經驗和實踐的積累和總結。

敏捷轉型從根本的目的來說,是要解決企業或者團隊的現有模式的管理問題,那就是要從總結現有模式的好和不好開始,好的方式要保留,不好的方式要改進。如何改進?改進的方式我認為絕不止敏捷一種,或者說是敏捷現有的流行的那幾種敏捷方法,更多的是要學習敏捷背後的精神和理念。例如敏捷中SCRUM框架中採用的每日站會,每日站會能解決什麼問題,我認為每日站會是對昨天工作的總結、今天工作的計劃,更重要的是發現的問題的溝通,這就能解決傳統管理中的“學生綜合症”問題以及溝通不暢的問題。既然能解決問題,那我們就可以在現有的團隊或者專案管理中引入這個制度。這就是個簡單的舉例,實際應用還是要根據不同的團隊情況和專案狀態進行調整。

總之,敏捷和傳統是同根共生的,敏捷轉型是要和傳統管理相融合的,是要循序漸進的,潤物細無聲似的滲透。