Original Article: How I became the PM bottleneck as a founder
作者：Roy Yuen, Oursky 創辦人
翻譯者：Queenie So
)裡唯一的專案經理（PM）。隨著我們的團隊逐漸壯大，我需要同步管理10個以上的項目和超過20個軟體工程師，在PM方面開始面臨難題。
問題的起點？
和我一直以來對高品質編碼的堅持。Ben以往甚至會仔細檢視每一行程式碼直至滿意為止。組成初期團隊後，Rick和我成為負責合併pull requests的僅有兩人。又因為我們同時是公司內最資深的軟體工程師，理所當然我們也負責了Quality Assurance。大部分公司只將PM視作客戶經理，但我期待PM可以跟我一起完成以下各項任務：
- 會見客戶（匯報進度，將客戶期望管理在合理水平）
- 提供產品操作的顧問意見
- 提供技術性建議
- 處理專案有關的行政工作
- 計劃未來的功能特點和可能的改變
- 管理軟體工程師的時程
- 指導工程師構思產品
作為新創的起點。該產品為我們賺取利潤的同時（幸運地至今仍是），我們開始接受客戶委託的案子。一開始，每位共同創辦人都親力親為跟客戶交涉。當公司發展到一定規模後，我們開始分工。Ben出席活動、負責銷售，Rick成為我們的CTO， 我則專PM。
我跟我的公司一起成長，卻沒有考慮到自己的極限，以及如何為急速增長做準備。
高峰時期，我需要同步管理10個以上的項目和超過20個軟體工程師。很明顯這是難以持續的。當時我第一個想法是聘請多一位PM來分擔我的工作，但一想到訓練新人需時，便打消念頭強迫自己更有效率地完成工作。終於，我們的產品品質無可避免受到影響。
聘請新PM為何沒有長遠解決問題的反思
Photo by via Unsplash
我們還是開始尋找第二位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匯報的問題
（截圖）Waffle平台上展示我們的旗艦產品
（開源後台程式）
如果時光倒流，我會如何處理這個難題？
如果可以重來一次，我會在達到隊伍最大產值的70%前訓練好下一位適任的PM。
PM是客戶專案質量的保證。如果你已接近產值極限，將難以在早期發現潛在問題，意味著開發後期你將耗費更多精力來修正重做。到時候你也無法撥出時間來思考較深層的問題（譬如如何訓練你的PM團隊）。你得預算一段長時間訓練直至他們達到你心目中的標準。
今天，我仍然像當初獨力管理10個專案時一樣忙碌。但有賴我一手培訓出來的PM團隊協助處理大部份日常公務（例如「日常焦點」、客戶報告、審理新功能），我才能騰出時間專心分析公司各階段的表現，包括專案預測或最佳化開發周期等等。將來如有時間，我也樂於和大家分享這些方面的經驗呢！
想更輕鬆地開發app嗎？試試我們提供的免費開發者工具 和開源後台程式 。本文章感謝Oursky提供本PM Blog專欄共同公佈。
