about 2 years ago

Davc McClure 曾經分享過一張關於 Marketing Channel 的難易度分析表

The Missing Trick : Referral

在這張表裡面,最簡單(綠色)的幾個技巧, 大家都耳熟能詳,也用的很熟練。

  • Email
  • Blog
  • SEO

唯獨 Referral,大概需要實際寫 code implement,所以比較少人討論。

但很少人知道,事實上 Referral 才真正是 startup 形成病毒傳播的必備武器。如果你觀察目前 YC 底下最值錢的兩大 Startup,可以發現他們剛好也是目前 Referral Program 做的最好的兩間 Startup: Airbnb 與 Dropbox。

事實上,目前事業擴產版圖越來越瘋狂的 Uber 也是愛用 Referral 一族。

How to Build Referral Program

Referral Program 主要有幾種玩法

  • 給 $10 折價卷
  • 給 10% off
  • 集滿十點免年費

透過消費者邀請朋友,給予雙方一定的折扣,造成自然傳播效應。

如果你不熟悉怎樣建制一個 Referral Program,其實現在這個產業也成熟到發展成獨立的 SaaS 了,我知道主要最大的有兩間:

這兩間幾乎都把建一個 Referral Program 需要面對的挑戰與機制做好了。比如

  • Fraud Preventing
  • Referral Analytics
  • Referral Widget
  • Billing Intergration
  • Well-documented API

如果你懶得寫那麼多 code 的話,其實直接整合現有服務也可以。或者是不知道怎樣的 Referral 實務才是最好的。直接抄他們 Widget 的設計或者是看他們部落格分享的 Tips,因為這都已經是產業 Best Practices,人家賣的就是把 Best Practices 自動化的產品。

Referral Checklist

雖然 Referral 「看起來」只是一套推薦朋友送折價卷的系統而已。但其實這裡面有不少學問。我整理一些必備的「檢查表」在這裏。

1) 自動產生的 referral code 建議不要是亂數,而是要貼近這個人的名字(可以靠 Facebook Login 或者是姓名用演算法做),且要提供給 customer 可以修改 referral code 的機會。

像我的 referral code 就是 http://www.airbnb.com.tw/c/ycheng267?s=8

2) Referral 要有自己的 Landing Page。這樣被介紹的人連過去會有親切感,而不是一個冷冰冰的創造帳號頁面。(所以 Airbnb 推薦各位用 Facebook Login 是這個原因)

3) Referral 要有自己的 open graph image,這樣在 Facebook 上才有傳播效果。

4) Referral 遊戲規則。要清楚易懂,而不是藏在一堆 Terms 裡面。

5) Referral Everyhere, Account 頁面要做,Receipt 要做, newsletter 要做,最好是要有個客製化的專用 Footer。

比如 Airbnb 就會把它們 想要客戶最想要做的三件事 做成一個客制的 Footer,到處插洗腦新用戶。

6) 讓 Referral 變成任務 ( Gamification ),設立 dashboard,讓 customer 有「完成」的動機。比如說 Referral 做成 Give $100 , Get 100,而不是 Give $10, Get $10。

(Dropbox 會用火箭當進度)

當然還有更多其它技巧,比如說改善 Referral Landing on Mobile 到開啟帳號的流程等等一些細微的部分,不過這是最主要的幾點。

各位對這個話題有興趣的話,之後如果有時間我還會多寫寫這個話題...

 
about 2 years ago

六月底會回台灣一趟,朋友盧我開一場講 Growth Hack。

以下是報名連結:http://rocodev.kktix.cc/events/growth-hack-intro-02

時間:7/1 晚上 19:15 - 21:00
地點:CLBC 大船艦 / 台北市松山區八德路四段 123 號 3F

《 適合參加的對象》

  • 自己已有網站或者是 App 的開發者
  • 稍微懂一些技術的 Marketer
  • 對於用數據做 MVP & UX 有興趣的開發者

《 演講內容 》

這次演講大約 1 小時,會後交流約 45 分鐘。

  • What is Growth?
  • What is Growh Hack & How to do Growth Hack?
  • Measuring
  • A/B Testingu sing Optimizely
  • Metrics-Driven Marketing
  • Re-engaging Customer using Customer.io
  • Referral Best Pratices

《 費用 》

門票:2000 元 (含晚餐)。座位有限。

報名連結:http://rocodev.kktix.cc/events/growth-hack-intro-02

 
about 2 years ago

根據維基百科。「Growth Hack」的定義是「技術創業型團隊通過數據分析和量化指標來推廣產品時所使用的一種市場營運技術」。

坦白說,這一串看起來是中文,但是對於沒做過 Growth Hack 的人,看起來跟火星文一樣。

Growth Hack 場景

我換個 Growth Hack 場景會發生的事,讓讀者比較有點頭緒:

「今天一些訪客到你的網站點擊了『註冊』按鈕,開啟了一個帳號,你也『察覺』到了他們訪問了『Pricing』的頁面,但在『一周內』這些訪客竟然沒有升級。發現「轉換率」竟然超低,0.5 % 不到。

你想問問他們阻止他們進一步的行動在哪裡。從「有開信回覆」客戶,回應得知是 C/P 值不夠好,你想 A/B Tesing 策略『多送一個月會員』,『給 10% coupon』,試試看哪種策略見效。『沒開信』的客戶,直接再『送兩個月會員試用』。

以上講的事情全是全自動發生的。

這樣的場景,在傳統 Marketer 來說是完全無法想像的事

  1. 要如何追蹤一系列這樣的行為?
  2. 要如何全自動做到?
  3. 這樣的技術團隊要多貴?

所以多數的 Marketer 追求的是「曝光」追蹤,測試不同曝光手段不同文案的轉換率。但是在曝光以後的階段,他們完全無能為力。所以市面上絕大多數的 Marketing 都在談「曝光手段」的極致化。

但等等,Growth Hack 的定義是:「技術創業型團隊通過數據分析和量化指標來推廣產品時所使用的一種市場營運技術」。『創業』????

