工程师哲学

网易游学2021-04-0733926次浏览

1评论

18收藏

21点赞

分享

Mingong

如何从毕业生成为一个优秀的工程师?这堂课分享给大家的是我工作以来的一些经验和体会。

程师的估值游戏

我把工程师在工作中做决策时候做的事情称为估值游戏

比如说你们做Mini项目的时候,面对需求一定会有很多的技术选择,选择A,可能用的时间长一点,但是可能性能更好;选择B可能用的时间短一些,但是可能效率差一些;那你会怎么选择?在你以后的职业生涯中,会面对无数次大大小小这样的选择,那选择的依据是什么呢?

其实就是一个最简单的经济学原理——投资回报比(ROI)

 

 

你要思考哪件事情性价比最高,比如说项目时间非常宝贵,也许并不需要一个很完善、效率很高的方案,因为Demo的时候服务端可能不超过十个人登录,客户端也最多只有两个人对战,那么在这个阶段可能就会选择技术B。

ROI这个道理看似简单,但预测ROI并不容易。看看这张图,橙色这条线是中国手游市场的增速,蓝色是端游的。在2012、2013年,手游市场规模很小,增速虽然很快,但是相比端游总量差距实在太大。这个时候老牌的端游公司对于是否应该进入手游市场,应该投入多少资源是充满疑惑的。当时网易做了一个非常正确的战略决策,花很多力气推动工作室去做手游,最终奠定了今天在手游市场的成功。

如何去评估投资回报比?

评估回报

除了直接回报,还有间接回报

我们都知道梦幻、阴阳师这些经典的游戏,目前在做动画、舞台剧等,非常受欢迎。但是你会发现这是没有直接收益的,票房或者其他收入肯定是抵消不了我们投入的成本,那为什么还要做这件事情?因为我们通过这些形式,放大了这个IP的影响力。现在的互联网用户获取是非常贵的,我们扩大IP影响力,就是希望通过IP的塑造来获得更多的用户。

回报有短期也有长期。

互娱做非常多的培训,大家进来先是两个月入职培训,还有非常多的沙龙和在职培训,这对于公司是一个直接投入,工作室非常缺人,但是我们依然坚持给同学们做两个月的脱产入职培训。因为公司相信这样的培训能够帮助大家成长,在长期给公司带来更好的回报。

同一件事情的价值随着场景的变化而变化

随着职业生涯的发展,有一天你成为了游戏项目的主程,那么你可能会面对一个问题:只有有限的资源和时间,而这个游戏有很多技术上的需求,比如打击感、画面,性能,网络同步等,你要如何去分配这些资源和时间呢?其实不同的游戏最终的决策也是不一样的,比如说一个二次元向的游戏,很重要的就是人设,所以将非常多的计算资源用在角色绘制上面,因为它本身打动人的就是角色和剧情。而如果去做个MOBA游戏,你发现会将很多的精力放在技能手感和网络同步上,因为这可能是核心竞争力。

考虑成本

实际工作中要不要给策划做编辑器?

做编辑器有程序的时间成本,但是可能节省的是策划的时间成本。做不做其实都有成本,只不过看由谁来支付这个成本。最终是否做编辑器,取决于节省的策划时间成本是不是大于程序制作的时间成本。

工程师为什么要在写代码前做设计?

因为我们不希望写出来的东西是与需求不符的,这样就有可能在新需求提出来的时候,需要去维护重写,这也就是增加了一个长期维护成本。

如果要去实现一个系统,你会选择自己造轮子,还是使用开源软件或商业中间件?

在不同的游戏中选择也是不一样的,核心点在于你要解决一个新问题的时候,这个问题是不是已经有人解决了,甚至解决的比你更好,那你就应该把时间放在更好的创新上。

 

Move fast and fail early

当你没有足够经验的时候,关键是要通行动去获取更多的知识,在实践中寻找可能正确的道路。

