米哈游员工手册.pdf
《米哈游员工手册.pdf》由会员分享,可在线阅读,更多相关《米哈游员工手册.pdf(63页珍藏版)》请在咨信网上搜索。
1、米哈游员工手册 01 米哈游是天堂,搞不好也是地狱 miHoYo 是一个有着独特文化、理念以及做事行为喜好倾向的地方。尽曾这么听起来显得很不“专业”。相信在很多其他公司入职后会有人告诉你,公司大了,要学着与那些你不喜欢的人也能合作。但在 miHoYo 我们会告诉你,我们是一群什么人,追求着什么,有哪些行为是受到欢迎的,哪些行为是坚决不能存在的。你觉得好,come and join us。你觉得不好,我们同样会很尊重你,只是这里可能不适合你。1.1 我们从来都不是一家游戏公司“miHoYo 不是一家游戏公司。在你看到这一句话之前,或许已经不止一遍的听说过它。可能是面试官在回答问题的时候说到的,也
2、可能是跟某个同学聊天时候讲到的,又或许是江湖上的传言(emmm 我最希望是这种形式 2333),当然也可能这是你第一次看到它。经常有人会问我,一家收入 90%来自游戏的公司,为啥不是一家游戏公司?嗯,如果按照这个标准,倒是无话可说。因为同理,企鹅也是游戏公司,万代是个游戏+塑料小人公司,Facebook,Google,Baidu 都是广告公司。为什么我们说自己不是一家游戏公司,即便大多数钱都是通过游戏赚来的呢?简单来说,确实很多公司,特别是传统工农业企业,用户花钱买的就是它直接生产的东西。但是到了服务业和互联网领域。有些商业模式就变得微妙了起来。比如,某些互联网公司,大量用户都是免费试用其产品
3、的,而其营收可能来自于广告商或者其他业务,这就不举例说明了。另一方面,在交易这一环节的背后,是什么动机,什么目的,让用户去使用或付费,则是个更加复杂的问题,所以,不能简单的因为我们的主要收入来自游戏。就认定我们完全是一家卖游戏的公司。(昨不说我们是卖水晶的公司呢?)更深入的原因,有如下三点:1.我们要几十年轻营下去的是 IP,而不是一款游戏;2.我们是一家科技公司、科技公司、科技公司(重要的话说三遍);3.miHoYo 从来不把“游戏”当“游戏”看。逐一解释下。先说 IP 这件事。miHoYo 创立的初心。是希望有一天,我们可以像 Macross、EVA、The Matrix 那样,创造出一个
4、 IP,在一代人的心中,留下永生不灭的回忆。就像当年 Macross 初代教会了我什么是三角恋。EVA 让我入了香党,而Matrix 则成了我们公司为之奋斗的终极目标。在创立 miHoYo 之前,其实我也尝试过动画、漫画,但在那个时候,于环境和个人能力来说,并不足以实现。所以,当我们开始选择以游戏作为产品形态的时候起,我们在想的是如何把这件事情做到二十年五十年,甚至更久。单一的游戏产品会老,但 IP 可以很持久。再说为什么我们是一家科技公司,首先 miHoYo 这家公司的创始人,是三位交大计算机(CS)、电子工程(EE)的理工男,我们一直有着对科技的原生追求。其次,我们一直认为,每次文化与娱乐
5、体验的重要升级,都依托在技术革命的基础上。同样,现在人类所掌握的科技还不足以实现我们最终的目标,所以,我们需要研发新的科技来实现。最后来说下此“游戏”与彼“游戏”的差异。游戏于 miHoYo 来讲意味什么?首先它是我们重要内容与 IP 的载体,我们的用户会通过游戏认识我们的角色。了解我们的故事与世界观,这些看似是影视与文学作品中实现的事情,我们的游戏也同样承载。其次,游戏作为游戏本身,必须要实现其好玩的价值。最后,游戏当然是我们重要的商业化手段,但深究付费的动机,我们希望更多的是出于对 IP 的认同,对角色的喜爱,而不仅仅是数值变强。其实,解释这么多,并不是希望别人改变对我们的看法,只要我们自
6、己认定这件事,并持续努力,总有一天,当他们再次看到我的产品的时候,会忍不住犹疑 这好像不只是一款游戏了吧?1.2 这可不是一家正经公司 我先罗列三个事实。问:哪家公司的老板是被怒艹次数最多的?答:miHoYo 的大伟哥。问:哪家公司老板的办公室是最大的?答:miHoYo,因为一整层超过 2000m都是老板的办公室,我们跟 200 多位同学共享一个大平层,没有隔断,没有玻璃门。问:我们公司的组织结构是啥样的?答:请看下面的图解。常见大公司的组织结构图(树状图)miHoYo 的组织结构图 啊,上面那个是草图,我正经来画一下。这就是我们中二的组织结构图 为什么我们是扁平的、自组织的网状结构?又有什么
7、在支撑着这种形式?这就是我现在要解释的事情。树状组织结构是我们常见的大公司的形态,也是一种执行效率蛮高的组织形态。除了大公司,军队等各种常见机构都可以看到清晰的树状组织结构图。在这种结构下,每一个叶子节点只需关注及做好局部的事情即可,如果碰到决策问题,则会层层向上汇报。有些问题直到最终根节点才会被解决,然后再层层传递下去,被层层执行。我们的组织结构,有书上把它称作网状结构,但不同于一般的去中心化网状结构,我们是有局部中心的网状结构。一种我比较喜欢的叫法是:Team of Teams,如字面意思所言,这样一个大的组织,是由几个到十几个相对独立的 Teams 组成的,每个 Team 有一个局部中心
8、。在沟通与决策过程中,每个局部中心会解决自己的局部问题,当涉及到其他部分的时候,这些局部中心可以主动与其它局部中心建立沟通,协同决策。在保证信息足够全局同步的基础上,大多数问题都可以在局部中心,或者几个局部中心的协同下决策解决。这样的组织要运作良好其实对 Team 的核心节点有着更高的要求。1.每一个 Team 的局部中心(可能是 23 个人)。需要有全局的信息、全局的认知,在信息缺乏的时候主动获取其它 Team 的信息;2.每一个 Team 的思考与决策,需要严格基于信息与逻辑;3.每一个 Team 都需要在必要时主动与其它 Team 进行沟通,协同决策。当然,除了 Team 的局部中心外,
9、任何问题,任何一个人都可以在组织或者跨越Team 之间,直接与其他人进行沟通,建立联系。那么,为什么我们会选择这样一种组织方式?或者说,这不是种选择,而是公司发展过程中的自然进化方向。相比树状结构,Team of Teams,越靠近一线的节点,越具有决策力,就是很多的决策,是来自于一线制作者,而不是高高在上的管理层。这正是我们最在意的一点,大家都知道我们在做的,是希望年轻人真欢的创意产品。我们相信,最接近用户的人,在一线制作产品的人,是最清楚什么才是美的,什么才是大家喜欢的,因为这也是我们自己所喜欢的。在 miHoYo,每一个人都是创作者,每个人都在创作用户喜欢。我们也喜欢的东西,都在尝试在自
10、己最懂的专业领域去突破,做出别人做不出的东西。所以。最懂的人,才是应该拍板的那个人。当然,Team of Teams 也有它的缺点。我们在这种组织里需要更高的沟通成本,更高的节点能力,而就单纯执行这件事情来讲,或许并不如树状结构高效。但是,敏捷效率,这就是我们的选择。扁平,不意味着我们是一棵比较宽大的树,每层叶子节点比较多,不是这样。扁平,意味着这是一个每个节点可以自主决策、自主进化的组织。Team 本身也是在演化、变化的。当然,扁平还意味着,我们认为在 miHoYo,人人平等,我们尊重每一个同学。02 我是一只萌新大佬 特别提醒:入职指引,请看另一本书哦 剩下的,请翻开下一页,233 老同学
11、可以跳过看第三章咯 2.1 瑟瑟发抖的第一天早上 当第一天前台小姐姐把你带到工位的时候,或许你会看到,一群群人站着围成一圈在轮流说话。Emmm说明你已经错过第一天的早会了!如 1.2 中所讲,我们是一个 Team of Teams 的组织形式。所以,每天早上,我们都会以 Teams 为单位进行早会。早会制度从 miHoYo 成立第一天,大概是 2011年春天的某一天开始就存在了。作为 miHoYo 少有的要求严格执行的制度之一。早会对于日常工作有着十分重要的意义。基于敏捷开发的原则,项目上的任务每天都在发生变化,出现各种问题。早会的重要意义在于,集合某一功能的相关人员,高效同步开发进展与问题,
12、以达到目标同步,问题暴露,进度管理等目的。注意,早会只提出问道,不进行讨论解决问题!因为没那个时间。特别说明,作为一项全员皆知的规定,任何小组成员,早会迟到要买水果。2.2 我要如何工作?在 miHoYo,我们一直秉持着我们的团队理念,就是“跟优秀的人在一起,做出优秀的事情,获得优秀的回报”。那么在加入我们之后,应该如何去做优秀的事情?如上一节所讲,我们在努力构建一个扁平的自组织结构的组织,并努力尽一切可能保持内部信息的透明与流动。那么在这个背景下,每一个人该如何工作,如何思考决策。答案就是:Context,not Control!Context,not Control 的理念来源于 Netf
13、lix。先解释一下字面意思:什么是 Context?一切做决策需要的背景信息,都叫 Context。比如:我们项目目标用户是啥,我们的历史数据如何,一测用户平成是咋样的反馈,做一个 Feature的人力成本如何,技术风险的高低,甚至某个同学熬夜加班效率特别高 233,等等这些都是 Context。那什么是 Control 呢?一切流程化的执行手段,比如:OA 审批流程,指令拆分分解,委员会投票表决等。那对我的工作而言,这两者是啥区别?“Control”的工作方式意味着,严格遵守你的上司给你下达的指令,不必去多想他为什么这么决策,只管执行好就行,也不用考虑这个指令之外的事情,只对下达的这个命令范
14、畴内的事情来负责。如果需要其他人来配合那就拆分,然后分配任务出去,然后同样严格控制他们来执行。这种工作方式,在很多大型企业和组织,都是十分常见的。“Context”的工作方式则不一样。当进行一个任务的时候,我们首先需要全面的了解上下文的信息,基于自己对眼前工作的专业的认识,结与相关人员充分沟通同步认知,然后做出好的解决方案并执行完成。举一个具体的例子,当我们要实现一个怪物的自动索敌跟踪功能的时候。“Control”的故事会是这样:客户端主程和策划讨论完成后,基于他的知识与经验,告诉具体做 Feature 的程序 A,用 Unity 的 NavMeshAgent 来创建Navmesh,然后实现一
15、个寻路算法,来满足需求上的功能。Context 的故事则是这样的:客户端组长拉具体的负责实现的程序 A 同学和策划进行深入讨论,告诉他要做一个这样的 Feature,并建议可以用到 NavMeshAgent这样的功能。看起来故事的开头并没有太大的差别,甚至很多时候这两个故事的结果也会差不多,程序 A 顺利使用 NavMeshAgent 实现了 Feature,并通过了验收与测试。但是当我们的项目越来越大,越来越复杂的时候,这两条故事线的发展会天差地别。Control 线的,程序 A 看完了文档,看完了策划的需求文档,开始动手实现,一天后他实现了功能,在一个测试场景里跑了一下,发现没有太大问题,
16、他喊策划来验收了一下,从而提出了修改意见,然后自己跑了跑也发现问题不大。这时候程序 A认为再过一天修完 Bug,close 掉这个 feature 毫无风险,第二天,修完 bug 后他把这个功能放到游戏大世界中去。这是一个面积一万倍于测试场景的世界,而且地形的复杂程度也比测试场景要高很多,不过地形复杂这件事早在程序的意料之中,他准备再花一整天时间来好好处理各种意料之外的情况。想到这里。他按下了NavMesh 的 Build 按钮,起身准备去接一杯水,1 分钟后程序 A 回到自己的工位,他发现这个还没有 build,他敏捷的意识到出问题了,这个世界太 tmd 大了,光离线构建一个 NavMesh
17、 就要好久,这可能会是个坑。程序啜了一口水,想了想,马上就要周版本打包了,这个任务还是得 close。主程说了让我用这个方法,他应该心里有数吧,反正我毫无 bug 的把这个功能实现完了。策划也验收得差不多了,就这样先提交一版吧,程序 A 不知思考了几分钟,正等他回过神来的时候,NavMesh 已经构建完了。在 PC 上这还是挺快的嘛,程序 A 继续开始做其他的功能与测试,并准时在打包前提交了全部代码。几个小时后,当晚的周版本打包完成了,大家开始下载,不知为何今晚的下载速度有些慢大家又开始抱怨这个 WiFi AP 太卡了,都集中在同一时间下载。终于,十几分钟后,有人下载好了,开始回归 Featu
18、re。“卧槽,怎么闪退了?”一个用iPhone 7 的人喊到、“是啊,我这里好像也闪退了。”越来越多的人发现自己的设备无法正常进行游戏。简单统计后,大家发现,除了最高端设备,好像其他的都很容易闪退。经过了 1 个小时的排查后,大家发现,这周周版本的包比上一周整整大了 500mb,而这其中 95%都是内存爆炸,都是因为太多 NavMesh 的载入而导致的。当目光投向程序 A 的时候,他很坦然地承认了问题,确实看来不能这么做。然后他用比别人更专业,更精准的语言来描述了问题,以及在当前 Solution下无解的程度。现在皮球回到了客户端主程的身上,在忙碌的周版本的午夜,他的疲惫显而易见的浮在脸上。因
19、为屁股后面还排了好几个人在反馈问题。PM 还在问他要不要重新打包好验收其他功能,给他用来思考这个问题的时间只有不到一分钟。那肯定是没办法离线缓存所有的 NavMesh 啊。这个世界太大了,是的,程序A 附和道,然后他继续在等待新的指示。主程叹了一口气。在叹气的这蓄须臾之间他想了很多,今晚的下班时间应该又是 3 点以后了吧;这个寻路的功能这么做下去恐怕要重新设计了;恐怕没法三言两语就把后续的走路时间给讲清楚,他自己还需要去思考更多;还有,他还想到了这项目再这么做下去,简直就是个无底深渊 在另一条世界线上,Context 线的故事,则完全不同,程序 A 还在会议室里跟策划讨论,这次的会议有点长,客
20、户端组长已经忙别的去了。“这个功能,要用在哪?地下城?”“嗯,不止地下城,大世界也会有。”策划答道。嗯,地下城还好说,除了地形之外,其他跟崩三差不多,“那大世界是啥需求?怪可以随处跑吗?”“可以。”策划随口答道,这在他看来是跟其他毫无差别的需求,十分平常。而此时,程序 A 脸色沉了下来,见程序 A 没有爽快的接锅,策划同学眉头一皱,发现事情并不简单。“有什么问题吗?”他试探性低问道。“有,你确定世界这么大,怪的活动范围是不受限制的对吧?”程序 A 又确认了一遍。“是的,至少是可以被拉到很远的地方的。”策划回答道。“我先去了解一下NavMeshAgent 的功能吧,现在还没法确定这个功能怎么做。
21、”好吧,虽然 PM要求的需求评审时间快到了,但此时好像也只能这样了。“那么有什么问题随时找我吧,如果有问题,我们也可以想想其他的解决方案”,策划说到。两人起身走到门口,策划突然停住了脚步,因为在他看来这个需求十分平常,不是所有游戏都是这样的吗?他觉得这个问题必须问清楚。于是他问道:“我们跟其他游戏在实现上有什么不同吗?”正在翻阅手机的程序 A 抬起头:“有很大的不同啊”,他放下手机,上面显示着 NavMeshAgent 的文档。他开始跟策划解释为什么有巨大的不同,平时少言寡语的程序 A,像是打开了封印千年的话匣子,为什么要离线缓存多大的 Mesh,如果 Runtime 计算会不会卡,异步 Lo
22、ad 我们可能要自己实践,等程序 A 再次闭上嘴的时候,他自己觉得自己的脑中貌似已经有了一个大概的Solution 了。策划一直听完了程序 A 的陈述,偶尔插一两个问题,虽然有些细节他不清楚,但大概意思是 get 到了。好歹我本科也是读 CS 的呢,策划自己心里盘算着。这场会议,终于在近两个小时的讨论后结束了。后来程序 A 了解完了 NavMeshAgent 的功能向程序组长表示,直接来用并不靠谱,但在长期的沟通中,他们都清楚这个 Feature 还是必须要做完,再后来他们又去找了工具组,引擎组,大家一起讨论了一个改造 NavMeshAgent 的方案,基于各方面的支持,先实现了一版功能。然后
23、,又是几周的迭代和反馈测试,才最终把这个功能稳定下来。Context 线的故事讲完了,如果你问我为什么中间没有写,策划 SB 吗?程序是不是老油条这样的桥段。我会告诉你,并不是他们多么的厉害与资深,而是他们在长期的沟通中,已经完全同步了。互相理解是因为,在同样的背景信息(Context)下,基于逻辑,得出了同样的结论。段子说完了,那要讲讲为什么我们的做事方式是“Context,not Control”呢?在我们看来,Control 往往会带来一些危险,人类在判断自己的理性控制能力时会有一种幻觉,对于聪明理性的人更是如此,常常抱有理性的自负。能力不错的人,往往有过一些成功的经验,不管是小成功还是
24、大成功,如果很少被人 Challenge,容易觉得自己英明神武。但是大家忽略了一点,行业是不断发展的,你所具有的知识虽然丰富,但在行业不断变化中依旧是有限的。即使自认为非常理性的人,有时候仍然会误以为,自己提出的方案特别好,模型特别优雅,希望把它执行,或者在全公司大范围内推行,但忽略了抽象知识和具体形式之间有差距。理性往往只适合做知识抽象,对具体问题的解决不一定真的有帮助。当然我们并不是要否定理性的作用,只是要避免过度放大理性会带来的危险。自上而下的宏大战略往往都是灾难,业界也发生过不少真实的例子,对于一个公司,一个项目,都是如此。Control 除了会带来战略上的问题,还会因为追求控制感而导
25、致企业反应迟钝。相比 Control,强调 Context 的管理模式有什么好处?第一、分布式运算,让更多人参与决策,利用集体的智慧。对于组长,因为精力有限,做审批决策只花 30 分钟,但团队成员他们在一线决策有更丰富的外部信息,它可以花三个小时,做更多的调研之后才判断。第二、可以更快速的执行,不需要层层汇总,不需要汇总到一处,不需要所有决策在 CEO 或制作人这里排队列,能够更及时的响应。第三、充分的外部信息输入。在 Control 的模式中,任何信息都要到 CEO 这个节点,靠 CEO 再分发出去,CEO 很大程度变成了公司和外部之间的接口,相比单靠CEO 接触外界情况,了解市场行业或者外
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 米哈游 员工 手册
1、咨信平台为文档C2C交易模式,即用户上传的文档直接被用户下载,收益归上传人(含作者)所有;本站仅是提供信息存储空间和展示预览,仅对用户上传内容的表现方式做保护处理,对上载内容不做任何修改或编辑。所展示的作品文档包括内容和图片全部来源于网络用户和作者上传投稿,我们不确定上传用户享有完全著作权,根据《信息网络传播权保护条例》,如果侵犯了您的版权、权益或隐私,请联系我们,核实后会尽快下架及时删除,并可随时和客服了解处理情况,尊重保护知识产权我们共同努力。
2、文档的总页数、文档格式和文档大小以系统显示为准(内容中显示的页数不一定正确),网站客服只以系统显示的页数、文件格式、文档大小作为仲裁依据,平台无法对文档的真实性、完整性、权威性、准确性、专业性及其观点立场做任何保证或承诺,下载前须认真查看,确认无误后再购买,务必慎重购买;若有违法违纪将进行移交司法处理,若涉侵权平台将进行基本处罚并下架。
3、本站所有内容均由用户上传,付费前请自行鉴别,如您付费,意味着您已接受本站规则且自行承担风险,本站不进行额外附加服务,虚拟产品一经售出概不退款(未进行购买下载可退充值款),文档一经付费(服务费)、不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。
4、如你看到网页展示的文档有www.zixin.com.cn水印,是因预览和防盗链等技术需要对页面进行转换压缩成图而已,我们并不对上传的文档进行任何编辑或修改,文档下载后都不会有水印标识(原文档上传前个别存留的除外),下载后原文更清晰;试题试卷类文档,如果标题没有明确说明有答案则都视为没有答案,请知晓;PPT和DOC文档可被视为“模板”,允许上传人保留章节、目录结构的情况下删减部份的内容;PDF文档不管是原文档转换或图片扫描而得,本站不作要求视为允许,下载前自行私信或留言给上传者【Stan****Shan】。
5、本文档所展示的图片、画像、字体、音乐的版权可能需版权方额外授权,请谨慎使用;网站提供的党政主题相关内容(国旗、国徽、党徽--等)目的在于配合国家政策宣传,仅限个人学习分享使用,禁止用于任何广告和商用目的。
6、文档遇到问题,请及时私信或留言给本站上传会员【Stan****Shan】,需本站解决可联系【 微信客服】、【 QQ客服】,若有其他问题请点击或扫码反馈【 服务填表】;文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“【 版权申诉】”(推荐),意见反馈和侵权处理邮箱:1219186828@qq.com;也可以拔打客服电话:4008-655-100;投诉/维权电话:4009-655-100。