Posts Tagged ‘Joel Spolsky’

精實的光譜

October 4th, 2011

前兩天讀到了一篇「選擇 (或批評) 精實前,先想想網路效應」的文章,基本上針對前陣子不少網誌參與討論,創業的「Lean vs. Fat」,做了一些延伸思考,特別是從「網路效應」與「第一印象」的角度出發。

這是一篇很不錯的文章,我覺得大家都應該去讀一讀,尤其是文章的結尾,作者 Raincole 說:

就像網路效應、就像我們很少是極右/極左派一樣,精實不精實是一條光譜線而非開關,只要是面對消費者的軟體,大概都有點精實的味道。

事實上,即使Joel似乎不喜歡精實創業,他的方法和精實創業卻仍有相近之處。他並不是轉到精實的反面(瀑布開發),而是用封測的方式測試可用性(別忘了走廊可用性測試)。用內部人員或親朋好友去模擬真實使用會有誤差,但也是非做不可的功課。畢竟把菜端給客人以前,至少你自己要嚥得下吧!

所以,「精實與否」這個議題討論到最後,其實是一句簡單的問題:

你願不願意破壞少數人的第一印象,來換取一些真實世界的回饋?

這段話說得真的很好,而且如果我告訴你 Raincole 今天剛滿 19 歲 (生日快樂!),你應該會跟我一樣覺得台灣的未來很有希望。

沒錯,拿一些真實使用者來測試,或許會犧牲掉他們 (的第一印象),的確是做 MVP 的其中一個出發點 — 尤其一般沒有 Joel 號召力的創業者,由於要找到一群「對的」好朋友人來封測,是困難的,不得以只好拿出來給大家測。

但除此之外,「開放式 MVP 測試」,其實也還有其他考量,例如:

  • 早期採用者 — 許多早期採用者是特別會給「對的」回饋,也對產品的設計、臭蟲不會太計較,甚至是像 Joel 一樣具有影響其他人的能力。所以早一點用 MVP 來吸引他們,讓他們一開始就參與你的產品的設計,產生感情,有時候還會帶來周邊效應。
  • 預測需求 — 大多創業團隊,如果給他們足夠的時間和金錢,都是有能力花九個月時間「刻」一個「好」產品的。但為什麼這些產品大多數是失敗,因為創業團隊往往是沒有預測消費者需求能力的。所以除非你是像 Joel 這樣已經在業界打滾幾十年,深知需求在哪裡的人,早一點拿出來聽聽市場的反饋,在大多情況下是好事。
  • Pivot — 當你已經花很多精力在一個產品上,如果發現沒市場,這時候不要說是 pivot,連叫你刪一個大功能可能都很難。你會開始陷入「找洞給產品填」,而不是「做產品去填洞」的模式,這往往會大大降低成功機率。
  • 真實反饋 — 很多使用者的真實反饋,是要在你看過他親自用你的產品,才會得到的。如果一個產品沒有不斷經歷這個過程,往往很難達到超棒的使用經驗。
  • 複雜的毛病 — 當你花九個月做一個產品,往往難免會加很多功能,最後便犯了複雜的毛病。複雜不只難以行銷,也難以維護。

簡而言之,精實到完整,真的就是一個連續的光譜。每個創業團隊都會座落在其中的某一個點,沒有人說哪個點就是最好,哪個點就是最差。但從實務經驗上來說,越是沒有經驗的團隊,如果選擇越往精實靠,那最後失敗的機率會比較低,因為你會給自己多幾次嘗試的機會。

而追根究柢,精實創業,也不過就只是要減少你失敗的機率,如此而已。

想要研究、實踐精實創業?第四屆育成計畫,歡迎你加入我們。

(image via andrea_r, cc license)

關於創業的 10 個不同點 — Paul Graham、Joel Spolsky 和 Jamie Lin

May 18th, 2011

