我是 Kota，宇鯨智能的創辦人，從 2021 年開始了一人公司，協助中小企業透過 Data / AI 技術進行數位轉型。

我特別關注想要建立新的服務模式、獲取營收的製造業。這背後需要進行大量的流程再造和數位管理，也需要藉由 AI 技術自動化瓶頸的步驟，這些是我特別擅長的領域。

一開始看起來，只是一個 API 串接需求

這個專案一開始，客戶提出來的需求其實很技術。他希望我們提供 API，讓合作通路可以直接把訂單送進來，再由系統整理資料後建立到既有 ERP。當時已經有一個合作通路，對方有自己的系統與開發資源，因此希望減少 Email、Excel 與人工整理訂單的工作，把原本需要人員轉錄的資料直接透過系統介接。從這個描述來看，專案很容易被理解成一個系統整合工作：外部平台提供訂單，我們定義 API 與資料格式，把商品、數量、圖片與客戶資訊轉成 ERP 可以接受的內容，再處理 Token、欄位 Mapping 與建單結果。

在這個案子裡，我的功能更多 PM、較少工程。我的工作主要是理解製造商想發展的商業模式、整理合作方式、確認現場流程，以及把客戶提出的需求轉成可以繼續討論的問題與優先順序。工程師則負責產品開發，除了實際實作功能，也會確認需求能不能形成穩定的系統規則，以及目前的做法對後續架構會產生什麼影響。

所以前期的討論確實從 API 規格開始。哪些欄位由通路提供、哪些資料由製造商補上、商品代碼怎麼對應 ERP、圖片要怎麼傳，以及訂單建立完成後如何通知對方，這些都是當下需要確認的內容。從 PM 的角度，我比較常帶著客戶的合作方式與現場條件進來，希望先確保功能能支援實際的商業流程；工程師則會繼續追問，這些需求如果真的寫進產品裡，能不能成為可長期維護的規則。

工程師先確認的，是這套系統到底屬於誰

隨著 API 開始往下拆，工程師先問了一個比較上游的問題：這套接單系統到底屬於誰？他想確認的是，這是一套由我們提供、製造商租用的 SaaS，還是製造商自己的系統，只是由我們代管。這個差異會影響後續架構，因為如果系統屬於製造商，而且未來會讓外部合作夥伴直接透過 API 發單，它需要承接的責任會比一個內部 Web App 多很多。

工程師接著問，如果今天這個通路可以直接串 API，未來會不會還有第二家、第三家合作夥伴提出相同需求。這個問題讓我開始往回整理，客戶原本規劃這套系統時真正希望建立的是什麼。對我來說，這也是 PM 角色在這個專案裡很重要的一部分：有些問題表面上是在討論技術選項，但要回答之前，需要先回到客戶的商業方向，確認這套系統未來準備服務什麼樣的合作方式。

往回看商業目標，才逐漸看見按需製造

客戶想發展的合作方式，是讓外部品牌、IP 商家或通路把少量、多樣的訂單交進來，由製造商依照事先約定的條件完成生產與後續交付。前端的合作夥伴可以把重心放在商品企劃、設計與銷售，不需要自己擁有製造能力；相同的商品規格也可以搭配不同設計，每次下單的數量不必很大，讓前端有更多測試商品與市場的空間。

沿著這個合作方式繼續往下看，接 API 只是其中一個環節。未來進來的訂單可能來自不同 IP 公司、電商平台、創作者平台，甚至其他公司的 ERP，而這些合作夥伴的系統能力也不會一樣。有些公司能直接做 API 串接，有些公司可能只適合使用 Web App 或檔案上傳。對製造商而言，真正需要面對的是如何讓這些不同來源的訂單進入工廠，而且新增一個合作通路時，不需要重新增加大量人工整理與溝通。

這也是我們逐漸把這件事情理解成按需製造的原因。少量多樣本身只是其中一個條件，接單與溝通方式也必須一起改變。如果每增加一個合作通路，都需要重新談資料格式、重新訓練人員，再由業務逐單確認規格、整理附件與輸入 ERP，訂單數量增加之後，行政工作也會一起增加。這樣的流程即使可以生產少量商品，也很難持續承接大量來源不同的小單。

PM 關心合作模式，工程師把它轉成產品問題

從這裡開始，我和工程師看的問題也逐漸分成兩個方向。以 PM 的角色來說，我比較關心的是，如果製造商未來持續增加合作通路，新合作方進入工廠流程時需要付出多少成本，客戶現有的作業方式要改多少，以及哪些條件會影響商業模式能不能持續擴張。

