建立自信 不要害怕被拒絕

人類社會的人際互動中，難免會有拒絕或被拒絕的經驗。有些人臉皮比較薄，一旦被拒絕會感到自尊心受損，變得缺乏自信，或因而過著逃避的生活。但也有一些人臉皮比較厚，不怕被拒絕，愈是被拒絕，愈是能愈挫愈勇。

多數人最難忍受的還是被拒絕的經驗。專家認為，這是因為多數人臉皮比較薄，凡事從自我出發，在意別人對自己的看法，因而，當別人忽略自己的感受或出言不遜時，我們心裡就開始自我挑剔，認為自己做錯了什麼或是怪自己將事情搞砸了。　　　　　

專家建議一些技巧，讓自己學習多一點自信，正視拒絕的正面意義，踏出自我：

1.不要什麼事都往自己身上攬。學著重新審視別人一些不好的行為，並認清有些事情不都是自己造成的。

2.不要被別人的情緒所牽動。拒絕別人加給自己消極、憤怒和過度敏感的負面情緒。如果受到負面想法控制了自己的情緒，可以採用調整情緒鼓勵的方法。嘗試做簡單深呼吸或暫時停止自己的腳步，給自己時間再想想。

3.切記！每個人都有被人拒絕的時候。接納自己，拂去心中的塵埃，繼續向前進。有些事也許該多花點時間和努力，但不要因此對自己感到灰心。成功的人是一次又一次地被拒絕，但從未停止過努力。 正如古人所言：失敗為成功之母。

4.當我們的請求被人拒絕或事情沒有按照我們的方式進行時，試著換另一種新的解決方案。通常拒絕我們提案的人並不是說我們不好，否定我們整個人。也許只是想要聆聽另外一個解決方案。成功的人會從拒絕中走出來，從另一個角度看事情和問題的解決方式，重新提案。

5.對於離題的討論不要猶豫去打斷對話。如果正在討論一項主題，討論方向已經不太對了，停下來，重新開始討論主題。

6.別太專注自己的情況。如果只注意自己，可能只會看到自己的缺點。多想想自己的目標，該採取哪些步驟以便能讓自己達到目標。

7.停止有害自我的對話。事情發生時，不要說些自我喪氣的話。自己是自己最大的敵人，因為我們最瞭解自己，但也不要因此成為自己的敵人，自己打敗自己。

8.不要擔心自己給別人的印象是愚笨的。如果有人問問題，我們不知道答案是什麼，你可以說： 我需要想想，想到以後，再回答這個問題。不用覺得難堪或自己很笨。

9.要學習耐心。突發狀況發生時，在沒有給自己時間冷靜思考前，不要貿然行動或反應。衝動時做的事情，有時要花更多的力氣收拾，有時候甚至是無法挽回的失誤。所以，凡事應三思而後行。

10.不要立即責備他人。想一想，每個人都有他生活上的高潮和低谷。給別人一點空間，也許更能化解衝突，事情會更容易進行。

11.考慮他人，先他後我。以這種服務他人的信念與人互動。問一問自己，我們可以做些什麼令他人覺得愉快舒服的事嗎？ 如果事事都能考慮他人的感受，人際關係就會更和諧。自己也不會只專注在自我，而能更加有自信。

熟悉多種程式語言，有助生產力

影響程式設計生產力的因子 第1回研究指出，最好和最糟的程式人，生產力的差距高達28倍。因此，有高速開發能力的程式人十分吃香


當我們想要評估一個程式人的能力高下時，會有許多參考指標，而其中一個重要的指標，就是撰寫程式的速度。對軟體開發而言，生產力是十分重要的，因為時間就是金錢，甚至有研究指出，最好的和最糟的程式人，生產力的差距可以高達28倍之多。


倘若一個團隊裡恰好雇用到一名最糟的程式人，那麼最好的程式人原先只需花費一週完成的工作，他很有可能要花上28週，相當於半年多的時間，這差距可說是相當驚人。因此，有著高速開發能力的程式人當然是十分地吃香。


打字速度直接影響開發效率

那麼，你，做為一名程式人，究竟是屬於高生產力，或者是低生產力的呢？在本文中，我將試著探討影響程式設計生產力的諸般因素。


撰寫程式碼的速度，無疑會影響到程式設計的生產力。而影響撰寫程式碼速度的第一個要素，很少人討論，但就我個人的觀點，覺得其實還挺重要的，那就是打字的速度。


