over 2 years ago

這篇要講的是 Growth 最重要的基礎在於 Retention。

Retention 強後,你就有基礎的財源,有了更好的 LTV ( Lifetime Value),有更多資源可以去做更強的 Acquisition。更容易做 Referral。

這個道理很簡單直觀。好像有講等於沒講。

盲區一:沒有人想要「改善舊功能」,但是「成長」多是基於改善舊功能

但是為什麼就算很多人知道了,還是做不到。這歸咎在於在大部分的網路公司,在業務擴張的規則底下,人性對於業務提振的方向還是

  • 開發更多產品新功能
  • 開發更多產品新功能
  • 開發更多產品新功能

別誤會。

開發更多產品新功能不是不好。而是開發產品新功能並不保證「會」成長。

Read on →
 
over 2 years ago

這篇文是接著羅胖的跨年演講結論寫的衍生。這裏有部分的演講筆記。而羅胖本人正版全演講稿在 Amazon 上有售

至於全長的四小時,正式影片在下週會在優酷與 Youtube 放送。

先寫結論: 2016 你該「創業」或「學寫程式」

我的文章正文一向很長,按照慣例還是會先寫結論:

  1. 2015 是個 Game Changing 年。
  2. 2016 開始你可以有明確兩個方向:

(1)如果你是個手藝人,2016 你可以勇敢創業做個小生意,接下來世界會是你的。
(2)如果你只是個覺得上班很無聊的文員,2016 年拿到的年終,你可以去報三種班 Android, iOS ,Rails。三門裡面至少學其中一門手藝。(為什麼是這三個,這是另外一篇原因了,為了不岔提,容後再敘)世界也會是你的。

Read on →
 
over 2 years ago

這次的專案管理班 有一個 QA,我覺得很有趣,拿出來分享:

「在規模較大的前公司上班時,使用簡單的甘特圖和每週檢討,使用硬性規定每個人應該達到自己預期規劃的進度,就可以動員整個team把應該完成的工作在上司交代的deadline前提早做完;現在自己開小公司,反而導入scrum、每天畫burndown chart、每天檢討居然還沒有辦法掌握得更好,反而覺得好像更沒效率~大家事情沒有做完就推說自己預估不準,下次再改進就好...然後就越拖越慢..」

我的回答是:中型公司以上適合專案管理。創業公司千萬不能專案管理。

我想這個回答,政治非常不正確。我想 RD 出身的人甚至都會為這個回答震驚。

先不要急著嗆我。你先自行創業一次,用自己的錢 + 專案管理規劃全新的 project,獲得大成功(月入一千萬)。我會誠摯的跟您認錯是我無知。

專業經理人對專案管理的錯覺

第一次創業的人,特別是 execs 出身的人,常常會有一個既定印象的錯誤推斷。

專案混亂 => 經過專案管理 => 順利產出 => 成功。所以,會推出一個結論:凡是經過好的「專案管理」規劃的 project 必定會成功。

我認為這件事其實放在創業公司的起步專案上,甚至是大錯特錯的事,甚至是你退到底限,只寫 user story 進行規劃還是不會達成目標的。

「短視」才是 Startup 常態

我在此有一個大膽建議假設:

  • startup 所有的 project 都只能短視。
  • 一個月只能有一個很模糊的大目標。
  • 想的方案要是在本週五不能 deliver 就是垃圾。
  • 沒有所謂 user story ,只有所謂 solution for user。

為什麼呢?

這就牽涉到一般有專案管理「需求」的公司,一般來說通常已經是 PMF 以上的公司了,所以公司養了很多人,所以才有管理專案的需求。

  • 產品已經定型
  • 已經確定要做的專案目標是什麼(大多是改善)

所以你已經有明確的 input 與 output ,所以這件事才能透過專案管理加速。

但創業不是這樣。你不會有明確的 input。你甚至不知道什麼東西會賣。你只有不斷的試,不斷的調整。所以你永遠不會有清晰的 scope,永遠不會有清晰的 deadline。

只有三天內生出 solution,否則客戶走人。要說什麼風險管理,資源管理,這些都是屁。你甚至沒辦法透過 user story 去解構客戶行為。

既有 PMF 的公司,客戶的臉很明確。沒到 PMF 的公司,客戶的臉大概有幾十張不同的類型。

你只能這樣一直土法煉鋼,煉到你的產品定型,這時候才能開始講所謂的專案管理。

在此之前,你只能用「專案協作」技巧,讓團隊節奏不要被打亂。用「專案協作」技巧,把複雜不能 scale 的事,拆到可以勉強依序執行。

startup 的世界與 PMF 的世界截然不同。startup 也不能透過專案管理技巧通向 PMF。只有 growth 技巧才能帶你走向 PMF。

我想這也是為什麼雖然我的專案管理技巧超強,強到甚至我想通了這層道理。卻選擇把專案管理課毅然決然的關掉的原因。。。。。。。。

