流言終結者 #2：「趕快申請專利保護起來…」

June 11th, 2011

大多數學校老師的問題，是他們一輩子都在做研究。由於沒有其他的實務經驗，他們很容易把學術領域的那一套，方便的套用在現實世界中。所以當你有一個不錯的創業想法，假如去找你的教授討論，他們很快就會跟你說：「這個東西不錯，趕快去申請專利保護起來。」

這個邏輯最大的問題，在於沒有認識到「專利」和「商業競爭」之間的真正關係。近年來最好的例子，莫過於長期位居全球線上金流市占率第一的 PayPal。處理網路付費，聽起來很簡單，問任何一個懂一點電腦程式的人，都可以跟你說就是把 A 的帳戶扣掉 300 元，然後把 B 的帳戶加上 300 元，兩筆資料庫存取，趴趴就搞定了。也難怪當初 PayPal 開始做線上金流平台時，全世界大概有 200 家公司在做類似的服務。

但是如果你跟消費金融行業的人聊聊，你就會發現處理任何金流往來，一點都不簡單。現金的流動本身或許很單純，但是當你把壞帳、詐騙、盜刷等這些隨之而來、必然發生的副產品列入考量，這件事情就變得非常複雜，往往根本就到了棘手的程度。而這就是當工程師 Max Levchin (麥克斯‧勒夫秦) 創辦 PayPal 長達一年後，才猛然發現的驚人事實。

當時 PayPal 的成長非常迅速，上線短短 18 個月後，每個月經手的金流已經高達美金上億元。也因此，該公司上下無不沉浸在突如其來的成功氛圍中，所有人都把目光放在「第一行」(營收) 的猛爆推進，卻沒有人意識到重大的危機正悄悄醞釀。直到有天 Max 閒來沒事，把資料庫的數據拿出來分析，這才驚覺事情有多大條。原來，PayPal 的營收成長雖快，壞帳增加的速度還要更快。由於壞帳的發生有一個時間差，如果他們再不做點什麼把它壓制住，PayPal 的壞帳比率很快就會高過金流手續費，這時 PayPal 將變成一個超級賠本生意，每處理一筆金流，不但不能賺錢，還要倒貼成本進去。

幸好 Max 在大學專注的剛好是資訊安全、加密等技術，於是他開始把解決 PayPal 的壞帳問題當做首要任務。不久之後，在與客服部門通力合作之下，Max 在 PayPal 內部推出了數個營運分析管理系統，最後有效的壓制住了壞帳。Max 以前的學校教授、同學知道了這個了不起的成就，紛紛建議 Max 趕快把這些技術拿去申請專利 –「保護起來！」他們說。

但 Max 知道他絕對不能這麼做，因為一旦他把這些方法拿去申請專利，其他 199 家還在賠錢的競爭對手，馬上就知道 PayPal 是怎麼做的了。即使他們不直接盜用，也可以想其他的方法繞過 Max 的專利。而且更重要的是，道高一尺魔高一丈，就像台灣的詐騙集團一樣，當初北美的網路蟑螂手法也是日新月異。Max 決定與其把心思資源花在專利申請上，還不如專心和他們對抗，才能繼續確定 PayPal 可以長期把壞帳比率壓在手續費之下。

所以，在網路的領域，專利其實沒有多少「保護」的作用，尤其在創業初期或是一個產業剛開始發展階段。因此，與其浪費時間在它上面，還不如專注在做出消費者需要、想要的產品上，並且透過不斷的更新，來維持競爭優勢。至於專利戰爭，等到公司達到了一定的規模再來布局吧！

這篇文章編輯後的版本，刊登在 2011 年 6 月號的《30 雜誌》上。

(Image via kwc, CC license)

36 comments »

人與才

June 10th, 2011

昨天的「最棒的程式碼」一文，下面出現了更棒的討論。其中 Arvin Huang 的留言，讓我想了一整天，他說：

能夠 document 清楚自已程式含義的人，代表著他胸有成竹，程式的可用性就很高。本人的經驗是在試用一個程式員的時候，有時候您不用去看程式，因為看別人的程式是很累人的事，看他的 document 則是很好的方式，能夠很好的注解自已程式的人，基本上都是 A 咖級的，也是可以裁培的人。

這段話讓我一直在想「人才」這個字的涵義，既然它是「人」和「才」兩個字的組合，那麼一個真正的「人才」，是不是也應該要是「人」和「才」兼具呢？如果「才」指得是能力，那這裡的「人」，我認為應該是個性、價值觀、潛力、工作/溝通的態度等等。

