我是 2007 年初加入 Facebook，那時大概 150 人。2011 年 9 月底離開，當時 3200 多人。經歷了很多稀奇古怪但影響很大的項目， 像 Application Platform, Social Ads, News Feed, Gift Shop, Facebook Credits 等等。碰到的很多的問題都是全新的，規模是互聯網歷史上最大的。當時的心驚肉跳現在回想起來是很讓人懷念的舊時光。到我離開 Facebook 的時候，我負責支付安全和工具研發部門，還有部分的支付后臺研發組。

　　現在我在全職做天使投資，給看對眼的團隊在早期產品技術團隊搭建給予一些力所能及的幫助。有興趣的朋友可以關注我的微博@王淮 Harry 哥。

　　在 Facebook 的這些年讓我學習感悟了很多東西，很多東西溶在血液中，現在我換了時間來思考最值得分享的 10 點經驗和大家分享。希望能給創業的朋友一些啟發。

　　在我們開始之前，先來一段免責聲明“

　　1. 這里所有的東西都是從我自己的親身體會和實踐中獲得的。不一定都是新的，但都是真實的。

　　2. 所有的這些在 Facebook 的文化下能有效，但不代表對你的公司一定有效。好的種子還要有合適的土壤。

　　3. 不是所有的點都對你有用，但只要有一點對你有用，我就開心了。

　　OK. 我們開始吧。

　　1、堅持你的遠見， 但靈活的把握細節

　　作為領導者，在遠見上你只有依靠自己，至少在你自己負責的業務范圍之內。你是老板，意味著整個公司；你是經理，意味著整個部門。為你賣命的兄弟姐妹們是依靠你來給他們提供遠見。什么是遠見? 就是對最終狀態的一種描述。是讓你的團隊在瘋狂的飛行之后最終著陸的地方。是辛辛苦苦忙忙碌碌之后的新生活。它是北極星，它來指明方向。舉一個例子，當我一開始建立支付安全部門的時候，我們只有人工規則引擎。規則是人寫的。一條人工規則是有少數變量的簡單邏輯，比如“如果(注冊在 30 天之內和支出大于 100 美元和是首次支付和用戶來自印度尼西亞)，那么 (拒絕交易)” 但這里有個問題 —— 人寫的東西容易出錯. 人很難有效的處理 10 個以上的變量。我們需要一個更有可擴張性(Scalable)的解決方案. 我們希望把很多事情自動化，讓機器人做更多機器擅長的事情。因此我們建立了一個共識 —— 將我們絕大部分的規則逐步替換為機器學習獲得的判斷模型。這一遠見讓我們組新加了一位機器學習領域的博士和另一位之前有過機器學習體系開發經驗的工程師。賭注巨大，但是一個更好的未來需要下這個注。

　　但你需要對細節靈活把握，永遠都有條條大路通羅馬. 你需要給團隊足夠的空間來施展拳腳，只要他們在朝著正確的方向以合適的速度前進。另一個故事：在 classification 算法上一度我對決策樹的興趣比回歸要大。但玩算法的工程師告訴它們之間的差別可以忽略。我可以堅持己見（當時我是真心覺得決策樹要更合適），但我信任他并讓他放手去選合適的算法。同設計師(Facebook 的整個研發有設計師、產品經理、工程師三類物種) 合作的過程中也有趣事發生，他們對于字體、顏色、行距等等都很龜毛。我通常都會忍讓， 只要服務于產品的主要功能。我們精力有限， 吵架要選擇正確的戰爭，關乎全局的戰爭，而不是糾纏于某個局部戰斗。

　　2 、只和最好的人合作

　　一流的牛人只愿意和牛人廝守。他們聚在一起會更牛逼。一流人才無法容忍二流的人。那什么是“最好的人”？我的理解是能夠盡其所知，用其所長，學其所不能， 從而迅速完成目標并遠超期望。他們的本能是挑戰自己， 超越別人的期望，超越自己的期望。對他們來說，僅僅足夠好是不夠好。

　　只有一流人才組成的團隊有很多好處。

