書摘《原來你才是絆腳石》

2023/09/07閱讀時間約 9 分鐘
raw-image
這本書其實是參加 Agile Taipei 2018 時買的,還跟作者簽名合照,回到家後很『不』快地看完,大概是因為自己喜歡待在新創公司,有點難體會『大』企業的轉型困難點,現在回頭看一下當年畫的筆記,多了不少感受。

前言

接下來是所有的組織轉型,不論敏捷與否,都不是一朝一夕之功,而是常期抗戰,身為轉型領導者或推動者,我們只能『播』下改變的種子,時時關懷『灑』水,期待改變的力量在轉型的大『道』上到處開枝散葉。 p.xxviii

在企業轉型的路上,沒有兩個企業是一模一樣的,也沒有一套必勝的套路,我們需要隨機應變,視情況找尋當下最適合的做法,持續實驗,並從中學習。 p.xxviii

我們透過劃分為四個核心價值:自組織 (Self-organization),透明化 (Transparency),顧客導向 (Constant Customer Focus) 和持續學習 (Continuous Learning),來深入瞭解這四種流派的立論基礎。 p. xxix

Part 1 世局險惡

第 1 章 當今的挑戰

企業生存在一個「霧卡」的世界中。霧卡 (VUCA) 的含意是:不確定 (Volatility),不確定 (Uncertain),複雜 (Complex) 和模糊 (Ambiguous)。p.3

而在當今企業中,由於市場,競爭對手和其他影響因素快速地變化,長期計劃往往在計畫完成時 (甚至尚未完成時) 就過時了 …… 因此企業無法像過去一般預測和計畫未來,至少長期計劃是無效的,這驅使企業以更敏捷的方式來計畫。 p. 4

雖然讓大型組織扁平化可以提高創造力,但也會產生更多衝突,讓困難的決定變得更加困難,也會迫使員工離開。因此解決價購問題並不簡單,解法必須要更加微妙和細緻,並且把規模和人才等因素考慮在內。 p. 4

而當今的企業是應該先確定職務在尋找人才?還是他們應該先找人才,然後看看他們能做些什麼?後者可能會激發更多的創新。 p. 5

創新不太可能來自一個蘿蔔一個坑的螺絲釘。 p. 6

敏捷的做法是經驗導向,經由摸索後浮現的,而且注意力應放在與如何交付價值給顧客 (以提供產品或服務的形式)。 p. 9

第 2 章 廣發英雄帖

我們討論了許多主題例如技術、流程、王畫、價值觀等等。然而,人們似乎只記住和模仿一件事,那就是團隊架構:小隊 (Squad)、部落 (Tribe)、行會 (Chapter) 和公會 (Guild)。 p. 17

這在書摘《全員敏捷》也有相似的說法,畢竟形式容易學,內功難練。

我們擁有高度信任、容許失敗的文化,並且可以輕鬆實現團隊自治。 p. 17

我們決定結合其他三種流派來改善組織的設計,這三種流派分別是:

  • 超越預算模型 (Beyond Budgeting)
  • 開放空間技術 (Open Space)
  • 全員參與制 (Sociocracy)

我們也少量的使用其他的流派來闡述價值,例如精實創業 (Lean Startup) 和設計思考 (Design Thinking)。 p. 20

Part 2 華山論劍

第 3 章 自組織

整體中每個人的聲音都是有意義的,這就是自組織和創新思維的先決條件。 p. 41

透過共同的價值觀和合理判斷來治理;而非詳盡的規則和制度。 p. 43

培養對組織具有強烈的歸屬感及當則的團隊;而非受階級制度和官僚主義控制。 p. 43

全員參與制不是單一地命令連結,只由抽象到具體 (「由上往下」),而是有第二個權力系統,讓權力也可從具體往抽象流動 (「由下往上」)。這種雙向影響系統被稱為雙連結,意味著在每個層級上,除了主管 (從抽象到具體的觀點),還有一位選派的代 (由具體到抽象的觀點) 來表達看法。 p. 45

交付完整的產品、完整的功能、或用戶需求,除了作為團隊的共同目標,也是自組織的另一個先決條件。 p. 46

以認可決來做出決策,建立人人對等的文化,參與者的發言都受到同等的重視。 p. 50

自組織可以提高成員間的信任。如果鼓勵自組織的架構運作良好,那麼信任程度應該會隨著時間的推移而增加。 p. 51

第 4 章 透明化

我們所說的「透明化」 (Transparency) 是指資訊的取得容易性,以便人們可以做出有根據的決定。 p. 52

透明化是透過社會壓力來讓人們自我調節行為。 p. 53

透明化指的是需要資訊來完成工作的人,可以容易地找到資訊。 p. 53

全員參與制 (Sociocracy) 將透明化定義為:可獲取做決策所需要的所有資訊,而不是「每個人都可以看到所有的資訊」。但團隊要能看到需要的所有資訊,這意味著取得資訊實沒有不可逾越的障礙。讓資訊容易被取得的原因是,隱藏資訊的人可以輕易地操縱和控制他人,這違反了自組織中的我們討論過的對等性。 p. 55

第 5 章 顧客導向

相對目標:需要展現出我們的雄心壯志,但盡可能避免是絕對數值的目標。 p. 59

滾動式預測:此方式可以提高估計的準確度,藉由估計會發生什麼是和需要什麼調整。 p. 60

我們以持續供給的方式,在對的時間和杜的層級做出決定。這代表推遲決定的時間,得到更好的資訊在需要時才做決定,決定專案、活動、和我們的執行的強度。 p. 60