當我們在找夥伴、團隊成員時，往往放很多精力在「才」上面。懂不懂 LAMP、寫過幾年 RoR、什麼學歷、什麼經歷，但是常常花太少的時間在「人」上面。所以我看過不少團隊紙面上看起來非常不錯，但很奇怪就是一直搞不出什麼屁來，仔細研究之下，才發現原因出在成員的價值觀和溝通不良上面，白白浪費了每個人身上的好功夫。

所以在找夥伴時，除了能力，我覺得大家必須要同樣重視「人」這個原素。傳統的面試方式，其實很難讓你看清楚一個人，所以你必須要用一些新的方法。Mixer Labs 的 Elad Gil 前幾天寫了一篇關於他們公司如何徵才的文章，我在裡面發掘了一個是很重要的「看人」方法：

啤酒測試

每一個 Mixer Labs 有興趣邀請加入的人，他們都會帶他去吃個晚飯、喝點小酒，確認這個人和 Mixer Labs 團隊的文化是契合的。有一次，一個非常非常強的工程師，大概是他們面試過最強的，在幾杯黃湯下肚後，居然講出了一些種族歧視的話，這讓 Mixer 最後決定不要雇用他。

這個方法其實 appWorks 也用過，當我們在找 Associate 時，就請了幾個我們覺得不錯的應徵者去參加 Startup Mixer，看看他們跟創業者們的互動，是不是能夠融入我們所屬的社群。這個過程也幫助我們最後找到了 Joan，將近一年後，事實證明是非常正確的選擇。

所以，我想無論是 Arvin 的看 documents 方法或是 Mixer 的啤酒測試，我看到的是他們對「人」的重視，事實上，大多的時候，「人」是比「才」還重要的。這個問題，我覺得值得大家好好的去想想。而如果你有什麼其他的好方法，也歡迎你留言跟我們分享。

(Image via brandoncwarren, CC license)

42 comments »

最棒的程式碼，不是程式碼

June 9th, 2011

上次聊過工程師的生產力不應該用程式碼來衡量，因為他們的極致生產力，是在少寫幾行程式，而不是在多寫幾行程式。今天剛好又看到兩篇文章，可以用不同的面向延伸、解釋這件事情。

首先，是一位跑去日本教英文老師的前任軟體工程師，發現了寫程式和學語言間的共通性，他說：

這些工程師往往可以輕鬆的通過面試，但當他們真正開始工作，卻讓人大失所望。我讀了很多關於這個問題的研究，但當我越看它，就越發現這些「殘障工程師」，就好像我的英語學生一樣。他們有 5,000 字的詞彙，書裡面的每一個文法都背得滾瓜爛熟，但是就是說不出一句話。

我的理論是，程式其實就跟寫作沒什麼兩樣。多數的程式概念上一點都不難 (跟你想的不一樣)，我們搞不好的原因往往只是寫作能力太差。大部分的工程師根本就不是「流暢」的語言使用者，也沒有努力想要讓自己變得流暢。他們不去多讀讀他人的程式，看不懂也不會使用「成語」，更不會「用程式語言來思考」。這些人寫出來的程式很糟，因為他們根本就是電腦語言的三歲小孩，卻試著要寫一本小說。

所以如果你是工程師，多讀讀別人的程式碼，是很重要的，就跟學習寫作一樣。

相反的，如果你的程式想要讓人家讀懂，那 documentation 是非常重要的。GitHub 工程師 Zach Holman 發表了一篇非常棒的文章，詳細解釋了為什麼你要寫文件，怎麼寫。

Documentation 是個人的 — 相信我，你以後一定會回來改這些程式，如果要讓未來的自己更快進入狀況，把事情搞定，今天請你務必把東西寫清楚。
Documentation 是清楚的 — 如果你不把你推出去的程式碼講清楚，那根本是在幫自己找麻煩，以後一定會出現一堆 bugs、困惑的同事，最後搞得自己更累而已。
Documentation 是可以測試的 — 因為你必須要把程式的邏輯解釋清楚，這讓你重新思考自己的寫出來的東西是不是符合原始精神，有沒有更好的方式。為了不在寫文件時陷入無法解釋的難關，這也迫使你簡化每一個功能，把一個複雜的東西切成好幾個功能。
Documentation 是可以比較版本的 — 好的文件可以讓版本間的比較更容易，也讓團隊合作更有效率。
Documentation 是行銷 — 透過好的文件，可以讓下載你軟體的人更容易開始使用，這也大大提升了轉換率。
Documentation 讓你在床上表現更棒 — 這點 Zach 還在驗證，不過他認為建立好的文件讓你很酷，這應該對自信會有幫助。