36 氪的 @truant 昨天寫了一篇很棒的文章 — Paul Graham 與 Joel Spolsky 的 10 個不同點,詳細比較了關於「創業」,Paul Graham (保羅‧葛蘭) 和 Joel Spolsky (喬‧史波斯基) 這兩個目前北美最受推崇的「名家學派」,各自不同的看法。讀完了之後我也有很多想法,所以決定跟大家分享一下。

我知道把自己跟他們兩位神人比較完全是臉上貼金行為,不過重點是關於創業的經驗和心法,請大家就別拘泥於形式。更重要的是這裡面的每一個建議,其實都只是從我們自身微小的經驗和極少的採樣、觀察中萃取出來的,所以沒有一定的對錯,尤其是時空背景可能已經改變,所以你們要自己學會判斷,然後選擇合適的策略。

  1. 開始
    • PG:  找到可以支持3個月開銷的種子資金,啟動項目。
    • JS: 支持不了2年?先來我的公司吧,我這裡工作環境很酷。
    • JL: 自己先存一點錢,確定半年一年不會餓死,就開始做吧!
  2. 天使投資或風險投資
    • PG: 需要時從天使或創投那裡拿更多的資金。
    • JS: 創投?想都別想,他們都是低能兒。
    • JL: 錢反而是次要,你需要的是找能幫助你的人,然後用投資把他們綁進來。
  3. 神奇公式
    • PG: 開始一家創業公司,努力工作4年,然後賣給某個人,解決錢的問題。
    • JS: 一點一點建立偉大的公司。
    • JL: 重點是這家公司的價值、成長潛力,如果你建了一個好公司,什麼事情都有可能發生。
  4. 微軟
    • PG: 微軟邪惡。
    • JS: 微軟很好。
    • JL: 微軟的伺服器軟體很爛,但是 Excel 還是很棒。我之前把 SharePoint + Excel 拿來 Hack 成 Issue Tracking System,其實還蠻好用的。
  5. 基本原則
    • PG: 與聯合創始人工作在租來的公寓裡是最有生產力的階段。
    • JS: 建立公司,公司是偉大的工作地點。
    • JL: 一開始的階段是最有開創力的,找到 PMF/Business Model (商業模式) 後,就必須建立制度,其實是一門更難的工作。
  6. 規範
    • PG: 儘早做出原型,然後不斷的完善,不需要規範。
    • JS: 實施之前製定規範。
    • JL: 找到 PMF 前,可以開始想規範的事情,但是不必急著實施。
  7. 步驟
    • PG: 不要提步驟,只要發布你的產品。
    • JS: 儘早確立步驟– 更好程式管理的12步。
    • JL: 過程中不斷的去優化開發、原始碼管理的流程。
  8. 計劃
    • PG: 當事情發生時,偉大的黑客計劃自己,沒有必要為事情做計劃。
    • JS: 為每件事做計劃– 你未來可能會遇到的困難時期,早期bug追踪等。
    • JL: 腦海中永遠都要有 B 方向和 C 方向,但是不用有想得很仔細,那就浪費了時間。
  9. 以微軟為核心
    • PG: 創業公司創始人用微軟的東西為核心建立公司注定會失敗(偉大的黑客自覺的不用微軟的東西)。
    • JS: 如果你支付的起錢給微軟的話,用一切跟微軟相關的東西。
    • JL: 微軟有很多東西是免費給創業團隊用的,請多多利用。至於伺服器,千萬別選 Windows Server。
  10. 歡迎大家補充。

以上,就是關於創業的一些想法,我和兩位大師的一些不同意見,希望能給你們一些想法和啟發。

PS. 本周五 (5/20) 1:00pm,appWorks 將在台大國際會議中心舉辦「appWorks Demo Day #2」,參與第二屆 appWorks 育成計畫的 12 個團隊,將在那裡向全世界展示他們六個月來辛苦創業的成果,歡迎關心我們的朋友,一起來見證這個台灣網路創業史上的另一個里程碑

(Image via scobleizer, CC license)

