偉大的設計出自偉大的設計師，而非好的設計程序

軟體工程協會（SEI）在軟體程序成熟度上的努力，其背後的基本假設就是，軟體產品的品質主要是由軟體開發和維護程序的品質來決定。

The basic premise underlying the SEI's [Software Engineering Institute] work on software process maturity is that the quality of a software product is largely determined by the quality of the software development and maintenance processes used to build it.－MARK PAULK [1995],“THE EVOLUTION OF THE SEI’S CAPABILITY MATURITY MODEL FOR SOFTWARE”

 

……或許有的人覺得他們很瘋狂，但我們看到了天才，因為這些瘋狂到自以為可以改變世界的人，就是改變世界的人。－史提夫．賈伯斯，蘋果公司廣告對白

...[W]hile some may see them as the crazy ones, we see genius,　because the ones who are crazy enough to think that they can change the world, are the ones who do.－STEVE JOBS, APPLE COMMERCIAL (1997)

 

偉大的設計與產品流程
開場白兩位作者的說法簡直相反，誰才是對的呢？

我早先曾依照產品是否擁有熱情的愛好者，列出我個人對某些知名電腦產品的分類，最近納入了一些補充，如圖19-1。我相信，此一區分已反映出這些設計的某些偉大之處。（跟商業上的成功一點關係也沒有，除了設計品質之外，商業上還涉及許多複雜因素。）

這張表引人注目的地方在於，據我判斷，右邊的產品全都是透過正規產品流程做出來的，亦即，牽涉到許多輸入和認可的程序；而左邊的產品則全都是在正規產品流程之外做出來的。

產品流程──正反意見
這項觀察就算多半正確，也並非全然如此，所衍生的重要問題如下：

● 為什麼有這麼多偉大的產品會跳脫產品流程呢？

● 產品流程有什麼用？為什麼需要產品流程？

● 遵循產品流程可以做出偉大的設計嗎？怎麼做呢？

● 如何使產品流程得以助長並刺激偉大的設計，而非抑制？

產品流程會抑制偉大的設計嗎？
我相信，標準的公司產品設計程序的確不利於真正偉大而創新的設計，想想公司流程如何演化、為何演化，便不難了解。產品流程之所以存在，就是為了帶來秩序，擺脫開發新產品時自然就有的混亂。

正如它的本質，程序是保守的，著重在某個井然有序的框架之下，引導出相似、又有點不同的東西。是故，完全不同的、高度創新的，就不容於這個框架。想想個人電腦，相較於1960 年代的企業級大型電腦機房，或1970 年代的集中式部門級迷你電腦，完全是不同的東西。

正如它的本質，產品流程著重在可預測性：在還沒有任何偉大的設計師對某個問題投入相當的時間之前，根據企業需求，粗略定義一項產品，就要在規定的時間、價格內交付。可預測性和偉大的設計是不相容的。

正如它的本質，產品流程是「打之前的戰爭」，鼓勵過去證實可行的策略，而不鼓勵失敗過的，所以，若產品面臨的是一場新的戰爭──全新的需求或運作模式──這兩種策略或許都不恰當。想想iPhone，跟單純的手機完全是不同的東西。

正如它的本質，產品流程是否決導向，著重在阻擋不良構想，捕捉疏漏之處。這種流程強調防止銷售不符期望、成本超乎預期的產品，並避免在功能和時程上無法履行的承諾。更微妙的，公司產品流程也旨在防止混亂的產品線，以免自己的產品變成自己最致命的競爭者，連顧客也不知該買什麼才好。由於引發失敗的因素很多，所以產品流程一般都需要多人取得共識，而這些人都是通曉某一類潛在失敗因素的專家。

這樣的共識在幾方面抑制了偉大的設計，首先，每個負責把關的專家都是為了避免失誤，而非讓偉大的事物發生，所以每個專家都傾向找出不要做下去的理由。即使某個真正的新產品未被否決，取得共識的機制也經常在強制妥協之下，磨鈍了利刃，然而，能削能切，靠的就是利刃！

其次，產品流程不僅要在現況取得共識，也要和過去取得共識，才好編入規則。跟所有典章制度一樣，產品流程會持續增長，為免重蹈覆轍，每次失誤的經驗都會帶來新規則，或新的認可程序，很難阻擋這種額外規則的產生，而且，一旦產生出來，除非緊要關頭，否則沒有任何力量可以消除。正是此一本質，使得官僚作風更加錯綜複雜，程序的包袱也更加沉重，而組織在成功與成長的同時，也越來越不靈活。