這技能已經變成我上輩子的技能。這就是大概笑來所說的:所謂的七年就是一輩子吧。

====

延伸閱讀:https://www.facebook.com/joe.wang.376/posts/10208247441972002 (看到有朋友轉文時得精彩衍伸)

 
almost 3 years ago

這一篇題目,我想一口氣回答三個常見問題。

  1. Growth Hack 是鼓勵追求差異化嗎?
  2. 如果 Growth Hack像美國那樣被玩得很徹底,下個階段變成怎樣?會不會失效了?
  3. 兩個類似的商品都用這個手法行銷,如何一分高下?

首先,我想解釋為什麼「行銷手法」會被一般從業者認為「成熟後會有失效問題」的原因。

為什麼大家覺得「行銷」是「通靈術」?

如果讀者從未接觸過 Growth Hack,對於行銷的想像,往往會只停留在「Acquisition -> Activation」層次,也就是「大量曝光,然後用戶轉換」。

Acquisition 沒有不好。當你的 Funnel 轉換率很好時,這是最好的手段。因為 Channel 像是超大海洋一樣,引一下就有現成的水可以用。

所以很多朋友做行銷,直覺想到的就是「曝光曝光曝光」。但令人傷心的是,其實絕大多數人的產品,Funnel 轉換率都低到不可思議。而且在外部 Channel 上曝光,還會遇到實際上的幾個挑戰,這幾個挑戰就是造成你覺得行銷是「通靈術」的根本原因。

5 C of Channel Decay

Read on →
 
almost 3 years ago

這一部分講的是如何怎麼畫產品與 Growth 的 Roadmap。

一個 Project 有百百個功能,究竟怎樣排優先權。其實這也有系統性手段,這是我前一陣子從 Andrew Chen 與 Brian Balfour 開的課學到的,真是讓我大開眼界,這篇是我的上課筆記:

Step 1: 將功能分成:產品組 / 成長組

首先你應該把所有產品功能分成兩組,產品功能組與成長組。這兩組的差別主要在於「能不能促進指數型成長」。

比如說「產品組」類型的功能:

Read on →
 
almost 3 years ago

一般產品團隊,在要導入 Growth Hack 進產品團隊時,最常遇到的問題是:

  1. Growth Hack 的原理與基礎究竟是什麼? ( 可上 Intro to Growth Hack 心法班 )
  2. Growth Hack 的基礎建設有哪些?
  3. 我們的產品目前有哪些基本功基本服務沒有安裝?Why it matters? ( 可上 Intro to Growth Hack 實作班 )
    1. Landing Page
    2. Onboarding
    3. Measuring
    4. Customer Support
    5. NPS
    6. Referral

當基本設施建好後,內部後續最大的問題是:

Read on →
 
almost 3 years ago

坦白說,這個標題若照 Growth Hack 的定義,有點誤用。因為若照矽谷的建議來說,Growth Hack 的 tunning 是建議 Product Market Fit 之後才進行。( 這個原因是因為 Growth Hack 屬於 Marketing 範圍的一種,而且是創意的 Marketing。實作需要大量資源。而且沒進入 PMF 的話, Funnel 漏水率太兇)。

所以比較正確的標題應該是:「如何用 Growth Hack 中使用的技術工具,將自己半死不活的 MVP 產品推破 Product Market Fit 的下限」。不過顯然這樣「政治正確」的下標法,沒有人要看。所以我還是沿用原標題好了 XD

每月在舉辦 Intro to Growth Hack 講座 傳授「Growth Hack 心法」的緣故。我有時候會收到聽眾事前一些相當精彩的問題,發現大家困擾其實都長的差不多。

這一次因為收到一個「典型技術開發者」的問題,我覺得相當適合整理成具體的 FAQ,因此取得提問者的同意,把產品細節馬賽克之後放上來。

(因為這個問題的相同變形實在出現太多次了,包括我以前也有這樣的困擾)

常見案例:乏人問津的 MVP 屍體

我是個****,平時喜歡開發一些有趣的網站專案。但是常常發生寫的時候覺得這東西很有趣,把pototype服務丟出來後,發現沒有什麼使用者要用的窘境。

舉例來說,我最近寫了一個服務叫做****,他可以建****。一開始決定開發時都討論的很熱烈,幾個朋友都覺得很有趣。但當我實際寫一個把測試版的服務丟出去後,卻發現沒有多少使用者註冊或給予回饋,讓我只能猜測到底怎樣改善才會有人願意使用,但我又不太願意亂猜測亂加功能,因為根據過往經驗這都是很沒系統的try error,因此專案往往就這樣停掉,硬碟塞滿了各種沒下文的專案屍體。

另一個想學的是如何找出客戶care的點,將自己的服務充滿信心的推廣給別人,我目前正在做一個比較偏硬體的專案,目標是透過機器****,降低工讀生的人力需求,目前還在開發prototype的階段,預計再幾個月就會完成原型,送入合作的店家進行測試,我想要知道的是,因為硬體開發比軟體開發更耗時,而且價格更貴(數十萬),要修改更麻煩(****就要一個半月),更不可能用try error的方式看客戶想不想要,有什麼系統化的方法可以問早期顧客正確的問題並早出真正的需求,再來充滿信心的推銷給別人。

