over 1 year 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 手段把大石頭搬開,達成業績井噴。

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

 
over 1 year 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!我想你不會真的想真的去花幾萬在買書錢,以及花上三年慢慢把這些東西都練完。肝都先被操到爆掉了。

 
over 1 year 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

(目前兩人團報有優惠)

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

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

 
over 1 year 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 在設計問卷時,深深的經典巧思。所以拿來頗析,分享給大家。

 
over 1 year ago

我在兩個月前寫了一篇文章Growth Hack : Build proper Referral Program,簡單講解了設計 Referral Program 的一些簡單要素(小懶人包)。

今天要來探討,什麼樣的狀況才適合啟動 Referral Program。

照慣例先講結論:產品必須要在 PMF 情況下,設計 Referral Program。 Referral Program 不會幫忙達成 PMF。

為什麼有些服務會使用 Referral 取代下廣告?

Referral 是常見的行銷手法。商家會用 Referral 式行銷的原因很直覺:

  1. 行銷成本遠較一般廣告成本低。
  2. 朋友推薦朋友速度快,在信任程度高的情況下,轉換率通常非常高。

不過常見的謬誤是,有些行銷者會得出這樣的結論:「任何商品」 X 「Referral」=「病毒式增長」。

Referral 使用的條件與時機

事實上用 Referral 的條件有幾個,否則實際上 Referral 非常難啟動。甚至還可能不但啟動不了,反倒引火自焚。Referral 的條件與時機如下:

  1. 產品一定要已經 Product Market Fit 。
  2. 產品給的 Referral 的 discount 至少要高過產品本身訂價或服務量的 10% 價格或至少提供 10% 服務量。
  3. 產品要 Net Promoter Score 夠高,才有辦法啟動,甚至「才不會造成反效果」。

1. 產品一定要已經 Product Market Fit

為什麼要 Product Market Fit?Product Market Fit 後,通常代表你提供的服務已有「穩定的服務品質」,穩定的利潤。

1) 要做 Referral 之前,產品品質一定要維持一定,否則口碑行銷容易出事。(消費者總不希望推薦朋友去使用一個服務,然後那個服務砸鍋,從此搞砸信用吧)

2) Referral 也是廣告的一種,你還沒抓熟成本。不知道 Referral 會不會造成澇賽,一 Referral 下去甚至有可能入不敷出,甚至倒閉。

2. Discount 設計一定要過 10%

那些用 Referral 很兇的 Dropbox, Airbnb, Uber, 無疑的是獨角獸。但你也必須注意看他們提供的 Referral 內容是什麼?

Yes.

1) over 10 % 的 discount。
2) 有品質的服務
3) Referral 成本對服務提供者來說減損到純利的狀況是很少的。

為什麼要 over 10% 的 discount?這樣消費者才會真正覺得,推廣是對我有好處也對朋友好處的。

我從Gogoro、Tesla 與直銷的競爭優勢 一文,觀察到某 G 牌機車在做 Referral。事實上我不太知道他們想幹嘛。G 牌機車,一台 12 萬 8 ,送一個月電池服務(大概折台幣 1000 吧)????老實說我不知道這到底會吸引誰去買誒。(這到底哪個天才設計的?)幫你推廣的消費者搞不好甚至覺得都不敢跟朋友推薦吧。講這樣的方案內容可能還被笑死 =_=

老實說, G 牌真要做 Referral 的話送一萬折價卷大概才會有消費者鳥你吧,我說真的。

但這又要回到,G 牌是否有 PMF, 1 萬才有動力,但是利潤根本沒有 1 萬啊。

另外一件事值得一提的是 Tesla 雖然推薦一個人是 1000 美金。(動力雖然對車主沒有很高)。但推薦到 5 台以上是贈送「稀缺資源」,這才是強烈動機。(這是另外一種 Referral 密技,我有空再講)(拜託 G 牌不要再送保留號碼,大家都知道你們車子沒賣完...)

3. Net Promoter Score

這是做 Referral 前最重要的指標了 超重要超重要超重要 要講三遍

Net Promoter Score 就是「願意幫你 Promote 的顧客分數」。Referral 能夠 Run 的前提是 NPS 要高,就我的經驗,分數要高到 5 以上。

如果你有興趣瞭解更多 Net Promoter 原理的話,細節可以看這篇:http://blog.clientheartbeat.com/net-promoter-score/

