為什麼一種好好的動物，會有龍頭、馬身、麒麟角、獅爪四種不一樣生物學上的特徵？
這一點道理也沒有。
我懷疑這一定是遇到了四個不同的客戶造成的。
| 鄭和下西洋(七)：portotyping(1) |
獨孤木 2006/06/26
要解決軟體專案小組與客戶的溝通障礙，整個資訊產業界其實運用了兩種不同的哲學基礎的解決方式。
採用不同的開發方法
第一種想法，是不相信使用者可以一次就描繪出系統的全貌。封神演義裡面姜子牙有一匹神奇的座騎，是元始天尊賜給他的神獸。叫做四不像。為什麼一種好好的動物，會有龍頭、馬身、麒麟角、獅爪四種不一樣生物學上的特徵？這一點道理也沒有。
我懷疑這一定是遇到了四個不同的客戶造成的。每個人出一張嘴，到最後拼裝在一起，就弄出一個四不像來。咦，封神演義後面的章節裡面，還有提到老子一氣化三清…嗯，所有的謎題都已經解開了。當初要設計這匹聖獸時，當開發團隊要找使用者討論它的features時，一定是老子敲完自己的頭之後跑出來了三個道人，外加他自己四個人，大家七嘴八舌，才會弄出一匹四不像來。弄完之後，自己覺得不太優，就給了師弟元始天尊當座騎。
當我們採取不相信使用者可以一次就描繪出系統的全貌時，我們會傾向於相信，開發系統不是一個一勞永逸的工作。你會需要第一版，你會需要第二版，你會需要一組人沒日沒夜地不斷加班，然後不斷產生新的版本，慢慢去趨近真正使用者所要的東西。頭一版先找匹龍過來取出龍種來，下一版找匹馬來做做DNA實驗，接著再一步一步往四不像邁進。
當你開發的東西沒有人可以掛保證 ：『是的，你就是照這樣子去做，這就是我們要的。只要你做得到我們就付錢。』那麼，你就可能需要採用這樣子的開發方式。
這樣的思考哲學當然就造就了所謂iterative的開發方式。不過要採用這樣的開發方式，會有一些先天的限制，像是出錢開發的人，會願意為了不斷地改版付錢，而決定需求的人，需要在每個不同的版本之中，都投注資源進來參與開發的工作。所以通常我們看到大多數會採用這種方式進行開發的系統，都是拿來開發公司內部自有的產品或是內部使用的專案居多。真正客戶掏錢出來，委託軟體公司使用iterative的方式開發，這種例子其實極為少數。
所以當我們在挑選開發方式時，如果你所面對的是一個固定金額的合約，有著明定的系統範圍與交貨時間與交貨項目，你就需要慎重考慮，你是不是要採用iterative的開發方式。
對於大多數的專案來說，你並沒有機會可以不斷地針對同一套系統進行改版。對於開發人員來說，既然沒有重來的機會，那另一派的思考邏輯就會在於，怎麼樣可以透過適當的軟體模型(model)，讓使用者與開發人員之間的誤差可以降到最小，期望透過有效的溝通，可以減少漫無方向成長的requirement。
要降低使用者跟開發人員之間的溝通障礙，最有效的方法就是建造一個雛型(prototype)。
Prototyping
提到prototype，我忽然想起了一個老笑話。話說小學一年級的學生剛入學，老師要大家把他們的名字寫在紙上，然後老師看著大家交上來的紙條，老師就開始點名。
老師：黃肚皮，黃肚皮？......奇怪，怎麼沒有這個人？
老師想想就先跳過了。當老師點完所有的小朋友之後，就問：有誰沒有點到的呀？
這時有一個小朋友舉手了。
老師問：你叫什麼名字？
小朋友說：我叫黃月坡。
如果你看不懂這個笑話，你必需先在內心中想像一個小學一年級，還不太會寫字的小朋友，寫著歪歪斜斜擠在一起的文字。然後再看看肚皮跟月坡這兩個字…嗯，如果寫得很難看，誤解也是難免的事情。
當我們在進行軟體開發時，為了降低文字的不精確，也為了讓我們比較快速了解你想表達的意涵，我們會選擇採用許多圖形化的模型，透過這些模型，來表達並確認我們對於系統的了解。
有時候，就算你做出來的模型不對，可能會造成錯誤的解讀。這種時候，也就是[黃月坡]會被解讀成[黃肚皮]的時刻。可是只要經過確認的動作，通常，雙方就可以搞懂，原來我把這幾個字看成黃肚皮，是一件不對的事，我們要的其實是黃月坡。
對於軟體系統來說，當你需要跟客戶確認虛無縹緲的軟體需求時，最有力的工具，就是透過製作一個長得很像的雛型(prototype)來進行確認。當一個人看到一個長得蠻像系統的東西時，比較有辦法在腦海中描繪出他們對於系統的需求。
所以當一個系統分析人員在確認需求時，或是專案經理在規劃開發模式時，不管你採用什麼樣的開發方式，prototyping通常都會是一個相當不錯的溝通方式。
不過在採用prototyping時，常常會遇到下面的問題：
沒有抓到確認prototype的重點
Prototype的目的會期望使用者可以從系統實際開發出來之後的模樣，去確認他們對於系統的真正需求。所以照理說，只要把想要傳遞的概念完整呈現之後，讓使用者可以驗證邏輯上是否正確，並且可以讓使用者依據他們的作業流程，從頭到尾走一遍，看看這個故事有沒有什麼走不通的地方。
不過對於使用者來說，他們看待事情的方式可能截然不同。所以有時候可能會遇到這樣的問題：
布魯斯：獨孤大人，這是我們採用虛擬實境的方式，讓您可以事先透過最新的電腦科技，體驗您會參加的行程。
獨孤木：等一下，為什麼我坐的專機是漆成好像三色牙膏一樣？搞什麼呀？是不是政黨輪替後你們就喜歡綠色？我可是大明國的堂堂侍郎。
布魯斯想，座機是什麼顏色，有那麼嚴重嗎？真是沒度量的小官：喔，這是我們製作prototype時的疏失。您可以先看一下，整個行程的其它部份。
獨孤木：搞什麼呀，簡直是亂搞…嗯，不錯，去泰國看人妖秀。耶，這男的這麼醜也去當人妖？你嘛幫幫忙，看了就想回家。
布魯斯：喔？大概是我們找不到適合的臨時演員。找來演人妖的人不合您的喜好。不過我們這次體驗的重點在於會想要跟您確認每一關的行程，像是要去皇宮看看暹邏國王，然後要去騎大象玩拖曳傘。
獨孤木：這不成，你們回去重做。看到那個醜男去扮人妖就倒胃口。我明天再來看一次，到時候你要是沒弄好…哼！
布魯斯大驚：啟稟大人，這有困難呀。我們上次做這個prototype，光是製作成視覺向量模型，就要一天的時間去做運算。更何況還要再去找臨演。
獨孤木：這是你的困難，不是我的。我付錢就是要當大爺，又不是要聽你訴苦的。你把我當做你的心理醫生呀？就這樣決定了。
不過實務上，我遇到最多的，其實都是夾雜各式各樣的修正意見在裡面。像是欄位太寬太窄，字型不好看，字型太小，應該要靠左邊縮排，文字描述不對…這類型的意見其實佔了最大宗。很多時候，當我們透過prototype要確認需求時，會弄得很像是大家來找碴：『請在這個畫面中，找出十個跟你心目中預期的畫面不一樣的地方。』
這並不是說這些畫面設計安排的元素不重要，而是說prototype的用意在於收集到使用者的需求。並且期望透過prototype的建立，可以讓使用者的需求慢慢收斂到合理的範圍之內。
不過實務上，很多人都把它當做是在簽訂一份合約書一樣。只要你在這裡面沒有挑出毛病來，到時候要改，就要拿出大把鈔票，開發團隊才會讓你改。
當然，當我們玩完大家來找碴之後，常常就會收到很多要你更改prototype的意見，然後就會有人要你做大家來找碴part 2, part 3…，好像製作prototype完全不用成本一樣。
這其實是蠻不好的現象。不過由於提出修改的單位通常就是業務的主要承辦單位，是系統開發的要角，所以你大概也只能乖乖的陪著去玩大家來找碴。
還有一點要注意的是，要想辦法控制參與確認需求的人數。參與的人越多，官僚體系就會生出越來越多跟開發無關的事要做。比如說小老闆的想法可能就跟大老闆的想法差很多，光是要找一個大家都有空的時間來開會，就很難排出時間表來…這種隨著人多就自然而然衍生的問題就會變得很討厭。盡量讓客戶去凝聚他們的共識，而非你一個一個去打通關，應該就是最高指導原則了。
作者為資深工程師及軟體開發專案經理，經常撰寫軟體專案的文章，作品散見於資訊論壇網站及其個人部落格中，著有《軟體超人X光眼：專案開發揭弊大爆料》一書。
本文為投稿作者意見，不代表CNET立場。--
留言列表