　　(1) 這讓你更加愿意委托。從我的經驗來看，牛人不會輕易信任不熟悉的人。如果你還沒有證明自己和他們一樣出色甚至更出色，他們寧愿自己獨立工作勞累死也不愿接受你的幫助。因為他們擔心你會搞砸。但當你證明自己之后，他們會信任你，放心的把事情交給你一起合作。一個互幫互助的牛逼團隊才能做到1+1遠大于2.

　　(2) 通過艱巨任務的完成，牛人們互設榜樣。你會想“牛，這哥們竟然能把這玩意做出來了，咱得加油了”。這種 peer pressure 合理的利用可以大幅度的提高工作表現并在團隊中形成良性循環。

　　(3) 牛人們喜歡互相挑戰。我記得一位工程師總監立下賭約 —— 如果我們在規定時限之前完成網站翻譯平臺所需的代碼修改，他將把頭發染成藍色。這樣的挑戰把“枯燥”的工作變成了挑戰性游戲。在玩游戲中寫程序比純粹的寫程序要有趣得多。當然我們也有很多更加認真的挑戰。因為牛人們天生(賤命，哈)容易對挑戰上癮， 不管是挑戰別人還是接受挑戰。

　　(4) 牛人們相互學到很多. 每個牛人都有自己牛的地方，彼此有很多的互補。如果 Facebook 不是有很多東西可以學習的話，我不會呆 4 年多。對缺乏經驗的人來說，這點很給力。我們雇傭非常聰明的畢業生(潛在牛人)，這些人希望引爆自己來證明他們的牛逼之處。他們不愿到一個舒適無挑戰的公司過日復一日的生活。他們想學很多來豐富他們的經驗，完成不可能完成的任務并在他們的職業生涯上前進。他們想要證明“yes, we can”。和其他牛人一起才能更容易的實現這些。

　　你不想要二流的人，但如何遠離他們？首先，慢點招人 (Hire Slow)。在招人的標準上固執一點。訓練你的面試人員讓他們明白他們需要招(某些方面)比他們更強至少不會拖后腿的人，如果不是，拒絕平庸，不要屈就。我曾好幾次在招聘決策會議上發現黃金履歷者無法拿到 Offer, 只因為某個面試官覺得這人無法給他深刻印象沒有讓他驚訝。但在另外一些例子當中，那些獲得一致通過的候選人仍被放棄因為大家都只是覺得他僅僅符合要求而已， 沒有出彩的地方。在招人問題上，絕大多數情形下，你要小心不要冒進。（順便提一下我們也會雇用那些沒有全票通過的候選人，只要有一兩票是強烈推薦 —— 因為對于已有員工的強烈推薦你是不應輕易忽視的，這時可以冒險）其次，炒魷魚要快 (Fire Fast).。使用二流人才就像服用慢性毒藥，一天一點， 遲早咯屁。Facebook 要求所有的管人經理對于員工的表現要特別敏感。經理發現員工分配的任務或者答應的事情經常沒有做到，如果是客觀原因，一定要盡力幫助解決；如果判斷為人才質量問題，走法律允許的程序迅速將人炒掉。我見過幾次炒的比較慢，那對團隊造成的負面作用可不是鬧著玩的。

　　3、樹立高的期望值并加以衡量

　　作為領導者，你需要設定足夠高但仍合理的期望. 足夠高使得你的團隊不會感到無聊。仍合理使得他們不至于油盡燈枯。你要給他們創造一段經歷，使得在旅程結束時，他們回過頭來看會說 —— "他妹的， 我都沒想到我居然做到了這個，這個屌爆了。" 在 Facebook, 和其他硅谷高技術公司一樣，期望同薪酬相結合。每半年 Facebook 都有5-6個公司級的大目標，所有人的獎金算法中都會考慮該目標的完成情況。因此樹立明確的期望本身就至關重要。

