项目组的顾问制度

【本文仅针对游戏行业的顾问制度进行讨论，如果能对你有所启发我将倍感荣幸】

        相信许多成功的游戏项目组都有过这样的经验：上线之前的各种测试都正常（压测、功能测试）各种安心，但是等到上线服务器就出现各种问题：玩家登录不上、战斗进不去、奖励发放错误、数据回档等等（玩家这些表现统称为：“炸服”）。突如其来的各种奇怪问题，让开发几乎奔溃，等这些问题都解决，已经是一天之后的事情了（更有甚者是一周之后的事情了），导致项目白白错过一个绝佳的时机并且因为炸服的原因导致玩家口碑下滑项目损失亿点点。
       但是这些问题似乎和腾讯、网易这些大型成熟厂商绝缘，甚至他们代理的产品也甚少出现这些问题。就我了解的一些情况，原因有一部分来自于他们成熟的顾问制度。下面我从开发者的角度，按照工作内容将顾问分成两种，并给予简单介绍：

1. 验收检查顾问：

        验收检查顾问更多承担的是QA的职责。从他们工作内容和目的来看，大家在共事过程中可能会有一些小冲突，毕竟他们的目的和考核就是找茬。他们的职责有：找出项目组工作不好的地方（从技术到玩法，只要他们认为不合理的都会指出），并督促改进。开发要面临的主要验收包括：压测工具是否正确且完善、压测场景是否完整、压测覆盖率、压测指标是否合理、主要系统设计是否合理等等。

腾讯在项目顾问和阶段审核制度方面也是有比较完善的制度的，下面是关于腾讯顾问和审核制度的一点描述：

        管理团队希望给开发团队足够的自由度，完成自我表达。我们不想深度干预项目日常开发。然而，宽容不等于纵容，对于明显有问题的项目，还是要有些方式，来提出意见，提升项目品质。日常的Review提供了一个不错的反馈渠道，但是这远远不够。我们发现有些产品在难度设置上不合理，有些产品整合后品质不够，有些产品有口碑风险，这些问题，都有一个共性，就是只在产品开发的后期才会出现，早期的版本，因为完成度有限，并不会暴露问题。
        现代游戏开发，过于流水线化，每个工序都切分细致，美术专心画画，程序专心写功能和整合，策划专心设计玩法和系统，测试寻找功能Bug。可是这个开发流程里面，并没有玩家。很多时候，用普通玩家的视角，进行游戏测试，会发现大量问题，而这些问题，在基本的开发过程中，没有人留意到。于是我们引入了各个节点的专家评测，更早、更全面反馈游戏中的问题。我们也引入了Master Review，在游戏上线前，集中召集相关人，用玩家的视角，来体验游戏，看游戏的节奏，看游戏的问题，给予开发者深度的反馈。此时版本完成度较高，也更容易发现体验的问题。——mp.weixin.qq.com/s/egJlYY3KL…

个人对验收检查顾问的理解就是：项目没有上线之前公司要确保项目是否值得再继续下去还有其健康状况，加入的一些评审和强制性要求，不过与其说是要求不如说是帮助。

2. 技术协助顾问：

        协助型技术顾问可能会伴随项目组较长一段时间(注意：他们不一定是项目组成员)。他们一般是在项目组关键时间段(如项目立项demo期或上线前期)暂时加入，以指导项目某些方面的推进或给出项目所遇到难题的合理建议（比如：更好的代码设计建议，以适应项目后面的快速发展）。协助型技术顾问是用于帮助经验不足的项目组渡过关键时期的技术或业务大拿，当然也承担项目组成员的技能培训的部分责任。

验收检查顾问主要是强调的是审核和要求，和技术顾问侧重点有所不同，但两者制度也相去不远。技术顾问就是项目一些关键时间节点(如立项demo期、公测前，上线初始阶段)，项目组应该增派在业务和技术都十分有资历和经验的技术大牛坐镇，平日就进行代码走查和解答项目组内一些大家拿捏不定的技术点的顾问责任。

技术顾问一般是适用于规模比较大的公司，当一些经验不足的项目组面临复杂或难度较大的问题时，就会出动技术顾问。作为初创团队或者小开发团队一般就没有这个资源了。但是不意味不能向外寻找技术帮助，这个时候项目组成员可以通过各方的途径(如技术交流群或是成员中有认识的朋友)进行外在的技术沟通，借助外力来帮助自己的项目，吸收更多好的解决方案。

技术高超，项目组经验丰富的人才可以说是凤毛麟角的。但是大型多人游戏的开发是一个技术难度十分高的工作，它对知识、经验的要求特别高。所以很多大的工作室都有项目组之间的互派动作，进行经验交流和技术协助。一来是为了帮助新生项目组，二来也是为了培养更成熟的开发团队。

我曾经参与过的一个项目就有过技术顾问的入驻。当时由于第一次线上测试服务器炸掉，导致相当大的负面影响。公司决定派驻技术顾问支援我们。技术顾问大佬直接入驻到我们的项目组里面，帮我梳理了项目组主要的几个重要系统。然后给出优化方案不断进行优化和压测，最后项目成功上线顶住了预期的压力。可以预料的是如果没有哪位大佬的帮助，我们的项目绝对会在下次上线的时候再炸服一次。

本人也有幸帮助过别的项目（我当时并没有入驻项目组，只是每周有两天时间需要和他们进行线上协同工作），我自己的总结就是：对别人的帮助远远比接受别人的帮助给我的成长要大。不断的挑战各种从前没有想过的问题；学习其他项目组的架构设计思路；不断优化、验证、再优化；这些都是十分难得的体验，整个过程自己都在升华。解决问题比提出问题更锻炼人，预防问题比解决问题更困难。

以下部分是我个人在项目关于技术顾问制度的实践心得：

1. 项目的大规模线上压测版前期，项目组增加了两位技术顾问(一个常驻顾问，一个定期检查顾问)，两位顾问无论是通用组件的了解程度还是编码经验、业务经验和各类技术基础技能知识方面都是高水准的。他们指导了项目组几个重要系统的优化、压测工具的编写；收集哪些压测数据、如何收集；压测数据如何分析等等线上压测前必要的工作。

2. 压测所用工具是另一个同事来完成、优化是我来做。但这些工作本质上都是来源于他们的构思和以往的经验。比如说通过日志打印命令耗时、打印redis、mysql耗时与具体操作，这些都是他们的主意。这些最底层的构思也保证了这次压测顺利。一些优化思路和连续不断的指导，都使得项目组和我们个人得到长足的进步。

3. 效率和经验在项目关键时期是非常非常重要的(其他时候，完全可以用时间战术，用时间换效率)，但是关键时间段，时间根本不够，也不敢冒险。所以技术顾问制度在这个时间段是很合适的。

4. 技术顾问给项目组的另一个好处在于帮助项目组成员的成长，很多问题和这些问题的解决方式可能没人告诉项目组成员，他们可能永远都不知道。通过真实的线上实战和指导，对项目组成员的提升是非常高效的。工作带来的知识可比自己写demo或瞎捣鼓更有用也更珍贵。

5. 顾问制度有效地加强了公司内部项目组直接的交流————从技术研发到游戏玩法和运营，不同的思想进行碰撞和汇聚。最终受益的是双方，当然最大的受益者还是公司。

6. 顾问制度处理保证项目的健康状态，还有一个重要的作用。它会促使整个项目进行思考和反思。