译文:

我对facebook的运转着迷。这是一个很独特的环境，不容易被复制（他们的体系并不适合所有的公司，即使他们努力尝试过）。下面是我和facebook的朋友们关于他们如何开发和管理项目的记录。

现在距离我收集的这些信息又过去6个月了，我相信facebook肯定又对他们的项目开发实践进行了改进。所以这些记录可能会有点过时。同时facebook的工程师驱动文化也越来越为大众所知。非常感谢那些帮助我整理这篇文章的facebook的朋友们。

记录：

• 截止到2010年6月，facebook有将近2000名员工，10个月前只有1100名，一年之间差不多翻了一番。
• 两个最大的部门是工程师和运维，每个部门大概都是400-500人。这两个部门人数大约占了公司的一半。
• 产品经理与工程师的比例大约为1-7到1-10。
• 每个工程师入职时，都要接收4-6周的培训，通过修补bugs和听高级开发工程师的课程来熟悉facebook。
• 培训结束后，每个工程师都可以接触线上的数据库(更大的权力意味着更大的责任，也有一份”勿做清单”，不然可能会被开，比如共享用户的隐私数据)。
• 有非常牢靠的安全体系，以免有人不小心/故意做了些不好的事。
• 每个工程师可以修改facebook的任何代码，随时可以迁入。
• 浓厚的工程师驱动文化。”产品经理基本可以被忽略”，这是facebook一名员工的话。工程师可以修改流程的细节，重新安排工作任务，随时植入自己的想法。
• 在每月的跨部门会议上，由工程师来汇报工作进度，市场部和产品经理会出席会议，也可以做些简短的发言，但如果说得太多，很可能就会被打小报告。他们确实想让工程师来主导产品的开发，对自己的产品负责。
• 项目需要的资源都是自愿的
  • 一个产品经理把工程师们召集到一起，让他们对他的想法产生兴趣。
  • 工程师们决定开发那些让他们感兴趣的特性。
  • 工程师跟他们的经理说：”我下周想开发这5个新特性”。
  • 经理会让工程师独立开发，可能有时会让他优先完成一些特性。
  • 工程师独立完成所有的特性——前端/后端/数据库，等等所有相关的部分。如果需要得到设计人员的帮助，需要先让设计人员对你的想法产生兴趣。其他如架构之类的也一样。但总体来说，工程师要独立完成所有的任务。
• 对于某个特性是否值得开发的争论，通常是这么解决的：花一个星期的时间完成他，并在小部分人群中(如1%)进行测试。
• 工程师常常希望解决难题，这能获得声望和尊敬。他们很难对前端项目或UI设计产生太大的兴趣。这跟其他公司可能正好相反。在facebook，后端任务，比如新的feed算法，广告投放算法，memcache优化等等，是工程师真正感兴趣的。
• 所有的代码修改都要进行审核(通过一个或多个工程师)，但News Feed是个例外，因为太重要了，Zuckerberg会亲自review。
• 所有的修改至少要被一个人审核，而且这个系统可以让任何人很方便地审核其他人的代码，即使你没有邀请他
• 工程师负责测试，代码修复，和维护自己的项目。
• 每个办公室或通过VPN连接的员工会使用下一版的facebook，这个版本的facebook会经常更新，通常比公开的早1-12小时。所有的员工被强烈建议提交bugs，而且通常会很快被修复。
• 很奇怪只有很少的QA或自动测试——”大部分工程师都能写出基本没有bug的代码，只是在其他公司他们不需要这么做。如果有QA部门，他们只要把代码写完，扔给他们就行了”
• [针对上一条]我们有自动测试，代码发布前必须要通过测试。我们不相信”所有的工程师都能写出没有bug的代码”，毕竟这是一个商业公司。
• 很奇怪，缺少产品经理的影响和控制——产品经理是很独立的和自由的。产生影响力的关键是与工程师和工程师的领导们们搞好关系。需要大致了解技术，不要提一些愚蠢的想法。
• 所有提交的代码每周二打包一次。
• 只要多一分努力，终于一天会发生改变。
• 星期二的代码发布，需要所有的提交过代码的工程师在场。
• 代码打包前，工程师必须在一个特殊的IRC channel上。
• 运维执行打包过程
  • facebook有大约60000台服务器
  • 有9个代码发布级别
  • 最小的级别只有6台服务器
  • 星期二的代码发布会先发布到6台服务器上，运维组会检测这6台服务器的反应，保证代码正常工作，然后再提交到下一级
  • 如果发布出现了一些问题（如报错等等），那么就停止下一级的部署，提交出错代码的工程师负责修复问题，然后从头继续发布。
  • 所以一次发布可能会经历几次重复：1-2-3-fix. 回到1. 1-2-3-4-5-fix. 回到1. 1-2-3-4-5-6-7-8-9
