數位轉型-準備篇(三)：練好轉型會用到的功夫

正因為數位轉型的不確定性，所以你需要“學習”

只要談到了組織的學習，會充斥著許多的觀點和框架，以這幾年最流行的一些方法或概念，莫過於 “敏捷 ( Agile )” 了，為何敏捷的專案管理也罷、冠上敏捷之名的組織也好，會這麼熱，都要感謝許多的媒體、大師或報導一直在提及 VUCA (volatile, uncertain, complex and ambiguous) 「波動、不確定、複雜和模糊」。

為了因應 VUCA 世代的挑戰，過去從分析開展策略到戰略執行的邏輯和方法，顯得有點追不上變化，因此敏捷這種小而美的戰鬥形態和思維，就容易脫穎而出。筆者稍微比較一下古典的專案管理和 SCRUM 的專案管理(敏捷的方法之一)，大家就可以體會到 “學習” 這件事在兩者之間的差別。

古典專案管理這樣做

古典的專案管理偏重於需要規劃好地圖，再逐步的依照地圖去執行，每當執行了一小段，都要來個超級比一比，如果產生了差距，就可能走向變更的流程，透過變更來修正地圖，確保地圖的可用性和可比較性；當專案走到了尾聲，因為有著許多的紀錄資訊 (e.g. Issue Logs, Change Logs)，所以可以從中體會和整理出如何讓下一次專案更好的 Lesson Learned，讓之後的專案可以避免風險，更容易走向成功。

SCRUM 會這樣做

其實沒有絕對好的方式，但要知道的是，
不同的方法應對的情境真的不太一樣

從上述簡單比較上，可以理解到敏捷的觀點，會希望不停的從執行中、客戶觀點中去理解、學習以及應用學習的成果，當理解了這一點時，就不難理解到為何在 VUCA 的時代中，敏捷會這麼的熱門了；另外，我也非常喜歡分享敏捷的宣言，在這個宣言當中可以看到許多從人性出發的觀點…

Individuals and interactions over processes and tools.
Working software over comprehensive documentation.
Customer collaboration over contract negotiation.
Responding to change over following a plan.

個人與互動勝過流程與工具

分享一個筆者之前很失敗的經驗，記得第二次開公司的時侯，我在頭一天很開心的決定了公司應該要用的工作流程和工具，每當有新人來，我很認真的對著每個人教導這些事，好景不常，過了半年，某個案子突然在我意想不到的狀況下炸了，當時很火大啊，因為從紀錄上不容易看出來客戶的積怨和不滿，只看出我們有持續的執行和交付，後來也是親自到客戶那裡低頭道歉及割讓專案價金才勉為其難的收了個尾，是不是一個接案公司很常見的情境呢? 當時的我只知道紀錄是重要的，卻忘了多走個幾步路，去聽聽工程師、PM 的想法，相信只要你是有經驗的 PM，嗅到案子的敗象其實一點也不難，但我就是沒多做這件事，而且在之後還又發生了幾次類似的事件，我才慢慢警覺到自己的錯誤。

講到這，難道流程工具不重要嗎? 並不是這樣說的，它們依然很重要，也是團隊協作和產生認同的重要基礎，但別忘了事在人為，人不顧好，就算你用上最好的流程一切也不過是一場夢。

有價值的交付成果勝過周全的文件

因為敏捷的宣言當初是以軟體工程的角度去起草，因此我們看到了 Working software. 它所代表的意義是對於客戶來說有價值的事，因為是有價值的事，它必需要滿足…

• 客戶拿得到的
• 客戶可以用的
• 符合客戶的需求情境的

這三點看似簡單，但是要達到非常的困難，這件事某種程度也促成了 DevOps 的觀點和潮流，要如何做到，當然要從掌握客戶的需求和情境做起，並搭配了 MVP ( Minimum Viable Product ) 的做法，先交付出一個可用的小成果，並從中紀錄和學習使用者的反應，例如：當有100人開始使用時，有多少人會用到最後 ? 他們多半在那個環節就放棄了 ? 放棄的原因又是什麼 ? 這 100 個人開始使用的理由是不是如我們所想的那樣 ? …等等利用數字、利用訪談等等理解關鍵在那裡，並持續的調整和演進。

客戶協作勝過合約協商

筆者曾經在這篇《親~ 你知道數位轉型比創業難嗎?》有聊到一個觀點是，只要是合約性質的專案，甲方沒有認知到自己的角色，只是想把專案的執行都丟給乙方時，那麼案子掛掉的機率會出奇的高；而在合約的簽訂上，不論中外，會發現絕大部份都是保障甲方居多；這一點並不是要甲方放棄保障或權利，但希望有積極一點的是，在執行的過程中，應該是相互尊重的、相互幫忙的，而不是單純的指揮或頤指氣使。

響應變化勝過照計劃進行

這一點有個誤區，千萬別搞錯了，並不是照著計劃有錯，只是如果計劃本身應對變化反應不夠快時，也許會偏離專案中的那個北極星；加上，古典的專案管理改計劃不是那麼簡單，不只是文件的問題，更多的是高層會不開心的問題，導致有不少計劃是寫完之後束之高閣而失去了做計劃的意義。

既然會有這樣的情境發生，而且修正計劃又是常態，不如在每次的執行過程中，再去計劃就好，將計劃演變成為執行的內容之一；講到這裡，筆者不得不談一下其實這一點是宣言中最難以讓高層接受及信服的一條，如果你開車時有用過 google map 或其他的導航工具，其實你並不會太介意開到一半重新修正路線，反正到得了就好；但是啊，比較傳統的公司的習慣是，終點不能動、里程碑不能動、預算不能動，只要產生了任何衝擊或改變，直接會把責任怪到執行者或 PM 控制不力上，而這個心態扼殺的其實不是事情能不能做好，而是不會有人願意去嘗試或冒險，它真正扼殺的是數位轉型中最重要的一件事 “學習”。

金庸小說中的張無忌能學成太極成為一代高手，
不在於學會了形，而是理解了意

而你要如何練好轉型會用到的功夫，不外乎就是把這四條宣言放在心中並去實踐它，不論你選用了 SCRUM 或者是 Google Design Sprint 又或者是應用了 OKR，不論是那一種工具，這四件事都是核心的原則，只有持續的練習這些 “功夫” 才有辦法讓數位轉型可以做得好。