每個人都完成了工作，為什麼整件事還是做錯了？

產品服務驗收時，PM 說需求完成了，工程師說開發完成了，QA 也確認測試通過了。從專案管理的角度看，一切順利。

但我當下有點 emo，心裡忍不住想：

這個功能，真的解決了我們原本想解決的問題嗎？

答案是，可能沒有。

真正讓我在意的，不是功能做錯

讓我在意的不是某個功能做錯了，而是這個專案從需求討論、規劃到開發，每個環節都有人負責，每個人也都很努力完成自己的工作，卻始終沒有人及時發現：整件事可能走錯了方向。

回頭檢討時，都有合理的解釋：

• 「當初需求沒有這樣寫。」
• 「這是前面交接過來的。」
• 「系統本來就有這個限制。」

這些說法可能都是真的。但問題在於，當每個環節都按照既定流程運作，最後卻沒有解決問題，我們就不能只把它當成單一環節的失誤。它反映的，可能是整個團隊的工作方式。

我原本想錯的地方

復盤這件事時，我也開始反省自己的管理方式。

我習慣快速分析問題、辨識風險，再找出可能的解決方案。這樣的工作方式確實能讓很多事情更有效率。但有個問題我一直沒正視：

我能看見問題，不代表團隊已經學會如何發現問題。

如果主管總是在第一時間指出問題、提供答案，短期或許能加快進度，但長期下來，團隊也可能逐漸習慣等待主管的判斷。等到主管沒看到的時候，就沒有人看到了。

可以從三件事開始改

① 開發前，先定義成功的樣子。

過去討論需求，很容易聚焦在「要做什麼功能」。但真正應該先確認的，是「我們希望改善什麼結果」。

舉例來說，需求不應該只是「新增匯出報表功能」，而應該進一步定義成：「讓原本需要兩小時的資料整理，目標縮短到十分鐘。」

兩句話看起來差不多，想的事情完全不同。前者看功能有沒有做完，後者看問題有沒有變好。先講清楚成功長什麼樣子，團隊最後才知道要驗什麼。

② 開發前，先讓使用者走一次流程。

驗證需求不一定需要一套完整的系統。一張流程圖、一個簡單的 Prototype，就能讓使用者提前確認實際情境，尤其是那些容易被忽略的例外狀況。

正常流程能順利運作，不代表整個設計就沒問題。取消、變更、資料不一致，這些往往才是真正考驗系統的地方。如果能在開發前發現問題，修正成本通常遠低於功能完成後才重新設計。

③ 驗收時，分清楚「功能正確」與「問題解決」。

QA 確認功能符合規格，是必要的技術驗證。但符合規格，不代表解決了客戶的問題。所以驗收時，還需要 PM、需求單位與使用者一起確認：這個功能，是否真的讓使用者完成原本想做的事情？

至於效率、錯誤率和使用行為有沒有改善，則需要上線後持續追蹤。

功能通過測試，是技術驗證；問題獲得改善，才是業務成果。

我想要的團隊

回到管理本身，我本來就不期待團隊永遠不犯錯（畢竟我自己也每天在犯錯）。也不認為每個決定都能在一開始就找到正確答案（人生不也是如此？）。

但我希望團隊能更早辨識問題，也願意主動提出不同意見。而我自己要調整的，可能是別太快給答案，這點我也從老闆身上學到不少。讓同事先說明自己的判斷、看到的風險，以及建議的做法。

我想帶出來的，不是凡事都要主管點頭的團隊，而是主管不在場，也能做出好判斷的團隊。

最後

好的團隊，不是每個人把自己的事做完就好，而是有人願意多想一步，確認大家在做對的事。

有時候，一個專案最有價值的貢獻，不是有人宣布「完成了！」，而是有人在過程中說：

「等一下，我們是不是搞錯問題了？」

這句話當下或許有點掃興，卻可能替整個團隊省下好幾週的時間。