這種手段怎可能是『創業』團隊做到的事。

Well,其實理論上和實際上是做的到的。接下來我就會簡單敘述這要怎麼做。

資料收集

在做 Growth Hacking 時,一般人比較少用 Google Analytics,比較常用的是 Mixpanel

Mixpanel 做得更多是對用戶行為的「描繪」。做的方法是這樣的,開發者針對網站或 App 上所有「Click」,「Submit」,「Impression」的 Event 做埋 code 監聽。(這需要 JS / iOS / Android 技能)

當使用者觸發這些動作時,client 會將事件傳回去事件中心。所以透過 Mixpanel 這個工具,可以具體描繪出用戶在這個網站上的軌跡。

透過「Funnel」(漏斗)可以測出每一個階段的「轉換率」。

而使用者真正下單之後,對後端服務 submit order 後,網站之後也 submit 一個事件回去記錄使用者已經下單了,這次下單購買什麼。(工具都會提供 identify 這個動作,所以有辦法準確記錄前端的某個 session 是後端的某一個人)
收集了這些 Event 之後,以下這個敘述的場景就不難做到

「今天一些訪客到你的網站點擊了『註冊』按鈕,開啟了一個帳號,你也『察覺』到了他們訪問了『Pricing』的頁面,但在『一周內』這些訪客竟然沒有升級。發現「轉換率」竟然超低,0.5 % 不到。」

然而,我們也不會單只用 Mixpanel 這套工具。如今具體而言,Growth Hacker 都會使用 Segment.io 這套工具去蒐集 Event 。Segment.io 的優勢就是整合了很多服務,只要搜集一次資料,就可以一次同時倒入很多 Growth Hacking Tools。

搜集到了這些 Event 之後,會再利用類似 Customer.io 這種工具,將 Event 匯入建立描繪出個人 Profile。

如此一來,就可以利用 Customer.io 上的這套工具,精確瞄準出(用界面選單方式,精確 Select )出你要 Target的人。在「固定週期」內對這些猶豫不前的客戶進行臨門一腳的「推坑」。

Automated Targeted Email

以下這個敘述的場景在 Customer.io 上真的是可以實際做到的。

「你想問問他們阻止他們進一步的行動在哪裡。從「有開信回覆」客戶,回應得知是 C/P 值不夠好,你想 A/B Tesing 策略『多送一個月會員』,『給 10% coupon』,試試看哪種策略見效。『沒開信』的客戶,直接再『送兩個月會員試用』。」

所以創業者就可以輕易做到這些事:

  1. 針對那些每次只買一件的人,推送買一送一訊息。
  2. 請那些「常客」,推薦其他朋友來買,送他 credit。
  3. 地區性限時打折。
  4. 挽回那些很少再回來的客人。

Growth 其實就是 增加 Conversion ,降低 Churn。

以上講的不是 Growth Hack 的「全部」,只是 Growth Hack 中的小小一個場景。

Growth 其實就是 增加 Conversion ,降低 Churn。當然 Growth Hack 還是需要一些「技術」才能做的 Marketing(這就是為什麼 Growth Hacker 比較稀有,同時要懂技術,營運,與行銷)。只是這些技術並不再是專門養一堆「大數據」技術團隊才能做到的事。

創業團隊可以做,也必須做。

 
about 2 years ago

國內媒體寫過幾篇 GrowthHacker 的文章,但是對 Growth Hack 技巧的文章幾乎沒有。這一陣子都在玩這個題目,有一些心得,所以決定寫一個初級一點的懶人包,以後跟人解釋時好有個基礎概念。

相信很多人都知道 GrowthHacker 是什麼(幫忙公司巨幅成長的人),但是對 How to Growth Hack 可說是很陌生。甚至對於 Growth Hack 的印象都只停留在「衝 PV」或是「衝下載數」。事實上,Growth Hack 遠不只如此,Growth Hack 是一整套 Marketing 成長引擎。

Customer Lifecycle

要入門 Growth Hack 前,我認為想學這套技術的人應該要從 Customer Lifecycle 這個主題切入。

  • Acquisition : 從多個管道曝光
  • Activation : 註冊帳號使用第一次
  • Retention : 留住客戶繼續用很多次
  • Referral : 介紹朋友也一起用這個 Service
  • Revenue : 從客戶上賺到錢。

了解 Customer 有這五個時期,去 increase 這五個時期的 conversion rate 才叫 Growth & Hack。值得注意的是所謂的 Conversion rate 並不是單指 Revenue,而是 A => B , B => C 中間動作轉換的機率都叫 Conversion Rate。

Acquisition

大多數人對於增進 Acquisition 的想法是下廣告,或者 SEO。這叫 Acquisition。

增強 Acquisition 的手法不外乎是經營粉絲團,下 FB 廣告,寫很好的 FB 廣告或一般廣告流量,改善 open graph 上的標題與資訊,搜尋引擎上的文案。

不過這些效果其實有限。因為讓使用者踏入你的生意第一步最重要的是「 Activation 」。讓使用者願意開一個帳戶,體驗你的生意帶給他的 "Ah-Ha" moment。

Activation

增進 Activation 最常用的手段是設計一個 Landing Page。

台灣人作網站其實不太重視甚至不知道有這個東西。多半是功能寫好就上線了。然後上線就死城了。這當中問題是:

  1. 消費者不知道你提供什麼服務,不願意註冊
  2. 消費者不懂 How it works,不願意註冊
  3. 消費者有一些疑問,不知道怎麼樣繼續詢問下去,就不願意註冊
  4. 消費者不知道你的來歷,註冊了帳號卻不願意把信用卡資料填上去。

這就是設計一個 Landing Page 的重要性。Landing Page 是「使用者著陸的第一個頁面」。它可以是首頁,或者是 Referral 頁面,或者是搜尋引擎給到的第一個頁面。

好的 Landing 頁面是 Acquisition => Activation 的重要關鍵。因為它能幫你很好的介紹自己。同時在使用者介紹給朋友用的時候,幫你的使用者再一次很好的做了自我推銷。

