preview-of-lean-project-management

「PM World – 全球聲音」精實專案管理: 九年實戰經驗不藏私分享

本文章感謝 Oursky 提供本 PM Blog 專欄共同公佈。
原文: Lean Project Management: Field Notes from 9 Years of Development
作者: Roy Yuen, Oursky 創辦人
翻譯者:Queenie So

在創立 Oursky 的初期,專案經理( PMs ) 是由我們三位創辦人同時兼任的。當公司穩定成長的同時,我們跟其他公司一樣需要面對品質管理的問題。而當我們的團隊成長到超過 50 位成員,我們更要努力在「培育經驗相對較少的初級工程師」與「確保交付給客人的編碼和設計品質」之間取得平衡。

終於,我們在撐過 10 個同步進行的專案後開始聘請新的專案經理。我們的專案經理並不是單純的客戶經理,他們還擔當橋接管理層與工程師的黏著劑、驅動專案進行的靈魂人物、與客戶溝通的重要聯絡人。這邊和大家分享一下,要成為一位強大的專案經理,需要哪些必備的技能。

(請留意,我們很強調由設計師、工程師、專案經理到品管人員,每一位團隊成員都需要對產品品質負責。)

在科技公司任職專案經理有哪些實務要求?

stairs-to-lean-project-management

Photo by Christopher Burns via Unsplash

有別於其他機構,Oursky 的專案經理和客戶經理是由同一人擔任的。我們的專案經理一手包辦了籌劃專案、掌握開發進度以至為最終產品的品質水準把關。而同時作為一位客戶經理,他們也會向客戶建議在他們的預算範圍內能把產品做到什麼程度、各種技術上的考量和匯報開發的進度。

Oursky 通常會在業務團隊確認成立專案時引薦專案經理。當簽訂合約、專案正式啟動後,專案經理就會建立一個 Basecamp 專案,方便客戶隨時檢視我們的進度或留言查詢。要完整列出一個專案經理需要負責的工作就足以另外寫一篇文章了,這邊先簡單提供一個概念:一位專案經理在專案成立的初始階段工作清單。

 

專案成立:

  • 適當地設定各種自動化工具(例如:Hockeyapp, Apple TestFlight, QA 伺服器等等)
  • 安排會議讓技術領導人和開發工程師討論專案延伸的技術問題
  • 草擬 API 文件
  • 預備資料庫 Entity-Relationship Diagram
  • 規劃伺服器的架構
  • 規劃 App 的架構 / 流程圖
  • 設置模組的測試案例
  • 定義採集分析數據的內容

預估成效

Lean project management

我們把 app 的功能和 issues 歸類,衡量它們的重要性和排列優先順序

確定成立一個新專案後,第一步是要設定專案的商業目標。專案經理一開始會根據客戶要求的功能和預算提供兩個預測結果(以計費工作天數計算)。我們提供最少兩個選項是因為客戶在意識到原本設想規模的相對價格後,通常都會選擇修改產品。而一般在這個時間點,專案經理同時也會請設計師開始設計線框稿。

當關鍵元素(例如主要功能、預算、時程等等)都確定下來後,專案經理會按照每位同事的時間表和專長來組織一個工作小組。我們的開發工程師一般擅長 Android、iOS 或網頁開發,但因為他們需要全盤掌握產品完整的功能,所以他們同時也是全端工程師。接下來,我們會替主要功能排定優先順序,還有把各個功能解構成最多兩天內可以完成的小任務。

追趕進度、保持溝通

lean-project-management-is-as-challenging-as-game

Photo by Quino Al on Unsplash

專案經理的另一個重要任務是保持溝通渠道順暢無阻。每天專案經理會利用 Waffle.io(與 GitHub 整合)來舉辦站立會議,讓所有開發成員都能有效進行討論。專案經理會先了解新的 issues、把客戶的要求排列優先順序,再替工程師設定各項新的任務。作為客戶的聯絡窗口,專案經理也需要懂得分析哪些要求是迫切的(比如修正關鍵的 bug),或哪些要求應該先押後避免讓工程師分心。又因為我們的專案經理同時管理多個專案,他們也能分享一些可能被不同小組的工程師忽略的相關函式庫或常見問題,提升整體的開發效率。

建構與改進

lean-project-management-needs-teamwork

Photo by Margarida CSilva on Unsplash

