獨孤木 - 打狗救台灣

July 10, 2006

Prototyping

提到prototype，我忽然想起了一個老笑話。話說小學一年級的學生剛入學，老師要大家把他們的名字寫在紙上，然後老師看著大家交上來的紙條，老師就開始點名。

老師：黃肚皮，黃肚皮？奇怪，怎麼沒有這個人。

老師想想就先跳過了。當老師點完所有的小朋友之後，就問：有誰沒有點到的呀？

這時有一個小朋友舉手了。

老師問：你叫什麼名字？

小朋友說：我叫黃月坡。

如果你看不懂這個笑話，你必需先在內心中想像一個小學一年級，還不太會寫字的小朋友，寫著歪歪斜斜擠在一起的文字。然後再看看肚皮跟月坡這兩個字…嗯，如果寫得很難看，誤解也是難免的事情。

當我們在進行軟體開發時，為了降低文字的不精確，也為了讓我們比較快速了解你想表達的意涵，我們會選擇採用許多圖形化的模型，透過這些模型，來表達並確認我們對於系統的了解。

有時候，就算你做出來的模型不對，可能會造成錯誤的解讀。這種時候，也就是黃月坡會被解讀成黃肚皮的時刻。可是只要經過確認的動作，通常，雙方就可以搞懂，原來我把這幾個字看成黃肚皮，是一件不對的事，我們要的其實是黃月坡。

對於軟體系統來說，當你需要跟客戶確認虛無縹緲的軟體需求時，最有力的工具，就是透過製作一個長得很像的雛型(prototype)來進行確認。當一個人看到一個長得蠻像系統的東西時，比較有辦法在腦海中描繪出他們對於系統的需求。

所以當一個系統分析人員在確認需求時，或是專案經理在規劃開發模式時，不管你採用什麼樣的開發方式，prototyping通常都會是一個相當不錯的溝通方式。

不過在採用prototyping時，常常會遇到下面的問題：
‧沒有抓到確認prototype的重點
‧客戶看到prototype之後，就會期待做出來的系統會有一模一樣的反應
‧客戶看到prototype之後，會預期系統在短時間內就可以開發完成

沒有抓到確認prototype的重點

Prototype的目的會期望使用者可以從系統實際開發出來之後的模樣，去確認他們對於系統的真正需求。所以照理說，只要把想要傳遞的概念完整呈現之後，讓使用者可以驗證邏輯上是否正確，並且可以讓使用者依據他們的作業流程，從頭到尾走一遍，看看這個故事有沒有什麼走不通的地方。

不過對於使用者來說，他們看待事情的方式可能截然不同。所以有時候可能會遇到這樣的問題：

布魯斯：獨孤大人，這是我們採用虛擬實境的方式，讓您可以事先透過最新的電腦科技，體驗您會參加的行程。

獨孤木：等一下，為什麼我坐的專機是漆成好像三色牙膏一樣？搞什麼呀？是不是政黨輪替後你們就喜歡綠色？我可是大明國的堂堂侍郎。

布魯斯想，座機是什麼顏色，有那麼嚴重嗎？真是沒度量的小官：喔，這是我們製作prototype時的疏失。您可以先看一下，整個行程的其它部份。

獨孤木：搞什麼呀，簡直是亂搞…嗯，不錯，去泰國看人妖秀。耶，這男的這麼醜也去當人妖？你嘛幫幫忙，看了就想回家。

布魯斯：喔？大概是我們找不到適合的臨時演員。找來演人妖的人不合您的喜好。不過我們這次體驗的重點在於會想要跟您確認每一關的行程，像是要去皇宮看看暹邏國王，然後要去騎大象玩拖曳傘。

獨孤木：這不成，你們回去重做。看到那個醜男去扮人妖就倒胃口。我明天再來看一次，到時候你要是沒弄好…哼！

布魯斯大驚：啟稟大人，這有困難呀。我們上次做這個prototype，光是製作成視覺向量模型，就要一天的時間去做運算。更何況還要再去找臨演。

獨孤木：這是你的困難，不是我的。我付錢就是要當大爺，又不是要聽你訴苦的。你把我當做你的心理醫生呀？就這樣決定了。

在實際上驗證需求的過程中，使用者常常會抓不到確認prototype的重點。當我們在進行需求確認的時候，重點其實是在於有沒有忽略什麼重要的功能，所有的功能之間是否可以彼此合理的串接起來，各種系統的反應，是不是合乎使用者的預期。