1960 年代初期，當我負責管理IBM System/360 電腦系列的硬體開發時，我們的Model 20 主機係由Boblingen（德國）的實驗室負責開發，這支團隊擁有一流的天才和堅強的領導者，然而，他們經營多年，雖在特定市場有過成功的產品，?從未把產品帶到IBM 的主要產品線，亦即全球市場。為了這個「賭上全公司」的System/360 專案，實在頗令人擔心，於是我就展開調查。

後來弄清楚了，工程師們總是小心翼翼地謹守那100 多頁的IBM公司產品流程。其他實驗室成功的專案經理，都在正確的時刻對這套規則做出膽大的「例外」決定，智慧地選擇通往成功的秘訣！我把一位像這樣的流程操作老手送去管理這個案子，由他啟動強大的天才發揮潛力，終於締造出System/360 Model 20 非凡的成功。

最後，取得共識的過程會把資源吃掉，連帶吃光創新設計的資源。構築共識需要開會，開很多很多會，而開會將耗掉時間，耗掉很多很多時間。偉大的設計師非常稀少，他們的時間非常寶貴。

所以，到底為什麼要有產品流程？
我在妄想倡導推翻所有公司設計流程，擁護有創造力的混亂，是嗎？非也。以下諸多採用流程的理由都是無可避免的，有時，是否要做下去，必須得到公司的認可；有時，應善用經驗來捕捉明顯的疏漏；有時，產品的時程和預算必須取得同意才行。為了讓偉大的設計有機會出現，要訣就是扣住「流程」夠久，久到偉大的設計浮上檯面，這類非主流的議題終於得以討論──而不是還在搖籃裡就被程序悶死。

後代產品：由於大部分設計都並非為了高度創新，所以產品設計流程總會有某個重要作用，而成為運用流程的好理由。成功而真正創新的產品，一旦使用者用上手，至少會引發四個效應：

● 使用後，缺點得以浮現，必須在後代產品修正。

● 使用者把創新用在意想不到的地方，從而擴展了產品的概念，往往越做越大。

● 創新的實用性經過實際驗證，創造出更佳產品的需求，並隨時準備為它掏更多錢。

● 然而，在各方驅使改變的同時，廣受歡迎亦將引發凍結，使用者不喜歡下一代產品是「重大變革」──他們要的是他們所熟悉和喜歡的那個東西。

是故，後代產品是非常高度受限的，少有創新的空間，不過，先前的成功孕育出許多可在後代產品改良的機會和方向，?沒有任何組織可以做完所有的事，所以，這些後代產品必須從眾多的可能性中審慎選擇，其開發必須受到監控，以保證產品持續地貫徹所選擇的目標，貼近它所預期的顧客。

產品流程週而復始地運用於：

● 產品定義

● 市場預測

● 成本預估

● 定價預估

很有效率地貫徹它的選擇，以及監控。

不過，精確的市場預測取決於之前某些類似產品的銷售經驗，精確的成本預估取決於之前某些類似產品的開發和製造經驗。

是故，產品流程理所當然是為後代產品而設計的。至於創新，你必須跳脫流程。

提升設計實務的等級：產品設計和交付程序無法把優良的設計師變偉大，也絕少不靠偉大的設計師就能做出偉大的設計，但紀律確實可以提升設計曲線的低點，增進這項技藝的平均表現，這是不容忽視的。

軟體工程界已對開發流程給予了相當多的關注，這有其必要，據我所知，很少設計領域像軟體一樣，實務平均水準遠低於最佳水準，最差水準又遠低於平均水準。

Watts Humphrey 和軟體工程協會所發展並積極推廣的能力成熟度模型（Capability Maturity Model, CMM），非常值得大家參考，CMM 是一種制式化的量測方式，用以量測一個優良設計程序的要件，而這些要件是已被普遍認定有效的。流程改良對提升一個領域的實務水準最有幫助，CMM在這方面做得很好。