NPS 的運作方式,是送一個 1-10 分的問卷,只問一個問題,「你會不會推廣這個服務給朋友,為什麼?」

如果你的 NPS 不高,千萬別推 Referral ,因為

1) 輕則推不動。(我覺得這服務還可以啦,但是價格太高,不一定每人都需要)
(只要有「可是...」,服務提供者就要盡力去修)

2) 重則反效果。「笑死人,那麼貴那麼爛的服務還要做推廣,這種折扣貼出去超丟臉」。你寄希望幫忙做 Referral 的信給使用者,憤怒的使用者甚至會覺得他們被你騷擾了,開始幫你反行銷。

矽谷現在甚至有專做 NPS 的服務叫 Delighted https://delighted.com/

所以通常做 Referral 之前都會先 run NPS,而不是盲目的做 Referral。以免賠了夫人又折兵。

提供想設計 Referral 的人一個參考。

結論

產品必須要在 PMF 情況下,設計 Referral Program。 Referral Program 不會幫忙達成 PMF,切記。

 
over 1 year ago

兩個禮拜前,我寫了一篇 HomeJoy 陣亡的討論。今天我要寫另外一個面向的探討。就是 HomeJoy 究竟怎麼死的。

在這個切入點之前,我必須要先談 YC 與其他加速器最大的不同:他們的加速器不教別的,教創業者「Growth」。

創業者只需要學會「Growth」

市面上有很多加速器,坦白來說你也不知道他們在加速什麼的,有些你加入了反而「減速」。

好,不多扯這個主題了。每個加速器不太一樣,有的教你怎樣造 Traction,有的教你簡報技巧,有的教你募資技巧,有的帶你大量曝光。

但真真切切的,報名加速器的創業者真的需要什麼,就是學會「怎麼做生意」,然後「成長」。

(所以不是教你做生意的加速器,就省點時間別去了....)

創業「無法」也「不能」 Game the system

PG 本人說過 ": starting a startup is where gaming the system stops working."。他認為創業是唯一個無法靠作弊成功的領域。

何謂 Gaming the system?就是像你上大學,大部份人考試考高分,並不是真的了解這門知識,而是知道「教授會考什麼」。你知道教授想出什麼會出什麼,所以你考高分。

但創業不是這樣,他無法靠「game the system」達到你想要的終點,你如果始終想要 "gaming the system",這個心態會殺死你,只是死的時機點而已。

而 HomeJoy 就是這當中的一個例子。

HomeJoy 倒閉的真正原因:「Growth X Game the system」

雖然創業不能 Game the system,但 YC 還是找到了一顆「北極星」,那就是 Growth。並把這整個概念覆蓋到他們旗下的 startup 下。

公司圍繞著「成長」這個概念,可以讓創業聚焦。因為你要想辦法達到成長,所以你就不會浪費力氣在 big bang 式的媒體曝光,或者是砸大錢在廣告上。創業者會開始注重在產品的 AARRR。

好。那 HomeJoy 出了什麼問題呢?

OK。你要想想 HomeJoy 什麼時候從 YC 畢業的呢?2012 年七月。距離現在多久?三年。

三年拿到 10 億台幣資金,然後擴張到 31 個城市的 B 輪公司。你覺得這門生意是擴展的太成功還是太奇怪?創辦人才 20 幾歲。

這看起來反而像是類固醇打過頭的公司。

實體辦公室的迅速擴張

1) 首先軟體公司暴發式成長的公司不是沒有。但多是「純軟體」居多。就連當年爆發性成長的 Facebook,都沒有「實體 Operation辦公室」的快速擴張。但是 HomeJoy 擴張了 31 個點。

小孩玩大車,人數的迅速擴張

2) B 輪公司大多在 150 - 300 人規模。兩個年輕人要怎樣從只管 5 個人迅速「心智」上成長到可以管 150 人?
管 5 人,10人,20人,50人,100 人,500 人,都是不同等級的難度,需要時間與歷練。

而且還是 Operation-oriented base 的公司。

如果你上 HomeJoy 的 Glassdoor 一定可以看到類似的抱怨(對幼稚管理層的瘋狂抱怨)。而且還會是滿滿一大堆。

瘋狂盲目地燃燒資金,用「成長」去吸引下一輪投資者