在我們眼中,凝聚力跟溝通同樣重要。要留意的是,保障編碼品質的負責人應該是技術領導人而不是專案經理。但這也不代表專案經理就能隔岸觀火。他能做也應該要做的是,在每天跟開發團隊進行的會議中提問適當的問題,譬如說客戶的推廣活動正在進行期間值得馬上更改資料結構嗎?另外,專案經理也應該主動要求一些可以改善使用者體驗的變更,比方說趁著修正其中一個功能的 bug 時順便加入像「更改狀態時自動轉換顏色」這樣的小細節。換句話說,專案經理應該比較宏觀地掌握整個設計藍圖,並讓所有人根據這個藍圖來組合各項功能。編碼並不是單單只求無瑕而已,高品質的編碼同時意味著下一個人可以把時間花在如何改善體驗而不是機械性地修正瑕疵。

捕捉細節

lean-project-management-like-taking-care-of-a-baby

Photo by Margarida CSilva on Unsplash

談到公司裡新進工程師遇到最大的困難,如何在 GitHub 上發出一個好的 pull request (包含明確的提交紀錄與易讀的編碼)一定榜上有名。我們公司會把不同專案的工程師互相輪替去確保編碼是可讀的,因此確認剛進來小組的新成員已了解狀況還有能夠如期完成被賦予的任務是專案經理的重要職責之一。

我們為如何監管品質整理出一連串的指引:

  • 每一個 pull request 都需要被一位技術領導人檢閱過其編碼
  • 每一個專案都需要指派最少一位人員負責檢閱編碼
  • 自動化編碼文法檢查,檢查程式複雜度,設定測試範圍

專案經理同時也是負責為新功能做最後檢查、還有當新版本完成時協調進行品管測試的人。當團隊完成整個專案後,我們會向客戶提供原始碼和本地端儲存庫方便他們日後進行維護或修改。

專案管理工具

oursky-working-style

Oursky 的工作模式

工欲善其事,必先利其器。時至今日,專案管理已發展出許多工具可供選擇。而專案經理的角色,是選擇最適合用來追蹤專案時程和促進客戶溝通的工具。

我們應用在非技術類型的顧問委託和內部專案時,最愛使用的是 Basecamp。而針對技術委託還有內部開發小組,則使用整合到 Waffle.io 裡的 GitHub Issue Tracker,方便取得像 Trello 版本的 sprint 概觀。至於以管理角度縱觀協調全公司所有工程師的工作量,我們則回歸到最簡單的工具:使用試算表為特定專案效期安排人手。

總結

teamwork-is-important-for-lean-project-management

Photo by rawpixel.com on Unsplash

Oursky 裡,我們從不諱言熱愛自己開發的產品。當我們從一個三人小團隊發展到今天成為超過 50 人的公司,我們意識到公司員工很需要一種特質:可以把人們凝聚起來、一起充滿熱情地創造喜愛的產品,還有能力把這個產品做得很出色。事實上,專案經理正正擔任這個角色。

如果你喜歡這篇文章,歡迎追蹤 Oursky 的 Medium 帳號 獲得更多有關新創 / 企業家創業 / 專案管理 / app 開發 / 設計發想有關的消息!

Oursky 致力幫助品牌與企業家實現他們的點子。如果你正在尋找合作夥伴一起建立下一個自家數碼產品,來跟我們聊聊吧!

project management oursky

「PM World – 全球聲音」專案經理和開發工程師的雙贏方程式:不再讓 Deadline 只是隨口說說而已?使用 EBS 是關鍵!

本文章感謝 Oursky 提供本 PM Blog 專欄共同公佈。
原文: How project managers and developers can both (happily!) give realistic ship dates
作者:Ben Cheng,
Oursky  創辦人

翻譯者:Queenie So

Evidence based scheduling EBS fog creek joel on software

圖片來源: Fog Creek

如果專案經理只站在客戶的角度思考,有時難免會陷入迷思。為了幫客戶降低成本,努力追趕 deadline,務求在最短的時程裡交付產品。其實客人真正追求的,首先是最好的產品,然後才是盡早的交付日期。
 
精心編寫的程式碼是創造高品質產品的基礎。軟體開發者應該按照約耳測試 ( Joel Test ) 裡提到邁向高品質軟體開發的12道法則來做好版本管理、鼓勵每日編譯 ( daily builds ) 或善用品管測試 ( QA )。
 
參考過往的紀錄進行推斷,才能制訂出合乎現實的 deadline。我們的專案團隊一直致力驗證我們預測的準確度,同時為我們的 PM 和開發工程師建立一個反饋循環。在開始實行 Fog Creek 旗下的循證式時程規劃 ( evidence-based scheduling, EBS ) 兩個月後,我想與大家分享一些心得。
 

沒有強迫症也可以進行 EBS

 
我們使用 Fog Creek 的 EBS 去追蹤和比對開發工程師預期和實際花在專案上的時間。這些數據幫助我們編制更切合的專案時程,並且提供一個反饋循環,促進 PM 和工程師改進他們為個別任務制訂的需時預測。
 
