改善設計的建議：我們該怎麼做？
1. 管理（辨識、定義並排序）需求
產業整體並不擅長辨識、定義與排序需求。人們喜歡解決問題，也樂於提出解法……（以下內容續於下一頁）
我們往往急著提出解決方案，但事實上，專案流程中也許最重要的一個環節是需求的定義——也就是當你在把「客戶的聲音」翻譯成「工程師的語言」時。
客戶通常是以「他們需要的東西是什麼」來描述需求，而不是以「那個東西能為他們帶來什麼效用」來表達。當他們說：「我需要一棟新的辦公大樓給我的公司」，他們真正的意思其實是：「我需要一個能容納我員工的結構。」
這有點像有人說：「我需要減肥」——他真正的意思其實是「我想變得更健康」或「我想看起來更好」。因此，負責需求定義的人有責任去理解為什麼需要這件事，因為那裡面才真正蘊含價值。
正如 Peter Drucker 所說：「客戶購買並認為有價值的，從來不是產品本身，而是效用——也就是產品或服務為他帶來了什麼。」
我記得有一個專案，一家飲料公司作為某設計—建造公司的潛在客戶，想要擴建他們的釀造廠，因為他們希望提升產能。受聘來評估專案需求的生產工程師最後得出的結論是：這家公司其實不需要擴建廠房；他們真正需要的是優化既有釀造廠內的生產方式。
這家設計—建造公司因此失去了這個專案，但他們卻因此獲得了一位終身客戶，因為他們沒有去建造一個根本不需要的東西。
我曾聽一位建築師說過：「我們必須突破極限，重新定義邊界。」這聽起來或許很令人振奮，但它同時也伴隨著成本與風險。對於大多數專案而言，更好的做法是「描繪設計空間」，或者簡單來說，根據各種需求來界定可接受的選項範圍。
需求大致可分為三種類型：
物理層面（Physical）：
即使是最具遠見的思想，也無法違背物理現實的法則（例如：「你想蓋一棟二十層樓的結構，但如果你再多蓋十層，它就會倒塌。」）。
利害關係人（Stakeholder）：
任何專案中都有眾多利害關係人，從規劃與建設階段需要取得核准的政府機關、環境影響評估單位、建築法規、放款機構（各自都有條件）、保險公司（有各種限制條款）、地方社區、客戶、供應商等等。
商業層面（Business）：
顯而易見，專案中有各方希望獲利，並需要建構資產來實現。經濟因素，包括建造成本、營運成本與收入，都是關鍵的商業需求。
與一般認知相反，商業需求往往是彈性最大的部分，儘管多數公司會把它們放在優先順序的最前面。大多數企業的運作假設是：商業需求最重要；但事實上，利害關係人需求（更不用說不可撼動的物理定律）才是優先順序更高的因素。而且，這三種類型的需求往往彼此衝突。
為了降低風險，大型企業往往不惜代價導入「階段關卡（stage gate）」的專案流程。這些流程包含預先設定的決策節點（通常伴隨簡報、會議等），用來決定專案是否進入下一階段、停留在目前階段進行進一步分析、暫停，甚至終止。
實務上並不罕見：最終投資決策往往是在專案投入已遠超過「是否繼續」所需資訊之後才做出。每一個階段關卡，都要求你滿足某些條件，或做出是否前進的決策。
之所以會如此，是因為規劃機關與環境主管機構的要求，加上希望在早期就充分理解……（以下內容續於下一頁）
專案在財務上的可行性，驅動了必須在遠早於實際建造資產之前，就完成大量工作的需求。
業主不希望在「階段關卡（stage gate）」流程下走得太遠或投入得太深，因為那意味著可能浪費金錢。換言之，他們希望避免在前期投入大量資源，最後卻不得不整個專案喊停。但利害關係人的要求——例如環境影響評估，或地方都市計畫委員會的限制——可能需要投入大量設計與規劃工作，結果反而讓業主偏離了他們原本偏好的階段關卡流程。我們把這種情況稱為「有點懷孕了」（being a little bit pregnant）。
舉例來說，我曾提到過一個政府機關及其對於醫院建設的相關法規。為了取得核准，你的技術文件必須細緻到一個程度，使得以競標為基礎的傳統專案交付方式變得不可行，因為設計必須非常完整，而這又代表專業分包商必須在比以往更早的階段就被納入流程。要為一個在政府健康監管機構那「全知、全視之眼」中尚只是個模糊概念的專案，取得承包商的參與，更不用說承諾，是非常困難的。但這些政府機關並不在乎你的階段關卡流程；他們有自己必須遵循的職責與關注重點。
換句話說，階段關卡在實務上之所以行不通，是因為它忽略了利害關係人。這只是另一種由迷戀官僚制度的人所創造的專案管理形式，卻忽視了環境保護機構、都市計畫委員會等在真實世界中的實際需求。
2. 限縮設計空間（Constrain the Design Space）
退一步想一想：這一切究竟意味著什麼？
與其等到之後才來學這些，不如現在就把所有東西攤在桌面上，看看我們能做什麼、不能做什麼。與其一味突破極限來定義邊界，不如先去理解規劃與審查的要求，理解商業面的需求，理解建築法規的要求，理解市場上正在發生的事情。讓我們把這一切整合起來，進一步明確這些需求，然後加以排序。如此一來，我們的決策雖然不會像以前那樣廣泛，但會是我們可以真正落實、可以在其上持續建構的決策。
因此，與其由那種不斷突破邊界、定義極限的建築師說：「都市計畫委員會說我們只能蓋十層樓，但我們來挑戰二十層吧」，他更應該說的是：「我們實際上是要做到十層，那就以十層為設計目標，但也許我們能往下減四層，最後做成十四層。」這些需求必須被理解，而不是被草率地擱置。
在更細部的層級上，詳細工程（detailed engineering）能夠從既有的零組件與材料規格資料庫中獲益，並搭配與公差、零件使用等相關的政策，來限制那些不符合需求的項目所造成的不必要探索。
3. 及早納入專業人員以促進並行作業（Involve Specialists Early to Enable Concurrency）
沒有任何理由不在設計初期就讓專業分包商參與討論，就像汽車產業所做的那樣。他們帶來的是他人所沒有的、與詳細生產工程相關的寶貴知識。特別是，專業分包商所參與的專案數量，往往比設計顧問公司與建造管理公司還多，因此他們擁有更多第一線的實務經驗……（內容於下一頁續接）
這正是第一線（trench-level）的洞見。事實上，將「規劃」與「執行」分離，本身就意味著必須及早讓專業人員參與其中。
這件事說起來容易，做起來卻很困難，挑戰主要有兩個層面：（1）業主與建造管理公司急於知道設計的成本；而（2）專業分包商則在長期的制度環境下被訓練成「報價者」，因此當你邀請他們上桌時，他們只會說：「告訴我你要什麼，我就給你一個價格。」他們其實不知道該如何在這種情境下進行協作，因為他們從來沒有這樣的機會。這會在業主、設計團隊，甚至建造管理（CM）團隊之間造成緊張關係，因為 CM 團隊也非常害怕拿不到「最好的價格」。
但你對投資最好的運用方式，其實是去運用他們的專業知識，找出「把事情做到最好的方法」——畢竟，真正每天在做這些事情的就是他們。而且，這件事應該在一個清楚定義並被充分理解的「目標價值（target value）」框架下進行，其中包含總成本；並且要在設計初期就進行，因為在那個階段，詳細工程與生產工程才能真正影響與產品設計相關的決策，包括如何最佳地製造、交付、安裝、維護那些用來建造與營運資產所需的系統與零組件。
4. 以「系統」為基礎來組織（而非以「專業分工」）
不要再以專業別來組織團隊，而是以系統來組織。舉例來說，可以成立一個「基礎系統團隊」，其中包含所有與基礎工程相關的專業人員（土壤工程師、混凝土承包商、鋼構承包商等）。
「施工方法（means and methods）」的議題，導致產品設計與流程設計被分離。建築師與工程師位於組織階層的一側，而建造管理者與專業分包商則位於另一側。企業往往投入極大的心力，試圖整合並建立高績效團隊，但這些團隊仍然是依照專案組織架構，以及每一位成員何時加入團隊而被切割開來的。
以下是一個英國某公司於 2004 年建成的新總部專案所採用的組織架構。其理念是依「系統」來組成團隊，讓每個團隊都具備完成其系統所需的所有角色，涵蓋設計、工程、製造、物流、施工、試運轉與營運。
（圖示文字直譯重點）
-
利害關係人／總部管理系統
-
ProjectFlow 管理系統
-
結構團隊
-
外裝團隊
-
機電服務（M&E）團隊
-
室內裝修（Fit-Out）團隊
-
垂直動線團隊
-
引導／決策團隊
-
共置專案團隊（Co-Located Project Team）
-
World Wide Web（全球網路）
目前也有一股趨勢，嘗試將所有人共置於同一個空間中——也就是所謂的「大房間（Big Room）」協作。但共置是否有效，取決於設計流程中的工作流與進程；有時你可能會讓一些人坐在那裡卻暫時沒有事情可做（請回想本書前面提到的「以資源為基礎的排程」）。這正是共置的取捨之處：產能使用率與其所帶來的價值之間的權衡。
當然，近年 COVID-19 疫情期間，也讓大家學會了以遠端方式工作的全新模式。
5. 繪製並控制流程（Map and Control the Process）
專案具有高度獨特性。其成果是一個客製化產品，通常由一個為該專案特別組成的團隊所完成，而團隊成員代表了不同的組織與單位。然而，設計執行的實際流程往往並未被清楚理解。人們很少花時間去描繪設計流程本身（也就是：「哪些事情需要發生，以及如何發生」）。
現場其實有大量的「正在做的事情」。結構工程師知道該做什麼；機械工程師知道該做什麼；地質工程師知道該做什麼；每個人都知道自己該做什麼。他們具備專業知識、技能，以及電腦系統來完成工作。但整體工作流程的整合，卻從未在全局層次被理解。因此，我們必須將設計流程的工作流描繪出來，讓所有參與者都能理解整體的工作流，進而加以控制。
我們也需要聚焦在那些必須「解耦（decouple）」的地方。
有時候，不同角色之間會陷入一種僵局，彷彿老西部電影中的對決場景：兩名槍手在黃昏時分的荒漠小鎮對峙——只是這一次，沒有人想先拔槍。設計並非線性流程，而是反覆迭代的。管理這樣的流程至關重要，而理解「誰先動、如何先動」同樣關鍵。
我們實際觀察到的情況，往往是要嘛完全沒有控制手段，要嘛嘗試用長條圖，甚至是 CPM（關鍵路徑法）來管理設計。
在過去幾年中，用於釐清並協議設計工作流的各種方法與工具，確實被愈來愈多地採用。但這些工具仍然無法解決 Fondahl 所指出的關鍵問題：資源會影響完成工作的時間。即使工作流本身很重要，我們也不能忽略有效管理「產能（capacity）」與「在製品（WIP）」的重要性。WIP 尤其關鍵，因為我們希望避免因過早做出決策，或在缺乏適當資訊的情況下做決策，而導致重工。
那麼，敏捷軟體開發（Agile Software Development）呢？
基於其在 IT 部門中所展現的成功案例，企業高層開始尋求在公司內部更廣泛地應用敏捷方法。具體而言，就是將敏捷軟體開發方法引入資本性資產（capital assets）的設計中。
這是一個相當有趣的發展。首先，我們必須認知到，敏捷流程（如反覆迭代、短衝、Scrum、站立會議等）以及以團隊為基礎的組織架構，其實早在 1900 年代初期就已經被建造業所使用。同時，我們也必須承認，軟體開發專案與資本性專案在本質上是截然不同的。
實體資產的建造需要一個高度複雜的供應網絡，其中包含大量「依訂單設計製造（engineered-to-order）」的零組件。這類工作同時具有技術性與實體性。此外，外部利害關係人（例如專業與商業執照機構、工會）對於「誰可以做哪些工作」具有相當大的影響力；而在軟體開發中，這種情況大多不存在。
監管要求往往導致大型批次或瀑布式的專案交付模式。即使自我設置的治理流程會帶來某些非預期後果，但在可預見的未來，建造業仍無法放棄瀑布式模型。與軟體開發或其他產品開發工作不同，建造專案必須納入大量的法規核准程序。
這些法規核准與其相關的文件申報，包括環境影響評估、規劃主管機關或委員會的核准、建築許可，以及使用執照等，只是其中幾個例子。監管機關要求特定流程必須被遵循，且在每一項核准中必須提供特定資訊。此外，政府機關與其他公共部門通常也要求透過公開競標或招標程序，來選擇工程顧問與建造承包商。
為了促進這個流程，必須彙整並發佈給投標者清楚的指示，或完整的投標文件（bid packages）。
在大多數情況下，這些法規要求並不適用於軟體開發。不過，與所有事物一樣，未來某個時間點，政府也可能選擇對軟體開發進行監管。其中，隱私與資安很可能會成為兩個主要的關注焦點。那麼，這樣的監管將如何實施？又會對軟體開發流程帶來哪些挑戰？如果真的發生這種情況，也許軟體開發反而需要向建造業尋找解方。
建造活動與實體世界密不可分。因此，化學、物理，以及相關的工程與材料科學領域都適用於建造。基礎必須在結構豎立之前完成；混凝土也必須養護完成後，才能達到其結構完整性。
建造的物理法則對產品設計、設計流程，以及與產能、庫存與變異性相關的決策，設定了明確的限制條件。改變工作的執行順序必然需要取捨。例如，若將基礎工程與上部結構解耦，使得基礎設計不會延誤其餘設計工作，則可以透過對基礎進行「過度設計」（承受實際上可能永遠不會施加於結構上的荷載）來達成。然而，這樣的取捨會為專案帶來額外成本。
有趣的是，主要的科技公司實際上在其消費性產品設計中，採用了瀑布式（waterfall）的設計方法。
敏捷方法本身其實是一種值得質疑的實務，因為它假設我們擁有無限的產能。它認為總是會有足夠的產能來完成工作；也就是說，因為這是技術性工作，就一定會有知識型工作者隨時待命。但現實並非總是如此。
數位科技已經徹底改變了生活與商業的每一個面向，而建造業同樣沒有理由不能善用這股尚未被完全發揮的力量。然而，應用科技解決方案時，必須放在一個清晰、理性且具策略高度的脈絡中，而不是只是把東西往牆上丟，看哪個會黏住。
在本書的最後三分之一，我將談論一個自動化的數位未來，整合我們所討論的所有元素，並提出一個框架，協助我們有信心且靈活地轉型，跳脫目前低效的現狀。
沒有留言:
張貼留言