3) 2012 開始剛好是 Uber like 的大爆發年,所以該年開始,只要你的題目是 Uber for Anything,都很好拿錢。消費者也很容易買單。

因為消費長也想要買單 Uber for everything。所以相關 O2O 題目瘋狂的爆發。錢變得很好拿。成長曲線也會很漂亮。(因為市場上從未有這一類的商品)

但是這就又燒出一個隱憂。拿到錢的人真的懂這個 Business Model 的成本結構嗎?

(當然台灣環境比較悲哀啦。所以根本沒有「拿到錢」的煩惱 XDDDDDD所以做 O2O 的通常是 run 幾個月就血流倒地了。)

矽谷都是燒錢式的把 business model 燒出來。不過這在 O2O 這一個領域開始踢到了大鐵板。Operation 真的非常非常非常非常地燒錢。

而且非常非常燒管理人才。我認為矽谷這樣 O2O 繼續玩下去,operation 的人才搞不好現在大概跟 Software Developer 一樣搶手吧。

清玉迅速展店都還是加盟主捧錢給總店,加盟金還是天價的高,都會迅速崩潰了。更何況是自己拿錢到處砸開「加盟店」。我想用這個例子你更能明白 HomeJoy 發生了什麼事。

一旦 retention rate 很低,幾乎就是賣 1 單賠 5 單吧。

不過 HomeJoy 需要錢,也有投資人的壓力。怎麼辦呢?反正他們有 Growth 曲線,就是繼續去募,他們也募到了 B 。
在這過程中,他們有思考自己的 model 問題在哪呢?我想應該也是沒有。

不然擴張 31 個城市還擴到其他國家(美國英國加拿大法國)這件事,看起來很屌,實質上在運營管理上根本像神經病一樣。矽谷很多觀念是很先進很成熟,但這是超越物理極限的事(需要大量管理人力以及運營經驗堆積),是不可能做到的。

HomeJoy 就如同他的僱員和同業批評的一樣:「盲目擴張,盲目追求增長」

一旦募不到下一輪,就趴了。

結論

O2O 雖然挑戰門檻極大。但並非不能做的生意。

Homejoy 的 CASE 正像海水退潮就知道誰沒穿褲子。接下來 O2O 界相信應該會有一系列海水退潮。

我自己覺得可以從 HomeJoy 這個例子裡面吸收的是:

  1. 要創業,慎選資金,沒辦法幫自己成長的資金與加速器少拿。
  2. Focus 在 Growth,可以省走歪路。
  3. 人員擴張,運營擴張,是成長結果不是成長手段。
  4. Never game the system

共勉之。

 
over 1 year ago

我今年下半年重開了去年評價很好的 Rails 商務網站 x 即戰力班。開這個班的目的,是為了讓市場上多一點即戰力能戰鬥的 Rails Developer。

目前口碑蠻不錯的。

課程內容以及設計理念

雖然網頁上我已經有公布上課大綱是什麼。不過有朋友還是希望我解釋一下這是在上什麼。所以我就大致上寫一下:

第一週

第一週我會教新手,「軟體規劃」,以及「規劃完怎麼樣慢慢實作完內容」

這是過去我訓練過幾十個 Rails Developer 發現大家的共同罩門。很多人學完坊間的 Rails 基本教材,會操作基本的 API 了。但是對於「要重新寫一個自己屬於自己的 App」有困難。

其實不要說自學了,就連許多公司裡面新雇用的 Rails Developer,很多人頭三個月都還只能實做「單項」簡單的功能,沒辦法說「規劃一個整塊功能」,在限時內寫完。

這就是我第一週想要傳授的能力。這個能力會在後面的課程中一直反覆的用到。

第一週其餘的內容,都會圍繞著

  • 「軟體規劃」
  • 「如何圍繞著軟體規劃,慢慢把軟體疊出來」
  • 「利用 gem 實作功能」。
  • 「如何問出不會被鄙視的問題」

同時鼓勵大家下課後去參加社群,寫作業,問問題。

第二週

第二週,份量會變得非常的重。

主要是「規劃一個整塊功能」並實作。
從 Helper -> View -> Controller -> Model 逐層的深入設計。同時透過這些一個一個功能,把 Rails 常見的功能觀念一個一個帶進去。

這一週的主題是

  • 實作購物車
  • 結帳
  • 生成訂單
  • 切換訂單狀態

