從公共建設的系統失常看系統開發的複雜性

談到系統開發，很多人都不反對它具有複雜性，至少不會認為它是很容易的一件事。然而，當聽到公共建設的系統失常的消息之後，人們似乎又會忘了系統開發存在的複雜性。我們經常會看到許多相關的評論，認為系統會發生錯誤是因為方法或是技術的問題，卻甚少探討有關系統開發的複雜性問題。

當然，系統發生錯誤的原因，也許真的很可能和方法或技術有關。但是否所謂的方法或是技術，就是一般對系統發生錯誤的評論中經常提到的方法或技術；不是開發者的技術觀念有問題，就是沒有遵照正確的流程及方法來做事？筆者覺得這樣的假設似乎把系統開發看的太容易了。

如果系統失敗的真相，真的是技術觀念、流程、或方法論的問題，那麼只要在系統開發過程中，加強這些因素就可以確保系統開發的成功。但從筆者系統開發的經驗顯示，這些因素雖然很重要，但它們並不是系統開發能得以成功的關鍵，而是要等到逐漸適應系統開發的複雜性之後，才能逐漸地改善增加系統成功的機會。

要認識系統開發的複雜性，這並不是一件很容易的事。不過，忽略它會讓我們和湊熱鬧的外行人一樣，從他人系統失敗的經驗中只能看得到表相；以為這只是犯了離譜的技術或方法論的錯誤。我們應該學習像內行人一樣，從系統失敗的教訓中看到成功的門道，了解到系統開發複雜性本質的真相；不天真地以為技術或方法論可以解決系統失敗，而是深入省思系統開發的複雜性。基於筆者過去對系統失常的觀察及體會，想以這篇文章從公共建設的系統失常看系統開發的複雜性。

從文湖線的系統品質談起

自從捷運文湖線通車之後，筆者就常聽到有人對它的系統品質提出批評的意見。筆者記得以前在上班的途中，在路上遇到同事就曾和他討論到捷運文湖線的系統品質。這位同事林君的看法是以工程技術觀點看待系統失敗的典型，雖然他的觀點並不能夠讓我們看到系統失敗的全貎，但對系統開發的複雜性本質，倒是不失為一個不錯的思考起點。

林君知道筆者平常上下班都是搭捷運文湖線，然後再轉乘公車接駁。當時他問筆者搭乘捷運文湖線的人潮，筆者回答和過去文湖線未通車前搭乘捷運新店線相比，文湖線的人潮似乎並沒有新店線的人那麼多，雖然不見得會有位置坐，但文湖線的擁擠程度確實比不上新店線。林技術長猜測也許是人們對文湖線沒有什麼信心，所以搭乘的人比較少。

林君長年在國外定居和工作，因此以歸國華人的身份看待捷運文湖線的系統品質，會認為人們對捷運文湖線的系統沒信心是很自然的。文湖線在開始營運之初，發生過很多次嚴重的當機事件，因而讓人們覺得系統的品質不佳，這的確是不爭的事實。不過文湖線現在的狀況，確實已經比剛上線的時候要穩定許多。

依據台北捷運公司所提供的資料，文湖線系統可用度與國際穩定度指標 MKBF 的兩項指標，可以客觀地證明，文湖線已是一條符合國際水準的捷運線。以筆者每天親身搭乘的實際體驗，我認為文湖線現在的狀況，其實並沒有像林君說得那麼糟糕。

筆者以過去參與的大型公共建設的系統開發經驗，讓我比較能夠理解文湖線剛開始上線的系統失常，直到後來才逐漸穩定的狀況。以筆者過去的系統開發經驗顯示，很多系統在剛開始上線的時候，總是會碰到一些偶然的意外，讓系統功能無法正常運作。直到專案團隊耗費足夠的時間與心力，找到系統異常的根本原因，才能針對問題對系統改善或調整使其趨於穩定。

因此筆者認為系統從剛開始上線到逐漸穩定，需要足夠的時間。剛開始是由於開發人員經驗不足，以致於不夠了解狀況而難以掌控系統以因應問題。等到開發人員從系統失敗中得到寶貴的經驗及教訓，並努力費心解決問題並改善系統，系統自然就會開始漸入佳境。很多系統並不像捷運文湖線或是高鐵售票系統那樣受到大家的注意，但其實每個系統在上線後，會出現問題的機率都是一樣的。

不過，林君倒是不這樣認為，而是認為由於開發者的觀念錯誤，才導致捷運文湖線的品質不良。以林君長期在國外開發系統的經驗，他很推崇老美做事的方法，按步就班地照著正確的方法來進行開發的工作，不求速成只求「把事情做正確」。反觀在台灣，他認為人人都是為了趕進度而求快速，經常省略了一些不應該省略的作業，為了節省時間，卻得到系統品質不穩定、甚至是系統失敗的代價。

