這個系列的文章有一陣子沒寫了,最近 Teddy 家裡一堆電子產品壞掉,讓 Teddy 想起了另一個敏捷式例外處理設計原則:自動化更新。
先談一下 Teddy 維修的慘痛經驗。
維修奇美 42" 液晶電視
前一陣子 Teddy 買了 2 年多的奇美電視壞了,當初會買奇美,主要是『便宜』,和日系相同尺寸的電視相比,價錢大約只要 1/3 ~ 1/2,而且有三年保固。現在電子產品的生命週期都那麼短,與其買一台很貴的日系電視,還不如買國產的用一用先,萬一 3 年後真的壞了,到時候液晶電視價錢一定降很多,再買一台新的也划算。
沒想到還不到三年就真的壞了,電視完全無法開機。Teddy 從網路上查到奇美維修站的電話,打去報修,和維修的師父約了好幾次,都說當天晚上沒有時間不能來,最後只好約了禮拜六(Teddy 的電視是禮拜一壞掉的,此時心中已經略有不爽)。
等維修師父來了之後,居然雙手空空,什麼也沒帶。隨便看了一下電視型號與保固書,說了一句令 Teddy 吐血的話:你的電視還在保固期,我們無法維修,請聯絡『原廠』。
就這樣,過了一整個禮拜,Teddy 的電視機居然都還沒進入到『維修狀態』。後來好不容易聯絡到『原廠』的維修師父,服務還不錯,當天晚上就帶著一個電路板直接到 Teddy 家裡來更換,當場就修好了,免費。這下子總算讓 Teddy 對奇美的信心指數稍微回升了一點(你看,台灣的消費者是很容易就滿足的)。
相信有類似經驗的鄉民們應該不少(維修過程與結果是好是壞就不一定了),以上的經驗告訴我們:
- 為了搶 Time-to-Market (即時上市),很多電子產品的『品質』都只能作到『堪用』。
- 消費者為了『嘗鮮』,心裡也都預期到『新的東西 bugs 很多』。
但是,如果『售後服務很爛』,消費者被騙一次之後就不太可能持續購買同一家的產品(
***
以上故事告訴我們,要推出一個成功的產品,至少存在著兩個互相衝突的力量 (conflicting forces):
- Time-to-Market (想想 Eee PC, iPad 或 iPhone)
- Quality (在這裡我們考慮 reliability)
,反正先買先享受,有問題維修很方便。
***
鏡頭回到軟體開發。軟體例外處理的最高境界,就是程式中所有可能發生的例外都被妥善的處理,如此一來在 runtime (程式執行時期)就不會因為有『未被處理的例外 (uncaught exceptions)』而導致程式當機或是系統出現一些不預期的行為。例外處理的目的很清楚,但是實施起來卻很難,關於這一點 Teddy 在『敏捷式例外處理設計的第一步:決定例外處理等級』曾經提到三個主要原因:
- 屬於非功能性需求的例外處理很容易被忽略(時間不夠)
- 有些例外是需求面看不到的,要到實做時才會出現
- 真的不知道要怎麼處理(實做知識不足)
想像一下,原本你開發的軟體可以順利執行在 Windows 2008 64-bit,但是有一天使用者安裝了 SP2 更新程式,你的軟體就無法再執行。這種『因為執行環境改變而導致系統無法順利執行』的情況實在太多了,當然你可以辯解說『我們的程式出生的時候,SP2 都還沒
所以,兩週後產品就要推出了,環境相容性測試還沒做好,程式還有
對,就是『自動化更新』,明知軟體產品有問題還是要硬著頭皮推出,還好有『自動化更新』這個法寶,當作最後的『安全網』。這就好像
這時候,消費者早就已經忘了,『為什麼以前的電視看 20 年都不會壞,現在的電視看兩年就壞了』。總之消費者與業者各取所需,
消費者:先買先享受(口袋又薄了)。
業者:先賺先贏 (股價又漲了)。
***
結論:軟體功能做的爛沒關係,『自動化更新』一定要做的好。多學學人家 M$crosoft,多麼認真的更新啊,還會幫你重新開機喔...(路人甲:他馬總統的,我跑了三天的實驗...XD)
***
友藏內心獨白:這一篇是抱怨文嗎?
沒有留言:
張貼留言