他說沒人能幫忙，事情卻一直留在他手上

朋友公司的那位 RD 主管，只要談到客戶，就很沒有耐心。

他覺得很煩，也覺得沒有人能幫忙。可是客戶目前走到哪裡、答應過什麼、下一步在等誰，也沒有好好留下來。

我聽著，想到的不是再找一個人，站在他和客戶中間傳話。

因為我們自己，也正在讓工程師更直接面對客戶。

靠近客戶，是我們想走的方向

以前，需求可能從業務到 PM、客服，再到開發。這樣的分工不是沒有道理，但我們走過之後，感受到的是時間長、成本高，還有一種很累的循環。

事情沒做好，討論很容易停在前面沒問清楚、需求沒整理好，或後面沒有理解。每個部門都有理由，客戶的問題卻還在。

所以現在，在 AI 的協助下，我們走向 FDE，也就是讓工程師更靠近客戶現場的工作方式。直接理解問題、確認限制，再把做出來的東西放回實際使用情境裡看。

Google 的 DORA 指引也建議讓開發與維運人員直接交談、觀察客戶。這讓我覺得，我們想縮短的，不只是開會時間，而是問題和解決之間的距離。

但我也知道，距離變短，不代表事情就會自己變順。

小公司的預算，養不起每次從頭來過

我是在 Facebook 的這支影片裡，看到 Walmart 和 Kmart 的比較。它讓我想到的，不只是誰贏了，而是原本被認為做不起來的生意，有沒有可能換一種做法。

若影片無法直接播放，可以到 Facebook 看原影片。

魯梅特在《好戰略，壞戰略》裡談到，原本被認為不足以支撐大型折扣店的小鎮，放進共同運作的門店網絡後，就有了不同的可能。單店服務當地顧客，背後的配送、資訊與管理，不必每家各自從頭建立。

Walmart 的 1985 年報也能看到它從小鎮發展，以及配送網絡的角色。讓我有感的，不只是它把價格壓低，而是它改了做生意的方法。

大型專案可能有預算，也確實需要完整分工。但如果服務的是小公司，不能只是把報價縮小，做事的方法卻完全照舊。

每個客戶都重新理解、重新串接、重新救火，最後不是客戶付不起，就是我們少收了錢，卻用更多人的時間去補。

我希望留下來的，是下一次能沿用的工具、測試和處理方法。共用的是能力，不是把不同客戶的資料混在一起。

這也是為什麼，朋友那位主管的困境，讓我不能只用一句「做好交接」帶過。

「我自己弄一弄比較快」之後呢？

自己處理，有時候真的比較快。

尤其問題看起來不大，補個設定、改一段程式，就能讓客戶繼續工作。要再開工單、解釋背景、整理紀錄，眼前反而多了事情。

如果站在那位 RD 主管的位置，我能理解那種疲累：交給別人，要先講一遍背景，最後可能還是自己檢查。站在工程師的位置，需求一直變，交期卻沒變，原來的系統也不能壞。這時候再聽到「你要更懂客戶」，很容易覺得，又多了一件要自己扛的事。

但這也連到我前幾天寫的〈AI 寫完了，但那不是我想說的〉：產出有了，不代表真正想解決的問題被理解了。

我認為，即使在大公司，RD 也需要往更靠近現場、理解問題的方向走。不一定每個人都改叫 FDE，更不是人人兼做業務與客服。但如果工作只剩照著別人給的文件產出程式，其中一些事情，AI 可能已經做得更快。人的經驗，應該用來發現文件沒寫出的限制、判斷哪些要求不該直接照做，還有讓產品之後能繼續改得動。

這不是一句「工程師要轉型」就能交代過去。公司也要給工具、時間和決策支援，不能要求他靠近客戶，卻把後面的整理與風險全留給他。

可是一段時間累積下來，文件裡的產品，和客戶真正用的產品，可能已經不是同一個樣子。

客戶搞定了，大家鬆一口氣。但多花了多少時間、哪些是追加的工作、哪些是原本就該修好的問題，報表不一定看得出來。案子表面上結束了，後續支援還在吃掉時間。

如果客戶沒搞定，就更難受。客戶記得的承諾、工程師理解的範圍，可能各有一套。等到有爭議，才回頭找當初怎麼說，甚至面對訴訟風險，就不是補一份會議紀錄能解決的。

我在意的不是他多幫了客戶，而是這些付出，有沒有被看見、被確認。

不要等他回來，才開始整理

我會建議朋友，讓工具從對話發生的時候就開始幫忙。

例如，先取得客戶同意，說清楚用途、誰能存取與保存多久，再由合適的工具錄音、轉錄。不適合錄音的場合，就用共同筆記。

但如果還要他回公司，手動上傳、下指令、複製到另一份文件，這件事很可能又被排到最後。

我比較想嘗試的是：會議結束後，自動把摘要接到對應的客戶和工作項目。讓他確認的，不是一大篇逐字稿，而是幾個重要的地方：客戶要完成什麼、我們答應了什麼、哪些還沒決定、下一步誰處理。

AI 可以先整理，不能替我們答應。討論過，不等於已確認；客戶沒回覆，也不能自動算同意。涉及範圍、費用和期限，仍要有人確認，並讓客戶看見同一份理解。

這些是我建議朋友嘗試的方向，不是換一個錄音工具就全部完成了。

也從工程師本來就在用的地方看

我也建議把 Git、工單和部署紀錄，當成觀察與稽核的節點。

Git 留下程式修改的歷程。如果一筆修改能連回客戶的要求和工單，就不用請工程師把同一件事再抄一次。AI 也比較有機會提醒：這裡有修改，卻沒有對應需求；原本說是小修，範圍卻一直增加；工單寫完成了，實際還沒部署或驗證。

我希望看見的是落差，不是提交次數排行榜。

Git 不會告訴我們客戶有沒有同意追加，也不能拿幾次提交換算成工時。設定調整、資料修復、電話支援，也未必都在裡面。投入時間需要簡短確認，承諾需要客戶核對，交付則要看實際使用結果。

工具把線索接起來，人再處理重要的判斷。緊急問題可以先處理，留下最小紀錄，再補確認；牽涉新增費用或承諾，就不能只靠一句「先幫他弄好」。

當然，這些提醒出現之後，也要真的有人接手、有時間處理、有權限決定。否則系統只是多了一張清單，壓力仍在原來的人身上。

朋友公司的這段故事，也讓我回頭看我們自己。

讓 RD 直接面對客戶，是希望事情更快被理解，不是把理解、開發、支援和所有人的記憶，全壓在同一個人身上。

我希望他為客戶多做的事情，能被團隊看見，也能留下來，讓下一個人接得下去。

不要事情做成了，公司不知道代價；事情沒做成，才發現連當初怎麼說的，都找不到了。

---

延伸參考：Google DORA：團隊實驗與直接理解客戶・Walmart 1985 年報：小鎮與配送網絡・Richard Rumelt《好戰略，壞戰略》