值得注意的是很多 Mobile App 因為大家都會互相抄襲對方上線的設計,所以很自然的幾乎所有 Mobile App 都有一個很好的 Landing Page。但是大多數的網站服務很少意識到自己也需要一個。

( 之後有空我會繼續談如何作一個 Landing Page )

Retention

Activation 之後你會想要讓使用者繼續來你的網站,這叫 Retention。Retention 分兩塊。一個是帳號的 Retention,一個是付錢的 Retention。

有時候你註冊外國網站 SaaS,幾天後 Founder 有時候會親自寫信給你。(或者機器偽裝 Founder 寫信給你)。

目的是要查看使用者為什麼卡住了,為什麼不繼續用。或者有什麼疑慮我們可以協助排除。

付錢的 Retention,則是比如說提供 Daily new deal promo,或者是 Loyalty program....etc.作一些互惠的活動,來保持使用者繼續回訪。

Referral

Referral 是讓使用者願意且希望自己的朋友們也來用。拓展使用者 Base。

Referral Program 當然不只有設計 Referral Code 這麼膚淺。好的 Referral 如 Airbnb 與 Dropbox 都有相當好的循環獎勵設計。這也是位什麼他們的 user base 瘋狂成長。

比如說 Airbnb 在 Referral Landing, 獎勵, 與介紹就做的相當好。Dropbox 則是擅長辦競賽以及 online quest。

Revenue

最後是 Revenue,Revenue 談的是如何 increase revenene。包括 long-time customer revenue, increase customer basket size, customer re-engagement.

圍繞這五個主題的增進 "Coversion Rate"的技巧,稱之為 Growth Hack。

小結

知道了這五個主題,接下來用這五個主題一一去檢視自己的網站,就有很多點可以去作改善。比如說要怎樣設計 Landing Page,怎麼樣設計 Tagline,怎麼樣設計 Call to Action 流程。怎麼樣設計好第一次的 onboarding experience。怎麼樣做好 Customer Service。怎麼樣 Build Referral Engine。如何增加 Customer Re-engagement 的機會。

光是用這些關鍵字,接下來就可以找到很多文章。而且會更讓你吃驚的是,國外在 Growth Hack 這個主題上,其實已經相當成熟,幾乎你要作什麼 improvement,都有相對應的 SaaS 軟體幫助你做到更好。

在這裡也提供一個連結 http://growthhackers.com,這裡是 GrowthHacker 的 Hackernews,在上面可以找到不少資源。

希望大家 Happy Growth Hacking,有什麼想法也歡迎交流。

 
about 2 years ago

續前作:用 EC2 上的 Windows 玩 GTA 5

前一篇主要是在講怎樣用 Steam 的 Stream 玩 Steam 上有的遊戲。這篇是在講如何如何玩 Steam Library 以外的遊戲。

Steam 的 Stream 技術

用 Ctrl - ESC 逃獄 (不可行)

在可以玩 Steam 上的遊戲後,感到非常興奮,讓我想要去實驗嘗試更多種不同的遊戲。我發現 Steam 的客戶端有點像是桌面傳輸工具,就在想可不可以跳脫遊戲之後去玩其他遊戲。不過跳脫遊戲要用 Alt-Tab,這個指令送不出去,後來改用 Ctrl-ESC 可以順利逃獄。(我開 Tomb Raider 這類輕量的 DOSBOX 遊戲當 Bridge)

但雖然可以回到桌面。但是跑去執行其他遊戲,遊戲更新畫面送不回來。看起來一定還是要透過 Steam 本身的 Client 傳輸畫面回來。

用內建的功能

用內建的功能可以把有在 Start Menu 上的遊戲掛上去

但是像在 Origin 上的遊戲如模擬市民 3 ,紅色警戒 3 。

就只能用 exe 的方式掛上去

再把 Origin 從 Game 裡面關掉

http://www.technipages.com/how-to-stream-origin-games-over-steam

Happy Gaming

RA3

http://d.pr/v/1atr6

Sim3

http://d.pr/v/1aUyu

感想

我強烈建議喜歡模擬市民 3 的人,絕對要用這個方法去玩。

在 EC2 上跑模擬市民 3 竟然比我在家用頂標 2013 iMac (一台快台幣十萬,32GB 記憶體,SSD) 還要順暢 10 倍之多。過場不 lag,存檔不 lag。有股從此幹嘛花錢買厲害硬體的感想 Q_Q

 
about 2 years ago

今天早上看到 Victor 在 FB 上分享了一篇文章 Run your own high-end cloud gaming service on EC2。大意是如何惡搞 EC2 在上面玩 GTA5。看了看覺得很新鮮,加上這個方法要是成功了,Steam 上的 Windows 遊戲 幾乎就可以玩了,所以動手實驗看看。

會用中文重寫一篇指南是這件事沒有想像中的簡單,踩了一堆雷也害我燒了一整個下午弄機器,想了想還是把步驟重新寫下來以免將來忘記。

想法與成本

這個惡搞大招主要是基於

  • EC2 上提供了 Windows 2012 R2 的 Server,而 g2.2xlarge 的機器上面有 NVIDIA GRID K520 graphics card。
  • Steam 提供了同區網可以 Stream 遊玩的功能
  • 買一台可以打 GTAV 或 Cities Skylines 的 PC 要台幣 30000 - 40000 不等。而用這招惡搞的方式,一個小時成本大概在台幣 15 元,可以當租台機器在網咖打。(特別是方便我們這種只有 Mac 的人)(如果租到 Spot Instance 大概一小時台幣 3 元...)

所以要克服的主要的點,就是如何讓遊戲可以跑在 EC2 的顯卡上,然後穿牆 VPN 同網段,用 Mac 開 Stream 模式開來玩。

