有时候，我们会觉得分工和分模块是产生效率的前提，但是实际情况并不是这样。我们可以看到，所谓的“分工”被彻彻底底滥用了，他们把“分工”当成了永远只干一件事的借口，一个程序员应该能够掌握多个语言，也能够负责多个模块甚至不同的职责。如果一个程序员觉得多学习一门语言，多掌握一个模块是件很困难的事，那么这个程序员本质上是不合格的。
2.4.8 老员工的管理
管理者遇到的一个最典型、最纠结的困难就是老员工处理问题。团队成长过程中必然有老员工和新员工，老员工甚至可能是你的朋友或者前同事。这种情况下，文化管理尤其重要，一旦管理不当就会出现很大问题，我们可以称这种情况为预期管理，预期如果没有管理好，有些人就会产生失落感，甚至对公司的方向和文化产生质疑。一旦一位很卓越的员工对公司文化产生质疑，后果将会很严重。
1.避免生锈
一般情况下，初始团队都是金子，偶尔会有一些铁存在，在中国，铁可能就是老朋友，而土和锈一般不会出现，除非面试环节出错，但在初期也不容易被发现。团队中每个人的发展方向不一样，但有一个共同点，大家都希望朝着金子的方向走。
公司发展过程中，做的事情和范围必然扩大，当公司的成长速度和人的成长速度不匹配时，问题就会产生。如果人的成长速度慢于公司，那么公司要做的事和人能做的事之间就会产生一个缺口。这个缺口需要管理者去填补，可能需要加人或者其他人去做。但在填补这个缺口之前需要和老员工进行深入的沟通。你可以让他去尝试做更多，去追赶公司的发展，但是如果能力上办不到，就要停下来做得少些，能力提升后再去做更多。怕就怕缺口已经产生，管理者却因为这个人是朋友或者老员工而忽略沟通，这时候老员工会产生失落感，而失落感将直接影响到一个人对公司的态度。
在公司成长很快、缺口很大的情况下，管理者必然要招新员工去填，这时候老员工心里的失落感就会影响他对公司的态度，当态度持续恶化时就会掉进锈里面。锈不会把金子拉下来，因为金子的愿景和舞台很大，但是铁会严重被锈影响，一旦铁被锈影响，更多的铁会掉进土里，公司的整个氛围就会变差。
所以在公司快速发展过程中，铁非常重要。大部分新的管理者不会去炒掉这个已经掉进锈里的“铁”，把他们当朋友，因为过往为公司做过很多贡献。但从一个理性的管理者角度来说，一旦发现锈在拉铁下来，应该马上采取行动。
2.兑现承诺
在请有问题的人离开时，之前的承诺全部要兑现，这是一个管理者的道德。有很多管理者做不到，他们站在现在的角度看过去，觉得这个人与公司目前的要求差太多，顺理成章地否认他之前所有的贡献。作为老板要清楚，这个人把公司带到这一步已经付出了很多，他的付出值得之前所给的承诺。
一个小气的老板必然留不住人，即使在公司生意做得风生水起的时候，一旦发生不兑现承诺这种事情，员工也会受到很大影响，而公司里更多的铁会掉到锈里。这个公司可能在几年之内，或者几个月之内就会被毁掉，所以，请别人离开并不意味着你可以不遵守承诺。
处理掉进锈里的铁并不容易，执行过程中会存在很多困难，这里面会存在很多感性因素，比如这个老朋友有房贷、车贷，有老婆和孩子要养。但是一个公司的发展不是感性而是理性的，如果感性的决策做太多，就会有人开始不作为，其他人觉得他也可以不作为，因为他是老员工而那些拼命做事的人就会跳槽，因为在他们心里这个公司已经没救了。
2.4.9 工作时间
我的一位前同事，父母从家乡过来陪她一段时间，2个月时间里没能抽出几天回家吃晚饭，她妈妈一怒之下拉她来辞职，因为在小城市生活的人来看，只有资本家才会这样压迫员工，哪有天天加班的道理。很遗憾，这就是我们这个行业的现状，不是某个人可以左右的。
谈到工作时间，其实大家想表达的是时间自由，即自己可以左右时间，而左右时间，很多人又会认为需要财务自由作为前提。这种想法不在少数，但是我认为，相比较财务自由而言，当代社会更多的是应该看是否能力自由。假设你现在有一笔钱，并且达到你所设想的财务自由标准，那你是否可以退休了？我想，真的让你退休了，你还会不自在，因为朋友圈逐渐没有了，紧跟着你会陷入更深的迷茫。所以，我认为，真正应该关注的是工作能力是否自由，如果你能力很强，又很善于掌握新的技能，那你完全可以自己掌控自己的时间，可以自己创业，或者去那些愿意给你时间自由的公司，一切事在人为，关键还是自身。
当然，不会有那么多具备这类能力的人，大多数的人还是需要上班的。而作为IT企业，还是需要体谅一下程序员的心理诉求。如果你可以做主，我建议针对程序员最好采用弹性工作制，多数企业中的多数雇员属于白天型的人，但与他们不同，多数程序员属于夜晚型的人。他们一般到了晚上才开始很有精神，对于开发工作也更加专注，所以如果有可能，尽量对他们使用弹性工作制，不要太过于限制工作的时间和地点。当然，很多开发工作是需要及时沟通的，所以每天必须有大于4个小时的时间让大家聚在一起，这样才能够完成需求、设计等评审流程，才能对具体的系统架构、代码问题进行讨论。此外，毕竟产品、市场、职能部门的工作人员不是弹性工作制，也要体谅且配合他们。
2.4.10 缺乏愿景
最有效的领导方法，包括两个能力：一是愿景（Vision），二是沟通能力。我们这里主要讲愿景。
什么是愿景？愿景就是作为一名软件工程师，未来你的发展前途、你做的产品对未来世界有什么影响等。说得直白一点，就是要让一名软件工程师对这家公司有归属感和对未来的期望，这些都是要能够落地的，给一个虚无缥缈（例如我们要做最好的科技公司）的目标，会让底层员工感觉不到真实。对一名软件工程师，你最好能够告诉他，你对公司很重要，但关键要说清楚为什么重要，特别需要让他们体会到他们的技术能够不断提高的愿景。
大公司有大公司的愿景，小公司有小公司的愿景，我们技术团队和个人应该也有自己的愿景。
团队里的个人可以有这样的愿景：三年之内成为Web前端方面的技术专家。团队可以有这样的愿景：打造国内技术领先的前端团队。
Jim Collins的那本《Build to Last》，提到了所有Visionary公司都具有一个特质，就是很注重自身企业文化的建设。FaceBook为了降低人才的流失风险，设立了相当严谨的内部人才建设规划，所有人都以成绩说话，只要完成一个重要项目并且在规定的时间内完成目标数据，公司立即对项目成员进行加薪和晋升。因此FaceBook打造了顶尖科技企业独一无二的“黑客核心文化”，并发挥到了极致。
2.5
其他相关知识
2.5.1 理解程序员工作
技术为主的公司和非技术为主的公司，技术管理者所做的工作是有明显区别的，因此，对技术管理者的技术背景要求也是有明显差异的。非技术为主的公司，团队领导可以不是程序员出身，他可能来自业务部门，也可能来自运营部门，只要他过往的经历可以帮助他Hold住这个岗位。而对于技术为主的公司，技术管理者如果不懂技术，就无法和程序员进行交流，基本上参加会议时一句话也插不上，别人又怎么对你尊重呢。
Gace Hopper 在1961年写下了这些文字：“程序员是一个古怪的群体，他们崛起的速度很快，很快就形成了独立的职业，并且过早地感染了不愿做出改变的抗性。我曾经听说有些程序员因为客户不愿意修改自己的系统而斥责客户，有时走进我的办公室，也会要求坚持他的想法。出于这个原因，我在办公室悬挂了一个逆时针走动的时钟。”
编程是一种有趣的工作，且大多数程序员都很享受工作，这样就不难理解了。为什么难以管理他们？如果有人付钱让你开心地玩，你还会愿意受制于人吗？受人管制就会减少工作中的乐趣！
程序员之间的差异非常大，只有很了解程序设计的人才能完全理解这一点。事实上，程序员之间的差异主要来自个人的内在因素，而不是外在属性。大多数公司的高层管理者对所有的程序员一视同仁，这种看法是片面的。微软公司的Bill Gates、Adobe公司的John Warnock、FaceBook公司的Mark Zuckerberg都没有犯这样的错误，因为他们也都是程序员。这也是为什么我觉得某些大型软件企业需要变革的原因，在科技界，你最好不要让非技术出身的人担任CEO。
如果没有外界的干扰，许多程序员在独自面对自己的设备时通常都会很投入地写代码，一边写一边设计。技术团队管理者必须培养软件开发文化，而文化又是建立在可靠的开发实践基础上的，否则程序设计项目就可能失败。
成功管理程序员的关键是要认识到他们是独立的个体。程序员之间的差异很大，你必须努力地让每个人的长处都得到发挥，同时尽力提高或者至少抵消每个人的短板，这也是对技术管理者的要求。
因为程序员都是些无拘无束的人，常见的激励方法往往没什么用。除了进行必要的技术监督并把开发实践和过程落实到位之外，善于利用程序员的自我意识和改变世界的欲望也很关键。这就需要一类既能理解程序员的工作方式，又能理解工作本身的技术管理者，他们不仅能有效地激励程序员超常发挥，而且能按时交付结果。
此外，也不是只有计算机专业毕业的人才能做程序员。有一个同事，以前是学法律的，后来转行写代码，写出的代码比很多多年写代码的人还好。她在法律上的缜密思维，很好地转移到了代码逻辑上，不学自通，这就是程序员，你用正常思维理解不了他们的成长路线。
2.5.2 左脑型VS右脑型
右脑理论与左脑理论源于Roger W.Sperry的具体研究工作，根据他的研究表明，大脑的左半球和右半球具有针对不同任务的专门功能。左脑通常专用于分析任务和语言表达，而右脑主要用于空间感知任务、音乐等。左脑的表达能力比右脑强得多。
如果你是一名程序员，你很可能属于“左脑型”，这意味着语言、逻辑和分析使用得更多，也更客观。其实称为“左脑为主型”更恰当，因为我们只有一个大脑，两个半球始终是同时工作的。因此，你既可以是“左脑型”的人，又可以具有非语言交流、直觉、想象力较多且更主观等强烈的“右脑型”倾向，这些倾向通常更多地与音乐家、作家、艺术家等创新型人才相关联。
对于一名优秀的程序员来说，强大的左脑分析能力是必不可少的，不过，与右脑相关的活动往往也同样重要，这是因为程序设计是一门很有创意的艺术。事实上，我们发现，一些最顶尖的程序员同时也是音乐家。
《Thinking in C#》的作者Larry O’Brien和Bruce Eckel有这么一段评论：“计算机程序设计非常有趣。与音乐一样，它也是先天才华与刻苦练习相结合的产物。与绘画一样，它也可以有多种发展方向，商业、艺术以及纯娱乐。众所周知，程序员的工作时间很长，但很少有人将其归因于富有创造力的狂热。程序员们在周末、假期甚至吃饭的时候讨论软件开发，不是因为他们缺乏想象力，而是因为其他人看不到他们想象的那个世界。”
2.5.3 程序员思维
程序员的思维有一个专业术语，叫作计算思维（Computational Thinking）。计算思维是根据计算机科学的基本概念和方法提出的，是用来理解需求、设计系统、实现编程、解决问题的思维方法。简而言之，计算思维就是描述程序员或计算机科学家是如何思考的。当然，计算机科学的理论知识如数理逻辑、离散数学、数据结构、算法以及面向对象等是计算思维的必要条件。计算思维有一系列的智力工具，不能一一尽述，仅介绍关键的几项。
1.抽象思维（Abstract Thought）
给定一个问题，抽象就是去掉纷繁芜杂的与计算无关的部分，用规约（Reduction）的方法还原到问题的本质。所谓本质即把原来的问题转换为一个或几个可以使用计算机描述并解决的问题，进一步讲也就是转换成在算法上可计算的（Algorithmically Computable）一个或几个问题，更准确、更理论化、更上档次的描述是转换为邱奇–图灵论题（TChurch-Turing Thesis）可计算的可数个问题。图灵机（Turing Machine）和λ演算（Lambda Calculus）本身就是对可计算性（Computability）的漂亮的抽象，可以作为抽象思维的经典案例来学习。一般在实际工作中，常常需要把问题的实体对象根据需求表示为各种数据结构，如树、堆、栈等，而业务逻辑（Business Logic）过程表示为各种算法，如排序和查找等。
表示（Presentation）
表示是解决问题的第一步，也是关键的一步。在编程实践中，我们都有很深的体会，一旦问题被准确地无歧义表示出来了，解决方案就烘云托月般地呈现出来了。这就是“数据即代码，代码即数据”的道理。抽象思维也广泛用于数学家的工作。面对一个困难的问题，数学家们常从两个方向开展研究。
一方面，从特殊情况入手，推广到更一般的情况；另一方面，将一个一般问题具体化成几种特殊情况。两个方向的结果最终汇聚在一起，就找到了问题的答案。我想这可能是论语中“我叩其两端而竭焉”的一个最好注解。而从特殊到一般就是一个不断抽象的过程。我们用一个具体的例子加以说明，有一个著名的“六度分隔理论（Six Degrees of Separation）”讲的是世界上任意两个人最多通过另外6个人就能相互认识，如果要验证这一理论，怎么做呢？
我们可以借助一个图来表示人与人之间的关系，每个人用图中的一个节点表示，如果A和B认识，那么在代表他们的节点之间有一条边连接。现在的问题就转换为检查这个图的直径是否大于6。考虑到世界人口众多，且有生老病死，图的规模必然超大，并且是动态的不断变化的，算出它的直径仍需要更多的简化，这里就到此为止了。
2.逻辑推理（Reasoning）
逻辑推理对于程序员的重要性不言而喻。与其说逻辑推理用于程序新功能的开发，不如说更多的应用在程序调试和修改BUG的过程中。程序调试有点类似于Sherlock Holmes侦破案件的过程。和Dr.Wason比较起来，Holmes的推理优于常人的地方有两点：第一，在观察现场或听取来访者叙述时，他能够得到更多的数据，尤其是一些别人容易忽略的关键细节，这得益于他对犯罪领域知识的丰富积累，知道什么才是更重要的数据；第二，根据得到的数据，他能够联想到更多的可能性结论，这得益于他大量的案例储存。有了这两点，就能够通过一环套一环的推理链逐渐缩小侦察范围，最终认清犯罪事实。
程序调试也是如此，首先必须掌握程序执行过程的细节。然后从问题出发，分别朝着产生的原因和导致的后果前后两个方向推理。逐渐定位问题的范围，最终找到问题的根源和解决的方案。我们比Sherlock Holmes幸运的是，可以借助调试工具来了解程序运行的过程。所以，一个不能使用调试工具的程序会令程序员感到无比沮丧，只能通过跟踪信息来跟踪程序运行的过程。如果不知道程序运行的过程，推理就只能靠猜，那么修改Bug是非常危险的，很容易导致回退（Regression）的错误，这种情况下如同盲人摸象，根本不知道自己在做什么。另外，Sherlock Holmes还多次表达过这样的观点，案子越是离奇，越容易解决，因为奇怪的点都是线索。
对程序员来讲，也不必担心奇怪的问题，奇怪本身就是线索。关键看对程序运行细节的了解程度和逻辑推理的技术水平。
3.分析（Analysis）
分析是上文提到的数学家所用思维方式中从一般到若干特殊情况的过程。面对一个问题，如果一下子描述不清楚或者表示不出来，可以先找出满足问题条件的几种特殊情况。通过仔细检查这几种特殊情况，求同存异，找出他们共同的规律或模式，并对这些模式或规律加以验证，就可以找出描述或表示问题的方法。这就是猜测加验证（guess-and-verify）的过程。项目需求分析时常见的应用案例分析（Use Case Analysis）方法，就是用一个个具体的使用案例将模糊的项目需求生动地表达出来。
4.分解（Decomposing）
把一个大问题分解为几个小问题，或者把一个复杂的过程分解为几个子过程，这样有助于问题的解决。这也是程序员常用的手段，如算法策略中的分而治之（Divide-and-Conquer）和合并排序就是这方面的例子。
5.递归（Recursion）
对于初学编程的人，递归可能是一个比较诡异的、较难掌握的概念。但是一个程序员如果不懂递归，很难称之为程序员。因为很多稍微复杂的算法他都不可能理解，如回溯和动态规划，甚至于树的遍历。递归常常可以用简单的方法非常优雅地表达复杂的算法。
另外，有关计算思维的特有方法还有并行、异步/同步、模拟/近似、优化、分层、封装、解耦等。程序员的思维艺术即计算思维不是一两天的短时间内可以形成的，需要在实践中慢慢琢磨，不断提升，且永无止境。
2.5.4 杰出的程序员
杰出的程序员是如何产生的呢？仅仅具备程序设计方面的天赋是远远不够的。杰出的程序员是大师级的人物，做事有条不紊、遵守纪律，能够凭借直觉把代码和程序组织好，能够约束自己总是在编写代码之前进行设计，能够在最少的时间内编写出清晰、简洁、实用、高质量的代码并获得预期的结果。换言之，杰出的程序员是大师级的工匠。
如果程序员的学习、工作动力主要来源于项目管理时间表、管理层的压力，或者金钱，那么他不会成为一名杰出的程序员。对大多数杰出的程序员来说，动力实际上来源于更高的追求，例如改变世界，做出人们喜欢使用的程序或产品。杰出的程序员希望并且需要为具有世界影响的项目而工作，他们希望能够感受到自己的工作是有意义的，哪怕只在某个很小的方面有意义也行。杰出的程序员偏爱能够满足他们更高理想或要求的公司和项目，他们非常在意自己所做的事情，常常为了想要的结果而超负荷工作，而不会在某种压力下自愿做低技术含量的重复劳动。
美国科罗拉多大学早在1993年就做过一个关于软件工程师的研究，报告显示：“和普通工程师相比，那些出类拔萃的工程师往往更能照顾全局，更喜欢实际行动，更易受使命感推动，更能展示和表达出一种坚定的信念，在管理中更容易发挥主动的作用，更能帮助其他工程师。”
世界上杰出的程序员不多，不可能让每个项目团队都拥有杰出的程序员。而且多数团队也只能容忍队伍中有一两名杰出的程序员。大多数的程序都需要靠普通程序员完成，他们通常是称职的、专业的、能干的，但是可能会把程序设计看作为一种工作，而不是追求。
2.5.5 小型团队VS大型团队
一般来说，小型团队的效率比较高。一个小型团队可以就近办公，经常可以聚在同一个办公室，即便是敏捷团队，规模可能更大，但是也提倡就近办公的原则。
高效的小型团队会在所有成员之间平等地共享所有沟通信息，坚持做到遇到问题时能够立即回答，当发生设计难题时马上解决，并互相提供调试相关的建议与帮助。遇到问题寻求人帮助的时候，不需要浪费时间在流程步骤与消息的往来循环上。
随着团队人数的增加，沟通也会变得更加困难，沟通交互变得碎片化，这样会导致更多的错误预设，以及其他在小型团队中能够避免的错误步骤。
对于大型团队来说，可能需要从外部招聘团队管理者，这时候你需要了解他的管理风格，并成功交付项目的实际经验。如果可能的话，找到曾经与他一起工作的人，看看他们是如何看待他在这两个方面的表现的。LinkedIn的出现大大简化了寻找证明人的步骤，要充分利用它。最好的方式是从内部培养团队管理者，一般来说，能够变成杰出管理者的优秀程序员很少。对于那些有才能，并且期望能够成为高效管理人员的程序员，我们应当鼓励、培养和奖励他们。随着组织的发展，他们可以产生显著的积极影响。
大公司可能会采用“矩阵管理”方式组建团队，这意味着团队成员都有各自隶属的职能领域，但为了完成某个指定的项目，被“临时”分配到了一个矩阵型的团队中。这样能够在项目人事配备方面获得最大的灵活性，但是也带来了考核的难题。如果团队成员很优秀，这不会是一个问题。但是当团队成员表现不佳时，则可能成为“临时”团队负责人的烦心事。这个问题通常被称为有责任但没有权力。
2.5.6 扁平化管理
雷军曾经在一次采访中谈到小米的情况：“小米团队是小米成功的核心原因。和一群聪明人一起共事，为了挖到聪明人可以不惜一切代价。如果一个同事不够优秀，很可能不但不能有效帮助整个团队，反而有可能影响到整个团队的工作效率。真正到小米来的人，都是真正干活的人，他想做成一件事情，所以非常有热情。来到小米工作的人聪明、技术一流、有战斗力，这样的员工做出来的产品注定是一流的。”
小米的组织架构没有层级，基本上是三级：七个核心创始人–部门leader–员工。同时不会让团队太大，稍微大一点就拆分成小团队。从小米的办公布局就能看出这种组织结构：一层产品、一层营销、一层硬件、一层电商，每层由一名创始人坐镇，能一竿子插到底的执行。大家互不干涉，都希望能够在各自分管的领域给力，一起把这个事情做好。
从小米的团队管理，我们已经可以了解到扁平化的好处，它更容易让能干的人冒出来。理论上来说，通过减少管理层次、压缩职能部门和机构、裁减人员，使企业的决策层和操作层之间的中间管理层级尽可能减少，以便使企业快速地将决策权延至企业生产、营销的最前线，从而为提高企业效率建立富有弹性的新型管理模式。扁平化管理解决了传统的金字塔状的企业管理模式的诸多难题和矛盾，是解决层级式管理在现代环境下面临的难题而实施的一种管理模式。当企业规模扩大时，原来的有效办法是增加管理层次，而现在的有效办法是增加管理幅度。当管理层次减少而管理幅度增加时，金字塔状的组织形式就被“压缩”成扁平状的组织形式。
为什么过去没有这么强烈的诉求？因为中国的IT起步较晚，人才的出现、累计需要很多年，现在已经出现了大规模的知识型员工。知识型员工的一个鲜明特点就是，对专业的忠诚大于对所服务的企业的忠诚，选择企业的目的是致力于寻求能够实现自身专业成就最大化的成长平台。200多年的工业社会发展使专业分工模式越来越成熟，也进一步催生了庞大的知识型员工群体。知识型员工群体的兴起和“去中心化”的信息传播方式，这两者结合，对企业管理提出新的要求，同时，这部分群体对企业的绩效发挥着越来越大的影响，而知识型员工又是社群自组织和传统组织混合协作的主要群体。
2.5.7 金州勇士奇迹
在2015～2016年的NBA（美国职业篮球联赛）赛季，位于硅谷地区的金州勇士队（Golden State Warriors）创造了NBA历史上常规赛获胜率最高的纪录，在全部82场比赛中获胜73场。而在一年前，该队获得了NBA总冠军。
但事实上，勇士队长期以来一直是NBA里的一支“鱼腩球队”。在2009年，金州勇士队还是NBA里最烂的球队之一，那一年它的成绩排名倒数第二，当然勇士队也不可能有大牌球星和教练。因此该队能取得这样的成绩，实在是一个奇迹，而它创造奇迹的方式在体育史上恐怕是独一无二的。
金州勇士队的成功并非砸钱的结果，而是因为它处在一个特别的地区——硅谷。
硅谷地区有两种人最不缺，即风险投资人和工程师，勇士队的奇迹从很大程度上讲是靠他们创造的。前者善于看到其他人还没有发现的投资潜力，然后把它经营成值钱的实业；后者善于利用技术创造奇迹。
勇士队的成功就是他们合作的成果。6年前勇士队的比赛成绩跌到了谷底，因此价值较低，一些风险投资人决定将这支不值钱的球队买下来好好经营，让它成为美国体育界最耀眼的明星。
这个计划看上去有点疯狂，不过投资人有自己的考虑，他们有秘密武器，那就是应用大数据的工程师。最终，投资人用4.5亿美元这个相对较低的价格完成了对勇士队的收购。
在收购完成后，投资人为球队委派了新的管理层：没有任何执教NBA经验的史蒂夫·科尔，因突出的投篮优势被委任为教练。科尔在执掌勇士队之后，坚持用数据说话，而不是凭经验。
他根据背后团队对历年来NBA比赛的统计，发现最有效的进攻是眼花缭乱的传球和准确的投篮，而不是彰显个人能力的突破和扣篮。在这个思想的指导下，勇士队队员苦练神投技，全队在一个赛季中投进1000个三分球，又创造了一项NBA纪录。
这其中，最亮眼的新打法是尽可能地从24英尺（大约7.3米）外的三分线投篮，这样可以得3分。正是因为不再按照篮球传统的战术作战，勇士队卖掉了那些价钱高却效率低的明星，而着重培养自己看中的新人。
这位新人叫斯蒂芬·库里（Stephen Curry），三分球的神投手。在2014～2015赛季中，库里的神投让勇士队夺得了40多年来的第一个总冠军，他自己也成为当年的最有价值球员（MVP）。到了2015～2016赛季，库里投进了403个三分球，创造了NBA历史上的纪录，打破了由雷·阿伦所保持的个人单赛季269记三分命中数的纪录。
除了利用数据制定战略，勇士队还利用实时数据及时调整比赛中的战术。早在2012年，勇士队的总裁兼COO（首席运营官）里克·威尔茨（Rick Weltz）就在一次大数据会议（TUCON2012）上介绍了该球队应用大数据的成果。根据威尔茨的介绍，大数据可以帮助球队改进精细到两个人配合的细节。正是靠高科技，勇士队才得以在短短6年里从倒数第二名登顶NBA的总冠军。
鉴于勇士队的战术和成绩给NBA带来的巨大冲击，奥巴马在白宫专门接见了勇士队，并且讲道：“（这）看起来正在打破这项运动的格局，这似乎是不公平的比赛。”篮球界的人士则认为，勇士队是NBA里的Google。
2.5.8 KPI之祸
索尼公司前常务董事天外伺朗的《绩效主义毁了索尼》一文，曾经在业界流传甚广，也激起了广泛的争议，支持的、反对的意见和声音到现在都还没有停止。抛开索尼是否真正理解KPI等争议，单纯从文章描述的现象来看，相信绝大部分公司里面都会存在类似的现象，例如：
·因为要考核业绩，几乎所有人都提出相对容易实现的低目标。
·因实行绩效主义，索尼公司内追求眼前利益的风气蔓延。这样一来，短期内难见效益的工作，比如产品质量检验以及“老化处理”工序都受到轻视。
·上司不把部下当有感情的人看待，而是一切都看指标。
·为衡量业绩，首先必须把各种工作要素量化。但是工作是无法简单量化的。公司为统计业绩，花费了大量的精力和时间，而在真正的工作上却敷衍了事，出现了本末倒置的倾向。
大多数人开始带技术团队后，在绩效考核这方面同样遇到了类似的疑惑，例如：
（1）程序员的工作怎么量化？Bug数？代码行？版本数？
做过程序员的都知道，这些指标都是不可行的。假设公司考核程序员的Bug数和等级，并且同时也考核测试人员发现Bug的数量，结果程序员和测试员为了一个问题是Bug还是需求遗漏、Bug等级是严重还是一般，能够吵上2个小时，于是最后就看谁会吵，谁官大，搞得程序员和测试员身心俱疲，关系很紧张！
（2）即使程序员的工作可以量化，每次绩效都是这几个指标，定绩效目标还有意义么？
例如，假设考核程序员用Bug数、代码行数、版本数，2000年用这个指标，2017年也还是这个指标，这样的绩效目标有什么意义呢？
（3）团队Leader如何制定团队的KPI？
例如，可以看两个团队谁的代码行多么？可以看谁的团队Bug数多么？可以看谁的团队版本数多么？可以看谁的团队分享次数多么？这些其实都不行。
（4）前瞻性的工作谁愿意做，有风险的工作谁愿意做？
例如，引入ElasticSearch理论上是可以提升搜索性能的，但可能在引入的这一年反而会带来很多问题，而能带来多少收益还不确定，这个时候怎么定KPI？这个时候推荐使用OKR。
OKR全称是Objectives and Key Results，而KPI的全称是Key Performance Indicators，OKR和KPI具体的差别表现在：OKR的关键词是Objectives，KPI的关键词是Indicators！
不要小看了这两个词的力量，正是这两个词决定了OKR和KPI的本质差异：OKR关注的是目标，KPI关注的是指标。当我们关注“目标”的时候，我们会思考接下来我要做的事情是什么；而我们关注“指标”的时候，我们会思考自己的工作如何评价。
·以程序员为例，如果我们关注目标，我们会想接下来我应该做什么事情，是要解决产品的卡顿问题，还是引入大数据来做精准推荐；如果关注指标，因为我们的工作是编程，那我们就会想哪些指标可以衡量编程工作呢？我们想到的是代码行数、Bug数、单元测试覆盖率等。
·以足球运动员为例，如果关注目标，我们会想到夺冠、四强、保级；如果关注指标，那我们就会想到进球数、助攻数、跑动距离、比赛场次等。
·以滴滴和快的为例，如果关注目标，快的的目标应该是超越滴滴；如果关注指标，快的的指标应该是司机数量、订单数、乘客数等。
为何这两种思考方式差异如此大呢？有一句名言形象地说明了这一点：如果方向对了，就不怕路途遥远！如果方向不对，指标再漂亮都没有意义，甚至指标越漂亮就错得越离谱。目标是我们的方向，指标是评价我们做事情的质量。使用OKR的时候，我们的第一反应是：“我们的目标是什么？”而使用KPI的时候，我们的第一反应是：“我们的职责是什么？”如果我们将思维固化在当前的职责，那就不会去审视整个环境当前的状态以及后续可能发生的变化，也就不会及时地根据实际情况进行调整。
彼得·德鲁克在《管理的实践》中说：“并不是有了工作才有目标，而是相反，有了目标才能确定每个人的工作。所以企业的使命和任务，必须转化为目标。”我觉得这句话非常好地诠释了OKR的本质，以及OKR和KPI的区别，形象地提炼一下：OKR让我们做正确的事情，KPI让我们正确地做事情！
OKR目前在美国硅谷的科技公司应用并取得了很好的效果，但介绍OKR的文章里面无一例外都提到了OKR和绩效考核无关，例如Facebook的绩效考核是360度环评，而中国公司的绩效目前来看不太可能采用这种方式进行绩效评价，如果我们要推行OKR，绩效考核如何做？难道还要发明另外一套机制来进行考核？
前面我们分析OKR和KPI的关系的时候，提到了OKR其实可以用KPI或者Milestone的形式来进行衡量，而这正好和我们传统的KPI绩效考核的形式是一致的，因此我认为根据OKR来进行绩效考核并没有什么问题，而且可以从已有的KPI绩效考核平滑地过渡到OKR绩效考核，只要考核OKR的KR的达成情况就可以了。
2.5.9 团建活动的技巧
很多团队为了加强成员之间的了解和协作，并建立成员对团队的认同感，每年都会组织Outing活动来进行团队建设，但我们看到越来越多的情况是Outing变成了单纯的休闲旅游，并且越来越高端，现在已不满足国内游了，很多团队开始出国游。当然，如果这是公司的一种变相福利无可厚非，但是是否真的很有帮助呢？尤其是人数超过十个以上，大家出去玩，会各自找自己相熟的人一起玩，最多说说一些无关痛痒的话，Outing结束了一切照旧。
个人比较倾向于户外活动，最好是有一定强度并过夜的活动，当然最好能够找专业的户外拓展公司来协助，效果会更好。在荒无人烟的野外，通过刻意划分的小组、强制的行为约束、集体的协作，共同挑战艰苦的旅程，在别无选择和共同的困难面前，人和人的心会迅速打开和贴近，自觉地相互帮助共同完成目标，再通过晚上的喝酒助兴进一步加强和巩固团队关系。
户外活动过程中，会遇到很多困难和挑战，每个人都需要团队的鼓励和帮助才能成功突破自我，这特别能体现团队协作力量的伟大，这和我们工作中遇到的问题解决思路是一样的。