具體救回 MVP 專案

Step 1: 裝上線上即時問答工具

建議工具:Zopim、Olark、Intercom

每當我建議別人安裝網站上的「線上即時問答工具」時,很多開發者內心是抗拒的。原因是:「我沒有辦法一直掛在線上回答問題」,所以抗拒安裝。

但你可能不知道的是,線上即時問答工具:

1) 許多使用工具的商家,其實也沒有時常在在線上。
2) 使用即時問答工具留下問題的顧客,轉換率非常非常的高(以我自己銷售課程的例子,大概轉換率超過 80%。我本人在線上的時候,轉換率是 100% )。

線上即時問答工具,很像是降低客戶心理門檻,輕易送出需求的一個方式。寫一封信到 support@yourcompany.com 心理門檻是很高的。但是私密留言門檻是很低的。

我喜歡舉一個例子:傳統我們到體育用品店買球褲時,如果店員招呼我們不殷勤或甚至看不到店員,可能自己四處晃晃就走了。但是如果有一個店員,能夠即時回答你的問題,並且幫你快速找到適合風格的服飾,調貨。你可能不小心手滑就會買了很多運動商品回家。

線上服務正是有這樣的問題,消費者上網站,沒有店員能夠在心裡容忍的時間界線(約一天內)解答他的疑惑,所以這個銷售機會就 Churn 掉了。

你的朋友可能可以到 Facebook 即時找到你,但陌生人沒有辦法。所以即時線上工具,是讓陌生用戶跟你接觸的第一步。

很多人不使用你的服務不是你的產品不好,而是跟他的期望有一點落差。而他們會透過「詢問」透露出他真正的需求,你可以用這個方式逐漸逼到客戶的痛點。

Step 2: 安裝數據量測工具

建議工具:Mixpanel、Amplitude

第二件事,就是裝上量測工具。監測關鍵 Funnel。

什麼是關鍵 Funnel?首先你要釐清:你的用戶是不活躍還是註冊率低。不活躍是因為沒有解決他們的需求,還是學習成本太高?

而第一個步驟,就是找出產品核心使用行為。

假設你的服務是線上記帳軟體。但是使用者登入後,登錄了三筆帳單後,卻不再使用。或者是經營專案管理系統,但是使用者開了一個項目之後,填了幾筆 task,卻沒有再繼續使用。

所以關鍵動作是要找出「為什麼」「流失」。

使用這些工具,追蹤使用者關鍵行為的「轉換率」。如果他沒有完成你預期的動作,請寫信問他為什麼?

寫信成本並不會很高。因為這些數據工具都有 Trigger 可以使用。你可以設定「使用者註冊後三天內沒有完成某某動作」,或「開啟某某專案後」沒有進行下一步,自動寄信給使用者問他你有什麼可以幫忙的地方。

這樣可以有效得找到開發者當初設計的盲點,可能你自認自己的 UX 很棒,但對使用者來說可能困難重重,毫無頭緒。

利用這個手法,開發者可以具體的找到這些「操作上的 BUG」修掉。

Step 3: 撰寫 Landing Page

建議工具:Unbounce、Launchrock

我在演講時,常常反覆跟聽眾強調 Landing Page 的重要性。因為在歐美,製作一個產品或推出一個服務,Landing Page 幾乎是必備款。但在台灣,很多人僅僅視為 Landing Page 是一種「產品首頁設計 style」,是「選擇性的東西」。

「選擇性不設計 Landing Page」的產品,大概佔 70% 以上吧。這就是為什麼很多產品轉換率差到爆炸的原因。

你應該同意開一間餐廳要設計招牌和設計菜單。但為何推出一個線上服務,開發者卻覺得幫你的服務掛上一個招牌,以及介紹說明「不是一件必要的事」?

在這裡必須要說明:「首頁」有「內容」。不代表「有招牌」。

Landing Page 就像是「招牌」。而且 Landing Page 有具體的格式。協助使用者消除疑慮,增強信心,並且 CALL TO ACTION。

Step 4: 設計 Check-in Message,設計 Onboarding 流程

建議工具:Drip、Intercom

Check-in Message 是持續「教育」使用者的一環。使用者剛註冊,未必能馬上理解你的服務能夠 offer 的價值。或者需要很大的精力才能搞懂如何使用你的服務。這時候是 Churn rate 很高的時期。

如果你注意觀察,一些 SaaS 的服務,在使用者註冊之後,會每天寄出一封 tips,教使用者如何使用這個軟體。並且使用進度以及有無卡關。

Growth 通篇談的就是增進 Conversion,降低 Churn。

這就是降低 Churn,增進 Conversion 的一大好招。就像士林夜市水果攤,推銷陸客總先讓他先試吃一塊,然後跟他介紹這水果有多威,結果陸客就只好被迫買單....