為什麼工程師的薪水和生產力如此不成比例?

April 29th, 2011

算起來軟體工程師大概是全世界最特別的一種職業,因為一個最好的 programmer 和一個最爛的 programmer,生產力相差至少 10 倍,有時候甚至可以高達 100 倍。這在其他的職業幾乎是沒聽過的 — 像 Jordan (麥可‧喬丹) 這樣強的籃球員,平均一場比賽的生產力,頂多也只是菜鳥板凳的 10 倍。即使是其他腦力、創意密集的行業,例如:IC 設計、建築、商品設計等等,生產力的差別也都是在 10 倍的這個級距,很少達到 100 倍的。

但又為什麼,當 Jordan 的薪水是 NBA 菜鳥的 100 倍,一流建築師的費用是菜鳥的 1,000 倍時,最好的軟體工程師,他們所賺得的卻往往連新人的 5 倍都不到?這個問題我一直想不透。它也不是壞事,因為很久以前當我第一次發現了這個現象後,我就學會要花 3 倍的價錢去顧一個 10 倍強的工程師 — 多麼划算的一個買賣啊!只是這件事情發生的原因,讓我非常的困擾。第一,它一點都不符合經濟學上「邊際效應遞減」的原則,你看其他職業,例如上面提到的 NBA,當你要雇用一個生產力 10 倍的球員,你必須付出 100 倍的成本。更重要的是,它一點都不公平,生產力 10 倍的人,就算沒有拿 100 倍的薪水,少說也應該要拿 10 倍的薪水。

直到昨天,讀了 John D. Cook (強‧庫克) 的這篇文章:「Why programmers are not paid in proportion to their productivity」,才給我了一個天大的啟發。

原來,這件發生的原因主要有兩個 — John 其實也是引述  Joel Spolsky (喬‧史波斯基,有名的 Joel on Software 作者) 的說法:

第一,雖然全世界的工程師優劣差很多,但是一間公司的工程師優劣卻是差不多的,因為一流的工程師不可能長期忍受跟一群蠢蛋一起工作,所以遲早會離去,於是久而久之這間公司的工程師品質就會趨向一致 — 這也就是為什麼你必須要花很多力氣在團隊上面

而另一個更重要的原因,是一個好工程師的生產力,其實很難被察覺。如果你要判斷一個業務好不好,那很簡單,看看他的業績就行了。你要看一個建築工人的生產力,那也很簡單,看看他多快把房子蓋好就行了。以此類推,如果你要知道到一個軟體工程師的生產力,就看看他寫了幾行程式…

大錯特錯!!

一個軟體工程師生產力最高的時候,是當他可以少寫幾行程式的時候。當他可以用一些現成的東西,在很短的時間內拼湊出你需要的產品、解決方案的時候;當他可以跟你明確的溝通,不會浪費時間在開發錯誤的東西上的時候;當他可以正確的解讀數據,然後快速的修正產品的時候。這些…

通通不是用幾行程式碼去衡量的!!

問題是當一個優秀的工程師,快速的把產品湊出來,或者是很有效率的溝通時,老闆的反應是什麼?99.9% 都沒有辦法聯想到這就是極致生產力的表現,然後說:「嘿!我應該幫他加薪 10 倍!」所以,難怪好的工程師往往沒辦法獲得合理的報酬。

因此,如果你是創業團隊,該怎麼做?當然是用力的利用這個市場不平衡,把優秀的、在大公司鬱鬱不得志的工程師,通通都吸收到你的團隊來。而這也就剛好解釋了為什麼 EZTABLE 會說:我們在找的是「人」,而不是技術

PS. 意猶未盡的人,這裡有一篇 Hackers vs. Coders 的故事。

PPS. 我超喜歡下面的討論,比文章本身還精采,大家千萬不要錯過。

(Image via scobleizer, CC license)

©2020 MR JAMIE.
網站由 Allen Hsu 設計 | Logo 動畫由 Wen Chen 完成