事情沒有那麼美好，流程改良的程度不可能把這個領域的實務水準提升到最高點，偉大的設計並非出於偉大的流程，而是得自於有天份的人勤奮的努力。引用蘋果公司的格言，「我們在〔CMM 的〕第I級，而且永遠都會在這一級。」然而，蘋果公司的成就已說明了一切。

即使是創新的設計，也不需要流程嗎？：有人問過我，「System/360專案整合了跨國界的實驗室，以及多重市場的商業需求，當然運用了大量的流程，你如何駕馭它，而不受限於它？」

我們的核心設計團隊適當地與例行的IBM 監督流程保持隔離，再加上來自各階層的膽大管理者強力支援，我們有破格從其他公司小組徵召天才的能耐，我們也有足夠的錢。

每當產品被要求照標準流程來走，設計就變成例外，高層指示，這次的賭注眾所皆知是革命性的，沒必要完全拘泥於標準流程。每一週，我們的團隊在預測、估計、定價等方面推出更多創新，而流程小組則會適度地打回票，形同拉鋸。不過，流程人員的才幹是一流的，在邁向成功的道路上，他們的能力是不可或缺的。

兩難：流程不利創新，又避免不了，怎麼辦？
偉大的設計出自於偉大的設計師；找出他們！
五音不全又無運動細胞的我，認為不論音樂、投球、舞蹈、設計，顯然天份的分布不僅不均勻，而且不管哪一種天份，好壞差距都非常大。

即使是一支學經歷很整齊的團隊，其中的天賦變化也相當大，在我帶過的團隊成員和學生裡，有些就是天賦高人一等的設計師──他們在我記憶裡閃閃發亮，藝術的歷史乃是由寶石般的典範裝飾而成。

此外，沒有兩個人擁有相同的天份。所以，有智慧的領導者都是先看有什麼人、能給他什麼，才賦予責任，而不是依自己的理想畫出框框，再把人硬塞進去。

我們標準而基本的民主信念是法律之前人人平等，對於更艱難的目標，大家機會均等，但是，在追求這些目標的同時，不能無視於天份的分布本來就極不平均，以及對成長、磨練、展露天份時具有不同驅策力的事實。

所以，我們的組織體系和流程必須冷酷無情地認知到，曾經做出偉大設計的人，就是比別人更有可能再做出另一個偉大的設計，只要信賴他，把自由和權力託付給他。

偉大的設計師需要企求創新的膽大領導者
最重要的是，組織的最高領導人必須非常熱愛以偉大的設計做出創新產品，蘋果公司在史提夫．賈伯斯首次當家期間，顯然就是如此，他的繼任者就不同了，直到他再回鍋擔任執行長才又改觀。這方面的例子還有很多。

如何創造有助偉大設計的流程？
我曾為累贅的流程所苦，在規避或違反流程方面，我是有一些經驗，但在精簡或重建流程方面，我則毫無經驗。每個組織不時都會有修改流程的需要，我願意把這份工作委派給第一流的天才，並在有限的工作與時間內充分授權。

倘若你正在設計一套新的產品流程，或重新改造舊有的流程，為了克服固有的不利因素，該如何在流程中納入制衡措施呢？如何創造一個流程，不僅容許、促成，甚至能助長偉大的設計呢？

首先， 產品流程必須明確區分出基本重大議題（fundamental importance），並針對這部分設限，也只對這部分設限，本質上，這是一種保護機制，用來確保象徵王位的皇冠，不過，同等重要的，可得小心是不是圍了一堵高牆，裡面卻是只垃圾桶，這需要審慎與克制——保護者的天性就是過度保護。

其次，產品流程必須提供簡便而即時的例外處理機制，以供任何專案經理提出請求，只要一位權限足夠的高階主管點頭即可，換言之，要有清楚而明快的判斷力和常識：「所有規則都可以打破。」

追求概念整體性：把你的設計託付給主設計師
鑒於概念整體性（conceptual integrity）是偉大設計最重要的特質，又因為概念整體性係來自於一或少數腦袋協同一致運作的結果，所以有智慧的管理者會大膽地把設計工作託付給有天賦的首席設計師。

託付有很多意涵，第一，管理者本身不可以對設計事後批評，倘若管理者也很想當設計師，那可真是一種誘惑，不過，一個人的設計天賦不見得比他最棒的部屬還要高（設計和管理是非常不同的工作），而且一個人在忙其他事情時，注意力也會分散。

