訂閱本網誌: Facebook, Google+, 電子報, RSS

技術到底重不重要?

July 18th, 2011 by Jamie

昨天下午我去參加了 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)

  • Gilles

    找人接你的case很容易,Ptt就有版專門接專案了。

  • 「網路業」對於技術的分類方式,和「軟體業」的確很不一樣。這篇文章的重點不是人才,而是風險。

  • 我的確不是念 CS 的,但是寫程式也有 20 多年了。 🙂

  • 如果能夠的話,但更重要的是把了解使用者需要什麼的能力練到爐火純青。

  • 是,所以我們在討論的是「網路業」

  • 這表示 PCCES 的 A 已經確定是使用者非用不可的,那去投資 B 就有意義了。

  • 你最好祈禱找到另一個 Mark Zuckerberg: http://venturebeat.com/2009/02/10/winklevoss-twins-made-65-million-on-facebook-copycat-settlement/

  • 因為如此,所以不論是AWS,GAE或Azure,目的都在讓開發者可以專注於在事業邏輯的開發上,你會需要分配好工作,專心做好每一道菜,所有烹飪器具設備都已經幫你準備好了。人類科技或說是技術的進步,都在於讓人們更快的實現它們的夢想(想法)。如果你發現不是這樣,那就忘了這項技術吧。
    再怎麼簡單的技術都還是有門檻的,如果你發現對你而言不是那麼容易上手,那還是先專注於你的事業邏輯上吧。
    科技是幫助人們實現夢想的。重點還是在實現夢想。

  • Gilles

    「網路業」跟「軟體業」的說法就真的很硬凹了。

    如果你技術不重要的重點在風險,我的《雜魚論》就是正確的。

  • 真正的技術,也就是不要活在別人定義裡的技術,不用也不會去區分 feature vs scale。

  • 回覆「風險 vs 網路業與軟體業」,還是怪怪的,現在都已經有雲端服務,在雲端運算時代,看 Scale 的角度與「傳統網路業」是非常大的不同,看風險也不一樣。

    既然有雲可以用,根據真的雲端運算的定義,MVP 成功上線,使用雲服務,立刻成長到 100 萬人以上的服務也沒有問題,這是為什麼雲端運算對草創的微型企業更為重要的原因。

    看這樣的風險考量,很顯然 Jamie 大大沒有把雲端運算考慮進去,是有點訝異。

  • 術業有專攻,大大拋磚引玉,大家一起討論,謝謝 Jamie 大大。

  • Tzan-Feng Chien

    同意 Cray Kao 的觀點

    這是一個非線性規劃的問題
    開發時間和使用者人數都與文中所述兩者技術成正比
    但因網路業的特性
    其目的就是要最小化開發時間
    並得到最大化的使用者人數
    這時勢必就需要 trade-off而不是1/0的問題

    當然因為系統使用者是 incremental 增加的
    所以 Jamie 才會認為初期不需要”太過”考量規模技術
    且我認為軟體工程品質與這種考量沒有太大的衝突 😉

    另外…抱歉不是要挑語病…
    只是…這標題會讓工程師暴走XD
    For a starup, A is more important than B.
    Instead of A is not important anymore.

  • 可惜「雲」並你想像中那麼強

  • 區分的目的是為了闡述創業的步驟,不是為了定義。 🙂

  • 網路是通路業,軟體是服務業。

  • How about A is way more important than B? 😛

  • T.Y.

    謝謝您 !

    T.Y.

  • oh! Someone just forwarded this to me and i just read this article! Haha… sorry Jamie for putting you under the bus! Don’t you love to be the center of controversy? =P i’m just doing my part to help!! haha!

    As for your article, I think there is a perception that to build a highly scalable and fault-tolerant system requires a lot of money, time and up-front capital expenditure. While our team did spend a lot of money and time (guilty!), the actual money spend on building a scalable system is actually quite low. Everything we used is open source, and a lot of what we build on top of is on cloud, and therefore, not a lot of upfront CAPEX. 

    What I am trying to say is it can be very inexpensive to build a good architecture for your software stack, and I implore all web/app startups to think about scaling from the beginning, because it wil be 100x harder to do that once the site is live. 

    ps. the time and money we did spend on building this system is largely due to our inexperience. Once you learned how it works, you want to hit yourself in the head and say why i didn’t learn about it the first time!

  • 我想這是比例的問題… 因為Gulu不是精實創業, 它是另一種模式, 也是有機會成功, 但不必拿Gulu來和Jamie的文章作對照或解釋….
    Jamie 想講的絕不只是什麼系統效能, 他那麼多精實創業的想法, 並沒有在這篇文章中列出來, 大概是不想和Gulu直接比較…畢竟Gulu是另一種創業模式, 和Jamie提倡的lean是不一樣的, 無法比較…
    Jimmy 認為花在 ” a highly scalable and fault-tolerant system” 的錢不多, 應該是因為 Gulu 在其他地方也花了很多錢, 所以比較起來, 當然不算高…

    在看完 “How we built gulu.com” http://vimeo.com/26593720 的影片後, 我覺得Gulu一定有非常雄厚的資金在支撐, 因為辦公室很豪華, 租金一定不便宜…
    且光員工就將近30名了, 還分工很細, 有財務長, 有行銷人員, 有設計人員…
    甚至還能去學校招募程式設計師, 也太好野人了吧… 呵…

    這些對appWorks所輔導的團隊來講, 根本就是天方夜譚…
    甚至連 appWorks 所投資的 Richi.cc 說要用一千萬來找畢業生, 大家都嚇到了, 都還覺得天使給的錢一定很多(或團隊的募款能力太神)…
    一般小工程師團隊根本夢不到Richi了, 何況是去比較那麼強大的 Gulu …

    舉例來說, Jimmy 在影片中還強調 Gulu 的網站是要以非常用心的頁面設計, 來感動使用者, 這是Gulu有別於其他網站以工程師來設計的畫面.
    那… 這點對通常只有三個人的團隊, 就已經是難以達成的…

    大部份的網路創業團隊, 都是窩在一間小公寓寫程式, 三餐不繼, 而其中一名比較倒霉的工程師, 還必須站到外面, 去找錢, 去學習, 去行銷…
    還要像Jamie說的, 要寫網誌, 要去看敵人在作什麼, 一堆一堆的事…
    校長兼撞鐘, 當然不可能每件事都作好, 所以只能挑最重要核心的來集中心力去作, 其他的就只能先作到堪用或捨棄, 將來等到上線後再來慢慢調整, 並等有資金後再找人才補上…
    所以這才叫精實創業…

    如果能像Gulu那樣先天就有這麼大的規模, 後天又能細心努力, 那當然更好更棒, 遠景更可期待!!
    只是… 那並非Jamie目前要談的…

    所以, 這才是我覺得appWorks偉大的地方, 那想幫臺灣網路業盡一份心力的地方…

  • Gilles

    Exactly.  Scalability should be part of the feature design, instead of a great addition that builds on top of features.  Jimmy said it all.

  • Gilles

    Exactly.  Scalability should be part of the feature design, instead of a great addition that builds on top of features.  Jimmy said it all.

  • No problem, man. As long as it helps your cause, do whatever you want with me.  I’m all for having fun.

    I know what you’re saying but my thing is it is STILL more costly and time consuming to build a scalable product than if you would have had built just a working one.  And the point is why spend more time & resource on it before making sure it’s something customers want.

    That said, if your thesis is customers want a social dining platform that does not only work BUT also scales, then what you’re doing is correct.

  • 另一個是時間的問題,一個可規模化的產品,必須要花更多時間去建置。在還沒確認市場需求前,就花那麼多時間在一個產品上面,萬一不是市場要的,那不是白白浪費了生命?

  • I’m not saying it should be an additional feature but an additional phase.

  • 不過, 反過來說, 對系統性能的這些投資, 可能是將來在必須pivot時, 成為最有機會延用而省錢的部份.
    因為介面/商業邏輯/程式/資料, 都可能會因pivot而大變動, 甚至要捨棄之前作的;
    但整個系統的後端建置, 則一般變動較少, 再利用的機會很大.
    如果資金夠, 現在作了, 以後也許可以少花點錢…

    但是, 也有一點要注意, 技術和設備不斷在進步, 現在花錢設計了一個很棒的彈性擴展架構; 等哪天pivot後想重覆利用時, 會不會覺得系統又過時了? 必須要再規劃更好(更貴?)的?

  • 建系統的時候,如果要考慮到未來 pivot 的彈性,是不是又要花更多精神和時間呢?

  • 我覺得 Jamie 的觀點不錯,但對軟體的看法跟國內的硬體廠商就有點類似:只要做出想要的樣子就 pass。但文中所提的 A 和 B 其實是互相會影響牽制的軟體技術,日後要擴大規模或增加競爭力,A 不可能不動。而且文中所談的 A 和 B,真的如同 Gilles 所言,很相當於 application 和 framework。跟國內的硬體廠商一樣,習慣認為用最便宜的人找工具兜出 application。這樣的結果是:當服務品質升到中等以上,準備再往上爬時,就被 application 的技術卡住了。

  • 我覺得 Jamie 的觀點不錯,但對軟體的看法跟國內的硬體廠商就有點類似:只要做出想要的樣子就 pass。但文中所提的 A 和 B 其實是互相會影響牽制的軟體技術,日後要擴大規模或增加競爭力,A 不可能不動。而且文中所談的 A 和 B,真的如同 Gilles 所言,很相當於 application 和 framework。跟國內的硬體廠商一樣,習慣認為用最便宜的人找工具兜出 application。這樣的結果是:當服務品質升到中等以上,準備再往上爬時,就被 application 的技術卡住了。

  • “”可惜「雲」並沒有你想像中那麼強””,這沒有一個絕對的答案。

    Netflix 四月份的 AWS 當機事件已經證實這點。

    真正的關鍵是,大家對雲的認識,還是誤解。雲就像車子,不同人駕駛,同樣的車子也會有不同表現。

    很巧合,今天我自己也碰到,流量爆衝100倍,網站一度死當,但是終究在沒有升級硬體的條件下,靠著系統技術,做了調整,目前暫時過關。

  • 我想表達的是「雲」要能 scale,雖然比較容易,但還是要很多設定。

©2016 MR JAMIE ─ 創業者需要的啟發,新鮮供應.
網站由 Allen Hsu 設計 | Logo 動畫由 Wen Chen 完成