米哈游员工手册.pdf

米哈游员工手册 01 米哈游是天堂，搞不好也是地狱 miHoYo 是一个有着独特文化、理念以及做事行为喜好倾向的地方。尽曾这么听起来显得很不“专业”。相信在很多其他公司入职后会有人告诉你，公司大了，要学着与那些你不喜欢的人也能合作。但在 miHoYo 我们会告诉你，我们是一群什么人，追求着什么，有哪些行为是受到欢迎的，哪些行为是坚决不能存在的。你觉得好，come and join us。你觉得不好，我们同样会很尊重你，只是这里可能不适合你。1.1 我们从来都不是一家游戏公司“miHoYo 不是一家游戏公司。在你看到这一句话之前，或许已经不止一遍的听说过它。可能是面试官在回答问题的时候说到的，也可能是跟某个同学聊天时候讲到的，又或许是江湖上的传言（emmm 我最希望是这种形式 2333），当然也可能这是你第一次看到它。经常有人会问我，一家收入 90%来自游戏的公司，为啥不是一家游戏公司?嗯，如果按照这个标准，倒是无话可说。因为同理，企鹅也是游戏公司，万代是个游戏+塑料小人公司，Facebook，Google，Baidu 都是广告公司。为什么我们说自己不是一家游戏公司，即便大多数钱都是通过游戏赚来的呢？简单来说，确实很多公司，特别是传统工农业企业，用户花钱买的就是它直接生产的东西。但是到了服务业和互联网领域。有些商业模式就变得微妙了起来。比如，某些互联网公司，大量用户都是免费试用其产品的，而其营收可能来自于广告商或者其他业务，这就不举例说明了。另一方面，在交易这一环节的背后，是什么动机，什么目的，让用户去使用或付费，则是个更加复杂的问题，所以，不能简单的因为我们的主要收入来自游戏。就认定我们完全是一家卖游戏的公司。(昨不说我们是卖水晶的公司呢?)更深入的原因，有如下三点：1.我们要几十年轻营下去的是 IP,而不是一款游戏；2.我们是一家科技公司、科技公司、科技公司(重要的话说三遍)；3.miHoYo 从来不把“游戏”当“游戏”看。逐一解释下。先说 IP 这件事。miHoYo 创立的初心。是希望有一天，我们可以像 Macross、EVA、The Matrix 那样，创造出一个 IP，在一代人的心中，留下永生不灭的回忆。就像当年 Macross 初代教会了我什么是三角恋。EVA 让我入了香党，而Matrix 则成了我们公司为之奋斗的终极目标。在创立 miHoYo 之前，其实我也尝试过动画、漫画，但在那个时候，于环境和个人能力来说，并不足以实现。所以，当我们开始选择以游戏作为产品形态的时候起，我们在想的是如何把这件事情做到二十年五十年，甚至更久。单一的游戏产品会老，但 IP 可以很持久。再说为什么我们是一家科技公司，首先 miHoYo 这家公司的创始人，是三位交大计算机(CS)、电子工程(EE)的理工男，我们一直有着对科技的原生追求。其次，我们一直认为，每次文化与娱乐体验的重要升级，都依托在技术革命的基础上。同样，现在人类所掌握的科技还不足以实现我们最终的目标，所以，我们需要研发新的科技来实现。最后来说下此“游戏”与彼“游戏”的差异。游戏于 miHoYo 来讲意味什么?首先它是我们重要内容与 IP 的载体，我们的用户会通过游戏认识我们的角色。了解我们的故事与世界观，这些看似是影视与文学作品中实现的事情，我们的游戏也同样承载。其次，游戏作为游戏本身，必须要实现其好玩的价值。最后，游戏当然是我们重要的商业化手段，但深究付费的动机，我们希望更多的是出于对 IP 的认同，对角色的喜爱，而不仅仅是数值变强。其实，解释这么多，并不是希望别人改变对我们的看法，只要我们自己认定这件事，并持续努力，总有一天，当他们再次看到我的产品的时候，会忍不住犹疑 这好像不只是一款游戏了吧?1.2 这可不是一家正经公司 我先罗列三个事实。问:哪家公司的老板是被怒艹次数最多的?答:miHoYo 的大伟哥。问:哪家公司老板的办公室是最大的？答：miHoYo，因为一整层超过 2000m都是老板的办公室，我们跟 200 多位同学共享一个大平层，没有隔断，没有玻璃门。问:我们公司的组织结构是啥样的?答:请看下面的图解。常见大公司的组织结构图(树状图)miHoYo 的组织结构图 啊，上面那个是草图，我正经来画一下。这就是我们中二的组织结构图 为什么我们是扁平的、自组织的网状结构?又有什么在支撑着这种形式?这就是我现在要解释的事情。树状组织结构是我们常见的大公司的形态，也是一种执行效率蛮高的组织形态。除了大公司，军队等各种常见机构都可以看到清晰的树状组织结构图。在这种结构下，每一个叶子节点只需关注及做好局部的事情即可，如果碰到决策问题，则会层层向上汇报。有些问题直到最终根节点才会被解决，然后再层层传递下去，被层层执行。我们的组织结构，有书上把它称作网状结构，但不同于一般的去中心化网状结构，我们是有局部中心的网状结构。一种我比较喜欢的叫法是:Team of Teams,如字面意思所言，这样一个大的组织，是由几个到十几个相对独立的 Teams 组成的，每个 Team 有一个局部中心。在沟通与决策过程中，每个局部中心会解决自己的局部问题，当涉及到其他部分的时候，这些局部中心可以主动与其它局部中心建立沟通，协同决策。在保证信息足够全局同步的基础上，大多数问题都可以在局部中心，或者几个局部中心的协同下决策解决。这样的组织要运作良好其实对 Team 的核心节点有着更高的要求。1.每一个 Team 的局部中心（可能是 23 个人）。需要有全局的信息、全局的认知，在信息缺乏的时候主动获取其它 Team 的信息；2.每一个 Team 的思考与决策，需要严格基于信息与逻辑；3.每一个 Team 都需要在必要时主动与其它 Team 进行沟通，协同决策。当然，除了 Team 的局部中心外，任何问题，任何一个人都可以在组织或者跨越Team 之间，直接与其他人进行沟通，建立联系。那么，为什么我们会选择这样一种组织方式？或者说，这不是种选择，而是公司发展过程中的自然进化方向。相比树状结构，Team of Teams，越靠近一线的节点，越具有决策力，就是很多的决策，是来自于一线制作者，而不是高高在上的管理层。这正是我们最在意的一点，大家都知道我们在做的，是希望年轻人真欢的创意产品。我们相信，最接近用户的人，在一线制作产品的人，是最清楚什么才是美的，什么才是大家喜欢的，因为这也是我们自己所喜欢的。在 miHoYo，每一个人都是创作者，每个人都在创作用户喜欢。我们也喜欢的东西，都在尝试在自己最懂的专业领域去突破，做出别人做不出的东西。所以。最懂的人，才是应该拍板的那个人。当然，Team of Teams 也有它的缺点。我们在这种组织里需要更高的沟通成本，更高的节点能力，而就单纯执行这件事情来讲，或许并不如树状结构高效。但是，敏捷效率，这就是我们的选择。扁平，不意味着我们是一棵比较宽大的树，每层叶子节点比较多，不是这样。扁平，意味着这是一个每个节点可以自主决策、自主进化的组织。Team 本身也是在演化、变化的。当然，扁平还意味着，我们认为在 miHoYo，人人平等，我们尊重每一个同学。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的人力成本如何，技术风险的高低，甚至某个同学熬夜加班效率特别高 233，等等这些都是 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 的。2.3 我会被开掉吗？我会不会被开掉？答案是有可能的，而且是时刻都存在这个可能性。在被开掉这个问题上，我们倡导负责考核绩效的 Leader 不许手软。历史的数据告诉我们：每四个离开 miHoYo 的同学，其中有一个就是被辞退的。那么我们一起盘点一下，当哪些情况发生时，你会触发这一“成就”。文化的匹配性 miHoYo 有我们自己的文化。这种文化并不是写在纸上，贴在墙上的那种。可以说我们的文化是一种味道，我们强调这种味道。这种味道来自于我们倡导的价值观，或者来自于经过集体多年磨合出的一套认为正确、应被倡导的工作习惯。我们希望在人才筛选和匹配的过程中，能够选择到具有相同味道的人。然而毕竟五湖四海汇聚一川，我们理解每个人的味道都会不一样。但如果 miHoYo 的味道让你很难接受，让你发自内心的不认同这个说到做到、有话直说、追求极效、只认功劳的价值观，或是在这样的价值观环境以及工作习惯下让你感到并不舒服。我们会请你离开。但请相信这不代表着你错了，也不代表你不优秀，而是我们不合适。就像恋爱一样：我们尝试了开始。但在一起生活之后，才发现没办法认同对方的习惯和价值观，这时无论谁提出分手都是最好的选择。能力与认知滞后 我们相互之间喜欢以同学相称，字面意思就是共同学习。共同成长。如果把 2012年的 miHoYo 比喻成一艘小帆船，那么 2018 年的 miHoYo 或许就是一艘大商船。我们都明白这个道理：如果你仍然只掌握着驾驭帆船的能力，但今天的你站在了这艘大商船上，那么你的能力就跟不上组织的发展了。如果我们的目标是航空母舰，那么在这个组织不断变强的过程中，无论是舰长还是海员，组织对每一个人的能力要求都在提升。所以在我们发展的过程中，你必须要能跟得上组织发展的速度，不断去提升自己的认知水平。举个例子：如果在 2006 年，你无论如何给一位诺基亚工程师讲述今天智能手机的概念，他都不会理解。最糟糕的是，如果那位工程师自我感觉良好地认为“老子手机，天下第一”，基本他也就离手动再见不远了。而如果有一天你成为了那位“工程师”，那么在不远的将来，你也就有可能“被”离开了。因为我们要去更大更远的地方了，且这艘舰船也并不具备慈善机构的功能属性。高压线 踩高压线都会被电死。其踩法主要有两种：一种是因为蠢而踩，而另一种是真心实意，诚心诚意的踩。前者多数出于类似炫耀，觉得事儿不大、得瑟、吹牛逼、自欺欺人等等动机（实际的表现是将工作资料晒出或者将内部的信息/同事信息流出等等），这种踩法可以被归纳为蠢，而且很有可能造成很多你根本 hold 不住的结果。所以这些因套而触犯高压线的同学事后往往会觉得自己很“窝囊”。其实最好的规避方式就是：在高压线面前，Dont do anything stupid”，绝不在危险边缘试探。另一种踩法则是真心实意、诚心诚意的踩，这就比较危险了。针对这种“明知山有虎，偏向虎山行的同学，一旦让我们明确这种动机，我们并不会自己去处理这个问题。miHoYo 2017 年就成为了徐汇区公安局网安大队的重点保护单位，警察叔叔会直接立案并介入调查（他们一定有办法掌握他们想知道的东西）。游戏行业曾经出现过因蓄意信息泄露导致刑法落地的案例，我们不希望任何人成为 miHoYo 的第一例。我搞砸了怎么办?会不会被开掉?miHoYo 没有一次因为谁犯了错而开除他的历史。任何错误都是反思教训的机会，如果犯错就该受到惩罚，那么 miHoYo 就会变成一个谁都不敢多做事的公司了。如果多做多错，那么价值从哪里来？我们鼓励尝试，鼓助创造更多的价值。工作中犯错在所难免，我们绝不苛责犯错的结果，更不会因为犯错就开掉谁。但我们也绝不认为犯错是件天经地义的事，尤其是在研发环境中。我们主张组建能力高密度性的团队;每个人都很强，在执行中就会降低犯错的几率。就算你是个毕业生或初学者，也不能认为自己就矮了别人一头，犯错就是天经地义的，要为别人给你擦屁股这件事而感到着愧。想不犯错误就要认识到自己弱。就要鞭策自己迅速成长起来，变得更强。什么时候你可以炒了米哈游?当你认为自己的能力被低估了、自己被当做傻 X 看了、我的汇报关系没有资格评价我等等这时欢迎你直接发邮件（)给大伟哥，告诉他：“我的薪酬、奖金对不起我付出的贡献”请放心，他一定亲自会处理这件事的。03 路人英雄的养成方法 不是因为我们有这样的愿景，所以才有了这样的一家公司。而是因为我们有了这样的一群人在一起，才会做出这样的事情，成为这样的一家公司。那什么才是这样一群人，与其他群体的本质差异？就是我们的理念与文化。一群理念一致，文化相融的人在一起，他们发现彼此的理想是相似的，做事的方法是一致的。从此，他们集结起来开始拯救世界，成为英雄。所以，请铭记我们的文化：说到做到，有话直说。只认功劳，追求极致。3.1 说到做到 什么是”说到做到”？“说到做到”的意思是，在 miHoYo 内，以任何形式作出的承诺，都应该在承诺的时间内，保证质量的完成。承诺的形式可能是一封邮件、一个 TAPD 上的任务、一段微信上的聊天，也可能是在走廊里跟别人说了一句话：”诶，这个东西我今天晚上给你做好。”那么就要在你所承诺的时间节点保证质量地把它完成，这就是说到做到的意思。为什么要”说到做到”？说到做到是项目能够正常推进的最基本的执行力保证。如果每个人的承诺不能够按时兑现的话。那我们就无法基于这个承诺去做一个更大的团队的计划，我们的产品计划就全都是空谈。当然，作为一个数字娱乐产品，在软件工程中会碰到各种各样的风险，所以更需要我们可以科学的预估，科学的做出计划。说到做到，就是这样一个十分基础的要求。怎么做到”说到做到”？1.先搞清楚任务需求，才能给出靠谱的承诺 在一项任务的讨论阶段。如果你对其中的目的、要求存在疑问时，务必当面提出来。千万别抱有”应该是这么个意思吧”之类的想法，很可能你的理解和现实会有极大的偏差。有哪些基本信息是你需要明确的？1）交付结果是什么？（是一个工作计划的邮件？完成一个功能的代码？还是下班的时候把空调关掉？）2）交付的衡量标准，完成这项工作结果的程度。你们对好坏的衡量标准的认识是不是一致的？（能用？易用？友好？什么程度呢？）3）交付的截止时间，也就是我们常说的 Deadline。我们希望就算你的 Leader 或者合作伙伴没有很清楚地定义这些问题时，你也要和他非常明确地沟通清楚，因为这会直接影响到你是否能说到做到。除了这些直接要求以外，任务和任务之间的上下游关系，是否存在配合这项任务的人等这些辅助信息，也都能帮助你更好的理解这项任务。在充分了解任务的背景信息后，尽可能把这项任务拆解成细分行动，并评估清楚每一个小行动所需的时间和资源，你才能给出一个真正意义上务实的、可达成的承诺。2.对于没有把握的事，一定不要给出承诺 主要体现在三点：1）当工作任务具有不确定性时，正确且安全的做法是：不要草率做出承诺。你应该把你看到的不确定性因素抛出来，并且主动去了解这些不确定的情况。2）对于无法评估的不确定性问题，先进行尝试，摸一摸路，估计一个预研时间。等预研时间到了，或者有了阶段性结论，再进行下一步的评估。3）绝对不要因为：碍于面子、Push 自己不要拖延或迫于组长压力等愚蠢的理由做出你预期无法完成的承诺 特别对于新人，或者对于项目情况不了解的时候。请务必记住，不作出承诺才是最负责的做法。否则耽误的会是整个项目的进度预期，而不仅仅是眼前的这一个任务。3.充分细分&累加时间，是一个靠谱的预估方法 为了能够评估出一个合理的任务完成时间，我推荐一个方法：在充分了解需求的情况下把每一个需求和目标进行细分，细分到不能再细分为止，然后把这每一细分项的时间算出来，再把它们累加起来，应该会有一个相对靠请一些的结果。一般来讲，一个细分任务的时间不应该超过 2 天时间。否则，我会认为这个任务一定有可以继续细分的空间与必要。3.2 有话直说 什么是”有话直说”？有话直说的意思是：在我们公司内，当你发现一个问题，或者感觉哪里做的不对的时候，唯一正确的做法是：找到这个问题的当事人，当面向他客观陈述这个问题，这个就是有话直说。这个问题，可能是产品上的问题，比如说你觉得这个地方策划设计的不对，也可能是团队上的问题，比如说你觉得某个地方我们运转不对，或者说你认为某个人好像没有尽到应尽的职责。不论什么问题，我们都应该在看到这些问题后的第一时间当面有话直说。为什么要做到”有话直说”？有两个重要的原因：1.有话直说是通往卓越产品的重要保障；2.鸵鸟姿态面对小问题，必将酿成大炸弹。我分别来解释一下。先说第一条：有话直说是通往卓越产品的重要保障。在 miHoYo 刚刚成立的时候，我们几个创始入共同立下了一个规则：无论遇到什么问题，我们都要有话直说。有话直说并不容易，但是作为一家创意企业，有话直说是通往卓越的唯一途径。我们希望自己和 miHoYo 都能不断进化，而为了实现这一点，我们需要对彼此极度坦诚，有话直说。因为我们知道任何一个人在团队里面，不管是制作人也好，是策划负责人也好，是美术负责人也好，都是有他的局限性的。简单来说。作为一个人，他一定有其擅长的地方，和不擅长的地方；有他特别容易关注的地方，和容易忽视的细节。所谓人无完人，人就是这样一种生物。但我们对于产品的要求是无限接近于完美的，那怎么办呢？必须通过一个团队来取长补短，互相弥补彼此的缺陷，发挥长处。那如何做呢？就是要在团队里面，可以听到来自不同角度的声音和意见，所以我们需要有话直说。对于任何一个人，当我们觉得他负责的东西有问题的时候，应该立刻告诉他，这样才能让他获得一个更全面的认识，避免个人视野的局限，帮他建立一个全面的认知。只有看到的问题全面了，再以严密的逻辑进行判断，才有可能做出比较好的决定。这里有一个很有趣的现象。大家都知道，我们公司没有主美，主程这样的 Title，而只讲美术组长，程序负责人。为什么呢？因为主 x。往往会给人一种，他说了算，对错都由他来一言定之的印象。这样以难免个人影响太重，难免在获得部分正确判断的同时也放大了个人缺陷。而 XX 负责人，或 XX 组长则意味着：这个岗位的同学，负责组织整个团队一起来取长补短，发挥每个人擅长的事情，最终把一个问题解决好。他是组织者，也是负责人，但不等于其他人要言听计从。每一个人都拥有对自己负责事情的决策权，也必须遵循有话直说，开放地接收各种意见。再说第二条：鸵鸟姿态面对小问题，必将酿成大炸弹。在 miHoYo 短暂的发展史上。我们也曾经犯过类似的错误。冰冻三尺非一日之寒，大问题也都是因各种小问题没有被及时解决从而变得愈发严重。通常当问题还在初期阶段时，解决起来不仅成本小，方式也多。但如果问题没有得以及时暴露，经过不断积累，它会像病毒一样扩散，破坏面越来越大。这时再去解决它就可能会牵一发而动全身，付出的代价无法估量，甚至导致团队决裂、产品最终失败。所以有话直说，可以保证在问题还比较小的时候就暴露出来，并把它及时解决。我们坚信，我们应当把问题和分歧摆到桌面上，从而及早地暴露问题，及时的解决问题。“有话直说”该怎么做？1.当面直接说，及时说，绝不在背后说 当看到任何项目上的问题、产品的缺陷、项目成员的不足的时候，当遇到跟团队其他人意见不合或者对某些事情做法不满的时候，唯一正确的做法就是找到当事人，当面跟他反馈、吐槽甚至吵架。直面所有的问题，有话直说，创造环境做直接的沟通，这是正确的做法。对任何公司同事，当面不会说的事情也绝不在背后议论。一个公司里直在讨论问题的场合没有声音而背地里有嗡嗡嗡的声音，就是不正常的表现。这种嗡嗡嗡的声音大都是以匿名、小圈子的形式存在的；小团体甚至是办公室政治的形成大多都是从两个人同时吐槽同一个对象开始的。背地吐槽对任务、团队、尤其是对你自己，没有任何正面作用。非但不会解决问题反而会增加问题的复杂度。2.客观陈述，对事不对人 有话直说的文化有时候会让人不适，尤其在存在分歧的时候，我们有话直说的唯一目的就是让问题或者分歧暴露出来并朝着好的方向去发展。因此只有客观陈述事实，只针对”事”本身才能推动问题的解决，针对”人”解决不了任何问题。表达时怎么算是对”事”，怎么算是对”人”：对”事”：对事情本身下判断（正确与否的结论）、给支撑结论的论据（问题定位）或提供处理方式的建议（解决问题的方法）。如”这打出来的伤害太低了（判断、结论），你的圣痕搭配得有问题（问题定位），换个”薛定谔上”输出会更高（解决问题的方法）”。对”人”：对人（人格、个性）产生攻击行为。如：”某某就是不行”，”某某完全不懂”。3.直面冲突，求取共识 很多人以为，掩盖分歧是维持和睦最容易的方法，这种观点大错特错。回避冲突也就回避了解决冲突的机会；躲过了小的矛盾，之后往往会有大的矛盾，甚至会导致人与人的疏离。只有直面且积极解决小的矛盾，才会更好地维持长久的信任关系。认真处理分歧，有话直说，当事方之间开放、坚定地进行高质量的反复讨论，细心梳理所有问题的过程，这些方法都非常有用。因为它们有助于双方了解此前不清楚的情况，这是有话直说的另一层含义。我们需要做三件事：1）把我们的真实想法摆在桌面上；2）存在经过深思熟虑的分歧，但人们愿意在相互了解的过程中更改观点；3）如果分歧依然存在，拥有一种大家一致同意的决策方式（如投票或者拥有清晰的权威）。以便我们能够不带怨气地把分歧留在身后。我们相信任何组织或任何人际关系想要保持的好，这些都是必需的。我们极力鼓励大家有话直说。直面冲突，求取共识。4.保持开放心志，着眼大局 我们充分鼓励大家有话直说，但这并不意味着你提出的建议或吐槽就一定要被采纳和解决。影响一件事对错与否的判断因素有很多（可能是时机、获取背景信息的丰富程度、看待问题视角等等），但我们最终会把决策权交给具体负责这项任务的同学（他所掌握的信息不但是最全面的，同时承担的责任也是最大的）。当观点争执不下，然而事情还要继续推进的时候，就需要由这位决策同学出来确定路径并执行落地。如果决策已出，就必须要放下个人的异议（事后会进行决策复盘），全力以赴去达成目标。针对有话直说我们总结一下，在 miHoYo 最让人痛恨的有这 5 种人：1.马后炮的，事后会说”你看，当时我就觉得这地方不对”；2.当面不说，喜欢在背后议论人的，拉帮结派搞小团体的；3.分不清楚什么是对事，什么是对人的；4.好好先生，明明看到了问题就让问题烂着，而无动于衷的；5.难我独尊，个人意志高于集体意志的。最后，必须说明，有话直说一人一票。这是关于有话直说必须跟大家强调的一件事情：有话直说的目的是暴露问题。任何人提出来的意见，可能是对的，也可能不对。可能只是提问者自己的另一种局限视角。所以，有话直说绝对不意味着说了必须改，也不应该被滥用做少数服从多数。我们一直以来的理念都是，谁在一线做这件事情，谁最了解一线的情况，谁来做决定，并为结果负责。有话直说，是为了帮这个决策者，更多的看到全局的信息与意见，然后让他可以在一个更丰富的信息下，做出更好的决定。3.3 只认功劳 什么是”只认功劳”？只认功劳，也可以说是以结果为导向。有两层意思：1.在 miHoYo，我们对一件事情或一个人的首要评判标准是：所做事情的结果是好是坏。只有在一件事情输出了好的结果的前提下，才有继续去评判实现方法是否合理，是否科学的意义。而一件事情只要结果没做好，什么管理井井有条，团队人人开心，都是扯淡。2.miHoYo 一直崇尚的理念是跟优秀的人在一起，然后做出优秀的事情，然后给予大家优秀的回报。所以我们从来不会论资排辈，对一个人最重要的评价标准就是做出了什么样的结果。结果好，我们就要给予他相对应的优秀的回报，不论他是新人还是老手，也不论职位高低。为什么要”只认功劳”？“只认功劳这个企业文化，是为了保证两点。第一点叫做”经营第一”的原则。别看我们今天讲企业文化，而且我们把企业文化讲得这么重要，我还是要实事求是的告诉各位：在企业发展当中排第一位的是经营。管理和我们内部各种文化制度只是第二位的事情。经营就是面向市场，满足用户需求，赚取利润。miHoYo 这个组织存在的唯一价值就是满足目标用户的需求，为目标用户创造价值，赚取合理的利润。如果我们不能为目标用户创造价值，满足目标用户的需求，那我们谈公司制度很健全，企业文化很先进，人才很优秀，都是无稽之谈。我们看那些公司，整天内部开会研究学习公司管理。研究如何让公司流程并并有条，却很少去面向市场，研究用户需求，研究如何做好产品，这样的公司管理再好也会因经营不善而必然倒闭。我们的企业文化再好，但是我们做出来的产品玩家不真欢，那这个企业文化是没有意义的。因此我们的企业文化必须保证我们做出来的产品是符合用户需求，为用户创造价值的产品，这样的企业文化才是有意义的。现在大家普遍知道，”苦劳”是对绩效对公司没有帮助的。但是在规实中，很多同学有了”苦劳”之后，就会