專案的挑戰，不在技術，而在「不確定性管理」
許多 專案失敗的原因，並不是技術力不夠，而是團隊無法在「資訊不完整、時程緊迫、跨部門溝通不清」的環境下快速決策。
PM 真正的價值，往往不是「把事情做對」，而是「在沒有人知道什麼是對的時候，仍然推得動團隊」。
這場 POC 教會我——
成功的專案，不是建立在一切確定之上，而是建立在混亂中仍能行動的勇氣與判斷。
從慌亂到協作，一場真實的 POC 試煉
我還記得那天早上，剛泡好的咖啡還沒喝一口，Line 的通知聲就接連響起。
那時我還不知道，這一則訊息，會讓我接下來整整一個月的生活天翻地覆。
意外的任務
老闆興奮的說:「我跟美國電腦大廠談到一個合作耶！他們願意借我們 server 跟軟體平台，讓我們做 PoC，還能和政府單位合作！」
我愣了一下。
大好機會、國際合作、PoC 聽起來都很美好，但我腦中浮現的第一個問題是：
「我們真的準備好了嗎？」
現實是殘酷的。
產品正在改版、AI 引擎剛重構、對方的平台我們完全沒碰過。 我腦中閃過所有最糟的畫面：時間不夠、部署出錯、合作信任崩壞。
那天晚上，我在筆記上寫下一句話：
「不要追求完美，只要能運作。」
重新定義「可行」
我召集 RD 團隊，大家圍著白板開了一場戰略會議。
「PoC 必須讓對方看到什麼？」
「哪些功能可以先 mock？」 「展示結果要怎麼包裝？」
我們一步步拆解，把不可能分割成可行的小段落。
白板被擦得發亮，螢幕被夜光映得發白。 我們沒把握會成功，但至少，我們願意一起試。
還沒準備好，就得上場
進度剛有眉目，老闆又在週會上宣布：
「對方很喜歡我們的概念，想先拿現有產品去安裝測試看看！」
我腦中只剩一句：「蛤？我們還沒準備好啊！」
但時間不會等人。
我們立刻進入連夜測試模式。每一次報錯、每一次重啟，都是倒數的心跳聲。
令人意外的是，對方雖然口音濃厚、語速極快，卻出奇地好溝通。最終，他們在自己的環境中順利部署，我們交出了第一份成績單。
那一晚，團隊在聊天室裡刷了一排 🎉 emoji。
短暫的勝利，卻只是更大挑戰的開端。
政府單位的內網地獄
接下來要面對的，是政府單位的 PoC。
那是完全封閉的內網環境，而我們的系統卻需要連外下載映像檔。
這意味著——我們得在無法連網的情況下，完成安裝與測試。
我們嘗試模擬政府網路環境、手動儲存映像檔、反覆測試、修正腳本。
每次卡關都要跨部門開會、歸納可能的 bug、找出 workaround。 幾乎每天都在 debug 與重試的循環裡打轉。
終於，在無數個深夜後，我們在公司內部成功重現了政府的部署環境。
螢幕出現「Deployment completed successfully」的那一刻，我幾乎要落淚。
面對不確定性，PM 可以這樣做
這次 POC 讓我學到三件事，也成了我之後帶專案的原則：
原則說明實際作法
1. 明確定義「可行」而非「完美」在時間緊迫時，先確認「能展示的最小價值」用 MVP 框架列出：最少功能、最小成果、最早可交付版本
2. 將未知變成具體問題面對不熟悉的技術時，不要焦慮於「不會」，而是列出「哪裡不確定」以問題樹（Issue Tree）方式分層分析：部署、環境、相依性、權限
3. 維持團隊節奏感不確定時最容易產生焦慮與混亂，PM 要穩定節奏每天固定 stand-up、與開發夥伴們同步狀態、每週更新進度
結語
回頭看，那場 POC 不只是技術挑戰，更是一場「心理韌性訓練」。
PM 的價值，不是等所有人都準備好再出發，而是讓團隊在未知中仍能前進。
我想起那杯早已冷掉的咖啡。
那時的我，確實還沒準備好。 但有時候—— 最好的準備，就是開始行動。
