[轉]我在Facebook的十點經驗分享 – 非反人類文字版

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

在Facebook的這些年讓我學習感悟了不少東西, 不少東西溶在血液中, 如今我換了時間來思考最值得分享的10點經驗和你們分享. 但願能給創業的朋友一些啓發。

來源：王淮Harry哥

在咱們開始以前, 先來一段免責聲明.

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.習慣委託, 但不要盲目, 請謹慎

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

若是你有一個重要的任務須要委託給別人, 你要麼

• 已經對此人很是瞭解. 知道他戰鬥力非凡能夠搞定; 或者相信他能夠迅速學習提升打雞血搞定;

要麼

• 須要在一開始手把手教他, 時不時問他, 直到你對他有足夠的信心.

具體我是這麼作的. 項目開始時, 我讓被委託人給我一個總體計劃以及幾天內能夠完成的任務. 一開始常常會面跟進, 而後肯定後幾天的任務. 根據每次完成情況來估計他能不能」高快狠」地完成最終的目標. 信心逐漸建成後能夠減小關於該項目的細節討論. 此時的委託能夠放得更開. 但有一點要注意, 若是跟的太緊的話, 可能讓人以爲你對他不放心, 他也會作得畏首畏尾, 這可能比盲目的委託還更差. 因此在委託和謹慎之間, 有一個微妙平衡.

我以爲在這一點上我還要增強. 這裏也和你們提個醒.

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年半很好玩. 我學到的感覺到的遠多於以上的十項. 但但願這個分享能對朋友們有點幫助. 同時祝全部的朋友在本身如今扮演的角色上都有好運.