功能等價

範例：更換物流系統

一個物流組織參與了一項計畫，要更換用於包裹接收、路線規劃和配送的舊軟體。作為計畫的一部分，他們同意由 IT 主導一項與業務利害關係人參與度相對較低的計畫。技術觀點是他們可以僅進行「功能同質性」，從而解決他們更換過時技術的迫切需求。作為此計畫的一部分，一項主要工作是更換接收客戶包裹的系統。我們在計畫的這部分接近尾聲時參與其中。

我們認為與業務利害關係人的參與度低對計畫構成風險，特別是因為我們透過另一個專案聽說業務對開發工作感到沮喪。作為計畫的一部分，我們與包括財務團隊在內的關鍵利害關係人交談。這時我們得知曾進行過一項檢討，指出只有相對少數的客戶對組織有利可圖。反過來，這表示只有少數的「包裹類型」有利可圖，許多包裹由於特殊處理需求而讓組織虧損。因此，業務有一項計畫要停止處理那些包裹。

結果發現，「功能同質性」專案中投入了大量的精力來處理那些包裹，也就是業務表示他們不再需要的包裹。業務希望在沒有這些困難的邊緣案例的情況下，流程和軟體會變得更簡單。在這個案例中，「功能同質性」導致大量時間和金錢花在處理業務不再需要的需求上，同時進一步損害 IT 在業務眼中的聲譽。

範例：電子商務組織重新建置平台

此組織曾享受一段快速成長的時期，但已數年未優先考量 IT 支出，這造成了立即更換目前解決方案中許多元素的迫切需求。例如，在某些時段，他們必須減緩銷售數量，以避免壓垮核心系統，這從商業觀點來看並非理想。

許多關鍵業務營運是由同一台大型主機處理，這台主機最初是在其電子商務營運的最早期委託製造的。顯然從此系統中萃取元素在技術上將會是一項挑戰。同時，由於企業領導人已見識過數個中斷的失敗專案，因此希望將對其員工的任何進一步中斷降至最低。另一個挑戰是，目前的流程和系統使得在使用較漸進的方法時，極難優先考量要移轉的產品線。簡而言之，要了解他們銷售哪些東西能賺錢，哪些東西不能賺錢非常困難，因此認為唯一選項就是一次性全部移轉。根據這些挑戰，認為複製他們現有的一切是最佳且風險最低的方法。

由於目前的業務流程在表面上都是一起在同一台大型主機中實作的，這表示任何「功能等價」替換的範圍本質上就是整個業務的所有主要活動和流程。他們展開一項工作，為替換系統記錄「範圍內」的現況流程，計畫將此用作供應商選擇流程的輸入。

很快地，有幾件事變得明朗。第一件事是，這真的必須涵蓋業務執行的幾乎每一項活動，每項記錄「現況」功能性的努力都會揭露更多需要納入以提供「功能等價」的事項。其次，由於歷史性的權宜措施、多年來不斷變動的需求以及許多未解決的錯誤，與舊系統合作的實際人員最不想要的就是同樣的東西。這幾乎總是讓他們的工作更困難，而且是錯誤和延遲的主要來源。最後，由於錯誤和權宜措施，很明顯有幾個關鍵流程實際上是在手動建立的試算表中「離線」執行。關鍵業務資料從大型主機中萃取，用於透過試算表執行業務流程，然後稍後將現在已修改的資料上傳回大型主機。

在這個階段，有些人認為「功能平價」變得過於冒險，範圍持續擴大。這是需求收集程序完成之前，而且該工作沒有明確的結束日期。我們的參與在這個階段停止，因為我們認為繼續「功能平價」風險太大，而且無法提供業務所需，更重要的是，由於缺乏關鍵業務指標，使得優先處理任何更多增量方法變得不可能。幾年後，他們仍在進行「現狀」需求程序，遠遠超過原始截止日期。

缺乏正確的指標和從業務角度優先考慮功能元素的能力，通常會迫使組織採用「功能平價」方法。在這種情況下，我們認為最初努力收集各種產品線周圍的關鍵業務指標可能會提出解決問題的方法。這是一個很好的說明，說明您如何在沒有正確的業務背景和參與的情況下做出正確的技術決策。

範例：成功更換財務計算服務

我們的團隊之一正在為一家大型金融組織工作。他們希望現代化執行複雜財務計算的現有服務。財務計算的規格是固定的，服務的介面類似，只需要更新技術，從 J2EE Session EJB 實作更新到最新（當時）版本的 Java 中的 SOAP Web 服務。

團隊在現有實作周圍建立了一個豐富的測試套件，並在設定、執行和斷言責任之間進行明確區分。

圖 1：tests_for_feature_parity

一旦測試就緒，就可以用最小的風險替換執行適配器，並建立一個新的實作，以符合與舊系統相同的可執行規格。