設定 EC2 機器

  • 上 EC2 租 g2.2xlarge 的機器(儘量找離自己近一點的 zone)。

  • EBS 開大一點,至少 150 GB 掛上去。(因為 Windows 本身就 30GB,GTAV 至少 60GB)。
  • Security Group 開 All traffic。
  • 記得要產生 key pair,這是拿來取得 Windows 密碼用的。

一但機器開好了,用 Mac 上的 Microsoft Remote Desktop 連進去,然後架 VNC Server。

設定顯卡與音效

裝完記得要把系統內建的顯卡驅動程式停用並砍掉。

裝完驅動程式要記得重開機

設定 VNC

這邊值得注意的是,如果上 RDP 是玩不動 Steam 的,所以 RDP 只是讓你進去裝 VNC 的。VNC 我是用 UltraVNC。(因為跑了 RealVNC,TightVNC,Service Mode 的密碼都設不上去...)

記得 UltraVNC 要開 Service mode 跑成常註。

然後到 Admin Properties 裡面去設定 VNC 密碼。

記得要開內部防火牆

當初 EC2 的 Allow Anywhere 雖然有開。但是 Windows 自己裡面還有 Firewall。記得要去 Security 那邊加 rules allow 5900 Inbound / Outbound 流量都可以過。

設定 VPN

我是直接跑商用的 Hamachi 點對點直接做 Private Network。

做法是建立一個 network,EC2 與 Macbook 都連到這個 Network 進來。

我完全不建議裝 OpenVPN ,是因為表面上省錢,其實浪費一堆時間,因為 OpenVPN debug 實在太困難....。(我燒掉一堆無謂的時間,最後生氣了就直接裝Hamachi,一年 29 美金而已。)

設定 Steam

打開 Steam 的帳號設定,加入 Beta Program,然後重開

(因為加入 Beta Program 才可以玩串流遊戲)

然後啟用串流

兩台都要啟用串流,理論上在同一個網路的話,就可以看到對方機器了。

再把硬體編碼這些選項都打開...

安裝 GTAV

  • 安裝 GTAV。(這邊沒什麼技巧,不過當初硬碟真的要留大一點...,不夠的話 EBS 是還能再追加,只是要重開機)
  • 安裝 Windows Media Foundation

實際安裝完 GTAV 並登入後,GTAV 會出現一個錯誤

"Dependency MFREADWRITE.DLL is missing. Please reinstall the game." errors on GTAV for PC"
官方有提出解法,不過這是給家用 Windows 7/8 用的。沒有 Windows 2012 Server 用的。最後 google 了超久才試到怎樣在 Server 上裝上去

到 Server Manager

Add Roles and features

裝 Media Foundation

然後重開機器。

Happy Gaming

然後基本上之後,只要 VNC 進去

  • 打開 VPN
  • 打開 Steam,確認兩檯機器連線
  • 在 Mac 上執行 Stream,接著就可以玩了。

成果

我在 100M 的 Comcast 上面玩 1280x960的大概有 50fps 左右。

錄了一段參考影片

原始檔:http://d.pr/v/1dDDu。其實蠻清楚的。

同場加映

如何租便宜的 Spot 機器

有朋友反映,不知道怎樣把 root volume 掛到 Spot 機器上。我是用 on-demand 的機器先裝好環境,然後對該檯機器做一個 AMI出來,然後再用該 AMI 跑去租 Spot。一小時才 0.1X 美金而已。(租一個小時台幣不到 5 元...)

 
about 2 years ago

我在兩年多前寫過類似的這樣一篇文章

現在我的想法轉變成:我認為不應該導入,而是應該導入 MDD ( Money Driven Development ) 。

到底現在這篇文章是要闡述什麼邪魔歪道?

重看我當年的那篇文章,我想我寫那篇文章時犯下跟很多程式師,以前從來沒想過的一個問題:對 startup 定義錯誤。

在繼續講下去之前,我想我要把我近兩年來理解到的一些名詞再重新寫一次,後面的文章脈絡才能拓展開來。

Startup

Startup 是有一個點子,你認為可行,於是你想要嘗試這個商業模式,或者是將你想像的概念轉換成商業模式。

Company

而 Company 是你有一個已經稍有形狀的商業模式了,你想固定下來,以一個商業組織的形體去營運。

程式設計師加入多半的是 Company 不是 Startup

絕大多數的程式設計師都是加入 Company(因為 Company 才有錢付給工程師去每天專心優化塑形商業模式),而不是 Startup。只是很多大家以為的 Company 根本連商業模式沒有,天真的以為程式寫出來,交付正確的 Spec ,消費者就會自動買單。

Startup 需要的是不斷探索什麼行為是真的可以賣錢的。為了達到這件事,未必需要寫程式,可以是放需求表單,可以是用露天拍賣,可以是用 FB 訊息交易,可以是用 FB 養觀眾。

這些,可不可以自己寫程式達到?可以,只是成本超級高,高到難以想像的地步。同時,程式設計師通常也不希望做這樣的工作,因為他們會覺得「老闆是王八蛋,什麼都沒有想清楚就叫他們做。」

所以程式設計師通常本質上加入的是一個 company,只有已經確定要做什麼了,程式設計師拿到「確定的需求與模式」,將之塑形。

正常的業界

接下來要討論,為什麼有這樣的爭議。原因在很多的「公司」,進行軟體專案的方式是在一般人眼中是很奇怪的。

首先,他們會任命一個不懂生意也不懂技術的人,其實是一個跑腿人物,負責「跟老闆或 BD搜集需求」再「寫 Spec」再「請工程師完成」,擔任一個翻譯的工作。這個職位叫 PM。這也是大部分專案完蛋的原因。

既然是「翻譯」,那中間的那個人兩邊的語言都不會說,你覺得會發生什麼事情?當然是交付錯誤(與 BD 所要的的解決方案不同)。程式設計師為了解決「翻譯者」能力低落的問題,主張中間應該不需有翻譯。所以開始主張 BDD。

實作一個軟體時,需求者應盡量提供原始情境:

1) 誰會使用這個軟體
2) 使用者在操作時會產生什麼情境。
3) 基本邏輯
4) 什麼是必要的,什麼是應該可以有的,什麼是完全不能做的。
5) 以 Story 敘述,而不是 Spec。

