Archive for the ‘管理學’ Category

4 個造成創業失敗的最重要陷阱,你該如何避免?

Monday, May 9th, 2011

我常說創業跟棒球很像,即使是全世界最厲害的打者,10 次上場打擊也有 6 次要摸摸鼻子下來,更何況你是剛剛開始拿球棒的新人。所以身為一個創業人,你的目標不是避免失敗,而是認知到你一定會失敗,然後學會如何從失敗中獲取教訓,讓你的打擊率一次比一次更高。

不過雖然如此,就像上場打擊一定要帶球棒一樣,有些創業失敗的陷阱其實你大可以避免。這些可以說是創業必要的基本觀念,很多前人已經經歷過了,你們學起來就好,不用自己嘗試一次。昨天剛好讀到一篇 Elad Gil (伊列‧蓋優) 寫的「4 Ways Startups Fail」(4 個新創團隊失敗的原因),我認為寫得非常好,按照慣例,原文不長,我鼓勵你們去讀讀。以下,則是我加入自己的經驗後整理出來的版本:

陷阱一:錢燒完了

大多創業團隊失敗的原因,不是在募不到創投的資金,而是在募到錢後開始盲目的花費,搬新家、一股腦的雇用工程師、每個人一台最高檔的 MacBook Pro 筆電。在你發現之前,你的公司已經只剩下 6 個月的現金水位了,但是你根本還沒找到 Product/Market Fit,怎麼辦?只好再去跟創投伸手要錢,我問你,這時候誰會再給你錢?

如何避免?

  • 精實創業 — 只把錢花在最有效率、生產力的地方 (我再說一次,精實指得是效率,不是摳門)
  • Product/Market Fit 優先 — 大多時候找 PMF 是不需要 (一大筆) 錢的
  • 假如明天開始創投都垮了 — 即使你拿到一些資金,你要當作你永遠不會再拿到更多
  • Hack Everything — 管理、行銷、人事、營運,所有的事情,都去想要怎麼把錢花得更有效率

陷阱二:團隊分裂

每個創業團隊都會吵架,但是解決的方式大不同。如果大家是就事論事,最後很快的做出結論,那還好。如果吵到不相往來,彼此看不順眼,甚至公司變成兩個黨派,那就非常糟糕。

如何避免?

  • 明確的分工 — 共同創辦人間要有明確的分工,一個事情就要有一個總負責人 (Direct Responsible Individual),關於這件事情,大家都要聽他的話
  • 認清決策一定會有錯誤 — 有些人一旦自己的意見不被採納,就陷入一種看好戲的心態,等著看對方出糗。這對於團隊一點好處也沒有,沒有一個人知道什麼會成功,什麼會失敗。如果這個決策最後失敗了,原因往往也跟你預測的不一樣。全部的人都在同一條船上,如果團隊決定了一個方向,那每個人都必須要盡全力讓這個東西成功,失敗也是每個人的責任,每個人的學習機會。
  • 開門見山的溝通 — 團隊這麼小,就你們幾個人,要養成什麼話都說出來的習慣,如果連這麼小的團隊都有溝通上的障礙,那你們注定失敗。

陷阱三:市場不對

很多創業失敗的原因,是選了一個錯誤的市場。大多數是太早,比較少是需要這樣東西的人不多。

如何避免?

  • 專注在找 Product/Market Fit — PMF 的重點是 Market 的需求,而不是產品本身的功能酷不酷,設計炫不炫,千萬別搞錯了
  • 選一個大/成長/多金的市場 — 千萬別搞錯了,大不一定要是幾億人,如果有 300~500 萬人有這樣的需求,而且每個人都有很高的付費意願,那也是很棒的市場。
  • 適時 Pivot — 苗頭不對,趕快 Pivot 吧!

陷阱四:爛咖投資人

相信我,這世界上最恐怖的不是笨蛋投資人,而是「不懂又想要插手」的投資人。他們會叫你趕快多雇一點員工、干預產品決策、沒事叫你開董事會、做報告,甚至還想要把你開除,找「專業的人」進來「管理」,天啊!

如何避免?

  • 只跟「你需要的人」拿錢 — 在找到 PMF 前,其實你不太需要錢,所以如果你跟這個人拿錢,應該只是為了你需要他成為你的支持者,幫助你找到 PMF。
  • 做好你的功課 — 拿錢之前,先跟別人聊聊,確認這個投資人帶來的是價值,而不是毀滅。
  • 過半 — 找到 PMF 之前,你需要能夠快速 Pivot,在那之前讓投資人過半,是很不好的架構。
  • 董事會 — 在找到 PMF 之前,董事會其實沒什麼功能。

以上,就是會造成創業失敗的四個最重要陷阱,以及如何避免,提供給你們參考。不過說穿了,其實也很簡單,就是在找到 Product/Market Fit 之前,請你什麼事情都不要做,專心的找 PMF,那就對了!

PS. 5/20 (五) 1:00pm,我們將在台大國際會議中心舉辦「appWorks Demo Day #2」,參與第二屆 appWorks 育成計畫的 12 個團隊,將在那裡向全世界介紹他們六個月來辛苦創業的成果,請先圈好你們的行事曆,更多資訊過幾天會公布。

(Image via Pierre J., CC license)

程式設計的 Top 10 做與不做

Monday, May 2nd, 2011

聊完了軟體工程估算時間的問題,工程師薪水的問題,今天來和大家分享兩個很不錯的程式設計「做」與「不做」列表。首先,是 Andres Taylor (安綴斯‧泰勒) 寫的「Top 10 Things Ten Years of Professional Software Development Has Taught Me」,翻成中文就是「十年的程式設計經驗教我的十件事情」。

原文不長,裡面有很多不錯的觀念,我鼓勵你們去讀讀。以下是中文版:

  1. 物件導向比你想像中的還難,很多
  2. 程式設計師最重要的技能:溝通
  3. 你必須要學會說「不」
  4. 如果所有的事項都一樣重要,那意思是它們都不重要 — 無論如何必須把先後順序排出來
  5. 千萬別把事情複雜化
  6. 深入問題的核心,但是不要被困住了
  7. 非常清楚的了解其他人在做的事情,無論是行銷、設計、客服
  8. 你的同事就是你最好的老師  (你該試試 Pair Programming)
  9. 無論如何最後的產品必須是好用的
  10. 這世界上總會有一些混蛋

而至於什麼事情應該要避免,大家可以參考 Dare Obasanjo (戴爾‧歐巴桑侯) 寫的「Top 10 Signs Your Software Project is Doomed」,翻成中文就是「十個軟體專案注定失敗的跡象」。

  1. 第一個版本就想做太多功能
  2. 採用太新的技術平台
  3. 「複雜的問題,需要複雜的解法…」
  4. 團隊人手不足
  5. 成員開始隱藏進度落後的事實和原因 (Schedule Chicken)
  6. 不斷更改、增加的需求 (Scope Creep)
  7. 不知道客戶在哪裡
  8. 2.0 症候群 — 後繼版本非要更大、更強、更美 (Second System Syndrome)
  9. 與公司裡面另一個很有份量的產品競爭 (這在創業團隊應該不可能發生)
  10. 根本從一開始就選了一個你無法解決的大問題

以上,跟大家分享,希望能夠幫助你們在做的產品更順利、更成功,加油!

(via Coding Horror, photo via stianeikeland CC license)

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

Friday, 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)