我有個很有趣的經驗，當年我小學畢業初學程式設計時，雖然還是個連26個字母都識不完整的小朋友，但老師第一堂課，就教我們如何熟悉自己的鍵盤，如何不看著鍵盤，快速地讓雙指在鍵盤上遊走，輸入所有想輸入的字元。


打字速度，雖然看起來是一個在程式設計領域，很少有人談論到的因素，但無疑的，卻最直接影響到產出程式碼的速度。無論一名程式人思考的速度有多快，最終還是得透過鍵盤，才能讓程式碼從人腦傳遞到電腦。


如果你有留意，我們在撰寫程式時，有時候速度的瓶頸是在思考，有時候速度的瓶頸是在打字。我的觀察，許多生產力表現優秀的程式人，他們對吃飯的傢伙──鍵盤，都是相當的熟悉，一旦寫起程式來，雙手快速地在鍵盤上飛舞，程式碼就一行行在畫面上出現。


這並不是說，所有生產力高的程式人，都一定得練就一番快速打字的功夫，但是，打字速度快，絕對有助於更快速地產出程式碼。尤其當你思考的速度，勝過打字的速度時，腦中浮現一堆程式碼，但卻受限於手指移動的能力，難道不會感到無奈嗎？


此外，這也不是在暗示只要你打字夠快，寫程式就會夠快（因為你可能思考不夠快），有太多因素在支配著程式碼生產力了。即使你能高速的產生程式碼，也不代表這些程式碼都是有品質、可供使用的程式碼呀！


好的整合開發環境，可強化生產力

除了打字之外，為了要更有效加速直接產出程式碼的速度，大多數的整合開發環境（IDE）都提供了一些輔助的機制，協助程式人更快速地產出程式碼。例如，程 式碼的自動補齊（Auto-Completion），會自動偵測目前你可能要輸入的類別名稱或函式名稱，自動猜想並且可以幫你補齊，如此一來，便可以減少 很多需要打字的時間。


好的整合開發環境不僅會提供這類產生程式碼的協助，同時也提供了許多在撰寫程式碼時，所會需要運用到的機制，像是跳至某類別、某函式在程式碼中定義的位置之類，都能加快程式人撰寫程式碼的速度。


因此，是否選擇了一個好的整合開發環境、是否熟悉所選用的整合開發環境，自然成了重要的因素。有一些開發速度驚人的程式人，對於自己所用的開發環境十分熟悉，他們搞懂整合開發環境所能提供的每一項有助於加快產生程式碼的協助，並且快速地運用它們。


這些熟悉整合開發環境的程式人，早就把各種快速鍵運用得有如自己的手足一般，完全不需要思考或反應。能將整合開發環境所提供的機制發揮到淋漓盡致，自然能夠有更好的生產力。


熟悉多種程式語言，便可針對情境挑選生產力最佳者

倘若，不限單一程式語言的話，那麼，從中挑選出有生產力的程式語言以及搭配的應用程式框架，也會是決定生產力的重要關鍵。


例如，這幾年來被公認在網站開發上，具有高速開發生產力的RoR（Ruby on Rails），它的設計相當符合開發網站的需求，因此能夠提高程式開發的速度。


想要開發得更快，使用更有生產力的程式語言，以及搭配的應用程式框架，也會是一個決定因素。好比，你的需求是在Windows平臺上開發一個視窗應用程 式，你的選項有C/C++搭配MFC及C#兩種。雖然說熟悉MFC的程式人，一樣有著很好的生產力，但我想，一般來說，利用C#開發使用者介面的生產力， 應該還是會勝過MFC，因為不論是語言本身，或者是程式庫，新生代的C#以及.NET平臺，終究還是針對生產力提供不錯的改善。


有時候，同時熟悉多種程式語言，有助於提昇生產力，便是因為當要解的問題不同時，你手上可以運用的語言工具比較多，便有機會從中挑選出最適合、最有生產力的程式語言。


倘若你熟悉的語言受限，那麼選擇不多的情況下，想要憑藉著程式語言來加分，機會就比較低了。所以，在程式設計這個圈子裡，普遍認為優秀的程式人最好是兼通多種程式語言。


這並不是說，專精一兩種程式語言不足以成為高手，而是說，當可用的工具變多時，可以針對不同的應用情境從多種語言中挑選最適合的。當生產力對你來說是重要的因素時，便可以挑選開發生產力較好的語言。