績效評量的重點是在學習,而不是個人的獎勵,特別是從如何讓企業成功的角度來看。 p. 61

關鍵是企業必須盡一切所能來獲得顧客的反饋,還要預測顧客需求的演化方向,甚至是革命性的需求翻轉。 p. 63

在一個瀑布式軟體專案中,團隊首先將分析所有的需求,這意味著在很長一段時間內沒有任何東西可以交付給顧客,因此很難獲得任何有價值的反饋。 p. 65

這裡,所有的需求,要小心看待「所有」的範圍有「多大」。

第 6 章 持續學習

持續學習的想法雖然聽起來很棒,但卻很容易被人忽略。 p. 71

要讓企業在當今取得成功學習效率比投資回報率更重要,因為學習效率支持了仇報率。 p. 72

全員參與制的參考文獻也說明「發展」意味著進行與目標有關的學習、教學或研究,有些全員參與制組織試圖為發展保留至少 5% 的工作時間。而需要再次強調的是,至今尚無通用的方法能夠成功地避免在危機時期,人們傾向於專於手上工作而犧牲了投入發展的時間。 p. 72

當人們從學徒、學長、到師傅前進的過程中,無論是哪個科目在提高技能和知識時,更多的訓練時間會花在自己進行研究,而非花在接受教導。 p. 74

這也許可以解釋在公司舉辦 workshop 效果不見得好的原因?

第 7 章 見證新流派的誕生

生產單位也許會尋求顧客的回饋,可是關注點卻往往被放在提供服務上,而並非獲取回饋。 p. 80

這種依照功能來劃分的缺點之一是,在缺乏溝通的情況下每個部門自掃門前雪。而矩陣型組織就是為了對抗這個缺點而產生,垂直的代表工作分解架構,水平的代表跨功能的專案或產品團隊。 p. 85

因為 Scrum 強調自組織團隊,新的架構中團隊中不再有小組長,團隊內沒有任何一個人有高過其他人的權利。Scrum Master 處於團隊之外,並由團隊自行選擇由誰擔任他們的 Scrum Master。 p. 87

Part 3 闖蕩江湖

實事是所有的組織都是建築在錯綜複雜的信任網絡上,階層組織只是勉強靠在其上的鷹架,價值觀和政治關係都是由信任網絡所塑造的。 p. 95

主管們該如何才能確保組織內深遠有效的改變?他們必須先從信任網絡中找出關鍵的被信賴核心人物。因為在隨著改變接踵而來的紛爭或創傷中,圈子裡的信賴遠比階層的權勢更能服人。 p. 95

在探測時不存在所謂的失敗。因為不管探測是成功還是失敗,重點永遠在於學習。因此,你必須強調目標是學習,而非探測會達到成功,這才能將探測變成一個「失敗得起」的行動。 p. 97

在「儘管去做 (Just Do It)」提及的模式所指,不要去等待資源完備和知識具備的完美瞬間;相反的,踏出那一小步並開始學習。 p. 97

產品管理無法預測顧客未來的需求,而產品開發無法在開發前準確預測產品開發所需要的心力。 p. 98

第 8 章 策略

策略就是企業確立其基本的長期目標,並採取適應性行為和資源配置來達到這些目標。 p. 102

安排一些團隊成員與顧客一起工作,透過體驗顧客的日常工作來瞭解他們的需求。預期結果是團隊會想出更好的方案來解決顧客的需求,並且更對團隊的共同目標有更深刻的理解。 p. 109

每家公司裡的各個領域都有專屬的人際信任網絡。這些信任網絡的領導者往往有著能影響公司動態架構的能力。 p. 111

這可能不是作者的本意,但這聽起來就像是上有政策下有對策的感覺。

第 9 章 架構

為了做出有效的決策,你需要考慮制定良好且決策被接納所需要的時間,而不是僅僅關注於截止日期。 p. 126

第 10 章 流程

團隊常常在還沒有真正瞭解情況前,就直接跳至解決方案。他們最終會越搞越糊塗,例如治標不治本或嘗試解決根本不存在的問題。 p. 131

如果有解決方案被提出,引導者可以把方案紀錄在另一張紙,然後回到圖像組成的流程,依此來引導討論聚焦在問題本身。 p. 132

流程順暢不僅僅是指消除等待時間。為了順暢你有時候需要延遲時間。 p. 135

團隊努力學習技能、提升表現,最終卻被告知績效只能透過鐘型曲線來分配。那為什麼要如此拼命呢? p. 136

第 11 章 持續精進

熟練代表在壓力下也可以保持運用該技能的水準。任何人都可以在課堂環境中遵循一套實踐,但在面對壓力和干擾的情況下,一個團隊真正的熟練度就會展現出來。 p. 146



後記

這本書其實還有第 12 章,但主要內容是企業與社會的關係,有很多例子,但沒有特別劃下的重點,所以上面就沒有第 12 章的內容了。

當初買這本書,是被書名吸引到的,原文書名其實很平實,在書中其實有一頁「關於書名」的說明,但中文書名還是太有趣了,特別是副標題。

51會員
100內容數
這是從 Medium 開始的一個專題,主要是想用輕鬆閒談的方式,分享這幾年軟體開發的心得,原本比較侷限於軟體架構,但這幾年的文章不僅限於架構,也聊不少流程相關的心得,所以趁換平台,順勢換成閒談軟體設計。
留言0
查看全部
發表第一個留言支持創作者!