讓程式設計師,可以盡量出設計貼近可以解決原始需求(程式設計師稱之為『正確』)的方案。

好了。回到 Startup 與 Company 的話題。這套手法在 Company 行得通,也必須。因為中間需要經過太多的合作人員,所以我們要透過這樣的手段,盡量減少「翻譯」Cost。

Startup 本來就不是規模化自動化的階段

但是 Startup 需要 BDD 嗎?Startup 都沒人沒錢沒時間耗一天到晚在實驗新需求了,怎麼會是需要用到 BDD 這樣的技巧。Startup 所需要的是 Money Driven Development。只做賺錢必須的功能,找到幾個有錢賺的模式,能 Scale 需 Scale,那時候大家才有興致談 BDD 。

所以 Startup 前期應不應該導入 TDD / BDD?我現在認為這兩個名詞根本不是可以放在一起討論的東西。

就跟我覺得 Startup 跑 Scrum 是奇怪的做法一樣。

(我不是反 Scrum,Scrum 的一些手段對於釐清時程,Story ,權重。不管是專案大小都很有幫助。但是不是每個團隊都可以導入或適合這套流程的。)

 
over 2 years ago

這是最近做產品的一些雜感。放在 FB 有不少迴響所以貼過來。

做產品 = 「解決問題」

很多人做產品,包括我很久以前做產品。其實都犯了一個很大的謬誤。就是太早寫 code,甚至是說太早寫 spec。

做產品,精確地來說,就是在「解決問題」。

很多產品之所以會失敗,就是可能下決定的那個人(有可能是 Founder,有可能是 PM )看到了問題,先做了第一個假設性的解法,並決定將之 implement。

因為這個假設性的解法,很可能是有盲點的。但 Founder 或 PM 下了命令,它必須得執行。團隊覆對實作手法產生了矛盾大吵特吵。經過了大半天,合作的眾人才可能發現。原先被設定的解法,可能是錯誤的。

甚至當初被武斷所下的結論,甚至也可能是錯誤的。甚至再追溯下去,還可能發現原來的那個問題是假問題。

一旦太早由個人所推出的結論規格化,並且放到整組人馬的生產線上。後面自然可能巨幅浪費資源,甚至可能因為其他面子或政治問題再也難以回頭。

由這個主題延伸談下去的部分可以往下繼續談:

  • 創業 MVP
  • 寫 code 是否 tdd, 是否需要早期架構封裝化
  • 好的稱職 PM 應該為團隊做什麼

創業 MVP

一些活躍的網路從業人員,創業的 pattern 是:因為有著精湛的 coding 技術或者其他網路資源,所以想創業時第一想到的就是蓋平台 => 找錢。或者是先寫 code 再 pitch 找錢。

事實上這是錯的。

創業,實質上就是解決問題並將之商業化。

要先找到了想付錢的買家,再有了初步方案,再透過前幾筆的銷售確定的這個解決方法可以 work。再想要把這個過程 automated 化。automated 的這一步才是寫 code。

之所以為什麼很多時候,想發包給接案公司的客戶或者是公司內部的 PM 連 User Story 都寫不出來。那是因為他根本連自己的商業模型都沒有 run 透想通。既然沒有想通,何來 automated 化。

這中間大部份的實作者(aka RD)都沒有錯,因為在不知道你想解決什麼問題之前,能做的只是能憑藉著過去的經歷與想像把類似的模型蓋出來。

創業與做產品就是在一個一個回覆客訴與處理危機的過程中,慢慢把模型砌出來。

當然,沒有人說這個成本很低。

只是大部分沒有悟通這件事的人,會選擇在一開始就想閃避這件事的風險,例如一開始就創業者「想建立平台讓大家上來用」,PM 一開始就寫出「詳細的規格」。

結果在中間實做 Interact 的時候造成了更大的風險,甚至產生結不了案,錢提早用完的悲劇。

開發產品是否需要 TDD,是否在早期就需要將架構封裝化

實際上寫 code 的也是會遇到類似的狀況。

有些個性過於要求完美的 RD,也是會做出類似的事。明明只是一個簡單的功能,卻 Over Architecture。程式碼很漂亮,但是改不動。

程式碼只是表達解決方案的一種手段。

Over Architecture 或過於封裝的程式碼往往不是去除程式債,反而是新增的程式債。

因為這些人的過於封裝,不是增加 Story 的可讀性或維護性,他們的修改手法,反而恰恰把 User Story 支解到無法辨讀。大大造成隊友擴充功能或者修改方向的困難。

同理,什麼時機寫 Test

  • (後補 Test ) 你已有了粗略的方案,你想要將之塑形化,並且希望他不會在意料之外的情境下發生。同時避免其他人以後修改這段程式碼時,破壞了執行結果。
  • (先寫 Test ) 你手上拿到了一個非常清楚只是要重複的方案。你要用結果驗證你的 automated 方案是無誤的。

程式碼的乾淨度與創業成功的因果關係

同理,Code 的乾淨度與創業成功也沒有正相關,至少,在最初期沒有正相關。

Code 的乾淨度與 Project 成功的正相關度是受到 RD 教育訓練的影響產生的迷思。

大多數成功的專案,專案 code 都很噁心。至少在一開始很噁心。創業要的是正確的解決方案,而不是優美的 coding style。就如同創業公司的 Stage 演變。沒有人 care 你是怎麼優美的解決,人人只要買解決,而不是你多優美的解決。

什麼時候 code 會變得乾淨,當你有 A round 的錢,B round 的錢時候。有錢 hire 資深人士 refactor的時候。
你的「生意模式」需要「塑形化」,需要「水平擴展」化。這時候你的 code 就會變得乾淨。

不是一開始你的 code 就「先行塑形」「先行水平擴展」,那麼就會成功。而是一開始的主意 works,由生意驅動的 refactor。才帶來後面的 clean code。