Step 5 : 不要沈迷使用 Growth 工具,反覆利用以上提到的工具,持續修正產品

寫到這裡,很多人應該會問,為什麼我沒有繼續介紹下去。講 A/B Testing、Referral 的那一些密技。原因是:不需要。

在 MVP 到 PMF 階段,最重要的是將 Activitaion Rate 與 Retention Rate 衝高。

Referral 必須在產品有高滿意度實作才有效果。A/B Testing 則是太花時間。當顧客跟你說有需求,而且這個需求一直重複被不同顧客提出來時,這是一個直球訊號,你不應該婆婆媽媽的在那裡 A/B Testing,而是應該直接做給他。不要花費太多時間在設定變化球的轉彎係數上。

很多開發者在剛接觸 Growth Hack 議題時,常常會沈迷於上網找尋及安裝一百個 Growth Hack 技巧。這是大量浪費時間且很容易迷路的行為。

最常出現的情形是:當你開始操作這些 Growth 工具時,上網找尋 Growth Hack 密技,在網路上開始找尋相關資訊時,你會驚訝的發現,上網搜尋到的結果不會是找不到增進轉換率技巧(100招),而是找到太多轉換率技巧(10萬招)。這也是我一開始回來台灣後,教 GrowthHack 只教心法,目的正是為了教大家「正確辨認判斷篩選」「適合你現階段的轉換率技巧」。

一般而言,如果想讓產品開始起飛要逼近 PMF,只用以上四招反覆修正,就能夠讓產品快速靠近。

具體前進 PMF

我必須很坦白的說,有 MVP 並不代表可以前進到 PMF。上面的招數是假設你的「開發方向」正確。我在我的另外一個部落格寫過一篇文章:如何挑選正確的創業題目?提到:「正確」的創業題目,其實應該滿足兩個要件其中之一

a) 創業要找你已經非常熟的技能作為題目
b) 或創業要找你周遭非常「高需求」的題目

這兩種題目才能讓你快速前進市場。(a)題目你很明確地知道產業「精確」需求,以及很快能夠製作改善產品 (b) 市場有 high demand,你能夠快速取得用戶,根據用戶 feedback 並搶佔市場獲取利潤。

還有一個重要的關鍵是:做這件事情能夠對用戶貢獻的價值。

這篇文章前面提到的案例是,想開發一台機器,降低工讀生的人力需求。首先我覺得開發者應該去調查出的是:這是一個真需求還是假需求。當然,降低人力成本是一個「顯然賣點」。

但市場未必是這樣看待,如果是開一間餐飲店,工讀生未必是最大成本,照台北的房價來說,店租可能才是最大成本,而這個成本可能遠勝於工讀生人力支出成本。如果這一行都是這樣的狀況,那麼去改善工讀生成本,未必有太大的價值。

如果工讀生人力成本顯然是這個行業最大的成本,這個產品才有被開發下去的價值。後續的第二個衍生問題:引入該機器,是否可以瞬間大量降低工讀生人力成本?

如果不是。那麼開發這個機器也有大量的風險在。

開發者的迷思

純技術開發者常見的迷思是:也許我的某某創意,可以「顯然」的提供「某個市場」價值。於是就一股腦的投入,等到產品照自己想像的產規劃推出後,才發現市場不買單的機率超高。此時頭洗到一半,往往不知道要繼續做下去還是放棄。

解決的方法是:開發產品,你一定要先確定是這是真議題,真到目標客戶已經焦躁到處嚷嚷誰可以開發哪個工具,我馬上買。而且你也確定市場上,現有市場這類替代性方案,成本非常高。也就是開發的產品內容與方向符合止痛藥類產品。

總不能花上大筆成本,才做出一個沒多少人有購買意願的維他命產品。再抱怨自己的運氣不好吧?

Summary

很多人對於 Growth Hack 的幻想是:任意主題 X Growth Hack = 井噴。這是錯誤迷思。

我個人對於 產品 以及使用 Growth Hack 的建議是:

  1. 請開發「止痛型」產品
  2. 自己對目標市場有一定的專業
  3. Growth Tools 的價值在於拉近客戶距離,時時反饋修正
  4. 基於以上前提都紮實的情況。再利用各樣 Growth Hack 手段把大石頭搬開,達成業績井噴。

這是一套有系統有方法的市場行銷與運營技術,但前提是「開發者」「不能盲目開發產品」。

 
almost 3 years ago

我第一次接觸到敏捷開發這個詞,大約是 2008 年。本來剛入門對於這個詞是懵懵懂懂,但隨著經歷大大小小過百個專案,試過十數套專案進行方式後。在這七年當中,我逐漸累積建立自己一套系統性的心法與作法。

常有朋友問我「敏捷開發」要如何學習?