在公司有两类实习生:一种是把事情交给他,过了一周他说“我还在思考方案,我有很多想法还没想清楚,等想清楚再找你吧”;第二种是过了一两天他来找你说“我有一个想法,准备这样…”,然后你给他反馈,再过一两天他说“我尝试了一下遇到一些困难,但是我觉得总体是可行的”。大家觉得两个月实习期结束后,哪位同学能够取得更好的进展?显然是第二位。

《管理软件欠帐》里面有句话:“你通常能够在第三次把事情做对”,因为你做任何事情的时候,可能一开始选择的并不是最佳方案,然后重新去思考一个更好的方法,直到第三次可能找到比较完善的方案。既然我们说了一次可能做不对,我们要三次甚至四五次才可能做对,那必然面对一个很重要的问题,就是不能失败的太晚

怎么不失败的太晚?

有勇气去承认失败

当有人给你反馈说你肯定做的不对的时候,第一反应不是要去反驳他,先想一想,是不是真的有地方可能做的不够好。然而没有人有义务或有责任,不停的在你身边给你反馈提示你可能犯的错误。

给自己建立一个反馈系统

当我们的服务器上线之后,不会等用户打电话说“你们的服务器宕机了登录不了”,我们会有非常多的监控系统。你需要通过建立一些指标,帮助自己及时知道是不是发生了错误。

应对反馈需要敏捷

互联网行业越来越讲敏捷,就是希望更快的发现问题,更快的给用户交付品质。对个人也是,当你发现问题的时候要去建立自己敏捷生产跟改进的流程,帮助自己更快的走出问题。

从失败中学习

人的进步必然是从失败中不断学习的,这也有两个层次:你学习的是经验,还是规律。经验是判断一件事情能不能做,而规律是在什么前提假设下不能做,什么前提假设下能做。从失败中学习很重要是:不要学经验,去学规律,去思考这件事情失败是真的不能行,还是有些前提约束才做不到

关于团队

关于团队跟大家分享几个理论,第一个理论是经典的一本书《人月神话》里的:团队的总生产力随着人数增加而慢慢增加,但是会到达一个拐点,然后再加人反而会下降,配合这张经典的图。

原因是当人越多,我们不可避免会投入更多的沟通成本,协作效率会降低,可能原来一个人有60%的时间在实际产出,人越加越多他可能60%都拿去做沟通了。

怎么去解决团队总生产力或者边际收益的下降?

拆分团队

大的团队我会在内部拆成几个小组。举一个例子,在初期我们的常见团队拆分方式就是两个团队,客户端和服务端。但是我们的功能点往往涉及客户端跟服务端开发,随着团队扩大,造成一个大的客户端团队和一个大的服务端团队对接,引入了较多的沟通成本。这个时候我们会慢慢建立功能团队,针对某些系统组建几个人的小团队,负责客户端和服务端的人都在里面,通过类似拆分微服务的方式来拆分团队,降低沟通成本,实现团队组织的低耦合和高内聚。

团队中会有目标不一致的情况。

当你说“我这里需要几个UI,产品表现才完整”,程序说“我正在重构服务端,我要做一个逆天的分布式系统”,然后你又跟美术说“不要放这么多模型,这个手机已经发烫了”,但是美术说“如果不这样效果达不到”。所以存在一个很大的问题就是:你们到底是几个职能团队,为各自职能的最大化在努力,还是一个产品团队,为同一个产品的收益最大化而努力。

  怎么去成为一个优秀的团队?

做事情有相同的优先级

不会出现你把代码写完之后跟UI说“我的UI图出好了没有”,UI说“我在出另一个系统的图,你的要下周才出”。往往一件事情是需要很多职能部门合作的,能不能在职能之间达成一样的优先级,是优秀团队很重要的特点。

用相同的工具去合作

比如GIT这个版本管理软件程序员很喜欢,但是美术策划很难掌握,而当一个游戏项目有非常多美术、策划要跟你一起工作的时候,强迫人家去用他们很难掌握的工具,其实并不见得能最大化整个团队的生产力。

用相同的语言去沟通

