新同学在SAGI的成长：自下而上

文章目录

在上周写的 给 SAGI 新员工的一封信 中，我提到 SAGI 是一个终生学习的组织，乐于打破常规，挑战极限。SAGI 的每个人都是自己的领导者。

SAGI 的每个人都是领导者。你是自己的领导者，是团队的推动者，是公司的检验者。SAGI 关注你的每一条建议，每一个意见，只要你提出来，都会获得反馈。你应该开诚布公，直接且明确地向你的 Leader 说出你的想法，如果没有得到合适的反馈，你知道在哪里能找到我。但请你注意，SAGI 不欢迎无意义的吐槽，提出意见的同时，也要提出你的解决方案。

学习型组织面临的问题

有学习，就有成长。终生学习的组织会面临下面这些问题：

1. 如何快速培训新同学？
2. 如何让团队成员有「成长的感觉」？
3. 如何根据成长的阶段调岗或转岗？
4. 如何让成长优秀的员工接受「更大的挑战」？

SAGI 在尝试解决这些问题。

周报治公司

我每周都会阅读 SAGI GAMES 所有人的周报，大约需要使用 2-3 小时。摘录和回复周报是我周末最重要的工作，这个过程给了我一个整体的视角，让我对每个岗位上的具体细节有了全面梳理的机会。

如果说 川建国 是 Twitter 治国的话，我可能就是周报治公司了。😝

本周有比较严重的问题，也有一些针对问题的解决方案。SAGI 的同学们都在周报中毫无保留地将它们展示出来了。有趣的是，某个岗位的问题，在另一个岗位的周报中似乎就给出了解决方案。也不知道大家写周报的时候有没有互相通过气（SAGI 的周报是全员公开的，只要愿意，每个人可以阅读每个人的周报）。

我把上周周报中的一些有趣的相互印证的点拿出来说一说。

新同学吐槽：为什么流程这么乱

从结果上虽然没有出现重大的用户故障，但是问题依然存在，都有补充热更的情况出现；而问题的原因却生动的佐证了质量管理的各个方面，比如有临期做功能，测试不够、有“顺手”改代码、有了解不足的；这些问题有流程上的，有风险管理、还有合作部门的规范。

有新同学也提到，为什么我们的流程这么混乱。 在版本之间连续两天会有热更，仿佛每天都在搞热更。质量管理肯定不是单纯的”点点点“三个字可以解释，要想简单做测试，也可以，无知无畏，出了问题就甩锅，要么就说能力不行，那确实很容易做；但是要想精细的做到方方面面，用科学的方式方法，基于理解的前提下做事，那肯定也需要付出心力。

看得出来，上面这段周报是质量管理部门同学写的。「新同学认为新东家的流程乱」是一个很普遍的现象，大厂也不能免俗。知乎上有个热帖讲大厂新程序员吐槽老代码质量差的，引起了很多讨论，可惜我一时找不到地址了。

类似的 老流程问题的吐槽，我作为新同学的时候也干过，但没好意思说出口，默默在心里吐一下，然后就去理解流程，推动优化了。阻力固然大，但我就是来干活的，不是来交朋友的。 只要不让我走人，我就能推下去。

吐槽的反面，是坚决执行。我想起 《授权》 一书中的段子：

作者大卫是圣塔菲号核动力潜艇的指挥官，他和轮机长商定了 「推进到 2/3 转速」 的指令，轮机长也严格传达了这个指令。然而推进装置上并没有 2/3 转速。下面是作者和轮机长的对话：

我问他是否知道圣塔菲号的电力推进装置上没有2/3转速。

“是的，指挥官，我知道。”

“那你为什么还下达这个命令？”我震惊地问。

“因为你命令我这样做的。”

“什么？”

“我以为你掌握了一些我们不知晓的军事机密。”

读到这一段的时候，我笑得停不下来。转念又倒吸一口凉气。在 SAGI 有出现过这样的事么？由于我的坚持和独断，是否也有同学因为我「可能掌握了一些商业机密」而严格执行指令，甚至都没有发出一声质疑？

对于新同学来说，敢于质疑一切，挑战权威是相当好的习惯。 可想要成长，只有习惯是不够的。Leader 应该主动面对质疑，做好新同学培训，梳理清楚质疑对象的前世今生。新同学则应该站在历史的角度全面理解问题，直面挑战，推动流程向好的方向发展。