不過實務上，我遇到最多的，其實都是夾雜各式各樣的修正意見在裡面。像是欄位太寬太窄，字型不好看，字型太小，應該要靠左邊縮排，文字描述不對…這類型的意見其實佔了最大宗。很多時候，當我們透過prototype要確認需求時，會弄得很像是大家來找碴：『請在這個畫面中，找出十個跟你心目中預期的畫面不一樣的地方。』

這並不是說這些畫面設計安排的元素不重要，而是說prototype的用意在於收集到使用者的需求。並且期望透過prototype的建立，可以讓使用者的需求慢慢收斂到合理的範圍之內。

不過實務上，很多人都把它當做是在簽訂一份合約書一樣。只要你在這裡面沒有挑出毛病來，到時候要改，就要拿出大把鈔票，開發團隊才會讓你改。

當然，當我們玩完大家來找碴之後，常常就會收到很多要你更改prototype的意見，然後就會有人要你做大家來找碴part 2, part 3…，好像製作prototype完全不用成本一樣。

這其實是蠻不好的現象。不過由於提出修改的單位通常就是業務的主要承辦單位，是系統開發的要角，所以你大概也只能乖乖的陪著去玩大家來找碴。

還有一點要注意的是，要想辦法控制參與確認需求的人數。參與的人越多，官僚體系就會生出越來越多跟開發無關的事要做。比如說小老闆的想法可能就跟大老闆的想法差很多，光是要找一個大家都有空的時間來開會，就很難排出時間表來…這種隨著人多就自然而然衍生的問題就會變得很討厭。盡量讓客戶去凝聚他們的共識，而非你一個一個去打通關，應該就是最高指導原則了。

客戶看到prototype之後，就會期待做出來的系統會有一模一樣的反應

通常這方面的問題可以分為兩種。一種是功能面的問題，另一種是系統的效能面(performance)的問題。

當我們在製作prototype時，其實只是做一個看起來長得很像的東西，想要藉著這樣的雛型，可以讓使用者體驗一下實際開發出來的系統的感覺。由於你的目的只是要做一個看起來很像的東西，所以背後的運作就都是寫死的，透過你心目中假想的資料與流程來讓使用者進行確認。

在這樣的狀況下，使用者會期待做好的系統，就一定是長成跟你給他看過的prototype一模一樣。

可是當你實際開發時，你很有可能會發現，有些事情你辦不到，或者是為了要達成這樣的目的，你會需要付出太多的代價。這種時候我們就會修改設計，然後可能會用一個不太一樣的解法來解決這個問題。

如果使用者發現功能面上有所不同，而你沒有事先告知這個改變，你要驗收時就有你受的了。

另外一個問題則在於performance的問題。你在製作prototype時，由於大多數狀況下都不會牽涉到要拿實際的資料進行運算或是處理，所以速度都是飛快。畢竟prototype就是一個長得很像的空殼子。

可是當你把真正的程式開發完成之後，如果規劃的不好，你要面對的問題很有可能就是performance上的夢魘。使用者喜愛的方式，可能速度奇慢無比。遇到這種狀況時，修正就是勢在必行。不過這種時候，就有可能會造成雙方對於何者是enhancement，何者是在scope中的爭辯。

所以當你在設計prototype時，請記得要考慮，這個功能這樣做會不會做不出來？如果遇到實際的資料，會不會造成performance的瓶頸。

客戶看到prototype之後，會預期系統在短時間內就可以開發完成

大家都知道懷胎十月才會把小孩給生出來，不過如果你老婆懷孕了，你陪著他去做做超音波檢查，看看肚子裡面的小寶寶在裡面動來動去的，你會有什麼想法？再過幾個月，時間到了，應該就要準備迎接小寶寶了吧？

很多客戶看到prototype時，就跟期待小孩的父親看到超音波檢查的畫面一樣。當你看著已經成形的系統可以動呀動的，心裡面總會想，應該再過幾個月，系統就可以順利上線吧。雖然，我們會針對客戶的預期進行管理，可是對於很多客戶來說，他看到prototype，就會覺得這套系統的上線運轉，應該就指日可待了。

