修正錯誤的代價

剛開始工作時，東西有問題就該改，彷彿是天經地義的。慢慢地，知道專案的資源有限，就越來越常面臨到各種需求與規格的取捨問題。這樣的想法，在聽到Randy Pausch說了"時間必須受到明確的管理，就像金錢一樣: 你把樓梯扶手的底部擦得再亮也不會有人看到"後，更強化了這樣的想法。

然而，對於不用負擔人力、時間成本或營運風險的需求單位來說，並不容易理解這樣的考量。經過幾次拉鋸後，我也越來越好奇，別人是怎麼處理這樣的問題? 最近剛好看到幾個例子，雖然不知道真實的原因，還是可以思考可能的原因。


雖然台灣有個很長壽的售票網也有萬年測試資料，但是發生在這麼年輕的網站，是讓我蠻驚訝的。這是管理問題，也可能影響消費者的信賴，不知道管理階層不知道，還是真的不打算處理這樣的問題。


"甘蔗阿公累病"，是這兩天的新聞。不過在抓圖的當下，同個網站已經有另一篇"網友讓「甘蔗阿公」笑了　廠商承諾將全數買走"的更新新聞。不知道是編輯沒有更新，或是首頁演算法漏了這則，首頁顯示的還是較舊的一則。


或是像颱風新聞，大標題已經是強颱了，但是連結還包含了之前輕颱、中颱時期的新聞。以一個新聞網站來說，讓讀者看到新聞的最新狀態，應該是很重要的事情。就算可以透過修改演算法解決，其複雜度與例外處理也需要列入考慮，也是成本與效果的取捨。


讓使用者看到錯誤的交易記錄，會不會很怪? 以這家銀行來說，即使是同一天的正負相抵，還是會列出一正一負的交易記錄。雖然使用者看起來會怪怪的，但或許會對銀行每筆交易都有憑有據更有信心?


另一個銀行的例子。名稱更是不避嫌地顯示為"更正"。


百貨公司發行的各種禮券、折價券，對於消費者在使用的時候意義都是一樣的。不過沒想到在退還未使用餘額時，是分別記錄到兩種不同的卡片。大部分的使用者來說，"為什麼不整合到同一張"肯定是個大問號，甚至抱怨。不過或許對該公司來說，轉換的成本遠高於處理這類抱怨的成本。畢竟，這種問題累計成客訴的機率不高，解決這問題能提高的消費金額也有限，萬一系統改出了bug反而造成更大的問題，也就變成了現在看到的狀況。

=====================

有錯就"應該"要改，還是身為PM要有的責任感。只是在面臨抉擇值不值得投入資源時，會不會影響產品核心競爭力、投資效應、修改的衍生風險... 都要考慮進來。至於要不要改、怎麼改，就要看公司的授權、文化、產業，以及PM的經驗與判斷了。