讀到以下新聞：伯明罕宣布實質破產：英國第二大城為何跌落赤字深淵，其中一個原因：伯明罕市議會裝設Oracle IT系統，原本期望以此簡化議會的財務和人力資源系統使用，最初預算是1,900萬英鎊，但安裝工程卻拖延3年，《BBC》報導2023年5月時還傳出消息，指出該系統的最終安裝成本可能高達1億英鎊。
想起台灣自身的著名案例：沒有杜英宗的南山人壽 面臨三大嚴峻挑戰，主因是花了 4.5 年 101億台幣導入的 SAP ERP 上線後造成資料錯亂。
我好奇的是這兩個慘案後的 IT 人員日常，因為南山人壽至今仍是台灣三大壽險之一，相信伯明罕市的財務與人事模組至今應該仍在運行，否則會有更大的新聞出來。IT 如何在混亂中仍能度日？人與系統混合而成的韌性讓我佩服，總在破洞處體現縫補的功力。
自己參與過幾次面臨傾頹之際的救亡圖存，而系統也都活下來了，總有 IT 人咬牙撐過後請辭或黯然離職，曾陪走過報業、造紙業、金融業或線上零售業…等，核心系統轉換時的艱鉅時光，由衷佩服為解問題打死不退，解了後越挫越勇，抑或是心力無以為繼的夥伴們。
值此想著
莫聽穿林打葉聲，何妨吟嘯且徐行。竹杖芒鞋輕勝馬，誰怕？一蓑煙雨任平生。
料峭春風吹酒醒，微冷，山頭斜照卻相迎。回首向來蕭瑟處，歸去，也無風雨也無晴。
幾日後…
Emma 問：這有解嗎？
我：很難，人對於複雜度的處理有限，尤其複雜度是動態交錯，時刻在變。
甲乙兩方的軟體專案，和開發軟體產品的專案有很大的不同。現今話語權非常大的軟體聲音都來自開發軟體產品的，微軟、Google、SAP、Oracle、Open Source 的專案…皆是。幾乎沒有承接甲方需求，拿前述公司產品完成專案的乙方公司的聲音。大眾用著 Office、Google Search、Windows、Android，仰望著軟體明星，傳頌著強大的英雄故事。
各種方法論，乃至於人月神話(參看前文的介紹)等經典都出自於做軟體產品的公司，自認原因如下：
1.需求定義：開發軟體者依其洞見，不管是全新應用，或集大成的抄襲者，都依自己的規劃與步調做，但甲乙兩方的專案開發者，往往有一直變動需求的甲方。特別是大專案，甲方的系統已經累積多年使用，有大規模的使用者變更了極細微處，沒有人知其全貌，往往一個關鍵細節就大規模重工。
當系統活得越久遠，越要敬畏。能活得久，顯其重要。其生命過程中，一定因為新需求而縫補、整合其他系統、納入與混用多種時期的 IT 流行，期間不同團隊以不同技術實作，沒有主架構也沒有依循規範，沒人說得清全貌，文件殘缺不全。明的介面，暗的服務，每天的交易，月季年的結算，有千絲萬縷的連結，只有在用到新系統對應功能的那一刻才發現無法滿足舊需求。
2.時間期程：開發軟體者依市場需求、經費，可以依最小可用進程規劃，但做專案的乙方往往面對甲方的心血來潮調時間期程。甲方的主導者是 user，面對的是產業競爭，不見得尊重專案開發，若時間期程與專案團隊不合，往往就是乙方拼命完成，留下一堆技術債。
3.技術規格：現今很流行排行技術規格，語言、Framework、OS…總喜歡有個評比排名，軟體開發者可擇其最適合者。但專案乙方要配合甲方的陳年技術，遵循獨特的規章準則，找尋各種整合周邊系統的 workaround，還有一大堆的髒資料，特別是歷史悠久的系統，因為三五年換接棒的開發商，導致每三五年有新的髒法。換句話說，擬定的規格是拼裝的，不一定有誰擅長，有可仿效的最佳做法，有適合的單一技術。
4.測試與驗證：產品的測試也是開發的一部分，參與測試者一樣有其目標與進程。專案的測試者，尤其是 UAT 的使用者，往往地位高於 IT，對於測試的配合度不高，而 UAT 與平測往往是加諸於正常工作外的加班，對於準備資料與驗資料大多是瑕疵不斷，但這誤導開發專案者，頻頻遭受 Bug 指謫後需辛苦證明資料本身的問題，然後看到使用者不在乎的樣子，招致雙重打擊
5.團隊意志與鬥志：產品開發者因其目標明確，開發過程中與做專案者一樣辛苦，但操之在己者多，較能調適，因進程較為清晰，也就比較有希望感。但做專案者面臨一再翻案的需求，這並非甲方故意，而是甲方往往也是做到才發現關鍵差異，就算再有誠意者願接受 Changing Requirement，受限經費與時間，仍會有兩方的劇烈摩擦。
甲方的專案團隊會有一堆非 IT 的部門組織，往往本位主義高。且甲方 IT 原是 Support 單位，在公司內只會花錢，地位與聲量都不高，每日的生活本就磨光了趣味。來自兩個公司文化的人組成團隊，各有利害又先天對立，要有高昂鬥志與持久意志，本就困難。
6.摩擦與組織變動：甲乙兩方的如質、如時、如預算先天存在著認知落差，且甲方往往還有花錢是大爺的心態。與產品開發者往往有技術明星如眾星拱月不同，專案甲方多有根本不認可乙方的專業，只拿學歷與年資品頭論足。產品開發者的公司組織變動可以預先調整產品開發進程，但甲方的組織變動卻會造成乙方的措手不及，一旦更換窗口與負責人，通常會大量否定先前的承諾。
現今有很多工具與方法論，不管是 DevOps、Scrum、PMP…對軟體專案開發都有其幫助，但麻煩在一群人對這些工具與方法論的共識。產品開發團隊較容易有共識，無法接受的走人即可。但甲乙雙方的專案，不可能沒有共識就叫甲方的 Key man 走。甲乙兩方都面臨歷史共業，在新舊技術與信念並存下，沒有純粹，只有四不像。
雖然專案不易做，但就自己的經驗，也很少全然失敗的，每次的專案都是讓整個企業 IT 建置更好一點，這次做不到的，再準備起個專案即是。
最後回到為何這些方法論和經典都只出自於做產品的，每個失敗的專案都有其失敗的原因，但可參考性不高，因為專案沒有一樣的，都有其特殊需求，人員技術落差與偏好、既有系統環境整合差異、不同的時間、質量、預算，不同的規範(操作與管理、安全、高可用性、容量、保存時限…)。寫成的是本血淚史，但讀者不能因此避免什麼。自己每天都這麼過著，只想看甜劇麻痺一會。
或許，除了技術與經驗，兩方人唯體諒與誠意可走過專案，就算結果黯然，但仍能存續等待下回。
偶有所得 