當然,最快的方式,我會推薦你來報敏捷專案管理班2015年版。這是許多專案血淚經驗以及書籍精華融會貫通的懶人包。大家最常問的一百多個問題,幾乎答案都在裡面。沒有那麼多時間自己讀書,或者衝不過鬼打牆的天險,報這個最快。

如果有時間讀書,其實我推薦大家自己研究以及實踐。

畢竟自己實踐出來的心得還是最牢靠。

回到主題,為什麼我要寫這篇「如何入門敏捷專案開發」?因為不少朋友想要掌握這門學問,卻因為網路上 google 到太多資料,不知道如何篩選。導入敏捷框架,反而沒有加速,還被團隊裡的反彈搞得鼻青臉腫。總而言之,走了很多冤枉路,所以我想寫一篇導讀,節省大家的時間。

1. 欲練神宮,必先自宮。第一件事:放棄學習專案完美規劃術。

下這個標題,我知道許多 PM 對於這件事,一定完全無法接受。

但在這裡,我也必須要告訴你一件殘酷的事實,這件事情沒得妥協。如果想要導入「敏捷專案開發」,團隊必須完全放棄由 PM 寫規格 -> 美術畫 Mockup -> RD 套版這樣的做事流程。

(如果你在這樣的架構下要導入敏捷開發,只會比當初沒導的情況下還慘,這就是為什麼有人會誤以為敏捷開發是半吊子沒用的技術。因為大家會以為不寫文件、亂寫文件,就是敏捷。)

我了解 PM 想學專案管理,進階技巧,甚至是學習敏捷專案開發。為的是「提前規劃」「巨細靡遺的不漏重點」「不讓大家浪費時間」。但是除非你做的是 repeat 性的專案(也就是你做過一次知道怎麼做了)。否則對於未知性的專案,這樣的方法只會越往反方向的結果走去(也就是越浪費團隊的時間,團隊成員對 PM 不滿的聲浪越大)。

而世界上大多數的軟體專案,處於「未知」的專案。專案成員(包括 PM)對於專案時程未知,耗用資源未知,專案難度未知。大家只明確知道一件事:「deadline」。

2. 敏捷三重點:消除浪費、過程透明、交付正確成果

當然,禁止了「走向完美規劃」這個方向,會讓很多 PM 大腦瞬間當機。因為這是一直以來大家對於「專案管理」的積極作法,甚至是終極方向。

那麼如果採用敏捷開發的方式又是怎麼做?

在談這件事之前,我想先來談談專案結束後,大家最挫敗的是哪些事?
我想應該是:

  • 在專案前期中期,錯誤的規劃方向大量的浪費團隊寶貴的時間
  • 在專案協作的時候,成員對於「規格」錯誤的「解讀」,導致不必要的「反覆大方向修改」
  • 交付成果完全錯誤。當初花了大把時間規劃出的東西,完全沒人要用,當初熬夜死線加班,好像夢一場。

也因為每次都會產生這三樣的挫敗,所以大家會一直想把原因歸咎於「當初沒有完美規劃,所以造成的災難」,所以解決方法就是「研究如何一開始就完美的規畫調查出詳細的細節以避免慘劇發生」。

PM 是專案裡面「最沒有實作專業」的人,PM 的工作是負責協調資源,而不是負責「主觀的翻譯」「主觀的下決定」

事實上這反而是錯誤的解法。「研究如何一開始就完美的規畫調查出詳細的細節以避免慘劇發生」的解法奠基於「PM 是全知全能的」。現實生活中,PM 反而可能是專案裡面「最沒有『執行實作』專業」的人。所以 PM 永遠不可能做到這件事情。

要讓專案能夠準確以及快速地前進,必須要仰賴於「有實作專業的人」,了解「正確要交付的結果」,才能辦到。

過去瀑布流的過程:『 PM 寫規格 -> 美術畫 Mockup -> RD 套版』,反而會造成了

  1. PM 花了太多時間以「PM自己」的角度,規劃了完全不接近事實的規格與進度
  2. 因為規格省略了「情境」,所以實作的 RD 以及 ART,對於規格有各自解讀的方式,以及實作的方式。在「沒有時間溝通」的情況下,交付了完全不能用的東西。或起了嚴重的爭執。
  3. 當初「規劃」的「進度」,完全是綁死在「每個里程碑皆能完美交付,並沒有意外產生」的情況下。忽略了專案進行其實有「溝通來往成本」,結果時間就不知不覺被揮霍掉了。

「消除浪費、過程透明、交付正確成果」的系統性作法

所以這些你在各敏捷領域看到的實際作法

  • Scrum 裡面提到的 User Story,其實是來解決「規格被各自解讀」的問題。
  • Kanban 的 Story Board,是解決「時間就不知不覺被揮霍掉」的問題。
  • Daily Standup 是解決「大家都不溝通,結果執行方向歪掉」的問題。
  • Integrate Early, Integrate Often 是解決「最後一個月才開始看到成果,所有人包括金主看到最後成果都大憤怒」的問題。
  • etc....

都是為了朝向:「消除浪費、過程透明、交付正確成果」的目標前進。

