项目组的技术顾问制度

技术顾问我从工作方式角度将他们分成两种：

1. 协助型技术顾问；
2. 检查型技术顾问

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

检查型技术顾问：相比于协助型技术顾问，检查型技术顾问更多承担的是QA的职责，而且他们表现的可能并不友好。他们的职责有：指出项目组工作不好的地方，并督促他们改进——压测工具不完善、压测覆盖率低、压测指标不合理、登录服与逻辑服之间设计不合理等等。

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

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

上面主要是强调了审核制度，但其实技术顾问制度也相去不远。技术顾问制度就是项目一些关键时间节点(如公测前一个月，上线前一个月)，项目组应该增派在业务和技术都十分有资历和经验的技术大牛坐镇，平日就进行代码走查和解答项目组内一些大家拿捏不定的技术点的顾问责任。

技术顾问一般是适用于规模比较大的公司，复杂或难度比较高而且成员经验不足的项目，作为初创团队或者开发团队小的公司就用不上了。这个时候可以通过各方的途径(如技术交流群或是成员中有认识的朋友)进行外在的技术沟通，借助外力来帮助自己的项目，吸收更多好的解决方案。

 

以下部分讲述了我们项目关于技术顾问制度的实践：

我们项目的大规模线上压测版前期，公司为我们项目组增加了两位技术顾问(一个常驻顾问，一个定期检查顾问)，两位顾问无论是通用组件的了解程度还是编码经验、业务经验和各类技术基础技能知识方面都是高水准的。

他们指导了项目组压测工具的编写；收集哪些压测数据、如何收集；压测数据如何分析等等线上压测前必要的工作。

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

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

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