開發者驅動文化

　　在全球擁有超過 6 億用戶，非死book 已經在社交媒體世界實現了其的霸主地位。貫穿整個用戶界面的變化，非死book 從未失去其核心原則，包括用戶的社交活動，個人信息的可訪問性和無限主機服務。持續不斷的進化是一個成長型公司的標志，而 非死book 絕對符合這個條件。但是在卓越價值觀和創新的背后，使其成功的部分因素可能要歸功于他們的開發者驅動的文化（Developer Driven Culture）。非死book 的員工創建和維護的代碼，使平臺運行有了更加流暢，更加動態的體驗。

　　許多公司和分析師在仔細剖析這種做法，想找出是哪一點起的作用，是否可以復制到其他事情中。基本上在開發者驅動的系統中，讓工程部門運轉的是開發者而不是產品經理。

　　在以產品為導向的文化中，往往是前臺的那些東西帶來最大的聲譽。開發者可以聲稱他們發明或者在從事一些很炫的用戶界面方面的工作，既讓公眾熟悉，又只需要最少的“高難度”編程技巧。

　　然而 非死book 的文化是那種吸引開發者而不是產品經理的文化。例如給予后臺而不是前臺更高的聲譽。能讓開發者興奮的是那些工程問題，比如如創建快速算法或最高效率的壓縮策略，或者打造云端托管服務基礎設施等，這些都能吸引最優秀的工程師。

　　“pushing down“的工程決策對工程師們來說可以起到在開發過程中增加更多責任承擔的效果。工程師們能夠調用他們自己的程序，但是他們必須承擔多出來的那部分責任。

　　不過不是開發者決定的事情所有都會被自動批準。據可靠消息，非死book 在讓任何變動生效之前確實使用了自動化測試來包含”push-blocking”。該報道說 CEO Mark Zuckerberg 會親自在每一個修改發布前，從新聞源里檢查這些修改。

　　不過一般而言，在 非死book 的工程師們比那些在一個產品經理驅動的工作環境里有更多的回旋余地和權力。產品經理同開發者的比例據說在1:7 到1:10 的范圍。在產品會議上，開發者的發言占大部分時間。如果產品經理占用了過多的時間，工程師們經常就會抱怨。產品經理可以提產品的想法，但是決定做哪一個還是取決于開發者。

　　想法就是單純地信任工程師們，讓他們做自己最擅長的，盡量減少外部干涉。同樣，如果某件事情出錯了，比起在其他類型的工作環境，他們也沒有太多可以責怪經理的。

　　有跡象表明，擁有自己的代碼而增加的壓力和責任能做出更好的工作。舉個例子，初創公司的員工比起那些已建立好的公司的員工，一般來說有更多的產出。因為當問題出現時，他們沒有太多理由去責怪他人。

　　開發者驅動模式可能不是在每個公司都奏效。這很大程度依賴于員工的質量。作為世界上最大的社交網絡，因為既得利益的關系，非死book 在激勵和吸引頂尖的人才上毫無困難。這樣，他們可以在雇人上面挑剔。事實上，根據內部消息，非死book 要求新程序員經受四到六周的”新手訓練營“。他們需要在里面學習 非死book 的基礎結構。大概 10% 的受訓人員不會達到要求，他們會被建議馬上離開公司。

　　顯然，如果你有熱愛編程和接受新的挑戰的好員工，并且他們能負好責，那么開發者驅動的文化可以運作的不錯。盡管這樣，不是所有的開發者都適合這樣的模式。有的可能就是習慣工作在那種出現問題很容易推卸責任的環境。

　　非死book 的例子說明，在時機正好時期，開發者驅動的文化可以良好的運作。在某些情況下，公司可能必須用試錯法，來看這種模式在他們的情況中能否奏效。當然，不是每個公司都能夠接納一個給予工程師如此大的權力的系統。

　　公司通過仔細研究 非死book 的做法和與日俱增的關于它的報道，能決定在他們自己的情況進行的實踐的適合程度有多大。他們的細致分析可以避免當其還沒有準備好給自己的工程師這樣給力的投資時犯下錯誤。還是那句話，如果環境對了，當我們跟隨和學習 非死book 時，好事就會降臨。