這個案子做完，下一次會容易一點嗎？

最近看了幾段影片，一開始覺得它們在談不同的事。

奶昔／顧客雇用理論，提醒我看客戶要完成的工作。沃爾瑪／戰略支點，讓我想到成本背後互相支撐的做法。MVP 把注意力拉回驗證，伯利恆鋼鐵／資源配置 則讓我想，眼前合理的安排，會不會一直擠掉未來的機會。

討論到後來，我覺得它們在我們的專案裡接起來了。

客戶的工作沒有看清楚，可能做出很多他用不上的功能。需要還沒驗證，就可能投入太早。每次交付都重新開始，成本就難以改善。即使知道該整理，也可能因為下一個案子比較急，一直沒有時間。

這是我從幾段影片延伸出來的問題，不是它們替 metabiz 下的結論。

我最想留下的，是每次完成一件工作時，除了看眼前有沒有交付，也看看我們是不是更知道，下次該怎麼做。

我想先挑幾個已完成、也確認收款的案子，做一次具體的回顧。

先用已有的交付紀錄、支援工單與款項資料，整理出一份初步回顧，再請交付與財務的人補上缺口。沒有工時紀錄的地方就留下限制，不替它編一個數字。

和客戶確認時，也不需要先丟給他一張成效問卷。可以由我們挑一段原本要改善的工作，把可核對的前後情況整理好，請他確認是否符合實際，以及還有哪些地方不好用。不是急著寫成成功案例，而是先知道這幾個案子真的留下了什麼。

這些資料不在我一個人手上，也不是看完報價就能補出來。所以需要做過這段工作的人一起確認，不能只由我或 AI 寫一個完整結論。

如果你也做過不少專案，下一案卻仍然要重新問、重新做，這次回顧可以先從其中一段重複工作開始。

一個專案結束，最直接的問題是，答應的事情有沒有完成。

客戶能不能使用，還有哪些地方需要修正，接下來誰負責維護。這些都不能少。

最近把幾段影片放在一起想，我又多了一個問題：做完這次之後，下一次會不會比較容易？

它聽起來很簡單，卻未必能很快回答。

程式留下了，文件也有了，不代表下一位同事就接得下去。有時真正重要的判斷，仍然只有做過的人知道。遇到例外該怎麼處理，為什麼當初沒有選另一種方法，文件裡不一定看得出來。

下一個案子來了，如果仍然要找同一個人，再問一遍、再確認一遍，那些東西雖然留下了，工作卻還沒有真正變得容易交接。

這也是 metabiz 想替企業處理的事情：把會做事的方法留下來，讓下一個人有機會接住。

我想，我們自己也需要用同樣的標準回頭看。

上一個案子問清楚的資料，下一個能不能更早確認？上次發現的錯誤，有沒有變成這次交付前就會做的測試？某個共用模組真的省了時間，還是換了一個客戶，又要改很多地方？

可以留下來的，也包括怎麼幫客戶看清問題。哪些資訊我們能先查，什麼示範讓對方容易理解，哪些例外要特別確認。下一次有了這些經驗，就不用把同一串抽象問題重新問一遍。

但它們應該幫助我們更快提出可核對的方向，不是讓我們套上模板，就認定每個客戶的問題都一樣。

這些不能只靠感覺。要看實際花了多少時間、返工在哪裡、後續支援需要做什麼。

也不是每件東西都可以拿去用在另一個客戶身上。

客戶的資料、專屬規則與經驗，有它的界線。可以留下的通用方法、工程能力和驗證流程，和不能跨界使用的內容，要分清楚。

我也不認為每個專案都得變成產品，才值得做。

有些案子支撐公司運作，有些讓我們學會處理更難的工作。只要知道為什麼做，也看清楚代價，都可以有價值。

但如果每次都說這次很特殊，最後卻沒有任何一段變得比較成熟，那就值得停下來看。

前幾篇談的事情，在這裡慢慢接在一起。

幫客戶一起看清要完成的工作，才不會只留下更多功能。由我們協助設計驗證，才不會一直往未確認的需求投入。整理與交付的方法逐漸成熟，才有機會減少成本。資源安排也要替這些改善留位置，否則再重要的整理，都會被下一個急案往後推。

我想先從幾個真的完成、也確認收款的案子開始看。

不急著整理成成功案例，先把客戶得到的改變、我們實際的投入，以及還需要人補救的地方放在一起。

也許看完後，會發現有些原本很有信心的地方，還需要補證據。也可能發現，一個沒有那麼顯眼的小方法，才是下一案最值得留下來的東西。

我希望結案時，我們除了確認這次答應的工作，也能慢慢回答兩個問題。

客戶哪件事變好了？

我們下一次哪件事，會更容易一點？

— Adam｜metabiz 創辦人

延伸參考：顧客雇用理論・MVP・戰略支點・資源配置

本篇提到的四段原片：