品質就是沒有錯誤？

林君認為開發者為了讓捷運文湖線提早上線，沒有確實地把開發工作做正確，因而使系統品質變得不穩定而不斷發生系統異常的事故，所以應該歸咎於開發過程的觀念錯誤。林君的論點似乎是認為「品質就是沒有錯誤」，但這種觀念必須把系統開發的錯誤當成道德問題，否則它將會造成邏輯推論上的繆誤。

「品質就是沒有錯誤」會造成什麼邏輯推論上的繆誤呢？的確，當系統出現大量的錯誤時，毫無疑問地，不管系統功能如何，人們還是會因為品質缺失而認為它沒有價值可言。但反過來說，即使系統沒有發生任何的錯誤，我們也無法確認它的價值為何。曾昭屏譯（2006），《溫伯格的軟體管理學：第一卷（系統化思考）》，p.294，經濟新潮社

事實上，在追求系統不會出錯的完美之外，要讓系統有價值還需要對特定的人有用處。開發者致力於工程技術的完善，開發出不會發生任何錯誤的系統，即使盡到開發沒有瑕疵系統的道德責任，但這並不代表系統能夠為客戶或是使用者產生價值，而能夠贏得他們讚揚的肯定。

這是因為追求系統在工程技術的完美、和系統符合客戶及使用者在問題領域真正的需要，根本就是兩回事。就像系統開發者常會碰到幾種導出使用者需求的障礙。尤其對於大型規模或複雜的系統，客戶和使用者通常要等待較久的時間，才能接觸到實際的系統。經過長時間對環境所產生的變化，加上他們在想法上的蘊釀，讓系統在認知和實際上的差距變大，於是便出現「是的，但是…」症候群的現象。開發者照著客戶或使用者提出的需求來開發系統，但等到系統開發出來之後，他們反而表示「是的，系統功能看起來很酷，但是它不是我想要的功能」。

「是的，但是…」症候群顯示系統開發在導出使用者需求的一種常見障礙；由於系統在被開發出來之前的不可見和不可觸摸性，客戶和使用者在還沒看到和接觸系統之前，根本很難說清楚他們需要什麼，而且有時候連他們都不知道自己要什麼。

除此之外，系開開發在導出系統需求還有兩種常見的障礙，一種是在系統範圍內存在「未發現的廢墟」，當開發者愈深入認識系統，愈會發現很多原來沒有被發現的系統問題；另一種是開發者和客戶或使用者的語言不同，因為彼此背景、專業知識、技能、以及關注的焦點不同，使雙方在溝通上採用不同的方式，增加彼此誤解和衝突的機會。Dean Leffingwell & Don Widrig (2003), 《Managing Software Requirements: A Use Case Approach》, Second Edition, Addison Wesley Professional.

由上面幾種導出使用者需求的障礙，我們可以了解僅僅系統開發要把需求弄清楚，就是一項艱鉅的任務。很多時候系統發生錯誤，問題的關鍵並不是開發者開發的系統有錯誤，而是沒有開發客戶或使用者真正需要的系統。因為在具備規模和體制的系統開發專案中，系統不大可能在層層工程驗證和確認過程把關之下，還會發生沒有把事情做正確的繆誤。但倒是很有可能因為系統開發在各種因素交互作用下產生的複雜性，讓人無法在混亂和秩序之間適當地調適而讓情況失去控制。

系統開發的模糊地帶

從工程技術的觀點來看，系統開發應該需要客觀及明確，其中不應該有模稜兩可和高度的不確定因素存在。但實際上在系統開發的過程中，卻讓我們發現要開發被嚴謹定義的系統，處處出現無法具體而明確清楚定義的難題。系統開發顯然存在模糊地帶，只是假設它不存在，更加容易讓人忽略系統的複雜性，而在系統出現混亂的時候無所適從。

系統開發為什麼會存在模糊地帶呢？理論上，只要能夠發展出足夠具體的需求規格，系統應該就不存在任何的模糊地帶才是。然而，即使沒有前面提到導出使用者需求的三大障礙，人也沒辦法藉由發展嚴密的系統規格，讓系統開發過程的模糊地帶因此而消失。

因為雖然定義具體的規格可以用來規範系統的一致性，減少系統發生模稜兩可情況發生的機會，然而，規格所規範的一致性愈高，也就代表系統的完備性愈容易受到限制；在系統規格沒有錯誤的情況下，不可能不出現任何邏輯上的矛盾。