• 运维组是受过严格训练，倍受尊敬，而且有商业意识的。他们的工作包括分析错误日志，负载和内存状态等等。还包括用户行为。
• 代码发布期间，运维组使用IRC-based页面系统，可以通过facebook/email/irc/im/sms ping每一个工程师，如果需要他们注意的话。对运维组不做回应是一件很羞愧的事。
• 代码一旦发布到第9级，并且稳定运行，就算发布成功了。
• 如果一个特性没有按时完成，也没什么大不了的，下次完成时一并发布即可。
• 如果被svn-blamed,public shamed或工作经常疏忽就很可能被开除。”这是一个高效的文化”。不够高效或者不够聪明的员工会被剔除。管理层会在6个月的时间里观察你表现，如果不 合格，只能说再见。每一级都是这个待遇，即使是C级别和VP级别，如果不够高效，也会被开除。
• 被责骂不会导致解雇。我们特别尊重别人，原谅别人。大部分高级工程师都或多或少犯过一些严重的错误，包括我。但没有人因此被解雇。
• 我也没有遇到过因为上面提到过的犯错误而被解雇。有些人犯了错，他们会非常努力地去修复，也让其他人得到了学习。

来源：http://goo.gl/do4cL

发信人: sighsighsigh (哦~~呵呵呵呵呵), 信区: Java
标 题: 带了几个特弱的程序员怎么办
发信站: 水木社区 (Wed Jan 12 02:04:52 2011), 站内

直想骂人
都是刚毕业或毕业一年的小孩，不知道哪个旮旯的烂校专科毕业的
我下达指示已经详细到存哪个表查哪个表的地步了，数据库字段千锤百炼，绝对简洁易懂
只要他们把存取实现利索，系统就出来了
一个人平均就做3~4个模块吧
结果做了干了三四个月了，还不利索，bug一堆，到处是弱智问题，用户体验差得让人冒火
代码……更加不忍卒看，一点破事能啰嗦一大篇，看得我来气
没办法，就当我是个幼儿园阿姨吧，只要他们实现不了的，有困难的，让他们都来找我，我解决，我一个小时解决的问题他能给我拖一个月
这样下去还不行，领着他们重构吧，我写demo，让他们模仿。我真不明白一些问题我得讲解的细到什么程度，难道真得帮他们把代码都写出来？
现在他们一肚子不情愿，觉得拼sql串挺好用criteria不好，觉得我规定成员变量不许用缩写很长很麻烦，觉得功能都实现了还干嘛折腾他们。我靠！不看看你们这个破进度，要是再加功能在这么个垃圾堆上能盖出什么好房子？
更要命的是还有个不懂开发又写过程序的半吊子领导，主键不能逻辑相关我都跟他解释不清，催我的进度，嫌我前面开发的慢，嫌我一直拖着不加新功能新功能，想把现在的几个小孩开掉又舍不得花大价钱弄几个靠谱的程序员
问题是他嫌来嫌去的，向上级汇报的时候给他争脸的还是我，其他子系统，当初他觉得放心的，现在问题一堆。就这样了，他还执迷不悟，继续跟我拧巴。

现在向上得顶住上级的压力，向下又得顶住懵懂程序员的压力，问题是我不是个强势的人，最不擅长的就是施加压力，现在还得面临着下面造反的威胁，要命
–

发信人: bigzergling (sg552)

没办法，你应该也是属于“被项目经理”的人。
好好的中高级程序员不做，非得带领一批菜鸟，只好受这个罪。

发信人: recoba (雷科巴-漂流)

你自己完整的写一个模块，然后让他们照葫芦画瓢
这样的人的水平也就够这样的，指望独当一面?
我手下1W的coder都得我来按着，一点点的改，sigh

