伯樂線上注：英文原文寫於2011年3月，所以文章中的資料會和目前的不相符。感謝@奇風餘谷 的熱心翻譯。
在全球擁有超過6億使用者，Facebook已經在社交媒體世界實現了其的霸主地位。貫穿整個使用者介面的變化，Facebook從未失去其核心原則，包括使用者的社交活動，個人資訊的可訪問性和無限主機服務。持續不斷的進化是一個成長型公司的標誌，而Facebook絕對符合這個條件。但是在卓越價值觀和創新的背後，使其成功的部分因素可能要歸功於他們的開發者驅動的文化（Developer Driven Culture）。Facebook的員工建立和維護的程式碼，使平臺執行有了更加流暢，更加動態的體驗。
許多公司和分析師在仔細剖析這種做法，想找出是哪一點起的作用，是否可以複製到其他事情中。基本上在開發者驅動的系統中，讓工程部門運轉的是開發者而不是產品經理。
在以產品為導向的文化中，往往是前臺的那些東西帶來最大的聲譽。開發者可以聲稱他們發明或者在從事一些很炫的使用者介面方面的工作，既讓公眾熟悉，又只需要最少的“高難度”程式設計技巧。
然而Facebook的文化是那種吸引開發者而不是產品經理的文化。例如給予後臺而不是前臺更高的聲譽。能讓開發者興奮的是那些工程問題，比如如建立快速演算法或最高效率的壓縮策略，或者打造雲端託管服務基礎設施等，這些都能吸引最優秀的工程師。
“pushing down“的工程決策對工程師們來說可以起到在開發過程中增加更多責任承擔的效果。工程師們能夠呼叫他們自己的程式，但是他們必須承擔多出來的那部分責任。
不過不是開發者決定的事情所有都會被自動批准。據可靠訊息，Facebook在讓任何變動生效之前確實使用了自動化測試來包含”push-blocking”。該報導說CEO Mark Zuckerberg會親自在每一個修改釋出前，從新聞源裡檢查這些修改。
不過一般而言，在Facebook的工程師們比那些在一個產品經理驅動的工作環境裡有更多的迴旋餘地和權力。產品經理同開發者的比例據說在1:7到1:10的範圍。在產品會議上，開發者的發言佔大部分時間。如果產品經理佔用了過多的時間，工程師們經常就會抱怨。產品經理可以提產品的想法，但是決定做哪一個還是取決於開發者。
想法就是單純地信任工程師們，讓他們做自己最擅長的，儘量減少外部干涉。同樣，如果某件事情出錯了，比起在其他型別的工作環境，他們也沒有太多可以責怪經理的。
有跡象表明，擁有自己的程式碼而增加的壓力和責任能做出更好的工作。舉個例子，初創公司的員工比起那些已建立好的公司的員工，一般來說有更多的產出。因為當問題出現時，他們沒有太多理由去責怪他人。
開發者驅動模式可能不是在每個公司都奏效。這很大程度依賴於員工的質量。作為世界上最大的社交網路，因為既得利益的關係，Facebook在激勵和吸引頂尖的人才上毫無困難。這樣，他們可以在僱人上面挑剔。事實上，根據內部訊息，Facebook要求新程式設計師經受四到六週的”新手訓練營“。他們需要在裡面學習Facebook的基礎結構。大概10%的受訓人員不會達到要求，他們會被建議馬上離開公司。
顯然，如果你有熱愛程式設計和接受新的挑戰的好員工，並且他們能負好責，那麼開發者驅動的文化可以運作的不錯。儘管這樣，不是所有的開發者都適合這樣的模式。有的可能就是習慣工作在那種出現問題很容易推卸責任的環境。
Facebook的例子說明，在時機正好時期，開發者驅動的文化可以良好的運作。在某些情況下，公司可能必須用試錯法，來看這種模式在他們的情況中能否奏效。當然，不是每個公司都能夠接納一個給予工程師如此大的權力的系統。
公司通過仔細研究Facebook的做法和與日俱增的關於它的報導，能決定在他們自己的情況進行的實踐的適合程度有多大。他們的細緻分析可以避免當其還沒有準備好給自己的工程師這樣給力的投資時犯下錯誤。還是那句話，如果環境對了，當我們跟隨和學習Facebook時，好事就會降臨。
英文原文：Robert Diana，編譯：@奇風餘谷
譯文連結：http://blog.jobbole.com/36797/
【非特殊說明，轉載必須在正文中標註並保留原文連結、譯文連結和譯者等資訊，謝謝合作！】