但重點並不在這些近乎強迫症的計時上 — 我們信任我們的工程師和 PM,當然也包括他們在專案檢查表上自主填寫的時間。
 
除了 Fog Creek 在他們 EBS 部落格文章提到的要點外,我們在實際應用上也有一些體驗。
 

確保 Issues 都能在兩天以內解決

 

Evidence based scheduling formula fog creek

我們的 EBS Google 試算表範本

 
如前所述,我們透過 EBS 追蹤預估和實際耗費在撰寫 user stories 和開發各個功能的時間。個別的功能都被切分為理應在兩天以內可以被完成的 GitHub Issues。
 
開發工程師仍然需要創建許多足夠小的任務,再梳理和整合每項功能的架構。比如說,與其很概括地表示「建立購物車功能」,我們可以把它切割成很多細項,譬如「以列表形式清楚地展示購物車內的產品」。
 
這個追蹤過程同時讓我們的客戶獲益,因為他們能清楚掌握我們在每兩週一次的 sprint 裡正專注在什麼項目。如果某些功能超前或落後進度了,他們都能及時收到通知而避免意料之外的「驚喜」。
 
我們同樣會追蹤我們 PM 的預計時程,因為他們不只擔任客戶經理的角色。他們某種程度上必須具備技術層面的基礎和理解,並從錯誤學習,將來才能做出更準確的判斷,優化他們的時程規劃。這對 PM 來說是很重要的一環。
 
當他們發現和工程師針對開發相同功能預計的所需時間存在巨大誤差時,他們可以提問並從中學習什麼環節比較耗時,技術債會如何影響一個專案的進行,還有所有事情如何安排才會進展得比較順利。
 
我們的 PM 努力尋找商業獲利點:他們提供足夠時間予工程師去好好建構和編寫程式碼,同時給客戶建議一個合理的時間框架(還有成本)。
 

追蹤實耗時間

 

Toggl free time tracker

圖片來源: Toggl

 
我們的公司奉行彈性上班時間,很多同事可能會忙裡偷閒去喝杯咖啡或聊天放鬆一下。 EBS 會把這些休息時間都算進該功能的總開發時數裡。有些工程師可能會頻繁休息但在短時間裡一氣呵成快速衝刺,而其他人則可能選擇持續而穩定地埋頭工作。
 
說到底,假如預計的時間與實際花費的時間是一樣的話,這兩種工作模式底下的工程師都是預算準確的。你可以利用 Toggl 應用程式來檢查自己的預估時程,只需在開發某一個特定功能時打開計時器直至開發完成為止(包含休息,不管那些休息時間有多長或有多頻繁)。
 
不過,其實你不一定需要這樣精細的追蹤檢查。
 
因為有很多任務要被完成至少也得固定花幾個小時,工程師可以在每天完結前快速紀綠當天完成的 issues。像「 0.25天 」這樣的概估就已經足夠了,也就是說為什麼我們不是非要用到計時工具不可。
 
我們使用「 velocity 」(速度)作為測量預計花費和實際花費時間的量度單位。如果預測時間和追蹤到的耗時是一樣的話,我們判定為「 1 」。如果工程師在兩天內完成一個任務,但當初預期需要 2.5 天的話,速度就是 1.25,意味著他們低估了自己的速度。
 
追蹤時效的目的並不是一味的追求快速。 EBS 的最終目標,是保持一致性和準確度。一致性代表團隊成員能根據以往的表現預測各自的 deadline,而準確度則是把 velocity 盡可能持續地控制到貼近 1 的範圍(或最低限度的誤差)。
 

將工程師的預算時程慎重納入專案時程的考慮因素之中

 

evidence based scheduling software development

我們的 EBS Google 試算表範本

 
客人委託專案的時候,我們的 PM 會分析所需功能並推算各項功能的開發時間。把所有的功能組合加總,再加上審閱編碼和品質管理的時間,我們就能向客戶提供一個標準的專案時程。
 
EBS 幫助我們審視個別工程師如何影響整體專案的進行。在我們開始追蹤時效後,我們發現一些有趣的現象。例如有些工程師可能持續地高估他們的速度,所以永遠落後於預計進度。但是,他們可能最終仍然以快於平均值的速度完成開發,而且還能配合整個專案的進度。
 
因為這些行為是可以預測的,我們的 PM 現在學會了如何在提供預計時程給客人參考時做出適當的調整。相反地,假如我們某位工程師長期超前完成任務提早交付,我們的 PM 也能有把握判斷可能可以向客人建議一個更緊湊的時間表。
 
