[PM World-全球聲音] 創辦人非萬能:兼任專案經理反而局限公司發展

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專欄共同公佈。