over 3 years ago

最近幾年,興起 Lean Startup 的風潮。主要的訴求是創業者應該先把重點放在打造一個 Minimum Viable Product (MVP),觀察市場的需求,再行調整變化商業主軸成長。

說起來簡單,但沒人敢篤定的說,這個 Minimum 的 M 到底要做到什麼程度才足夠。討論一個點子,快速製造出一個原型,然後讓使用者快速反餽調整?這樣做的人很多,但卻不是人人 work。

更普遍的是你見到一個「草率」的產品上線,然後從此就快速沉寂消聲匿跡。

M 不代表草率

很多創業者在製作產品的過程中,常常不自覺得把「MVP」這三個字拆開來看,亦即只完成了「M」,以為實作了「Mininum」的產品規格,就可推出觀看市場反應。事實上,市場上有人會要的東西是 MV (Minimum Viable)。如果你的產品並沒有解決了任何有價值有意義的問題,只是一堆精美的介面功能,那麼是沒有人會買單的。只是浪費了時間浪費了金錢,生出一堆沒有用的程式碼。

相反地,若提供的解決辦法對某些人很重要,那麼就算產品介面再怎麼 crappy,他們還是有興趣停下來試用,甚至付錢給你希望開發者將把它做得更加完善。

M 的 scope

回到正題。我們終歸要討論 M 的 scope 到底在哪裡。

我的建議是:

不會寫程式的作法

如果你不會寫程式的話。先去找一個「會用」的工具湊出一個勉強能夠動的流程,解決問題,然後開始找人試用。

如果你找不到現成的工具可以兜,那麼還有一個方式。你可以拿非常仿真的 Mockup 工具,如 Axure XPBalsamiq,把「可以解決問題」的流程和出現的畫面畫出來。

不要覺得這樣的步驟很麻煩,因為到這裡為止,還是只有梳理工作流程而已。

你可以從這樣的流程,粗略的知道後面將要面臨多麻煩的事。以想要開一個商店來說,你就會知道商店:

  • 需要一個上架介面
  • 需要傳圖介面
  • 需要結帳介面
  • 提供哪些結帳選項
  • 提供哪些寄送方式,如何選擇
  • 要用哪種條列方式管理使用者訂單

會覺得製作這些畫面很花時間對吧?這些都只是畫面而已。要寫出後面的程式可能是畫一張畫面「五倍」甚至是「十倍」的時間。

透過把畫面與流程畫出來的方式,可以讓你(很清楚的)知道要製作這個東西要花多久的「成本」(不管是時間上還是金錢上)。

不要因為覺得很麻煩,就使用「功能列表條列」、或者「單張畫面,列出滿滿按鈕與分頁去表示所需功能」的方式去估算工作時間。

因為事實上,在列表上,一個功能你都只會以為需要一小時或一天就能完成。而真實會發生的情形是,一條功能至少要開發 7 天。

當你一旦理解到要執行這個計畫所需成本可能是多麼巨大的時候,自然就會毫不猶豫的把不需要的功能砍掉,只專注在「必要的解決手段」。就這個例子,甚至最可能的情形,是上去 Shopify 上面開一個網路商店,或者是註冊一個 Wufoo (線上表單服務) payment integration Plan。

會寫程式的作法

會寫程式的作法反而相反。我相信各位開發者都很威,開發軟體的成本對你們來說都超低。但,請千萬千萬忍住,只做一個功能就好。思考哪個功能是「解決問題手段裡面絕對不可以沒有的」,只做這一個就好了。以 Logdown 這種部落格平台來說,標準就是只做一個編輯器,以及簡單的文章系統就好了。

(真的不要擔心作太少,一上線你就會知道就算只有「一個」也是會操掛你。相信我,實際試一次就知道了)

因為技術創業者都是「很會寫程式」才會出來創業的人。所以往往的毛病就是不打 idea 草稿,邊寫邊想。又以 Ruby on Rails 開發者(哈,在說我自己)最容易有這壞毛病,因為開發程式太快。所以 generate model, generate controller, 套個版,就覺得這東西可以上線,上線就等於可以開始收錢發財了。

然後,就沒有然後了。

作產品跟上班、接案做的東西驗收標準完全是不一樣的。上班、接案,你只要按照 issue tracking 上的「指示」完成工作就可以了。但是「產品」的「完成」標準,是「順利」的「幫 End User 解決他的問題」。而要做到這件事,產品需要花上大量的時間打磨:介面要做到讓用戶可以理解不會迷路。程式不會出現詭異的錯誤。按照 End User 的需求調整加強,甚至打掉重練。

一開始就作太多功能的問題是:開發者以為這些功能都已經「完成」了。但事實上,他們每一個對使用者來說幾乎都是「未完成」的。也許使用者可以從這麼多的功能列表「猜」出開發者想要提供什麼服務,但是實際上他們不會繼續用下去。因為這個網站爛透了,每一個功能都是「未完成」。沒有解決到任何一丁點問題的網站,沒有人有興趣繼續用下去。

那麼你說,沒關係,我可以之後照使用者的反饋調整網站。但是問題又來了,做了那麼多功能「都有問題」,使用者的回報意見,自然涵蓋了所有板塊。那麼你該如何判斷出什麼問題沒做好才是最嚴重的呢?優先權該放在哪個模組呢?有些厲害的模組甚至是當初花了很多心血做的。結果使用者劣評如潮,你思考了下徘徊在投入心血改進和不如砍掉兩個選項。但狠的下心嗎?

然後,就沒有然後了。被第一次進來的 Customer Feedback 打爆,就沒有然後了。

所以,只做一個能夠解決問題的功能。只做這樣就好了。

Recap

  • Minimal "Viable" Product
  • 不會寫程式:Write down User Story
  • 不會寫程式:用手邊可以兜出的方案實作
  • 會寫程式:只寫一個「可以解決問題」的功能就上線。

Lean SaaS

這是我的新書 Lean SaaS 的第一章。若你對接下來的內容有興趣的話,我將會在這本書繼續連載後面的內容(保證每週連載,約十期)。

連載期間價格 30 USD。連載結束後 45 USD。

本書最後附贈 SaaS 上線 checklist,我會在書中的逐章解釋 CheckList 的每一條意義。

歡迎各位讀者來信交流,我的 email 是 xdite@rocodev.com

 
over 3 years ago

https://leanpub.com/lean-saas

Lean SaaS : Build SaaS From Small Ideas

這是我最新的一本書。書的內容是綜合我過去幾年開發以及營運中型網站, 以及在過去六個月內,實際運營一個 SaaS 網站所得到的寶貴經驗。

( 可以省下技術創業者非常多的冤枉路)

本書將會以連載的方式進行。以每週一篇的方式進行內容發行。

連載期間價格為 $30 USD。連載結束後的價格會是 $45 USD。

目前的(暫定)內容有:

  • MVP 的 M 最低尺度
  • 寄信,大量的寄信給你的用戶
  • 作產品應不應該寫測試
  • 如何決定要不要實現一個功能
  • 該聽用戶的還是聽自己的聲音
  • 如何拓展用戶
  • 何時找外包 (外部資源篇)
  • 產品定價策略
  • B2C 與 B2B
  • 產品的包裝
  • 行銷包裝自己的團隊
  • SaaS 產品 checklist
  • SaaS Podcast 及資源

其他

我在這期 TeaHour 與 @knwang 與 @yedingding 做了一期節目:SaaS 血淚史

http://teahour.fm/2013/11/18/lessons-learned-from-running-saas-products.html

如果你聽完對於 SaaS 的拓展擁有強烈的興趣。我將會在這本書內逐一深入各式的主題。

 
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 →