本系列取材自真實經歷，人物、場景、對話與時間順序經過合成與小說化處理。

晚上八點，我照例到住家附近的超市買打折便當。熟食櫃裡的雞腿已經賣完，剩下排骨和炒麵，我看了一下價格，拿了排骨便當就去結帳。鄉民把我叫作乞丐超人。

買完便當回到社區，夜班保全正在櫃台後面看交接簿。我們平常見面會點頭打招呼，有包裹才多聊幾句。

那天我經過管理室，發現他的桌上放著一台筆電，螢幕上開著編輯器和終端機。因為我自己也是工程師，所以走到電梯前，又回頭問他是不是在寫程式。

管理室裡的保全，也是美國新創的 CTO

保全抬頭回答：「對，在做公司的東西。」我原本以為是保全公司的系統，繼續問了才知道，他說的是一家美國新創。

這就讓我有興趣了。我問他：「你是接他們的案子，還是已經在那間公司工作？」

他解釋，最早是以 contractor 的身分承接工作，後來成為共同創辦人，現在主要負責技術。我聽完再確認一次：「所以，你現在是那間公司的 CTO？」他點頭說是，然後把交接簿裡還沒看完的那一行讀完。

我看著他的筆電，又看了一下管理室。一個在台灣社區值夜班的人，同時參與美國新創、擔任 CTO，這中間到底怎麼接起來，我實在很想知道，便問他為什麼還在這裡值班。他說這要從前面的經歷講起，正準備說明，住戶就進來領包裹了。

來的是許小姐。她背著包，低頭看手機上的通知，跟保全說應該有兩件，其中一件昨天就到了。保全先查看領件紀錄，再到後面的架子找出一大一小兩個包裹，請她核對、簽收。許小姐把小件塞進袋子，抱起另一箱，道了聲謝就往電梯走。

我在櫃台旁等他把領取紀錄補完，才接著說：「你有空的時候，可以跟我聊聊美國新創嗎？我想知道怎麼接到那邊的工作，還有怎麼從 contractor 變成共同創辦人。」

保全問我是不是也寫程式。我說是，他便答應有空可以聊。我順口回了一句：「好，那我叫你師父。」他笑著說不用這麼正式，先問我想知道什麼。

那天的第一個問題，是對方怎麼決定要跟他合作。我們都會寫程式，但把履歷寄到一家不認識自己的美國公司，和真的拿到一份工作，中間還有不少事情。

美國新創怎麼判斷一個陌生工程師能不能接工作？

我問師父：「他們一開始不認識你，也沒跟你共事過，怎麼敢把工作交給你？是看履歷、作品，還是 GitHub？」

師父說，這些資料都能幫助對方了解一個人，但要先看對方需要完成什麼工作。履歷列了很多技術，或者 GitHub 放了很多專案，對方仍然要花時間判斷：哪些是你實際做的、做到什麼程度，以及和眼前的需求有什麼關係。

他反過來問我：「假設你現在要找人幫忙，看到一個人的 GitHub 有二十個 repo，你會從第一個開始全部看完嗎？」

我回答：「應該會先挑和需求有關的，再看他在裡面做了什麼。如果剛好很忙，可能就先看 README。」

師父接著說，如果對方打開專案，連它能做什麼、怎麼執行、執行後要看什麼結果都不清楚，就得再花時間詢問。能把這些內容交代好，至少讓對方比較容易進行評估。作品的用途、自己的貢獻和完成程度，都應該接得起來。

這個說法對工程師應該不難理解。我們接手別人的程式時，也需要知道它怎麼啟動、輸入和輸出是什麼、目前有哪些限制。同樣的資訊放在合作之前，也能幫助對方判斷這個人是否適合眼前的工作。

不過，我還是問師父：「文件寫得很清楚，也可能只是很會寫文件啊。最後還是要看他能不能做出來吧？」

師父同意。他說，前面的說明讓對方知道該看什麼，接著還要有能檢查的成果。至於要準備哪種成果，最好用一個具體工作來討論，才不會一直停在「要有作品」這句話上。

用訂單 CSV 報表說明交付與驗收