3. 引入專案管理工具是為了讓「進度透明、時限內交付、可追溯決策」

很多團隊引入專案管理工具,失敗的原因在於:這些團隊只把「專案管理工具」當作是派票(順便可以 email)的工具。

(所以很多執行者,只會在票的內容裡面寫 done)

而忽略了專案管理工具的目的是為了讓「進度透明、時限內交付、可追溯決策」。

反而不小心把專案管理工具將「原先要達到的目標切得支離破碎」,最後人人只 focus 在單項工作的完成,而忽略大局所要完成的「有效成果」。

專案管理工具的發明是為了要在龐大的專案待辦事項(幾百項)中,能夠讓專案成員繼續

  • 保持時間感
  • 階段性交付、階段性驗收
  • 緊密溝通
  • 決策回溯

所以在使用專案管理工具時,通常我還是建議要有自己的一套「切票工作方法」,配合這套工作方法,去對應相對的專案管理工具。

大中小團隊的管理方式以及拆分

專案管理工具有百百種。我會建議依照要完成的事的規模以及團隊 size 去選擇。

  • 小團隊,小事:Trello
  • 中團隊,中事:Brightpod
  • 大團隊,大事:Redmine、Jira

主要的心法在於

  • 小團隊只要用 Kanban 的方式去管。狀態:待辦、正在實作、完成。
  • 大團隊、大項目,則要用 Milestone 與 User Story Mapping 去切分。

4. 框架不是仙丹,專案加速不夠快不是你做的不夠徹底

敏捷世界裡面最有名最熱門的一套框架是 Scrum。這套框架讓許多團隊又愛又恨。愛的是裡面的確很多方法的確是有用的,很多方法卻是詭異到你根本不敢引入團隊的,而且引入以後也發現的確沒用的。

但是你卻不知道,哪一些招術是可用可以不用的,哪一些招術是你執行錯誤還是 Scrum 原先就設計錯誤。甚至是有些 Scrum 培訓老師還會說如果你引入 Scrum 無法加速,一定是你用的方式錯誤或「沒有全用」,需要再進修或者是整個團隊需要繳錢全部來上課。

更討厭的是,Scrum 裡面很多「規則」,團隊實際執行起來非常綁手綁腳,結果 Scrum 書籍出了一大堆「Exception」去解釋例外的狀況以及處理方法。

( 我個人的想法是正確的道理一定有一套心法說得通,如果這一套道理出了一堆 exception 集,一定是有一個核心前置設定錯誤了)

我在半年前寫的一篇文章如何同時執行 Growth 戰術以及 Project Management 裡面其實就有談到 Scrum 以 Product Owner 為 User Story 的主導角色造成的嚴重問題。

我的看法是你應該取敏捷框架裡面可以『消除浪費、過程透明、交付正確成果、驅動全體成員關心執行成效』的招數,而非所有招數照搬使用。

我建議取用的概念是

  • Standup
  • Sprint Planning
  • Scrum Retrospective Meeting

不建議取用的概念是

  • Planning Poker
  • Velocity
  • Burndown Chart
  • Product Owner

5. Deadline-Driven 與 MoSCoW method

以上講的四段,偏向原則。我真正用於實務最有效的主軸執行方法,其實是 Deadline-Driven 與 MoSCoW method。

Deadline-Driven

為什麼是 Deadline-Driven 呢?因為對於幾乎絕大多數的專案來說,幾乎只有 Deadline 是明確的,其他結構全部不明確。所以用 Deadline 去「倒序排定要完成哪些事」是最準確的,而非「順序去規劃」(只會嚴重超時)。

我在 三年前得到世界首獎的 Hackathon 就是用這樣的方式去管理七小時內的可用資源的。

MoSCoW method

MosCow Method 是把所有的需求照

  • Must have
  • Should have
  • Could have
  • Won't have

的方式區分。

這配合時間倒序的專案管理方式特別有效,在有限的時間內,會迫使人們去決定重要順序。如果是用正向順序進行專案管理,人們往往會將需求通通定義為「Must Have」。

推薦書籍

當然,以上談的通通是心法與關鍵字。如果真的進行深度研究,每一個主題領域都至少好幾本書專門深入探討該題目。我推薦有幾本「淺顯的聖經」是可以去翻翻的:

這三本都是 Mike Cohn 寫的,本本是經典。

至於如何與軟體開發搭配,有兩本心法書我是建議用來搭配:

兩本都是 Kent Beck 寫的。都是老書了。一本 2000 年一本 2004 。(所以敏捷不是新把戲了)

至於如何將產品主導權從 PM 交還到團隊成員,我推薦兩本書給你方向:

推薦課程

如果你沒有那麼多美國時間看完,我有一堂專案管理課:

建議有「現在就有打仗需求的人」直接來上 XD!我想你不會真的想真的去花幾萬在買書錢,以及花上三年慢慢把這些東西都練完。肝都先被操到爆掉了。

 
almost 3 years ago

