[系統開發]我們該專注的是程式Bug數還是規格Bug數？
所以，若要分析系統的穩定性問題，應該從錯誤發生的地方，一路從程式追溯回規格與架構，在專案開發中PG幾乎是最後一個接手人，決定權也不高，但卻必須要承擔大多數系統的品質問題，這是不公義的，其實規格的Bug所帶來的影響並不比程式的Bug來的小，應該被同等重視，別再讓PG成為系統問題的代罪羔羊。
我想寫過程式的朋友都知道，當系統發生Bug時，首當其衝的通常是程式撰寫人員，而Bug這個詞，也往往跟程式問題畫上等號，所以「系統有Bug=程式有缺陷」這個觀念似乎已根深蒂固在使用者心中，而當系統Bug多時，程式設計師也被迫要背負著程式品質不良的罪名，但其實，系統的Bug應該被分成以下三類：
1.程式的Bug：直接當掉、跳出錯誤訊息、script執行失敗、運算結果不對....
2.規格的Bug：與使用者需求不一致、不良的介面設計、不精確的規格內容...
3.架構的Bug：不正確的介面設計、不當的技術選擇、有問題的3rd party元件...
我們在做系統的異常分析時，會將Bug區分開來，有Bug不見得都是程式的問題，很多時候是架構與規格本身就有問題了，當規格已經錯了，程式可以寫對反而詭異，這意味著需求的V&V沒有做的落實，原則上規格應該往回追溯到需求(追溯的觀念可以參考：[系統開發]需求雙向追溯矩陣(Traceability Matrix))，確認這樣的規格是滿足使用者需求的，程式設計師再依規格往下進行撰寫，對程式設計師來說應該只要關注品質問題，而不是規格問題，而SA/SD人員則該對需求的正確性負上責任，不能隨便開開就叫程式開發人員往下撰寫，然後由程式開發人員承擔一切後果，這是不公平的。
所以，若要分析系統的穩定性問題，應該從錯誤發生的地方，一路從程式追溯回規格與架構，在專案開發中PG幾乎是最後一個接手人，決定權也不高，但卻必須要承擔大多數系統的品質問題，這是不公義的，其實規格的Bug所帶來的影響並不比程式的Bug來的小，應該被同等重視，別再讓PG成為系統問題的代罪羔羊。
 |
游舒帆 (gipi) 探索原力Co-founder，曾任TutorABC協理與鼎新電腦總監，並曾獲選兩屆微軟最有價值專家 ( MVP )，離開職場後創辦探索原力，致力於協助青少年培養面對未來的能力。認為教育與組織育才其實息息相關，都是在為未來儲備能量，2018年起成立為期一年的專題課程《職涯躍升的關鍵24堂課》，為培養台灣未來的領袖而努力。 |
