昨天提到了在開發前確認好要驗收的項目與規格的滿足條件，今天就聊個相關的議題吧。這也是一個在軟體開發與維護上很常發生的情境：使用者和需求方常常會把真正的 Bug 和與預期有落差這件事看作同一件事，統一在回報時說是 Bug 、壞掉、缺陷等等，但有時候回報的項目不是 Bug，而只是雙方對軟體行為的認知有差異導致。

所謂的 Bug，應該是預期軟體有什麼行為，但是給了預期外的反應。而所謂的預期落差 [^1]，是原本不預期有這個行為，但是提出者認為應該是這個行為，把實際的反應認為是預料外的回饋。對不知道原本規格的使用者來說，很難分辨這兩種是情有可原的，對他們來說，這兩種都是預料外的反應。但是若是需求方或是組織內部的其他成員，如客戶與業務無法分辨時，就代表了他們和開發方對需求上有著認知不對稱的情況，這會導致兩方溝通上的衝突以及增出額外的成本。

當實際上不是 Bug 的預期落差不斷的回饋給開發者時，就等於一直打斷開發者正在進行的事情，不得不花時間不斷解釋，為什麼這個不是 Bug。但是有時候卻也不是單純解釋完就結束的，更容易發生的情況是開發方不斷說這不是 Bug，而需求方或是組織其他成員卻一直說是 Bug，兩方陷入鬼打牆，虛耗溝通成本與增加不愉快的衝突。這也是昨天之所以會講在開發前要確認好驗收項目與規格的滿足條件，而且若是開發中有變動滿足條件時，也要讓資訊同步出去。

為什麼區分這兩者很重要呢？Bug 很單純，就是把它修復成原本預期的行為就好。但是若是把預期落差認為是 Bug，就等於是無形偷渡了許願、額外的需求、未預期的變動，而所謂的偷渡就是沒有經過篩選、討論的，這可能就會導致軟體與原本預期的功能和行為逐漸背離，也會增加日後開發維護與客服的複雜度。

比較好的方式應該在於讓組織內部成員都能分辨兩者，把預期落差的回報另外建檔管理，將這份資料視為使用者的潛在需求，另外進行討論。看是不是其實某個需求在當初規劃時沒有考慮進來，但實際上是多是使用者很需要的功能，若確實如此，就可以考慮排進軟體未來版本的規劃中。若是回報數量少，那可能就該加強的就是對使用者的教育訓練、或是討論是否原本介面上的說明與導引有可以再加強的地方，而不是讓它被偷渡直接被實作出來，最後卻沒有幾個使用者在用，浪費了昂貴的開發成本。所以這些資料雖然不是 Bug，卻也是產品未來的具參考價值的值得被分析珍貴資訊。對組織來說，是未來規劃產品的底蘊；對接案者，也可以透過這些資料與業主談談下一期的開發合約。所以釐清兩者的差異，對軟體開發是有幫助的。

1: 這不是什麼已存在的專有名詞，是我為了方便代指這件事所臨時建構出來的名詞，尚不確定有沒有現有的專有名詞可以代稱，若之後有找到會再修正。