同學會學到

  • Helper 常見設計方法
  • Model 常見設計方法
  • Controller 常見設計方法
  • 怎麼樣拆架構,「跳開還沒有頭緒」的架構

第三週

第三週呢,我們實際介紹如何介接「第三方服務」,以及處理第三方服務需要處理的問題。再來,因為前兩週我們把程式寫得很亂了,怎麼樣整理程式碼。

這一週的實戰主題是「寄信」以及「實際付款」以及「部署」。

  • 寄信是教 Mailgun
  • 付款是教 歐付寶
  • 部署是教 Heroku

部署這些第三方服務還會有一些「開發環境」與「正式環境」的差異。我們教如何處理相關的疑難雜症與 debug。

整理程式碼部分我們會教

  • View
  • Controller
  • Model

的相關 Best Practices 收納術,以及整理心法。

第四週

第四週呢,我們教實際從業 production 環境會遇到的各種挑戰。去年我們教了

  • 簡單的 SEO 與 Facebook Opengraph 資訊
  • Frontend 怎麼樣提升效能,
  • Backend 怎樣提升效能,簡單的資料庫設計以及索引原則,怎麼要找效能瓶頸點。
  • 開發時需要注意的簡單安全性問題
  • 求職履歷要怎麼整理

今年這些全部都會教。

另外我還會多教一些簡單的 MVP 與 Growth Hack 實戰。讓你知道一開始哪些產品功能可以先做,哪些不用做。還有簡單的推廣產品技巧。

為什麼這樣設計?

這套課程,內容都是一個 Rails Developer 從業 2-3 年(還未必會全)學到的課題。目前是沒有一本書以及線上教材所可以提供的。全是從我 Rails 從業八年來帶過非常多 Rails Developer 的 Training Cycle 所萃取出來的。

所以如果要說這個班跟其他人有什麼不同。

1) 首先,雖然我們上課只有四周,每次只有 3 小時。但是這 3 小時不是講一些 「網路上就找得到的基礎教材」灌大量時數。我們是教書本上沒有的東西,鐵錚錚的實戰累積經驗。

2) 我們上課是高度互動。學生一定要留時間寫作業(下課要至少寫3-6小時的作業,有解答),下課還來 meetup 問助教問題。每一上上課就能帶很多高度半成品的東西回家。

如果你有點子想自己實作,按照類似的架構就可以搭出有模有樣的東西。

而不是只教你單一個功能,你根本不知道為什麼會這樣設計。(如果要學這種東西,Railscast 很多)

3) 我們教的整理術是 rails 圈內已經演化到有最佳解的東西。所以學生不用浪費時間重新再進行這個 cycle 一遍,還不一定有方向。

這個班從設計的宗旨開始就是要教出:錄取後馬上可以打仗的人。不管是你想要換工作,或者是做自己產品,都可以自己有方向快速上手。

我們不會唬爛你說出來可以變即戰力,事實上每週都在教你網路上的 101。

趕緊報名

這個班是每季才會開一次。錯過了就要等上 2-3 個月。每次開放都是幾天之內就爆滿。

目前 2015 冬季班正在接受開放報名,請趕快卡位:

 
over 1 year ago

昨天剛傳出 HomeJoy shutdown 的消息。雖然行內認為這篇資訊已經夠多,但是我認為還是可以寫出更深一點的評論。

(P.S. 筆者曾在矽谷 O2O A 輪公司任職,擔任 Engineering Lead 且設計主導重寫擴展過整套 O2O 複雜的商業系統架構)。

這篇文章太長,所以我先寫結論。

  1. 如果你只能賭一家 O2O 公司,賭 Uber。如果你能賭第二家,賭 Airbnb。
  2. 初次創業者,不要來碰 O2O。必死。這行不是寫個 "Google Map" + "Billing" 就可以開始賺錢的行業。
  3. 在台灣搞 O2O,嗯...。(我不想直接寫會引發地圖砲的字句)
Read on →
 
over 1 year ago

幾年以來,我在執行專案時,一直是使用「使用者故事」的方式,與團隊一起進行敏捷專案開發。

開發專案時,捨棄寫 Spec,而改由撰寫「使用者故事」。可以讓團隊釐清,整個專案有多少角色,在什麼場景,執行什麼功能。我們再針對爬梳出來的 User Story,進行資源以及執行期限的限制篩選。擬定可以執行的方案。

