天之虹:由《大明龙权》佳游挖角门 谈团队挖角的风险、补救、预防

文/天之虹

在刚为转盘得到的《大明龙权》测试资格兴奋得连玩了两个晚上，但在前两天却连续传来大明被团队挖角的消息。网上各种文章不断，在这里我姑且不论这消息的真伪，只去谈谈团队挖角这件事。

团队挖角这件事在业内已经变得越来越常见了。近有《大话2》的核心团队得到巨人支持的小道消息，远有当年的徐波、尚进、王峰等案例，这些都是对前一家公司造成很大影响的或挖角或自立门户的业内事件。

诚然，游戏业这碟香气扑鼻而来的菜肴让每个有能力掏腰包的人都想尝一口鲜。不止行业里已有的各家公司借扩大自主研发和手持项目来大幅扩张，连其他行业的巨头——百度、谷歌、淘宝……甚至CCTV——也无一不蠢蠢欲动了。

国内的游戏业本来就是一个新兴产业，对这么一个还没有专业教育机构且各种标准还没落实和成熟起来的行业来说，有经验人才的增长速度是呈缓慢且稳定的态势的。面对要尝一口羹的顾客爆炸性增长的局面，好厨师自然供不应求——所以对好厨师，乃至整个酒店的厨师进行大批量挖角的事件势必成为必然以及是近年来的趋势。

引子谈得太多，回到“大明”的事件，我们不禁问一句：先不谈把团队挖去的公司如何部署和利用这些人才，光谈被挖的公司——被挖后会面临什么样的风险，该如何补救，日后又该如何规避和预防呢？我想尤其是后者，会是每一家对自己人才竞争力信心还不足以拍胸口留住人才一辈子的公司都在意的。

OK，那这篇文章允许我以一个研发从业者的身份去尝试无责任YY。谈谈我对团队挖角的风险、补救和预防的理解。

项目的三种人

我们通常指的挖角都是指挖人——事情都是人做的，人挖去了，各种事情也就水到渠成了。但“人分三六九等”，是不是所有人被挖了都该恐慌得惊惶无措呢？

我看不然，因为我认为一个项目团队在人员构成里是分成三种人的：

核心人员（A类人员）
核心人员往往是一个项目早期（例如Demo阶段）甚至立项期就组建的人员，当然也不排除后来人员调动后内部提拔或空降的人。这些人在项目里扮演着最核心的角色——或者是主美主程主策等管理和引领主要方向的人，又或者是掌握着核心专业技术的专家。

这些人掌握着项目最核心的设计、技术、方向和决策。项目里大多数的成果都是源于他们的想法、决策和管理结果产生出来的。

重要的一线人员（B类人员）

重要的一线人员往往是前期招募的，在项目的某块领域里经历和浸淫了一段时间，积累了大量第一线的经验。而更为重要的是，他们积累的经验都是基于这个项目而生的，是最适合本项目的经验——外界也不乏有经验的人员，但有着对本项目摸爬滚打积累起来的经验的人员太珍贵了。

这些人在项目里可能没有实权，也可能是低层管理者（例如组长，比方说任务组组长、动作组组长等等），但他们掌握着项目第一线的开发技术和开发经验。

例如有本项目经验的3D人员，他们可能具备以下特征：

了解熟悉引擎的各种长处和短处，懂得怎么扬长避短——大量发挥引擎擅长的美术表现，尽量规避引擎欠优的效果制作；
清楚引擎对3D制作（建模、贴图绘制、导出等）的限制；
清楚哪种3D制作方式才是最适合项目的（表现最好、性能最优、成本最省）；
熟悉引擎相关的各种参数配置和工具运用，乃至有着自己总结的参数最优配置和工具、流程；
熟悉项目在美术管线上的流程，熟悉自己的上下游工作人员和沟通、交接方式；
……

他们是项目一线人员中最有经验的，是把核心人员想法理解、解释、修正、传承和规模化量产的关键角色。

量产的一线人员（C类人员）

