over 3 years ago

最近閱讀很多 SaaS ( Software as a Service ) 相關的 newsletter, blog, 書,閱讀的蠻上癮的。有一個影片看完以後我蠻想分享其中重點,這個故事也許可以給台灣的創業家一點激勵。

這個主題就叫「從世界的邊緣創業」。這是我當初在 Bussiness on Software Conference 翻歷史影片,看到的一隻主題蠻吸引人的 Talk :Going global from the edge of the world

講者是來自「南非」開普敦的創業家 Adii Pienaar。他的公司就是赫赫有名的 Wordpress Theme 公司 : WooThemes

「從世界的邊緣創業」這個主題真的非常吸引人,一般人對於要作 Global 生意的印象都是網站創辦人非得是美國人,否則這生意怎麼做的起來。這也是吸引大家來參加這個 talk 的原因。

WooThemes 的背景

  • 2008 年創業。花了 13 個月,賺到第一個一百萬美元
  • 總部一直在南非開普敦。其他人在英國和挪威。
  • 員工 25 人
  • 用戶 30 萬人
  • 平常都是 remote
  • 沒有收過任何 Funding, 100% Boostrapper
  • 開 WooThemes 之前,是一間三人的 Design 工作室

第一件事:公司在哪個國家並沒有太大關係

要比慘的話。Adii Pienaar 說南非開普敦作為一個科技創業的地方,其實不是什麼太優的位置。

開普敦一如非技術城市的一樣。沒有這些東西:

  • Networking 關係圈
  • Mentors 導師們
  • Advisros 顧問們
  • Investors 投資者

當地沒有 Startup Culture,公司更很難請開發者,因為他們都寧願去當地的銀行上班。而且物資還缺乏....XDDD ( 什麼東西寄到南非都要拖三四個月)。

這是他們公司為什麼以雇用 Remote worker 為策略的關係。

從哪裡出發並不重要。Adii 賭他們公司的客戶應該 99% 以上都不知道他們公司其實在南非。客戶根本不會關心這間公司真實的地址在哪裡。

第二件事:不要因為潮所以去創業,不要因為潮所以去募資。決定必須基於生意決策

Adii 在演講裡面談到他在該 talk 前幾個禮拜寫的一篇文章:Startups Shouldn't Follow Trends

最重要的原則是:Stop doing things just because they're trendy and mainstream media seems to reward it with publicity 不要因為趨勢以及主流媒體激賞這些行為,你就去追逐。

  • 可以 bootstrap 就不用去募資
  • 不要因為 Eric Ries 講 Lean Startup,你就跑去用。如果你的生意這樣幹才適合才這麼用。
  • 大方的用 .NET 技術作網站,只要你認為這是對你生意上最合適的決定。

第三件事:從技術社群和客戶裡面挑員工

現場有人問 Woothemes 的員工幾乎都是 Remote 的。雇用 Remote worker 似乎是一件嚇人的事。他們去哪裡找到值得信任的人可以雇用。

Adii 的回答是從社群和客戶裡面挑選。因為他們公司是在賣 Themes 的。所以客戶蠻多都是開發者,所以最後就問其中幾個能不能來上班。也因為打過交道彼此認同也熟悉產品了,這件事來得容易一點。

第四件事:比任何人努力工作

Adii 深信的兩件事是

  • "The more In practice, the luckier I’ll get."。(雖然它們可能不會同時發生)
  • There’s no way to exceed unless you actually work harder than anybody else.

他很羨慕 Ryan Carson 推行 4days a weeek 運動。不過那福利是給員工的,Bussiness Owner 可能永遠不會有這種機會 XD

第五件事:用國際級的水準建立國際產品

從開普敦打造國際級產品,不是不可能的。只要你拿國際級的實力,上台競技。網際網路允許你這麼做,而且沒有理由你不去奪取這個機會。

第六件事:作 B2B 生意

Adii 會創業的原因是,是他在開 Woothemes 時前是作 Design Consultancy 的。他幫客戶作一個案子是收大概 $3000 美金(from design to deployment)。他意識到可以把 Theme 做成產品。當然,做成一個變成只收 70 塊。但是你可以省下客戶很多時間和金錢,讓客戶原先的本業做得更好。而且你可以創造一個「Bussiness Model」,而不是只「僅」得到一個「Bussiness Customer」。

<題外話>