這也是透過prototype進行溝通時所遇到的一個大問題。做一個看起來很像的東西，跟做一個完整的系統，中間的相距很大。不過對於不懂開發系統的人來說，看到prototype出來，大多都覺得剩下的事情就很簡單了。你們只要認真一點做，就應該可以在很短的時間內把東西做出來。如果出問題，一定是你們開發的人不夠認真，才會沒有辦法在時間內把系統開發完成。

雖然prototype會面臨這些問題，不過在進行專案開發時，採用prototype來驗證使用者的需求，好處是遠遠多於壞處。

這樣來說，如果我們建造正確的prototype，並且配合適合的軟體模型，選用了合適的開發方法，就可以解決軟體開發時所面臨的溝通問題了嗎？

這當然不然，我們還需要面對專案開發團隊之間的溝通問題。

使用相同的modeling language，並且使用適合的工具，就可以解決開發團隊之間的溝通問題？

在過去的幾年中，大家常常聽到的一種說法就是，因為大家在開發系統時，會採取各種不一樣的開發方式，會用不同的方法去進行軟體的設計，所以所有的問題就是導因於大家沒有一套標準的modeling language，只要我們大家採用相同的modeling language，並且使用同樣的一套工具，就可以徹底解決這方面的問題。

這樣說來，使用相同的modeling language，並且使用適合的工具，就可以解決開發團隊之間的溝通問題？真的有這麼好康的事情嗎？

駙馬爺要收紅包或是要炒股票，雖然知道不可以使用自己的帳戶，可是用家人的人頭帳戶來進出，比起很多專業的洗錢團隊來說，就是很遜的解法。就媒體報導的洗錢手法來說，三等親之內的人頭通通都不該用才對。

難道是因為駙馬爺不懂得說國語，所以洗錢的能力就輸給專業的洗錢團隊嗎？我想，最重要的，是想要洗錢的人到底懂不懂這裡面一些特殊的訣竅。一樣使用人頭帳戶洗錢，方法不同，效果也就完全不同。

一個團隊中，會有各式各樣不同的人，每個人擁有不同的能力，不同的背景，對於Domain knowledge，也就會有不同的認知，不同的經驗，擁有不同的想法。寫軟體是概念的溝通與意念的交換，每個人的知識水準不一樣，怎麼樣讓大家對於解決問題，建立起相同的共同的想法，就是進行溝通時，最重要的事情。相形之下，Modeling language只是一個工具而已，使用同樣的語言，當然可以降低溝通的誤差，增進溝通的效率，可是工具就僅只於工具而已。它並沒有辦法讓還在學習加減法的小學生，了解微積分的奧義。

那我們又要怎麼樣讓大家可以建立共識呢？事實上，當我們觀察不同的開發團隊時，我們可以發現，很多長期合作，具有越多共同開發經驗，以往表現良好的團隊，越有可能在新的專案中做出比較好的成果。

如果你去觀察這樣的團隊，你會發現，在共同開發的經驗中，其實累積了很多共通的概念。而這些概念，有很多會被轉化成不同的隱喻(metaphor)。就像是很多秘密幫會都有屬於自己一套的秘密儀式與行話一樣，當你唸了某一句詩，再做個什麼動作，馬上就知道你是同一掛的，而且你還是青木堂的堂主。比如說天地會的會眾只要把鞋子脫掉，就會看到腳底下刻著反清復明。

以這幾年的風潮來看，蠻多人嘗試透過學習design pattern，讓大家可以就很多系統開發常見的問題，找到一個前人已經研究過，覺得比較優質的解決方案。這樣的學習當然對於系統開發會有正面的效益，對於大家彼此交換心得與概念也有正面的幫助。不過書上看來的東西，跟自己實務上遇到的問題，以及團隊彼此合作所建立的共識與默契，其實這中間還是存在蠻大的距離。我個人是覺得，只有在你清楚明白你所面對的問題，並且知道各種判斷解決方案優缺點的標準之後，你對於這些所謂的pattern，才會有真正自己的體會。

很多人聽過這樣的一句話：『世界上最遠的距離，就是你在我身邊，卻不知道我愛你。』對於專案開發來說，可能就應該這樣詮釋：『世界上最遠的距離，就是你在我旁邊不斷地畫圖引經據典在解釋演算法，我還是搞不懂你要我怎麼寫這支程式。』

對於有心建立一個軟體專案開發團隊的人來說，怎麼樣讓大家在開發的過程中，可以累積相同的體驗，並且建立屬於自己團隊的metaphor，就會是一個需要去面對的課題。