怎麼跟開發廠商回報問題：什麼算 Bug、回報要寫什麼、嚴重度怎麼分
上線之後，系統一定會冒出問題，這件事本身不意外。真正會消耗雙方時間的，是 Bug（缺陷）回報的品質：一句「今天系統怪怪的」丟到群組裡，工程師看到後只能反問，一來一回三天過去，問題還沒被重現。
先畫一條界線：這篇只談上線之後的回報。驗收期的缺陷分級、以及分級怎麼綁付款節點，軟體驗收怎麼做已經寫過，這裡不重複。以下把上線後的回報拆成幾個部分：怎麼分辨缺陷與需求變更、一則有效回報要有什麼、嚴重度怎麼快速分、以及管道與節奏該怎麼約定。
先分清楚：這是缺陷，還是需求變更
這是所有爭執的源頭，值得先講明白。
**缺陷（Bug）**指的是系統的實際行為與約定的規格不符。訂單金額算錯、按了送出沒有反應、在手機上版面跑掉，這些都是缺陷，屬於廠商應該修正的範圍。
需求變更則是系統行為符合規格，但你希望它改成別的樣子。「這個欄位能不能改成必填」「希望多一個匯出報表的按鈕」「這個流程想簡化成兩步」——都是合理的想法，但不是缺陷，需要另外評估工作量與時程。
怎麼判斷：問自己一句話——「當初有講好它應該怎麼運作嗎？」如果規格寫了而系統沒做到，是缺陷；如果規格根本沒提到，那就是新的決定。
最常踩到的一步是把所有不順手的地方都當成缺陷回報，久了會讓真正的缺陷被淹沒，也會讓廠商開始逐條爭辯歸屬，雙方都在花時間打仗而不是解決問題。比較務實的做法是照實描述現象與影響，讓歸屬在議題紀錄裡討論，不在對話中先下定論。規格當初寫得夠不夠清楚，也可以回頭對照軟體需求怎麼寫檢查。
一則有效回報該有的六個元素
一則能讓工程師直接動手的回報，通常包含以下內容：
- 一句話標題：用現象描述，不要用情緒。例如「結帳頁選超商取貨後運費沒有更新」，而不是「結帳壞掉」。
- 重現步驟：從哪個頁面開始、按了什麼、輸入什麼，一步一行。
- 預期結果：你認為應該看到什麼。
- 實際結果：實際看到什麼，錯誤訊息照原文抄下來。
- 環境資訊：什麼裝置、什麼瀏覽器或 App 版本、用哪個帳號、什麼時間發生。
- 截圖或錄影：畫面比文字有效，能錄一段十秒的操作過程更好。
六項裡面最常被漏掉的是環境資訊與實際結果的原文。很多問題只在特定瀏覽器、特定權限的帳號、或特定資料狀態下才會出現，缺了這些線索，工程師在自己的環境試十次都不會發生。
重現步驟怎麼寫才有用
重現步驟是整則回報的核心，因為「能穩定重現」幾乎等於「能修」。
寫的時候有三個要領。第一，從登入開始寫，不要從中途開始，因為前面的操作可能正是觸發條件。第二，寫下實際使用的資料，例如「訂單編號 A12345」「數量輸入 0」，抽象的描述會漏掉關鍵。第三，寫出發生的頻率——每次都發生、偶爾發生、只發生過一次，這三種情況的處理方式完全不同。
只發生一次、事後重試又正常的問題該不該回報？ 應該回報，但要誠實註明無法重現，並盡量附上發生的時間點。時間是重要線索，工程師可以回頭查當時的系統紀錄。不要因為「怕是自己操作錯」就不說，這類偶發狀況往往是比較嚴重的問題在提早示警。
嚴重度怎麼分，才不會每件事都最緊急
如果每一則回報都標成「非常急」，等於沒有分級。上線後的日常回報用三句話就夠分：
- 核心業務停擺（客人無法下單、無法登入、金額顯示錯誤）——立刻用約定好的緊急管道通知，不要只丟進系統等人看。
- 主要功能壞掉但有替代做法（報表匯不出來，但可以在後台逐筆查）——進本週處理，不必打斷當下的工作。
- 不影響完成任務的瑕疵與外觀問題——累積到下一次議題檢視時一起排序。
更細的分級級距、以及各級對應的驗收與付款安排，屬於驗收階段的範圍，見軟體驗收怎麼做。
判斷的關鍵不是你有多在意，而是業務受多大影響。一個讓客人無法付款的問題，就算只出現在少數瀏覽器，也屬於最高一級；一個難看但不影響操作的版面問題，再礙眼也是最低一級。不同等級對應的回應時效與修復時效應該在維護條款裡先寫清楚，網站維護費用包含什麼裡有更完整的討論。
回報管道：什麼該進系統，什麼可以用通訊軟體
最常見的問題是所有回報都塞在通訊軟體群組裡。訊息往下捲就找不到、沒有狀態、無法統計，同一個問題可能被三個人各講一次，也沒人知道到底修好了沒。
比較能運作的分工是這樣：所有議題一律進工單系統或共用清單，不論大小；通訊軟體只用於緊急通知與即時釐清，而且釐清完的結論要補回工單。工具用什麼不是重點，用一張共用的線上表格也可以，重點是每則議題都有編號、狀態與負責人。清單的最少欄位只有五個：編號、一句話現象、嚴重度、目前狀態、負責的人。欄位設計得太複雜，第一週之後就沒人願意填。
誰可以直接回報，也要先講定。如果全公司每個人都能直接找工程師，同一件事會被重複回報，而且沒有人做過內部初判。比較穩的安排是收斂到一到兩位窗口：先在內部確認「這是不是設定問題」「別人有沒有一樣的狀況」，再往外送。這一步通常能過濾掉相當比例的誤報，也讓廠商收到的每一則都值得處理。
節奏也要事先講好。比較實際的安排是：非緊急議題累積成批，每週固定時間一起檢視與排序，會上只做三件事——確認新議題的嚴重度、更新進行中議題的狀態、決定下一批的順序；緊急議題另有通報方式與聯絡人，並且講清楚「緊急」的定義與可聯絡的時段，避免下班後的每一通電話都變成例外。避免每發現一件事就立刻打電話，那會打斷開發節奏，最後反而拖慢所有議題。
回報之後：狀態、時效與確認
一個議題的完整生命週期應該包含這幾個狀態：已回報、已確認可重現、處理中、已修復待驗證、已關閉。其中最容易被忽略的是待驗證這一段——修好了要由回報的人實際操作確認，而不是廠商說修好就關閉。
驗證時有兩件事要做：確認原本的現象消失，以及確認周邊功能沒有被改壞。第二件事很常被跳過，但修改一處造成另一處出問題並不罕見，尤其在系統各部分關聯緊密的時候。這也是自動化測試的價值所在，相關概念可以看自動化測試是什麼。
常見的無效回報與改寫方式
實務上最常見的幾種無效回報，改寫方式其實不難：
- 「系統很慢」→ 改成「後台訂單列表頁，篩選日期範圍後載入超過十秒，其他頁面正常，時間是今天上午十點左右」。
- 「客人說他訂單不見了」→ 改成「客人帳號 xxx 於某日下的訂單，在會員中心訂單列表看不到，但後台查得到，附截圖」。
- 「這個功能很難用」→ 這不是缺陷回報，改成需求建議，並說明使用者在哪一步卡住、卡住的原因。
- 「全部都跑掉了」→ 拆成個別議題分別回報，一則回報只講一個現象。
最後這一項特別重要：一則回報只講一件事。把五個現象寫在同一則裡，狀態就無法追蹤——修好三個算不算修好？拆開來寫才有辦法各自排序、各自關閉。
保固與維護的界線先講清楚
回報之前值得先確認一件事：目前這個系統處於什麼階段。保固期內的缺陷修正通常包含在原本的合約裡，保固期外則進入維護範圍；而需求變更無論什麼階段都是另外評估的工作。
三者的界線最好在簽約時就寫清楚：保固期多長、涵蓋什麼（一般是缺陷修正，不含新功能與環境變動造成的問題）、維護合約包含哪些服務與回應時效。沒有先講清楚，上線後每一次回報都會夾帶一次歸屬爭論，對雙方都是消耗。
寫得好的回報其實是在替自己節省時間。多花三分鐘描述清楚，往往換回好幾天的等待，也讓合作關係停留在解決問題上，而不是互相證明對錯。
一套能用的回報流程，通常是在系統上線前就談好的，不是出事之後才補。想把回報格式、緊急管道與維護時效一次講定，跟 NETVANA 約個時間談你的系統。我們會依你的系統規模與實際使用情境討論適合的支援方式；軟體服務沒有固定套餐，一律先了解需求再報價，各項服務的內容與交付物可以看軟體服務介紹。
延伸閱讀：合約模式會影響變更怎麼算，看固定報價還是敏捷開發；上線前把該檢查的做完可以減少後續回報量，看網站上線前檢查清單；挑選廠商時該問的支援相關問題，看如何挑選軟體開發公司；同一個地方反覆出問題通常有結構性原因，可以讀技術債是什麼。
