今天想暫時跳脫工具系統開發本身的討論，回頭看一下這個專案從kick off至今，我跟工程師之間合作方式的演變。

專案剛開始的時候，我就是很典型的專案負責人。業務團隊提出需求，我負責把這些需求整理、歸納，再把商務語言轉譯成工程師可以理解的技術需求。我會在 Jira 上開ticket，把需求逐項列清楚，再跟工程師討論這個工具的系統架構、功能怎麼設計，以及實際上要怎麼建置。

那時候我的定位比較像是兩個世界之間的橋樑。一邊是業務團隊，他們會告訴我「我們希望有什麼樣的功能」、「期待這個工具可以達成什麼效益」；另一邊是工程師，會拋出一些我可能無法自己想到的問題：這個資料之後會怎麼被使用？這個功能未來還有增加使用情境的可能嗎？如果是的話，設計是不是要重來、保留一些彈性？

很多時候，正式因為工程師問了這些問題，我才發現自己其實還沒有把需求想清楚。於是需要再做更多功課、或回頭去找業務團隊討論，再次調整開發的需求給工程師。

所以一開始基本上就是我提出需求、工程師負責把它做出來。
但隨著專案的推展，有許多的功能需要同步做測試調整，工程師身上同時也有很多其他的專案。當一個小功能、一個小調整都需要排進工程師的開發工作裡，其實對這個專案來說逐漸變得很不方便，多了許多等待的時間。

於是我們開始想是否有更敏捷彈性的方式可以做開發，有沒有可能部分的功能開發可以交到我手上？

工程師先幫我把開發環境串接好，剛開始讓我可以透過Claude Terminal直接連到 GitHub 上的專案資料夾。後來我也開始使用Claude、Codex等AI coding tools，同樣在branch上進行開發。完成之後，我會 create pull request，讓工程師 review。確認沒有問題之後，由工程師 approve、merge 到 main，再部署到 production。

我的工作逐漸從「描述我要什麼」變成「我自己去把它做出來」。這個階段對我來說其實已經是很大的變化了。以前我看到 GitHub 上的一堆 Code，知道它是程式，但卻覺得極度複雜、認為那不會是我可以碰的東西。沒想到有天我開始可以自己修改、測試，再把一個功能真的送進系統讓工程師review。再到後來，工程師也鼓勵我用AI先檢查一輪Code (因為其實他也是用AI協助做驗證和檢查），於是我開始請AI幫跑測試、檢查修改、在我這端確認沒問題後再交給工程師做final review, 也因此節省更多工程師那端的心力。

就這樣又經過幾輪之後，工程師最後甚至把approval的權限開給了我。現在的流程已經變成，我可以自己在本地端做開發，讓 AI 協助我測試和驗證，確認沒有問題之後，直接 commit、push 到 main。當然工程師在整個流程中還是擔任把控的角色，一旦出現問題，我們也總還是可以roll back到前一個版本。只是回頭看這整個工作流的變化在短短幾個月內發生，還是蠻不可思議的：幾個月前，我還是一個需要把需求整理成 Jira ticket，再交給工程師開發的人。現在，我已經可以獨立對系統進行功能更新。

這個過程也讓我一再思考PM和工程師之間的合作關係，在AI介入之後的轉變。因為AI的賦能，我彷彿擁有零點幾個developer的能力，變得更像是能夠跟工程師肩並肩一起做開發；因為vibe coding過程中的學習，也更理解技術層面的運作，擁有多一些知識基礎可以和工程師做深入一點的系統設計、開發討論，這都讓我覺得自己確實因為AI增能不少。但同時，也有些工作模式的變化需要適應，舉例來說，以往我很習慣直接與人討論問題、進行腦力激盪，但現在似乎與AI先討論才是default；與AI討論之後仍得不出好解方，這個時候才向人類同事求助。雖然這樣確實在許多情境下能節省不少時間，但我可能還是對「這題你問過AI了嗎？」這樣的問題尚不是很適應，仍在一面做著專案，一面緩緩在消化這些合作模式的轉變。對於這樣的轉變沒有好壞的定論，但在整個過程中，老實說偶爾會冒出一些矛盾的感受，感覺自己過往的人文社科腦和新的所學有些奇妙的衝突，這也是在開發專案執行過程中對自己意外的新發現。