排灣會館: 走上創業之路的你，應該避免的18件事（中）

2010年8月19日星期四

走上創業之路的你，應該避免的18件事（中）

由排隊彎彎透過 Google 閱讀器傳送給您：

走上創業之路的你，應該避免的18件事（中）

經由 Inside Lawrence 著 (日期為 2010/8/18)

前言

Paul Graham是個成功的創業家、程式設計師、知名部落客與科技寫手，多年來他在網路上發表了許多文章分享他對於創業或是科技領域的看法，他在2005年創辦了一家特別的創投公司Y Combinator後，這些文章也成了Y Combinator與所有網路創業團隊的指導教材。如果你對於Paul Graham或Y Combinator還不了解，可以先從以下兩篇文章開始閱讀：

在走上創業之路的你，應該避免的18件事（上）我們已經跟各位讀者分享了六件應該避免的事情，如果有任何指教或討論，歡迎透過 twitter.com/deduce 與我聯繫。

你也可以訂閱Inside電子報，訂閱連結：http://bit.ly/subscribe-inside，我們會將最新的文章寄到你指定的電子郵件信箱。

7. 選了一個錯誤的平台(Choosing the Wrong Platform)

除了雇用了不好的程式設計師，選擇錯誤的平台也是必須避免的問題。

舉例來說，很多在2000年.com泡沫化時期的新創公司，都是使用Windows作業系統。微軟已經收購Hotmail多年後仍一直使用FreeBSD作為Hotmail提供服務的作業系統，其主要原因大概是因為Windows的作業系統無法有效率地處理Hotmail整個系統營運時產生的系統負擔。如果Hotmail的創辦人當初使用Windows作業系統，大概也是早就爆炸了。（不過顯然微軟在近幾年，伴隨著Hotmail的改版與Windows系統提供Web服務的效能改善，目前的Hotmail前端服務是直接由ASP.NET技術與Windows Server在提供的）

PayPal，全球知名的線上信用卡金流系統，在當年合併X.com時，新任的CEO想要將平台從Unix架構的系統轉換到Windows架構，即使PayPal的共同創辦人Max Levchin很明確的指出如此的系統轉換，在架構上的延展性不過只是多了1%的效益，新任的CEO還是決定要進行轉換。不過最後的結果是PayPal沒有換掉他們的Unix架構系統，而是將CEO換掉。

在這邊談所謂「平台」是個很模糊的字眼，平台可以是作業系統、開發用的程式語言或是以某個語言打造出來的開發框架，選擇任何的平台決定了你所能得到支援與可能面對的各種限制。這就像蓋房子一樣，如果你一開始就決定你要蓋茅草屋，也選擇了一支擅長蓋茅草屋的團隊、採購了相關建材，在房子蓋好之後，除了砍掉重練，你大概很難房子升級為台北101。

關於平台最可怕的一點是，總是有一些看起來很棒、後勤支援完整的方案可以選擇，但實際上你選擇了它們之後卻足以摧毀你的事業，像是90年代的Windows、Java Applets都是很顯著的例子，尤其Java Applets在當時看起來好像是一種在線上提供服務很好的方式，誰知道當時選擇Java Applets創業的團隊後來幾乎全部都掰掰了。

你如何選擇一個正確的平台呢？最常見的方式是先找到一個好的程式設計師，讓他來幫你做決定。如果你本身不是個好的程式設計師，或是你找不到好的人選，一個方法是去看看頂尖的資訊科學系在他們的研究案中都用了哪些架構、平台，或許你可以找到不錯的答案。