比起經驗,實證數據甚至更為可靠。
 

有關 EBS 的觀察與省思

 

Photo by NeONBRAND via Unsplash

 
我們還有一些有趣的觀察:資深的工程師在預估時程上未必比初級工程師更加準確。其中一個可能性是因為我們傾向指派更複雜的功能讓他們開發。即使規劃時思慮周詳,背後還是隱藏了很多不確定的因素,像是那些新發掘出來的問題都在開發過程中有待解決。
 
我們的目標,是讓工程師與 PM 在面對一些無法完全掌握藍圖的情況時,有足夠的緩衝時間去完成任務;同時利用現有的預計時程,去判斷一些常見基本工作所需的時間(譬如登入頁面)。
 
我們另外發現,即使工程師富有開發經驗,也不代表能加速完成開發一些常見功能。因為不管開發者有沒有經驗,某些功能的開發本來就需要花費固定的時間。我們不應該為了節省成本,就以優化為名,試圖追趕或縮短預計的時程。
 
以試算表進行 EBS 和任務追蹤也幫助了我們快速判別出哪一種特定功能將重覆導致延誤。
 
實證的數據有助我們追蹤行為模式和其引致的現象,讓我們更深入認識自己的工作方式。但是,這也不代表我們就能完全依靠數據,因為每一個專案都是一個全新的計劃,都有變化的可能。
 
Joel已展示過應該如何在專案管理上應用蒙地卡羅模擬法( Monte Carlo simulation ),模擬 100 種可能發生的情景、每個場景搭配 1% 的機率進行演算。根據隨機抽取有關工程師工作速度的歷史數據,可以完整地展現一個專案中所有可能發生的面貌。演算的目的在於縮小產品交付日期的變化範圍,而不是期望能指定某一個日子交付,或假設每一次都能達到 100% 準確度。
 
EBS 已證實了軟體開發也是機率的一種。( Software development is a probability. )
 

最後的反思

 

Photo by Felix Plakolb via Unsplash

 
基於現實考量,我們仍然為客人的專案提供一個預計的 deadline。我們同時邀請客人參與 Basecamp 計劃,讓他們清楚了解我們每週的工作進度。
 
當一家公司或一個工程師(包括你的同事!)提供一個專案預測時程給你時,嘗試不要只專注在總天數上。不論專案長短,請向對方要求各項功能分配的時程,還有他們過往完成專案的時程紀錄。先了解對方的團隊如何制訂預計時程,再把那些背後的因素納入你編制長期預算的考慮範圍內。
 
你喜歡這篇文章嗎?請按讚或分享給更多朋友看到。謝謝!
*Oursky 致力幫助品牌與企業家實現他們的點子。如果你正在尋找合作夥伴一起建立下一個自家數碼產品,來跟我們聊聊吧!*

「PM World -日常生活」星座四大象限看PM

大家應該常常會在網路上看到各個星座的解析,不管是個性、感情觀、處理事情的態度,甚至也有很多youtube的頻道會拍攝十二星座面對xx事情的反應等等的話題。不得不說,在我有生之年,確實遇到很多星座得以解釋個性的人,所以讓我對於星座這件事的探討越來越感到著迷,不知不覺會常常記下一些星座的特性。雖然也是會遇到一些覺得並不符合該特定星座個性的人,不過蠻大一部分的人,個性去對應到星座,還是有跡可循的。 所以這次的PM專題我們就來走個輕鬆一點的話題,來分析不同星座象限的PM,對於專案管理這樣的工作有什麼不同的處事態度吧!

 

(註:筆者非專業星座專家,只是偶爾喜歡猜猜共事的人星座,然後又蠻常猜中的所以被派來寫這篇文章,若裡面有寫到不中聽的也請勿太過桑心,畢竟這只是一篇不專業文章,別太過認真囉!)

 

風象星座-(水瓶、雙子、天秤)

 

風象星座代表的是頭腦,最擅長抽象的語言思考能力—邏輯推理、理性分析、溝通表達等等的能力。 在四大星象裡面算是最能使用“理性”處理專案的星座。 也是最能夠在面對客戶、工程師等眾多情緒攻擊中抽離情緒而以理性以待的星座了。換句話說,在專案管理中,能夠客觀的去看待事情,換位思考,算是風象星座在專案管理上的優勢。畢竟在專案管理中,其實很多事情的處理是在於人與人之間的應對以及溝通,若是能省掉情緒上造成的困擾,在專案的管理上會更有助益。