　　另外， 你需要找到一個不容爭辯的途徑來衡量期望。我花了大量時間和團隊一起制定下季度里最重要的3-5個目標并有數據化的衡量指標(一個目標背后可以有多個指標)。根據工作量把目標分別委派給單個或多個攻城獅，或者讓他們自己攬。在這一情況下，我們不僅有可衡量的目標，使得我們可以迅速地說出來我們在做什么做到哪了，同時也知道每個具體目標后面的負責人是誰。團隊的表現和個體表現掛鉤，所以他們失敗了我即不成功。例如， 當年我們團隊最大的成果就是在一年時間里，通過每季度不同的指標，讓信用卡支付的投訴率降低了75%.

　　有一點要強調的是 —— 期望還是要基于現實要合理。在你只有 10% 的市場份額的時候卻幻想 10 幾倍的收入增長無疑不現實。Steve Jobs 喬老爺是這方面的老手，非常善于推動他的團隊超越潛能但同時也榨干他們（雖然他們后來還是為他們所做到的而自豪一輩子）99.9% 的領導者不是喬老爺，也不需要是。更可行的是在團隊的真實極限中找到一個可持續性的驅動來激勵團隊超越自我。

　　4、重視數據而不盲從數據

　　決定產品方向時， 要的是想象力， 激情和膽量， 而不是數據。數據能讓你的團隊沿著正確的方向前進而不出軌，也有助于產品從“一開始是什么樣”到“最后應該是什么樣”的逐漸優化成型。但數據不能幫你決定方向。舉個例子，當我們在人工智能(機器學習)上壓上我們團隊所有的資源的時候，我們忐忑不安。但是我們堅信一點，現有的基于人工規則引擎的防欺詐系統會很快成為死胡同，因為它太死板而且不易規模化以處理大數據。所以，就像在電影指環王中 Frodo 明知通向 Mordor 的道路很黑很冷很危險，但那是一條他必須要選擇去走的路；我們選擇了在機器學習上壓上所有的寶。失敗，整個團隊會很難看；但我們決定走艱難但我們認為是正確的路。這種思路同樣應用在如何設計用于用戶報告(外部工具)和案例審查(內部工具)的工具來應對潛在的欺騙行為。我們最后決定的方向是“進行自動處理”和“建立反饋機制”。直接拋給人工來處理總是很容易被選的一條路， 因為只要建立一個人多人傻的客戶支持團隊即可。Lame! 我們希望通過自動處理來解決大部分的欺詐案例，而把精力則放在那些確實需要單獨處理的特殊案例上，同時把從業務支持團隊(即客戶支持部門)的處理意見自動采集并集成到下一輪的機器學習中去。由此，我們的機器判斷會越加精確和聰明且與時俱進.

　　但你不能忽視數據。沒有數據的支撐而一味靠直覺走黑路， 很容易走岔道， 甚至大錯特錯。有一段時間我們認為爬行工具(通過分析關聯的cookie, 信用卡)可能可以找到很多欺詐的同伙。通過實驗結果卻發現， 這種預期是否成立很大程度上取決于當前流行的欺詐行為的特點。比如，當失竊或販賣信用卡的案例非常普遍的時候，關聯分析是一種有效的方法。但如果主要情況是帳戶被黑或小寶們冒用媽媽的信用卡去網游消費時，關聯分析就作用不大。直覺在現實前面碰了一臉的灰。不過幸運的是我們很快意識到這點且把這個項目叫停了， 所以沒有浪費太多的資源。

　　另外， 順帶提一下A/B測試。A/B測試并不會告訴你去做什么產品，但它可以幫你確定實現產品時的哪個細微版本更能揪住用戶大爺們的心。

　　5、避免無謂的時間浪費