歌德不完備定理已經證明在理性的世界中，沒有任何的公理系統可以表現它的正確性，而在它所涵蓋的範圍中不發生任何的矛盾。只要公理系統所涵蓋的範圍足夠廣大，可以蘊含自然數所定義的成員，那就必然可以找到沒辦法證明也不能夠證否的命題。此外，也沒有任何的公理系統可以證明自己的正確性。

從歌德不完備定理可以讓我們理解系統開發的模糊地帶是必然存在的。對系統運作可能會碰到各種問題，如果開發者對問題領域沒有足夠的經驗，藉由數理公式及邏輯推演，沒有人可以定義出沒有模糊地帶的完備具體系統規格。當規格具有相當的涵蓋範圍，就代表系統存在更多的模糊空間，不然就代表了規格一定存在邏輯上的矛盾。

歌德不完備定理並不是說沒有系統的規格是完備的，而是指只要規格的涵蓋範圍夠廣，就沒辦法透過計算或是推論來證明它的完備性，否則將會以破壞規格的一致性作為代價。當然對於系統運作將來會面臨的某些情境，開發者可以增加規格的細節來擴大規格的完備性，但通常這樣做會影響到系統其它部分的功能，於是還是無法提昇規格整體的完備性，或是因此喪失規格的一致性。

因此，系統開發的模糊地帶是因為人們經驗的侷限，它們讓我們不可能用規格的正確無誤來證明系統對人的用處，也就無法確保系統的價值為何。因為單單要定義什麼是「完全正確無誤」就是個大問題，很多時候人不是不知道應該把事情做對，而是缺乏可以減少或避免犯錯的經驗。

一般而言，系統開發的錯誤包括缺少兩種典型的經驗；第一種錯誤是缺乏問題領域的經驗，使人沒辦法在規格中清楚定義系統，因為不清楚系統未來將面對的情境，沒辦法問正確的問題以做正確的事、第二種經驗則是缺乏工程技術的經驗，使人不了解系統可以採用的技術及方法，沒辦法回答正確的解答來把事情做正確。

工程技術的對策

在工程實務上，面對系統開發的模糊地帶，開發者並非無技可施。要避免沒有問對問題和沒有提供正確解答的缺失，開發者可以透過驗證（Validation）流程來做正確的事情，然後再運用確認（Verification）流程把事情做正確。這是面對系統開發的模糊地帶，工程技術所提供的對策，只是運用工程實務的驗證和確認流程，是否真能有效降低或避免系統開發的模糊空間？

從筆者實際參與系統開發的經驗來看，在系統開發過程中，開發者經常花費很多的心力在系統的驗證和確認上，但實際上它們對降低或避免系統開發的模糊地帶其實非常有限。主要的原因並非開發者的能力或是他們的使用的流程或方法不對，而是開發者終究會發現他們沒辦法完全忽略、或是排除工程技術以外有關人的因素。

筆者再舉另一個著名公共建設發生系統失常的例子。就像在幾年前，通過 CMMI ML3 的神通電腦開發高鐵售票系統，被人們詬病像登機的售票系統是忽視真正的使用者需求。以通過 CMMI ML3 的公司水準來看，人們很難能夠接受他們會開發出這樣的系統，不敢相信他們具有相當的軟體開發能力成熟度。

CMMI 工程領域中的驗證過程，它的目的是為了證實未來的系統，在預期中的環境中運作可以滿足預期的使用者需求，因此如果系統沒有滿足實際使用者真正的需求，很可能是因為開發者並沒有做好需求的驗證，並且以「用廣泛的方式驗證需求」來發展需求。

然而，高鐵售票系統沒有辦法滿足使用者真實需求，原因不盡然是需求驗證的問題。相信有參與過大型軟體系統開發專案經驗的人都會非常清楚，在開發過程中，開發者能夠主導需求方向的能力是很有限的。面對系統的真實情況，開發者並不如其他的利害關係人更能了解需求，可能很難分辨什麼樣的系統擺在預計的環境，才能滿足使用者需求。

當然，開發者可以用各種方法來探索各個候選的系統解決方案，然後運用各種廣泛的方式來確認需求；諸如用展示、雛型、模擬、或概念驗證等技術來驗證使用者需求。然而，除了筆者在前面提到的三大導出使用者需求的三大障礙之外，系統開發還會常碰到其它原因，讓「用廣泛的方式確認需求」也不能獲得使用者的真實需求。

例如負責需求確認的人員，並不是實際操作系統的使用者。他們可能會誤解使用者的需求、或是因為利害關係而忽略使用者的需要，等到系統開發完成後，系統使用者才發現系統不符合他們的需求。

