這本書的讀後心得是，被坑了，之前讀幾本作者是日本人的麥肯錫系列很好閱讀很實用才會買這本書的，但這本書不好讀，讀起來巨累的，而且收穫有限。

話題性是還不錯，很專業很先進，但這是讀得來的人壓根不需要讀，讀不來的人為同嚼蠟，而那些只是想得到一些口號專有名詞唬人的，大概會得到對他們來說可能有點用，但實際上沒有任何價值的幻覺。

這本書是把幾個主題融合在一起。

最主要的是數位轉型，也就是資訊化提升競爭力。

手段是敏捷，這個敏捷是專有名詞，是那個敏捷，與字面上的敏捷只是有點相關，是軟體行業的一種方法論。

另一個重點則是軟體技術，書中推崇DevSecOps，這個是創新的專有名詞，就是DevOps加上資訊安全強化的Sec弄出來的酷名詞，API開發解藕以及快速可擴充規模化的技術如容器與K8s等等。

與書名有關的，則是人工智慧與機器學習，用敏捷方法加上DevOps等技術，來做企業的數位轉型，主題是這個。

與之配套的人力資源管理很重要。

以客戶體驗為出發點，UX直接融合到敏捷流程裡也是這本書的重點之一，這部分是傻蛋覺得有實用的部分，書中的比重很低就是。

關鍵問題就是，書裡隨處很多看表面是簡簡單單的一個章節，有圖表或表格式的參考範例資料，乍看好像很容易讀，實際上，裡面很多細節都是需要相關經驗背景才能正確理解的。

傻蛋是剛好大部分都略有涉獵，所以讀起來才特別累。

涉獵的主題太多太廣，每個又僅用少少的文字描述帶過，但又沒把概念與基礎交代清楚，如果不仔細的針對每個看似平常的專有名詞去深入了解，會很容易對書中的主題產生誤解的。

而且也會有倒果為因的嫌疑，到底是企業規模很大才會做這些事，還是有做這些事才能有這麼大的成功規模，相當之可疑。

需要幾百支甚至上千支敏捷團隊開發的組織，這個聽起來就不是很敏捷了喔。

美國企業的規模大多遠大於台灣的企業，對於大多數的台灣中小企業來說，這本書的經驗只怕誤導大於指導，只適合那些錢太多，不做點事搞搞噱頭不好對媒體與投資人形象交代的大企業有點用吧。

這本書還是有一些專業品質，章節分類，圖表與案例的排版，看起來是有條理的，對這整個領域完全不懂的人猛然看了或許會覺得驚艷，覺得寫得很好，但那應該是用字面意義去理解許多專有名詞產生的誤會喔。

先說第一個敏捷團隊。

敏捷是一個精神，就是要靈活快速，但軟體的敏捷開發實際上是融合了許多具體實務作法，有時候或相當多的情況，並沒有達到真正的靈活高效，成功的靈活敏捷比例其實不高。

敏捷團隊著重從一個最小可運作的原型開始發展。

使用者需求最好是一開始就加入，從最少最必要的功能畫面開始發展。

然後逐步的增加更多功能，一次加一些，加了馬上看更新後的原型，馬上反饋，馬上調整，一次加一點點，直到整個需求完整成熟為止。

這樣的作法好處是避免了冗長的分析設計，脫離使用者需求的分析與曠日廢時的開發，到驗收時才發現需求根本就不對的那種尷尬。

而一些具體的敏捷方法，主流是一種叫做衝刺的管理，基本上就是兩週一個衝刺，先把需求用清單方式全部列出來，然後每一個衝刺週期開一次會挑選要實踐的需求項目，然後這一波衝刺就做這部份功能，加入原型，並結束這一回合。

這是做法。

如果一開始的需求清單品質就很糟，那麼後面的衝刺，就算姿勢再正確，做出來的成果也必然不如預期。

敏捷方法的發展現況是博大精深，有各種方法論，但敏捷的精神只有一個，就是要靈活高效的把事情做好，專業細緻的敏捷實踐方法不必然帶來敏捷的成果，更多的是求方法得方法，就是過程與管理都很形式上的敏捷方法，但反而是另一種官僚。

有效的敏捷精神，必然要有好的目標，必須要能專注在重要的事上頭，只有核心產品核心流程需要極致的敏捷，那些非核心，競爭的時間壓力也不大的瑣碎細節實際上外包就好，搞大量敏捷團隊反而是一種分心，分心基本上就不敏捷了。

