圖書描述
專案為何會落後一年？……因為每次落後一天。－《人月神話》
要有高品質的軟體，就要有高品質的管理。－《溫伯格的軟體管理學》
《溫伯格的軟體管理學》一套四冊，主題分彆是：
一、 係統化思考（Systems Thinking）、
二、 第一級評量（First-Order Measurement）、
三、 關照全局的管理作為（Congruent Action）、
四、 擁抱變革（Anticipating Change）。
本書是這個係列的第四本，要談的主題是：如何創造一個有利於軟體工程進行的環境。前三本書已談過為瞭創造高品質的軟體，如何進行高品質的管理；而這本書是說明如何創造齣實踐必要的變革所需之環境，在這種環境下，專案的品質與生産力都會有大幅的進步。
變革聽起來很偉大，其實就是改變，無論是組織引進一項新工具、改善流程、或是來瞭一個新主管，或是在個人層次的改善，都是一種變革。為瞭能夠成功變革，個人和組織都必須學習，能夠成長。
然而軟體這個行業，由於一直以來未能創造齣一個有利於軟體工程的環境，使得軟體産業在實踐品質與生産力方麵，大多數都以失敗收場。為瞭改善糟糕的情況，大多數的經理人將錢花在工具、方法論、外包、訓練、套裝應用軟體上，而沒有用心去改善、或撤換掉那些造成這種後果的始作俑者－－經理人。
在本係列的前三捲已談到，想要在軟體工程的管理上獲得高品質的成果，需要具備以下三種能力：
1. 具有瞭解復雜情況的能力，讓你能夠為專案做好事前的規畫，從而進行觀察並採取行動，使專案能依計畫進行，或適時修正原計畫。（第1捲）
2. 具有觀察事態如何發展的能力，並且有能力從你所採取的因應行動是否有效，來判斷你觀察的方嚮是否正確。（第2捲）
3. 在復雜的人際關係中，即使你會感到迷惘、憤怒、或是非常害怕，甚至害怕到想要一走瞭之並躲起來，但你仍然有能力採取閤宜的行動。（第3捲）
本書所談的組織變革，就是要讓經理人運用前三捲的觀念和工具來進行管理，讓你的組織不僅現在能瞭解和實踐優良的軟體工程觀念，未來也可以。這樣的組織稱為「防範未然型」（Anticipating）的組織，它讓組織變革成為一種明確的、普遍性的功能。
「防範未然型」的文化具有四個特性：
1. 它具有有效的模型，以協助人們在理智與情感上瞭解組織與個人的改變。
2. 組織裏的員工（不光是經理人）有相當高的比例是擁有技能的變革能手（change artist），他們獲得組織實務上的支持，能夠使變革順利進行。
3. 「防範未然型」組織總是前瞻未來，並且為變革做好規畫。在變革能手的協助下，這種文化知道如何堅持到底執行計畫。
4. 「防範未然型」文化讓有計畫的變革立足於健全軟體工程實務的基礎上，使評量和預測得以進行。
本書的主題包括：常見的變革模型、薩提爾變革模型、外來成分（foreign element）、變革纔能（change artistry）、變革能手（change artist）、個人對於變革的反應、設計債務、維護債務、統閤規畫（meta-planning）、戰術性變革規畫、變革專案vs.軟體專案、流程原則與模型、為什麼專案會失敗、流程的三種含義、流程改善的三種層次、需求流程與管理、測試vs.竄改程式、正確地啓動專案、正確地維持專案、適當地終止專案、保護資訊資産、技術移轉的法則、以及六個附錄幫助復習本係列所運用到的觀念模型。
組織需要成長，個人也需要不斷學習，以因應變化，為未來做好準備。本書將幫助您成為傑齣的軟體工程經理人，並有能力帶領整個組織進行轉型。也讓您的組織能夠邁嚮永續學習、持續改善。
作者簡介
傑拉爾德．溫伯格Gerald M． Weinberg
是美國軟體工程界大師級的人物。在40多年的軟體業生涯中，他曾任職於IBM、Ethnotech、水星計畫（美國第一個載人太空計畫），並曾任教於多所大學。他更是傑齣的軟體專業作傢和軟體管理思想傢，因對技術問題與人性問題所提齣的創新思考法而為世人所推崇。1997年，溫伯格因其在軟體領域的傑齣貢獻，入選為美國計算機博物館的「計算機名人堂」成員。他也榮獲J.-D. Warnier奬項中的「資訊科學類卓越奬」，此奬每年一度頒發給在資訊科學領域對理論與實際應用有傑齣貢獻的人士。
溫伯格共寫瞭30幾本書，包括《顧問成功的祕密》、《真正的問題是什麼？你想通瞭嗎？》、《領導者，該想什麼？》、《從需求到設計》（以上由經濟新潮社齣版）、《程式設計的心理學》、一共四冊的《溫伯格的軟體管理學》等等，這些著作主要涵蓋兩個主題：人與技術的結閤；人的思維模式、思維習慣與解決問題的方法。在西方國傢，溫伯格擁有大量的忠實讀者。溫伯格現為Weinberg and Weinberg顧問公司的負責人，他的網站是www.geraldmweinberg.com
相關著作
《溫伯格的軟體管理學：關照全局的管理作為（第3捲）》
譯者簡介
何霖
美國賓州州立大學MBA，兼職從事財經企管類書籍翻譯工作，譯有《PMP專案管理認證指南》（三版）、《比率管理全書》、《軟體專案管理》、
《公司裏最難說的4種話》 、《管理工具黑皮書》等書。
著者信息
圖書目錄
緻颱灣讀者 傑拉爾德．溫伯格 7
Preface to the Chinese Editions 10
〔導讀〕從技術到管理，失落的環節 曾昭屏 13
〔推薦序〕期望改變又不想受傷害的軟工思維 王剋明 17
編輯說明 24
謝詞 35
前言 39
第一部 讓變革真正能夠發生的模型
1 一些常見的變革模型 45
1.1 擴散模型 46
1.2 地闆有洞模型 48
1.3 牛頓模型 53
1.4 學習麯綫模型 57
1.5 心得與建議 59
1.6 摘要 60
1.7 練習 62
2 薩提爾變革模型 65
2.1 模型綜述 65
2.2 第1階段：近期現狀階段 67
2.3 第2階段：混亂階段 72
2.4 第3階段：整閤與實踐階段 74
2.5 第4階段：「新現狀」階段 77
2.6 心得與建議 79
2.7 摘要 82
2.8 練習 84
3 對變革的反應 87
3.1 抉擇點 88
3.2 運用麥理曼的時區理論來決定變革介入時機 94
3.3 資訊流動的方式 97
3.4 統閤變革 100
3.5 防範未然型組織中的變革 102
3.6 心得與建議 104
3.7 摘要 106
3.8 練習 109
第二部 防範未然型組織中的變革纔能
4 變革纔能 115
4.1 個人對變革的反應 116
4.2 個案研究：變更座位安排 121
4.3 個案研究：程式碼修補 123
4.4 個案研究：知道什麼事該丟下不管 125
4.5 心得與建議 127
4.6 摘要 128
4.7 練習 131
5 大部分事情維持不變 133
5.1 你在維持什麼？ 134
5.2 揭露使用中的理論 138
5.3 變質 140
5.4 設計維護債務 141
5.5 變革纔能債務 144
5.6 破壞變革纔能 145
5.7 經理人的簡單規則 148
5.8 心得與建議 149
5.9 摘要 150
5.10 練習 153
6 練習成為變革能手 155
6.1 去上班 155
6.2 做一項小改變 157
6.3 什麼都不改變 160
6.4 改變關係 162
6.5 成為觸媒 165
6.6 完全在場 167
6.7 完全不在場 170
6.8 應用加法原則 172
6.9 安排「大旅行」（Grand Tour） 174
6.10 以史為鑑 176
6.11 將理論化為實務 178
6.12 自我發展 180
第三部 替未來的組織做規畫
7 統閤規畫第一部分：資訊 183
7.1 從統閤規畫開始 184
7.2 資訊蒐集 188
7.3 技巧 201
7.4 心得與建議 203
7.5 摘要 205
7.6 練習 207
8 統閤規畫第二部分：係統思考 211
8.1 解決問題 212
8.2 成長與規模 215
8.3 風險與報酬 222
8.4 信賴 227
8.5 移除掉完全靜止不動 230
8.6 心得與建議 234
8.7 摘要 236
8.8 練習 240
9 戰術性變革規畫 243
9.1 何謂戰術性變革規畫？ 244
9.2 開放式的變革規畫 245
9.3 以倒推方式做規畫 247
9.4 挑選實際可行的新目標 250
9.5 從頭到尾言行一緻 253
9.6 挑選與測試目標 255
9.7 什麼會妨礙達成目標？ 260
9.8 麵臨不可預測性時的規畫模型 261
9.9 迴饋計畫 268
9.10 心得與建議 270
9.11 摘要 271
9.12 練習 273
10 以軟體工程師的思維做規畫 275
10.1 工程控製的含意 276
10.2 工程管理行動的基本圖 285
10.3 控製的層級 286
10.4 心得與建議 292
10.5 摘要 295
10.6 練習 296
第四部 應該改變什麼
11 穩定軟體工程的構成要件 301
11.1 為什麼軟體沒什麼不同 302
11.2 為什麼軟體成本如此高昂 304
11.3 何處可找到改進空間 307
11.4 為什麼軟體專案會失敗 309
11.5 資訊失敗 310
11.6 找齣資訊失敗的解決方案 314
11.7 行動失敗 317
11.8 心得與建議 319
11.9 摘要 320
11.10 練習 321
12 流程原則 323
12.1 百萬富翁測驗 324
12.2 穩定性原則 326
12.3 明顯性原則 330
12.4 可評量性原則 334
12.5 産品原則 337
12.6 心得與建議 340
12.7 摘要 341
12.8 練習 343
13 文化與流程 345
13.1 文化∕流程原則 346
13.2 文化與流程互動的例子 347
13.3 流程的三種含義 353
13.4 是什麼創造瞭文化？ 358
13.5 心得與建議 360
13.6 摘要 362
13.7 練習 364
14 改善流程 369
14.1 三種流程改善層次 370
14.2 一個流程改善案例 371
14.3 讓看不見的變成可見 376
14.4 預防未來再發生 377
14.5 學到的教訓 378
14.6 但是我們公司不一樣 379
14.7 但是那代價太高 382
14.8 心得與建議 385
14.9 摘要 386
14.10 練習 388
15 需求原則與流程 389
15.1 固定需求的假設 390
15.2 軟體品質第零法則 392
15.3 需求的流程模型 395
15.4 孿生流程 397
15.5 需求的嚮上流動 399
15.6 管理階層對需求流程的態度 401
15.7 心得與建議 403
15.8 摘要 404
15.9 練習 407
16 改善需求流程 409
16.1 衡量需求的真正成本與價值 410
16.2 獲得對需求投入的控製 414
16.3 獲得對需求産齣的控製 421
16.4 獲得對需求流程本身的控製 425
16.5 心得與建議 429
16.6 摘要 431
16.7 練習 434
17 正確地啓動專案 437
17.1 專案的先決條件 438
17.2 想要的結果 442
17.3 指導方針 444
17.4 資源 446
17.5 責任歸屬 448
17.6 後果 451
17.7 心得與建議 455
17.8 摘要 458
17.9 練習 462
18 正確地維持專案 463
18.1 瀑布模型 464
18.2 級聯模型 466
18.3 疊代強化 468
18.4 可再利用的程式碼 469
18.5 原型設計 471
18.6 重新規畫 474
18.7 心得與建議 479
18.8 摘要 482
18.9 練習 486
19 適當地終止專案 487
19.1 測試 488
19.2 測試vs.竄改程式 492
19.3 如何知道專案何時步入失敗 499
19.4 使專案重生 504
19.5 心得與建議 506
19.6 摘要 509
19.7 練習 512
20 以更小規模更快速建造 515
20.1 更小的意思是什麼？ 516
20.2 縮減規格的範圍 519
20.3 消除最糟糕的部分 520
20.4 盡早拿掉 525
20.5 管理遲來的需求 528
20.6 心得與建議 533
20.7 摘要 535
20.8 練習 538
21 保護資訊資産 539
21.1 程式碼庫 542
21.2 資料字典 543
21.3 標準 546
21.4 設計 547
21.5 測試庫及其曆史 549
21.6 其他文件 551
21.7 增進資産保護 551
21.8 心得與建議 555
21.9 摘要 557
21.10 練習 560
22 管理設計 561
22.1 設計創新的生命週期 562
22.2 設計的動態學 564
22.3 艾德濛．希拉瑞學派 570
22.4 法蘭剋．洛伊．萊特癥候群 571
22.5 泰德．威廉斯理論 573
22.6 太多廚師 577
22.7 哎呀！ 577
22.8 心得與建議 579
22.9 摘要 579
22.10 練習 583
23 引進技術 585
23.1 調查工具文化 586
23.2 技術與文化 588
23.3 技術移轉定律 593
23.4 從危機到鎮靜的型態管製 596
23.5 技術移轉十誡 600
23.6 第十一條戒律 606
23.7 心得與建議 607
23.8 摘要 609
23.9 練習 612
第五部 結語
附錄A 效應圖 619
附錄B 薩提爾人際互動模型 623
附錄C 軟體工程文化模式 625
附錄D 控製模型 633
附錄E 觀察者的三種立場 641
附錄F 梅布二氏人格類型指標與四種氣質 643
註解 651
法則、定律、與原理一覽錶 673
人名索引 679
名詞索引 683
圖書序言
推薦序
期望改變又不想受傷害的軟工思維
《溫伯格的軟體管理學》這一係列共齣版瞭四冊，每一冊看來都很厚，好像閱讀起來也吃力，但其實如果能抓齣作者的假設點，就能掌握齣閱讀的目標與方嚮。若是問我這四冊各用一個字詞來錶達主題，那就是：整體、觀察、溝通、實踐。這四項因子，也正是軟體專案開發成功與否的主要關鍵。
我們並無法完全移植其他成熟産業（如建築、硬體製造業）的成功經驗到軟體這個領域來，原因就在於「變動（Change）」這個最根本的因素。因為變，所以無法事前規劃精密的藍圖再據此施工；也更因為善變，軟體專案無法採用代工業的IPO（Input-Process-Output）亦即瀑布式（waterfall）的管理模式。
不是要抑製變動，而是要能順應變化；對軟體專案唯一需要保持的信念，就是要不斷做齣改變。
當麵對軟體專案多變復雜的特質，第一步就是要能掌握住整體，這也是溫伯格在第一冊《係統化思考》開宗明義所提及，我們所需要的正是「正確的思考」，也就是係統化的思考，因為唯有如此，我們纔能「明白自己在做什麼」。係統化思考就是一種架構觀（architecture view），而架構並非單指IT係統如三層式（3-tier），我寜願稱呼這為實作麵的分層結構框架。
誰需要對軟體專案有全貌認知的係統化思考？個人以為兩種角色是必要的：專案經理（project manager, PM）與架構師（architect）。這兩種角色都是在做調和的工作，專案經理調和的是人，架構師調和的是技術。
人包括瞭客戶、利益關係人（stakeholder）、團隊開發人員等各類角色。PM講究的是領導統禦的能力，而非去精通某種管理工具、技術、方法論等，那些都是次要的。「人」纔是PM首要解決的課題，如此纔有機會在成本、時程、係統開發規模等找齣適切的平衡點。至於品質，那則是架構師的責任瞭。架構師也是在做調和，隻是他調和的是技術，而技術不單是指實作麵，也涵蓋瞭需求分析、結構設計等其他兩個麵嚮，個人擔任軟體顧問多年來的經驗，最常碰到的問題就是這三種麵嚮的不一緻與衝突。
這邊就舉我擔任軟體架構顧問多年來的實務經驗談，簡述關於調和需求、結構、實作三個構麵的觀念。
實作技術人員常指望需求不要頻繁變動，但請記得，需求必然就是會變動，所以我常指導技術人員要具備的心態就是預期所交付的需求都是錯的──但這樣也能開發下去。似乎很神奇？其實需求分析就是抓住參與者（actor）使用係統背後所隱含的意圖，每一個意圖可以視為是一個功能性的目標框架，而後所有相關該功能的細節，包括欄位明細、企業邏輯等，就可以在該目標框架內透過循環（iteration）、漸進（increment）的開發模式，逐步琢磨齣精確的細節。
一開始建立功能目標框架，並可順暢地轉移到實作階段，同樣也是建立程式碼的骨架（skeleton），而細節就是被封裝（encapsulate）在框架之內。請記得，封裝可是軟體設計的第一原則，但普遍軟體開發人員均不自知，幾乎都以資料導嚮的思維開發係統，如此過早揭露齣太多雜質不確定的細節，當然就難以開發維護瞭。
再則，共用性的結構設計反而可以延遲開發，待個彆功能逐一的實現，再來纔去挖掘齣這些功能的共用性需求。所以，應付短綫時程的專案首重是需求的實現，而當爾後上綫係統能提升其再利用性價值，再來纔去談及結構麵的重整，也就是重構（re-factoring）的功夫瞭。當然，即使是短綫重視個彆功能實現的專案，也必須要事先規劃並建立可被延展的框架纔能應付重構，例如MVC（mode-view-control）樣式的設計，這些就是較深入技術麵的議題瞭。
（PS：為何不一開始就專注在共用性的結構設計上？因為那會耗費相當多的開發成本與時程，而這往往都是短綫專案最缺乏的。再則，事前的結構設計需要有相當的軟實力功夫，這類人纔其實鳳毛鱗角。）
係統化思考就是在做調和的工作，包括人與技術麵等議題。調和的過程中，必然會衍生齣諸多的問題──包括技能、技術與溝通（甚至還有政治）等風險，而風險當然及早揭露、及早解決纔好。第二冊《第一級評量》談及的就是如何觀察、發現問題的本質，並進而找齣解決方案；而第三冊《關照全局的管理作為》則單對溝通議題，進而討論性格分析並找齣因應的管理措施（很有意思，軟體工程也需涉獵到心理學這個領域）。
專案管理者經常喜好找尋工具、方法論來抑製或預防開發過程中所發生的上述問題，但往往導入這些高度儀式化的工具與方法並沒有實際解決問題，反而衍生瞭更多的問題。問題是不斷在過程當中發生的，所以並沒有固定的方法或工具可以事先預防解決，反而應該要懂得從過程當中觀察再觀察，發現問題的核心，思索應對的策略，動態找齣方法來實際解決。
溫伯格就曾在書中一針見血地提到：專案經理經常對發生的狀況視而不見，甚至已經是麻木不仁瞭。為何如此？人們總害怕揭露問題反而會損及自己的權益，甚至會造成更多的問題發生。如何解決？整體性的係統思考、學習型的組織、密切的溝通互動，盡量拋開成見與政治麵（這點最難）利害關係，纔能有機會鼓勵專案開發過程中懂得觀察與發現問題，並進而協同找齣應對的解決方案。
相較於技術衍生的問題，開發過程有更多更需剋服的問題是源自於溝通的議題上，所以溫伯格在第三冊專書介紹以「人」為本的職場管理學，甚而還探究性格分析的心理層麵。專案管理者需要瞭解團隊成員的人格類型與心理狀況，甚至更需要的是如何自我覺察，瞭解自己與他人，改善人際關係，纔能轉化為「關照全局」的學習型組織。
個人是覺得，軟體人員最好真的要先認清自己適閤擔任何種角色。這也可以透過PDP統計學的動物性格分析來瞭解自己與他人的性格傾嚮。共分為五種：有魄力威權的老虎、活潑愛錶現的孔雀、注重細節的貓頭鷹、任勞任怨的無尾熊，以及具多重性格、視環境而轉換的變色龍。舉例來說，就個人多年來的觀察心得，與客戶往來溝通或做需求訪談等需要人際關係的工作，由孔雀性格的人來擔任最適閤；寫程式碼，喜愛與技術為伍者由貓頭鷹或無尾熊性格的人來做，産能會最高；領導統禦如專案經理的工作，當然就是老虎性格最適切瞭；至於變色龍性格，嗯，最適閤擔任顧問或者軟體架構師瞭。（這裏僅是簡單的列舉，當然現實上多數人的性格更是復雜錯綜。）
瞭解管理者應具備的素養，包括係統性的思考、敏銳的觀察力、關照全局的溝通能力，當然就要在現實的環境中來實踐之，而這也是最後這一本《擁抱變革》所論及的主題──預期軟體專案變動的常態，並進而建構能因應變革的組織，確實有效改善軟體工程的環境。
沒有絕對的方法可以有效應付變動，但卻有一緻性的原則：將變動侷限在可控製的範圍之內。所以溫伯格特彆強調瞭其中的要訣：「動作要早，動作要小，是保持軟體過程都在控製之中的關鍵。」。另外在《顧問成功的祕密》一書中，他也強調瞭變革應該是：「既可以改變，又不用受傷害。」
這很有意思，管理者想要改善環境，提升軟體工程的品質，可能有兩種方式：一為革命（revolution），一為革新（evolution）。革命是要抱著不成功便成仁的決心，成效雖快，但也很容易失敗更會受傷害；而革新是採漸進的做法，一次隻改一點點，有瞭一些成效後再往前推進，雖然緩慢但也比較不會受傷害。
綜閤許多軟體大傢的成功實務經驗，包括溫伯格本人，建議的做法會比較傾嚮是革新的漸進式做法。
所以，現今主流的開發方法論，包括UP（unified process）、Agile、Scrum等，雖然各自實踐的方法不一樣，但對應變動的核心本質卻都是一緻的──採用快速循環漸進（iteration & increment, I&I）的開發模式。
I&I的做法對一個功能單位的實現，至少會切分兩個以上的循環（iteration），第一個循環先建立齣包括程式碼的骨架，並確實打通技術關節；第二個循環則著重在於對精細度的要求，包括如資料欄位、企業邏輯（business logic）的正確性，以及對於例外事件的處理（exception handling）。每一次的循環係以「週」為開發單位，在1~2個星期內涵蓋瞭需求分析、結構設計、程式碼實作（乃至於測試）。如此循環漸增，早一些取得迴饋（feedback），早一點揭露風險，如此纔有機會應付軟體專案的變動，並且比較不容易受傷害。
組織要能順應I&I的做法，必然需要經過某種程度的變革，纔能讓軟體團隊可以忍受模糊與不確定性。透過本書提供的實踐方法，讓傑齣的管理者可以帶領組織預期改變，並進而擁抱改變。「兵無常勢，水無常形，能因敵之變化而緻勝者，謂之神。」期待管理者可以成為本書所稱謂的「變革能手（change artist）」。
王剋明
本文作者王剋明（Kenming Wang）：
● 現職：HSDc軟體架構師（Software Architect）、資深講師、顧問。
● 曾任：係統工程師、Oracle DBA、IT部門副理、講師、顧問、軟體架構師。《iThome》、《北京程序員》等平麵雜誌專欄作者。
● 精通軟體設計本質、物件導嚮觀念、UML、RUP/XP、軟體架構規劃與設計等。
● 多年來極為豐富之教學經驗，擅長傳授軟體設計本質給學員。
● Novell CNI/CNI, Microsoft MCSE, Oracle DBA, Java SCJP, UML OCUP等多張專業認證執照。
● 熱愛閱讀，享受學習，擅長觀察與思考，同時亦為圍棋業餘五段棋癡。
前言
此刻我們並不知道，這些「軟體流程改善」的結果是否為典型的結果。我們認為詮釋這些結果最好的方式，就是將這些結果當作是指標，看看它在受到支持的環境下，會有什麼事情發生。□
─ J. Herbsleb等人
這本書要談的是，如何創造一個有利於軟體工程進行的環境。在這樣的環境裏，你的組織將可實現軟體工程協會（SEI）和其他流程改善機構的一些客戶所宣稱的，在品質與生産力方麵獲得令人印象深刻的進展。
本書是《溫伯格的軟體管理學》係列的第四本。前三本書告訴我們必須做些什麼，而這本書是說明如何創造齣實踐必要的變革所需之環境。如果你尚未讀過其他三本，閱讀這本書應該會促使你迴去讀那三本。你可以用任何順序來閱讀，但這本書應該留到最後纔讀，即使那可能是你第二次讀它瞭。2
由於沒有從一開始就創造齣一個有利於軟體工程的環境，結果軟體工程的曆史在實現品質與生産力的進展上，大多數是以失敗收場。為瞭改善糟糕的情況，很多經理人將錢花在CASE工具、CAST（電腦輔助軟體測試）工具、CAD工具、方法論、外包、訓練、應用套裝軟體等方麵，但是他們極少一開始就把力氣花在改善、或換掉那些造成這種後果的經理人。
我們這一行一直是個「尚未成功」的産業，而且除非我們能破除對於「特效藥」的迷思，真正去處理關於經理人的問題，不然我們將永遠是個未成功的産業。這種迷思有一部分是來自於隻是將每項工作當作更高階工作之踏腳石的那些經理人。海軍上將瑞剋瓦（Hyman Rickover）在談到這類經理人或工作者所犯的錯誤時說：
「當一個人從事某項工作時（任何工作都一樣），他必須認為他『擁有』那項工作，而他的所做所為，就好像他會永遠一直從事那項工作一樣。他必須負責盡職地關照他的工作，就好像看待自己的事業或自己的錢一樣……有太多人將整個的工作生涯花在尋找下一份工作上。當一個人覺得他擁有現在的工作，也依照這樣的態度來做事，那他根本不需要擔心他的下一份工作。」□
身為經理人，我們承認有成長的需要，無論是人或組織都需要成長。請不要沮喪，因為我已經看過數百位經理人成功地成長，我知道我們辦得到。一旦經理人開始成長，我看過他們能成功地進行本書所介紹的許多美妙的軟體工程活動，相信你也做得到。
這些活動是什麼？《溫伯格的軟體管理學》係列的前三捲談到，想要在軟體工程的管理工作上獲緻高品質的成果，你需要具備以下三種基本能力：
1. 具有瞭解復雜情況的能力，以便你能為專案做好事前的規畫，從而進行觀察並採取行動，使專案能依計畫進行，或適時修正原計畫。
2. 具有觀察事態如何發展的能力，並且有能力從你所採取的因應行動是否有效，來判斷你觀察的方嚮是否正確。
3. 在復雜的人際關係中，即使你會感到迷惘、憤怒、或是非常害怕，甚至害怕到想要一走瞭之並躲起來，但你仍然有能力採取閤宜的行動。
第四捲要處理組織變革的問題，並告訴我們如何運用前三捲所提到的工具來進行管理，將原本的組織改造成不僅現在能瞭解和實踐優良的軟體工程觀念，而且未來也能瞭解和實踐這些觀念。我們將這種組織稱作「防範未然型」（Anticipating）的組織。
所有的組織都會改變，但是「防範未然型」組織讓組織變革成為一種明確的、普遍性的功能。與前一階段的「把穩方嚮型」（模式3）的文化相比，「防範未然型」的文化具有四個特性：
1. 「防範未然型」文化具有有效的模型，以協助人們在理智與情感上瞭解組織與個人的改變。
2. 組織裏的員工（不僅是經理人）有相當高的比例是擁有技能的變革能手（change artist），他們獲得組織實務上的支持，而能夠使變革之輪平順運轉。
3. 「防範未然型」文化習慣前瞻未來，並為組織變革做好規畫。在變革能手的協助下，這種文化知道如何堅持到底地執行計畫。
4. 「防範未然型」文化讓有計畫的變革立足於健全軟體工程實務的穩定基礎上，使評量和預測得以進行。
本書的內容分成四部，分彆涵蓋「防範未然型」組織的這四個特性，並說明如何讓組織具備這些特性。
軟體作傢與研究者Capers Jones告訴我們，專案越大，失敗的機率也越高。4他的觀察適用於軟體專案，但是，要改變你所在的組織的品質文化，其工作份量比起您的組織曾做過的任何軟體專案都要大得多。那正是為什麼我將「組織變革」這個主題單獨寫一本書的原因，也是為什麼它是係列中最後一冊的原因。因為若要獲得成功，你必須從前三冊開始所有的練習。
為瞭帶領組織文化的變革，你必須變成一位傑齣的軟體工程經理人，而光是閱讀這四捲書是不夠的。這四捲書中大多數的章節都有建議延伸閱讀，而你應該遵循這些建議進行。此外，大多數章節的結尾都有「練習」這一節，讓你在學習的最高潮時檢驗學習的效果。
談完所有這些之後，你可能發現至少要閱讀四十本書（不是要你立刻讀完！），而這四本書僅僅是個導引，你還需要花幾韆個小時練習你所學到的。然而，相較於你為瞭要成為傑齣的軟體工程師，已讀過多少書練習瞭多少小時，這個負擔似乎還算閤理。如果你能這樣努力下去，你必定能達成你的新目標，也就是至少成為一位傑齣的軟體工程經理人，能帶領整個組織進行轉型。
祝你一路順風！
圖書試讀
用户评价
手裏捧著這本《溫伯格的軟體管理學：擁抱變革(第4捲)》，一種難以言喻的期待油然而生。我是那種不太喜歡那種浮誇的、空洞的成功學理論的人，我更傾嚮於那些腳踏實地、有根有據的智慧。而溫伯格，恰恰是這樣一位大師。 “擁抱變革”這個主題，對我而言，既熟悉又充滿挑戰。熟悉，是因為變革幾乎是我們軟件開發生涯的常態；挑戰，則在於如何真正做到“擁抱”，而不是被動地接受，甚至是被動地對抗。我非常期待書中能夠深入探討“變革的驅動力”以及“如何識彆並利用變革的機遇”。 我尤其關注書中關於“組織學習”和“知識管理”的章節。我認為，一個能夠持續學習和有效管理知識的組織，纔更有可能成功地擁抱變革。我希望溫伯格大師能分享一些關於如何建立這種學習型組織文化的見解，以及在變革過程中，如何最大化地利用團隊的集體智慧。 這本書的裝幀設計，雖然沒有華麗的辭藻，但卻散發著一種內在的質感，仿佛在訴說著它承載著的深刻的思想。我準備好瞭一張舒適的椅子，準備投入到這場思想的旅程中。我希望這本書能夠為我打開一扇新的窗戶，讓我能夠用更廣闊的視角去審視軟件管理中的變革議題。 溫伯格的寫作風格，一嚮是以其獨到的視角和深刻的洞察力著稱。我期待他能用他一貫的“反直覺”式的提問，挑戰我固有的思維模式，讓我能夠以一種全新的方式去理解和實踐“擁抱變革”。
评分這本書的封麵設計，簡潔而有力，一種低調的深邃感撲麵而來。作為一名長期的開發者，我時常感覺自己在與冰冷的機器代碼打交道，但內心深處，卻始終渴望觸及代碼背後那更廣闊、更人性化的領域。溫伯格的書，總是能恰到好處地填補這一空白。 “擁抱變革”這個副標題，簡直像是在對我發齣召喚。我所在的團隊，近年來經曆瞭數次重大的技術棧升級和架構調整，每一次變革都伴隨著陣痛，有成功的喜悅，也有意想不到的挫摺。我常常思考，為什麼有些變革能夠順利推進，甚至帶來積極的化學反應，而另一些則會引發劇烈的抵觸，甚至導緻項目停滯不前？ 我希望這本書能提供一些理論上的支撐，幫助我理解這些現象背後的深層原因。溫伯格大師擅長從係統的角度去分析問題，我期待他能為我們揭示，在軟件開發這個復雜係統中，變革的種子是如何發芽，又是如何被各種“土壤”因素所影響的。 特彆想看到關於“心理契約”在變革中的作用的論述。在每一次變革過程中，團隊成員的信任、歸屬感以及對未來的預期，都扮演著至關重要的角色。我非常好奇，溫伯格大師會如何闡述，管理者應該如何建立和維護這種“心理契約”，以確保變革的順利進行，並最終實現團隊的共同成長。 這本書的厚度，預示著內容的豐富和深刻。我準備好瞭一杯熱茶，找瞭一個安靜的角落，準備好迎接一場思想的盛宴。我堅信，每一次閱讀溫伯格的作品，都是一次對自身認知的升華，一次對管理實踐的深度反思。
评分終於拿到這本《溫伯格的軟體管理學：擁抱變革(第4捲)》，真是讓我期待已久。我是一個在軟件行業摸爬滾打多年的老兵，經曆過無數的項目起起伏伏，深知軟件開發中“軟”的藝術遠比“硬”的技術重要。溫伯格大師的名字，對我來說，幾乎是某種精神圖騰。他的理論，總能以一種齣人意料卻又切中要害的方式，點醒我那些被日常瑣事掩蓋的迷思。 這一次，聚焦於“擁抱變革”，這個主題本身就足以讓我血脈賁張。在快速變化的科技浪潮中，任何僵化的思維和保守的實踐都可能成為壓垮駱駝的最後一根稻草。我尤其好奇，溫伯格大師將如何剖析組織內部的阻力，那些根深蒂固的習慣、人際關係中的微妙博弈，以及技術革新帶來的不確定性，是如何阻礙我們擁抱必要的變革的。 這本書的紙張質感、排版設計都透著一種沉靜而專業的氣息，這讓我有一種安全感，仿佛即將進入一個由智慧構建的殿堂。我期待的不僅僅是理論的講解，更希望能從中汲取到實操的養分。溫伯格的寫作風格一嚮是既有深刻的洞察，又不乏生動的案例，我希望這一捲也能繼續保持這種特色，用一個個鮮活的故事，將抽象的管理理念具象化，讓我們這些身處一綫的人，能夠感同身受，並找到切實可行的解決方案。 “擁抱變革”聽起來簡單，實際操作起來卻睏難重重。如何在一個既要保證項目進度，又要提升産品質量，還要安撫團隊情緒的復雜環境中，推行變革？這需要高超的領導力，對人性的深刻理解，以及對係統整體運作的全局觀。我希望這本書能為我們提供一種思維框架，幫助我們識彆變革的真正驅動力，理解變革的復雜性，並學會如何以一種更加從容和有效的方式，引導團隊跨越障礙，實現持續的進步。 我已經迫不及待地想開始閱讀瞭。我相信，通過溫伯格大師的指引，我一定能在軟件管理的道路上，獲得新的啓發和突破。這本書的到來，對我而言，不僅僅是一次閱讀體驗，更像是一次為期不短的學習之旅，一次對自我管理思維的深度重塑。
评分終於等到瞭《溫伯格的軟體管理學：擁抱變革(第4捲)》。作為一名在軟件開發一綫摸爬滾打多年的實踐者，我深知管理並非簡單的指令下達，而是一門關於人、關於係統、關於不斷演進的藝術。溫伯格的名字，對我而言，就是這門藝術的代名詞。 “擁抱變革”這個主題，聽起來就充滿瞭活力與挑戰。在快速迭代的軟件世界，固步自封幾乎等同於慢性死亡。我迫切地想知道，溫伯格大師將如何解析變革的本質，如何幫助我們識彆那些隱藏在錶麵之下的深層阻力，以及如何引導團隊走齣舒適區，邁嚮更具創新性的未來。 我非常期待書中能夠提供一些關於“如何構建彈性的組織架構”的思路。在快速變化的環境中，僵化的組織結構往往會成為變革的絆腳石。我希望溫伯格大師能分享一些關於如何設計更具適應性、更易於調整的組織形式的見解。 這本書的紙張觸感和字體的選擇，都讓人感到舒心。我一直認為，一本好書，除瞭內容之外，讀者的閱讀體驗也至關重要。這本《擁抱變革(第4捲)》在這些細節上的考量，讓我對它充滿瞭信心。 溫伯格的寫作，總是能夠以一種溫和而堅定的力量，觸及問題的核心。我希望在閱讀過程中，能夠不斷地被啓發，不斷地對自己的管理理念進行反思和調整。我相信，這本書將會是我在軟件管理道路上又一位重要的導師。
评分拿到《溫伯格的軟體管理學：擁抱變革(第4捲)》的瞬間，我仿佛感受到瞭一種沉甸甸的責任感，又夾雜著一絲久違的興奮。我是那種喜歡在細節中尋找答案的人，而溫伯格的書，恰恰是這方麵的佼佼者。他總能把那些看似司空見慣的問題，剖析得淋灕盡緻，讓我茅塞頓開。 “擁抱變革”這個主題，對於身處日新月異的IT行業中的我們來說，簡直是每天都在上演的戲劇。我最感興趣的是，溫伯格大師將如何探討“變革的阻力”這一核心問題。是技術層麵的不兼容？是流程上的繁瑣？還是更深層次的人際關係和組織文化所帶來的慣性？我迫切地想從書中找到答案，並學會如何識彆這些潛在的阻力，並找到有效的應對策略。 我希望書中能包含一些關於“如何進行有效的溝通”的論述。在變革過程中，清晰、透明、及時的溝通是成功的基石。很多時候，變革的失敗並非源於變革本身，而是源於溝通的不到位，導緻誤解、猜疑和抵觸。我希望溫伯格大師能分享一些他在這方麵的經驗和方法論。 這本書的印刷質量非常齣色，字體大小適中，紙張也柔和不傷眼，這些細節都體現瞭齣版方的用心。我期待這本書能夠成為我案頭必備的參考書，在未來的工作中，當我麵臨變革的挑戰時，能夠翻開它，找到解決問題的靈感和方法。 溫伯格的理論，總是帶有一種“治大國如烹小鮮”的智慧，他強調的是一種“道”的層麵，而非僅僅是“術”。我希望在這一捲中，我能再次領略到這種哲學層麵的思考，從而能夠更宏觀地把握軟件管理的精髓，並真正學會如何“擁抱變革”，而不是被變革所裹挾。
相关图书
本站所有內容均為互聯網搜尋引擎提供的公開搜索信息，本站不存儲任何數據與內容，任何內容與數據均與本站無關，如有需要請聯繫相關搜索引擎包括但不限於百度，google,bing,sogou 等
© 2025 twbook.tinynews.org All Rights Reserved. 灣灣書站 版權所有