此外,對於專案管理的執行面,風象星座是很會抓住大方向的掌控,對於事情的輕重緩急是很有概念的而且規劃是有條理的,所以總體來看,在時程上及專案方向上是不用擔心的。不過,當你把大任務仔仔細細的拆解成小小的任務來看的話,其實是會發現風象星座對於細節的掌握是非常不精準的。 這大概就是風象星座對於專案管理當中最弱的一個環節:細節。多多少少來說,不管是水瓶、雙子、天秤都會有點以小聰明的方式在做事,把重要的事情先做好,或是把重要的事情先呈現出去,結果細節的部分就忘了,或是因為下一個更重要的事情而被忽略了,這就是風象星座要注意的地方。

 

火象星座─(牡羊.獅子.射手)

 

火象星座代表的是能量,總是給人自信、直來直往、樂觀積極、衝勁十足的感覺。十二星座中行動力最強的星座就是火象。這在專案的執行中絕對是一大優勢,目標一但確立,就會勇往直前。而且牡羊座是大姐頭、獅子座是領導者、射手座又衝第一,加上他們的自尊心都頗強的,所以不用擔心專案在這些PM上面會毀掉,因為他們天生個性就是很適合帶領事情(套用在PM上就是專案),加上自尊心強,所以他們不會讓這種事情發生的。除此之外,火象星座的直來直往,能夠直接說明的態度反而對溝通更有幫助,不用讓他人花費心機去猜測潛台詞:不過相對來說,這樣的直來直往在某些人際關係上有可能會造成爭執,所以火象的朋友們有時候要稍稍注意一下把自己拉住。另一部分還有要稍稍注意的是,因為衝太快,有時候行動力遠遠超過於思考,怕是思慮不周有沒有考量到的地方,例如:專案細節尚未確定,只是把大方向想得很簡單,就先做了再說,而錯估時程之類的。

 

水象星座—代表情緒(雙魚.巨蟹.天蠍)

 

感性的水象星座就是水做的~~天生比其他星座都更細膩有感,懂得觀察別人,也夠細心細膩。 水象星座的細心發揮在專案管理上是一個很大的優點,因為PM處理的事情很多很雜,所以細心其實是一件蠻重要的事,而水象星座的PM都可以把這些事情處理的很好。而善於觀察別人,懂得察言觀色,實際上可以是優點但也可以是缺點。因為PM不可能是好人,所以無法面面俱到,有時候甚至會需要跟人處於對立面,偏偏水象星座因為感受得到其他的人的情緒而且也會在乎其他人的情緒並且將其放在心上–無論對象是“客戶”或是“工程師”。這種狀況下就會造成自己的壓力並且影響自己的情緒,將工作上的壓力以及情緒持續地帶進專案當中,也不見得是件好事。懂得適度的釋放壓力跟情緒大概是水象星座的朋友們在PM生涯中最需要克服的一點。

 

土象星座—代表身體(魔羯.金牛.處女)

 

星座分析說,土象代表身體,是我們的自我最具體的呈現,他們是所有星座中最注重“實質”的一個象限。土象的朋友們就是腳踏實地的在做事,做事穩健及保守是他們鮮明的形象。所以大家會把土象的PM當成一個可靠的PM,因為他們一定會認真做事,好好發揮。尤其在文件的產出上,會認真仔細,拼命地做好做滿。無論是摩羯、金牛、處女,都是埋頭猛幹的個性。不過呢,穩健及保守的再延伸一些就是相對地缺乏彈性、比較固執一點。在專案的管理上有時候會比較無法變通。這可能是優點,也可能是缺點。例如,處女座的要求完美,總是希望把文件做的漂亮、完善再交券,卻可能為了把細節做的最完美,而忽略了時效。畢竟做專案是一個很重視時效的工作,這點可能要小心注意。而摩羯跟金牛,有時候可能會為了執著一個自己心裡的原則,不願意放下那些原則,而造成其他共事的人哭笑不得的狀況。由於專案管理實際上會面臨到很多不同的團隊,所以這些原則有可能就變成了他們的門檻,需要他們去突破跟跨越,才能讓整個專案更順利的進行。

 

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

本文章感謝Oursky提供本PM Blog專欄共同公佈。
Original Article: How I became the PM bottleneck as a founder

作者:Roy Yuen, Oursky  創辦人
翻譯者:Queenie So

很難想象,從九年前創立公司到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為何沒有長遠解決問題的反思


Photo by Nicolas Cool via Unsplash

我們還是開始尋找第二位PM。雖然很少應徵者能夠達到我們對技術層面與客戶應對的要求,幸運地我們聘請的第二位PM富有經驗也表現亮眼。一切看起來如此順利。直到他決定離開公司自行創業,我們又回到了原點。聘請一位PM只是暫時解決我們的問題,可惜我們沒有利用這個機會標準化PM流程。

