引言：前几天，网上有流传出米哈游员工手册的高糊截图，因为对内容实在感兴趣，我就保存了下来。最近两天顶着接近马赛克的画质读完可读的部分，几乎泪流满面，对其中的内容深感触动。由于其中的文字内容实在过于模糊，以至于OCR都难以识别，于是决定将其中的内容手打转换为文本，打算长久保存用以激励自己。以下为第二章第一、二节的内容
02我是一只萌新大佬
特别提醒：入职指引，请看另一本书哦
剩下的，请翻开下一页，233
老同学可以跳过看第三章咯
2.1瑟瑟发抖的第一天早上
当第一天前台小姐姐把你带到工位的时候，或许你会看到，一群群人站着围成一圈在轮流说话。
Emmm……说明你已经错过第一天的早会了!
如1.2中所讲，我们是一个Team of Teams的组织形式。所以，每天早上，我们都会以Teams为单位进行早会。早会制度从miHoYo成立第一天，大概是2011年春天的某一天开始就存在了。作为miHoYo少有的要求严格执行的制度之一。早会对于日常工作有着十分重要的意义。
基于敏捷开发的原则，项目上的任务每天都在发生变化，出现各种问题。早会的重要意义在于，集合某一功能的相关人员，高效同步开发进展与问题，以达到目标同步，问题暴露，进度管理等目的。注意，早会只提出问道，不进行讨论解决问题!因为没那个时间。
特别说明， 作为一项全员皆知的规定，任何小组成员，早会迟到要买水果。
2.2我要如何工作？
在miHoYo,我们一直秉持着我们的团队理念，就是“跟优秀的人在一起，做出优秀的事情，获得优秀的回报”。那么在加入我们之后，应该如何去做优秀的事情?如上一节所讲，我们在努力构建一个扁平的自组织结构的组织，并努力尽一切可能保持内部信息的透明与流动。那么在这个背景下，每一个人该如何工作，如何思考决策。答案就是:
Context, not Control！
Context, not Control的理念来源于Netflix。
先解释一下字面意思：
什么是Context?一切做决策需要的背景信息，都叫Context。比如：我们项目目标用户是啥，我们的历史数据如何，一测用户平成是咋样的反馈，做一个Feature的人力成本如何，技术风险的高低，甚至某个同学熬夜加班效率特别高23.等等这些都是Context
那什么是Control呢? 一切流程化的执行手段，比如: OA审批流程，指令拆分分解，委员会投票表决等。
那对我的工作而言，这两者是啥区别？
“Control”的工作方式意味着，严格遵守你的上司给你下达的指令，不必去多想他为什么这么决策，只管执行好就行，也不用考虑这个指令之外的事情，只对下达的这个命令范畴内的事情来负责。如果需要其他人来配合那就拆分，然后分配任务出去，然后同样严格控制他们来执行。这种工作方式，在很多大型企业和组织，都是十分常见的。
“Context”的工作方式则不一样。当进行一个任务的时候，我们首先需要全面的了解上下文的信息，基于自己对眼前工作的专业的认识，结与相关人员充分沟通同步认知，然后做出好的解决方案并执行完成。
举一个具体的例子，当我们要实现一个怪物的自动索敌跟踪功能的时候。
“Control”的故事会是这样：客户端主程和策划讨论完成后，基于他的知识与经验，告诉具体做Feature的程序A，用Unity的NavMeshAgent来创建Navmesh，然后实现一个寻路算法，来满足需求上的功能。
Context的故事则是这样的:客户端组长拉具体的负责实现的程序A同学和策划进行深入讨论，告诉他要做一个这样的Feature，并建议可以用到NavMeshAgent这样的功能。
看起来故事的开头并没有太大的差别，甚至很多时候这两个故事的结果也会差不多，程序A顺利使用NavMeshAgent实现了Feature，并通过了验收与测试。但是当我们的项目越来越大，越来越复杂的时候，这两条故事线的发展会天差地别。
Control线的，程序A看完了文档，看完了策划的需求文档，开始动手实现，一天后他实现了功能，在一个测试场景里跑了一下，发现没有太大问题，他喊策划来验收了一下，从而提出了修改意见，然后自己跑了跑也发现问题不大。这时候程序A认为再过一天修完Bug ，close掉这个feature毫无风险，第二天，修完bug后他把这个功能放到游戏大世界中去。这是一个面积一万倍于测试场景的世界，而且地形的复杂程度也比测试场景要高很多，不过地形复杂这件事早在程序的意料之中，他准备再花一整天时间来好好处理各种意料之外的情况。想到这里。他按下了NavMesh的Build按钮，起身准备去接一杯水，1分钟后程序A回到自己的工位，他发现这个还没有build，他敏捷的意识到出问题了，这个世界太tmd大了，光离线构建一个NavMesh就要好久，这可能会是个坑。程序啜了一口水，想了想，马上就要周版本打包了，这个任务还是得close。主程说了让我用这个方法，他应该心里有数吧，反正我毫无bug的把这个功能实现完了。策划也验收得差不多了，就这样先提交一版吧，程序A不知思考了几分钟，正等他回过神来的时候，NavMesh已经构建完了。在PC上这还是挺快的嘛，程序A继续开始做其他的功能与测试，并准时在打包前提交了全部代码。
几个小时后，当晚的周版本打包完成了，大家开始下载，不知为何今晚的下载速度有些慢大家又开始抱怨这个WiFi AP太卡了，都集中在同一时间下载。终于，十几分钟后，有人下载好了，开始回归Feature。“卧槽，怎么闪退了？”一个用iPhone 7的人喊到、“是啊，我这里好像也闪退了。”越来越多的人发现自己的设备无法正常进行游戏。简单统计后，大家发现，除了最高端设备，好像其他的都很容易闪退。经过了1个小时的排查后，大家发现，这周周版本的包比上一周整整大了500mb，而这其中95%都是内存爆炸，都是因为太多NavMesh的载入而导致的。当目光投向程序A的时候，他很坦然地承认了问题，确实看来不能这么做。然后他用比别人更专业，更精准的语言来描述了问题，以及在当前Solution下无解的程度。现在皮球回到了客户端主程的身上，在忙碌的周版本的午夜，他的疲惫显而易见的浮在脸上。因为屁股后面还排了好几个人在反馈问题。PM还在问他要不要重新打包好验收其他功能，给他用来思考这个问题的时间只有不到一分钟。那肯定是没办法离线缓存所有的NavMesh啊。这个世界太大了，是的，程序A附和道，然后他继续在等待新的指示。主程叹了一口气。在叹气的这蓄须臾之间他想了很多，今晚的下班时间应该又是3点以后了吧；这个寻路的功能这么做下去恐怕要重新设计了；恐怕没法三言两语就把后续的走路时间给讲清楚，他自己还需要去思考更多；还有，他还想到了这项目再这么做下去，简直就是个无底深渊……
在另一条世界线上，Context线的故事，则完全不同，程序A还在会议室里跟策划讨论，这次的会议有点长，客户端组长已经忙别的去了。“这个功能，要用在哪？地下城？”“嗯，不止地下城，大世界也会有。”策划答道。嗯，地下城还好说，除了地形之外，其他跟崩三差不多，“那大世界是啥需求？怪可以随处跑吗？”“可以。”策划随口答道，这在他看来是跟其他毫无差别的需求，十分平常。而此时，程序A脸色沉了下来，见程序A没有爽快的接锅，策划同学眉头一皱，发现事情并不简单。“有什么问题吗？”他试探性低问道。“有，你确定世界这么大，怪的活动范围是不受限制的对吧？”程序A又确认了一遍。“是的，至少是可以被拉到很远的地方的。”策划回答道。“我先去了解一下NavMeshAgent的功能吧，现在还没法确定这个功能怎么做。”好吧，虽然PM要求的需求评审时间快到了，但此时好像也只能这样了。“那么有什么问题随时找我吧，如果有问题，我们也可以想想其他的解决方案”，策划说到。两人起身走到门口，策划突然停住了脚步，因为在他看来这个需求十分平常，不是所有游戏都是这样的吗？他觉得这个问题必须问清楚。于是他问道：“我们跟其他游戏在实现上有什么不同吗？”正在翻阅手机的程序A抬起头：“有很大的不同啊”，他放下手机，上面显示着NavMeshAgent的文档。他开始跟策划解释为什么有巨大的不同，平时少言寡语的程序A，像是打开了封印千年的话匣子，为什么要离线缓存多大的Mesh，如果Runtime计算会不会卡，异步Load我们可能要自己实践…，等程序A再次闭上嘴的时候，他自己觉得自己的脑中貌似已经有了一个大概的Solution了。策划一直听完了程序A的陈述，偶尔插一两个问题，虽然有些细节他不清楚，但大概意思是get到了。好歹我本科也是读CS的呢，策划自己心里盘算着。这场会议，终于在近两个小时的讨论后结束了。
后来程序A了解完了NavMeshAgent的功能向程序组长表示，直接来用并不靠谱，但在长期的沟通中，他们都清楚这个Feature还是必须要做完，再后来他们又去找了工具组，引擎组，大家一起讨论了一个改造NavMeshAgent的方案，基于各方面的支持，先实现了一版功能。然后，又是几周的迭代和反馈测试，才最终把这个功能稳定下来。
Context线的故事讲完了，如果你问我为什么中间没有写，策划SB吗？程序是不是老油条这样的桥段。我会告诉你，并不是他们多么的，而是他们在长期的沟通中，已经完全同步了。互相理解是因为，在同样的背景信息（Context）下，基于逻辑，得出了同样的结论。
段子说完了，那要讲讲为什么我们的做事方式是“Context，not Control”呢？
在我们看来，Control往往会带来一些危险，人类在判断自己的理性控制能力时会有一种幻觉，对于聪明理性的人更是如此，常常抱有理性的自负。能力不错的人，往往有过一些成功的经验，不管是小成功还是大成功，如果很少被人Challenge，容易觉得自己英明神武。但是大家忽略了一点，行业是不断发展的，你所具有的知识虽然丰富，但在行业不断变化中依旧是有限的。即使自认为非常理性的人，有时候仍然会误以为，自己提出的方案特别好，模型特别优雅，希望把它执行，或者在全公司大范围内推行，但忽略了抽象知识和具体形式之间有差距。理性往往只适合做知识抽象，对具体问题的解决不一定真的有帮助。当然我们并不是要否定理性的作用，只是要避免过度放大理性会带来的危险。
自上而下的宏大战略往往都是灾难，业界也发生过不少真实的例子，对于一个公司，一个项目，都是如此。
Control除了会带来战略上的问题，还会因为追求控制感而导致企业反应迟钝。
相比Control，强调Context的管理模式有什么好处？
第一、分布式运算，让更多人参与决策，利用集体的智慧。对于组长，因为精力有限，做审批决策只花30分钟，但团队成员他们在一线决策有更丰富的外部信息，它可以花三个小时，做更多的调研之后才判断。
第二、可以更快速的执行，不需要层层汇总，不需要汇总到一处，不需要所有决策在CEO或制作人这里排队列，能够更及时的响应。
第三、充分的外部信息输入。在Control的模式中，任何信息都要到CEO这个节点，靠CEO再分发出去，CEO很大程度变成了公司和外部之间的接口，相比单靠CEO接触外界情况，了解市场行业或者外部环境，让更多的同事，更多节点直接面向行业，信息确实会更充分，角度也不一样。
第四、参与感激发创造力。做同样的事情，如果团队成员知其然，也知其所以然，会比只知道指令，做起来更有意思。这个对于发挥团队成员创造力是有帮助的。
第五、可规模化。Context的建设，表现形式可能是内部的系统，可能是知识共享文档，这些都是可以复用的，是可规模化的。而CEO和Leader们的时间、精力是有瓶颈，靠拼体力，脑力，耐力来解决，是有瓶颈的，是没有规模效应的。
当然，有时候也需要Control：
一、 紧急情况和重点项目。比如重大的玩家口碑危机需要快速响应。重点项目也是如此，如果竞争对手已经逼近，这个时候进行分布式的讨论，自下而上的涌现，来不及解决问题，时间窗口很快就过去了。所以紧急情况和处理重点项目需要Control。
二、 创新业务和新团队早期。如果一个新团队设立，或者一个新Leader刚加入，这个时候需要Control，新业务早期，需要更多支持配备资源的时候，也需要CEO统一协调，主导进展。
三、 不匹配的职位安排。某个岗位的人跟公司理念差距很大，那么他的Leader也是需要Control来干预的，比如一个资深运营同学，之前一直是做强商业化产品，游戏运营以拉收入为主。那么他的Leader在早期也是需要Control的。