　　剛進 Facebook 做工程師的時候，我非常享受那種日夜泡在碼海中的感覺。后來慢慢的承擔的項目責任越來越大越來越多，寫代碼的時間越來越少(但絕大多數時候仍占大頭)。有時候更多的是把時間花在決定產品的方向和設計上。很多事情是和產品經理設計人員一起搞的。但在 Facebook 攻城獅們有很大的發言權，甚至有些時候是拍板的權力。Facebook 希望攻城獅們有王者風范。Facebook 希望攻城獅能決定自己要做什么應該做什么，而不是總是"被決定"做什么(一種流行的說法是，write your own job description). 因此，我花了大量的時間在思考這些問題 —— 哪些功能需要添加，哪些功能需要刪掉，需要開始或停掉哪些測試，我們正在流血流汗的是不是現在最最最重要的問題，我們是該花時間優化用戶交互流程呢，還是減少出錯率， 還是讓系統更快，等等。這些問題很傷腦筋，答案經常不確定，比一個勁碼到手抽筋要難。但這些問題很重要， 甚至可能決定了你熬的日日夜夜究竟有沒有必要。建議所有的攻城獅思考思考代碼之外的這些問題，團隊領導者就更有必要了。當然，攻城獅的大多數時間還是應該花在代碼上。

　　那究竟哪些時間不應該被浪費呢？

　　很多，但我只舉兩個我認為最重要的例子。

　　郵件。不是所有郵件都發而平等。有些郵件純粹打醬油的，有些郵件是不需要馬上處理的。我嘗試使用過濾規則來踢掉打醬油的郵件，突出需要馬上處理的重要郵件。對此，分享兩點。

　　1) 建立一個適合你的郵件過濾系統。我會對重要和緊急的郵件做即刻回復，而暫緩處理那些可以等到晚上再回復的郵件（尤其是發自我自己的團隊，產品經理，兄弟連和頂頭的不頂頭的上司們的郵件）。但是，我要確保在我掙扎的爬到床上之前，把這些郵件全部處理掉， 讀的讀， 回的回。對于那些僅供參考的郵件，過濾系統會將其塞到某個固定的角落，我隔三差五去瞅瞅。此類郵件諸如某酒鬼詢問 Napa Valley 哪個酒窖比較正點等等. 這些郵件通常比較有趣， 挖的坑很大很深所以也很耗時間， 我通常不跳或者不馬上跳。

　　2) 廣而告之你的個人郵件處理策略。我讓我身邊的戰友們知道我是如何處理郵件的， 并把這個政策放到我所有的郵件末端。如是說 —— “正在嘗試個人郵件處理策略 —— 為了戒掉 Email 癮， 我將強迫自己每隔三小時或以上查看一次 Email，急事請電話/短信/IM 我”，這么做更多的是讓別人明白不要指望馬上得到回應。其實我查 email 比每 3 小時要頻繁，但至少不用馬上逼得去回每個 email 了，我可以憋著悠著點。因為如果真的很急，我的 iPhone 應該已經響過了。而且，批量處理真的效率要高很多。不騙你。

　　會議。開會太容易變成一群人互相在扯對方的蛋。浪費時間而且開完后發現沒有結論且很蛋疼。但開會對于 teamwork 很多時候是必要的。如何主持會議是門學問，這里不細談。不過，你不可能也不需要參加每個邀請你的會議。當你認為你參加某會議于己于人都無太多價值的時候，建議你考慮不去。如果想要有禮貌一點， 那就寫個 email 問問主持人你是否可以缺席。通常當你想過這個問題決定發這樣的郵件時，答案通常都會是 yes。有些時候我也會很可恥的讓我的產品經理替我去開會。當然，我會鼓勵他也爭取不要去。Only make the meetings you really have to. 同樣，我要求我自己的團隊在組織和參加會議的時候要慎重，也經常問他們想想看自己花在會議上的時間是不是多了。一個做法是把可能的會議都整合在一起。有一個例子。早些時候，我們會經常收到來自支持團隊的比較隨意的會面請求。這讓攻城獅的一天被會議分割得支離破碎。寫代碼的都知道沒有3-4個小時的連續時間是不容易高潮的。而且這種會議通常效率很低。于是，我們改變了做法，每周安排固定的答疑時間(office hour)和支持團隊嗑想法然后 follow up。當然， 緊急的問題另當別論應當馬上處理.

　　有一個被經常忽略的原則 —— 有意識地去思考哪些事情不應該做并且馬上不做。例如，哪些是無謂的爭論可以避免介入，哪些功能可以放棄，哪些關系不應該發展， 哪些人應該開掉，等等。我經常問自己一個很簡單的問題，我現在正在做的是否對我的目標很重要。如果你清楚自己正在做的和自己想要的，答案會明了。Go for it。