只是人人往往倒果為因。

PM 的職責

PM 的職責是什麼?

既然創業做產品是解決問題。PM 的職責是負責去搜羅資源負責讓實作者更能設計出正確方案的或者接近類似方案的人。而不是「方案制定者」。

很多爛網路公司的產品會失敗,是因為請了不懂實作的 PM 亂寫規格,導致的黑暗混亂與巨幅浪費資源。之所以這些 PM 不懂實作,是許多 RD 認為「搜羅資源與需求」不需要技術(他們自己也懶,而且 RD 喜歡寫 code 當戰士勝於在前面當坦克)。

而 PM 又認為自己是 "Manager",既然他負責搜羅這些資源,就有權力引導甚至是決定專案的方向。

如果你仔細觀察,打造出成功產品的 PM ,往往有技術背景。

一個成功的 PM,應該具備下列特性

  • 能夠協助 Unpack 問題本身
  • 能夠協助引導討論方向
  • 能夠協助搜集幫助討論方向的資源
  • 具備一定的實作能力知道資源的限制與 Tradeoff
  • 引導溝通
  • 緊盯資源的花費與加速或放慢專案的進度
  • 花上大量的時間與專注力在 improve 團隊溝通速度與方法

因為實作產品,本身就是一件協調眾人之力,釐清問題,溝通,Prototype,Implement 並balance resource 的過程。

 
over 2 years ago

我們公司系統裡面有一個使用情境:有一個 method 要去查詢一個 Order,路上哪些司機車上放的貨可以送單,甚至這些司機可以要設定條件多少距離內可以送。

OK.

  • order has_many sold_products
  • sold_products belongs_to menu_item
  • driver_session has_many driver_session_items
  • driver_session_item belongs_to menu_item

這個使用情境就是要對 driver_session 造一個 scope 然後丟貨物需求數量,回傳可以繼續串接下去的 ActiveRecord::Relation。

一般 method 實作想法會是

  • 我先去問路上有哪些司機,身上有載客戶所要的貨
  • 然後對這些司機一個一個對他身上的貨夠不夠送
  • 然後列出這些司機的名單

虛擬碼會是

def my_method(order)
  results = []
  on_road_drivers.each do |driver|
    resuls << driver if driver.can_ship_this_order(order)
  end
end

然後再去下 on_roard_driver 和 can_ship_this_order 的條件。問題是這會有 db 掃描的問題。有 20 個 driver,3個 driver_session_item 就要問 20*3 = 60 次。有 10 個單要問就要問 600 次。(這是純 Ruby 解法,不是 SQL 解法)

下 SQL 難度沒有太高。不過難的是如何用 ActiveRecord 把這個作法拼出來,還能維護。

先說最後解法。

  module ClassMethods
    def fulfill(item_hash)
      item_hash.map {|item_id, amount| joins(:driver_session_items).merge(DriverSessionItem.where(:menu_item_id => item_id).where("available_qty >=?", amount).select(:driver_session_id))  }.reduce(scoped) { |scope, subquery|
        scope.where(id: subquery)
      }
    end
  end

主要想法是用 array 的 map 拼 SQL 出來再塞 subquery。是的,scope 可以用這種奇技淫巧用 map 出來再塞回去組 query。ActiveRecord 翻譯的動...

延伸閱讀可以看這兩篇:

http://stackoverflow.com/questions/6686920/activerecord-query-union
http://stackoverflow.com/questions/11838537/query-intersection-with-activerecord

不管你是要做 UNION, INTERSECTION 或者是多條件的 JOIN 都可以用這種密技解。而且 code 可以維護,不用真的寫 SQL。

 
over 2 years ago

每年過新年前夕就會看到一堆人在討論專案管理工具或方法 XDD

大概是這時候各 Manager / Lead 現在才有喘息的時間可以來 Survey 工具。然後趁這個過年大 break 一口氣改掉專案進行方法。上一次寫這方面的懶人整理包已經是三年前。我也來整理新版的心得。

有興趣的可以配我之前的文章看

網站程式上線前需要準備的事 ( 2012/3 撰)

專案管理之道在「協調」

在談如何挑專案管理工具或方法之前。有一個中心原則很重要,我覺得必須要寫:

「這世界上沒有一套大一統的管理術,還有神奇專案追蹤工具。不會讓你裝了之後大家就變成超級賽亞人,人人練成通靈術。」

而專案管理也不是大家想的那樣,學了以後「命令」「指揮」大家做事比較有效率,專案管理是「協調」大家「一起做事」的技巧。

「協調」,「協調」,「協調」!

很重要所以要講三遍!!

瀑布與敏捷

專案進行方法有幾種,瀑布式,敏捷式(還有分 Scrum, Kanban, Scrum + Kanban ...) ,到底哪種比較好?

我的看法這幾種方法是因運組織以及組成人事有關。

有很多人講敏捷就要先幹瀑布式一下。抱怨只是做個簡單的東西結果 spec 被不專業的人花上很多時間寫了一堆廢物,拖了一堆時間結果 delay,實際實作時卻脫離現實。

我個人認為這其實跟組織運作有關。通常一個組織會出現「瀑布式做法」,通常已經代表這個組織太大或太冗了或者缺乏合作情感。頭無法控制到腳,或者 pm 根本無法跟實作團隊建立互信,或者根本是與不熟的外部團隊(外包)合作,為了避免產生糾紛才會有這種做法。

Spec 與 Story

寫 spec 跟 story 也是不一樣的東西。

spec 是很精確定義要做什麼,細節要做到怎麼樣的程度,不容修改。這適合你已經知道要做什麼了,你這次要做第二遍第三遍,所以只是重複上一次要做的東西,然後加上局部修改。

而 story 是你有一個使用情境,但你不知道確切成品會長成什麼樣,所以我們需要有一個 story「讓參與專案的人反覆討論改進」。

讓「讓參與專案的人反覆討論改進」

「讓參與專案的人反覆討論改進」「讓參與專案的人反覆討論改進」「讓參與專案的人反覆討論改進」

