但是……誰來寫規格？#

規格文件的品質取決於由誰來撰寫。本章回顧 Program Manager（PM）角色的歷史演變，以及這個角色在規格撰寫與團隊協作中的定位。

歷史脈絡：Program Manager 的誕生#

1980 年代的 Microsoft 受到 Fred Brooks《人月神話》（The Mythical Man-Month）的啟發，認識到大型軟體專案需要一個統籌設計的角色。Charles Simonyi 提出了「Master Programmer」的概念，後來演化為 Program Manager 這個職位。

Program Manager 的職責#

PM 是產品設計的核心驅動者，主要工作包括：

• 蒐集需求：從使用者、客戶、業務團隊等各方獲取需求
• 定義功能：決定產品要做什麼、不做什麼
• 撰寫規格：將需求轉化為詳細的功能規格文件
• 協調各方：作為技術團隊與其他部門之間的橋樑

PM 的角色本質上是一座橋——連接工程師的技術思維與商業、設計、市場等非技術領域的需求。

如何挑選 PM#

兩個常見的錯誤做法：

• 將優秀的工程師升為 PM：工程師擅長的是技術實作，不一定具備產品設計與跨部門溝通的能力
• 從行銷部門調人當 PM：行銷人員可能缺乏足夠的技術理解，無法與工程師有效對話

理想的 PM 需要同時具備兩種特質：

• 魅力與溝通力：能說服不同部門的人接受設計方案，能在會議中有效推動共識
• 技術知識：對技術有足夠的理解，能與工程師進行有意義的討論，不會提出技術上不可行的需求

管理動態與權力關係#

PM 不應該擁有對工程師的直接管理權限。當 PM 能直接指揮工程師時，規格文件就失去了存在的意義——因為 PM 可以隨時口頭改需求，工程師也無法挑戰設計決策。