我在另外一篇 SaaS 文章,也看到勸 Founder 作 B2B 的產品。因為 B2B 的產品顧客,更願意付錢。他們願意付錢讓 Things Get Done。付這樣的小錢,目的是為了賺更多的錢。 B2B 收費模式會比較容易擴展且穩定。

第七件事:到世界各地去旅遊參加研討會

這是他的 Talk 裡面分享的最後一個 Lesson。到世界去旅遊,去見不同的人。到世界去旅遊見不同的人,可以為你充電。帶給你不同的靈感,得到不同的機會。甚至可以有機會在不同的城市認識到厲害的導師。

特別是如果你不住在科技重鎮,或者是一個熱鬧的城市。旅遊是你要找到 mind-liked 的人的唯一的機會。

而要找到 mind-liked 的人最容易的方法就是參加研討會。

小結

這個 Talk 是一個 60 分鐘的 Talk。Adii 的演講當然不只以上內容,但最重要的是,他想展示的是,不住在矽谷,也是可以打造一個國際企業的。而這是他個人的親身經驗。

我也是到昨天看完這個 Talk,才發現 WooThemes 竟然是從南非的公司。而且那些 37signals 分享的部份經驗,也不是傳說。Woothemes 的經歷也蠻多相似的地方。

Adii 還有一個部落格 http://adii.me/ 。如果你是創業者的話,我強烈建議你訂閱 Adii 的部落格與電子報。他在裡面分享了很多關於 Startup 與 SaaS 的 esay。

過幾期,我們將在 Tearhour 作一期關於 SaaS 的節目,屆時也歡迎各位指教。

 
over 3 years ago

https://twitter.com/bottico/status/400397602522279936
https://twitter.com/dhh/status/400397737763434496
https://twitter.com/dhh/status/400397858173485057
https://twitter.com/dhh/status/400397926158983168

相當有意思。

 
over 3 years ago

前陣子我在 RubyConfChina 2013 的 Talk:Maintainable Rails View

現在已經重新整理成一本書 Maintainable Rails View https://leanpub.com/rails-view-book

當初會整理這個 Talk 和書的原因是是因為長久以來:相對於 View,在一個 Project 裡面,設計出乾淨的 Model 與 Controller,是相對簡單的。但事情一跑到 View,就會變得相當複雜。很難有一個基礎簡單的思路去整理這些糾結的線條。

所以我最後決定釋出一份這樣的整理指南。

這其實也是我們 Rocodev 目前在用的 Rails View 整理技巧。

這本書包含以下幾個主題:

  • Helper 使用時機
  • Helper Best Pratices
  • Partial 使用時機
  • Partial Best Pratices
  • Helper 與 Partial 之外的整理武器
  • Object-Oriented View

共有十八個技巧。定價是 20 USD。

新書上架,提供折價卷:rubyconfchina2013 (折價 5USD 至 2013/12/01)

其他

曾經購買 Essential Rails Pattern 的舊讀者,我後來考慮這本書的架構太龐大。之後應該會分拆成幾本書。原書則不再更新。我會寄一個 Maintainable Rails View 完全免費的 coupon 給你們。(屆時請查看你們的電子信箱)

有讀者問到與之前的文章系列的不同。這本書部分內容是重新寫過並且編排的。有關於 Object Oriented View 的部份本月底也會翻新(新增更多 code example)。

 
over 3 years ago

Summary

總結以上 18 個設計手法,看似複雜,其實原則不外乎:

  • Always assume things need to be decorated (永遠假設東西必須要被裝飾)
  • Extract logic into methods / classes ( 將邏輯封裝成 method 或者 class )
  • Avoid perform query in view/helper ( 盡量避免在 view/helper 裡面進行資料查詢 )
  • When things get complicated, build a new control center (當事情變得複雜,不要拘泥於舊的手段,找一個新的中心重新整理控制)

掌握這些原則,就可以儘量把 View 整理的乾乾淨淨。

Read on →
 
over 3 years ago

這一篇的重點也是 Object-Oriented View。因為篇幅太長所以再拆一篇。

16. Form Builder

有時候我們為了排版 Form,不得不在 Form 裡面也穿插一些 HTML 作 styling。

<%= form_for @user do |form| %>
  <div class="field">
    <%= form.label :name %>
    <%= form.text_field :name %>
  </div>

  <div class="field">
    <%= form.label :email %>
    <%= form.text_field :email %>
  </div>
<% end %>

但要寫十幾遍 <div class="field"> 是一件很煩人的事。我們最希望的是,其實 View 裡面只要這樣寫就 OK 了:

<%= form_for @user, :builder => HandcraftBuilder do |form| %>
  <%= form.custom_text_field :name %>
  <%= form.custom_text_field :email %>
<% end %>

這樣的煩惱可以透過客製 Form Builder 解決:

Read on →
 
over 3 years ago

這一篇的重點是 Object-Oriented View。

14. Decorate using Decorator ( don’t put everything in model )

在前面我們介紹了幾個手法,包括 將 Logic 收納到 Helper 裡面

def render_article_publish_status(article)
  if article.published?
    "Published at #{article.published_at.strftime('%A, %B %e')}"
  else
    "Unpublished"
  end
end

以及 將 Helper 裡面的 Logic 重新整理到 Model

Read on →
 
over 3 years ago

這一篇的重點是除了 Helper 和 Partial 外,還有什麼工具是可以拿來用來整理 View 的。

11. content_for ( yield )

有些開發者不是很了解 Rails 的 yield 是拿來作什麼的。你可以理解成 跳躍到定點執行

這招常被用在一個情景上: Best Practices for Speeding Up Your Web Site 中的 put javascript at bottom。

在調整前端 performance 時,最常見也最有效的一招就是,把肥大的 JavaScript 放在最底端讀入執行,因為很多 JS 都是 document.ready 才會被執行。

但是,如果開發者只是把 javascript_include_tag 丟到 view 的底下,如:

Read on →
 
over 3 years ago

這一篇的重點是 Partial 的設計

7. Move code to Partial

什麼時候應該將把程式碼搬到 Partial 呢?

  • long template | code 超過兩頁請注意
  • highly duplicated | 內容高度重複
  • indepdenent blocks | 可獨立作為功能區塊

常見情境:

  • nav/user_info
  • nav/admin_menu
  • vendor_js/google_analytics
  • vendor_js/disqus_js
  • global/footer

8. Use presenter to clean the view ( 使用 Presenter 解決 logic in view 問題)

在前一章節,我們介紹過 view 裡面常被迫出現這種 code

Read on →
 
over 3 years ago

這篇是我在 RubyConfChina 2013 的 Talk:Maintainable Rails View

當初會整理這個 Talk 的原因是因為長久以來:相對於 View,在一個 Project 裡面,設計出乾淨的 Model 與 Controller,是相對簡單的。但事情一跑到 View,就會變得相當複雜。很難有一個基礎簡單的思路去整理這些糾結的線條。

所以我最後決定釋出一份這樣的整理指南。這其實也是我們 Rocodev 目前在用的 Rails View 整理技巧。

前情提要

要了解這些用法中間的轉折,首先我必須先解釋幾個前提,這是這些「整理方法」之所以被發明的原因:

  1. 在 View 裡面有 Logic 糾纏 ( if / else & other syntax )是不好的,這會導致 View 很難修改以及維護
  2. 在 View 裡面有 Logic 糾纏是不好的,這會導致 View Performance 下降 ( pure logic )。
  3. 在 View 裡面有 Logic 糾纏是不好的,這會導致 View Performance 嚴重下降 ( with data query )。而這包含在 Helper 裡面 perform data query。

這個 Talk 會包含以下幾個主題:

  • Helper Best Pratices
  • Partial Best Pratices
  • 除了 Helper 與 Partial 之外的整理武器
  • Object-Oriented View
Read on →
 
over 3 years ago

從這次打造 Logdown 的過程中,我還學到寶貴的另外一個經驗:「先做軟體,不要先做平台」。

打造「平台」,幾乎是大多數人對於做網站的第一個預設想法。

如果你跟你的朋友說你要做一個網站,然後說你不是做平台,那麼大概有 99% 的機率他會以為你是瘋子,不然就是超級外行的笨蛋。如果你跟投資人說,我們沒有要做平台。嗯,他可能連見你都懶....XDD

盲點一:「平台」=「賺錢」=「成本很低」

這個道理很簡單:「平台」=「很大」、「大」=「賺錢」。「平台」=「很多人會主動貢獻內容」、「很多人會主動貢獻內容」 = 「成本很低」。所以,如果你一開始就宣告不做平台,「正常人」會把你當「瘋子」。

盲點二:一開始就要作「功能完善」的「平台」,不然之後修改的成本很高

因為從以前到現在,打造一個網站因為架構和技術上的關係。軟體修改的成本一直被認為是很高的,所以絕大多數人的傾向是:「我應該一開始就要企劃完善,否則之後修改的成本很高。」

