mod

极客时间专栏/研发效率破局之道/管理和文化/31 | 业务目标和技术目标两手抓：怎样打造高效团队？.md

@@ -0,0 +1,145 @@
+<audio id="audio" title="31 | 业务目标和技术目标两手抓：怎样打造高效团队？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/f9/45/f902c7e809d5162a8901e1763aee6b45.mp3"></audio>
+
+你好，我是葛俊。今天，我来和你聊聊管理和文化。
+
+今天这篇文章，是最后一个模块“管理和文化”的第一篇。在前30篇文章中，我已经从优化流程、团队工程实践、个人工程实践这三大方面与你介绍了很多原则、方法和具体实践。通过这些内容，相信你应该对软件研发活动的本质有了更深刻的理解，也对这条超级灵活的流水线如何提效有了新的认识。
+
+但作为团队管理者，要提高团队的研发效能，掌握了这些原则、方法和实践后，还要通过管理和文化让它们真正在团队落地。管理是提高团队研发效能的基石，而文化是持久高效的保障。同时，管理又决定了文化，如下图所示。
+
+<img src="https://static001.geekbang.org/resource/image/30/bf/30fbd592b6447409cd941625d94fb4bf.png" alt="">
+
+所以，在接下来的几篇文章中，我会参考硅谷高效能公司的一些管理实践和原则，以及我在国内外公司的落地经验，与你介绍如何通过管理和文化来提高团队的研发效能。今天，我们就先从技术管理者的主要工作步骤出发吧。
+
+在我看来，技术管理工作主要有如下3个步骤：
+
+1. 寻找目标；
+1. 目标管理；
+1. 计划并执行去实现目标。
+
+其中，计划执行又包括人、流程和工具3个方面。
+
+## 第一步：寻找目标
+
+在[第1篇文章](https://time.geekbang.org/column/article/125840)中，我曾和你分享研发效能的三要素是有效、快速、可持续性，其中第一条就是有效，也就是准确性。所以，要想建设高效的研发团队，技术管理者的第一项重要工作就是，作为舵手，为团队寻找方向和目标。
+
+**首先，技术团队的根本目标就是业务目标。**毋庸置疑，业务目标是团队存在的意义，完成它是一切的基础。
+
+业务目标的设定有两个层次：
+
+- 弄清楚公司和上级对团队的预期，达到这个预期，是团队的基础目标。
+- 在基础目标之上，还要给团队设定一个进取目标。我们需要分析公司的发展方向，以及团队的实际情况，找到那些既符合公司利益，又通过跳一跳就能够得着的目标。
+
+除了业务目标之外，还有**另外一种技术管理者一定要关注的目标，即技术目标**。如果只关注业务，我们的行动就容易短视。有这么一句话我非常赞同：技术常常在短期被高估，在长期被低估。作为技术管理者，我们需要看清楚并坚持技术在长期可以发挥的巨大作用，在技术上持续投资，制定并完成合理的技术目标。
+
+在我看来，**技术目标主要有两种：**
+
+- 一种是关于偿还技术债的，这是处理已经形成的问题。关于技术债的处理，你可以再回顾下[第14篇文章](https://time.geekbang.org/column/article/138916)中的相关内容。
+- 另一种是前瞻性的技术目标。作为技术管理者，我们要有灵敏的技术嗅觉，对即将出现的技术挑战，做一些预防和准备。
+
+关于前瞻性的目标，我再和你分享一个我在Facebook时的例子吧。
+
+2013年左右，我们从公司开发者的使用数据观察到，由于代码仓的迅速增大，Git对它的支持有些吃力，比如一些操作的速度越来越慢。于是，我们抽出人力去做调研，克隆了一个Facebook的代码仓，并按照当时的增长速度去模拟大量的提交进行测试。
+
+结果发现，再过半年，许多常用的Git操作速度都将下降到不可接受的程度。于是，我们团队专门成立项目组来解决这个代码仓将会出现的性能问题。最终，我们在问题还没发生前就把它解决掉了。这种具有前瞻性的技术目标，确保了公司的业务能够持续发展，给公司和团队带来的好处显而易见。
+
+**关于技术目标的设定，有两个常见问题：**
+
+- 一是，业务目标和技术目标的时间占比应该是多少？从我个人的经验看，80%是一个合适的点。
+- 二是，技术目标要不要立项？在我看来，这要视公司情况而定。如果你的主管对技术目标认可，那最好能够单独立项；否则，就把技术目标合并到业务目标中。比如，要实现某一个业务，我们必须重构某一个组件。这里，重构组件就是一个技术目标，无论采用哪一种方式，我们都需要持续关注技术目标。
+
+## 第二步：目标管理
+
+目标管理的第一步就是制定计划。这里，我先给出一个有效设定目标的原则：SMART原则。SMART是Specific（具体）、Measurable（可衡量）、Attainable（可达成）、Relevant（与主目标有相关性）和Time-bound（有明确的截止期限）这5个英文单词首字母的缩写。
+
+一个目标可能被定义为“今年下半年实现用户讨论功能”，但很明显这个定义不够清晰。而另外一种定义方法是“今年12月31号之前，实现用户讨论功能模块，在主页以及至少一个其他页面使用，并且用户使用率大于10%”。
+
+可以清楚看到，第二种定义方式更具体，团队成员有更明确的方向，能专门针对具体的模块使用场景和使用率努力。并且，具体的数字和截止期限，可以帮我们更容易跟踪项目进展。
+
+很明显，第二种定义方式正是使用了SMART原则中的具体（S）、可衡量（M）和有明确截止日期（S）三个原则。另外，这个任务还要是可达成（A）的，也就是既要有挑战性又可以通过努力达成，这样团队工作起来才会更有劲头。最重要的是，与主目标的相关性（R）是前提，只有这样的任务才有价值。
+
+总结来说，SMART有更明确、具体的目标，利于员工更加明确、高效地工作，完成与公司目标更加对齐的业绩，也为管理者实施绩效考核提供了目标和标准。网络上有很多SMART原则的相关资料，比如[SMART 原则以及实际案例](https://blog.csdn.net/limuzi13/article/details/52245983)这篇就还不错。
+
+除了SMART原则，**OKR是一个很有用的目标管理工具**。
+
+我们经常会听到领导者（Leader）和管理者（Manager）这两个概念，但你有注意过它们的区别吗？两者经常混用，但实际上有一个本质区别：领导者告诉团队需要去哪里，而管理者告诉团队如何去到那里。
+
+在我看来，**每一个管理者都应该努力成为一个领导者**，给团队目标，让团队成员自己找到达成目标的方法。而，OKR正是帮助管理者做到这一点的工具。
+
+其中，O表示目标，是鼓舞人心的目标，可以使每个人保持一致和受到启发；KR则表示关键结果，是达成目标需要注意的度量。在Google使用后，最近几年OKR很流行，效果的确很好。OKR的内容比较多，如果你想要系统了解并在团队落地的话，推荐你阅读《[黄勇的OKR实战笔记](https://time.geekbang.org/column/intro/100030701)》这个专栏。
+
+这里，我想强调一下**用好OKR的两个关键点**。
+
+第一，使用OKR最重要的目的是，让全公司对齐目标，所以在实施OKR时，我们要随时留意这个目的。可以说，这是执行OKR最关键的原则。基于这个原则，我们可以扩展出很多实际操作。比如公司级别定义一个O，每个团队和个人根据实际情况制定自己的O和KR；所有人的OKR都透明，全公司可见，同时定时做回顾、调整和复盘。
+
+第二，OKR不是一个HR工具，不是绩效管理方法。绩效管理方法一般包括目标、度量和考核（激励 / 惩罚），与之相比，OKR只包括目标和度量，是一个目标导向工具。
+
+OKR之所以在目标对齐上有很大作用，是因为团队成员可以发挥主观能动性，自己制定与公司目标一致的KR。而一旦OKR跟绩效挂钩，团队成员承担风险的意愿和内驱力就会大大减弱，倾向于制定更容易实现的KR，从而失去了目标导向的意义。
+
+所以，OKR不要跟绩效挂钩。那么问题来了，**使用OKR之后怎样进行绩效考评呢**？实际上，这也很简单，只要评估团队成员具体完成的工作对公司的贡献度即可，甚至可以OKR和KPI并存。比如，公司高层可以使用KPI，用数字衡量绩效，而全公司都使用OKR进行目标对齐。
+
+## 第三步：任务执行
+
+在具体的任务执行上，作为技术管理者，我们应该从人、流程和工具上来提高研发效能，高效达成业务目标和技术目标。
+
+### 关于人：最关键的是调动起主观意愿
+
+首先，把团队成员的利益统一起来，才会激发他们的主观能动性，自己想办法去达成目标。典型的例子是，为了消除职能竖井，采用全栈开发方式（你可以再回顾下[第8篇文章](https://time.geekbang.org/column/article/132539)中的相关内容）。
+
+**统一团队利益的主要方法是，采用康威定律来组织团队结构**，使其与产品结构相吻合，让产品的成功成为团队一致的目标。
+
+比如Facebook，针对产品和功能，一般组织10人左右大小的团队，里面包括了前后端开发者、设计师、产品经理、数据科学家等。所有人的目标，都是如何把自己团队的功能、产品做好。小团队之间松耦合，有比较高的自主权，不同团队间主要通过目标的一致性来进行协调。这种方式不但使得大家的力往一处使，而且灵活机动、出产品很快。
+
+把这种小分队的方法用到极致的是Spotify公司。他们在产品层面把各个功能模块隔绝开，某个功能出现问题，不影响其他功能正常使用。每个功能由8人左右的自主运营小组负责，称之为Squad。Squad的主管负责确认、沟通团队需要解决的问题，以及解决这些问题的意义，而团队成员的职责是自己决定如何解决这个问题，自主性非常强。
+
+另外需要注意的是，**在把组织架构和产品对应起来的时候，还有一个重要原则：DRY。**对个人开发者说，DRY是不要重复自己；而对公司或者团队来说，DRY就是要建设针对基础设施、共享业务的平台，以避免重复造轮子。
+
+以Facebook为例，Infrastructure团队（基础平台团队）人数众多，话语权大，对公司的业务发展至关重要（我之前所在的内部工具团队，就是Infrastructure团队的一部分）。各项业务之所以能够快速开发、验证、上线、迭代，并实现高可用、高并发支持上亿日活用户，都跟Infrastructure团队的工作密不可分。
+
+除了基础平台外，DRY在业务方面最主要的表现是业务中台，也是最近非常火的话题。
+
+调动人员的意愿，除了组织架构方面外，绩效管理和企业文化也很重要，我会在后面几篇文中与你详细介绍这些内容。
+
+### 关于流程：选择合适的方法论、原则、实践
+
+关于流程需要注意的是，寻找符合软件开发行业特性的方法，并根据团队情况不断优化。**具体来说，我推荐使用先从全局的端到端流程入手，寻找系统瓶颈，然后再集中精力解决瓶颈，完成一轮优化。**
+
+这样可以从全局出发，避免以偏概全，能够最高效地使用团队的人力、物力。在优化过程中，我们要尽量采用数据驱动的方式，用数据来寻找问题，并通过数据的比较来检查改良措施的有效性。
+
+针对流程的优化，你可以再回顾下[第4篇文章](https://time.geekbang.org/column/article/128867)中的相关内容；而关于效能度量，你可以再回顾下第[2](https://time.geekbang.org/column/article/126447)和第[3](https://time.geekbang.org/column/article/128151)篇文章中的相关内容。
+
+另外，要提高团队的研发效能，作为团队技术负责人，需要保持技术判断力，包括技术选型的能力以及方法论的选择能力。你可以参考我在前三个模块中，给出的流程优化、团队工程实践及个人工程实践的一些高效方法论和实践。
+
+### 关于工具：根据实践进行选择
+
+完成了人、流程的工作之后，工具的选择就比较容易了：让团队**根据方法论选择适用的工具即可**。在前面的文章中，我对各个方法论的适用工具都做过详细介绍，你可以再回顾下相关内容。
+
+这里，我再给出**团队选用工具的两个原则**吧。
+
+第一个原则是，选择工具时要根据场景的复杂程度选择自建还是使用第三方服务/工具。对简单、单一场景，我推荐使用开源工具；而对复杂的系统和流程，可以考虑使用一些付费工具，比如SaaS产品，因为术业有专攻，这样比自建工具性价比更高。
+
+通常情况下，针对小型创业公司，很多SaaS产品的价格不算太高，有些甚至免费。作为技术管理者，我们要考虑投入产出比，让开发人员把时间花在业务上可能才最合适。在硅谷，小公司使用付费软件服务的现象也很普遍，国内公司也慢慢有这个趋势了。
+
+第二个原则是，工具虽然重要，但背后的方法论和原则更重要。比如OKR，如果使用得当，使用一套简单的wiki系统就可以做起来；但如果概念不清、原则不对的话，即使引入专门的OKR工具效果也不会好。所以，作为技术管理者，我们一定要花时间了解工具背后的原则。
+
+## 小结
+
+今天，我通过寻找目标、目标管理，以及如何执行这三步与你介绍了一些管理方法。
+
+首先，最重要的一点是，技术管理者需要同时关注业务目标和技术目标。只有这样，才能够让团队持续发展。如果今天这篇文章你只能记住一个观点的话，我希望是“业务目标和技术目标两手抓”。
+
+在目标管理方面，OKR是帮助团队对齐方向的不错工具。不过，我们使用OKR时一定注意，目的是对齐目标，与绩效挂钩的效果会大打折扣。
+
+在具体的任务执行方面，从人、流程、工具三个方面入手，即想办法调动人的主观能动性，从流程全局入手把时间花在最需要优化的地方，以及根据具体方法论和场景复杂度选择工具。
+
+最后，我觉得每一个技术人员，都应该花些时间去了解管理，原因包括两点：
+
+- 对公司、团队的管理措施有更清晰的理解，可以帮助我们更高效的、有的放矢的工作；
+- 管理是职业发展的一个方向，了解一些管理可以帮你尽早弄清楚这条路是否适合自己。
+
+## 思考题
+
+Facebook提前预测并解决Git性能问题的例子中，我们最后使用Mercurial代替了Git。你知道这其中的原因是什么吗？
+
+感谢你的收听，欢迎你在评论区给我留言分享你的观点，也欢迎你把这篇文章分享给更多的朋友一起阅读。我们下期再见！
+
+

极客时间专栏/研发效率破局之道/管理和文化/32 | 从Netflix公开的著名PPT谈硅谷公司文化.md

@@ -0,0 +1,142 @@
+<audio id="audio" title="32 | 从Netflix公开的著名PPT谈硅谷公司文化" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/df/d5/df56fff7b35d0207eb612ba241d456d5.mp3"></audio>
+
+你好，我是葛俊。今天，我分享的主题是如何从公司文化的维度提高研发效能。
+
+首先，什么是文化？定义很简单：
+
+> 
+文化是决定一群人行为方式的共同认知、价值观和信念。
+
+
+对于一个公司或者团队来说，文化就是决定其团队成员行动的基本价值观。文化决定行动，它的价值自然巨大。可以说，**一个团队能否高效产出，文化起到关键作用**。所以，硅谷的很多公司都特别重视公司文化。
+
+比如，SpotIfy对公司文化的态度就是，“如果远见是你想实现的目标，那么文化就是确保你能够实现这个目标的根本（If vision is where you are going, culture is what makes sure you can get there）”。再比如，工程师文化，正是Facebook这些年来的创造力引擎。
+
+最近几年，国内公司也越来越重视文化建设了。比如，阿里巴巴的面试官有一个角色是“闻味官”，考察候选人是否和公司文化对味儿；再比如，有很多公司把核心价值观以红底黑字的形式做成条幅，挂在了墙上。但事实上，能够真正理解文化，并推行下去的公司却很少。
+
+这里，**我首先要和你厘清的是，文化更像是潜规则，写到横幅上的标语并不一定是公司文化；文化的建设，更是技术活和力气活的合体，绝不是喊几句口号就可以完成的。**
+
+比如，美国2001年爆发的安然丑闻案，就是因为许多高级职员参与了销毁、篡改、编造财会记录的行为，欺骗了股东，导致了这一起美国历史上最大的破产案，给股东造成了超过600亿美元的损失。而“诚信”正是安然公司价值观的第一条，被凿刻在大理石上，装潢精美地放置在公司一楼的大厅。所以说，“墙上的价值观”真正地践行起来，才能形成公司文化。
+
+那么，**了解公司文化，到底对我有什么帮助呢？**
+
+在我来看，如果你是管理者，或有志成为管理者，关于公司文化的讨论能够帮助你设计并实施适合自己团队的文化。而如果你现在还不是管理者，了解公司文化对你会有两方面的帮助：一是，可以帮助你推动团队进步，提高自己对团队的价值；二是，衡量团队文化是否适合自己，因为这是衡量是否要加入一个新团队或公司的重要考量因素。
+
+接下来，我们看看**到底如何推进好的文化在公司和团队落地。**从硅谷的成功案例来看，推行文化主要包括三步：
+
+1. 定义出自己团队需要的文化；
+1. 从招聘、流程设计方案推动文化；
+1. 持续地用行动去推动，并总结提高。
+
+接下来，我就以奈飞（Netflix）为例，与你详细探讨这三个步骤。之所以用奈飞做例子，是因为这个公司在推行公司文化方面做得非常彻底，并且他们对外公开的关于文化讨论的资料也比较多。
+
+2004年，奈飞发表了一篇关于公司文化的PPT，叫作“[自由和责任](https://www.slideshare.net/reed2001/culture-1798664)”，详细阐述了他们的公司文化及背后的思考。这个PPT非常不错，Facebook的COO 雪莉 · 桑德伯格（Sheryl Sandberg）曾经说，它是硅谷产出的文章里最重要的一篇，没有之一。
+
+需要说明的是，这篇文章中我也参考了“自由和责任”这个PPT中的部分素材。通过对奈飞关于公司文化的经验介绍，我希望你了解怎样定义文化，以及更重要的是怎样落地文化来提高研发效能。
+
+## 定义出自己需要的文化
+
+从公司文化的维度提高研发效能，第一步就是要定义出你需要的文化。而文化比较抽象，所以**常见的定义文化的方式就是定义核心价值观**。因为价值观是团队成员做事儿的潜规则，是文化的具体体现。
+
+**而定义价值观，需要根据公司的发展，确定要追求的最重要方向。**一般来说，公司的价值观定义包括四个方面的追求：产品快速上线、产品的有效性、客户满意度、员工满意度。但每个公司都要根据实际情况，来定义这些目标，不能简单地复制其他公司的成功经验。
+
+比如，美国有相当一部分互联网公司推崇创新，它们的价值观是在任何地方、任何时候都要尽量保持创新。但如果是一家ToB或者与金融相关的公司，那么简单地引入这样的创新文化，肯定会让你的客户不高兴，因为这样的公司往往更重视安全和低风险。
+
+从结果来看，奈飞的价值定义精准，对公司业务成功非常有效。所以接下来，我们就一起看看奈飞是怎样定义自己价值的吧，相信他们定义价值的思路对你也会有参考价值。
+
+1997年，奈飞成立并进入DVD租赁市场。当时，市场竞争已经非常激烈，除了几个很成功的线下连锁店（比如，BlockBuster、Hollywood Video、Movie Gallery）外，沃尔玛等巨头也开始加入。在这种情况下，**奈飞仔细思考，制定了追求高效能/绩效和创新的核心价值观。**因为只有这样才能杀出重围。
+
+基于这两条基本价值，他们细化了判断力、创新、好奇心、沟通等十条核心价值观。你可以在奈飞官网看到每一条[价值观的详细解读](https://jobs.netflix.com/culture)。
+
+你可能会说，这些价值观都很常见，并没什么稀奇的啊。确实是这样，但奈飞最牛的地方是他们做到了。
+
+以创新为例，奈飞在刚成立时，将小众电影作为了一个突破点。因为线下连锁店通常只关注当前票房较好，以及历史上比较流行的电影，于是小众电影很难找到就成为一些电影爱好者的痛点。这是奈飞得以生存下来的一个重要战略。所以说，创新这条价值观的确帮助他们在红海中杀出了一条血路。
+
+定义出了自己需要的价值，更重要的是落地。那到底怎样去推动这些价值落地呢？
+
+## 从招聘、流程方面设计方案推动文化
+
+仅仅提出价值观是没用的，必须认真分析，找到合适的方法落实到招聘、流程、组织结构上。接下来，我们看看奈飞是怎样操作的吧。
+
+他们关于创新的分析思路是这样的：一个小公司，在刚创立的时候，效能和创造性都很好，属于创新者。但随着公司规模逐渐变大，复杂度也随之变大，进而导致混乱，比如信息沟通不畅导致最终产品与用户需求差别很大。为控制混乱，公司就会引入流程和规则，但副作用可能是导致一流人才的流失，以及降低现有人才的生产效率和积极性。所以，很多公司壮大后，常常会败于新的创新者发起的挑战。
+
+那怎么解决这个问题呢？
+
+奈飞认为，**在公司规模变大时，不应该引入规则，而是应该引入更多人才来控制混乱。**只要招收到优秀的、负责任的人，并给与他们自由发挥的空间，他们就能够灵活高效地解决公司在成长过程中遇到的各种复杂问题。因此，**只要引入人才的速度超过复杂度的增长速度，就可以让公司在成长的同时，持续保持高效能和创新能力。这就是他们的基本思路。**
+
+基于这个思路，在HR方面，他们采用高薪招聘、奖励人才，而对不合适的人容忍度则很低。基本思路就是：一个员工如果称职，就用高于市场平均水平的薪酬去招聘或留住TA；一个员工如果不称职，就尽快解聘。
+
+在具体操作上，他们使用了很多非常直接和非常规的方法。比如，取消每年定时的绩效考评，而是在平时实时考评。绩效考评结果只有合格与不合格两种，评判依据是员工能否胜任当前工作，并不太考虑过往表现：
+
+- 对于绩效考评不合格的员工，没有其他大公司常用的PIP计划（绩效提高计划），而是直接用丰厚的遣散费解雇；
+- 而对于绩效考评合格的人，也不是按照每年一定的百分比提升工资，而是根据市场价进行调节。
+
+也就是说，在绩效考评合格的前提下，不管你的表现怎样，你的薪资都会根据市场平均水平来调高或者降低，但肯定会高于市场平均水平以保证你愿意留下来。
+
+另外，他们也没有年终奖。是不是觉得很不一样呀？反正我第一次听说这些政策时，非常震惊。
+
+奈飞认为，通过这些举措，能够保证任何时候，只有合格的人才能留下来，并且因为高薪，他们愿意留下来；另外他们能够接受这些特别客观的评定标准，所以是理性的“成人员工”。总结来说就是，这些措施能够确保员工有能力，并且负责。
+
+有了这些有能力并且负责的人才后，**在流程方面，奈飞就可以对员工进行松散、基于信任的管理了**。
+
+比如，奈飞是硅谷很早就使用假期无限制政策的公司之一，这也很好地体现了他们的思路。
+
+在上市之前，奈飞有10天带薪假、10天节日假期，以及几天病假的一个准正式系统。说它是准正式，是因为没有正式的跟踪系统，是让员工自己统计已经使用了的假期，并告知主管什么时候他们请假了即可。这个系统本来运行得挺好，但在上市时，审计程序要求有正式的系统统计员工放假时间。
+
+这时，常规方法是引入一个这样的正式系统。不过，CEO里德 · 哈斯廷斯（Reed Hastings）了解到，如果员工没有假期的话，那没有这样一个假期管理系统也能通过审计。所以，为了节省精力、资金，他们干脆决定不引入正式的假期统计系统，而是由员工自己决定什么时候放假，以及休多长的假。公司只是提供一些指引，比如财务人员应尽量避免在工作特别忙的时候请假；再比如，连续请假超过30天，需要向HR说明原因等。
+
+因为，他信任员工能基于公司利益做选择。既然绝大部分员工都能自觉，何必让他们花额外的时间来处理流程问题呢？至于极少数不自觉的员工，只能说招聘时看走眼了，尽快解雇就是。
+
+## 持续地用行动去推动，并总结提高
+
+文化是一种潜规则，行动才能真正表现出文化。所以，**推动文化建设的第一点，就是坚持去做。**
+
+团队的领导者，一定要以身作则。比如，奈飞采用了灵活的无限制假期的政策，那你有没有想到可能存在的一个问题，如果团队的其他成员都没有休假，只有我休假了，会不会影响我的绩效呢？所以，奈飞要求比较高层的领导，每年必须要休一定时长的假期，并且要向团队成员公布他的假期日程，来避免这个问题。
+
+**推动文化建设的第二点，是明确提出价值观**。虽然说文化是潜规则，但推广文化还是需要把这些文化强调的价值明确地提出来，并尽可能多地和员工沟通，使他们对公司的价值观更加明确。所以，奈飞一直很强调他们的文化，甚至还将其总结成PPT对外公布。类似的，Facebook也很强调文化，甚至有海报文化，到处都贴满标语。在后面几篇文章中，我也会和你介绍Facebook关于文化的很多实践。
+
+**推动文化建设的第三点，是注意文化的演进。**为了适应并跟随社会的发展变化，公司文化也不应该一成不变。所以，我们在建设公司文化时，也要时常回过头来看看，公司现在的文化和价值观是否还适合当前情况。
+
+## 关于奈飞文化的思考
+
+最后，我想再和你分享一个奈飞的小案例，希望你借由他们在推广文化上的操作和得失，可以对公司文化建设有更深刻的理解。
+
+首先，**我想说的是奈飞在文化执行上非常坚决彻底**。这一点在“自由和责任”这个PPT的作者帕蒂 · 麦科德（Patty McCord）身上得到了很好的体现。
+
+帕蒂是制定这些政策的核心成员，在公司文化建设上功勋卓著，却在2012年因为跟不上公司发展被解雇了（因为奈飞的绩效考评不考虑过往贡献）。当时，这个事件还掀起了一段热烈讨论，很多人认为她是自掘坟墓。不过我倒是认为，这只能说明她当年制定的策略被成功执行了，真正起到了作用。
+
+**正因为奈飞采用了很多非常规的，甚至是极端的方式去推行文化，所以这些年来确实做到了持续的高效能和创造性，业绩也非常亮眼。**
+
+从2012年Patty被解雇到2018年，奈飞的股票涨了25倍，用户数达到1.37亿，覆盖190个国家。可以说，他们关于自由和责任的公司文化功不可没。
+
+但极端政策给奈飞带来成功的同时，也有很多负面作用。因为公司对低绩效员工的容忍度非常低，解雇人员的频率比较高，所以很多人认为奈飞内部存在一种恐惧文化，有些人时刻担心自己会不会突然被解雇，时常处于害怕的状态。
+
+这种状态让员工工作得并不开心，对创造性也会有很大影响。在公司满意度调查网站glassdoor.com上，奈飞的满意度只有3.7分，而Facebook、Google的满意度都在4.5分左右。2018年10月，华尔街日报发表了关于奈飞文化的文章，针对其负面影响对奈飞的政策提出了一些质疑，在互联网圈造成了不小的轰动。
+
+**其实，我个人对奈飞的文化有两点不太认同。**
+
+第一，他们超级强调透明，认为一个成熟的人可以接受任何客观的评价。比如，奈飞会对一些被解雇的员工的解雇原因进行分析，甚至出现过让他们亲自参加的情况。虽然招聘的都是“成人员工”，能够客观看待因为绩效不合格被解雇这件事，但人终究还是有感性的一面，这种极端透明的措施确实会对一部分人造成影响。
+
+第二，太强调当前表现，而不考虑过往贡献，会降低员工的归属感，进而降低创造性。相比起来，我更喜欢Facebook这样的文化。关于Facebook的文化，我会在后续文章中与你详细分析。
+
+## 小结
+
+今天，我和你分享了什么是企业文化，以及应该怎样设计、推动文化去提高公司的效能。
+
+文化是团队成员做事的潜规则，所以好的文化是高效能的基础。而要通过建设好的文化来提高研发效能，我认为主要有以下三步：
+
+1. 根据公司目标，定义核心价值观；
+1. 围绕核心价值观，制定HR、流程方面的方案；
+1. 用行动推动价值观实施，明确提出价值观来统一团队认识，注意文化的演进来保证公司文化与时俱进。
+
+在介绍建设公司文化的三步时，我与你介绍了奈飞的很多实践，希望可以帮助你找到适合自己的方式、方法。
+
+接下来的几篇文章，我会与你讨论我最熟悉的Facebook的企业文化，并分享我在其他公司引入文化的一些实践。敬请期待！
+
+## 思考题
+
+你知道还有哪个公司像奈飞这样推崇透明的文化，效果又怎样呢？
+
+感谢你的收听，欢迎你在评论区给我留言分享你的观点，也欢迎你把这篇文章分享给更多的朋友一起阅读。我们下期再见！
+
+

极客时间专栏/研发效率破局之道/管理和文化/33 | Facebook企业文化：工程师文化是创造力引擎.md

@@ -0,0 +1,114 @@
+<audio id="audio" title="33 | Facebook企业文化：工程师文化是创造力引擎" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/87/0a/87c2b76450e216e45686dc663923280a.mp3"></audio>
+
+你好，我是葛俊。今天，我来和你聊聊Facebook的工程师文化吧。
+
+在上一篇文章中，我以奈飞为例，与你介绍了公司文化建设的三部曲，即定义核心价值观、针对性地设计招聘和流程方案，以及持续推动并总结提高。
+
+除了奈飞的“自由与责任”外，我们还比较熟悉、认可的是“Facebook的工程师文化”。所以，接下来的4篇文章，我会与你详细介绍Facebook的工程师文化、相关的管理实践，以及我离开Facebook后在其他公司落地的实战经验。
+
+那，我为什么要用这么多篇幅去分析Facebook的工程师文化，以及支撑这些文化的管理实践呢？原因很简单，因为我清楚地看到，工程师文化，可以极大地激发开发人员的内驱力和创造性。
+
+毫无疑问，这是一个双赢的局面：既可以为公司产生更多更有价值的产品，也可以大幅提升开发者个人的成长速度和幸福感。但相比之下，国内的很多公司在这方面有所欠缺，团队成员大都处于简单执行的状态，内驱力和创造性远没有激发出来。
+
+所以，通过接下来的4篇文章，我希望帮你深入理解工程师文化的Why、How和What，为管理者设计、实现团队文化提供示范和借鉴，为个人参与文化建设和选择团队提供参考，进而提升团队的研发效能，以及个人的能力和幸福感！
+
+我们先来看看工程师文化是什么吧。
+
+## Facebook的工程师文化，到底是什么？
+
+通过上一篇文章，我们知道“文化是决定一群人行为方式的共同认知、价值观和信念”。那，什么是工程师文化呢？
+
+工程师文化本意是，工程师群体行为方式的共同认知、价值观和信念。对工程师来说，我们的行为包括开发软件、解决问题、与客户打交道、与团队合作等。本来工程师团队的做事方式可能千差万别，但后来“工程师文化”逐渐演化成了“用正确的工程方法、思路来完成工作的文化”。
+
+那，Facebook的工程师文化又是什么呢？**一句话总结就是“黑客之道（The Hacker Way）”。**
+
+听到这里，你可能会说，黑客不是一个贬义词吗？事实上，黑客在程序员界本是一个褒义词，指的是动手能力极强的程序员，他们创造、实验、打破常规，可以让计算机做任何他想做的事儿，即使计算机本身不同意。
+
+但现在，黑客却和入侵电脑系统为非作歹的罪犯画上了等号。这个误解极深，以至于业界大神保罗 · 格雷厄姆（Paul Graham）专门写了一篇文章“[The Word ‘Hacker’](http://www.paulgraham.com/gba.html)”来澄清。
+
+那，为什么Facebook要把“黑客之道”作为自己的企业文化呢？
+
+Facebook的企业使命在2017年7月有过一次演化，不过总的来说，就是提高传播和消费信息的方式，把世界更好地连接起来。这样的社交网络系统规模庞大，有着很多前所未有的分布式、高并发等挑战。同时，也因为第一次把社交映射到网路上，有无限的创新可能。所以建造这样的系统需要优秀人才不断创新，打破常规。
+
+扎克伯格和Facebook的其他管理层认为，黑客做事的方式，很适合公司快速发展，不断进步、创新，能支撑公司实现使命。所以，Facebook一直把黑客之道设置为最根本的工程师文化，并且在全公司推广。
+
+2012年Facebook上市时，[扎克伯格发表公开信](https://www.wired.com/2012/02/zuck-letter/)，给出了黑客的4个特质。按照我的理解，我再和你分享下这4个特质。
+
+- **优化无止境**：黑客认为优化无止境，产品无完美。在大部分人认为服务已经无法改善，或者是满足现状的时候，会直接上手进行进一步的优化。
+- **持续进步**：黑客不追求一蹴而就，一劳永逸。他们更喜欢迅速发布小规模更新，并从中吸取经验教训，通过长久努力不断进步。
+- **代码为王**：黑客更在意代码实现。代码胜于雄辩，只有真正实现了的东西才有价值。
+- **能力为王**：黑客有极度开放和精英为王的心态，不会因为谁的头衔高而默认其权威。相比之下，黑客更看重的是技术，以及把想法变为产品的能力，说白了就是谁行谁上。
+
+针对这些特质和企业使命，Facebook又总结了五条核心价值观，分别是：专注于影响力（Focus on Impact）、迅速行动（Move Fast）、勇往直前（Be Bold）、保持开放（Be Open）和创造社会价值（Build Social Value）。
+
+接下来，我们就具体看看Facebook是怎样推行黑客文化的吧。
+
+## Facebook工程师文化的具体实践
+
+与奈飞推动企业文化建设一致，Facebook也采取了一系列措施有效地推行其工程师文化落地，包括重视工程师文化的宣传，以及从流程、工具方面推动文化落地。接下来，我们就具体看看吧。
+
+**第一，非常重视工程师文化的宣传。**
+
+Facebook一直有一个很大的“The Hacker Company”的标牌，几次搬家都被放到最显眼的地方。扎克伯格在上市的公开信中也详细讨论了公司的工程师文化。
+
+此外，他们的海报文化也非常有名。进入园区，你会发现Facebook的一大特色，有很多写着各种各样标语的海报，比如“The Journey is 1% Done（我们的旅程只完成了1%）”“Open the Door（敞开大门）”“Done is Better Than Perfect（完成比完美更重要）”“Focus on Impact（专注于影响力）”“Move Fast and Break Things（快速行动，打破陈规）”等。我最喜欢的是一句中文粤语的，“出来行，最紧要勇”，是勇往直前的意思。
+
+很明显，这些标语与Facebook的工程师文化和核心价值观紧密相关。Facebook的COO雪莉 · 桑德伯格（Sheryl Sandberg）在[一次访谈中](https://techcrunch.com/2012/01/19/sheryl-sandberg-valley-girl/)谈到这些海报时说，公司的文化正体现在这些海报中。
+
+虽然这些标语看似在打鸡血，但在Facebook工作过后你就会理解，公司的确是在践行这些工程师文化，而且为公司发展和个人成长带来了巨大好处。所以，这些标语很多都是开发者自己打印了贴到墙上的。
+
+**第二，从流程、工具方面推动这些文化。**
+
+关于如何从流程、工具等维度推动工程师文化落地，我会边和你列举Facebook的具体实践，边与你分析这与公司文化落地的关系。
+
+接下来，我们就具体看几个关于黑客特质以及公司价值观的实践吧。
+
+在**能力为王**方面，扎克伯格没有独立办公室，工位和我的一样普通。当然，他有一个私人会议室。另外，员工互相看不到对方的职级，所以讨论技术问题时，不会因为级别而束手束脚。
+
+在**持续进步**方面，公司搭建了强大的实验框架、功能开关，无论何时都可以测试上千个不同版本的Facebook服务，给开发人员创造能够迅速行动、快速迭代的环境。另外，公司的容错文化落到了实处。只要不是故意的，首次犯错都不会影响绩效。当然同样类型的错误重犯会有惩罚措施，另外有一些隐私、安全相关的红线也不能触碰。
+
+在**代码为王**方面，所有新员工入职时都被要求参加一个长达6周的培训，叫Bootcamp。这6周的时间，无论你是多高级别的管理者，都要学习公司的代码库、工具和方法，并实际编码完成任务。业内有许多工程师团队的管理者，并不愿亲自动手编写代码，这在Facebook是行不通的。因为，Facebook更看重的是实践型人才。
+
+在**专注影响力**方面，Facebook有一个定期举办的Hackathon（黑客马拉松）活动，让我们依照自己的创意开发原型产品，然后在公司范围内进行演示。这，就给了我们一个发挥想象力和能力来产生价值的机会。Facebook最成功的产品有些就来自Hackathon，包括时间线(Timeline)、聊天、视频、点赞按钮等。
+
+这样的流程、实践体现在公司的各个方面，不一而足。我在这里只是简单列举了些具体实践，详细、系统的分析会在后面的三篇文章中。
+
+那么，**这些文化的效果怎样呢？**
+
+从公司的长期快速发展和业界口碑来看，这些文化的效果显而易见，我就不再赘述了。这里，我就站在一名普通开发者的角度，来和你聊聊Facebook工程师文化对个人成长的效果吧。
+
+## Facebook工程师文化的效果
+
+Facebook的工程师文化鼓励优化无止境、持续进步、代码为王、能力为王，也着实体现在工作的方方面面。这些都是强大的技术人员的重要特质，对个人技术成长和创造产品帮助非常大。而在Facebook工作几年后，你的做事方式自然而然会往这些方向靠拢，可以说是润物细无声。
+
+比如，Move Fast and Break Things，是Facebook最有名的一句文化口号，也是对我影响最大的一句。
+
+2010年，我离开微软加入Facebook时，比较习惯瀑布式开发，非常谨慎，体会不到这句口号的精髓。入职后大概两个月，我从Bootcamp毕业加入了Phabricator团队。当时，有一个任务是查看MySQL数据库中开发人员的信息，我希望找到只读模式，来保证不会把数据库搞坏。
+
+但因为我对公司的MySQL命令行工具不是很熟悉，就去问别人只读选项在哪里。他对我的问题很惊讶，了解到我的担忧后，他说“你小心一点不就行了吗”。可我还是不放心，自己花时间找到了只读模式的命令。但事实证明，在Facebook四年多的时间，我从没有误操作过MySQL，花在寻找只读命令上的时间，属于浪费。
+
+这件事儿对我的职业成长影响很大。我逐渐体会到**Move Fast and Break Things的一层意思就是，要尽量快地去做事儿，不要担心搞砸，跟“Fail Harder”类似。**后来，我愈发适应这种方式，对公司的贡献也大了很多。
+
+比如，我在负责Phabricator时，带领两个人共同支撑了公司所有开发人员的代码审查、代码浏览工具，以及Phabricator和公司其他工具的集成、与开源社区的合作。说实话，我以前从没有接触过类似的工作内容，正是“Move Fast and Break Things”这种工作方式，让我能够快速行动、快速迭代、持续学习，最终顺利完成各项任务。
+
+当时，我们三个人就支撑起了几千名开发者使用的一个核心开发工具，其中涉及了开发、测试、运维，效率之高可见一斑。这，正是工程师文化为我们带来的个人能力成长，和整个公司研发效能的提高。
+
+## 小结
+
+Facebook的工程师文化，简单来说就是黑客之道，指的是能够打破常规，突破界限，完成任务的做事方式，其特质可以概括为优化无止境、持续进步、代码为王、能力为王。
+
+正是这些特质，帮助Facebook迅速发展业务、实现创新，从而达成公司愿景。所以，Facebook一直在文化宣传、流程和工具等方面推动其落地，效果确实非常好，实现了公司成功和个人成长的双赢。
+
+我很感激在Facebook的这段经历，不断突破极限的黑客精神对我影响非常大。
+
+在工作和生活中，我们都会面对一套现有的规则，告诉我们要做什么不要做什么，并认为我们感知到的这套规则就是事实真相。但其实，这套规则背后隐藏的另一套规则才是真正的规则。
+
+认识到这一点，我们就能突破现有规则，以非常规的方式去完成一件事儿，也就是我们所说的创造奇迹。而黑客精神，正是突破感知规则，寻找真实规则的精神。
+
+## 思考题
+
+在MySQL的案例中，“要尽量快地去做事儿，不要担心搞砸”只是Move Fast and Break Things 的一种理解。你知道这句话更常见的一种理解是什么吗？
+
+感谢你的收听，欢迎你在评论区给我留言分享你的观点，也欢迎你把这篇文章分享给更多的朋友一起阅读。我们下期再见！
+
+

极客时间专栏/研发效率破局之道/管理和文化/34 | Facebook工程师文化实践三大支柱之一做感兴趣的事.md

@@ -0,0 +1,152 @@
+<audio id="audio" title="34 | Facebook工程师文化实践三大支柱之一做感兴趣的事" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/4f/11/4fc265ac763243eb4df124f8fc8a0311.mp3"></audio>
+
+你好，我是葛俊。今天，我来和你继续聊Facebook的工程师文化及相关管理实践。
+
+在上一篇文章中，我与你详细介绍了Facebook工程师文化的核心：黑客之道，并给出了一些落地实践。从这些实践中，我们可以体会到，这种工程师文化推行得非常成功，已经融入了Facebook的血液中。
+
+也正因为如此，Facebook的工程师文化大大激发了员工的创造性、生产力和凝聚力，对整体的研发高效能和良好的个人成长环境起到了关键作用。
+
+与工程实践等方法论一样，知道好的实践还远远不够，我们更需要弄清楚的是，这些实践背后的原则，才能把它应用到自己的公司和团队。
+
+所以，在接下来的三篇文章中，我会与你系统分析Facebook是如何真正落地工程师文化的。同时，我会结合我在其他公司、团队推行工程师文化的实战经验，与你分析落地工程师文化的切入点，以及需要注意的问题。
+
+我希望这样的讲述思路，能够帮你更深入地理解这些实践和原则，将工程师文化更顺畅地引入自己的团队，提高研发效能。
+
+## Facebook工程师文化落地的三大支柱
+
+在讨论Facebook工程师文化实践落地的how之前，我们先看看why吧。
+
+我们首先需要明确的是：归根结底，**推行工程师文化的目的是，提高开发人员的积极性和创造性，从而更高效地进行软件生产，在竞争中取胜**。而要最大化地激发开发人员的自我驱动能力，根本出发点是，开发者这个群体的特性。
+
+**每一名开发者首先都是知识工作者**。管理学大师彼得 · 德鲁克（Peter Drucker）在《卓有成效的管理者》中说：“我们无法对知识工作者进行严密和细致的督导，我们只能协助他们。知识工作者本人必须自己管理自己，自觉地完成任务，自觉地做出贡献，自觉地追求工作效益。”从这个角度来看，每一个知识工作者，都是管理者。
+
+也就是说，要提高开发者的效率，强管理不是办法，根本之道在于激发他们的内驱力。正因为如此，**有效激励员工的积极性，正是硅谷高效能公司文化的共同点**。
+
+那，怎样才能有效激发开发者的积极性呢？在我看来，Facebook主要关注以下三个原则：
+
+- 让员工做感兴趣的事；
+- 让员工拥有信息和权限；
+- 用绩效调节员工和公司方向的一致性。
+
+员工能做自己喜欢的事儿，并有施展拳脚的空间，自然能最大限度地激发积极性；再加上绩效的调节，能够让团队成员的积极性与公司利益更有效的对齐，从而最大化员工积极性带来的成果。
+
+所以说，这三点就是Facebook工程师文化落地的三大支柱。
+
+接下来，我们就先看看第一个支柱，让员工做感兴趣的事儿的一些具体实践吧。
+
+## 让员工做感兴趣的事
+
+我首先要说明的是，这里的感兴趣，不只是狭义地觉得任务有意思，而是开发者对工作的整体状况感兴趣，包括项目前景、技术栈、挑战性、团队成员等。
+
+有研究证明，如果任务有意思、有挑战，同时又是加以努力就能完成的，员工的engagement和满意度就会非常高。那么，让团队成员灵活地选择岗位和转岗，就成了一个绕不开的话题。
+
+但，团队成员灵活选择岗位和转岗，在短期内会直接给公司，尤其是小团队带来负面影响。另外，如果公司比较小的话，每个人都很关键，自由转岗更难实现。
+
+接下来，我们就通过几个实践，看看Facebook是如何用好这把双刃剑的吧。Facebook让员工做感兴趣的事，包括了入职、日常工作和转岗这3个场景。
+
+其实，这3个实践，也并不是在Facebook成立之初就都有的，而是在不同的发展时期引入的。
+
+### 第一个场景：入职时
+
+在Facebook，新员工入职时都要参加Bootcamp，一方面可以帮助员工熟悉公司产品、研发流程和工具，另一方面可以帮助员工灵活选择岗位。
+
+**Bootcamp的具体操作是**：几乎所有的工程师在入职时，都没有明确会到哪一个团队工作。进入公司的前六周，新员工会先到一个特殊的区域办公，并从任务池中挑选任务工作。
+
+这个任务池中的任务，是公司各个产品团队放进来的，一般是难度不太大、优先级不太高，但又能让新员工快速了解业务的任务。新员工通过完成任务来了解产品和流程，并通过沟通了解这个产品团队的成员。
+
+在Bootcamp结束时，新员工和感兴趣的团队主管沟通，决定最后加入哪个团队，是一个双向选择的过程。不过，因为公司业务一直在扩张，很多团队都缺人，而且这些新员工的素质普遍不错，所以一般都是卖方市场，绝大部分新员工都能进入自己感兴趣的团队。
+
+让新员工选择并进入自己感兴趣的团队，可以极大提高其积极性，还可以在员工间建立关系网，提高凝聚力，长期收益非常可观。但，这个实践的弊端是，有些团队可能一直招不到合适的成员，在短期内影响产品进度。
+
+所以说，**这个实践比较适合有一定规模并发展较快的公司**，因为新员工多容易调节些。Facebook也是在2008年员工数接近1000时，才开始实施的。如果你的公司也具备这些特点，可以考虑尝试Bootcamp。
+
+如果你想了解Bootcamp更多细节的话，可以参考[这篇文章](https://www.businessinsider.com/inside-facebook-engineer-bootcamp-2016-3)。
+
+### 第二个场景：日常工作
+
+在日常工作中，提高员工工作兴趣的一个实践是Hackathon。
+
+**Hackathon有一个有趣的原则是，鼓励大家尽量不要做与日常工作直接相关的项目，而是做一些感兴趣的项目**。所以，我们在做Hackathon的时候，都是把它当作一个好玩的事儿，而不是当成任务来完成。
+
+Hackathon在开始的时候，还有一些好玩儿的仪式。组织者和参与者会敲锣打鼓，在公司里做一个游行，才正式宣布Hackathon开始。另外，Hackathon一般会在公司的餐厅进行。餐厅会被摆放些桌椅、提供些小零食，被整理得很舒适，适合三四个人的小团队讨论问题。
+
+值得一提的是，Hackathon并不会明确要求做出可落地的产品，但有趣的是，大家感兴趣的项目往往会和工作相关，所以实际上产生了很多很有价值的项目。在上一篇文章中，我也提到了，Facebook最成功的产品中有些就是来自Hackathon，除了时间线（Timeline）、聊天、视频、点赞按钮外，更典型的是Image Tagging和the Like Button(大拇指)。
+
+总结来说，Hackathon没有强制的业务目标，做不出东西也没关系，所以大家都很放松，抱着创造一个新东西的心情去做事，很爽。
+
+在落地实践方面，Hackathon不涉及转岗，所以比较容易实施。也正因为如此，国内不少公司都尝试过这条实践，也取得了不少成果。但需要注意的是，在实施时要注意些细节，否则会事倍功半。
+
+### 第三个场景：转岗
+
+在转岗上，Facebook采用的是Hackamonth，即离开当前工作岗位，去另一个团队全职工作一个月。每个员工在一个团队工作满一年后，都可以参加这个活动。
+
+跟Bootcamp类似，Hackamonth也有一个任务池。每个团队都会把一些一个月左右即可完成的、独立的项目，放入这个任务池里。有兴趣参加Hackamonth的员工，在这个池子中寻找感兴趣的任务，并跟新团队负责人确认之后，就可以和自己的主管提出参加Hackamonth的要求。
+
+接下来，你需要和主管沟通做好安排，以确保这一个月，原工作岗位上的任务有人处理。安排妥当后，你就可以进入新团队，并直接到他们的办公区工作了。
+
+Hackamonth结束后，你可以决定加入新团队还是留在原来的团队，当然前提是你想加入的团队愿意接收你。这实际上是一个通过做项目的方式来让员工和他感兴趣的团队互相了解并双向选择的过程。
+
+另外，Hackamonth还提供了更进一步的灵活性。在做Hackamonth的时候，如果你觉得这个团队不是很满意，你也可以私下接触其他团队。如果双方觉得合适的话，等Hackamonth结束后，你可以选择加入这个团队。
+
+Hackamonth对提高开发人员的工作兴趣，有两大好处：
+
+- 一是，开发人员可以比较自由地转岗，而且大概率能够找到感兴趣的项目；
+- 二是，即使最终没有转岗，也可以通过这一个月的工作转变，减少Burnout的感觉。
+
+我有一个同事在Facebook呆了五年，参加了三次Hackamonth，但每次都回到原来的组。用他的话说就是，去度一个月的假。是不是很有意思呢？
+
+但采用Hackamonth的弊端是，会直接影响原团队的工作进度，更容易对公司和团队造成短期伤害。与Bootcamp相比，Hackamonth更不适合小公司。Facebook是在2011年员工数达到几千时，才开始采用Hackamonth政策的。
+
+在Facebook，只要你在一个团队工作满一年了，即使团队主管不情愿，也没有权利阻止你去参加Hackamonth。可见，Facebook在执行Hackamonth政策上，再次果断选择了长期利益。
+
+以上就是Facebook为达成让员工做感兴趣的事这个目标，在入职时、日常工作和转岗这三个场景下的3个重要实践。
+
+接下来，我再和你分享些我在国内一家公司落地Hackthon的具体经验吧。
+
+## Hackathon落地经验
+
+当时，我所在团队的执行力非常强，但员工的自我驱动不够。考虑到对公司和团队的影响，我权衡之后决定引入Hackathon。
+
+在引入Hackathon时，我采用了和Facebook类似的方式：举行时间为周五和周六，下周一下午在团队内部进行演示和评选。
+
+这样一来，只会占用一天多一点的工作时间，大家还可以选择周日继续进行。通常情况下，大家虽不会通宵，但也会做到比较晚，并且周日还会持续。
+
+在这之前，公司其他团队也尝试过Hackathon，但效果都不太好。所以，这次的Hackathon，我制定了两大规则：
+
+- 明确要求，Hackathon的目的是Have Fun，不追求产品落地，尽量不做与工作直接相关的任务。
+- 评选结果时，由团队成员投票决定优胜者，而不是由专家或者管理层评选。
+
+对这两个原则，我的主管和人事部门是有些怀疑的，但在我的坚持下还是执行了下来。
+
+这次Hackathon下来，效果出奇得好：
+
+- 大家热情高涨，80人左右的开发团队基本可以产生12个项目；
+- 虽然没有要求项目落地，但还是产生了很多有意思、有价值、可落地的项目。
+
+比如，一次Hackathon时，3个同事做了一个卫生间管理系统：登录网页即可查看办公楼的卫生间占用情况。这个项目，既解决了大家的痛点，又很有意思，所以高票当选第1名。
+
+再比如，一次Hackathon时，几个运维同事做了一个ChatOps的项目。他们开发了一个聊天机器人放到聊天室中，在产品发布上线时，实时、自动发布部署进展，开发人员还可以直接询问聊天机器人当前的部署状态。这个项目，很大程度上解决了部署上线时团队的沟通不畅问题，所以成功落地到实际工作中。
+
+**这种形式的Hackathon，在结束后仍对团队有正向影响**：一是，团队氛围更活跃、成员间衔接更紧密了；二是，大家对技术更感兴趣，也更愿意讨论用技术实现各种项目的可能性了。
+
+总结来讲，几乎所有包含开发人员的团队都可以尝试Hackathon，但为了保证效果，需要注意些细节，尤其是上面我提到的两个规则。
+
+## 小结
+
+今天，我首先和你介绍了Facebook工程师文化落地的三大支柱：让员工做感兴趣的事、让员工拥有信息和权限，以及用绩效调节员工和公司方向的一致性。
+
+然后，在让员工做感兴趣的事方面，我从入职、日常工作和转岗三个场景，和你分享了Facebook的Bootcamp、Hackathon、Hackamonth这三个实践。这些实践，都对提高员工内驱力有非常关键的作用。
+
+在这三个实践中，Bootcamp和Hackamonth比较适合规模较大（千人左右或者以上）且发展较快的公司。如果你的公司符合这样的特点，可以考虑落地这两个实践，并根据实际情况做一些调整。比如，引入Bootcamp后，如果有一些冷门团队新员工都不愿意去，怎么办呢？一个可能的办法是，对这些职位进行定向招聘，专门寻找感兴趣的员工。
+
+而如果你的公司不具备这些特点的话，可以尝试Hackathon这个轻量级的实践。Hackathon花费的时间不多，但执行合适的话，效果会非常好。
+
+除此之外，作为技术管理者，我的建议是，在安排日常工作时可以多考虑团队成员的意向，尽量在条件允许的情况下，提高员工兴趣和任务的吻合度。
+
+## 思考题
+
+在你的公司或者团队，有什么措施让员工尽量做自己感兴趣的事吗？
+
+感谢你的收听，欢迎你在评论区给我留言分享你的观点，也欢迎你把这篇文章分享给更多的朋友一起阅读。我们下期再见！
+
+

极客时间专栏/研发效率破局之道/管理和文化/35 | Facebook工程师文化实践三大支柱之二拥有信息和权限.md

@@ -0,0 +1,149 @@
+<audio id="audio" title="35 | Facebook工程师文化实践三大支柱之二拥有信息和权限" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/55/09/550dddbc60abf84789d40bf7c03aae09.mp3"></audio>
+
+你好，我是葛俊。今天，我来和你聊聊，Facebook工程师文化的第二大支柱：拥有信息和权限。
+
+在上一篇文章中，我与你介绍了Facebook通过在入职、日常工作、转岗中的一些实践，来提高开发人员对所做工作的兴趣。有了兴趣之后，接下来就是提供空间让大家能够施展拳脚，在自己感兴趣的工作中自由发挥、充分发挥，也就是Facebook工程师文化的第二大支柱了。具体来说，第二个支柱包括让员工拥有信息和拥有权限两个子原则。
+
+在我看来，Facebook在这两个原则上的实践，对国内公司和团队有很大的参考价值。为什么这么说呢？因为**我接触到的国内公司管理都相对保守**，可以从与Facebook的具体实践对比中汲取经验，提升公司整体的研发效能。
+
+在拥有信息方面，国内公司一般过于严格。信息的不透明，会降低员工的主人翁意识，并会因为信息不通畅导致工作效率和有效性的下降。所以，在我看来，国内公司还可以在信息方面做得更透明些。
+
+在权限和信任方面，我接触到的国内公司，大都偏向于不信任的管理方法。这种方法难以让员工有主人翁的感觉，导致公司和员工互不信任。在这种情况下，又怎么期望员工能积极地为公司创造价值呢？
+
+我始终认为，国内的开发人员和硅谷的开发人员一样，都有很强的创造性，能力也没什么大的差别；只要能给他们创造好的环境，提供信息并给予信任，就可以更好地激发他们的内驱力，从而提高公司和团队的研发效能。
+
+接下来，我们就具体看看Facebook是怎么做的吧。
+
+## 让员工拥有信息
+
+作为知识工作者，拥有信息，是我们能够做出正确判断的一个必要条件。但信息的开放具有两面性，如果暴露过多的敏感信息，势必会对公司造成些负面影响。
+
+**面对这样一把双刃剑，Facebook的态度是考虑风险，但并不是一味地避免风险，而是权衡公开信息的利弊，在确保基本安全的前提下尽量实现信息透明化。**
+
+接下来，我们一起看三个具体的案例吧。
+
+### 案例1：代码的共享
+
+在Facebook，几乎所有的代码都是全员共享，开发人员可以非常方便地查看这些代码。这，跟国内很多公司的情况差别非常大。
+
+我在和很多国内公司的管理层谈到Phabricator时，对方的第一个问题通常就是如何管控代码仓的权限。比如，如何让前端开发人员看不到后端的代码，如何让后端开发人员看不到算法的代码，等等。
+
+但其实，**代码的共享可以在开发、调测时节省很多沟通成本，大幅提高效率**。比如，某个前端开发人员发现后台API返回值不符合预期，就可以自己去查看对应的代码，即使他没能自己找到问题，也可以在和后端开发人员沟通时提供有价值的信息。
+
+但如果他看不到后端代码的话，就只能直接求助于后端开发人员，一方面会浪费后端开发人员的时间（有可能这个问题前端人员就可以解决），另一方面双方的沟通效率也会因为信息不对称而大打折扣。
+
+国内公司大多对代码权限控制得非常严格，这跟国内的IP保护不力有直接关系。不过在我看来，国内的代码管理还是太过严格，甚至有些不分青红皂白就对所有代码进行严格控制的情况。这，不但会降低开发人员的工作效率，还会降低团队之间的信任。
+
+所以综合考虑，**我们应该在可能的范围内，尽量放宽对代码的管控，对于那些即使泄露出去也没有太大关系的代码，要放松管控。**这样做风险不大，但收益却可能会很大。
+
+### 案例2：看板（Dashboard）
+
+在Facebook，很多信息都会展示在公司墙上的显示屏上，包括很多业务的实时监控数据，甚至还有少量在其他公司认为比较敏感而不愿意显示给员工的信息，比如某些敏感服务的实时数据。此外，很多团队还会制作自己团队的看板去显示需要关注的信息。
+
+一些敏感数据泄露出去，的确会给公司造成些许负面影响，而且确实曾经出现过信息泄露。所以，有员工就问扎克伯格，**为什么要暴露这些信息**。
+
+扎克伯格的回答是：这些信息泄露确实会造成少量负面的影响，但这些信息可以极大地方便开发人员的日常工作，能够更好给用户提供价值，比如看板上的某一条信息可能在你做某个决策时起到关键作用，所以权衡利弊，我们决定开放这些信息。
+
+这个回答，恰恰佐证了公司认同信息对激发开发人员研发效能的巨大作用。
+
+关于信息开放，在国内比较容易落地的部分是，把可以显示的信息用看板显示出来。比如，线上服务使用情况可以拉近员工与用户的距离，让员工更直观地感受到业务的价值，从而提高工作积极性；又比如，当次发布进展的相关数据，可以让开发人员对当前进展更有掌控感，对交付更有紧迫感。
+
+**我们在落地看板展示时，需要注意两个问题：**
+
+- 一是，不要做给外人看，而是应该用来激励内部员工；
+- 二是，不要展示个人负面排名，比如Bug数，这种公开的负向激励方式，容易降低团队成员的积极性。
+
+### 案例3：使用Wiki来记录信息
+
+Facebook在公司内部大量使用Wiki来记录信息，很多对流程要求不严格的信息都用Wiki来记录，包括部分设计文档、团队成员列表、新员工入职手册、个人笔记，甚至有些团队的OKR也在上面。
+
+这样一来，我们在日常工作中遇到问题时，首先就是到内部Wiki上查找，而且一般都能找到有用的信息。这就使得绝大部分员工愿意在Wiki上添加信息，包括一些笔记、心得等。于是，形成了一个良性循环，Wiki系统的内容越来越丰富，对开发人员的帮助越来越大。
+
+但，我见到的很多国内公司，很多信息都是口口相传，或者是藏到某些文档里，需要花费大量的时间在查找信息上。
+
+在我看来，在公司内部用内部公开的Wiki来记录信息，风险比较小，而且可以大幅提升效能，所以比较容易落地。**作为管理者，我们可以考虑建立一个全公司的Wiki，并采取措施鼓励团队进行知识方面的共享。**
+
+这里的**一个技巧是**，把权限设置为默认公开，对需要进行权限控制的内容再特殊处理收紧权限。这跟默认保密，有需要再特殊处理放开权限的操作相比，看似相差不大，却是在传递支持信息开放的基本态度，效果非常不错。你也可以试试这个方法。
+
+## 让员工拥有权限
+
+在能做感兴趣的事，又拥有了信息之后，最后一条就是让员工能够拥有权限去做事儿。这里，我也与你分享三个具体的案例吧。
+
+### 案例1：对于商业软件，先购买再获取授权
+
+Facebook对商业软件的态度是，相信每个开发人员会从公司利益出发，权衡一个软件是否需要购买，如果需要可以先斩后奏。具体的案例，你可以回顾下[第1篇文章](https://time.geekbang.org/column/article/125840)中的相关内容。
+
+其实，国内有些公司也已经采用类似方式了，员工可以在一定数额下自行决定是否购买。我在跟这些公司的员工聊到这个政策时，能够明显感觉到他们的开心和对公司的认同感。
+
+一般情况下，员工不会擅自做离谱的决定去购买某一款软件，所以这个操作比较安全，你也可以试试。
+
+### 案例2：鼓励代码上的互相贡献
+
+在Facebook，除了几乎所有的代码对全员公开外，公司还鼓励开发人员互相修改和提高对方的代码。比如，前端开发人员发现后端API返回结果不符合预期时，如果他能识别出后端代码的问题，便可以去直接去修复，然后提交一个PR给后端开发人员，对方接受之后即可入库。
+
+又比如，你发现某一个产品的某一个功能有Bug，也可以直接修改，只要通过PR和测试，就可以上线。
+
+这在内部工具方面尤其明显，也是Facebook的内部工具超级强大的一个重要原因。因为内部工具代码上线的风险比较小，所以很多人在看到工具的问题时，会上手去进行提高，甚至自己开发一些新工具。
+
+一个具体的例子是，Phabricator在开源之前，很多功能和改进都是非内部工具团队的开发者贡献的（你可以再回顾下[第15篇文章](https://time.geekbang.org/column/article/140657)中的相关内容）。
+
+如果你要落地这个实践的话，我有两个建议：
+
+- 一是，先从风险小的代码试点，鼓励互相贡献；
+- 二是，对这种非本职却对公司有贡献的工作，应该体现在绩效考评中。
+
+### 案例3：提供宽松的容错环境
+
+Facebook对待事故的态度是，更关注吸取经验教训，以及将来如何预防，而不是追责。这样的容错环境，能够让开发人员放开手脚，最大限度地释放自己的创造力和潜能，保证公司的持续快速发展。
+
+在[第33篇文章](https://time.geekbang.org/column/article/162869)中，我提到在持续进步方面，Facebook提供的宽松容错环境，只要不是故意犯错或者重复犯相同的错，一般不会被追责。Move Fast and Break Things，就是一个有力的证明。
+
+我刚进入Facebook时，曾见过一个事故：有一个开发人员错误操作，把公司最大的SVN代码仓给搞挂了；公司找来两个SVN专家，花了一天半的时间才把整个代码仓恢复。这给公司造成了很大损失，但这个开发人员并没有因此被裁掉。还有些人因为误操作造成线上事故，影响了Facebook网站的功能，但只要不是故意犯错或者重复相同的错，也基本不会被追责。
+
+如果你想落地宽松的容错环境这个实践的话，我推荐你尝试Facebook的SEV复盘。我在国内公司实践过SEV，效果不错。
+
+你可以再回顾下[第4](https://time.geekbang.org/column/article/128867)和[第20](https://time.geekbang.org/column/article/144364)篇文章中关于SEV的相关内容，以及出现问题之后，到底应不应该追责、应该怎样追责的问题。
+
+“软件先购买再获取授权”“鼓励代码上的互相贡献”，以及“容错文化”三个实践，我都在国内一个50开发人员左右的创业公司引入过，效果都还不错。引入时，注意些上面提到的问题就可以了。
+
+## Facebook之外的落地经验
+
+接下来，我再与你分享两个，我在其他公司采取的让团队成员拥有信息和权限的实践吧。
+
+### 案例1：促进信息上下流通的实践
+
+在Facebook，每周五都会举办一个内部的Q&amp;A，员工可以通过现场或者线上提问的方式，问扎克伯格以及高管们任何问题。扎克伯格和其他高管都非常坦诚，尽量把可以公开的信息都坦诚相告，对公司信息上下流通的效果非常好。
+
+离开Facebook之后，我在一个团队内，采用类似Facebook的方式进行了Q&amp;A，使用尽量坦诚的、开放的问答形式，不说套话。这个团队的特点是，执行力很强，但氛围有些沉闷。在坚持了两三次Q&amp;A之后，气氛逐渐活跃，大家逐步敢问一些敏感的问题了。
+
+事实证明，开发人员的思维非常活跃，也都很喜欢用活跃的方式进行沟通，以获取到更多的信息。这样做的好处是，加强了员工对公司、对团队的主人翁的精神，进而提高整体的研发效能。
+
+**落实Q&amp;A还有一个小窍门**是，大家可以用匿名写纸条的方式去提问。这个方法，在国内效果更好，很多人更愿意用这种方式去问一些敏感的问题。
+
+### 案例2：信息共享的相关实践
+
+这个实践是，我在一个创业公司，采用Wiki的方式来推动全公司范围内的信息共享，内容权限默认设置为公开，只有特殊情况才可以设置为只对某些人公开。
+
+落地这个实践，的确是一个长期的过程。我见到，国内很多开发人员，都不太习惯做分享，所以**我推行Wiki时的两个方法，是坚持和以身作则。**
+
+在推广Wiki的第一个月，90%的新内容都是我写的！后来，大家逐渐看到了这种信息共享的好处，也看到了我的坚持，就开始主动向Wiki中增加内容。半年后，我的贡献降到了10%。
+
+## 小结
+
+今天，我与你分享了Facebook工程师文化落地实践的第二大原则，让员工拥有信息和权限。
+
+因为软件开发，是知识性工作，所以拥有信息是高效开发的前提。Facebook在这方面的实践，包括代码共享、看板和公司范围内公开的Wiki等。
+
+而让员工拥有权限和信任，可以让员工以主人翁的感受去施展拳脚，最大限度地激发其内驱力。这方面，Facebook的实践包括，信任员工进行一定额度下的软件自行采购、鼓励互相贡献代码，以及建设宽松的容错环境等。
+
+从我个人在国内推行文化的实践经验来看，国内大多数软件公司，是适合让员工拥有更多的信息和权限的。而且我也看到，国内越来越多的公司意识到了这一点，在逐渐放开信息和权限，从而提高员工的内驱力和团队的研发效能。
+
+我相信，我们会逐步找到更合适自己环境的平衡点，打造高研发效能的公司。
+
+## 思考题
+
+信息开放的确会导致信息泄露。今年10月份，Facebook出现了一次Q&amp;A被录音并泄露的事件，你知道扎克伯格是怎么处理的吗？你还能想到更好的处理方式吗？
+
+感谢你的收听，欢迎你在评论区给我留言分享你的观点，也欢迎你把这篇文章分享给更多的朋友一起阅读。我们下期再见！
+
+

极客时间专栏/研发效率破局之道/管理和文化/36 | Facebook工程师文化实践三大支柱之三绩效调节.md

@@ -0,0 +1,149 @@
+<audio id="audio" title="36 | Facebook工程师文化实践三大支柱之三绩效调节" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/cf/2f/cf7ec778d0b8bf2518d69a4970a57f2f.mp3"></audio>
+
+你好，我是葛俊。今天，我来和你聊聊，Facebook工程师文化的第三大支柱：绩效调节。
+
+在前面两篇文章中，我与你详细介绍了Facebook如何通过让员工做感兴趣的事，以及让员工拥有信息和权限，来很好地激发员工的内驱力。但归根结底，工程师文化是为公司的业务发展而服务的。
+
+那么，当员工的工作积极性被充分调动起来之后，Facebook是怎样让员工的工作方向与公司的发展方向对齐的呢？这把利器就是绩效调节。今天，我们就具体看看Facebook是如何做绩效调节的吧。
+
+绩效管理是一个很大的话题，其中Facebook帮助员工调节方向的管理方法主要包括两个：
+
+- 一个持续反馈的方式，也就是说主管要随时给员工反馈，帮助其调节工作的方向和方式。
+- 一套360度绩效考评系统进行每年两次的总结性绩效考评。
+
+**关于持续反馈，一般是在一对一（1-on-1）沟通中给反馈**。一对一沟通是硅谷软件公司常见的一种管理沟通方法，一般每周一次每次半小时，固定时间，由主管和下级，或者和下级的下级做一对一沟通。
+
+这个会议的主要作用是，从下往上的信息收集和从上往下的信息传递，是与员工沟通近期工作中值得肯定或需要调整内容的一个非常好的渠道。如果你想详细了解一对一沟通，可以参考“[浅析一对一沟通](https://www.infoq.cn/article/analysis-of-one-to-one-communication)”这篇文章。
+
+比如，我在[第13篇文章](https://time.geekbang.org/column/article/138389)中提到，开始时我在代码审查上做得不太好，主管就及时在一对一沟通中指了出来，让我能够迅速调整方向。
+
+而360度绩效考评系统，对帮助员工对齐方向起到了关键作用。今天这篇文章，我就与你具体说说它的原则、问题以及落地实践吧。
+
+**360度绩效考评系统的核心是，通过收集同事间的反馈，来评价员工对公司的贡献。**整个过程尽量关注公司的整体利益而不是小团队的局部利益，尽量做到收集客观具体的实例来评估贡献，而不是简单收集客观数字。整体来讲，这个方法可以比较客观、公正地评价员工对公司的贡献。
+
+相比起来，国内的绩效管理政策，真正使用同事间反馈的很少，更多的是主管的评价。这种方式的好处是，容易产生强执行力，但缺点是容易出现维上、内斗的情况，从而引发较多内耗。
+
+所以，通过介绍Facebook这一套不太一样的绩效管理系统，我希望能给你提供一个新的视角，从一些新的角度考虑如何更好地使用绩效考评这个工具，来提高团队的研发效能。
+
+首先，我们来看看Facebook的360度绩效考评系统具体是怎样的吧。
+
+## 360度绩效考评系统
+
+Facebook的360度绩效考评系统，因为要通过收集同事间的反馈，来评价员工对公司的贡献。所以，请谁来评价你的工作、评价内容是什么、如何定结果，以及如何应用结果就是4个关键问题。
+
+### 由谁给你写评价？
+
+这套考评系统之所以称作是360度，就是因为反馈来源的覆盖面广，尽量收集每一个能够评价被考评对象贡献度的同事的反馈。这些同事具体包括：
+
+- 被考评对象自选1~2个同事写评价；
+- 主管指派1~2个同事写评价；
+- 被考评人员自评；
+- 主管的评价；
+- 如果被考评者是管理者，他的所有直接下级都要给他写评价。
+
+### 评价内容是什么？
+
+对其他同事的评价，以及自评，核心问题就两个：
+
+- 这个同事在上一个绩效考评周期中，对公司最大的1~2个贡献是什么？请用事例说明。
+- 这个同事在上一个绩效考评周期中，如果在什么方面采取不同的做事方式，可以对公司有更大的贡献？
+
+当然，对管理人员的评价还有一些管理相关的问题，个人自评还会有申请级别晋升的部分，对下级评价会有是否满足级别要求等额外内容。
+
+### 如何定结果？
+
+评定结果的方式是，汇总对被评估对象的所有评价，并以此为依据，由他的主管和同级的其他主管一起讨论决定绩效。
+
+### 如何应用结果？
+
+绩效考评结果包括：是否涨级、工资底薪是否要调节，以及奖金金额。这，与其他公司相比没什么特别的。但，值得一提的是，奖金数会综合公司年度表现、团队年度表现以及个人年度表现，使用公式计算得出，而且员工可以看到自己的计算公式，使得奖金数额的计算更加透明。
+
+如果你想深入了解这个360度绩效考评系统，可以参考这两篇文章：[文章1](https://www.businessinsider.com/facebook-hr-chief-explains-its-performance-reviews-2016-2)、[文章2](https://www.quora.com/What-does-Facebooks-performance-review-process-look-like/answer/Molly-Graham)。
+
+讲完了360度绩效考评的四个关键问题，接下来，我们再看看这个考评系统的两个重要原则：
+
+- 绩效考评中关注贡献度（impact）；
+- 提高绩效考评的客观性和公正性。
+
+## 原则一：绩效考评中关注贡献度
+
+360度绩效考评系统要考察的两个核心问题，实际上就是表现的“好”和“坏”两部分。这是收集反馈最常见的内容，没有什么特别的地方。但Facebook的考察特别强调以下两点：
+
+- 问题描述强调以**贡献度为根本衡量标准**。这里并没有提到这个人的技术水平怎样、开发效率怎样。因为技术和效率都是为贡献度服务的，一个员工即使技术再厉害，但对公司的贡献不够的话，绩效也不会好。
+- **衡量贡献的维度，是对公司的贡献，而不是对团队的贡献**。因为，对团队的贡献最终也要以对公司的贡献来衡量。这种方式可以避免团队的局部利益和公司的整体利益不一致的现象，让员工更关注公司的整体利益。
+
+这两点，就能够让绩效反馈的收集专注于员工对公司的贡献，让每个员工的努力方向都和公司的方向对齐。
+
+## 原则二：提高绩效考评的客观性和公正性
+
+绩效考评的一个重点是，客观性和公正性。客观公正的评价可以让员工继续努力，反之则会极大地伤害士气，导致员工工作效率下降，甚至离职。所以，很多公司尝试使用数字化的方式来尽量提高绩效考评的客观性。也正因为如此，很多公司希望用数字化来衡量员工的开发效率。
+
+但，由于软件开发行业的灵活性，用指标来衡量生产效率的效果不太好。你可以再回顾下[第2](https://time.geekbang.org/column/article/126447)和[第3](https://time.geekbang.org/column/article/128151)篇文章中的相关内容。
+
+所以，Facebook采用了这种通过收集人的主观反馈的方式来进行绩效考评。这一点，看似和数字化管理背道而驰，但这就是由软件开发行业的特性而决定的。所以，从实际结果来看，这种方式的效果反而很好。
+
+**关于提高绩效考评的客观性和公平性，Facebook的实践主要包括以下4点：**
+
+- 在评价中，每一个对公司的贡献，都一定要有事例支持，有数字的话就更好了。
+- 员工给其他同事评价的质量，也是他自己绩效的重要组成部分，来保证每个人都会认真填写尽量客观的评价。以我为例，在第一次给同事写评价时，写的比较简短、空洞，结果被主管两次打回重写。后来，我每次写绩效考评时都特别认真。
+- 意见的收集，覆盖的人群比较全面，包括同事、自评、上下级。在给自己选择评价人时，要选择对自己工作比较了解的，从而能作出客观评价，而不能随便选择和自己关系好的同事。
+- 最终决定绩效结果的讨论中，虽然主管的评价比重较大，但其他同事提供的评价占比也很可观。而且，在最终决定绩效的讨论中，同事的评价也是参会者可见的，尽量避免主管一言堂的情况。
+
+以上，就是Facebook使用360度绩效考评系统时遵循的两条重要原则。通过这两条原则，360度绩效考评系统做到了尽量客观公正评价员工对公司的贡献，并依此进行年终奖和股票的发放，从而提高了员工的努力方向和公司方向的一致性。
+
+当然，这个系统也有一些缺陷。
+
+## 360度绩效考评系统的问题
+
+360度绩效考评系统依赖于人的主观反馈，所以很容易出现评价不客观的问题。虽然Facebook采取了上面提到的原则2中的4条实践来避免这样的问题，但仍会出现一个难以避免的情况，即人际关系好的人更容易得到好的评价。人之常情，关系的好坏会影响你对他人评价的客观性，不愿意对关系好的个人或和团队提出批评，进而导致一些问题暴露得不及时。
+
+不过，从我的个人经验看，这个问题并不太严重。如果你考虑采用360度绩效考评系统的话，可以有意识地关注是否出现了问题被隐藏的情况。
+
+接下来，我再与你分享下我在其他公司落地这套系统的经验吧。
+
+## 绩效考评落地实战：360考评系统
+
+360度绩效考评系统的确对软件开发公司有巨大好处，所以，我离开Facebook之后，在国内的一家公司引入了这套系统。具体的引入步骤包括：
+
+1. 制定职级系统，并详细描述每一个级别的技术预期和贡献度预期。
+1. 对公司的现有员工进行级别评定。
+1. 对整个考评系统，进行文档化、正式化，并在公司内宣讲。
+1. 正式使用这个制度，进行绩效考评。
+
+整个流程下来效果还不错。虽然有少数员工不满意，但相比于之前主要由主管直接决定绩效的方式，普遍反馈这一套系统的确更客观公正。
+
+在我看来，在推行这个系统时，有以下三点需要特别注意：
+
+- 宣讲时，强调客观、公正评判个人对公司的贡献度，是采用这种评定方式的原因。
+- 执行中，关注Facebook为保证客观公正性的四条实践。
+- 确保反馈的保密性。为保证大家愿意写出一些真实想法，不能让员工知道对方对自己的评价。
+
+值得一提的是，这个系统比较正规，所以有些员工会觉得太重。但在我看来，**一套公平的绩效考评系统，能够大大激励员工朝着公司的前进方向而努力，因此花费的时间绝对是值得的**。除非是只有几个开发人员的小公司，否则我都推荐你尝试这种绩效考评方式。而在几个人的小公司，即使评价系统还没有成型，也应该注意评价的客观公正性。
+
+## 小结
+
+今天，我与你介绍了Facebook怎样使用360度绩效考评系统的调节，来保证开发人员的努力方向和公司的方向保持一致，从而最大化地应用工程师文化释放出来的巨大能量。这种绩效考评方式，通过全面收集同事间的反馈来评定绩效，并通过一系列规则，提高客观性和公正性，驱动大家在工作中关注公司的全局利益。
+
+虽然在执行过程中偶尔会出现因为人的主观因素，而不能客观反映事实的情况，但从Facebook员工的反馈来看，这套系统总体的执行效果很不错。它相对客观公正，而且能够驱动员工以公司整体利益为重。这对一套绩效考评系统来说，实属难能可贵。所以，我推荐你尝试这套系统。
+
+Facebook的工程师文化，强调尽量去激发员工的内驱力。从这个点出发，Facebook从让员工做感兴趣的事、让员工拥有信息和权限、用绩效调节员工努力方向这三大方面，设计了很多对工程师成长有巨大好处，又会给企业带来巨大收益的实践。
+
+如果你是一个管理者，可以以这些实践为参考，并尝试引入一些轻量级的实践，比如Hackathon、SEV流程、内部全员公开的Wiki系统等。
+
+而如果你是个人开发者，也可以从工程师文化中汲取养分，用在自己的工作和学习中。比如，Move Fast and Break Things、Focus on Impact、持续进步、代码为王等文化，都对个人开发者非常有帮助。即使你所在公司没有这样的文化，你也可以培养自己按照这样的方式做事。
+
+今天这篇文章就是专栏正文的最后一篇了，我已经从研发流程、工程方法、个人效能、管理和文化这4大方面，与你讲述了提升研发效能的各种原则和实践。但，学以致用才是学习的最终目的！所以我希望，你可以将这些知识，应用到你的工作中，真正提升团队和个人的研发效能。
+
+写作专栏之余，我也在创业。12月6~7日，我的公司KodeRover会在上海举办一个10X 工程效能特训营，帮助个人实操打造“DevOps as a Service”体系，帮助企业提高研发效能、交付效能。通过这个特训营，你可以实践我在专栏中讲述的关于全栈开发、效能度量、环境服务化、自助化等方面的方法论。
+
+在这里，我给订阅专栏的用户提供了一个福利：报名推荐人填写“极客时间葛俊”，个人报名3折优惠（需审核）；携企业组团赠送一张个人免费票。
+
+<img src="https://static001.geekbang.org/resource/image/0e/1c/0e6c7bf196a356737fdfcd22ec165a1c.png" alt="">
+
+## 思考题
+
+在360度考评系统中，Facebook鼓励员工公开自己对别人的评价，也确实有部分员工这样做了。你觉得，这样做的利弊是什么呢？
+
+感谢你的收听，欢迎你在评论区给我留言分享你的观点，也欢迎你把这篇文章分享给更多的朋友一起阅读。我们下期再见！
+
+