当项目敲定前期所有元素后，在中后期会进入到大批量搭建内容的阶段，所以此时在美术和策划人员上会招募（或者内部调动支援）一大批负责量产游戏内容的人员。

这些人受过项目的技术培训（乃至在公司其他类似项目上有过相应领域的开发经验），了解自己当时当刻该做什么，能发挥出一个小原子的生产效率。但他们绝不会也不能主导设计，也没经验和能力去掌控和推动第一线的设计和技术（换言之是无法取代重要的一线人员的角色）。

对这么三拨人来看，被挖走不同类别的人员，其风险和补救方法是各不相同的。

项目人员被挖的风险与补救

诚然，这三类人对项目有着不同的重要性和不可取代性。

肯定所有人都会认为C类人员是最容易重组且重要性相对最低的。而A、B两类人就重要性上来说是很大争议的——我觉得两类人都同样重要，且一旦被挖角都很难物色到合适的人选。

接下来我们来看看这三拨人假如被挖后会存在什么样的风险，又该如何补救吧。
（以下我们只单独谈每一类人员如果被挖走时的情况，之后再看看多种人员被挖走时的情况。）

量产的一线人员被挖

量产人员一般不存在项目前期被挖的情况，因为一般项目前期多是小规模团队设计开发期，在敲定以后才会量产扩充。所以量产的一线人员往往在项目中后期被挖或离开。

风险
量产人员被挖会产生几种风险：
在项目最需要量产时导致项目突然要缓滞下来了；
这种缓滞对市场宣传（已有的以及即将展开的）和上线计划受到影响；
因为时间上的影响，带来对存留的团队士气的影响；
需要重新招一大批人来重新培训和熟悉；
这点又意味着招募上的风险和人员熟悉上的时间风险；

补救
在我看来，挖量产人员的情况是不多见的。因为这类人员不难招募，而且数量很多，也不掌握核心技术或具备显著经验，挖过去的性价比不高。
但Anyway，倘若真的发生这种不幸的事，在我看来补救措施也无非两点：
尽快招募大批人员（当然前提是这个被大批挖角的事件早已街知巷闻，不需要再掩盖其词了）；
全心全力展开培训，协助新招募人员熟悉项目工作；

重要的一线人员被挖

在我看来，通常是不会发生对重要的一线人员大批量挖角的事件的，或者说这群人的挖角更多是伴随性的发生事件——当核心团队被挖走时顺带挖过去。

这些重要的一项人员在前期（立项、Demo，乃至前一两个Milestone）被挖是关系不大的。这类人员对项目最重要的在于针对于项目所建立起来的经验和技术。前期各种技术底层和设计都处于萌芽和兴建阶段，没积累起太多谈得上经验的内容，所以只要内部提拔或者再找有潜力的人员即可。只要有时间，总有一线人员能成长成有经验的重要一线人员的。

但在项目中后期（开始全面铺量乃至对外测试开始后）出现这种状况就很头疼了。此时一方面项目开发进度不能停下来乃至不能缓下来，而且项目无论是系统还是开发内容上已经增长到很可观的规模，重要一线人员积累的经验和技术万一丢失了，重新积累、熟悉和弥补的成本是极高的。

风险
基于这点，在项目中后期重要一线人员被挖后会有着如下风险：
掌握核心技术/设计/底层的人空掉了。而此时这些技术又早已膨胀到大得难以完全交接过继的地步了。
例如任务脚本，有经验的第一线任务策划掌握着任务的所有底层结构，掌握着各种配置表和脚本文件的配置和编写方式，掌握着所有的接口清单和功能，乃至清楚哪些设计是可以采用，哪些是需要规避的。
这些经验无论是传授给下一任人员还是让新人员来接手都太难了。

低层管理人员缺失。

这些重要的第一线人员多是组长类的角色，当他们被挖后，低层管理人员就会突然架空了。这会导致中层管理人员（例如策划主管或主策划）骤添大量的管理压力，需要马上投入到第一线的开发上，但这又偏偏会削弱了他们本分的工作，使得管理和核心设计的工作都被削弱了。