其次，首席設計師對設計擁有絕對的主導權，即使他可能只管理少數幾位助手，他的社交位階也等同專案經理。

第三，一定要保護首席設計師不被專案外頭的賞鳥人士干擾，避免挪用他的時間。

第四，給予他所認為需要的一切工具和協助，他的事最優先。

偉大的設計師從哪裡來？
偉大的設計出自於偉大的設計師，而非偉大的設計程序，雖然技術設計目前多半是團隊合作，但我們還是可以看出團隊的組成仍是以偉大的設計師為核心。

不同於其他領域，高科技設計的管理者必須面對獨力設計典範（solo design paradigm）與團隊設計典範（team design paradigm）的根本衝突，前者在藝術、文學和工程上雖有許多偉大的創作，但為了因應當今人造工藝的複雜度，並跟上經濟發展的腳步，又不得不運用後者。

規劃正式教育的經驗
設計新秀和管理新秀一樣，也需要持續的正式教育，並搭配由設計老手所引導和批判的實務練習。

為什麼需要正式教育呢？因為世界一直在變，在高科技學科當中，技術教育更迭之快，實不言而喻，相當駭人。打從1952 年一頭栽進電腦這一行，我的專業智識生涯就像是浪濤中的超級海水浴，好不容易跌跌撞撞闖過一浪，後面緊接著又是一浪！非常爽快，非常過癮，而且變化無窮，所以，正式教育的第一個理由，就是持續地重整自己。

我個人發現，正式的短期課程是有效而經濟的重整方式──平均每年我都會安排一次，為什麼？持續閱讀期刊，勤跑研討會，不行嗎？確實也行！但我是正式教育的信徒──有好老師綜觀全局，針對某個主題悉心準備，可以把學習效率增進兩倍或更多，加速取得各方的均衡和見解，這是認真研究好幾十份期刊才會有的效果，身為老師，在努力把這樣的學習效率送給我的客戶之餘，我也嘗試為自己買下效率。

第二個理由，是增進深度和廣度。為此，最有效的做法，就是把從前和當代的好設計、壞設計都拿來研究，這方面，正式教育的重大優勢就是超然──專業老師比較會中肯地比較各種設計理念和風格，而任何設計機構的內部文化，則會偏重在自己的傳統和觀點，由公司贊助的正式教育亦然。所以，對設計新秀和他們的導師而言，這是到外界尋求正式教育的最佳理由。

規劃多樣性的工作經驗
如同現在最好的組織為管理新秀所做的一樣，我們也需要為設計新秀這麼做，關鍵是規劃兩字。年輕一代的職業生涯學習課程本身就需要經過設計──為了多樣性，為了涉獵的深度，以及為了全方位的挑戰和責任。

通常，在年輕設計師早期派任的工作中，成果最豐碩的，就屬送他到自己設計的東西的使用者公司那裡。我自己經歷過的短期工作，包括在一家商業資料處理機構，開發一支40 種級職的薪資程式；在一家科學計算機構，計算火箭彈道；一家密碼分析機構；在一家電話交換實驗室，辨識四戶合用線的撥話者……。在了解電腦使用者的內心需求方面，這些歷練的幫助都是無價的。Dewey的做中學（we learn by doing）理念是對的，有效的設計師培育課程必須納入多樣性的工作經驗。（摘錄整理自第十九、二十章）

---

設計的設計：一位電腦科學家的設計歷險
Frederick P. Brooks／著；錢一一／譯
碁峯出版
售價：480元

作者簡介－Frederick P. Brooks
Frederick P. Brooks, Jr.博士任教於北卡羅萊納大學教堂山分校，擔任計算機科學的Kenan講座教授，由於他在IBM System/360的開發階段擔任專案經理一職，遂以「IBM System/360之父」聞名於世，隨後還擔任了OS/360設計階段的軟體專案經理，為此，他與Bob Evans、Erich Bloch共同獲得1985年國家科技成就獎的殊榮。在此之前，他還當過IBM Stretch和Harvest電腦的架構設計師。

1999年，他獲頒美國計算機協會（ACM）的圖靈獎（A. M. Turing Award），這是在計算機領域中最具權威性的技術獎項，ACM盛讚他「對計算機結構、作業系統和軟體工程做出了劃時代的貢獻」。他也是《人月神話》的作者。