Author Archive

昨天早上在宏碁基金會主辦的龍騰微笑競賽當 mentor，跟入選這一屆決賽的 15 個學生團隊分享我這 12 年來的經驗，然後回答了他們很多關於創業的問題。其中關心指數第一名的還是「如何面對失敗」，這個題目我已經寫了很多，包括：「失敗了，怎麼辦」、「我們要避免失敗」和「成功與失敗」等等，今天就不繼續深究。

我想聊的是第二多人關心的，那就是如何從失敗中逐漸找到成功。這個題目我其實也寫了 不少，不過昨天晚上突然想到，講了那麼多，這件事情根本就可以用很簡單的四個字說完，那就是：

製造意外

邏輯很簡單，如果你去觀察，大多數的成功都是在追求 A 方向時，不小心找到了 B 市場 — 例如威而鋼，當初本來是要研發來治療心臟病的，想不到臨床實驗證明，吃了之後心臟病沒有好，反倒有了神奇的副作用。類似的故事在創業史上一而再、再而三的發生，我想這足夠證明「成功」，在大多數的情況下是沒辦法製造的。既然是這樣，那我們何不乾脆放棄，反過來製造通往成功的那個東西，也就是那些「意外」。

什麼意思？

我的觀察發現，在做一個產品嘗試時，尤其是第一次創業的團隊，他們往往會過度專注在要讓「這個」產品成功，把所有的心力都投注在上面，接著就陷入了「線性思考」的毛病。他們的眼睛、耳朵漸漸關了起來，於是看不到市場給的其他信號，這時候，本來有可能出現的「意外」就因此消失了。這其實跟之前寫到的「幸運的人」症狀很像，太專注於一個目標，你就變成了不幸的人。

怎麼改善？

而要改善這個情況，提升成功的機率，那我們就應該改成「製造意外」的模式。首先，你必須要多方嘗試，在能力的範圍內，每一個 idea 都給它一些機會，做很多小嘗試，而不要太早陷入一個長期的大產品裡面。再來，你必須要保持警覺，在每個小嘗試的過程中收集所有有用的信號，來幫助你找到那些可能的意外。也就是說如果做一個六個月的大產品會讓你有一次的機會碰到意外，那做 24 個一星期的小產品，就會讓你有 24 次機會碰到意外，期望值當場就增加了很多倍。

而即使你已經找到 Product-Market Fit，進入成熟的規模化的階段，你還是可以給你的團隊一些自由的時間去發現意外，提升效率。例如 Slideshare 工程師寫了一個午餐機器人，意外發現這讓大家少浪費許多時間思考去哪裡吃飯。在辦公室內裝了一個「程式碼佈署鈴聲」，意外發現這可以有效的減少溝通的毛病，接著想到可以用來通知大家有用戶付費，作為激勵士氣的好工具。

也就是說，各位創業者，從今天開始，別再一味的追求成功了，在那之前，讓我們先製造更多意外吧！

意外發生密度最高的地方 — 第四屆 appWorks 育成計畫歡迎你的加入。

(image via dunechaser, cc license)

在 appWorks 有一些問題我們常常討論，例如：用什麼工具、做什麼產品、該怎麼行銷、該跟誰合作、怎麼合作、什麼時候增資、該拿多少錢… 等等，這些問題往往沒有一定的答案，也必須要視情況而定。但越是沒有標準答案的，我認為越是應該多討論，這樣才能幫助創業者們根據自己的情況，定義出最適合自己的處理方式。

而關於 coding，「要不要寫 test」就是其中有一個這樣的問題。我個人的意見是當你要做一個非常簡單、用完即丟的 MVP，那不必寫 test。如果邏輯比較複雜、日後有維護的必要或是有和人家協同工作，那你一定要逼迫自己寫 test。

這絕對不只是完整性、邏輯性或是身為一個工程師的職責問題，而是你如果不寫 test，就是跟自己過不去 — 跟好的 comment/documentation 一樣，不做的話，日後要維護時，你將會花更多時間在弄懂自己當初寫的 code，當別人要用你的東西，你也必須花更多時間跟他解釋，這不就是跟自己過不去嗎？

我得承認關於更深入的判斷什麼時候要寫 test、該怎麼寫，我不是專家。但是今天讀到一篇文章寫得很好，在這裡跟大家分享。