缺乏標準化的流程,在產品預備呈交客戶時才發現問題已經太遲。

 

累積的經驗讓我們慢慢摸索出一套PM的心得。但當更多新人加入公司,我們發現無法快速傳授他們心得或提供指南讓他們跟隨。結果,因為我一人之力應付不來而讓公司無法承接新的生意。換言之,是我局限了公司的發展。

認清事實,我們對PM的職務存在過高的期待。


Photo by Christian Joudrey via Unsplash

作為香港一家小型的app公司,要找到一位符合所有要求的應徵者實在太困難了。現實是,我們無法跟能夠提出優渥條件(而職務要求可能比我們更低)的大機構搶人,所以我們另闢蹊徑 — 投資建立自己的PM團隊。部份是直接以PM身份聘來,其他則由另外的部門(例如QA)轉職。

我們從頭訓練PM,讓他們循序漸進掌握實務。


Photo by Fernando Reyes via Unsplash

經歷第二位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平台上展示我們的旗艦產品Skygear(開源後台程式)

如果時光倒流,我會如何處理這個難題?

如果可以重來一次,我會在達到隊伍最大產值的70%前訓練好下一位適任的PM。

PM是客戶專案質量的保證。如果你已接近產值極限,將難以在早期發現潛在問題,意味著開發後期你將耗費更多精力來修正重做。到時候你也無法撥出時間來思考較深層的問題(譬如如何訓練你的PM團隊)。你得預算一段長時間訓練直至他們達到你心目中的標準。

今天,我仍然像當初獨力管理10個專案時一樣忙碌。但有賴我一手培訓出來的PM團隊協助處理大部份日常公務(例如「日常焦點」、客戶報告、審理新功能),我才能騰出時間專心分析公司各階段的表現,包括專案預測或最佳化開發周期等等。將來如有時間,我也樂於和大家分享這些方面的經驗呢!

想更輕鬆地開發app嗎?試試我們提供的免費開發者工具 和開源後台程式 。

「PM World -工具類」小團隊跑敏捷,實務上這樣用 Trello!

專案管理有許多可以探討的議題,隨著新創風氣在許多育成單位協助後蓬勃發展,但不盡然都是資訊呈現為主的網站,在工具上更是雨後春筍般不斷有針對特定流程、特定目的、特定對象產生的第三方服務,那這些到底該怎麼選擇?用了這些工具就能做到他所說的效果嗎?其實並不其然。

 

目標先決比工具先決重要

 

相信許多 PM/管理者 一定都有過該遵循哪種管理方式比較好?專案管理服務幾十種該怎挑選?該怎麼樣確保上線的品質?該怎確保工程師成就感?等等的心中小劇場。筆者也經歷過這樣的過程,甚至試用了 10 幾套專案管理工具,最終才發現,這些服務、心法還是管理方法,終究只是達到我們管理目標的一個工具/方式,還是要問問自己,想要打造怎麼樣工作模式與氣氛的產品開發團隊。

 

當時在尋找工具前,希望管理方式能做到三大目標:

  1. 工程師能有不斷完成工作的成就感,團隊也能有一個時間區間的共同成就

  2. 一旦規格訂好討論好後,減少開發過程間的溝通

  3. 開發內容與討論過程都能公開透明並保留記錄

 

工具的挑選

 

現在專案管理服務非常的多,像是 JIRA, Trello, Asana, Redmine, Notion, Basecamp, Phabricator 等等,筆者都有實際上去測試且將某功能的 issues 搬上去玩玩。但形式非常的多,有適合敏捷的、Scrum、待辦事項的、指派工作為主的,甚至有連文件管理跟 CI/CD 統包的服務。蘇格拉底說:「我唯一知道的就是我一無所知」,這句話的奧妙就在我們生活隨處都在遇到,知道太多時就像無頭蒼蠅,不知道該往何處去。

 

目標先決重要就在於莫望初衷,我們想要的就如 Scrum 的模式,一開始大量溝通與規劃,每日隨時的校正,最後不斷透過每個 Sprint 檢核團隊成果,並檢討與改進,獲取不斷往前的成就感累積。但,小團隊與創業剛起步時,有的是許多的想法….就是沒有人、沒有錢、沒有客戶。這時需要的是快速的演進,根據客戶與市場需求不斷快速的開發,是產品 0-20 分很重要的過程。

 

最終,我們則是選擇了 Trello 作為管理工具,簡單、有彈性、有標籤、有篩選器、有指派功能,還有許多 browser extensions 能夠擴展功能,更重要的是,免費。

 