上面的情況在大型的系統開發專案中很常見，開發者經常會碰到提出需求和使用系統並非同一個人的困擾。跟開發者談需求和確認需求的是資訊部門，當開發者把系統開發出來之後，交付使用單位操作以後，使用者卻又表示系統並不符合他們的需求。

為什麼客戶不讓開發者面對使用者直接溝通需求，而要透過資訊部門的中間人的角色？這個問題其實很複雜，很多時候客戶很難找到確切的使用者來讓開發者訪談需求。即使排除像高鐵售票系統的使用者是一般的民眾的狀況，其它企業內部的系統的使用單位，很經常會橫跨多個部門，要找到所有的利害關係人一齊開會，其實是非常不容易的。

其實還有更主要的原因是客戶在策略觀點、和使用者作業觀點的不同調。客戶的決策高層可能不只是希望系統將現行作業自動化提昇效率，他更希望系統能夠運用資訊科技的優勢來改進作業流程，並改變使用者習慣來創造效益。所以並不希望開發者對系統需求的認知，被使用者的作業習慣框住。客戶端高層對系統的看法，經常會與實際操作系統的使用者的需求南轅北轍，很難能夠從當中找到讓每個人都滿意的系統需求，而只能從當中做出某種程度的取捨。

雖然系統開發在驗證和確認流程並不是對人而是應該針對事，可是忽略人的因素就很難能夠得到執行它們應有的成效。記得筆者曾經經歷過系統經過客戶的 Power User 測試需求的系統，最後在系統驗收之前，卻還是被客戶要求變更需求。這對開發者也許是難以理解並接受的情境，但其實這正是系統開發複雜性本質的展現。即使對企業需求更了解的資深使用者也很難發現自己提出的需求是有問題的，更何況有時候需求的變化是來自人力所不能抗力的環境因素所造成的，開發者很難能夠對他們來多加以責難。

社會技術的關鍵因素

因此，從上面工程技術經常碰到的困難我們可以清楚知道，系統開發即使透過嚴謹的工程技術，也不可能忽略人的因素，因為即使工程技術沒有出現錯誤，也不能證明它是對人有用處而展現價值。這正說明了系統開發的複雜性並不是單獨以工程技術的觀點就可以理解，而是更需要正視有關於社會技術的觀點。

社會技術觀點和工程技術觀點最顯著的差異，正是前者並不如後者的客觀，這也代表是非對錯沒有固定不變的標準，常常同一件事在不同的專案或基於人的不同立場而會有不同的結論。其實系統開發的複雜性正是因為無法限定在單一的觀點，而是必須考量各種不同面向的多重觀點。

因此，系統開發需要考量多重觀點，要先從取捨系統需求出發，這代表系統開發者必須做好利害關係人管理，它對系統的成敗具有積極的決定因素。利害關係人管理需要識別出專案的利害關係人，然後挖掘、管理、以及影響他們的需要及期望。專案的利害關係人包括主動參與專案的人員、或是他們所感興趣的事情，會對專案的產出或成敗有影響的個人或組織。

系統開發應該要儘可能地滿足每一位利害關係人的期望和需要，然而，一旦利害關係人之間，彼此意見衝突而且無法協調共識時，那系統就必須要以滿足專案的客戶為主。也就是說要把客戶當成是關鍵的利害關係人，為了滿足他的需要和期望，其他人的需要及期望都可以被放棄。

然而，有些時候系統開發者眼前直接面對的客戶、或是專案的贊助者，他們的意見不見得會讓系統變得更有用處，而且經常還會讓系統變得更不容易使用，反而讓人們沒辦法接受系統。因此，在這種情況下，可能會促使開發者認為應該思考使用者實際的需要，因為可能他們才是最重要的利害關係人，而不以滿足客戶或專案的贊助者的需要和期望為目標。

不過，這種想法的問題是開發者通常沒有能力判斷誰的期望和需要比較重要。當然使用者是直接使用系統的人，他們的期望和需要或許應該優先考慮。但客戶和專案贊助者是真正出錢的人，當他們和使用者的意見不一致、甚至是發生衝突的時候，考量現實的因素，開發者真的很難為了符合使用者的期望和需要，而違逆客戶或專案贊助者的要求。

其實開發者運用他所熟悉的工程技術，通常是不能分辨誰才是真的利害關係人，因為對於客戶所關心的問題領域，有太多他不清楚的事情。有時候，開發者基於工程技術感覺應該是對的事情，往往最後才會發現它可能是錯的。當然，其它像客戶、或專案管理的單方向觀點，可能會受到對解決方案領域的認識有限，也沒辦法分辨誰才是真的利害關係人。當我們聽到有人主張「客戶永遠是對的，所以你應該照我說的這樣做」就會知道這絕對不是真理而是偏見，忽略了系統開發的複雜性來自多重面向。

