7 days ago

Growth-Hacking-Tools.png

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

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

第二場連結:http://rocodev.kktix.cc/events/growth-hack-intro-02 (7/1 晚上 18:30 - 21:00)

時間:2015/06/21 14:00 ~ 2015/06/21 16: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

《 費用 》

門票:500 元 (含下午茶點心)。座位有限。

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

 
6 days ago

提到 Lean,恐怕大家只記得 Eric Ries 寫的那本 Lean Startup 。但老實說,雖然 Lean Startup 這本書名氣大,但內容卻是最乾最雞肋的一本。

Oreilly 後來有出了一整套 Lean 系列,如果你想創業或正在創業,我推薦讀者依順序讀這五本書。

1) 首先買 Running Lean,把你想做的點子「收斂」成「MVP」。別貪心,就是只做 MVP就好。

running-lean.jpeg
2) 接著買 Lean Customer Development ,將你的 MVP tune 的讓客戶越來越喜歡越容易衝動下手買。

lean-customer-dev.jpeg

3) 再來買 Lean Analytics,教你用數據做決策。

lean-analytics.jpeg

4) 買 Lean UX 配合數據與顛覆傳統設計工作方式去改善產品界面。

lean-ux.jpeg

5) 最後買 Lean Marketing for Startups,教你配合數據做 Viral Growth。(這本不是 Lean 系列,只是書名有 Lean)

lean-marketing.jpg

 
6 days ago

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

螢幕快照 2015-05-23 下午5.48.07.png

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 是這個原因)

螢幕快照 2015-05-23 下午6.19.22.png

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

螢幕快照 2015-05-23 下午6.20.08.png

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

螢幕快照 2015-05-23 下午6.21.25.png

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

螢幕快照 2015-05-23 下午6.23.12.png

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

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

螢幕快照 2015-05-23 下午6.26.20.png

(Dropbox 會用火箭當進度)

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

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

 
19 days 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 這個工具,可以具體描繪出用戶在這個網站上的軌跡。

Screen Shot 2015-05-08 at 16.39.15.png

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

Screen Shot on 2015-05-08 at 16-48-56.png

而使用者真正下單之後,對後端服務 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。

Screen Shot 2015-05-09 at 13.01.23.png

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

螢幕快照 2015-05-10 上午11.30.06.png

Automated Targeted Email

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

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

螢幕快照 2015-05-10 上午11.31.05.png

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

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

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

2015-05-08 8.09.59.png

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

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

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

 
24 days 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,有什麼想法也歡迎交流。

 
26 days 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 上的遊戲掛上去

螢幕快照 2015-05-03 上午11.10.51.png

但是像在 Origin 上的遊戲如模擬市民 3 ,紅色警戒 3 。
螢幕快照 2015-05-03 上午11.11.05.png

就只能用 exe 的方式掛上去

螢幕快照 2015-05-03 上午11.11.21.png

再把 Origin 從 Game 裡面關掉

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

Happy Gaming

螢幕快照 2015-05-03 上午11.19.28.png

RA3

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

Sim3

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

感想

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

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

 
27 days 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)。

ec2win2012.png

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

螢幕快照 2015-05-02 下午10.22.53.png

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

設定顯卡與音效

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

onlyonedevice.png

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

設定 VNC

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

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

iPhone image on 2015-05-02 at 22-34-20.jpeg

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

記得要開內部防火牆

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

設定 VPN

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

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

螢幕快照 2015-05-02 下午10.36.06.png

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

設定 Steam

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

螢幕快照 2015-05-02 下午10.40.38.png

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

然後啟用串流

螢幕快照 2015-05-02 下午10.40.23.png

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

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

螢幕快照 2015-05-02 下午10.40.59.png

安裝 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
螢幕快照 2015-05-02 下午10.49.07.png

Add Roles and features
螢幕快照 2015-05-02 下午10.49.14.png

裝 Media Foundation

螢幕快照 2015-05-02 下午10.49.44.png

然後重開機器。

Happy Gaming

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

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

螢幕快照 2015-05-02 下午10.44.15.png

成果

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

錄了一段參考影片

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

同場加映

如何租便宜的 Spot 機器

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

 
about 1 month 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 ,權重。不管是專案大小都很有幫助。但是不是每個團隊都可以導入或適合這套流程的。)

 
about 2 months 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 的過程。

 
3 months 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。