而資訊化或數位化，這個主題，這本書裡面東西太多又太淺。

以資料為中心，大數據分析與資料倉儲，這些個專有名詞，後面有一堆技術。

隨便一個Hadoop或BigQuery，不是經常和其打交道的人，要在一個小時內掌握其定義與概要，並不是容易的事。

資料庫，資料倉儲，資料湖，資料虛擬化，數位孿生，喔喔，不要看這些名詞好像都很像，就當作是差不多類似的東西，往往一個名詞就是一個概念，然後有多個廠商做出類似但略有不同的產品。

要怎麼才能理解這些名詞呢，傻蛋是之前工作的公司有代理國外的類似產品，有做過一些相關調查，才知道這些名詞不簡單。

要轉化成讓一線使用者使用在實際的商業情境上，需要先對抽象的概念有具體的掌握，然後還要去安裝那些產品，試著去用用看，再試著把需求和產品去配對比較，才會知道實際上是這樣用的，哪裡好用方便哪裡不好用不合用或根本與需求不搭，這不是幾分鐘或幾小時的能做好的工作。

而這本書可以連珠炮的出現一堆這種等級的專有名詞，每個名詞看字面意思好像都很好懂，但這些名詞和實際的內涵，沒有足夠的實務經驗，那是沒辦法應用的。

所以呢，有時候看到一個表格，把裡面的專有名詞一展開，傻蛋腦袋裡的暫存記憶體就壓力很大了，這堆東西放在一起談，裡面有很多是傻蛋碰過一些，知道水有點深，或是有些是真的碰得比較多知道實際上是怎麼回事的，很多時候一句話就有很大的質量，讀沒幾行眼皮就變沉重了。

資訊化簡單說就是把組織的資訊集中定義與保存與使用，來讓工作流程可以標準化與自動化，大概念好懂，但知易行難，實行各種細節可以有大量的變化。

資訊化不可以被技術細節牽著鼻子走，必須要集中專注於客戶需求與核心商業模式，要強化自己的商業模式與相對競爭力，越直接越好。

不然誘惑太多了，細節與各種產品和方法，太多太多了，每一種都努力做一點，全部加起來通常只會得到失焦與失敗的失能組織。

有具體的事情可以努力，大多數人都是矇著頭幹，反正就對自己被指派的任務負責，一開始的任務目標就發散，高階主管的專注力就會被不重要的事情吸引，然後整個組織窮忙了。

另外這本書對軟體工程師也有一些的看法。

好像只有敏捷開發加上最流行的DevOps與雲端技術架構，再加上各種專業技術如機器學習與生成式人工智慧大語言模型等，才是構成有效的軟體建構的基礎。

軟體工程領域有很多角色，各角色之間是有分工的。

早期是軟體工程師與系統工程師，主要分兩類，前者主要寫程式包括使用者介面與數據等，後者主要管網路硬體環境與資安等。

軟體工程師現在則分前端，後端與全端三種，前端主要負責使用者介面，後端負責數據邏輯，全端兩者都包。

看起來全端好像就是以前的軟體工程師而已，實則不然。

實際上，現在的角色定位是更加混亂的，後端工程師通常需要融合一部分以前系統工程師的專業，而前端與後端常常有各自的技術，後端通常都是API的解藕的架構，而全端則不一定，有些全端只是單純的使用較早期未做前後端分離解藕的技術，開發的形式就是前後端是一起處理的，而有的全端則是要同時做前端與後端，還有一種全端是前端加後端加系統網路架構什麼都要負責。

什麼都要會，如果還要加上什麼都要精通的話，那個能找到的全端工程師就會是鳳毛麟角了，會同時需要很好的天賦，以及對工作的熱情與大量時間的投入，才有機會追趕上來。

其實呢，分工做好的話，效率會更好，每個專業都有專人負責，每個專業需求都有人足夠深入的挖掘，又能靈活的彼此支援，才能讓生產力最大化，現在的DevOps其實是反分工的，每個工程師需要會的東西更多，但大部分又是重複的。

而需要更深入的挖掘，例如使用的框架有效能問題，可能會碰到如數據庫性能與框架工具使用時的一些障礙，過度追求DevOps流行，很多時候團隊是沒那個力氣去優化的。

就已經忙不過來了，要學的，要跟的技術夠多了，哪管得了那麼多?