前幾天我有個大學同學跟我說他想創業，找了一個兼職的夥伴開始用ASP.NET來打造他們心目中的好網站，我對於ASP.NET這個選擇感到些許的不安。我在過去幾年曾經利用ASP.NET開發過網站，我認為ASP.NET與.NET Framework、Visual Studio有其優勢，甚至在後來微軟也發展了ASP.NET MVC向知名的Web開發框架致敬（例如Ruby on Rails），加上Silverlight、Windows Azure Platform（微軟的雲端運算平台），在Web軟體開發上看似有完整的體系、後勤支援，然而，我認為對於一個資金不是那麼充足、技術不是那麼成熟的團隊來說，選擇ASP.NET所直接面對的問題可能就是大量的授權費用與系統建置費用。儘管微軟現在也很聰明地推出了BizSpark這類方案來推廣微軟技術、贊助新創事業，但長期來講，選用方案這個議題肯定是要很小心的。

我對於技術、平台、框架的選擇有以下的看法：

技術、平台或框架的成熟度
成熟度的檢驗指標可以從技術面深入探討，這部份要仰賴團隊的技術夥伴依照過往的經驗與專業能力，再加上對於目前各種框架的研究與分析、比較，以及是否有可供參考的最佳實務(Best practice)、是否已經有成熟的生態系(ecosystem)來提供各方面的完整支援，包括相關的技術知識、經驗與相關產業的支援。
另外，可以比較直觀的觀察打算採用的方案，目前是否已有成功案例或被知名的組織採用。例如，今年在Web領域很熱門的話題就是NoSQL相關的技術實作，其中由Facebook發起、目前是Apache基金會主持的開放原始碼專案Cassandra，其用戶包括了Facebook、Twitter、Reddit、Rackspace等知名廠商。另一個直觀的指標是目前發展的程度，同樣以Cassandra為例，儘管已經有知名網站採用，但目前版本發展到0.6.4版，就軟體專案來說其實還是很年輕、還有一段路要走，例如Flowdock前陣子就從Cassandra換到MongoDB，因為Cassandra用起來還是有些問題。
此外，就建置網站來說，需要具備各種專業知識，一個網站從無到有涵蓋的問題極為廣泛，其中在技術面又涉及了HTML/CSS/JavaScript、伺服器端語言、資料庫等基本問題，接著你可能必須要有版本控制系統、自動部署系統、伺服器與服務監控系統才能讓產品的開發與維護變得輕鬆，為了讓網站得以配合流量的成長，又涉及了擴充性、延展性的問題，你所選用的開發框架是否已經有對應的解決方案，這些都是要思考的問題。
整體投入的成本（短期、中期、長期都要考慮，從長計議）
包括採用方案的一次性成本、長期維護的成本、系統擴張的成本、開發的成本、尋找各種資源的成本、是否有授權的成本，甚至是在中長期才發現要轉換到不同的平台上時所需考慮的轉移成本。例如採用微軟ASP.NET，開發團隊每個人都要使用Windows作業系統，並且安裝Visual Studio才能進行開發，如果考慮到團隊的分工方式，甚至還要採購更完整的Visual Studio版本（例如提供給DBA、PM、Architect的專屬功能）；產品開發過程，還涉及到是否要採購足夠的SQL Server授權（SQL Server又是架設在Windows Server上，又有另一筆費用），產品本身提供服務的伺服器又是一筆費用。
花了這些錢之後，還要考慮到，同樣10萬元等級的伺服器，使用Windows作業系統與Linux作業系統所能提供的服務能耐，以及進行各種架構規劃時所需耗費的成本，包括建立Scalable Architecture或High Availability的成本，甚至你想部署到現在所謂雲端運算的平台上（例如Amazon的EC2），使用Windows跟Linux的費用與選擇性，都是可以直接在網路上找到答案的。
不是說用微軟方案就是錯的，但你必須知道這些能掌握的變因就在眼前，你是否有足夠的能力、人才、資源、金錢來駕馭這樣的架構與方案，倘若你的資金充沛、開發團隊超強、產品超強、業務超強，使用微軟方案可以讓你在短、中、長期都不需要擔心這些問題，那當然是很好的選擇。但我們目前比較窮，開放原始碼的方案可以讓我們在一開始的支出少一點，除非你已經很肯定開放原始碼的方案長期來講，路會走不下去，否則這應該是比較保險的方案。（在關於創業，你必須知道的13件事中也提到錢，省著點花）
另一個思考的方式是：目前世界上成功或知名的網路創業公司，採用ASP.NET提供服務的有哪些？與使用其他方案的團隊比較起來，比例又是如何？為什麼他們選擇採用特定的方案呢？