而網站上線之後,若網站一開始使用成效不佳,大多數的人檢討也會傾向「應該是宣傳不夠的關係」。


網站失敗的例子很多。後面的結局在趨勢部落格上多到不勝枚數。但有幾個共通點幾乎都是一模一樣的。

  1. 平台「大」不一定「賺錢」。「大」但不知道如何「賺錢」、虧得一屁股的到處都是。
  2. 作平台不等於「很多人會主動貢獻免費內容」。事實上一開站就是死城的平台到處都是,而這件事情會嚇到很多第一次的網站經營者,所以他們下意識的直覺就是花錢「請人來生內容」以避免「死城效應」,否則「死城效應」會讓這個網站在第一個月直接就 GG。
  3. 幸運的用錢熬過頭幾個月後,發現使用者和內容成長的速度還是遠低於預期,沒有使用人力或資本介入,直接放著還是會 GG...

.....(後面的事情寫都寫不完...)

但總而言之,「規劃」過的網站上線後多數的問題是這樣的:

(1) 事情不會如想像一樣的發生。而且絕對比你當初預期之外的的最糟狀況還要更糟。
(2) 不知道如何解決「死城效應」,只好用錢續命。
(3) 六個月以後終於發現問題完全不在「宣傳不夠」。而是在於「沒有解決任何問題」、「解決的問題價值不夠付薪水」。
(4) 九個月以後,發現解決根本的問題的手段在於「改版」(因為原先的手段錯了)。但「改版」會遇到的問題在於「舊的功能是否要留著,砍了很可惜」。「新舊版本並存的軟體成本問題」。「開發新版本的金錢成本問題和時間成本問題」。


承認失敗永遠是走出困境的第一步 : 往反方向而行

無疑的這對誰來說都是一個很難解決的困境。勵志書上常說「承認失敗永遠是走出困境的第一步」。我在自己上班的時候,曾經作過很多網站。在做過那麼多網站之後,我認知到,「先作平台」是一條我完全負擔不起的路;上班的時候公司的錢多到花不完了,但是還是避免不了掉入這樣的問題。現在我擁有的只是一個更小的公司,自然更玩不起這樣的作法。

所以我這次實驗方向就是:反方向而行。不要急,只做我做得到的事情,看看什麼事情會發生 ( 原先的公司 Rocodev 主要業務還是接案作軟體開發,內部生個產品還算養的起)。令人驚訝的是,我看到了許多以往我從來沒有想像過的世界。

「第一時間」不作平台,只「解決問題」

雖然打造一個「像樣」的「平台首頁」對我們來說「開發成本」是很低(註)的。而且在產品上線之後,許多朋友就覺得我們有機會打造像 Medium 這樣的寫作平台。一直希望我們加上「社群首頁」、「社群功能」,往平台發展。

但是我們一直有意無意的「拒絕」這麼做,直到最近才終於上了 Explore Logdown 這個功能。

在此之前,我們幾乎把接近 100% 的重心都放在打造 Logdown 的「寫作工具」之上。我們花了非常非常多的心力在打造這個編輯器之上,如果你知道我們在這個 Markdown 編輯器上花的心力、開發的 Editor Hack、和遇到的問題難度,你可能會嚇一大跳...(有空我會請同事簡單介紹我們解決了哪一些在實作編輯器上的 issue ...)

因為我相信一件事:「有解決到的問題的軟體才會有人要用。」

身為平台者開發的我們,往往會有一個巨大盲點:「我開發了一個平台,就會有人主動來用。」但若以使用者的角度來說:「你開發了一個平台,關我屁事,為什麼我要主動用,甚至從此搬到你家。」

我們之所以會把所有的優先權,幾乎全部貫注在後台功能之上。是因為如果連自己都無法愛上我們自己的產品,不覺得不用 Logdown 寫部落格會死,那怎麼有可能讓其他人也喜歡用。

而一旦大家喜歡用這個工具寫文章,自然內容的產生質和量就不是什麼問題了,作平台的門檻也沒有那麼高了。

(目前文章不包含搬家的文章,在 Logdown 上大概每個月文章產生速度大約在 6000 篇以上,系統文章數量目前是 14 萬篇以上...)

只有一件事需要作:「把產品做好」