1. Test 讓你用程式功力去挑戰你的程式功力 — 身為工程師，大家最討厭的就是不斷的手動測試了，那何不把這些寫成程式？況且最好的進步方法就是以己之矛，攻己之盾，這樣不斷的循環下去，你的程式功力一定突飛猛進。
2. Test 讓你跟你寫的程式還有你自己對話 — 當你若干時間之後回來看自己寫的 test，你將會重新檢視自己當初的邏輯 — 這樣複雜的錯誤處理真的有必要嗎？這個物件夠獨立嗎… 等等，並且想清楚你寫的程式跟整個系統的架構是否吻合。
3. Test 提醒你程式是用「用了」多少行衡量，而不是「寫了」多少行 — 記住，最棒的程式碼，不是程式碼！
4. 好的 Test 設計還包含好的 Test 註解 — 如果你寫好的測試，別人更容易了解你的程式，和如何跟你介接。
5. Test 讓你可以看穿別人寫的 code — 同樣的道理，如果大家都寫好的測試，那你可以更容易了解別人寫的 code，大家都會進步的更快。

以上，就是一些關於寫 test 這件事情的觀念，希望能夠讓你更認同 test code 的價值。或許你有更有趣的經驗？歡迎留言跟大家分享。

想要在臥虎藏龍的 appWorks 跟高手們一起創業？第四屆 appWorks 育成計畫歡迎你的加入。

(image via richardmoross, cc license)

做這個工作最大的好處，就是每天都會有創業者來找我聊天。他們真的很有創意，會提出許多你從來都沒有想過的 ideas 和做法。不過也常常發生的，就是這些 ideas 最後都變成了科幻小說的劇情。

創業是科學的

創業，尤其是網路創業，其實是很科學的。除了好的 ideas，你必須要用數字去證實這些 ideas，到底是有價值還是沒有價值、有效率還是沒有效率、消費者買單還是不買單… 等等等等。例如我上星期寫了這篇「Mr.Jamie 網誌的流量與營收秘辛」，其實就是在示範數字的解讀 — 今天如果我要最佳化這個網誌的營收，那應該多推薦書籍，不過那不是我寫網誌的目的。

Science vs. Science Fiction

而科幻小說和科學之間的差異，就是 Science Fiction 偏重作者主觀的感覺，或者只採取自己願意相信的數據。舉例來說，今天早上讀到的一篇文章，美國 10 年全球反恐戰爭，每年花費 750 億美金，結果呢？這些年來在國外死於恐怖分子攻擊的美國公民人數比死於車禍、大腸病變的都還要少。

當然這不是最好的例子，因為保護每一個人民是政府的責任，但如果你是創業團隊，與其一廂情願的花費更多錢在開發反恐裝備、制度，讓使用者的生活更不便，還不如把汽車安全和大腸檢測的儀器做好。這也讓人想到台灣每年要賠在面板、DRAM 產業上的幾千億資金，如果只要拿 1% 來投資網路業，那該有多好。這些，就是科學和科幻小說的差別。

假科學

另外一個常犯的錯誤，就是把因果關係的邏輯搞混的「假科學」。例如我們常常說「黑人比較會運動」，因為觀察到從 100 公尺、馬拉松、籃球到拳擊，獲勝的人常常都是黑人。但事實上，這件事情跟黑黃白一點關係也沒有。以長跑為例，常常獲勝的人其實都是肯亞人，而且都是肯亞的南地人 (Nandi)。也就是說，南地人有著一些特殊的基因，讓他們在長跑上更勝過其他地區的人。

而常常贏短跑的則都是牙買加人和美國人，其他非洲人根本沒有機會。所以跑步這件事情跟黑黃白其實一點關係也沒有。事實上，大部分的事情跟黑黃白都沒有關係 — 在同一顏色人種中，基因的差距影響高達 85%，但是在不同顏色人種之間的影響，只有 15%。

網路業也常常有類似的假科學，例如用「年齡」、「性別」去區分你的客戶。這是一件愚蠢到不行的事情，首先，誰知道電腦影幕前坐的到底是誰。再來，會買單的人就是會買單，你管他是幾歲、男的女的，重點是他買了之後還會不會回來，即使是一個 80 歲的老阿公，如果一試成主顧，你還是要好好服務他。所以一天到晚在那邊講我們要服務「女性」、「25 歲」的使用者，其實透露的是你對科學的不理解。與其那樣說，還不如說我們要服務所有「想要用高級保養品有效永保青春」的消費者。

而精實創業說穿了，也就只是這樣而已。把科學的方法用在創業上，讓你不再矇著眼睛寫小說，結果當然是大大增加創業成功的機率。這樣，你懂了嗎？

準備好把靈魂出賣給科學了嗎？第四屆 appWorks 育成計畫歡迎你的加入。

(Image via dahlstroms, CC license)