很難想象，從九年前創立公司到 2014 年為止，我是公司 ( Oursky ) 裡唯一的專案經理（PM）。隨著我們的團隊逐漸壯大，我需要同步管理 10 個以上的項目和超過 20 個軟體工程師，在 PM 方面開始面臨難題。
問題的起點？
問題始於 Ben 、 Rick 和我一直以來對高品質編碼的堅持。 Ben 以往甚至會仔細檢視每一行程式碼直至滿意為止。組成初期團隊後， Rick 和我成為負責合併 pull requests 的僅有兩人。又因為我們同時是公司內最資深的軟體工程師，理所當然我們也負責了 Quality Assurance。大部分公司只將 PM 視作客戶經理，但我期待 PM 可以跟我一起完成以下各項任務：
- 會見客戶（匯報進度，將客戶期望管理在合理水平）
- 提供產品操作的顧問意見
- 提供技術性建議
- 處理專案有關的行政工作
- 計劃未來的功能特點和可能的改變
- 管理軟體工程師的時程
- 指導工程師構思產品
Ben , Rick 和我以自家產品 Pandaform 作為新創的起點。該產品為我們賺取利潤的同時（幸運地至今仍是），我們開始接受客戶委託的案子。一開始，每位共同創辦人都親力親為跟客戶交涉。當公司發展到一定規模後，我們開始分工。 Ben 出席活動、負責銷售， Rick 成為我們的 CTO ， 我則專 PM 。
我跟我的公司一起成長，卻沒有考慮到自己的極限，以及如何為急速增長做準備。
高峰時期，我需要同步管理 10 個以上的項目和超過 20 個軟體工程師。很明顯這是難以持續的。當時我第一個想法是聘請多一位 PM 來分擔我的工作，但一想到訓練新人需時，便打消念頭強迫自己更有效率地完成工作。終於，我們的產品品質無可避免受到影響。
聘請新 PM 為何沒有長遠解決問題的反思
我們還是開始尋找第二位 PM 。雖然很少應徵者能夠達到我們對技術層面與客戶應對的要求，幸運地我們聘請的第二位 PM 富有經驗也表現亮眼。一切看起來如此順利。直到他決定離開公司自行創業，我們又回到了原點。聘請一位 PM 只是暫時解決我們的問題，可惜我們沒有利用這個機會標準化 PM 流程。
缺乏標準化的流程，在產品預備呈交客戶時才發現問題已經太遲。
累積的經驗讓我們慢慢摸索出一套 PM 的心得。但當更多新人加入公司，我們發現無法快速傳授他們心得或提供指南讓他們跟隨。結果，因為我一人之力應付不來而讓公司無法承接新的生意。換言之，是我局限了公司的發展。
認清事實，我們對 PM 的職務存在過高的期待。
作為香港一家小型的 app 公司，要找到一位符合所有要求的應徵者實在太困難了。現實是，我們無法跟能夠提出優渥條件（而職務要求可能比我們更低）的大機構搶人，所以我們另闢蹊徑 — 投資建立自己的 PM 團隊。部份是直接以 PM 身份聘來，其他則由另外的部門（例如 QA ）轉職。
我們從頭訓練 PM ，讓他們循序漸進掌握實務。
經歷第二位 PM 離去的陣痛後，我著手建立 PM 的訓練流程。目前我們有 5 位 PM 同時管理 16 個活躍專案和 10 個跟進項目。 我們要求所有 PM 對以下範疇有一定的理解： UX 設計、技術知識、產品設計、分析、專案管理、客戶溝通和內部溝通。
所需技巧：
- UX 設計：預視潛在 UX 問題，能獨立學習新的科技（例如把 ARKit iOS 11 應用於 UI 和 UX ）
- 技術知識：能向客戶提供開發時間的粗略估計；基本編碼知識；理解第三方系統整合詳情；能閱讀 API 文件（包括： payment gateway 、第三方服務 API 、認證）
- 產品設計：能指出使用者設計的瑕疵
- 分析：保持一貫且正確地進行假說、實驗到數據周期的運算
- 專案管理：同時管理多個（ 2 – 5 個) 專案而仍能良好地掌控時程、人手和資源分配；預測和追蹤衍生問題
- 客戶溝通：專業的客戶溝通技巧；管理客戶期望值
- 內部溝通：作為團員之間的橋樑；跟進任務；接納反饋和尋找資源
我們的 PM 隨著實戰經驗的累積，提升分析和建議的理解和能力，同時鞏固上述多方面的技巧。
專案助理（ Support PM ）
- 初入職，受指導培訓各項工作
- 參與會議，但不會要求他們主持會議
- 例子：參與客戶會議，跟進客戶電郵（但發送前須經過 Senior PM 檢查）
專案副理（ Associate PM ）
- 重度監督下承擔指定工作
- 主持站立會議（主管 PM 須同時出席）；計劃每週成果報告和承擔日常工作
- 例子：預備客戶會議備忘，管理專案的 Waffle board 和 Basecamp project portal
PM
- 半監督下承擔指定工作
- 假如 PM 已有足夠經驗（例如擁有客戶溝通或專案管理的優秀往績），除非他主動要求，否則不需受監督
- 如涉及重大決策或需要解釋較深奧的技術問題， PM 應要求主管 PM 和軟體工程師一起參與會議以保障溝通品質
資深 PM ( Senior PM )
- 資深 PM 應有足夠能力全面管理手上專案，並由上而下監督各項目進程，確保每個專案均達到公司標準
- 協調不同資源解決其他 PM 匯報的問題
如果時光倒流，我會如何處理這個難題？
如果可以重來一次，我會在達到隊伍最大產值的 70% 前訓練好下一位適任的 PM 。
PM 是客戶專案質量的保證。如果你已接近產值極限，將難以在早期發現潛在問題，意味著開發後期你將耗費更多精力來修正重做。到時候你也無法撥出時間來思考較深層的問題（譬如如何訓練你的 PM 團隊）。你得預算一段長時間訓練直至他們達到你心目中的標準。
今天，我仍然像當初獨力管理 10 個專案時一樣忙碌。但有賴我一手培訓出來的 PM 團隊協助處理大部份日常公務（例如「日常焦點」、客戶報告、審理新功能），我才能騰出時間專心分析公司各階段的表現，包括專案預測或最佳化開發周期等等。將來如有時間，我也樂於和大家分享這些方面的經驗呢！
想更輕鬆地開發 app 嗎？試試我們提供的免費開發者工具 和開源後台程式 。
原文：How I became the PM bottleneck as a founder
中譯版： 「PM World – 全球聲音」創辦人非萬能：兼任專案經理反而局限公司發展
翻譯者：Queenie So