師父舉了一個假設案例：某家公司每週會匯出訂單 CSV，希望做一個小工具，整理各項商品的銷售數量。我們就用這個案例，討論一個工程師應該交代哪些內容。

我先從實作角度回答，要拿到資料樣本，確認欄位、商品編號，以及對方說的銷售數量是訂單筆數還是商品件數。取消的訂單怎麼處理，也要先約定。這些定義沒有講清楚，程式即使跑得動，產生的報表還是可能和對方預期不同。

師父聽完說：「你剛才問的那些問題，就可以讓對方知道你準備怎麼處理。接下來，再把這次預計做到哪裡講清楚。例如先接受一種固定格式，只計算雙方約定範圍內的訂單，輸出每項商品的銷售件數。」

他接著解釋，完成小工具後，可以附上一份測試資料和預期結果，讓對方照著操作一次。對方可以手算，也可以和原本的報表核對，確認資料有沒有被正確處理。假如只是給一張結果截圖，對方就還不知道換一份資料會發生什麼事，也不知道自己能不能操作。

我問師父：「所以要一起交操作方式和測試資料？那還沒支援的部分呢？」

師父回答：「也要說。例如這一版先不處理退貨，資料缺少商品編號時會提示，就先交代清楚。對方才知道目前可以拿它做什麼，哪些事情還要另外討論。」

把師父這個例子整理一下，一份能讓對方評估的交付，至少要交代三件事：

1. 這次完成什麼。 接受哪一種訂單資料、如何計算、最後產出什麼報表，雙方要有共同理解。
2. 對方怎麼確認結果。 提供操作方式、測試資料與預期結果，讓對方可以自己檢查。
3. 目前有哪些限制。 哪些資料會被拒絕、哪些功能尚未支援，以及遇到問題時如何回報，都要交代。

這三件事連在一起，對方才有足夠資訊判斷成果能不能使用。如果規格、操作方式或限制有一項沒說清楚，後續合作就容易卡在不同的預期上。

我也提醒師父，有些工作卡住是因為客戶一直不提供資料，或者需求反覆修改。師父說，這些也要記錄、確認，讓對方知道目前缺什麼，以及會影響哪一段工作。工程師要評估合作對象願不願意一起釐清問題，責任也需要雙方約定。

我們談到這裡，有住戶推門進來。師父抬頭打招呼，看對方直接走向電梯，才繼續說明。他提到，最初以 contractor 身分合作時，對方會從一次次交付中了解他的做事方式。工作有沒有完成、卡住時有沒有說明、交出去的東西能不能接手，都是合作過程中看得見的事情。

第一堂課：把能力轉成對方能確認的成果

我問師父：「所以先把一份小工作做好，之後就比較有機會接到更大的工作？」

師父說，有過合作經驗，對方確實比較有資料可以判斷，但下一份工作還是要看公司需要什麼、自己有沒有能力承接。他當時從 contractor 走到共同創辦人的過程，也有不同階段，不能只用「小工作做好就會升級」來解釋。

我接著問，現在有 CTO 這個職稱，是不是比較容易讓對方願意聽。師父沒有否認職稱的幫助，但也補了一句：「人家還是會問你負責過什麼。CTO 三個字不夠。」

這就是我們第一天談的重點：當對方開始評估合作，你要能說明自己可以完成什麼、如何檢查成果，以及會負責到哪裡。 履歷、作品和職稱提供了認識你的入口，實際的工作內容則讓對方有辦法繼續問下去。

以訂單報表這個例子來說，從一句「我會處理 CSV」，到能說明資料格式、計算定義、驗收方式和功能限制，對方能取得的資訊就差很多。對一個正在找人解決問題的小團隊而言，這些內容也能幫助他們判斷，下一步要怎麼和你合作。

我還想追問，美國公司最初到底是怎麼找到他的。不過這時櫃台電話響了，師父先接起來，拿紙筆記下住戶交代的事情。

我等他放下電話，他看了一眼我手上的袋子，叫我先回去吃飯，這個問題等下次有空再聊。

我跟師父道別，順口說明天見。他笑著提醒我：「明天我休。下次再聊」。

我這才提著便當往電梯走，讓他回頭處理剛才接到的事情。

感恩師父、讚嘆師父。