在过去的学习中你积累了大量的专业词汇,比如计算机的专科语言、设计模式,短短的一句话浓缩了非常多的含义。保持这样一个高效的语言在整个团队中的流通,其实能够有效地降低团队的沟通成本。优秀团队会有自己的词典。

能够互相分担工作

按职能分其实可能会出现一个问题,团队如何让每个人都工作在自己擅长的事情上,但是在工作不均匀的情况下,也能够分担其他人的事情,这其实是团队管理中非常重要的一个课题。

 

我们如何从优秀走到卓越?

静态的看,团队生产力不管怎么样去优化都会有个上限。但是人是动态的,大家可以一起去学习一起成长,如果一个团队内部有更多的技术分享、技术讨论、互相能够碰撞出更好的思维火花,我相信这个团队生产力上限会不断提升。

好的工程师都在做什么

好的工程师具备哪些特征?

创造价值而不是代码。

谁是你的客户?用户当然是,因为你做游戏;策划也是你的客户,因为你给他做编辑器;美术可能也是你的客户,因为你给他做工具。所以其实你有很多的客户,你的每一行代码最终都需要创造价值。一个工程师好坏的区别在于:他是做了客户需要他做的事,还是创造了客户希望他创造的价值。优秀的工程师能够通过表面的需求去寻找深层次的诉求是什么,去设计一个更好的方案。

产出的杠杆率。

工程师的产出是有杠杆的,每个人每天能写的代码数量有限,能创造的直接价值有限。但是当你指导别人解决他们遇到的难题时,你就成功完成了一次间接产出,团队因为你这个行为提升了总体生产力。很多行为都是有杠杆价值的,比如分享帮助团队进步,良好的沟通去移除合作的障碍。

 

懂得建立自己的技术品牌。

我知道一个工程师很厉害,一定是他经常跟其他人做分享交流、沙龙,让我觉得这个人解决问题的方式很好、钻研技术的深度是非常深的。这带来两个好处,一个是可能有人遇到问题就会来找你,那你本身就能创造更大的间接产出;第二个是你在公司建立了自己的技术品牌,我们非常鼓励大家能够积极参加沙龙,以后可以多在组内做分享,多在公司内部做分享。

具备领导力。

一个好的工程师不一定是管理者,但他一定具备领导力。管理者是公司授权你去做一些管理的工作,而领导力是当一些事情需要人协作的时候,总需要一个人站出来说怎么去协同各个方面,怎么去推进,遇到障碍的时候组织大家去讨论、去解决。

如何成为好的工程师?

明白任务和期望的结果

比如主程交给你一个任务,他是希望你用一天的时间交一个凑合能用的版本,还是一周的时间交一个完善的结果。主程有很多自己的价值判断标准,如果他忘了传递给你,那么为了避免自己做很傻的事情,就需要去问一些可能你觉得很傻的问题。

不要有最后一分钟的“惊喜”

当你预估一件事需要一个月,千万不要等到最后才说“我当时预估错了,我还需要两个星期”,那有可能这一次外放版本很依赖这个功能。所以你需要及时的将这些变更反馈给你的技术主管,能够帮助他能够及时的做计划的更改。

使用和制作工具

在不断的工作之中会有很多重复机械的工作,而好的工程师会试图去制作很多工具来简化这部分工作。

什么时候知道自己成为一个好的工程师了?

当你赢得信任和信誉的时候。当团队遇到一个困难会不约而同的想到一个人的时候,那这个人就是大家信赖的那个好的工程师了。而信任和信誉不是凭空而来的,团队、主管对你的信誉是一点点积累下来的,你做的每一件小事,做得差还是超出预期其实都是在影响你积攒的信誉。

总 结

最后总结一下今天分享的内容,优秀的工程师大抵需要做到这几点内容:

1.擅长ROI的估值游戏,从而最大化软件开发带来的价值;

2.有运作良好的反馈系统帮助自己发现失败,快速改进;

3.懂得如何提升团队沟通和协作的效率

4.创造价值和解决问题,并懂得哪些行为对产出有杠杆作用

评论 (1)

0/1000
网易游学APP
为热爱赋能
扫描二维码下载APP