Logdown 在頭三個月幾乎不作所有「社群平台」有關功能,還有一個沒什麼人知道的好處:不用花時間去分辨使用率低到底是因為宣傳不夠的關係,還是純粹只是因為產品爛...。如果沒人用,就是產品很爛沒有第二句話好說 XD

如果一個產品的問題相對只剩下產品品質,那需要努力的方向也只剩下「把產品做到好」。不用為其他不存在的事情忙的焦頭爛額還一點效益都沒有。

軟體就是必須要一直調整,一直砍掉重練...

在做這個產品時,我們還在心理上先接受了一個事實:作產品就是要一直修改一直修改一直修改,必要時還要砍掉重練。雖然我們是職業軟體開發團隊,但不代表我們就沒有開發成本問題。

修改在往常讓 RD 難以接受的是因為:

(1) 軟體修改成本很高。(有可能因為是當初假設錯誤,或者是程式碼規劃不好)
(2) 你不知道修改之後,效果會比之前的好還是之前的爛。情感上很難接受以前的功能是「作錯了」這件事。或者只是「不覺得別人(通常是 PM)的意見是正確的」。

因為我們的開發是 Complain Driven Development(被不同人抱怨三次以上我們才要作)。Feature 正確率大概有 90% 以上...

當團隊基本上知道自己起碼是按照一個「相對正確」的方向走過去。心理上就不太會抗拒「修改所產生的成本」這件事。

一開始就作「收錢」的產品

許多人會對 Logdown 的「大膽」感到驚訝,為何一個「開發中」的軟體,就打算收錢?這在許多方面看來都是覺得奇怪的:

(1) 你們不是第一個作部落格軟體的。如何有自信讓使用者「好」到「值得付錢」?
(2) 一開始就收錢,不會把使用者「嚇跑」嗎?

我想這沒有絕對的答案。若要談當初的想法,我的觀念純粹是:

(1) 我現在開公司,做的東西理論是就是要收錢的,只是何時才要收?
(2) 我不想按照免費使用者的建議努力去作,做出一個到最後叫好(很多人稱讚)不叫座(根本不賺錢)的東西。
(3) 我不覺得「好」= 「值得付錢」。我認為「有解決問題」= 「值得付錢」。

我想最快知道要如何賺錢的方式,就是用直接一點的手段去作,直接收一個「還可以接受」的價錢,看看會發生什麼事。當然這個手段,現在由結果看算是相當不錯的:

(1) 網路上馬上有人罵,「哇靠,一個 Beta 的東西,沒有 OO 和 XX 還敢收錢,要不要臉」。我馬上就知道原來要收錢,至少要作 OO 和 XX,不用猜老半天...
(2) 朋友密我:「hmmm...但是你們可不可以把哪個 feature 改成這樣那樣,只差這個,我就願意付錢了。」我馬上就知道,哦,原來某些使用者最在意的是什麼功能一定要做到,他們願意付錢就只買這個功能。
(3) 其他公司直接打給我說:「hmmm...你們可不可以作什麼什麼功能,我願意付錢作 Enterprise 客製。」

我們是一個非常小的團隊,根本沒有能力負擔市場調查的成本,但是只公告了我們要收錢,我們馬上就知道要如何賺錢了。而甚至結果也不差,我們第一個月的收到的數字甚至可以打平整個開發團隊的薪水...(原本以為作部落格一定會賠的要死...)

甚至還有更意料不到的事情:使用者說我們的編輯器只用在部落格系統上實在太浪費了,可不可以作什麼什麼系統也用這個編輯器,他們也願意付錢 XDDDD

Summary

當然,這樣做的心臟要非常大顆。因為這樣做的方式,跟「一般作網站」的方式,差異非常非常的大,遭受周遭的人質疑也會非常非的兇,你甚至不可能在一開始拿到任何資源,因為沒有人會相信你這樣會是有結果的。但不可諱言的,這卻是我一直想做的一件事,我一直想看看這樣作,最後究竟會看到怎麼樣的世界。

我在 2011 年寫過一篇文章: 魔球,一個搞清楚產業重點的棒球故事 。這篇文章其實就是當初我創業的動機之一,只是在這篇文章裡面這樣的手段,不管身在哪一個公司,是不可能被任何老闆准許的。所以最後才走上了創業這條路。

Logdown 才剛開始沒幾個月,現在小小的成績實在不能證明什麼。但是,我開始知道原來不走那條相對很遠的路,也是可以的。


廣告:歡迎試用 Logdown,一個很棒的部落格寫作平台,我猜你應該也會喜歡它的。