新老人员在交接后最容易出现冲突问题——也就像输血所出现的血型不合的现象。例如
程序的血型可能会带来的问题：
新人员需要重读核心代码，带来大量熟悉所需的时间成本；
代码里很多技巧性的暗门无法理解；
最常见的是会因为不同人写这些重要模块的代码而带来大量本不该出现的bug，甚至是程序内部隐患；
美术的血型可能会带来的问题：
开发出来的资源不符合规范；
（这包括显性的和隐性的。显性是指显而易见的不符合，例如在引擎里表现有问题甚至放不进游戏；隐性的是隐患但又很难发现，例如模型面数远超过引擎要求的规格。）

风格与项目已有资源不符，甚至引领出新的风格；
美术管线上的流程不顺；
无法再充分发挥引擎的优势，甚至带出很多表现上的劣势；
无法再做出精彩的作品；
（只有符合项目特色且最大程度利用和发挥引擎性能的才是好作品）
策划的血型不合可能会带来的问题：
设计与原来的核心思路背离，不能理解或者马上理解核心人员的设计思路；
——也可能因为项目已经膨胀到太大了，没经历过整个渐进的过程，也是很难一下子理解的

由于这种不理解，可能会做出不符合项目基调的设计，做出不符合项目可行性的设计；

补救

基于前面的这些风险，补救其实往往也是针对性的，并且是基于重要一线人员具备项目针对性经验这点特征所做的：

中层管理/核心人员亲自抓第一线开发，尽快物色人选，把这些人员培养起来并积累出项目针对性的经验；
跨组协作培养。
依靠其他组别来帮助快速培养起人员的经验。例如程序向美术提供引擎的各项参数清单甚至培训课程，向策划提供详细的接口清单和示范样例。
此时切忌各组别各管各的——“你缺人你忙活算了，我还是忙我自己手头的事”。我建议把这个问题看作是全项目的问题，而不仅仅是一个组别的问题。
重申核心设计、底层技术和产品的vision。让有潜力培养成重要一线人员的人选能经历一场洗脑和换血，以免真正具备经验后出现血型不合的现象。

核心人员被挖

核心人员被大批挖角是很常见的，此时通常会叫做“核心团队挖角”。
如果这种情况出现在项目前期，在我看来风险只在于新的核心人员可能会对现有已定下的核心设计产生异议，从而带来改变。但由于前期已完成的工作不多，且还没铺开量产，所以这种改变带来的成本也不大，一定程度上可以忽略。
但遇到项目中后期核心团队被挖角，其影响是巨大的。

风险
在我看来，这种情况存在着三大风险：

新到的核心人员对核心设计、技术底层，乃至已完成的成果都不认同。

此时无论是明着干还是暗着干，无论是把项目进行大调整，还是后续指引自己团队做出的成果和原有基调大相径庭，这都会对项目带来极大不利。前者会大幅增加成本，而后者会因为前后矛盾而对产品带来方方面面致命的隐患。
把核心设计乃至成果带到竞争对手处。

或者更常见的是，其实他们本身已经是产品和团队最大的价值所在了。他们人过去了，脑子、经验和技术也会跟着转移。自己公司和竞争对手此消彼长，这对项目乃至公司来说都是最可怕的。

带走一批重要的一线人员。

核心人员都知道重要一线人员的价值所在，这些重要的一线人员很可能也是他们招募和培育起来的，所以会跟着老大们的旗号走。倘若核心人员被挖角，很有可能不论东家是开出筹码明着挖还是核心人员为了保证自己接下来在东家中的实力，其手下的重要一线人员很可能会跟着挪动。

倘若发生这种状况，那核心人员被挖的风险还该加上重要一线人员被挖的所有风险在内。

补救

后果固然很严重，但出现这种问题还是要补救的。由于我认为前期被挖没太大问题，所以只谈中后期被挖的补救建议：

求好不如求稳，空降不如内部提拔。

很多团队或者高管会想着：假如核心人员被挖，那我正好物色一个更好更牛的人员空降来。但我对此持反对意见。
项目能走到中后期，无论是团队还是高层肯定都是对项目走过的路认同的。此时核心人员被挖，更需要的是稳着这条路线加快走到终点，而不是打着小算盘想在这次不幸中捞点小便宜。持这种想法，最终很可能会得不偿失，不单丢了西瓜，很可能连芝麻都捡不到！