那麼，何謂選擇一個正確的平台呢？我們可以參考一個實際案例：網路創業實例：意外起飛、24小時累積10,000名用戶的Rapportive（關於Rapportive的服務介紹，您可以參考Rapportive：讓你的Gmail擁有Social CRM功能）

你永遠不會知道流量何時會湧進你的網站。過去如果建議你應該把系統的延展性做好，通常是個不好的建議（為了做到scalable，通常必須多花一些時間與金錢），但現在是雲端運算的時代，事情已經不一樣了。

想要擁有一個可隨時延展的架構(scalable architecture)，你只要選對廠商(hosting provider)就可以做到。

Rapportive的服務是放在知名廠商Heroku上，對於突然湧進的流量只需要增加Dynos的數量（Heroku提供服務的基本單位），基本上你是不需要修改你的程式的。

Rapportive採用Ruby on Rails作為主要的開發框架，使用Heroku作為提供服務的平台並且可處理延展性並省去部署系統或自行負擔系統管理成本等問題造成的麻煩，讓工程師可以將大部分的精神與時間放在產品本身的研發上。同時，以Ruby on Rails來講，各種關於網站經營本身相關的知識也都可以找到許多最佳實務的參考與對應的解決方案。倘若你使用ASP.NET，或是你使用PHP而經驗不是那麼豐富，在網站創業之路上會走許多冤枉路。

選擇一個正確的平台、正確的開發框架，不僅會讓你少造許多輪子，甚至有許多框架都是因為前輩經驗的精華才搭建起來的，善用這些經驗，可以讓自己的功力大大提昇、避開許多不必要的錯誤。

8. 推出產品的速度太慢(Slowness in Launching)

任何規模的公司都會面臨產品難產的問題，產品似乎永遠沒有做完的那一天，或是每做完一個段落就發現後面還有更長的路要走。軟體開發就是如此，你的軟體永遠都是85分的完成度，你總是必須努力的繼續打造你的理想產品並且釋出某個階段的產品給使用者。
產品推出速度要快的理由之一是快會迫使你在每個階段都完成一些事情，在你真的把產品做出來之前什麼都是假的，如果你很努力並且持續很快的在做一些事情，你至少可以看到一些事情逐漸完成；在我們尚未真正推出產品前，我們做的事情很簡單：關在會議室中假設人們應該會喜歡什麼功能、不喜歡什麼功能，但一切也都僅僅是假設罷了。當然，另一個產品開發速度要快的理由是你必須盡早推出產品，才能盡早了解你的使用者如何看待你的產品。

速度要快的原因並不是說要讓你的產品盡早接觸市場，而是你必須真的將想法付諸實現後並推出產品，你才真的是在創業。這個過程也才可以讓你真正了解自己究竟做了些什麼，你也會發現或許有些事情你做了但其實是在浪費時間。無論你推出了一個怎樣的產品、創造了什麼價值，重點是早點有機會了解使用者的想法。

創業團隊對於產品推出的時間點一再延遲總有各式各樣的藉口，這些藉口通常就跟人們在日常生活中用來推托各種事情的理由一樣。不過，就算你認為你的產品已經100%完成，你是否就會馬上發佈你的產品呢？

導致產品上市之日遙遙無期的原因，除了總是有一些藉口之外，可能還有一些具體的問題，像是工作效率不彰、沒有真正釐清要解決的問題、害怕必須去面對使用者、害怕產品發表後必須面對的評論、一次想做的事情太多、過度的完美主義等等。不過，幸運的是，如果你可以強迫自己跑快一點，你在面對、處理這些問題時，顯然都會有比較簡單的權宜之計。

