开发者驱动文化

　　在全球拥有超过 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 时，好事就会降临。