2008年8月1日

如有雷同,純屬巧合。

很久很久以前,有位有名的工程師,姑且稱之為 R。R 相當有天份,不但非常會寫程式,對於藝術也有一定才能。他的興趣跟專長是使用者介面程式,作品的圖形很精緻漂亮,而且都是自己畫的。R 正要開發一個新專案,使用者介面是由公司裡的設計部門提供,姑且稱之為 W。W 跟老闆的關係很好,他們都喜歡設計,不過本行都不是使用者介面,以前也沒有獨當一面經驗。

老闆跟 W 想做很酷的產品,於是用 flash 設計了一份介面,要求 R 做出。R 答應了,但過了一個月之後做出來卻全不是那麼回事。有些部分相似,但是他覺得不好的地方,卻自動的加入自己的想法改進。W 相當不高興,要求 R 要忠實的按照介面寫程式,因為研發部門不該干預設計部門的決定。R 反映這樣的設計會有些問題,等到實際使用時會造成不方便,不過並沒有得到 W 跟老闆的認同。於是 R 回去埋頭苦幹、打掉重做,忠實的複製了一份。但在研發的空檔,R 按照自己的想法,花了一些時間做了份相對簡化的介面,做為程式的另一種模式。

W 的版本完成之後,經過試用,當初 R 反映過的一些使用上可能發生的問題果然發生了。使用上相當困難,或者該說根本是無法使用。此時 R demo 了自己的版本,老闆跟 W 很不高興他沒有全力專注在開發自己的份內工作,不過也同意 R 的版本的確較佳,應該做為預設的模式,而非採用老闆跟 W 原本的設計。R 很不高興,他說他數個月之前就警告過,如今白費許多功夫。W 則認為新產品本來就是有嘗試錯誤的可能,他願意隨時修正。

一段時間後,專案漸趨成熟,R 與 W 再次發生衝突,這次是為了一個小按鈕。此按鈕原本不在設計介面上,但 R 認為有需要,所以加上。老闆與 W 認為此按鈕的功能可以取代,應該由程式自動判斷,而不需要在介面上出現。R 表示此一自動判斷的想法很好,但實質上無法要求所有程式都加上判斷功能,因為並非所有程式都由我們自行開發,所以還是保留手動選擇的餘地比較好。R 再次干涉設計團隊,也就是老闆與 W 的作品,讓 W 相當不滿。在充分的施壓後,R 表達他的反對,但仍然執行了決議。

按鈕移除後,在程式的使用者中引起很大的反彈,因為一旦自動判斷錯誤,就無法改變程式的決定,導致使用上非常不方便。掛名作者的 R 公開表示,他無能為力,因為設計團隊已經下了決定,他只是工程師,所以無法改變決策。使用者相當火大,要求設計者出面說明。W 得知後做了解釋,但對 R 的行為相當憤怒,認為是故意搧風點火。至於使用者,他們對 W 與老闆的解釋並不滿意,仍然持續要求放回按鈕。

故事的結局是:W 決定把按鈕放回。與此同時,老闆接受了 R 的辭呈。

這個故事是一則寓言。寓言的定義是,它在現實世界中從未發生,但聰明的人可以從中獲得一些啟發。

沒有留言 :

張貼留言