去年我有一個班,比 Ruby on Rails 口碑還要好。這個班就是 敏捷專案管理班

很多人不知道,其實在我心目中,我認為自己的軟體專案管理技能其實還遠比我的 Rails 強悍非常多。很多外界的朋友知道我 Ruby on Rails 網站開發的無敵快,以為是純粹是 Rails 技術精熟的原因。其實,Rails 技術熟練只是佔其中很小一部分而已,真正的關鍵在於我關於規劃管理專案 Scope 與資源的能力非常強大。(這方面評價都可以問我過去的同事)

在執行專案的時候,專案管理才是最重要的,如果專案的資源與時程管控不當,任程式設計師開發速度再怎麼暴力(就算你是 Rails Expert),不可能在時程內完成就是不可能完成。特別是軟體專案通常不是一個人進行,而是十個人,二十個人,五十個人以上進行。

為什麼需要專案管理?公司人員成長所帶來的溝通合作問題

我以前在網路上粗略發表過幾篇我怎樣做專案的文章,後續也有一些讀者來信或者社群朋友求教。而我發現許多公司成長的痛點在於

  1. 團隊成長太快,沒有有效的工具管理需求。真的需求與假的需求混在一起,工作量爆炸。
  2. 即使篩選出真的需求,委派給工程師執行。但是執行到最後,進度與成果都歪到不知道到哪去了。
  3. 想引入專案管理工具,卻導入哪套好像都不對,沒有加速的感覺。很多同事開始覺得專案管理系統「只是派票」,被抱怨為何我不回去用 Email 回就好了。
  4. 已經固定熟練了一套專案管理工具,也開始有加速的感覺。但是每次專案還是 delay,專案上線後的總檢討,永遠是當初被路人塞進了太多假需求。但是專案很趕,老闆很硬,PM 很盧,莫名其妙就做了。花了大把時間,上線後才發現當初花很多時間做的是垃圾功能。
  5. 公司開新專案,PM 越熱心,我越害怕。因為他越想規劃得越仔細,我就覺得專案越可能 Delay(每次三個月工期,PM 總花兩個半月時間規劃,最後只剩10天時間逼我加班寫完)。有沒有辦法叫它們停止瀑布流式的規劃。
  6. 我對敏捷很有興趣,也去上了 Scrum 與 Kanban 的班。這些課裡面有些工具與工作模式很棒。但是有一些完全不合乎常理。硬導入公司,還被同事嘲笑很像扮家家酒。到底這些敏捷框架哪一些是可以用的,哪一些可以不要用?
  7. 我們公司導入了敏捷,剛開始成效還不錯。但後面敏捷好像毀了我們公司,RD 原本很關心公司產品,導入了敏捷之後,變得只願意跟 PM 講話,去溝通需求都是 PM 的事,不甘他的事。專案分工是明確,但好像後來越花越多時間在釐清幾句話的需求。越來越慢以及越來越被動,而且需求還開始一直做錯。

三個想達到的目標

  1. 不想盲目加班
  2. 不想老是 delay
  3. 不想老是做錯功能

2014 年版的軟體專案管理班

2014 年時我開的班,主要集中在以下幾個技巧

  • 控制專案 Scope 的技巧
  • 控制專案時程與風險的方法
  • 如何使用 Redmine,及利用 Redmine 大幅加速專案開發的速度 (切票派票沉票技巧、Milestone)
  • 如何結合 Redmine 與一般敏捷開發技巧如 Kanban、Standup、Git、Continous Delivery 和團隊協作工具,流暢地進行專案。

也就是傳授如何一套如何將專案催到極速的技巧。同學評價非常好。

2015 年版的軟體專案管理班

2015 年我對課程做了大改版。主要是過去的一年,管理台美兩地快速成長中的跨時區軟體專案,讓我在專案管理上又有非常大的突破與領悟。我希望把 2015 得到的經驗也帶入這個班裡面。同時去年上完之後,同學也給我了一些他們想了解的主題。因此在「原有的主題」之外,我還會加入了以下主題:

  • 如何挑選敏捷方案?敏捷方法的核心
  • 如何挑選「適合」公司做事方法與部門的專案管理工具。
  • 如何解決導入「敏捷」後期反帶來的「效率低落」。
  • 如何避免做到假功能,以及如何做到正確的功能。( PM 與 User 提出的方法是錯的。花時間做完上線反而被罵)
  • Growth Hack 如何與專案管理一起並行

這些主題我都設計了一套系統性的做法,解答這些問題。
這也是為什麼這個課程比去年貴一些的原因。

QA 問到飽

並且這個課還有一如往常的 QA 問到飽。我們最後一段都有非常充裕的 QA 時間,你可以提出任何的專案管理問題,我都會想辦法解答。很多同學都在這個階段(藉由別人的問題)得到很寶貴的收穫。

我摘錄一個同學的課後回饋是:「 Xdite 有問必答。這麼多奇怪的問題,竟然沒有看到他在 Q & A 被問倒,我覺得真的很屌」。