在混亂中找秩序

既然系統開發的複雜性不能忽略多重面向，那麼我們就不可能在問題領域和解決方案領域之間選擇一邊來強調系統開發的核心思想是什麼，而是應該在各種不同面向觀點的交界之處，去找到適應系統開發複雜性的關鍵所在。換句話說，系統開發必須調合各種陰陽面，從未知和已知之間、混亂和秩序之間、結構和非結構之間，去尋找可以融合各種觀點的最大可能性。

要調合系統開發的各種陰陽面，以融合各種觀點最大的可能性，依複雜適應性系統（complex Adaptive System）的觀念來說，停留在會發生自我組織的混沌邊緣以適應變化，可以從三個方向著手。首先必須要把廣大而無所不包的可能性，限制在一小部分、其次是必須保持允許輕微改變的穩定性、最後是必須要在靜止不動的死寂和過度活動的混亂之間維持平衡。

這三個方向讓我們看到了適應系統開發複雜性的三大重點，那就是系統必須是可測試的、擁有允許改變的彈性、以及必須能夠持續的整合以維持動態的平衡。測試是為了知道系統的邊界在那裡、彈性是為了容納更多需要的變化、整合則是讓演進系統的火光能夠迸現。

於是，面對環境變化的無常，開發者需要自我組織來演化出適應複雜性的能力。筆者認為這種能力才是系統開發品質的關鍵，以工程技術和社會技術之間的調適，來尋求不同領域觀念之間的融合。這樣就能夠使系統在變化的環境中，能夠保持穩定的動態平衡。

就好像《太極拳論》提到「偏沉則隨，雙重則滯」的觀念一樣。工程技術重視規律和秩序，而社會技術則強調適應變化和彈性，兩者各有所長而無法偏廢。在開發過程採用（adopt）、調適（adapt）、並熟練（adept）不同著重點的轉移，是讓人學習在混亂中找秩序的法門與修煉。當然筆者承認這實際做起來真的不大容易，但至少它不會讓人用簡化的思維來看待系統開發。

後記

這篇文章本來是準備投稿 ZDNet Taiwan 的文章，從去年八月和同事的對話引發同人的寫作動機開始，到最近才把整篇文章完成，歷經了將近一年的時間。在寫作過程中，文章經過無數次的修改，希望能夠寫出不同以往談論系統開發複雜性的文章，沒有深澀的術語、也能用非技術專業的觀點來看到我對複雜適應性系統的領會。

這正是同人想突顯和另一篇有關系統開發複雜性的文章〈軟體開發是工藝還是工程〉最大的不同，也算是對我最近兩年在系統開發所行、所思、所得，做一個比較全面的整體論述。系統開發真的需的有效的方法，但沒有任何一套方法可以忽略人的因素而能夠正確無誤地運作。

很多時候，讓人們沒辦法流程把事情做好的原因其實很簡單，但人的情緒卻通常把它變得很複雜。尤其是高階主管的情緒，不去觀察現象來瞭解執行和計劃的落差，以調整計劃來做正確的事情，卻以批評與責難來反應自己的情緒，這正是顯示高階主管在系統開發管理的無能為力。這種無能代表他們除了只會讓人「聽命辦事」之外，其它對管理其實是一無所悉。儘管他們能夠一直用口號來「教育」員工，並藉此檢查工作者的工作態度對不對，但他們的管理能力只能讓他們「簡化」系統開發的複雜性。

這篇文章比〈軟體開發是工藝還是工程〉更擴展它的詮釋領域，系統開發不應該只限制在軟體開發上。雖然軟體的抽象性會增加系統開發的困難度，但系統開發複雜性的本質所在，在於技術和業務觀點相互撞擊而產生各種變化，它不只是存在於軟體開發的系統中，對其它非軟體的系統開發也是相同的狀況。

同人並不想讓這篇淪為整理過去文章的新瓶舊酒，而是以這兩年系統開發實務得到的經驗，融合複雜適應性系統的觀念，內化成系統開發調適變化與紀律的動態平衡之道。雖然這篇文章也許寫了太久，以致於錯過了投稿 ZDNet Taiwan 專欄的時機，但發表在網誌也算是對自己有交待和對喜歡《同人的生活派對》軟體開發和專案管理文章讀者的回饋。讀者的支持是作者寫作最大的動力，不管是在網路專欄或是個人網誌，同人將會持續寫作來分享我在軟體開發和專案管理領域所體會的點點滴滴。