程式框架好比巨人的肩膀，可節省開發時間

好的應用程式框架或程式庫對於生產力加分不少，因為好的應用程式框架，通常瞄準特定的應用領域，例如使用者操作介面、網頁處理、資料庫資料處理，抽取出該領域在開發時的共通需求，成為可滿足這些需求的設計。


立足在這些框架或程式庫上，好比站在巨人的肩膀上，可以省去許多時間。


因為在該應用領域中，會不斷運用到的重複部分，都被應用程式框架或程式庫給做掉了。而且它們在設計時，幾乎都會考慮到通用性，因此可以滿足大多數開發的需求。


簡單的需求搭配複雜的程式框架，反而拉長開發時間

但是應用程式框架或程式庫，雖然設計的目的，是為了要節省開發的時間，但是，近來觀察，許多應用程式框架有越來越複雜化的趨勢，原因當然是為了希望涵蓋更多的應用需求，但是，這麼一來，不但提高了學習曲線，複雜化的結果，往往讓程式人無法從中得到提高生產力的好處。


反而因為所面對的事物變複雜了，需要花更多的心力，去操控應用程式框架，也更容易迷惑、更容易犯錯，開發時間有時候反而拉長了，完全沒有得到運用應用程式框架應該要有的優點。


這其實是一個滿重要的迷思。許多程式人其實沒有搞懂自己真正的需求，只跟隨著潮流走，當大家一窩瘋地使用某個應用程式框架時，好像不用就趕不上流行，就不是正宗的王道。


倘若你的需求單純，應該挑選複雜度適宜的應用程式框架，而不是一味地追求最完整、威力最強大的框架。這麼一來，才真的不會因為應用程式框架本身的複雜度，使得生產力的提升打了折扣。

不夠用的時間，不夠用的人

幹部來跟我討論，說他的時間不夠用，他的人也不夠用。我則認為時間夠用，是他不會用。人也夠用，是他沒找對人用。

我想到帕金森定律。