　　6、增進親密感是減少緊張關系的有效方式

　　工程師和支持團隊之間有著糾結的合作競爭關系(注意， 合作在前)。互聯網技術公司中很多人(尤其是聰明人)總是期望工程師對所有問題給出一個讓人會心一笑的解決方案。但現實是，不是每一個問題都可以或者應該在技術框架下解決。對于一些具體的問題， 客戶支持和運營部門會有一些非常深刻獨到的見解。工程師未必行，畢竟很多見解需要不同的專業知識， 依靠實地經驗。沒錯， 工程師可以在代碼中自動 log 大量的原始數據，但從原始數據中提煉可靠的判斷卻并不總能如愿。和很多其他公司的客戶或支持部門不同，我們的支持部門招募了質量相當好的員工(很多來自美國名校 —— 在我直接接觸的反欺詐支持組 20 來人中就有 3 名斯坦福校友)。因此，當兩群都很聰明的人觀點相左時，該聽誰的呢? 緊張關系再所難免。

　　不同的工程師團隊也存在著合作競爭關系。 反垃圾郵件、安全和反欺詐（我的團隊）這幾個團隊之間存在密切的工作協作關系。這些團隊也都盡可能地相互學習，分享經驗和技術。但是，有時候各團隊獨立處理類似但不同的一些問題時，都試圖向對方推銷自己的解決方案和理念。

　　如何讓合作競爭保持在一種健康有序的狀態? 我覺得關鍵是促進人與人之間的親密感。把人搞近了，事情就容易了。我花大量時間用在建立和其他團隊的關系上面。例如兩周一次或者一月一次和其他團隊老大們的 1 對 1 碰頭會。越相關的團隊，頭碰得越頻繁。我自己或者我的團隊成員會有選擇性的經常參加一些其他團隊的會議 (我們稱之為 Friends & Family meeting)。當為一個共同的大項目工作時，我曾安排不同的部門成員（工程師、支持、數據分析、金融財務）坐到一起進行項目沖刺。這是拉近相互之間距離的非常有效的一個做法， 尤其對于減少扯皮的機會。因為互相之間經常會請或被請喝咖啡 (可稱之為"咖啡外交")。我也會經常和一些人約定吃工作午餐， 經常聊的是家常， 增的是感情。有的時候一次長距離的散步也更能讓人暢所欲言。而這樣的緊密關系，在我們面對一個極具挑戰性的項目的關鍵時刻，會幫助大家緊緊的抱團闖關。

　　7、習慣委托， 但不要盲目， 請謹慎

　　分配任務委托別人的重要性比較容易理解。因為你不是超人，不能端茶倒水什么都做吃喝拉撒什么都管。有些時候，你往往還不是最適合的人選。當團隊一大，事情一多，你一定要學會委托別人來負責合適的任務。對有些領導者而言， 委托別人一個重要的目標可能不是很放心，覺都睡不好；但我非常習慣委托別人，有時候可能太習慣了。這是我一位前老板給我指出來的一個問題。有一次我給一位組員分配了一個既有技術難度又有協調挑戰的難題，進程比較緩慢。但我給了他太多的時間空間來折騰， 而事實上他在某些方面需要一些加強，有些方面需要我更多的主動的幫助。我老板指出來，如果我要讓別人隨便折騰的話，前提是我需要有足夠的信心。我需要有事實來逐漸證明我的決定是正確的。需要謹慎委托，因為如果項目失敗， 對他而言， 最終負責的人還是我，不是別人。所以我不能以別人不行來給失敗的委托埋單。

　　如果你有一個重要的任務需要委托給別人， 你要么：

　　1) 已經對此人非常了解，知道他戰斗力非凡可以搞定，或者相信他可以迅速學習提高打雞血搞定；

　　要么

　　2) 需要在一開始手把手教他，時不時問他，直到你對他有足夠的信心。

