Posts Tagged ‘performance’

昨天下午我去參加了 Gulu.com 的產品發表派對，結果被我的好朋友，Gulu 的創辦人兼 CEO Jimmy Chen 直接在台上點名，說：有一次 Jamie 跟我說技術一點都不重要，讓我好難過。可是我覺得 Jamie 錯了，技術根本就很重要！

啊！我們又回到這個敏感的問題了。

我常覺得技術就有點像是身高一樣，身高重不重要？問這個問題，高個兒都會說：「應該重要吧！」但是如果你退一步想，當然是先看你要打什麼球啊！

不過光這樣講也太混，今天的文章當然不能只有這樣。要討論這個話題其實很簡單，首先，我只要把「技術」先解剖一下，你就知道問題出在哪裡了，技術其實大略可以分為兩大類：

A) 功能的技術 — 這類型的技術讓一個網站可以做到你想要它做到的功能，所以像是 PHP, JSP, HTML5, CSS3, SQL 等等，大略可以被歸入這一類。

B) 規模的技術 — 這類型的技術讓一個網站可以從 100 個人同時使用，長大成 100 萬人同時使用，所以像是 Load-Balancing, Clustering, Fail-Over, High Availability, CDN 等等，大略歸入這一類。

也就是說，A) 就是我們常說的「程式開發」(development)，而 B) 則比較像是「軟體/系統工程」(engineering)。

硬底子技術

再來，近年由於「開發」工具日趨成熟，所以 A) 類型的技術也越來越平民化，最好的例子就是 Ruby on Rails 的入門課，就是寫一個 Twitter，於是乎 A) 也越來越少被人稱作「技術」。相對的，雖然一樣有越來越多的工具，但是 B) 其實仍舊是一門非常高深的學問，即便是 Google、Facebook 這麼成功的公司，花了那麼多錢去請最頂級的工程師，還是常常會碰到網站掛掉的情況。所以，到後來，當我們說到「技術」，越來越是在討論這些最難的規模化理論和實施細節，越來越少是在討論做出一個可用產品的過程。

成本/時間

從另外一個角度去看，A)  相對於 B)，是非常便宜的。你可以請一個稍微有一點功力的開發人員，只要懂得運用市面上的工具，多多少少都可以把你想要的網站雛形做出來給你。但是要做到  B)，沒有花大把鈔票，雇用經驗豐富的一流工程師，使用第一流的設備，是很難達到那個水準的。另一方面，A) 相對於 B)，也是比較快的一個實作過程。

風險

了解了這些，我們就可以回到「B) 規模技術」重不重要這個問題。答案是當然重要，當你確定有 100 萬人同時要用你的網站時。問題是你要怎麼確定？當然是先用 A) 功能技術做出一個雛形 (或稱 MVP)，去確認市場的需求。為什麼？因為 A) 比較快，也比較便宜。沒有必要在還不確定市場的需求前，就投資珍貴的時間和成本在 B) 規模技術上。

而這，就是 Lean Startup 的最核心精神。所以，當我說「技術不重要」的時候，其實真正的意思是「規模技術一開始不重要」。這樣，清楚了嗎？

歡迎在 Google+ 加入我

(Image via jurvetson, CC license)

這世界上有很多產品，都把「速度」當做一種功能來吸引消費者。買車的時候，業務員會跟你說這台雖然只有 2,000 c.c.，但是因為加了渦輪增壓，榨出了最大的馬力，所以 0-100 公里加速，只要 4.8 秒 — 光聽你就已經血脈噴張。而很多時候，速度甚至讓消費者願意多花一點錢 — 高速鐵路的車票往往比一般火車的貴不少。

但奇怪的是，在理論上很科學、很追求效率的科技產業，這麼久以來，我們卻完全沒養成用「速度」來說服消費者的習慣。我們有一些奇奇怪怪的東西 — 例如：CPU 時脈、網路頻寬，「好像」跟速度有一點關係。問題是當消費者再問深入一點 — CPU 從 2 GHz 變成 2.4 GHz，那電腦速度是不是快 20%？你又必須要回答：其實也不是那麼一回事。頻寬呢？從 20Mbps 升級到 100Mbps = 五倍？錯，99% 的時候，消費者根本感覺不到任何差異。(事實上，如果頻寬是一群人共用的，還有可能因為封包數大增，塞爆路由/分享器，最後讓網路速度變慢。)