发信人: yishuihanxia (中国版柯南)

公司有时候为了省钱觉得招程序员吗，随便学几年的就行，结果水平参差不起，学习能力
又很差。搞得产品质量一直上不去
我现在才觉得管理者有技术背景是多么的重要。。。。

发信人: kabbesy (步子大了，容易扯着蛋)

来点干货吧

其实lz这种情况在非研发型外企里，比比皆是
想降低人工成本，结果不但进度效果差
还累坏了不擅长管理的高级程序员（大多数都不擅长）

还是参考外科手术团队的模式

越底层越核心的代码，由越好的程序员完成的。以质量为优先

越上层，越不可复用，越看起来需要擦屁股磨时间的事情，就越交给低水平的新手。以总人工时间为优先

对java程序员比如完善注释，完善javadoc，完善单元测试
对页面程序员比如xxxx，xxxxxx，xxxxxxxxx（贵版牛人太多，偶不敢瞎写）

最后再辅以良好的技术氛围
每周学习一块内容，交互的讲出来
以及良好的绩效考评及淘汰机制
新人其实很好成长的（而且也乐于学习）

大多数人就算不智慧，但也决不至于笨
新人水平不行，关键还是老师（环境）的错！

发信人: coquille (烟灰)

一大早看到这个帖子。。。
因为在类似问题上也曾吃足了苦头，我打算详细地回复一下，呵呵。

【 在 sighsighsigh (哦~~呵呵呵呵呵) 的大作中提到: 】
: 直想骂人
: 都是刚毕业或毕业一年的小孩，不知道哪个旮旯的烂校专科毕业的

什么样的项目用什么样的人，考虑到复杂度、难度、项目规模、期限等因素，
该用靠谱人士的项目用了不靠谱的人，整个项目组会变成一口大锅，
甚至把其他各项目组的成员也逼成救火队员。

所以项目经理必须要做“预算”，接项目之前，必须先搞清楚是个什么样的项目，
然后必须有向高层“要人”的权力，根据你的预算，把实实在在的数据摆出来，
就说我要多少多少什么能力层次的人，否则我没法保证期限和品质，
高层不给，那是高层的责任了。

接下来项目经理必须对每个被加入的成员做面试，必要时笔试机试都可以考虑，
而不管该成员是否正式员工，前任领导对其评价有多高，自己的评价才是靠谱的。

经过这几步，你说的那种员工已经进不到你的项目组了。
但是出于培养人才的目的，必然新人也是要带的，这就要考虑项目组人才结构，
多少个老头带多少个新人，老头能力（带人方面）性格如何，新人新到什么程度，
都要斟酌一二。。同时新人的“负产出”因素必须考虑并反映到schedule里。

: 我下达指示已经详细到存哪个表查哪个表的地步了，数据库字段千锤百炼，
: 绝对简洁易懂只要他们把存取实现利索，系统就出来了

这种现象很常见的，对于有基础甚至有默契的人，估计你三句话不到人家就明白了，
但是对于没基础的人，就必须做好“把任务粒度分解到是个人都能干”的地步，
否则对于高层来说，底下人没干好活，不是他们不行，而是你没有分解好任务。
像我刚参加工作的时候，遇到的那位头头，就手把手地带着我画流程图，
甚至有时候连伪代码都给我框出来，这么多年过去了，我对他除了感激还是感激。

话说回来，对于新人最高效的方法还是模仿，要给他们例子，比如说某个已经写好
的模块，至少也得有个demo，在项目初期demo是必须做的，也必须找一个最有共性
的模块组织精兵优先开发，然后再作为模范推广，不知道你们是不是这样做的？

: 一个人平均就做3~4个模块吧
: 结果做了干了三四个月了，还不利索，bug一堆，

这个确实无语了，大多数项目的开发阶段也就一两个月而已。。

: 到处是弱智问题，用户体验差得让人冒火
: 代码……更加不忍卒看，一点破事能啰嗦一大篇，看得我来气

用户体验？没有设计书么？设计书没有画面image和机能说明么？
没有的话，不怪他们，只怪你们input资料不完备。
你总不能指望一个新手去给你“发明创造”吧？
拿那么点可怜薪水的人能给你依葫芦画瓢已经不错了，不能指望更多。
（这句话是当初另一个头头对我带人时的抱怨的批评。。）

