September, 2011的文章

昨天早上在宏碁基金會主辦的龍騰微笑競賽當 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)