1958年，英國歷史學家、政治學家西里爾.諾斯古德.帕金森（Cyril Northcote Parkinson），出版了《帕金森定律》(Parkinson's Law)一書。
根據他研究發現，一個人可以用的時間越多，他做事情的速度會越慢。
一 個人同樣做一件事，所用的時間差別很大。例如每天早上看報紙，可以十分鐘看完，也可以看半天。一個很忙的人二十分鐘內可以寄出一疊明信片，但是一個時間很 多的老太婆，他可以花一天才寄出一張明信片：找明信片一個鐘頭，尋眼鏡一個鐘頭，查地址半個鐘頭，寫問候的話一個鐘頭零一刻鐘...
帕金森認為在工作中，工作會自動地膨脹，占滿一個人所有可用的時間，如果時間充裕，他就會放慢工作節奏或是增添其他項目以便用掉所有的時間。
組織內每個人都會覺得自己很忙，忙到做不完。做不完就要再找人做，組織就會膨脹，組織人員不斷膨脹，人員越來越忙，可是組織效率越來越低。

人員能力不好，也會造成組織膨脹。
人員要做一件事，做不好，他有三條路可以選擇：
第一、自己辭職，讓有能力的人來做，不要占著茅坑不拉屎。
第二、找一個能幹的人來協助自己。
第三、找二個比自己差的人來當助手。
一般人會戀棧，不會選第一。也不會選第二，因為他怕有能力者替代他。可是選了第三，一件事本來自己應該要做好，做不好，竟最後是三個人才能做。而平庸的下屬可能又會找更爛的二個助手來做...，以此類推，組織越來越龐大，效率越來越低。

當然，帕金森定律之所以能引起共鳴，就是因為他觀察到組織的通病。要克服這些通病並不容易。我認為，要從管理者自省開始。

首先，管理者要善加利用與規劃自己的時間。
時間其實是最寶貴資源，每一件事開始做之前就要先想需要多久時間，規畫時間內一定要完成，無論遇到再大的困境也要在時間內完成。不是依自己總時間資源，是依每件事情的計畫時間，要求準時完成。
時間內完成，即使不夠完美，也比雖然完美卻錯失完成時機來的好。更何況，根據帕金森定律，再多的時間也嫌不夠啊，所以，準時的效率比完美的效果重要。

其次，超越自己能力能做的事，要善加利用比自己強的人來做。
時 代改變，當今領導已經不適合型塑強人來領導，而是組成TEAM，發揮組織綜效戰力。所以領導者不用萬能，當然也不怕執行任務時被有能力的助手幹掉。通常， 組織的成敗榮辱都是主管來享受或承擔，因此，無所不用其極讓組織成功，當然包括任用賢才或退位，組織成功，組織上、歷史上你就都有位置。

第三、情願高薪用少量能力好的人，也不要聘請很多低薪無用人力，靠人海戰術完成工作。
如果A的薪資是B+C的總和，但是A的產能也是B+C的總和，你會用A還是用同樣薪資來聘請B跟C呢？
很多人會選B+C，這除了會陷落在帕金森定律內，以單店的損益分析來看也不划算。表面上好像A的薪資等於B+C的薪資，花費都一樣，人多好辦事，其實不然，因為薪資科目花費一樣，可是其他科目費用會增加。
例如聘請一個人給一套制服就可以了，聘請二個人得給二套制服，雜費科目會多出費用來。其他像教育訓練費、伙食費、三節禮品....等等費用都會增加
所以，人力應該採精兵制，甚至有些專業的部分也可以外包給其他團隊來做。

組織越精越小而美，效率越高。

果子創新的幹部都應該往整合型領導努力。

揭秘IT人才特點：中美印日四國程序員比較

      最近以裁判的身份參加了公司舉辦的編程大賽，發現高手雲集，對公司內部的程序員能力也有了更深入的了解。我覺得編程能力對程序員而言，雖然很重要，但並不是全部。那麼作為一個程序員，到底應該具備什麼樣的能力呢？這個話題顯然太大。不過我覺得可以看看其它國家的程序員，也許可以得到一些借鑒。我有幸和中國，美國，印度和日本四國程序員有比較深入的合作過。雖然他們不一定有代表性，但我覺得他們的共性還是比較明顯的。以下的比較純屬個人見解，歡迎指正。

      首先是日本程序員。他們的特點是非常仔細。我認為很主要的一個原因是日本公司的需求非常細緻。細緻到在網頁上，連一個像素都不能偏差的地步。另外，日本人的執行力非常強，對老闆的承諾比命還重要。一個項目可以做到連續3個月天天加班，每天只睡4個小時。然而，高執行力背後的代價是低創造力。在日新月異的互聯網今天，很少聽說日本工程師發明了哪些重要的技術。與其說這些特點是日本程序員的，不如說是大部分日本人的。因為在日本文化中，追求品質和遵守等級制度是根深蒂固的。另外，技術領域中的很多專業詞彙是外來語，以英語(論壇)為主。這些專業詞彙往往會被翻譯成片假名。而片假名的發言有時候和英語大相徑庭，導致溝通的困難。比如病毒一詞在英語中是Virus，發音為歪儒斯，而日語的發音是味魯斯。再例如服務器（Server）一詞在日語中的發音是薩巴，和英文發言簡直風牛馬不相及。因此與日本程序員溝通是比較痛苦的，除非你懂日語。

     其次來看看印度程序員。我所接觸的印度工程師都是在美國工作的。雖然他們和印度本地的工程師肯定有區別，不過相似的地方應該更多一些吧。我覺得他們的普遍優點就一個：流程做得好，文檔寫得好。但是他們寫代碼的能力，我個人的觀點是一般般。我想這裡面有兩層原因。一是有相當一部分在美國工作的印度程序員是半路出家。轉行做程序員是為了生存而已。二是印度程序員在算法，數據機構等基本功方面的水平明顯低於中國程序員的。這就導致他們寫的很多代碼邏輯性不強和性能不優（以我的標準來看）。不過這兩個問題在一定程度上被大量的文檔和高性能的硬件設備彌補和掩蓋了。在溝通方面，印度人的英語發音對西方人而言幾乎沒有問題，但很難被中國人聽懂，甚至往往被國人懷疑他們是不是在說英文。

      從某種意義上講，日本程序員和印度程序員十分相似。他們都很敬業，都能讓領導比較滿意，但不要過多地期望他們能做得更好，因為他們的目標就是完成領導指派的任務。日本程序員讓領導滿意的方法是不折不扣的執行和狂熱的加班。而印度程序員讓領導滿意的方法是通過大量的文檔來告訴領導他們的工作意義重大，流程嚴謹，資料齊全，而且成本很低。誇張一點地講：日本程序員善於做領導想做的事，印度程序員善於說領導想听的話。

      接下來說說美國程序員。美國程序員千奇百怪，好像很難只用幾個詞來定義他們。可能是因為美國是一個移民國家吧，本來就千奇百怪。但大部分程序員有一個共同的特點：喜歡技術，甚至崇尚技術。這點在矽谷尤為突出。這就導致每個技術領域中都有一些人會廢寢忘食地鑽研。其實這和打遊戲一樣，如果你著了迷，自然會忘了吃，忘了喝，拼命地玩。我所認識的美國程序員還有一個特點，才藝能力都不錯。以前在波士頓工作的一家公司中，幾十位工程師居然可以組成一個交響樂團。有小提琴，大提琴，小號，豎琴，打擊樂等各種各樣的西洋樂器手。而且這些哥們姐們還不是一般地玩玩，週末都有自己的固定樂隊，經常參加社區的表演。更有甚者，在矽谷工作時的一位同事，白天寫程序，晚上在自家的車庫裡練習乒乓球，竟然代表美國參加了悉尼和雅典的兩屆奧運會。說起寫文檔的能力，美國程序員絕對不亞於印度人。但是美國人寫文檔不是為了老闆，而是為了自己，為了分享。因此他們的文檔往往讀起來很有趣，很實用。當然，這會讓老闆有時候很頭疼，因為程序員不那麼“聽話”。他們不是給老闆交差，而是要實現自己的想法，自己的設計，自己的完美。說白了，就是美國程序員有時候想法多了點。

      最後是我們中國的程序員。和其他國家的程序員相比，我覺得他們的特點還是比較明顯的。他們的算法能力普遍高於其它幾個國家的。這可能是我們的教育體制導致的，比較注重理論知識。反過來，實踐能力就相對差些。我們的程序員執行能力並不差，但在解決問題的能力上明顯不足。往往需要把任務分解得很細以後才能完成，獨立解決問題的能力不夠。另外在表達能力上也相對差些。相信大家一定見過技術水平很高，但表達能力很差的工程師。最好笑的是，我見過不少工程師拿著一支寫不出字的白板筆（我們的白板筆質量也確實不咋樣），有模有樣地在白板上寫字。彷彿聽眾可以看得到他/她寫得是什麼。因為他/她完全沉浸在自己的邏輯中，完全不去體會聽眾的感受。不過我認為這些缺點並不嚴重。

      因為這些是屬於技能和經驗方面的東西，是可以通過實際工作或者培訓來提升的。我認為國內程序員最大的問題還是所處的環境不利，導致相當一部分人比較浮躁和急功近利。真正能夠沉下心來鑽研技術，熱愛技術的是鳳毛麟角。我在面試的時候，常常發現工程師知識面還挺廣，但深度幾乎沒有。這樣的人很難在技術領域有所作為。我希望找到的人是，敢於承認自己不會的地方，但是只要會的東西，哪怕就一樣，就要一定比別人理解得透，鑽研得深。我相信一個人如果在某一個問題上比別人做得好，在其它問題上也一定有能力超越別人。

      雖然比較下來，看到中國程序員不少的問題。但作為群體，中國的程序員可能是全世界最聰明的工程師群體。因為環境的原因，使得他們不得不想法很多，顧慮很多，無法最大程度地將聰明才智發揮在技術上。改變這種狀況首先要從公司的管理層開始。只有技術負責人熱愛技術，追求卓越，才可能為技術人員創造環境，激勵他們鑽研和創新。技術負責人需要深入項目，和工程師們一起討論技術設計，從而通過具體問題來提升工程師的能力，同時也防止自己的技術能力滑坡。在技術管理上，很多國內的公司把工程師簡單地作為資源，過於強調流程管理和資源管理。我的觀點是：工程師不是高級藍領，不能以管理生產線的方式來進行管理。優良的環境只有靠大家一起來創造。中國工程師一定可以成為世界上最優秀的工程師群體。

25個創業者失敗案例的啟示：創業大敗局

Y-Combinator創始人、著名天使投資人Paul Graham投資了80多家創業公司、堪稱互聯網創業領域的教父級人物，經常被人問到“哪些錯誤會導致創業失敗”。 Paul Graham嘗試開出了一張“創業失敗的18個錯誤”的不完全清單，希望幫助創業者察覺到自己正在做不應該做的事情。最近，一篇文章《25則“驗屍報告”—創業失敗者啟示錄》（http://news.csdn.net/a/20101018 /280604.html）也受到關注，作者的出發點與Paul Graham類似，雖然成功不可以復制，失敗卻可以盡量避免。
有趣的是，文章中提到的創業者們並不同意這個看法。 YouCastr創始人說他讀過Paul Graham的幾乎每一篇文章，但不親身經歷一遍是很難體會其中的道理。他創業失敗後在的經驗總結中寫道，希望自己的特定經歷與個人體驗能成為Paul Graham創業文章的一個註腳、一個背景詮釋。 IonLab創始人則更是誇張，建議創業者們停止閱讀一切創業指導文章或圖書，因為每一個小時的閱讀，至少需要創業者此前有三個小時以上的實際經驗才能理解其中內容，又至少再需要三個小時的實踐運用才能吸收。即使這樣，也很難把這些經驗教訓“內化（internalize）”。 IonLab創始人說，他讀Paul Graham文章時一直想，這些不會發生在自己身上，輪到自己創業一定能做得更好。當他創業失敗，重讀Paul Graham時，卻發現說的就是自己，驚出一身冷汗。
從某種意義上說，導致創業失敗的本質錯誤只有一個——沒人需要你做的東西。如果你在做的東西是用戶需要的，那麼你至少能夠生存下去，其它的問題都可以逐一解決。但如果不符合用戶需求，那就死定了。
25則創業者失敗教訓總結，幾乎都有一個共同點：個人有創業衝動，正好想到了一個自以為絕妙的點子，或看到了一個自認為很大的機會，就不管不顧地投入進去，而沒有進行客戶需求的確認。
eHarmony for jobs創始人想到了一個自動匹配求職者與用人企業的點子，僅僅諮詢了身邊朋友，得到認可後就迫不及待地投入創業。在這個過程中才認識到，“他們（指自己的朋友）只代表了不需要付費的求職者，而最重要的需要付費的企業客戶卻沒有去調研”。甚至在深入HR行業一段時間後，才知道這是一個過去幾年被無數人想到、嘗試並驗證失敗的模式。
BricaBox創始人最終認識到自己要解決的只是一個“技術問題”，而不是“商業問題”。技術人員創業，“自撓其背而止癢”當然沒錯，但最好是有“一個更具通用性的可推而廣之的解決方案”。他總結道，解決技術問題，更應該是發起一個開源項目，而不是創辦一家公司。
Xmarks代表著典型的技術人員創業。 Mozilla基金會主席，自己卻用Safari並非Firefox，因為需要在5台不同電腦上工作，而當時Firefox沒有書籤同步功能，就開發了Xmarks。他們當時的想法是，用戶收藏網頁相當於一次投票，可以做出一個更好、更智能的搜索引擎。請了可用性專家和用戶測試，才發現“人們搜索是想找到特定問題的答案，而不是得到某個主題領域內的一組權威鏈接”，並“驚訝”地發現“做搜索測試時，人們在電腦前坐下來第一件事就是搜索自己的姓名”。
YouCastr創始人的總結更是沉痛，“我們並不愛自己做的事。我們做這個只是因為我們想創業，想到了這個點子覺得不錯。我們不是我們產品的核心用戶。雖然我們很努力工作，但我們無法理解什麼是最佳的產品決策。”“創業基本前提從一開始就錯了，我們既沒有調查視頻內容提供方，也不了解觀眾。”而認識到這點，創業團隊用了三年時間，其中整整兩年，5個創始人都沒有領工資。
最近流行的“Lean Startup（精益創業）”，其精髓是“Customer Validation（客戶需求確認）”，即用最低成本、儘早獲取客戶需求的確認。推薦的方法都很有意思，如做一個假的網頁，投放Adwords關鍵詞廣告，通過點擊數據分析來判斷用戶是否真的需要你準備投入創業的這個產品；又如可以先不做產品，製作一段演示視頻，扔到網上傳播看用戶如何反饋。
創業大敗局給我們的啟示，借用Paul Graham的話，那就是“理解你的用戶”。
作者簡介：高巍，安卓愛普公司創始人。原搜狐媒體產品中心經理。關注移動互聯網、互聯網產品管理。
（本文來自《程序員》雜誌10年11期）