原文：https://martinfowler.com/articles/products-over-projects.html
如果只有 30 秒，這篇在說什麼？
軟體開發有兩種玩法：一種是「做完就散」的專案模式，一種是「養一支長期隊伍」的產品模式。這篇文章告訴你，為什麼現代軟體團隊應該從「接案思維」轉向「經營產品思維」，以及這樣做能帶來哪些好處。
核心概念拆解
專案模式（Project-Mode）
一句話解釋： 為了完成某個任務而臨時組隊，做完就解散。
生活中的比喻： 就像辦婚禮找的婚禮團隊——攝影師、主持人、廚師各司其職，婚禮結束後大家各回各家，沒有人繼續負責婚後生活。
為什麼重要： 這模式的問題在於，婚禮辦完了，但夫妻倆的生活才剛開始。軟體系統也是——上線只是起點，後續的維護、調整、改善才是真正的挑戰。
產品模式（Product-Mode）
一句話解釋： 組一支長期穩定的團隊，持續負責一個系統從發想、開發到維運的整個生命週期。
生活中的比喻： 就像一家餐廳的固定廚師團隊，不只負責今天的菜單，還要根據客人反饋不斷改良食譜、控制食材品質、調整營業策略。
為什麼重要： 穩定的團隊累積知識、保有脈絡，能快速回應市場變化，不需要每次都從零開始解釋系統歷史。
快速重新定向（Rapid Reorientation）
一句話解釋： 當市場或需求改變時，產品團隊能立刻調整方向，不需要等待漫長的審批流程。
生活中的比喻： 就像開車用導航——路塞了，導航馬上重新規劃。相比之下，專案模式像是出發前就把地圖印好，遇到道路封閉只能乾等。
為什麼重要： 商業環境瞬息萬變，能快速調整的團隊才能在競爭中存活。
真正的迭代（Genuine Iteration）
一句話解釋： 產品模式讓團隊能根據真實使用數據來驗證和調整方向，而不只是靠事前的商業案例拍板。
生活中的比喻： 就像廚師可以讓客人試菜、根據反饋調整口味。專案模式則是廚師做完菜交出去，不管客人喜不喜歡，這道菜就結案了。
為什麼重要： 軟體的價值只有在用戶真正使用後才能驗證，讓真實數據說話比靠預測更可靠。
知識保存（Knowledge Preservation）
一句話解釋： 穩定的團隊能把系統的來龍去脈、踩過的坑都記在腦子裡，不會因為人員流動而流失。
生活中的比喻： 就像一個在同一條街開了二十年的修車師傅，知道哪台車有什麼怪毛病、上次換了什麼零件。換成每個月換一個師傅，每次都得重新熟悉。
為什麼重要： 知識流失是軟體開發中最隱形也最昂貴的成本之一。
最容易搞錯的地方
很多人以為產品模式就是「沒有截止日期、隨便做」……但實際上，產品模式只是把責任從「做完交差」轉移到「持續創造價值」，反而需要更強的自我管理和成果意識。
很多人以為專案模式比較省錢，因為不需要養長期團隊……但實際上，每次重新組隊的溝通成本、交接成本、以及知識流失的隱形代價，往往遠超過維持一支穩定隊伍的費用。
很多人以為產品模式只適合科技公司……但實際上，任何需要長期維護和持續改善軟體系統的組織，不論規模大小或產業，都能從這個思維中受益。
用自己的話說一遍
想像你在蓋一棟房子。專案模式的做法是：請一批工人蓋好，驗收完畢，工人解散，房子交給屋主。之後水管漏水？得重新找人、重新報價、重新解釋房子的結構。
產品模式的做法是：保留一批了解這棟房子的人，他們不只負責蓋，也負責日後的水電維修、裝潢改造、甚至未來的擴建。因為他們一直在，所以知道哪根柱子不能動、哪個牆壁後面藏著管線。
這篇文章的核心主張很清楚：軟體不是蓋完就沒事的建築，它更像一個活的生態系統，需要有人持續照顧。把你的開發組織從「接案公司」思維轉向「產品團隊」思維，你會得到更快的市場反應速度、更少的溝通摩擦、更好的系統品質、以及更有動力的工程師。
當然，轉型不是沒有代價。你得重新思考「效率」的定義——不再是每個專家的使用率最大化，而是整個產品價值的持續交付。你也得接受，穩定的團隊有時會過於封閉，需要刻意引入外部視角。
但整體而言，對於任何把軟體視為核心競爭力的組織來說，產品模式是一個值得認真考慮的方向。
延伸思考
- 如果你的公司同時在用專案模式和產品模式，你會如何決定哪個系統值得建立長期產品團隊、哪個還是用專案模式就好？
- 產品模式強調穩定團隊，但如果市場變化快到連「產品方向」都要大幅轉型時，這種穩定性會不會反而成為包袱？
本文使用費曼學習法整理自原文，建議閱讀原文獲得完整資訊。