總是有人認為微軟推出的產品（作業系統、軟體）不完美，但或許就是因為這些不完美，導致了使用者有更多需求產生，也造就了微軟持續打造新產品的動力；此外，在商業競爭的考量下，微軟如果無法適時推出產品以符合市場期待或是回應競爭對手的產品發展策略，就有可能失去大片江山。例如微軟的Silverlight在1.0時期實在很差（或許到現在也沒多好？），但當時如果沒把握時機推出，或許新釋出的Flash版本會在當時的新聞報導、網路圈佔盡鋒頭。

我們同樣以Rapportive的實際案例來看他們的經驗：

其實Rapportive並沒有想要這麼早推出產品，一夕爆紅真的是意外。但是事後來看，早點推出產品是真的滿有幫助的。使用者回饋的訊息很快就塞滿整個論壇，開發團隊很快就知道到底人們喜歡什麼、不喜歡什麼，而且也確實可以根據這些回報，決定接下來開發的先後順序。如果你沒有早點推出產品，你很可能做了不對的事情，而且你會很晚才發現這些事情做錯了。就算你做的事情都是正確的，你沒有早點推出產品也可能讓其他人搶先一步，佔盡鋒頭。所以，早點推出產品吧！

速度要快、保持敏捷很重要，郭台銘先生也勉勵過：

在現今世界上，沒有「大」的打敗「小」的，只有「快」的打敗「慢」的

9. 太早推出產品(Launching Too Early)

因為「推出產品的速度太慢」而失敗的團隊數量大概是「太早推出產品」而失敗的團隊數量的上百倍，但是太早推出產品也是我們必須注意的重點，因為你也有可能太早推出產品。針對太早推出產品可能帶來的主要危機是你在自砸招牌、自毀名聲，很有可能你推出了一個產品，也找到了一些初期的使用者，但因為產品實在不怎樣，這些人就再也不使用了。

很可能只要有10個關鍵人物對於產品感到極度不滿，產品也不是沒有被一炮擊沉的可能。

尤其某些初期的使用者，都是在網路上極有影響力的專欄作家、趨勢觀察家、部落客，他們的口碑影響到千千萬萬個使用者，你的團隊、你的產品是否都會因此被打上問號，是必須很謹慎面對的議題。

所以，到底是要做到什麼程度才能推出產品呢？Paul Graham在Y Combinator給予創業團隊的建議是這樣的，試著思考到底產品開發的策略、計畫為何，並且確定兩個重點：

產品對於創業團隊本身來說是很有用的
產品的設計是可以逐步擴充，接著儘速完成

這兩個重點對於Paul Graham以及很多程式設計師來說，經常也是在開發軟體的過程中很重要的思維。如果產品本身對於創業團隊本身來說就很有用，至少這個產品不是毫無用武之地的，因為至少你們已經擁有第一個客戶，也就是自己。很多成功的創業團隊都是先從打造創辦人自身需要的工具起家。

還是再次強調，Inside上曾提過37signals這個成功的創業公司（37signals的37個創業心法），文中也提到：

解決自己的問題會讓你愛上你做的事(Solving your own problem lets you fall in love with what you’re making.)

我在關於創業，你必須知道的13件事中也提到：

創業團隊可以先從打造一個能解決自有問題的工具開始，因為當我們所創造出來的資訊工具可以有效地解決我們自身的問題時，它或許也可以協助其他遇到相同困擾的團隊，更別說當我們開始進行行銷、銷售，我們更能設身處地的告訴我們的潛在消費者它是如何解決我們的問題的。

這兩點我們陸續跟讀者分享，這真的是很重要的一件事情。記住，試著思考究竟最終的大目標是什麼，接著將這個大目標拆解為許多的小目標並且寫下來，接著一步一步將這些小目標完成。實現這些小目標的過程對於提昇團隊的士氣非常有幫助，同時間你也會更清楚你正在做的產品，接下來還有哪些事情要進行。