但是,後來這一套方案在特定的狀況下遇到嚴重瓶頸。我們公司的架構當時是分隔台美兩地。Product Owner 在美國協助整理使用者需求,台灣團隊收到後執行。但是,以往管用的招式在此狀況下卻不管用。

原因是以前如果開發團隊都在同一個辦公室,使用者故事上「沒寫到」的細節或原始情境,透過快速的口頭補述交流,就可以補完。專案不至於執行偏差。但是在團隊分隔兩地的情況下,因為時差與團隊成員功力差異,許多「需求」的「原始情境」會消失。

「使用者故事」變成 Product Owner 的一面之詞,他憑著「自己的判斷」以及「喜好」,寫成了「無原始背景」的技術性用戶故事,加上公司又是 Operation-Oriented,有些細節必須要是在現場才會知道。這些「重要的細節」隨著 Remote 與溝通不良被蒸發,於是「使用者故事」又變成只是「簡單版的 Spec」而已。這讓團隊之間,摩擦又開始變得很大。

於是我掙扎著又設計協調出另外一份問題解決結構,搭配 User Story 執行。方式是這樣的:

  1. 我們遇到了什麼問題?
  2. 為什麼這件事會發生?
  3. 我們目前的限制是什麼
  4. PM 建議的解決方案
  5. (召集相關的開發成員)大家建議的解決方案是什麼
  6. (召集相關的開發成員)簡單的 vote

這份敘事的結構,目的有幾個:

  1. 讓「原始目的」與「原始情境」儘可能的被重現
  2. 讓團隊了解這個問題的資源限制,以作出最好的建議(一天之內要解決?一週之內要解決?或放著想根本沒差)
  3. 讓相關的成員有參與感,以及可以激盪出最好最適切的解決方案。(透過 Hackpad 討論,所以來回不會很冗長,通常一個工作天內會結論與表決同時出爐)。而不再是 PM 的一面之詞。

我們成功用這個架構 deliver 了很多大大小小 tricky 的專案。

本來我們也以為這套方案是獨家發明,後來跟一個朋友聊天分享過後。才發現這其實已經是麥肯錫內的架構解決 Best Practices 了。我在麥肯錫新人培訓七堂課 這本書內有找到更多這套方法的敘述與強化。

以下整理出方法重點:

1. 解決真正的問題

比如說老闆抱怨「最近生意不好」,所以我們要搞個「促銷」。此時重要的不是真的去寫「促銷」的 User Story。而是去找出「生意不好」是指「來客量不高」,還是「單個客人貢獻營業額不高」。

2. 定義問題、假設與分析、解決策略

執行這個步驟的重點在於「分離現象和原因」。利用邏輯樹找出問題結構後

  • 生意不好
    • 來客量不高
      • 每個客戶平均成交率低
      • 沒有花新力在開發新客戶
    • 單個客人貢獻營業額不高
      • 單品平均銷售額沒有增加
      • 顧客平均購買量沒有增加

然後再找出什麼是最重要的議題。(因為沒有美國時間一個一個去做)

3. 根據團隊目前限制針對最重要問題設計出有意義的解決方案

因為產品開發不可能無限制發散討論。一定要有得收斂,且要在「一定時間內」完成,否則超過時間限制,原始的討論也會變得一點意義都沒有,而淪為純清談。

解決問題時必須注意到的重點

  1. 不要受眼前的狀況和條件所限
  2. 經常意識到邏輯思考
  3. 不斷問為什麼?
  4. 為什麼?做什麼?怎麼做?

「為什麼?做什麼?怎麼做?」

在商場上,這三個問題就是把「哪些產品與服務,透過什麼方法,提供給哪種類型的顧客?」只要這三個問題沒弄清楚,就會搞錯方向,浪費資源。

這也是當初我們單純只讓 PO 使用「User Story」單純敘事的缺陷。

PO 少告訴了大家「為什麼?」,而 PO 單方面的決定「做什麼?」「怎麼做?」。

這個方法是一個把產品所有權回歸到整個團隊的好方法。

推薦給大家使用。

 

宣傳連結

  1. 免費 Rails 學習手冊

    Buy Rails 101
  2. Intro to Growth Hack


    Growth GrowthSchool

    預購 8 折 中