over 1 year ago

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

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

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

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

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

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

Read on →
 
over 1 year 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 (看到有朋友轉文時得精彩衍伸)

 
over 1 year ago

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

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

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

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

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

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

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

5 C of Channel Decay

Read on →
 
over 1 year ago

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

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

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

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

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

Read on →
 
over 1 year 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 2 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 2 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 2 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 2 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 這門學問。原本在沒有接觸這門學問以後,我認為許多服務的「好」,只是「一種選項」。後來瞭解了原理之後,現在參觀任何「傳說中」的好服務都會放心思在看主辦方的細節,到底是真心設計還是只是搬弄照抄。又有什麼好技巧可以師法學習。

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

 
almost 2 years ago

之前有朋友希望我多寫一些 GH 實際案例,不過我手上有些 showcase 有綁 NDA 無法公開展示。想想,不如來寫「解構」系列,透過解構業界知名 GrowthHack 團隊怎麼樣設計系統,讓大家一窺後面的手法。

最近在旅行,住了不少 Airbnb 上的房子。剛好 Airbnb 的 GrowthHack 團隊是出了名的強,最近在被 Airbnb 催寫房客評價單,覺得這套系統真是設計的超漂亮,決定這次來解析他們的設計手法。

郵件不斷地提醒

首先,透過郵件不斷的提醒,在十四天內要寫評價。而且是雙向提醒,也就是如果你不寫評價,若房東有寫你的評價,你也會看不到。

強調是貢獻社區,而不是單向的被要求給 Airbnb 改善建議

提醒消費者,Airbnb 的社區改善(Traveler 與 Host 的 plan ) 是建立在大家的誠實 Review 回饋上改進。讓你覺得不貢獻有罪惡感。

將問卷分段

問卷採分段式填寫,非冗長式的一次填到底,讓住客有興趣繼續填下去。這種透過 Gamification 的手段,通常比較常見在商店購物車結帳中。即使是複雜的填寫,也會讓人有動力填寫下去。

將體驗與 Feedback 切開

設計三欄,讓消費者明白「體驗」與「小差錯」以及「相對建議」應該分開寫。

這一點要是 App Store 或 Google Play,可以改採用這樣方式的設計,可以降低很多莫名其妙的1星,而且開發者能夠得到真實建議。而非憤怒的一星意見「老是 crash」。

細節評價

  • 協助房東在各方面改善的更好
  • 如果不好,以消費者的觀點應該「怎樣補強」
  • 是否推薦朋友來這個房源 ( Y / NO )

是否提名房東參加 Airbnb 大獎

  • 是否提名 Airbnb 參加最佳房東(未必是一件真實的比賽),但能驗證你推薦此房東是否真心。
  • 前面跟房東談了他應該知道的事情,接下來跟 Airbnb 談談這個房子 / 房東的狀況。

插入 NPS 問卷

我上個月在這篇,Referral 重要的指標:NPS 文章中談了 Net Promoter Score。

相較於很多團隊總在突兀的時刻,送出 NPS 調查。Airbnb 很準確地在消費完畢後的問卷插入 NPS 問卷。

提醒 Review 是雙向的

  • Review 是雙向的
  • 如果你不寫 Reivew, 房東寫的 Review 你也看不到

跳回 Dashboard 之後再請使用者做一次 Referral

之前的一篇文章中 Build proper Referral Program,我提到 Referral Everywhere 的重要性。

Airbnb 又做了一次精確的 Referral everywhere, 塞到了精準的 Referral 時機。

跟傳統的旅館 Review system 差異

我在體驗 Airbnb 房間後,過幾天跑去住了「箱根吟遊」,算是非常高級的旅館。這是他們合作的線上訂房網的 Reivew Request。

Summary

Growth 是 Conversion Rate - Churn Rate。

降低 Churn 的手法,在於能真實的聽到顧客心聲,改進。且在聽取使用者心聲時,小心地不觸怒顧客,且得到非敷衍的改進意見。從而改進服務,增加 Conversion Rate。

在這份問卷上,可以看到 Airbnb 在設計問卷時,深深的經典巧思。所以拿來頗析,分享給大家。