讀到以下新聞:伯明罕宣布實質破產:英國第二大城為何跌落赤字深淵,其中一個原因:伯明罕市議會裝設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 建置更好一點,這次做不到的,再準備起個專案即是。
最後回到為何這些方法論和經典都只出自於做產品的,每個失敗的專案都有其失敗的原因,但可參考性不高,因為專案沒有一樣的,都有其特殊需求,人員技術落差與偏好、既有系統環境整合差異、不同的時間、質量、預算,不同的規範(操作與管理、安全、高可用性、容量、保存時限…)。寫成的是本血淚史,但讀者不能因此避免什麼。自己每天都這麼過著,只想看甜劇麻痺一會。
或許,除了技術與經驗,兩方人唯體諒與誠意可走過專案,就算結果黯然,但仍能存續等待下回。