工程師則會把這些商業條件往產品與系統設計繼續拆。誰可以發單、不同合作夥伴如何管理權限、外部 API 是否需要和內部使用者 API 分開、訂單狀態如何回傳，以及合作夥伴如果希望知道生產進度，系統是否需要預留 Webhook，而不是讓外部系統持續 Polling，這些問題都是從前面的商業方向延伸出來的。

這種分工對需求釐清很重要，因為 PM 帶進來的內容通常比較接近「客戶為什麼想這樣做」與「現場怎麼運作」，工程師需要再確認這些描述能不能變成產品可以重複執行的規則。反過來，工程師提出的限制與反例，也會迫使 PM 回頭確認，有些原本看起來合理的需求，到底是客戶真正需要長期保留的做法，還是目前合作情境下暫時形成的習慣。

長期方向開始影響今天的技術選擇

這些問題在只服務一個通路時，其實不一定需要那麼早處理。如果當下只有一個合作夥伴，API 欄位可以直接照對方的格式設計，權限也可以使用比較簡單的方式，一些特殊規則甚至可以先寫在程式裡。但當我們接受未來可能還有其他通路這個前提後，今天做的設計就可能成為下一次整合的基礎。

對 PM 來說，這時候需要先把商業方向與當前範圍切開。未來可能會有更多合作夥伴，這個方向會影響產品需要保留哪些彈性，但它不代表現在就要把所有可能的功能一次做完。工程師也會根據這個方向判斷，哪些地方現在可以先用簡單方案處理，哪些地方如果完全寫死，後續修改成本可能會變得很高。

長期方向確定後，開發仍然跟著當前 Milestone 前進

確認了這個方向之後，我們沒有因此一次把完整的平台全部開發完。工程師一直提醒，如果因為未來可能增加很多合作夥伴，就提前把所有情境都實作好，很容易把時間花在還沒有真正發生的需求上。站在 PM 的角度，當時更重要的還是先把第一個合作通路跑通，確認合作方式、資料流與製造流程真的能夠成立，再決定下一階段要補哪些能力。

因此，後來的開發比較像是在長期方向和當前 Milestone 之間找一個可以前進的位置。Webhook 當時不需要完整做完，但架構上先留下未來回傳狀態的空間；正式的合作夥伴權限機制還沒完成之前，可以先用較簡單的方式讓 API 測通，再逐步補上正式的權限與 Token 機制。Web App 也沒有因為第一個通路可以直接串 API 就被取消，因為製造商對市場的觀察是，未來很多合作通路未必有自己的開發團隊，檔案上傳或 Web 介面仍然會是必要的入口。

這些取捨不完全是技術判斷，也不完全是 PM 排時程。比較接近的是，PM 先把目前要驗證的商業假設與優先順序說清楚，工程師再根據產品現況判斷，哪些結構值得現在保留，哪些功能可以延後。兩邊都需要避免把還沒有確認的未來需求做得太完整，也要避免為了快速完成眼前功能，把後續已經看得到的擴充方向完全封死。

這次需求釐清最後確定的方向

回頭看，這個專案最早的需求其實一直都是真的：客戶確實需要接 API。只是隨著我們把 API 要承接的訂單、合作對象與後續流程逐步拆開，才比較清楚這個技術需求位在整個商業模式的哪一個位置。當初如果只完成「通路可以透過 API 建立 ERP 訂單」，第一個合作案例也許可以運作；如果製造商接下來希望持續增加品牌與通路，系統就還需要處理不同合作夥伴如何進入、哪些規則可以共用，以及每一次新的整合需要增加多少額外工作。

前期幾次討論之後，我們先確定了一個方向：系統需要替不同合作方式留下擴充空間，但眼前的開發仍然先用第一個真實合作案例驗證。對我這個 PM 角色來說，需要持續確認客戶想發展的商業模式有沒有改變、現場又多了哪些限制，以及哪些需求已經足夠明確，可以進入開發；工程師則持續把這些資訊轉成產品規則，並在每一次實作前確認，現在的做法會不會讓後面的產品越來越難維護。

當這個方向確定之後，下一個問題也開始變得具體。未來不同合作夥伴的商品資料、訂單格式與系統能力都可能不同，如果平台每增加一家通路就跟著新增一套規則，維運成本會持續增加；但如果一開始就要求所有合作夥伴完全配合相同格式，也可能讓新的合作變得很難開始。接下來需要釐清的，就是平台應該吸收哪些差異，又有哪些資訊值得逐漸形成共同標準。

有興趣知道更多的，也歡迎和我聯繫交流( kota@yujing.io )！