這件事超重要。所以也要講三遍!

我相信大部份的軟體開發與情境,都是不知道確切成品會演化成什麼樣。所以比較適合的是「敏捷式」與寫 Story 。

這也是本文要接續寫下去的方向。

Scrum or Kanban ?

好了。屁了這麼多廢話,到底要選哪一種?

好。先講結論:不要選 Scrum XDDDDDDD (那些靠教 Scrum 賺錢的不要揍我)

沒有啦。其實我沒有想要擋人財路。Scrum 很好,但是我會勸你去學 Scrum 但不要「導入」Scrum。(好吧看起來還是很欠揍,有人可能又會跟我吵那是因為 Scrum 學不到位才會講這種妖魔鬼怪的言論)

OKOK。我承認我不是什麼敏捷高手,只是低手。我只是在寫我的想法,理性勿戰 XDDDD

我個人對 Scrum 的看法,是 Scrum 是是一整套「工具集」。它是提升效率的一套「敏捷」「Framework」(這也是 Scrum 開宗明義講的)。每一個組織都有每一個組織各自的問題,一次全導 Framework 進去未必會幫到自己的組織,可能還會搞到非死即傷。

Scrum

有些讀者可能對 Scrum 沒那麼熟悉,我大概講一下這套工具箱裡面有什麼:

  1. User Story (敘述我們要解決什麼問題,以及相關的使用者情境)
  2. Story point (每一個 User story 的權重)
  3. Scrum Master, Stakeholder, Team member ( 裡面成員扮演的角色)
  4. Sprint (衝刺週期)
  5. Standup (站立會議,成員每天報告之前做了什麼,今天做了什麼,未來要做什麼,今天遇到什麼難題希望 Team Member 幫忙解)
  6. Retrospective meeting (回顧會議,在這個會議檢討我們這個 sprint 的部分有什麼需要改進的)
團隊難以導入 Scrum 的原因

為什麼很難全導呢?

  1. Story point 要怎樣分(爛票要優先做嗎?可以裝死嗎?政治問題與能力問題)
  2. Team member role (Scrum master 誰當?角色重疊會不會有後遺症。政治問題與能力問題)
  3. Sprint (啊我們一個 Team 同時在做多個 project ,哪有辦法精確估計守備範圍和速度? )
  4. Scrum 重視 Story,大家都在拼 Story point。那 Epic (不在 Story 上的技術問題,但很重要,比如 Refactor 或者是 Performance Tuning )怎辦?

etc.etc.

這些都是導入 Scrum 會面臨到的問題。導入開始產生一堆問題,接著 Team member 就會產生一堆疑惑,大家開始質疑,一個弄的不好大家就覺得比之前複雜超多好累不想弄喔,就 GG 了。

但這表示 Scrum 不值得導入嗎?

不不不。你應該看你有什麼樣的問題要解決,拆進去用,逐一導入。

我在前面的部分就說了:Scrum 是一套工具集,裡面的工具是是真的很不錯。

Scrum 細細說

User story 與 Story Point

