Facebook老員工的十點經驗

摘要: @王淮Harry哥在Facebook的十點經驗分享 我是2007年初加入Facebook, 那時大概150人; 2011年9月底離開, 當時3200多人. 經曆了很多稀奇古怪但影響很大的項目, 像Application Platform, So ... 分享到

@王淮Harry哥在Facebook的十點經驗分享 - 非反人類文字版 　　我是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年半很好玩，我學到的感受到的遠多于以上的十項。但希望這個分享能對朋友們有點幫助。同時祝所有的朋友在自己現在扮演的角色上都有好運。 via 新浪部落格 by 王淮Harry哥

本文來自騰訊大講堂(DJT.QQ.COM)，轉載請注明出處。