(後記:若有使用 github 作為主要管理程式碼的服務,可以試試看 Waffle.io,基本功能與 trello 一樣,差異最大在於他的每張卡等同於 github issue,且有做同步的整合)

 

Trello 的介紹與核心概念

 

先簡單定義一下 Trello 功能搭配專案管理上的連結關係:(參照範例圖)

  1. board(看板):代表一個專案

  2. list(列表):代表開發流程中的一個步驟

  3. card(卡片):俗稱的票(issue)。

 

這定義尤其重要的是 board,過去在使用 trello 上因忽略背後設計理念,以 board 為團隊,將所有專案的票都開在一起,最後沒了流程性,每張票的流程與進度都得進去看內容才知道;每個 list 也因爲各專案的工作很多,整合在一起時便多到讓人嫑嫑的,導致整個管理失敗。在吸取過去與其他團隊的經驗下,我們有了幾個原則:

 

  1. 各自為政,一同努力

    1. 每一個 board 代表一個專案,有多個專案就需要開多個 board,讓各個負責人專心瞭解他們該做的工作就好。
    2. 另外,若同專案有不同目的也應拆成兩個 board,像我們有個 A 產品開發版,以及 A 產品規劃版,讓 PM 規劃每個功能也有流程可以跑供大家檢視。
    3. 列表只用作為流程的步驟使用
  2. 分工合作,逐步完成

    1. 每張卡片盡可能切細,最多半天能處理完的大小
    2. 卡片在切分時盡可能降低耦合、增加內聚力,讓每張卡的相依性降低(這很難我知道,所以盡可能)
  3. 透明公開,彼此瞭解

    1. 以卡片在 trello 的 url slug 作為 git branch name(例如:https://trello.com/c/wIdo3qXx/732-system-should-apply-only-one-automatic-coupon-when-checkout,就會以最後粗體字處作為分支名稱,甚至在分支切換時也可透過前面的數字做到 auto complete)
    2. 每張卡片完成後,都需要在 github 上開 pull request(後簡稱 PR),並且將連結貼回至卡片中,讓 code review 以及其他對此工作有興趣的夥伴,都能直接連結過去。

 

(範例圖)

 

在這樣的原則下,我們的 lists 大致為:(參照流程圖)

  1. Sprint to do:每個 Sprint 團隊要一起完成的工作。

  2. Blocked by:若有張票開發到卡住,則丟進此處並標記被卡住的卡片連結,相對該卡片也應標記此張卡片,以便未來完成後可再持續解決這張卡。

  3. Developing:當工程師要開始開發時,則將卡片移動,作為一個開始動作,同時也可讓大家知道目前每個人正在開發什麼內容。

  4. To revise:開發流程最後一定都會需要有他人進行 review,不論是 coding style, architecture 或是 user flow,有需修正的地方,我們都會在 PR 中註記,並將此卡片丟至此處。

  5. Done:已完成開發的卡片,等待後續 review。

  6. To Deploy:代表 review 完成沒問題,並已完成 merge 等待最後確認(e.g. staging, CI auto testing)上線。

  7. Deployed:功能正式上線後,卡片就會丟到此處算流程完整跑完,大家也能在此看到已上線哪些功能。

 

(流程圖)

成效如何?

 

在新流程導入後,工程師都反饋比起過往在執行每個卡片時,需煩惱 branch name 如何命名,以及在想瞭解過往夥伴執行的工作時都還得打斷對方做詢問等狀況,在簡單一個統一的 branch naming rule 下,讓整個團隊運作的彼此瞭解,能透過工程師的共同語言:「程式碼」做溝通,減少許多不必要的溝通。

 

實際開發上,因為卡片的大小有一定規範,獲得兩個顯著的收穫。第一個是,每天工程師都能有完成些什麼的成就感,作為不斷持續的動力;code review 上也因為卡片的大小限制,讓進入成本(時間成本、心理成本)大幅降低,可以將可用資源最大利用的將功能完成測試上線。對於 PM 與管理人員來說,能更確實在功能上線前都一定會經過檢核,還能明確掌握每一位成員手中在執行的任務,協助每個成員對準團隊目標。

 

實際上在跑有遇到幾個比較特別的狀況,假設真的這個功能較大很難拆出每張可以獨自被 merge 到 master 的票,可以在卡片中溝通哪幾張票都應該 merge 到某一個 branch,等到最後完成時再一次回到 master;前端與設計該怎進入此流程?一樣將設計與切版都開票,走一樣的流程;若需要其他後端協助,再將後端拉進票中一同幫忙。

 

小結

 

我們團隊(後端*2、設計/前端*2、Tech lead/PM)依照這樣流程跑了超過半年,平均每週能上版超過10個大大小小版本。在聽過中國大公司其中一個小組分享他們一年上版150-200個版本,相比之下 10+/週算是很不錯的一個成績。

 

產品開發管理就這樣嗎?

 

此篇著重在從規劃完成後,票的建立到完成上線如何有效的被實踐。其他像是 standup meeting(我們用 jell 各自紀錄同步 slack 取代)、程式碼品質檢驗(code climate)、自動化測試、持續性發佈(CD)等等;非工程面,像是像是怎麼訂版本號、如何根據市場設定戰略目標、如何製作商業模式的營運報表等,又是另外一門學問了,讓我們下次見。

 

若有更多好奇的細節或是議題,歡迎來信或填以下問卷與我們討論。

問卷裡有神祕的Trello聚會活動喔~

課程筆記分享:【2017 紫牛學校 x ALPHA Camp】 #1 產品戰爭 – 移動互聯網下半場,產品經理該如何應對?

課程前情提要:
2017 年 5 月,台灣紫牛創業協會攜手雪豹科技、獵豹移動和在新創人才教育不遺餘力的 ALPHA Camp,要將雪豹、獵豹公司全球超過 30 億下載、月活躍用戶超過 6 億的傲人產品開發經驗,以實例呈現在學員面前。本系列課程,將邀請雪豹科技和獵豹移動各部門負責人,就負責人所擅長的專業職能做分享,從挖掘市場需求、數據觀察、用戶體驗優化到商業變現,完整概括產品開發週期和產品經理的 day to day life 。

 

講師:明鏡 (獵豹移動|PhotoGrid 產品負責人)

「依各時代互聯網模式變遷,探討 App 發展模式,產品經理的能力又應如何提升?」

Read More

Minerva — 一所顛覆高等教育的新型態大學

你滿意自己所接受的大學教育嗎?你覺得你所接受的教育幫助你有效地面對這個劇烈變動的世界,自信地面對未來的職涯嗎?在蓋洛普於2014年做的一項調查中顯示,有九成六的大學認為他們幫助學生有效地面對未來的職涯,雇主中卻只有 11 % 的人認同這樣的說法。由此可見大學的學習成果讓業界以及學生自己都不太滿意,這中間很明顯有其落差。螢幕快照 2017-03-19 下午11.49.56
受到科學革命與工業革命的影響,近代教育體制為了訓練且供應高品質的勞工而成形,集體且統一化的管理,標準化的教材與單向的灌輸,目的是在高效率產出一批批的勞工以及管理階層,即使幾百年過後的今天,大部份的學校在形式上仍沒有太大本質上的轉變。因此越來越多新型態的線上課程與創新學校出現,許多人都對當代教育的目的與功能提出質疑,教育改革的聲浪不絕於耳。
Read More
校友聚焦 梁多多

【ALPHA Camp 校友聚焦】 不想上班有限公司共同創辦人梁多多專訪

有想做的事情就去做,不會的就去學,天生反骨,敢拼敢衝,為了找尋之前創業失敗的原因,他在19歲的時候成為 ALPHA Camp 最年輕的學生,如今才21歲的他,帶領著一個20 多人的團隊,用自己的方法做出超高營業額的電商,年紀輕輕人生速度卻以倍速計算的他是如何在這過程中快速成長,又為什麼堅持走上創業之路?來看看 ALPHA Camp 第四屆行銷班校友梁多多的精彩故事。

個性叛逆,從小就有自己的生意經

Read More
4 個預告你的 Prototype 將會失敗的重要跡象

4 個預告你的 Prototype 將會失敗的重要跡象

身為一個為早期新創團隊的 UX 顧問,我常碰到的創業家可以分為兩種:那些認為他不用做使用者研究的,和那些後悔他沒有早點用正確方式做的。這兩種人的差別正在於他們是否已經用 prototype 和真實的使用者進行了測試—就算完成了測試,他們往往無法順利解析使用者的回饋,或不知道該如何運用。

既然如此,讓我們一起看看幾個顯示你的 prototype 正走向失敗之路的重要跡象,也許能及早避免悲劇的發生。

跡象 #1: 沒有任何(或極少)使用者參與就完成初步設計

以下流程你聽上去可能有些熟悉:你獨自又或者跟一個小團隊,關起門來腦力激盪,發想可行的商業點子,伴隨著許多「如果可以…」和「如果這樣就太棒了…」的驚嘆。這些問題多數是基於個人觀察或是某些關於周遭世界如何運作的假設。你的點子聽起來可能像這樣:「如果我們可以讓 X 個人願意做 Y 這件事,那麼理論上,我們應該可以有 Z 這麼多的營收。」

Read More
Page 1 of 2612345...1020...Last »