User story 的誕生是為了解決在專案過程中,因為負責專案管理的人過於描述細節而把原始目的破壞殆盡的狀況。很多時候,專案經理為了求好心切,甚至過於精確描述實作細節

  • 不僅花費了不必要的時間(講的方案不好
  • 還造成負責實作者的困擾 ( RD 或者 Design 覺得不切實際
  • 甚至 RD 做完了,stakeholder 才講這不是他要的。(因為精確描述時作方法,會造成實作者實作時缺乏上下文,想像錯誤 )
  • 只描述了一部份的細節(比如說只講商店要怎麼結賬,卻忘記講後台也要有後台可以管理訂單)

但做專案重要的是

  1. 中間經手的人通通都理解要解決什麼問題。在什麼時限之前。
  2. 我們手上有多少資源
  3. 我們可以在第一版做到什麼程度
  4. 能不能讓實作者在第一版就解決最真切的問題
  5. 能從不同使用者角度審視這個軟體
  6. 第一版我們要做哪一些功能。哪一些馬上就要做,哪一些可以之後再做。哪一些給 Senior 做,哪一些給 Junior 練手用。

Sprint / Standup / Retrospective Meeting

Sprint

做軟體不能沒有遙遙無期沒有 Release date。也不能「只有一個 Release date」。這會造成花了大把時間卻做歪掉。

或者是 14 天內只要 a,b,c 功能,但實作者卻因為想一口氣做完 a,b,d,e,f, 功能,一口氣報了 30 天才能「通通完成」,結果第三十天才發現 c 沒做。

這就是為什麼必須要有 Sprint。規劃一個短時程,把值得先實做的部分衝刺,邊改邊做小 release。

Standup

而 Standup 的用意不是為了監視 Team member 有沒有做事。而是為了保證每個人「做對事」。軟體開發者不是通靈者,沒辦法 100% 辦法精確 implement。

為了避免劇烈的 misunderstanding 發生,standup 是在每天一個固定時間讓大家交流實作狀控使用。報告現在的狀況,當發生無法實作或者需要改優先權,甚至改實作者(有些 junior 做不出來)的時候馬上可以調整。

可以讓大家常常保持在 same page,對專案有一個清晰的了解,保持士氣。

Retrospective Meeting

同時,為了團體的成長,在 Sprint 結束後,也會有一個回顧會議,去檢討在這個週期中,我們各自或甚至公司有什麼地方可以做得更好的地方。大家一起改進。而非一直忍耐某人某鳥事忍到受不了然後離職。

Scrum 要解決的事

看完這些,你知道 Scrum 要解決的是哪些事了嗎?

  1. 對專案目標的理解程度
  2. 對專案時程的透明程度
  3. 進步,溝通,協調

導入者要先知道自己組織有哪些問題,然後去調整去用工具才有意義。

Kanban 要解決的事

同樣的 Kanban 也是類似的想法。Kanban 沒那麼複雜的工具集。核心就是三個故事版:

  • 未實做
  • 實做中
  • 已實做

目的是為了讓專案所有成員了解現在的實作狀態。從而自己發展各式各樣的輔助方式協助時程內完成一定的目標。

敏捷是怎麼回事?

所以看下來,敏捷是怎麼回事?

  • on time
  • on budget ( resource )
  • deliver correct result
  • communication / collaboration

如果專案管理者只是想要「命令」實作者「通靈」。說真的我覺得導什麼敏捷方法都沒用。

最有效的方式是「擲筊」

我怎麼做專案管理以及用什麼工具?

具體一些細節可以看三年前的系列的文章。就不重複講裡面的內容了。這一段主要是描述現在我怎麼樣做專案的

  • 要做某功能前請某 pm 在 Hackpad 起草 User Story
  • 要開始實作實,用 Redmine 開一串巢狀式的實作票 ( Story, Design, RD frontend , RD backend, RD mobile, QA )
  • Redmine 與 Hipchat / Slack 整合,team member 都可以在 ‪#‎techlog‬ 上看到全部的票的更新狀況
  • RD 依照 ticket 號碼開實作 ticket branch, Senior 根據 branch code review, PM 根據 branch 跑驗收, devops 針對 ticket branch merge 并 deploy.
  • Admin backend 不寫測試,API 與 Service Object 一律要寫測試。code reviewer 不 review 任何 紅燈 branch.
  • deploy 是使用 samson 整合 CI 做 deploy
  • 內部 mobile release 是使用 crashlytics
  • CI 是使用 solanolabs
  • 難以敘述的部分使用 screenshot 與 google hangout 直接講
  • Tech / Design / Mobile team 會用 Hackpad 一有 release 會寫 updates 寄給全公司。

我們現在開發團隊的狀況是:美國,台灣都有 RD。靠這些工具, weekly pm meeting, company tech touch base, engineering demo 與 retrospective meeting 確保公司上下想要的東西是一致的。

平均我們 redmine 一周會產生100-150 張 ticket, rails 的主 branch 一個月 2000 commit,一周大約會 release 5-7 個 major feature。code climate 現在 3.08 分。test coverage 大約 60%,API 的部分應該有 90-95%。

我們怎用 Hackpad?

用 Hackpad 有兩個地方。

1. 寫 User Story。

User story 寫

  • 要完成什麼商業目標
  • 希望出貨的時間
  • 會動用到的 Team
  • 主要的使用者角色以及相關場景
  • 必要 Must / 有時間再做就可以 Nice to have

這時候會起一個 Redmine 的主票,在 slack cc 相關人等上去評論

2. 寫 Product Updates

因為我們 Tech team 開發速度和能量太驚人。非 Tech 的人常常會被新冒出的功能驚嚇到,或者已經上線的功能他們不知道還跑來催。

所以當我們 Deploy 或者要 release build 時,會寫 Tech Updates 寄給全公司。讓大家對我們這一兩天做了什麼有基本的了解。或者做好應有的應對衝擊。

以免產生要馬覺得 Tech 都亂作亂 deploy 功能,或者是 Tech 都 delay 功能的誤會。

我們怎用 Redmine ?

會用 Redmine 是因為試到一個功能其他專案管理軟體「都沒有」。就是「無限的巢狀票」。(我不是說其他套軟體不好。每一套有它適合的專案複雜度)

我們會用巢狀票去切細切碎 Story。Redmine 對於需要跨多 team 合作的專案非常適合。特別是我們幾乎所有的專案都需要 backend, front, design, 還要 release 到三個 client 上。

同時,切碎 Story 也有助於 RD 專精在功能的思考與任務分配上。其他專案管理最大的缺點就是通常只有兩層 Task。不太夠用。
就算是寫一個中型功能,RD 有時候也會遇到 nice to have, tricky bug, edge case, complex implementation, 不拆票很容易就鬼打牆。junior 更是不拆票就當場死,而且還死在非常前面。redmine 可以幫助 RD 有自我 task management 的習慣。

redmine 還有 related ticket 可以用。大家可以用 related 串來串去,related to / block by 之類的。
我們通常會這樣切票,

master 票,下有

  • story 票
  • design 票
  • backend 票
  • fnd 票
  • ios 票
  • android 票 implementation 做完會關掉開 QA 票。

然後因為我們公司有太多線 project 還有軟體有太多 phase release 要管了。所以我們還有一個 basecamp 去管這些 release。不然會管到爆炸..

Take away

所以結論是什麼? XDDDDD

結論不是我告訴你哪一套軟體或哪一套流程比較好。然後你回家照著用結果處處踢鐵板。

反省團隊的根本效率問題是什麼

而是要認真去檢視你到底要解決團隊裡面的什麼問題,一次解一個問題,遇到問題再去翻書逛 blog。

很多時候不是某某書上沒寫什麼,或者是某個作者對某方法或某軟體有強烈的偏見。而是你再找解法時,沒有認真先去 identify 你的問題到底是什麼。(「效率不彰」本身不是一個「詳細的問題」)

就連我自己寫不同專案在不同場景時也會用不同工具 Set 了。有時候我自己寫 side project 根本沒有 user story 也沒有 project management,甚至連 branch 都不切,Test 也不寫,但這樣慢嗎?無敵快的勒 XDDDDDD 但這卻不是一個專案合作上的好方法。

我這一篇文章主要是在介紹我現在管專案所使用的 General Method 與 General Tool,相信裡面大部分也是一般團隊常遇見的問題。

我自己認為,專案執行上有問題不脫是幾點問題

  • 對目標迷失
  • 時間觀念迷失
  • 外行領導內行
  • 缺乏溝通
  • 專案不透明

朝著這幾點改善才能大幅改善團隊裡面的效率。去挑選工具與方法也才顯得有意義。

幾本書推薦

這三本書是我覺得講敏捷觀念與方法比較根本的三本書,也許讀者可以從這三本書入門

這三本都有簡體中文版。露天上找得到。

歡迎各位業界朋友在本文留言討論專案執行經驗。