牛人都有自己一套开发理念，也会有较高的自视，所以他不认同原有的内容是很正常的，此时就应验了前面说到的一个很大的风险了。其次空降的人在融入团队时也有很多问题，万一引发团队内部矛盾，又走掉一批人，那就变成大换血了。
所以我建议求好不如求稳，空降不如内部提拔。

倘若真想空降。
外部挑人时针对性地了解性格，保证他能融入团队，且可以通过一系列问题了解他是否和游戏已有的设计和开发理念一致。

倘若决定内部提拔。
建议优先考虑的是重要第一线人员的意向，而不是能力如何。因为前期关键的设计已经敲定，对候选人考虑的更多是守业而不是立业的能力。
为新核心人员塑造环境和条件去快速熟悉和理解核心，协助其建立威望和快速融入团队。
设立临时副手来减轻新核心人员本该承担的工作。

众所周知，核心人员都肩负着设计、开发和管理的工作。要让新核心人员在加入团队后马上熟悉并同时全面开展这些工作是很难的。更可行的方式是先暂时另立副手，协助其完成一部分的开发和管理工作，让新核心人员能全身心地尽快熟悉项目，再在合适的时机把原本所有的工作转交回来。

组合技：被对手Combo了怎么办？

世事难料，以上三类人往往不会一次只挖一批，而是常常出现被Combo连击得元气大伤的情况。我们在这里只谈批量挖角，因为公司内部调动、换血和劝退的行为都是自己心里有底的，有了全盘的后续方案，而不像被批量挖角那样手足无措地突然被袭。
一般来说，我觉得挖角或跳槽的情况只有两种：

情况一：三类人小批量地跳槽
跳槽的情况是很常见的，每个公司都有应对的方法。
当以上三类人发生跳槽现象时，运用以上补救方法并提防核心人员在离开时带走一批重要一线人员，这样就好了。

情况二：A类被大批挖走，A带走B，或者AB一起被挖走
A类也就是核心人员，B类是重要一线人员。

这种情况是很糟糕的，或者说对正处于项目中后期的公司来说是致命打击。此时我建议公司出面和这批A类人员谈判，通过各种条件和手段吸引其留下。假如这些方法都无效，那只能考虑挖别人的墙角了。

只要A类人员留下，那B类人员也会随之留下，或者至少大部分留下。因为A类人员很清楚，假如缺了B类人员，那事情还是成不了的。

除此之外，一般不会出现连C类（量产的一线人员）也被大批挖的情况，因为正如前面所说，这些人太多，且挖的性价比不高。

当然，中国人都有句古话：预防胜于治疗。
作为一个还没出现这种危机的团队，有什么切实可行的方法来预防批量挖角事件的发生呢？
如何预防和避免
在我看来，预防和避免的方法都针对这三类人才的特征和失去时所面临的风险展开的：
善待员工，重视人才，对人才做好激励措施，时刻为他们注满信心。
在我看来，首先要让兄弟们都看到赚大钱的希望，因为人都是利益导向的；如果不能让大家看到希望，那起码和兄弟们同褥共枕，让他们愿意两肋插刀——这不得不说是一种黑社会的帮派管理学。

文档、注释、模板、样例

我经历过不少项目，也听说过不少项目。让我吃惊的是很多项目都是文档欠缺的。即使各种需求文档齐备，但很多项目还是缺乏规范和流程文档的。各种规范只是落实在口头上，无法贯彻到底，也无法很轻松地传承到新进员工那里。

文档是一方面，代码和脚本注释也是类似的。其次是模板和样例，例如说对需求文档有着明确的要求，那我建议做出各种文档模板，以便于更容易贯彻和继承；对美术来说，样例是和模板类似的存在，比方说一个规范和品质都完全符合的角色模型样例，它会成为其他后续开发模型的标杆。