記住：如果初期的使用者來試用你的產品，他們並不會期待你的產品可以解決所有問題，你的產品只需要解決特定問題即可。

10. 根本不知道要把你的產品賣給誰(Having No Specific User in Mind)

如果你不了解你的使用者，你就不可能做出使用者喜歡的產品。之前有提過，多數成功的創業團隊都是先從解決自己的問題開始。或許這其中是有跡可循的，你能從創業過程中累積的財富，會與以下兩件事成比例：你有多麼了解你正在解決的問題；你最了解的問題是否源自於自己的需求？

當然，這都只是理論，我們應該反向來說：如果你正在解決的問題是你根本不了解的呢？

有滿多的創業團隊都會進行假設，假設某些使用者會想要使用他們所打造的產品（事實上根本不知道是誰、是哪些人）。那麼，創業團隊自己的成員呢？這個產品他們自己會想用嗎？如果他們自己都不想用，那麼客戶在哪裡？你是想找到哪一種人？青少年？對在地活動感興趣的人？或是要找企業用戶？何謂企業用戶？哪一種企業用戶？加油站嗎？電影工作室？還是國防工業承包商？

你當然可以打造一個產品給某些人用，而不是給自己使用。事實上Paul Graham過去就是打造了這樣的產品（Viaweb，電子商務網站），但你應該要知道，這麼做是很危險的。

想像你正在開飛機，你必須有意識的操縱你的控制桿，而不是只是依賴直覺，同時你還必須透過各種儀表來掌握目前的狀況，正在創業的人，儀表板對你來說就是這些使用者的態度，你在設計產品的時候必須顯得有經驗、有方法一些，你不能再憑藉直覺判斷或猜想什麼應該可行、什麼不可行，你必須找到使用者並且試著評估他們對於產品的看法，你才知道這台飛機目前的狀況如何、該開往什麼方向、是否合乎自己的預料。

所以，如果你想做的產品，你自己不是用戶，那麼你必須趕快找到你的用戶，並且弄清楚你的使用者在想什麼，他們要的是什麼，讓他們試用看看你在做的產品（進行焦點訪談、封閉測試）。如果你找不到這些人，或是你也無法了解他們，那你很可能飛錯方向了。

如果你找不到用戶，很有可能是兩種情況：

你的產品、你的創新都不正確，根本沒有人要用，根本沒有你想像中的需求存在，或是你必須去創造出需求
你所設定的需求存在，只是還沒找到那群人罷了

如果是後者，你應該試著去找出那些人，但你也不能一廂情願的相信那些人存在，其實是不存在。如果是前者，你必須早點意識到這件事。

盡早推出產品、持續調整路線，可以讓我們少走些冤枉路，即使是推出產品來證明自己想法錯誤，也是一種收穫、一種讓想法進化的方式。

Vinod Khosla是Sun Microsystems的共同創辦人之一，他擔任過昇陽的董事長與CEO，目前從事創投工作。他曾經說過：

問題越大，機會也越大，沒有人會付錢請你解決不是問題的問題。

(Any big problem is a big opportunity. If there is no problem, there is no solution, and no reason for a company to exist. No one will pay you to solve a a problem that doesn’t exist.)

如果你所做的產品沒有解決任何問題，是不是意味著沒有人需要這個產品？你所做的產品是以什麼方式創造了價值？這是非常值得思考的問題，如果你的產品沒有解決問題、創造價值，那麼誰會花錢來買你的產品呢？

創新工場的創辦人李開復老師曾經說過：

創新本身並不重要，有用的創新才是重要的。

如果你對於你的產品創新，是深信不疑的，那麼你是否過於固執？如果你認為你的產品創新，是需要時間或是方法來教育使用者並創造出需求的，趕快找到使用者來驗證這件事情。