: 没办法，就当我是个幼儿园阿姨吧，只要他们实现不了的，
: 有困难的，让他们都来找我，

这个感觉属于方法问题，你说让他们找你，实际会发生的情况往往是
谁都不找你。为什么？国内常见现象，心理素质问题，他们在考虑某个
问题到底要不要找你的时候，心理过程往往是比较复杂而且微妙的。

站在他们的立场考虑，
一方面他们可能希望自己表现得强一点，不要什么问题都问；
另一方面，他们确实很难界定到底哪些该问哪些不该问；
还有可能，是挺体谅你，觉得你已经很忙，不该给你添麻烦等。

其实我觉得这只是一个权力尺度的问题，如果你希望他们能问出
有效的问题来，必须得把他们的权力尺度界定好并使之知悉遵守。
比如说在我这边往往就是两条铁律：
1、式样上问题必须问，然后balabala解释定义什么是式样问题
2、如果一个问题自己调查要两个小时甚至不够，而问一下
可能两分钟就能解决的，那么必须问。

说到底，最好的做法不是等他们来问你，而是你主动问他们，
这需要他们的直接上司能充分把握各member的工作内容，
然后每天根据schedule定出一些关键点或小的里程碑，
在某个合适的时间逐一问之：实现没有？怎样实现的？有什么难处？
不知道你们有没有早会和晚会，有的也可以在会上实施，
早会布置工作内容，晚会检查工作进度，如果时间能把握好的话还是有效的。

另外，新人的代码必须review，而且是行级的review，这也应该是铁律。

: 我解决，我一个小时解决的问题他能给我拖一个月

感觉这个也是你的问题，为什么你会允许他们拖一个月？
“允许”是个权力啊。。如果换成我，我认为自己没有允许他们“拖”的权力。

: 这样下去还不行，领着他们重构吧，我写demo，让他们模仿。
: 我真不明白一些问题我得讲解的细到什么程度，难道真得帮他们把代码都写出来？

必要的时候亲自操刀也是难免的了。

: 现在他们一肚子不情愿，觉得拼sql串挺好用criteria不好，
: 觉得我规定成员变量不许用缩写很长很麻烦，觉得功能都实现了还干嘛折腾他们。

这可能也怪你。做项目就像行军打仗，必须有纪律，
在时间充裕的情况下，你可以说服他们，criteria好，好在哪儿，
拼sql串不好，为什么不好；反之，不做任何解释，
“这是决定，你必须服从，有问题我责任，请务必遵照执行！”

至于变量命名之类，难道没有coding rules么？
没有的话，他们把代码写成什么样子都没啥可说的。。
详细的没有可以，但是关键的十条八条你花半个小时还是可以列出来的，
－－一般情况下这十条八条已经能涵盖80%以上的代码了。。

: 我靠！不看看你们这个破进度，要是再加功能在这么个垃圾堆上能盖出什么好房子？
: 更要命的是还有个不懂开发又写过程序的半吊子领导，主键不能逻辑相关我都跟他
: 解释不清，催我的进度，嫌我前面开发的慢，嫌我一直拖着不加新功能新功能，

这个没啥办法的，该好好解释就好好解释，到底是你解释不清还是他听不明白，
要考虑一下，不管是哪一种情况，都可以考虑调整自己的表达方式或详细程度。
一般而言单纯的口头表达没啥效果，要配合图、表等，载体可以是白板、文档等；
而且往往口说无凭，你不能指望你的上司掌握了和你一样丰富的基层细节，
必要时你要列数据，将真实情况作为支撑你的观点的证据详细地列举出来，
才有说服力，也才能让他更好地把握真实情况，理解你的难处，
否则任你叫破喉咙也没用。

: 想把现在的几个小孩开掉又舍不得花大价钱弄几个靠谱的程序员

什么样的价码用什么样的人，没啥可说的。
但是这个问题最好当机立断，人月神话的说法是往一个已经延误的项目里
追加成员往往会导致更严重的延误。要加人，越早加入越好，越往后风险越大。
再说，新加进来的人，不管宣称靠不靠谱，你不都得有个考察的过程？

: 问题是他嫌来嫌去的，向上级汇报的时候给他争脸的还是我，其他子系统，
: 当初他觉得放心的，现在问题一堆。就这样了，他还执迷不悟，继续跟我拧巴。