无论是文档、注释、模板还是样例，这些都会成为人员更快熟悉项目、熟悉技术的关键要素。这些要素都齐备时，即使发生挖角事件，至少团队和公司也不用太慌张——各种项目积累的东西都能传承出去，要在意的只是花多长时间传承完毕而已，而不会有很多东西无法传承下来。

基于这点，项目里每一项想法、设计、执行、决策、流程、规范等都需要至少有一种以上的媒体来备案和作为日后的指南。
别让核心技术和设计窝烂在一个人脑子里

常常见到这么一件事——主程把引擎核心部分的代码包揽，完全不交给其他人员去碰，也不做培训和教育，让其他人都无从接受到核心代码。

我先不谈这么做对项目能带来多少好处，光谈一旦这个主程离开后，其坏处是祸患无穷的——这就变成项目里没有任何一个人掌握核心代码了！那即使是找了一个很牛的主程来接继，上手和熟悉的成本也是很高的，出错乃至出现隐患的可能性也大幅提高。
所以各种技术和设计一定要在项目里保持着分享的氛围。即便很多人不会负责相关的工作，但他也懂得一二，要接手也有可能性。此外在项目里最好开展各种培训，让一些经验和技术能传承下来。

对不可或缺的关键环节/人员要有储备人才

这种人才或者是明着储备——例如是在项目里也负责第一线的人，但很有潜力，随时能顶替上面的人员接管所有的事情；也可能是市场上的储备，例如有着联系好的人员随时能到位——当然，后一种做法有较高的操作难度。

对各人员在项目里的价值要有正确的理解

我常常见到很多公司或者Producer会轻视策划的存在，这不得不说是策划在行业现状里的悲哀。多数公司的重视程度是：程序-美术-策划-QA这样依次递减的。Anyway，无论大定位如何，团队负责人需要很清楚每个人对团队的价值和意义所在。
在正确理解人员的价值后，他需要不时问自己一个问题：“如果×××走了，项目会变成什么样？”基于这些想法来未雨绸缪。
我认为做到这点的关键在于：不偏见，不浅见，不短见。

要有快速补充量产人才的能力

虽说量产人才的离去是风险相对最小可最有可能顺利挽救局面的，但为了不影响市场时机，公司还是得有快速补充这类人才的能力。

在我看来无非通过外包、公司体制（例如天晴是大工厂流水线作业，一群人走了，随时可以抽调其他人员来补充，因为每个人员是Serve多个项目的）、储备人才、猎头关系和HR部门能力这几条路径达成。

所以在这些路径上，公司都需要对其积累能力、人脉和基础，如此才能在需要批量补充量产人才时能快速响应。

流程和生产管线成熟且文档化，深入民心

很多公司会把流程作为中高层控制和麻木人心的法典——不应该这样！流程和生产管线的法则都是为了提高项目开发效率而设的，既然如此，它应该成熟且落实在文档里，并通过真正贯彻来深入民心，成为一种项目文化。

当做到这点后，任何一个人员都熟悉项目的开发流程了，此时人员离开或换血也更少会出现血型不合的状况。

最后在收篇时不得不往回谈到《大明龙权》的案例。

回看“大明”挖角事件

目前虽然我还不确定消息的真伪，但从我之前的了解以及亲身体验来看，大明的品质的确挺不错的，而且无论是玩法还是内容上都有自己独特的卖点所在，有着行业里少见的一些新鲜点。面对这么一款产品，我想腾讯更多是坚守而不是放弃。

那或许今后会极力挽救，但无论结果如何，都会对上线计划有明显影响了。

最终结果可能会视谈判情况、事前所做的预防工作的情况，以及腾讯自身的人才储备和风险应急情况而有所改变。

作为一个看客，我不便也无法深入推测和建议。

但总而言之，这篇文章的各种YY想法，希望都能成为腾讯乃至业内其他公司的参考——风起云涌之时势必乱世，挖角事件此起彼伏体现的正是乱世对人才资源的争夺，所以各公司对这类事件的重视程度也该相应提高了。

纯YY之文，说的不对的地方也望不吝赐教。