新同学对于团队流程优化，是有推动作用的。老同学可能已经习惯了流程，不容易发现流程中的问题。也可能是尽管发现了更好的工具和方法，但没有意愿或者时间推动整个团队调整。新同学是很好的催化剂。Leader 可能会想，为什么房间里的大象我一直没看到？为什么我早就想到这个解决方案却一直没有推进？为什么我需要一个新同学来推进执行工作？有反思，就有进步。

当然，也有新同学在没有全面理解现状的前提下就希望按照自己的想法和习惯推进工作。这不可取。所有的修改，都应该在全面同步信息之后进行，要得到团队大部分成员（尤其是 Leader）的信任，可是不那么容易的事！

以前从来没听说，就不该做吗？

另一位新同学在周报中进行了吐槽。然而，周一周二是吐槽，周五就变成了点赞。

其实刚开始进来的前两天不太适应每天都有表格要做挺不喜欢的，感觉以前从来没听说主播需要做表格啥的有点吐槽，T导让我做各种分析和表格其实一开始有点不是很愿意，感觉每个人的风格都是不一样的，没必要做的太框架，后边做了后感觉还是有用的，起码整体看起来更清晰明了，到最后我试播了第一次后发现很多问题，我自己会去自己去分析，到周5慢慢的好像习惯了这种有问题就做思路表格的这种方式，能够帮我更快明了的解决分析问题。

「以前从来没听说」，只能说明以前没有碰到过这样的要求，不代表以前的方式就是正确的。我们在做创新的时候，经常会面对这样的「灵魂拷问」：为什么别人不这样做？这涉及到两个前提：

1. 别人是否在全面思考和仔细求证之后才决定不这样做的？
2. 别人是不是因为没有别人这样做才不这样做的？

为什么不和其他人一样正常做事情呢？如果你的新计划顺利实行，那样最好；但如果事情不顺利，将会有很多人排着队奚落你：「就因为他追求与众不同」。

不，SAGI 不会奚落你。与众不同不是原因，而是结果。 SAGI 会愿意去尝试不同。如果我们本就知道这个尝试不合理，SAGI 就会向你解释不合理的原因。 如果是 SAGI 认定正确的事情，即使新同学有多么不情愿，SAGI 也会坚持这个做法。

自己发现问题，自己解决问题

这位开发同学总能挑战自己的极限，把解决方案做到终极。

本周研究了一下如何提高启动性能，所有小游戏进入之前会有一个几秒的下载代码包的过程，会导致启动时黑屏几秒流失一部分用户，之前做XXX项目的时候就用民间的办法优化过，启动的时候先用webgl渲染一张图片挡着以至于不会有黑屏的过程，通过这一方法启动分数首次提高到了80分以上。最近发现这一方法在安卓的最新版本微信上会有问题，渲染的图片会显示不正常，黑白、或者是各种拉伸，闪屏，具体原因不知道，论坛有人碰到了一样的情况但是也没人知道。

后来尝试用别的办法，发现官方也在想办法解决这个黑屏过程的问题，出了一个内测功能叫封面图插件，加了客服微信申请才能用。原理都一样，使用上之后也能到80分以上，双端显示都很正常，再加上主包被我缩减到30K，引擎也丢到分包，首次冲到了93分，剩下7分是在低端机上加载大量3D模型占用内存过多扣的，如果改成在游戏过程中分批加载，分数还能再冲一冲，目前进入游戏已经完全没有黑屏的过程了，我觉得这一套就是终极解决方案。

这位运营同学自己发现问题，自己解决问题，还顺便更新了部门的工作流，可以说是很 SAGI 了。

虽然看似很小，但仔细想想，其实是个很严重的问题：帖子发布前的审核标准。

按照当前的发布帖子，均为写完帖子之后，直接甩到群里，佛系的让大家检查有没有问题。这样其实很危险。

于是今天做了一个标准模板，在发布之前，先自查进行5个选项的自查，避免检查帖子的时候，不知道该检查些什么，就只是单纯的重复看一遍。

此外一定要和同事多多沟通，发布前专门拿出3分钟时间，面对面认真的去读一下帖子内容，讨论一下规则是否会挖坑。