歡迎同學今年再來報名挑戰這個傳說。

適合報名對象

我認為這個班適合報名的對象,偏向軟體界。不過如果你不是軟體界,但對專案管理非常有興趣,還是可以來聽看看。我建議來報名的對象是:

  • 老是被專案搞到加班的 RD
  • 老是最後因為公司很操很瞎搞到離職的 RD
  • 想學習如何管理軟體專案的 RD 頭
  • 快速成長中的 Startup RD team
  • 覺得自己勞心勞力卻老是被 RD 幹翻的 PM
  • 好還想更好的專案管理狂熱者

一季只開一班,趕緊報名

這個班是每季才會開一次。下一次這個班開課的日期是 2016 年的 1 月。如果你被這些問題頭大了非常久,歡迎來報名解決困擾。

目前最近的開課日期是 10/9。目前 2015 冬季班正在接受開放報名,請趕快卡位:

http://www.growthschool.com/courses/agile_management

(目前兩人團報有優惠)

 
almost 3 years ago

一直以來,對日本商家的「印象」都是服務「設計」得很好,以及招牌「設計」的很棒。但是如何好法,總是沒有個頭緒。

日本服務業的心法

疑惑 1 : 日本的「服務好」只是「一種選擇性的 style」?

講到想深入研究,旁人總會丟一句「不用研究啦,那是日本人的龜毛性格,台灣人做不來」。

自從我體悟到「Growth Hack」的原則就是「把服務做好」後,就對於日本的實體與線上服務就開始產生好奇心。這次來日本旅遊也特別留心注意周遭的服務設計,想試試看到底可以取經多少。

自從我發現「設計 Landing Page」是一種必要的選項,不是「一種選擇性的 Style」後。我也不再相信「日本服務好」只是「一種選擇性的 Style」。所以想藉此機會重新研究日本的服務業。

疑惑 2 : 為何日本的商店招牌,走在路上總可以讓人不小心掉到坑被騙進去?

之前來日本的幾次感想,都是日本的招牌設計太強了。雖然花俏,但是總可以讓人不小心掉進坑裡走進去。走在整條都是餐廳 / 居酒屋的街道,總是可以讓人決策樹崩潰。

這次重遊日本我也想研究到底原因是什麼。

1. Landing Page 之上的 Landing Page

我在上課時,總喜歡將 Landing Page 類比為「店餐廳外觀內裝潢」。

這次來日本才發現,日本為什麼拐客人這麼強,是因為他們在「Landing Page」上還再蓋了一層「Landing Page」

這是我從九州、東京、東北,拍到的店家外招牌:

撞球間

小說店

雞肉燒烤店

居酒屋

可以看到他們都用了 Landing Page 結構做了包裝:

  • 一句話形容自己(對本店的形容)
  • 提供什麼服務 (直接秀食物)
  • How it works(直接拍餐廳內裝潢)
  • CALL TO ACTION (營業時間)(甚至有寫 Happy Hour 時間)
  • 消除疑慮 (招牌都會寫店內最大容納多少人,讓人不會有「店會不會滿了的疑慮」)

2. 高級旅店的 Check-in Onboarding

這次我來日本,有兩天是住了超過五萬日幣的高級溫泉旅館。一間是在箱根的「箱根吟遊」,一間是在函館的「湯之川 渚亭」。這兩家都有類似的 check-in 流程。

因為我是一個禮拜內連續碰到,發現這已經是一種 check-in 的 best practices。而且跟 growth hack 的 onboarding 概念是一樣的。

超高級旅店如何做 onboarding

1. hand-free

這兩間的飯店的 checkin 流程是,首先是到了飯店以後,行李就可以放手了,有人會幫你提。然後來人會先幫你提到 check-in 處。

2. welcome-drink first

check-in 處是小小休息桌,然後第一件事不是叫你拿 id,而是問你要喝什麼歡迎酒 / 飲料。坐下來看風景聊天。會有好幾桌。這樣就算很多人同時 check-in,旅客也不會不爽。

3. personalize check-in

然後快喝完時會有專人帶著筆電來服務你,這時候才會請你給 passport。都辦完了之後,

4. personalize guide

會有另一個專人帶你去房間,一樣這段是 hand-free,還是會有人有幫你提行李。進房間之後,專人會幫開始介紹房間各項設施怎麼用。進房前,則是會介紹路過的公共設施要怎樣用。然後跟你 book 吃飯時間與鋪床時間,才離去。

Summary

我實在很慶幸當初去學了 Growth Hack 這門學問。原本在沒有接觸這門學問以後,我認為許多服務的「好」,只是「一種選項」。後來瞭解了原理之後,現在參觀任何「傳說中」的好服務都會放心思在看主辦方的細節,到底是真心設計還是只是搬弄照抄。又有什麼好技巧可以師法學習。

特別是又來了「好服務」的大國「日本」。走在街上,真是特別多靈感。