全站文章 iT邦幫忙
iThome Online提供免費電子報,現在就訂,最新IT訊息每日寄達。

iThome 每日新聞報
iThome 產品技術報
加入iThome Online會員,立即使用討論區、Blog等服務。

免費加入會員
登入 / 登出
管理會員帳號
忘記帳號密碼
聯絡客服
訂閱周刊
讀者服務
13' E政府專刊no.7(48)
13' iTcloud No.3(47)
12' E政府專刊no.6(46)
12' 個資法專刊No2(45)
12' iTcloud No.2(44)
12' e政府專刊No.5(43)
12' 個資法專刊(42)
11' CIO專刊(41)
11' e教育專刊No.3 (40)
11' e政府專刊No.4 (39)
11'iTcloud專刊(38)
10' e教育專刊No.2 (37)
10'e政府專刊No.3 (36)
09'e政府專刊No.2 (35)
09'e教育專刊(34)
09'e政府專刊(33)
08'企業資安專刊-端點安全防護(32)
08'企業採購情報誌(31)
07'資訊安全技術應用專刊(30)
07' 新世代資料中心專刊(29)
07'企業資安技術應用專刊(28)
企業採購情報誌'06冬季號(27)
書摘:偉大的設計出自偉大的設計師,而非好的設計程序
文/iThome (記者) 2012-03-16
分享到facebook
開發流程改良的程度不可能把某個領域的實務水準提升到最高點,偉大的設計並非出於偉大的流程,而是得自於有天份的人勤奮的努力


設計的設計:
一位電腦科學家的設計歷險

Frederick P. Brooks/著;錢一一/譯
峯出版
售價:480元
軟體工程協會(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 監督流程保持隔離,再加上來自各階層的膽大管理者強力支援,我們有破格從其他公司小組徵召天才的能耐,我們也有足夠的錢。

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


1 / 2 下一頁

分享到facebook

2014資安趨勢研討會
更多研討會
▼ ADVERTISEMENT ▼
▲ ADVERTISEMENT ▲

電週文化事業版權所有、轉載必究 •Copyright © iThome | 刊登廣告授權服務服務信箱隱私權聲明與會員使用條款關於iThome