　　具體我是這么做的。項目開始時，我讓被委托人給我一個整體計劃以及幾天內可以完成的任務。一開始經常會面跟進，然后確定后幾天的任務。根據每次完成狀況來估計他能不能“高快狠”地完成最終的目標。信心逐漸建成后可以減少關于該項目的細節討論，此時的委托可以放得更開。但有一點要注意，如果跟的太緊的話， 可能讓人覺得你對他不放心，他也會做得畏首畏尾，這可能比盲目的委托還更差。所以在委托和謹慎之間， 有一個微妙平衡。

　　我覺得在這一點上我還要加強，這里也和大家提個醒。

　　8、意見反饋應該一個持續性的， 而不是一年一次或兩次的活動

　　一年一度或兩度的意見反饋在硅谷公司是非常常見的。它的目的不是設置起來給員工難堪，讓他們互相責難的。它的目的是希望員工對自己對他人有更全面的認識，以助進步。意見反饋有自我反饋和同事反饋兩部分。自我反饋是自己評定自己，完成了哪些目標，錯失了哪些目標，哪些方面做好了，哪些方面還待進步。但由于是自己踢球兼裁判，難免有偏頗。同事反饋，就像一枚鏡子，讓你看到 180 度之外的自己。在 Facebook, 360 度的正式意見反饋是一年兩次，并且和薪酬掛鉤。但近年來，意見反饋和薪酬評定逐漸分開。比如我做的一件事就是季度性的意見反饋，時間和正式評定錯開。在那幾天中，我請求所有相關組的同事在自愿的前提下給我寫寫關于我直屬組員的意見反饋，短短幾句都行。我會收集，綜合，最后在1-1碰頭會時反饋給我的組員。

　　如果需要等半年才來收集意見的話，很多相關故事早以忘得一干二凈。故事越久遠，記憶越模糊，意見越空洞， 說了等于沒說。而且，意見反饋和薪酬綁在一起，正常人(即使是牛人)都會很自然的把心眼更多的放到薪酬上，而不是意見本身。

　　除了季度性的輕型意見反饋， 日常的意見反饋如果有的話應當立馬傳遞，趁熱打鐵效果更好。

　　如何有效傳遞整理好的意見也很重要，有句話是說"it's not what you say that matters, it's how you say it". 我沒那么極端，我覺得如何傳遞意見也同樣重要。有兩種方式我都試過，不確定哪種更有效。這里都談一談。一種是以問為主逐漸深入促其思考，比如"how did you think about the meeting you hosted yesterday"; 另外一種是赤裸裸的直入主題， "hey, let's talk about the meeting you held yesterday"， 然后開始談我自己的感覺.不管哪種方式，一定要給對方一個解釋自己行為的機會；永遠假設并告訴他我相信他的意愿是好的。為了避免陷入“你昨天做了 xxx”，“"沒有， 我做的是 yyy”，“我覺你是做了 xxx”的死循環式的爭論，我首先爭取和他們在"我們感知的即是事實"這一點上達成共識。基于這點前提， 我們把討論的重點放在如何做能改變別人的感受，最后讓事情能順利完成， 畢竟大多數重要的事都有很多人一同協作完成。當他們認識到自己想要改進某個方面的時候，如何改是一個相對容易很多的問題 —— 聰明人一向能夠找出改進的辦法，我所做的就是配合他們做頭腦風暴。最終談話的目的是產生一個下次如何能做的更好的具體方案。

　　關于有效傳遞意見反饋， 另有 4 點提一下。

　　1) 意見反饋不見得都是負面的。它可以是別人的一個長處，你很欣賞，你希望他這方面堅持做，做得更多。比如一句"hey, I really love your weekly summary email with the key metrics at the top. Please keep them coming"，可能產生很好的激勵效果。

　　2) 意見反饋必須擺事實和講道理。如果你只是告訴別人他很爛，但不說什么時候爛過了以及為什么，除了給他添點火氣之外無他用。所以我在相關人員包括自己寫意見反饋的時候要求提供實例，比如一句 "I think he could make meetings transparent and shorter by having an agenda, like the weekly data review meeting on last Friday"比"his meeting is too long"，更有血有肉有效。