沒看書中說的嗎，大企業的數位轉型需要的數位人才，人數是成百上千的，需要大量團隊，而且還鼓吹自建內部人才，不要用外包，看喔，有那麼多事可以做，如果老闆摳一點，用一個人做五個人的事，大家是不是都不用睡覺了?

實際上，傻蛋的經驗是，當完成一件任務後，可以針對已確實完成的任務來做檢討，再設法加以優化或自動化，達成同樣的成果，用更少的心力。

只要掌握主動，能抽得出時間來做優化，就能得到更多時間作優化的工作，最後就是能作更多有價值的事。

但新技術就是個無底洞，如果要時刻跟著最新技術，其實是沒有時間心力做檢討優化的。

傻蛋就是碰到需要學才會去學，不然呢，各種新技術，用得上的，不知道用不用得上的，或現在用得上學會時不一定還用得上的，那個選擇太多了。

傻蛋碰過的醉心於追逐與玩耍新技術的工程師，大多數都是生產力不錯，很有熱情，確實能玩出很多新東西，但品質細節與深度優化通常就不怎麼樣。

因為很容易找更多事做，也很容易帶來更多豐富有趣的複雜度，通常也就因此容易失焦，陷入窮忙缺乏成果的情況。

當然孰優孰劣是比較主觀的，但就組織能力發展來說，最好是做專業分工，每個角色都有深入發展的專家，並團隊靈活的合作才是最好的，現況是很多環境需要的是全端，要的太多，反而難以分工細緻化發展能力的。

人力資源是傻蛋之前工作經驗有涉及的。

之前就是在人力派遣公司開發維護人才招募平台的人資系統，當時也有研究是否開發一個新式的靈活人力資源管理工具，類似現在大陸的飛書那樣的工具，因為這種產品商業模式不明確，財務風險太高，也缺乏其他部份的支持，基本上就止步於研究階段。

傳統人資就是以選用育留為主要架構的。

新一點的呢，要更靈活並迎合新世代的年輕員工，則是要遊戲化的職場設計，把日常工作與考核設計得像角色扮演遊戲那樣，訂KPI要做得像在刷屬性，組織運作要像玩策略遊戲那樣，提供即時數位儀錶板。

而要有趣又兼顧有生產力的話，工作的設計必然會需要敏捷的精神，目標導向，並設法引導專注於各自關鍵的責任範圍內。

其實也就那樣，市場上能看到的相關產品服務，或是書本上的案例都是類似的。

這本書對人資的介紹則是有點歪。

需要特殊的人資團隊來針對性招募數位轉型需要的龐大敏捷團隊人力，與支援數位轉型的發展。

這真的只有超大型的組織才會有這種資源啦。

由人資很重要直接切到提供數位轉型敏捷團隊人力的人資很重要，這似乎沒有提供任何有益與有用的見解。

而真的有這種資源的公司大概也不會照單全收這作者建議的數位轉型策略的。

畢竟能成功的數位轉型基本上都是，以客戶需求或客戶體驗改善為出發點，並且足夠專注的團隊。

這本書的案例傻蛋看起來是，不夠敏捷高效的海量敏捷團隊，取得了大量的數位轉型的預算，然後做內部流程再造，以取得相對競爭優勢。

沒啥營養，有那種預算規模隨便做做也能交出一份看起來很專業很厲害的專題報導啦。

在不敏捷的組織環境裡做假敏捷的專案，或許可能用得上這本書組織好的內容。

但和之前的麥肯錫思考與工作方法的書比起來，這本書實在是沒什麼用。

所以這本書正確的打開方式應該是走馬看花，增加對一些名詞與概念的粗淺認知與熟悉，並且知道這裡面有很多專有名詞是需要深入了解，不是那麼容易懂與應用的，作為和相關專業人士討論時的談資也就罷了。

要認真的讀，認真的學習，把每個主題都google或問AI直到問到能用自己可以理解的概念掌握的程度，來通透的讀完，對本來不是技術領域的人來說，花的這個時間，大概就，會讓現在這個AI熱潮過氣了吧，同時技術與流行方法也很大概率會有新的流行花樣的。

反過來，如果對這本書的各個主題平常就有所研究的話，這本書的介紹又太淺，沒搔到癢處，也沒有讓概念變得更完整具體，反而是有些誤導，會擔心老闆被這書誤導而來亂盧一些不理性不務實的要求喔。

所以結論這本書不建議入手，基本上就是個地雷吧。