11. 募集的資金太少(Raising Too Little Money)

在美國，多數成功的創業團隊會在某個時間點募得資金。就好像前面談到多數成功的創業團隊都有不只一個創辦人一樣，從統計數據來看，能在某個時間點募得資金似乎也是個能否成功的指標。那麼，你們應該募得多少資金呢？

創業團隊的募資金額是以時間來衡量的，每個在一開始不賺錢的創業團隊（或說是幾乎每個創業團隊在一開始都不賺錢），在資金燒完並且決定喊卡之前都會有一段時間，這就好像你開著一台飛機在跑道上準備升空，你必須隨時搞清楚「你距離跑道盡頭還有多遠？」，隨時提醒自己當你們到了跑道盡頭的時候，只有飛機順利升空或是直接撞毀，你能做的就是在到達跑道盡頭之前盡力加速，達到應有的表現。

募得的資金太少，意謂著你可能沒有足夠的資源讓你起飛，如果現有資源足以讓你起飛，起飛後你想飛得多高又是另一個問題。通常你應該會想要飛得更高，例如你目前只有想法，你需要更多的資源讓你做出產品原型；如果你已經有產品原型，你需要資源來發表產品；如果你已經發表了產品，你會需要顯著的成長。當然這要看你的投資人願意投入多少資金，在你的產品還沒開始獲利之前，你必須能夠說服你的投資人。

所以如果你打算從投資人手上募得資金，你至少要取得足以讓你邁向下一步、飛得更高的金額，不管你是在哪個階段。幸運的是，募資成功後，錢要怎麼花、下一步到底是什麼，都是你可以決定的問題。Paul Graham建議一開始在這兩點都設定低一點的目標，不要因為募得資金就因此花了一些不必要的錢，記住你一開始的目標，趕快建立出一個穩固的產品原型，這會讓你擁有最大的彈性。

我認為，如果能募得的資金實在不多，不如別募資吧！這道理在關於創業，你必須知道的13件事中也提過：

我們大概找不到其他因素比起「分心」更容易讓創業團隊招致失敗。最糟糕的狀況就是那些貌似可以幫創業團隊帶來一些營收的副業，包括全職的工作、顧問諮詢、外包案等等。長期來看或許創業團隊可以有更多潛在的機會，但在這過程中你必須為了應付客戶（花錢在你身上的老大們）而中斷你真正重要的工作。事實上，募資也是一種讓創業團隊分心的因素，所以能避免還是盡量避免吧！

12. 花太多錢(Spending Too Much)

其實要搞清楚你是花太多錢還是募集到的資金太少並不容易。如果你的資金燒光了，這兩種說法都可以是你錢燒完的理由。唯一可以幫助你理性判斷到底真正原因是哪個的好方法是跟其他創業團隊做比較。不過當然，如果你募來了500萬美金，而且還把這些錢都燒光了，那應該是你花太多了。

燒太多錢已經不如以往常見，創業團隊似乎已經學會一些事情，例如在一開始應該要珍惜現有的資金，錢要省著點花，創業是出來打仗、上戰場的，不是開了一間公司來享受、到處跟人家炫耀說自己創業了，但其實可能沒多久這間公司就倒閉了。

不過，以Y Combinator來說，沒有一家旗下的育成團隊有錢花太兇或是募集到不夠資金的困擾，不只是因為Y Combinator投資的錢不多（所以創辦團隊其實沒什麼錢好花），而且Y Combinator旗下團隊通常都可以成功募集到一些資金。

將資金燒完其實有一種很常見的狀況：雇用了太多人。這種情況還會讓你有二次傷害，除了是每個月要燒的資金、人事成本會提昇之外，太多人會讓你向前跑的速度變慢，所以你會持續燒錢的時間也因此變得更久。Fred Brooks在人月神話一書中就有提到這個狀況。通常Pual Graham給Y Combinator育成團隊在人才招募上的建議有三點：