方法就在那里，用不用是你的选择，但展现出来的效果就是云泥之别。

上面质量管理同学提出的问题，有开发同学直接给出了解决方案：

1. 任何线上数据的修复，特别是影响大面积玩家的数据，必须在处理前备份数据库。如果redis在处理数据前备份，就不会使用时间跨度十几个小时的备份数据。
2. 代码质量一定要有保障，提交之前要确保每一行代码的修改都能知道目的与结果，如果不清楚的可以问，清楚但是没把握的需要通知相关代码提交者，“手贱”“顺手修改”一定一定不允许出现。
3. 对于线上问题的修复，要做到最小修改，一个步骤能解决问题的，两个步骤就算写出花来也不考虑。仅仅显示的问题，就只修改显示，不对存储做操作，存储出问题，就仅修改出问题的玩家。
4. 代码review的习惯要保持，对每一次提交的代码要进行审核。一些很明显的问题其实在审核阶段是可以解决掉的，比如这次删除存储代码的问题。

开发同学的方案规范了开发行为，产品同学则给出了流程思考：

提升团队“认知共识”“行为共识”！

研发过程中，策划要主动推动信息同步，推动有效工作沟通。特别是设计案评审过后，在具体制作环节。策划要不断的，定期的询问是否哪里有问题，是否有险，时程是否有调整…。 不要认为是怎样就怎样，要明确核对，实时同步。

评审，能解决 大多数的信息对齐。要做到位，技术评审也要更准确细致。并且要在平时工作中不断的交流，强化各种认知和默契，不断巩固团队的 认知共识，行为共识。

简单的方法，但凡有疑问的，可问可不问的，全都问。 具体工作上，可说可不说的，说。 再简单点， 多唠叨，多唠叨…。 形成共识后，很多工作效率和准确性可以有效提升。

以上不是单方面哪个人或哪个职能的问题，而是研发全局。 出现的问题，就全员同步。碰到认知不对齐 就立马抹平。

你甚至还能学到心理学

在 SAGI 的周报里，你甚至还能学到心理学和社会学。

玩家总是吐槽我们暗改、更新慢，其实很大的一个原因是因为每次发热更没有安排更新公告。当玩家打开游戏，发现一个下载的进度条，然后更改了什么内容也不知道，这时就会很敏感：“官方又在搞什么，肯定又是暗改了！”。其实开发策划美术等同事每天都有做很多事情，比如修 bug，优化等等，但是这些花时间讨论优化的内容玩家并不知道，只有一句 “又暗改“。作为一个小运营，以后也会不断和策划一起做好这一块的工作吧。

玩家暗改那个事情，充分说明了透明度的重要性。是不是真透明不重要，重要的是给人以「透明」的感觉。

Apple Music 刚上线的时候（当时乔布斯还在世），「随机播放」使用的是「真随机」。但用户上来就投诉说这个「不随机」，说重复的歌太多。最后乔布斯给改成了「假随机」，用户才满意了。

如果这位运营同学能直接去推动产品增加这个更新公告，那么整个团队都会获得成长。

我相信 TA 一定会这么做。

转岗是基础操作

沟通后确认了转岗相关的内容，我个人是觉得很具有挑战性工作，加上我自己对于直播是有一定了解并且感兴趣的，所以在知道了工作调整之后是毫不犹豫就答应了。虽然增长运营对于我来说是一个全新的模块，我觉得工作就是需要不断学习不断拓宽自己的，我也很期待之后的工作中能学习到更多，希望能尽快上手增长相关的工作为T多分担一些。

在 SAGI ，部门内部按需转岗是个普遍操作。跨部门转岗也是常见的。SAGI 作为终生学习的组织，支持转岗，也欢迎转岗。要成为 π 型人才，转岗是最快的方式。

新同学成长：自下而上

我们总是希望接受更大的挑战。在 SAGI，我们的成长是自发的，是受到尊重的，是有人帮助的，是自下而上的。

如果有人在 SAGI 的成长超过了 SAGI 的发展速度，我们应该怎样让 TA 接受「更大的挑战」？

无论是调岗，还是负责难度更高的工作，都会立即进行。

终生学习，终身成就。