　　3) 意見反饋必須是可操作的。讓人無從下手的意見意義不大。如果在提意見的同時提出一個方案以供參考就有意義的多。但注意，絕不能是命令的方式 (那是中青寶…)，比如前面的例子"I think he could make meetings transparent and shorter by having an agenda sent ahead of time…"就很容易操作。

　　4) (個人偏好) 在最近的兩個評價周期中，我給 15 個左右的同事(一半不直屬我)寫過意見反饋。我把我寫的直接分享給他們。出于這種想法，在我下筆時就少了很多沖動。因為他們會讀，所以我無法做到背后捅刀。因為他們要讀，所以我需要寫得有意義，容易理解，并且加上很多例子。并且，我歡迎他們和我直接討論。如此一來，他們也明白我寫這些反饋的一片苦心是為了他們進步。

　　9、你可以比你想象的做得剛好

　　這不是說說而已。我自己就有一個親身的例子，我們曾經認為把一個高得離譜的欺詐率降到所允許的范圍內會很難，的確很難。但想想看我們最終牛逼了一把，把它降到了比允許上限的一半還要低，感覺很爽，很長一段時間內整個團隊士氣高昂信心爆棚做事像開了外掛。

　　牛人們總是不斷的超越自己。給他們一個離譜的目標，配以應有的工具，適當的幫助，足夠的信心還有一定的時間，他們會讓你大吃一驚，也會讓自己大吃一驚。這一點，喬幫主是行家，屢試不爽。

　　但做到這一點有一個前提 —— 不能害怕犯錯。如果犯錯是被要嚴懲的，失敗是不允許的話，牛人們只能在框框中被圈養，沒有辦法實現突破。有一句話我經常掛在嘴上"ask for forgiveness, not for permission". 在 Facebook, 大膽行事犯錯是容易被原諒的。

　　但反過來，有一點要小心，就像第 7 點所說的 —— 你不能隨便把一個離譜的目標交給一個人，然后期待他來給你驚喜，盲目帶來的可能是驚嚇。你需要真正的牛人，至少是潛在牛人。而作為一個領導者，你的一個任務是幫助他們，鼓勵他們，來引爆自己的潛力點。Facebook 不缺此類待引爆的牛人。

　　10、不要過多設計或者過早優化

　　有些工程師有一股出于本能的沖動想把自己的程序規模化，甚至在這些程序還沒看到大規模使用的曙光之前。我在 Facebook 開始的時候，也是沖動型工程師一類。但經歷過幾次失敗的產品之后，我牢記了這個教訓。不要過多設計或者過早優化，把核心功能設計的簡單精煉。只有在看到產品有被大規模使用的趨勢后， 才來增加功能或增加規模量。有一個我做的產品使用的上限是 200 萬月用戶(當時 Facebook 整個月用戶群是 4000 萬左右)，但我的實現已經做了很多額外的功來滿足更多的用戶，做的時候感覺很爽(感覺自己很牛，感覺再多人用產品也不會崩潰)， 之后感覺很慘。

　　但這一點不一定能適用于架構上的工作，比如 Friendster 這個網站的失敗就是其基礎架構的性能長期無法應對急速增長的用戶以致網站很慢甚至崩潰。在用戶增長高潮來臨之前，你應該已經在架構上做了足夠多的前戲，否則搞不好就要像 Friendster 收攤子散伙。但同時也要意識到，你所看到的用戶訪問模式，你的網站功能，在你只有 10 萬用戶的時候，可能和你有 1 億用戶的時候會很不一樣。所有太多太早太頻繁的架構上的大動作可能會適得其反。這一點上，你要小心判斷。

　　結語:

　　在 Facebook 的 4 年半很好玩，我學到的感受到的遠多于以上的十項，但希望這個分享能對朋友們有點幫助。同時祝所有的朋友在自己現在扮演的角色上都有好運。

it知識庫：王淮：我在Facebook的十點經驗分享，轉載需保留來源！

鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯系我們修改或刪除，多謝。