速度有多重要

我們都常「耳聞」速度對網路業的重要 — 從 Web 1.0 時代大家就常把「8 秒定律」掛在口邊 (注意：已過時)，但或許你不知道，事實上，速度在網路業有著致命的殺傷力。研究顯示，Google 需要 0.4 秒來產生 10 個搜尋結果，要 0.9 秒來產生 30 個，但如果他們把「預設結果數」從 10 個變成 30 個，僅僅相差 0.5 秒的時間，居然就會損失 20% 的使用者！Amazon 也對消費者進行了許多 A/B 測試，發現即使網頁下載只慢了 0.1 秒，業績就會有顯著的下降。

速度可以勝過對手

也就是說，「速度」是網路業上僅存的幾個「技術」可以幫你勝過對手的地方。但這和一般提到的「技術」不一樣，想要速度，很多時候你往往必須要減少功能，而不是增加。關於速度，Stack Exchange 的 Jeff Atwood 提出了幾個實作上你可以利用的工具，包括：

• Yahoo 的 13 個網頁加速最佳實務守則
  • Jeff 特別提出了 CDN (Content Delivery Network) 的重要，它讓世界各國的使用者都可以享受到更快的速度 — 不過這比較適用於已經找到 PMF 的團隊。
  • 實務上我的經驗是大多數的網站，光減少 HTTP Requests，就可以大大提升速度 — 可以用 Firebug 裡面的 Page Speed 分析來看看 HTTP Requests 拖慢了多少。
  • 要減少 HTTP Requests，CSS/Image Sprites 是非常好用的技巧。
• 針對註冊和非註冊用戶分別進行優化
  很多東西非註冊用戶用不到，不需要讓他們下載額外的 Javascript/CSS 檔案，拖慢他們的速度。
• 把「速度」當作團隊的驕傲
  Stack Exchange 內部用 MVC Mini Profiler 把下載時間放在每一個網頁的右上角，時時提醒團隊要重視速度、速度、速度。(用 Google App Engine 的人看這裡)

除了 Jeff Atwood 的三點之外，關於速度，我覺得你還可以：

• 宣傳你的速度
  當你有辦法做到快時，你應該要大大的宣傳。Google 是第一個發揚這個做法的，他們很早就在右上角放上搜尋時間，不斷去提醒使用者 Google 引擎很快。
• 用流程設計來提升速度感
  • 記住，速度是一種感覺，使用者要的是「反應速度」– 按下去就有回應，不一定是「結論速度」。所以，當有一些東西就是要花比較多時間時，你應該設計一些流程來讓他們不會失去速度感。
  • 由於 iOS 不能背景下載，所以 Flipboard 設計了開場頁，讓你先在那裡欣賞一些朋友的照片，趁機趕快抓時間下載內容。
  • 很多機場故意把登機門和行李轉盤的距離拉遠，中間放置很多免稅商店，讓你下飛機後慢慢逛過去，等到你好不容易走到了，行李也出來了，如此反而減少了旅客的抱怨。
• 至少放一個 .gif 小動畫
  如果真的沒辦法設計一個流程，你至少要放一個小 .gif 動畫，讓使用者知道他真的有按到那個按鈕。最差的情況的就是按下去之後什麼反應也沒有，很多人這時會一直按，不但造成麻煩的重複 submit 的情況，很多時候還會引起更多的問題。

所以千萬別忘了，速度也是一個功能，很多時候甚至是殺手應用。在你把你的服務長成一個怪獸前，想清楚，在速度上，你想要給使用者怎樣的體驗，然後自始自終，不要忘記這件事情。相信我，你將大大提升創業成功的機率。

而除了產品要速度，介紹產品當然也要速度。本周五 (6/24) 6:00pm，30 組創業團隊將會用一分鐘的速度，在 「2011 六月號 appWorks Startup Mixer 創業人同樂會」介紹自己。除此之外，你還可以跟現場 200 位網路人天南地北的聊創業，這麼棒的活動，你一毛錢也不用花，還不趕快去報名？

(Image via gilderic, CC license)