争脸不争脸的问题有点扯了，项目做好了谁都有脸，
项目做砸了谁都吃不了兜着走，还有什么脸可言？
你跟你的领导其实就一条船上的，利益和方向都一致才对，拧巴个啥呀。。
还有，事实是怎样就是怎样，该怎么报告就怎么报告，
如果你们向高层的报告没有反映真实情况，或者容易引起理解偏差，
那么你还指望高层能做出正确的决策呀？

:
: 现在向上得顶住上级的压力，向下又得顶住懵懂程序员的压力，
: 问题是我不是个强势的人，最不擅长的就是施加压力，

这个确实很难把握吧。
但是一般而言你需要把项目的真实情况和紧迫性、以及上面做出的决策等
传达到每一个member脑袋里，一般而言不是极品的话不会不做出积极反应的。
如果真遇上了极品，那没啥好说的，如实报告，请高层定夺就行了。

: 现在还得面临着下面造反的威胁，要命

造反。。。开玩笑呢。

发信人: sayinger (言者)

原型总做过吧，不少项目是一个原型接着一个原型，基本是不靠谱的业务人员练手的，这种玩意就别锤子改锥的伺候了，纸糊才是王道…

发信人: coquille (烟灰)

嗯，理解你的意思了。
不过我做过的原型都是技术上的原型，是用来验证评估某种技术是否适用的，
业务上的原型倒是没有做过，只是看过一些，正式立项后都是要推倒重来的，呵呵。

发信人: wew (man in the mirror)

这事我觉得不能怪别人

首先比较一下，一张白纸好带还是一瓶子混水好带？
然后，你至少有2点没做到位：

1、前期没有做好架构、或者说架构没有解释清楚，
画上2、3天或者1周简单的画一些UML图，把接口设计交待清楚
省去后面3、4个月的无用功

2、关键时候没有做code review
初期的时候应该多做一些code review工作，把发现的问题给他们指出来
这样才能起到“带人”的作用，这样能够避免他们犯同样的错误
大概2~3周后就可以减少code review甚至让他们互相review

发信人: recoba (雷科巴-漂流)

it公司大部分开发都很忙啊
再说哪有那么多有耐心的人了
我毕业以后从没见过，都得自己咬牙努力看和理解
到了要带人的时候，也都是非应届的，难道还真的手把手的交?
除非有些核心算法交代不清楚，需要认真的画图和好好交流
其他的基本不会了

发信人: coquille (烟灰)

当你某一天带人带到万念俱灰的时候，耐心突然就出来了，呵呵。
人真是一种奇怪的动物，被逼到无路可退或被彻底打趴下的时候，
性格和世界观都可能产生不可思议的变化。。- -。

话虽如此，对于我们来说实际情况还是比较糟糕的，
就算有那耐心也没那时间和精力去坚持做这样的事情，
所以往往都存在体制超编、生产率低、客户评价低、薪酬低的恶性循环的死结。

发信人: canper (洗衣粉)

看了下，写得很好，m了。
不过大家也不必苛责楼主，除了埋怨用户体验差那条有点过了，其他的我还是挺理解楼主的，毕竟就算码农再怎么民工化也不可能靠软件工程让一帮弱人写出好程序。
至于说就不应该让这几个人进项目组，楼主也无奈啊

发信人: coquille (烟灰)

内牛满面。。
看楼主写的那些心里挺不是滋味，做软件难，原来大家都是这么过来的。

历史上一个产业从诞生到成熟可能要经历几百年的时间，软件产业才几年呀。。
想要降低到像建筑业那样的门槛，等到咱们这一代白发苍苍的时候都未必呢。
看《梦断代码》，那么一大票子的大牛，做一个GTD软件，尚且。。。

从明天开始就要再次投入ASP.Net的开发中了. 希望还没有太生疏. 这个项目麻雀虽小, 五脏俱全. 权限, 多语言, 多客户端平台, 二次开发接口等等, 正好可以好好的整理一下网站开发的架构. 顺便为以后的Web开发整理出一个标准的框架. 算不算是假公济私呢, 无语中…

PS: 昨天忙活半天，用Gallery把网站建设起来了，好多地方还没有配置，争取周末有点进展。Have a good weekend.