万字长文！资深大牛谈游戏程序员的个人修炼

程序员成长有很多外因，好的时机、好的公司、好的同事，会让你的成长更顺利。

这次我们聊聊刚入行的初学者该怎么提升自己，用个流行的说法，咱们来谈点观念，理清概念，才能更好地成长。

适合初学者的几点提升要诀

提高业务能力

对初学者，入行后最重要的肯定是抓紧提高自己的业务能力。对校招渠道入职的新员工，公司的期望一般不高，能干活，有潜力即可。

新员工的第一要务，当然是要迅速上手。在一个中小项目里，上手一般不是太大的难题。

我们看看 UI 开发的例子。初学者的第一份工作，经常会是简单的逻辑、菜单、UI 等等。

它们共同的特点是不难但很繁琐，一般只要照着前人的工作，依样画葫芦，就能做得八九不离十。

在这个过程中，新人可以很好锻炼自己在软件工程方面的实践，学习如何同团队成员配合；如何和跨领域的策划美术交流，尽快熟悉游戏的设计、开发、构建、测试等流程。如果项目快上线了，那还能顺便锻炼身体，加班熬夜。

关于做 UI 和逻辑，初学者常常抱怨，没有技术深度，不出彩，但特别繁琐，做起来很累。属于做好了没功劳，做砸了要背锅，摧残人性，让人痛不欲生。

这也是一个老生常谈，简单的工作也需要有人做，如果有心，在 UI 开发里面也可以找到个人的积累和发展，有几个事情不妨尝试一下：

提高自己的效率

做得更好、更快、更少 Bug。有了效率，就能提高质量。以前见过新的同事，学有余力，做一个功能，往往会自己发挥，做两三个不同版本让 Leader 挑选，这样的同学很快就能脱颖而出。

提高程序团队的效率

看看 UI 从设计、开发到验收，有什么流程可以改进，提高功能开发效率。Leader 或者其他 Senior 程序员往往有其他领域要关心，没精力关心这一块。

让领导放心不就是我们职场应尽的义务么，在这个子领域，初学者也有机会发挥的。

或者你也可以看看是不是能做通用控件，让整个 UI 团队效率更高。通用控件由于要考虑方方面面的需求，开发有一定的难度，能很好地提高个人的能力。

提高项目整体效率

UI 和逻辑上更多应用数据驱动，合理架构，减少硬编码，把一部分UI编码工作变成配置工作，开放给策划，既减少了工作量，策划也会觉得更灵活。

分开逻辑和表现代码，便于调整功能，也方便写单元测试。做点力所能及的重构，关注一下 UI 的内存和性能，别给整个项目增加不必要的风险，这都是可以尝试的。

无论在什么职业中，业务能力总是最重要的。有了业务能力，才能赢得大家的尊重。即使第一份工作内容并没那么有深度，也要认真做好它，从中学习，快速成长。

持续学习，找到 Unbroken Time

本职工作做好之后，千万别满足。我想聊的下一个话题，就是关于持续学习。

程序员族群，早就身处在一个终身学习的时代，入行就是焦虑的开始，持续的学习，不能保证百尺竿头，但至少能回避逆水行舟的惶恐。

虽说程序员都在学习，学习的质量差别还是比较大的。相当多的程序员并没有良好的学习习惯，忽略了提前储备知识的过程，只是被动的学习如何解决迫在眉睫的问题，掌握明天上班要用的技能。

学习和积累的主题以后单独展开，这里只说一个小习惯，也是个人效率里一个很重要的概念，找到你的不被打断的时间。

程序相关知识往往烧脑，没有沉下心，便不能理解。一整段不被打扰的时间，是必须的。

但碎片化的时代，整段时间早被手机的滚滚洪流碾得粉碎，大家前仆后继，把完整时间碎片化，刷刷朋友圈，回个微信，收个邮件，一个小时就过去了。

我们要做的，是尽量给自己创造条件，空出不受打扰的时间，用个人的意志抵制碎片化。

我工作早年使用的是公交车等座位大法。反向坐公交车到终点站，排个座位，上车，拿本书慢慢看。

那年代心还很静，手机还被叫做大哥大，没什么车上娱乐。快快翻过看得懂的页，看不懂的低头想想，每个工作日有那么一个小时可以静心阅读，不知不觉几年间啃掉了很多艰涩难懂的大部头。

后来开车上下班就悲剧了，尝试了各种方法，但还是没法专心阅读，车上的时间只能听听 Podcast。

要深度学习，要省出不被打扰的时间。实践下来最有效的还是早到公司法。早上提前 30 分钟从家出发，路上车没那么堵，往往还可以省出 15 分钟路上的时间。

到了公司也很清静，千万不要收邮件，也别去倒茶，要警惕碎片化陷阱。赶紧拿上要看的书，离开你的电脑，离开你的手机，去会议室学习。

另一些能用的方法包括早起法，晚睡法，打出租车上下班法，一个人去很贵很清静的馆子吃饭法等等，大家可以自行发挥。

有了完整的不被打扰的时间，可以深度储备业务知识，可以横向扫描行业进展，可以回顾工作得失，可以总结输出知识。

虽然每天几十分钟不起眼，但如果能坚持几年的话，你一定能看见自己的成长。

信息枢纽（Info Hub）

下一个对我很有帮助的观念，是需要努力成为团队中信息的枢纽。

信息枢纽是我的一个生造的概念，灵感来源于 HUB（集线器）。网络中的集线器，汇集了所有的信息，再广播给其他设备。

对我们信息从业人员来说，你做好了本职业务，积累了广泛的跨领域知识后，应该考虑如何逐渐让自己变成团队内开发知识沟通的中心，让自己在团队中更不可替代。

回到我的个人经历，我在 2001 年作为公司前几批开发人员，接触 Unreal2 引擎。

当时的项目使用 Unreal2，我做逻辑，做网络对战，有了持续的积累后，我很快在 Unreal 的逻辑开发上积累了丰富经验。

虽然在整体开发经验方面我还是比不上其他开发者，但在 Unreal 逻辑这一块我比较专业。

我在公司内做了一些相关知识的分享，然后在后续的项目里面坚持到处看看，帮助其他同事 Debug ，或者介绍相关的模块，让他们也能快速上手。

逐渐的，我发现了一些有趣的变化。很多同事碰到这个领域的知识，有问题都会先来咨询我。当然这些问题我也并不是全部能回答的，我择其易者答之，其不易者学之。

因为手头工作也很多，对那些不了解的问题，我通常会说让我研究一下，抽点时间看看能不能解决，然后再回复同事。帮助大家次数多了，我就自然成为了 Info Hub。

成为信息枢纽以后，对团队的好处显而易见，你润滑了团队，顺畅了知识通路，自身价值变得更重要。对个人的好处不那么明显，却更重要。

各类信息在你这里集结，回答已知问题可以巩固你的知识，研究未知问题可以扩展你的边界，信息在你身边流过，自然可以滋润你的认知。变成更好的自己，不就是我们一直的追求？

当然，成为 Info Hub 并不容易，需要个人努力，也需要一些机缘巧合。新项目、新技术的早期拓荒者，很有可能成为信息枢纽。

但新项目和技术有一定的风险，不是新的就是好的，新方向会失败，会毁了你统治信息的野望。

于我而言，在 2001 年这个节点，Unreal 也许就是一个新方向，在 2001 年后的八年里，熟悉 Unreal 给我带来了巨大的回报，甚至很多影响点点滴滴影响了开发自己引擎。

如果运气并不那么好，研究了没落的技术，参与了失败的项目怎么办？事情没有你想象的那么糟糕。

没落的技术，即将无人问津，但它是细分领域的知识，领域越窄，越少人懂，越方便你成为专家。

总结一下这个技术为什么失败，横向对比一下其他成功技术，谈谈趋势，都能让你自己提高。

至于失败的项目，就更无所谓。项目的失败，意味着公司或者团队损失了机会成本，但项目中的每一个人，确确实实得到了成长，吃一堑就能长一智。

时常总结，在失败中找到自己的成长，才是我们要关注的。

我刚开始用 Unreal，第一个项目是被公司砍掉的，也没有任何人有把握说，Unreal 将来能得到巨大的应用，但积累在那里，说不定哪天会给你带来丰厚的回报。

再来谈一个对初学者成长有帮助的概念。

跨界和好奇

如果让我总结怎么让自己变得更有价值，跨界无疑是一个非常重要的关键字。

所谓的跨界，是指拥有多个和本专业不同领域的开发知识，并可以灵活运用在开发过程中。

当你有了跨界的能力，就可以在开发和交流中，利用跨领域的知识，帮助团队更好的沟通、设计、实现功能。

跨界的意义有几个，重要性依次递增，增加沟通效率，提升产品质量，超越已有认知。我们分别展开讨论。

增加沟通效率是最容易理解的，游戏开发需要多工种合作，大家说着不一样的行话，做着不一样的工作。工种和工种之间，有壁垒，阻碍了交流。

拥有跨界的知识，逻辑程序员了解一点关卡策划的工作，渲染程序员懂一点技术美术的工具，引擎程序员接手一下工具程序员的模块。

这些跨界的认知，都能很好提高团队沟通效率，帮助不同职能同事更快的达成共识。

拥有足够的跨界知识，沟通会更精准，也不用经常拉上其他同事一起讨论问题，减少沟通环节，降低沟通中的失真，就顺理成章了。

人和人的信任，本就是从工作的合作细节开始，你会发现那些拥有跨界知识的同事，不知不觉间，就成了项目中心，加薪升职赢取白富美，从此过上了幸福的生活。

提升产品质量是下一个水到渠成的事情，当拥有了别的领域的知识，我们在设计和实现功能的时候，就可以考虑到用户的需求，把手头的工作做到更好。

举个简单例子说明一下。比如开发编辑器时，很常见的一个需求，就是编辑参数的界面。

比如我们要调整一个游戏内物件的参数，最常见的做法，就是选中这个对象，弹出属性表单，可以调整参数。

这个功能所有引擎都有，一般的实现方式是在引擎内表示对象参数的时候，对每一个参数有元信息描述，表示参数的类型、编辑方式、取值范围等等。

属性表单弹出后只需要遍历这个对象的参数元信息，然后为每个可调整参数创建显示和编辑的控件即可。

有了基础功能，下一个诉求，是一个对象会有非常多的参数，不是所有参数都需要暴露给编辑器编辑，全部暴露出来反而降低开发效率，容易误操作。

所以多数引擎一般在参数元信息加上标志，需要暴露的参数，才会被编辑器显示在属性表单内。

到目前为止一切都还好。但策划又提出新要求，同一个对象，在另一个特殊的编辑界面，也要调整参数，这次需要显示的参数，和普通界面需要暴露的参数不一样。

这个需求的本质，就是针对同一套数据 Model，定义多个不同的 View。如果按照原有的元信息系统发展下去，我们要加上新的参数标志，让这些参数开放给另一个 View。

当 View 变多的时候，整个设计就会比较臃肿，每多一个不同的 View，就需要修改 Model 的元信息，这个路径有点长，会动到已有的结构。

这个思路有点不对，为什么不同的 View，需要动到数据的 Model 呢？不同 View 的复杂性，就应该放在 View 里面啊。

当工具程序员设计参数元信息和属性表单的时候，如果能提前想到策划可能有这样的需求，那么设计角度就可以做点调整。不必通过在元信息上打标记，而是搜索的方式。

比如我们 Mac 电脑上的 Finder，它有智能文件夹，本质上就是一个组合的 Filter，用 Search 来进行文件的筛选，不同的搜索，保存成智能文件夹，就可以快速便捷的归类文件。

同样，对我们的属性表单，我们也可以使用正则表达式来进行属性的筛选。这样针对不同的 View，只需要定义不同的过滤表达式就可以了。

正则表达式还可以数据驱动，策划要什么参数就改改配置文件就好了。正则表达式来定义 View 的内容，既强大，也精准。

所以当你拥有了跨界的知识，了解用户的需求，了解其他领域的巧妙设计，就有可能设计出更好的系统。

超越已有认知是跨界更重要的好处，可以做出不同的设计，或更精简，或更高效，或更突破，或兼而有之。

举几个例子：

• 寻路问题是个搜索问题，可以用来计算最短路径，那我就可以用它来计算声音在室内的传播了。
• 序列化不仅仅可以用在保存上，也可以用来做垃圾回收的标记，做文本数据和配置文件的打包和二进制化，做数据文件的压缩和加密，做项目废旧资源的标记和删除。
• 谁说我们一定要在同一个进程里读写数据，为什么不在另一个进程里面统一读写数据，便于多开游戏进程可以共享读取的Cache，也可以对并发的读取进行重新排序，降低磁盘寻道开销。

既然跨界知识如此重要，如何来培养自己的跨界能力呢？我给的答案是好奇心，对技术有好奇，多看多问，多想多总结，自然就跨界了。

初学者最重要的品质就是好奇心，帮助你探索未知的边缘。游戏开发的客户端技术，业务领域众多，我们简单细分一下，就可以分出逻辑、UI、工具、渲染、引擎、物理、音频、动画、AI、构建等等领域。

相当多的方向，既广又深。再考虑到和周边业务团队接口，还需要对后台技术、美术技术、策划领域有一定的了解。

对技术的好奇，可以帮助你加速跨越岗位之间的边界。试着放纵一下自己的好奇，完成本职工作之余，向对面的工作内容张望几眼。多看看，就懂了。

我从业最初工作内容是 UI 逻辑，逐渐做了 Unreal 引擎上的开发，先写脚本和逻辑，然后支持关卡策划做逻辑相关开发，工作之余，游戏 Crash 时候，就顺便往脚本解释器里面捣鼓捣鼓，Debug 一下脚本编译器和解释器。

引擎程序员和逻辑程序员之间并没有分明的泾渭，看几次，没啥学不会的，逐渐也就熟悉了相关模块，再逐渐拓展到引擎其他模块，哪里有问题，过去看几眼，不懂找高手问问。

再不懂，放一下，职业生涯很长，现在不懂的，将来会懂，保持好奇，总会到彼岸。几年下来，也就把 Unreal 引擎方方面面磨了个透。

任何一个大项目，大引擎，都是知识的宝库，不用舍近求远，认真做好手边的项目，就会成长。如果有幸能参与到一流的项目中，成长速度会更快。

我的职业生涯前几年在 UBISOFT 工作，参与了很多 AAA 项目，即使没有太多的主动学习，眼界和能力也能有很大的增长。如果没有机会参与高端项目，也不需要气馁。

游戏技术领域的知识相当公开和透明，关注 GDC 以及其他开发会议，留心欧美新出版的技术书籍，定期扫一遍，就大致知道技术圈发生了些什么事情了，找个感兴趣的领域深入看进去，坚持几年，就会有很大的提高。

总结一下这写的一些观点。划一下重点，这几道是送分的必考题：

• 初学者要专注提高专业能力，即使是简单的工作，也能提高自己的能力。
• 培养自己对技术的好奇心，多看看，提升自己跨界的能力，对项目或者对自己都好。
• 培养良好的习惯，找到不被打扰的时间段，持续学习。
• 试图成为信息的集散地，帮助别人，才能帮助自己。

技术瓶颈期如何转岗转职？

前篇讲了从 Junior 到 Senior 程序员的成长过程，现在谈谈转职。从我自己的工作经历来看，工作了 5-6 年以后，就遇到了技术上的瓶颈期。

当我开发很久的逻辑和 AI，也包括一部分网络对战模块，在几个不同项目中锻炼后，多数相关的细分领域都接触过了。我逐渐对这些技术提不起兴趣了，于是想转岗去做点引擎相关的事情。

职场新人是一张白纸，有机会在不同领域换岗位。而工作几年的老人，常常有自己擅长的领域，不如小朋友可塑性强，且体力也不如年轻人。

这时候要转新的岗位，就有一定的难度。常常看见很多人想做渲染、想做引擎，但却没有太多的知识储备。

问他们为什么不提前准备，他们就说：工作很忙，没空学习渲染和引擎，但你不让我做一下，我没有经验，又怎么会有能力做好渲染和引擎呢？非常遗憾，这个逻辑是错的。

这里有一个必须注意的地方。在转岗这个事情上，公司是不会为了你的理想和野心买单，他们只会为你的能力买单。

我们把它翻译成人类的语言，就是公司一般不会仅仅因为你想转岗就让你转岗，只有你具备了新岗位需要的能力，才有可能让你转岗。

举个例子进一步说明，职场潜规则里，如果有几方利益相关团队要推动一件事情，潜规则就是哪个团队受益多，哪个团队就会更主动推动这件事。

你的小算盘是转个岗，学点新东西，公司想的是每个人安分做一颗螺丝钉，做好自己最擅长的事情，工作效率才高。

双方利益有一定的冲突，这时候如果你表示，我已经具备新岗位的能力，对公司来说，只不过是把你这个螺丝钉换了一个位置，而不是重新在新岗位造一个螺丝钉出来，这样公司会容易接受得多。

所以结论就是，想转岗，先自己学，能胜任了再去提。

回到我的个人经历，由于参与的几个项目都是使用了 Unreal，所以技术上有比较好的一致性。

由于自己平时也比较重视跨界知识，引擎那一块基本也有一定的熟悉度。于是和领导提了一下想转做引擎的事情，领导说忙完这个项目就让你去搞引擎。

很快找到了一个好机会，开始去 Splinter Cell 4 项目做引擎。接到的第一个任务，是独立把 Unreal 引擎移植到 Xbox360 的 Alpha 版开发机上。

当时接到任务，虎躯一震。Xbox360 架构和 PC 不太一样，当时 Epic Games 官方也没有 Xbox360 版本的 UE 可用，我们找了一个其他游戏 Xbox360 移植参考，但参考价值不大。

因为 Ubisoft 喜欢深度定制引擎，Unreal2 的引擎部分已经被 Splinter Cell 组改得面目全非，估计连 Tim Sweeney（Unreal 引擎的爸爸）都认不出这是 Unreal 了。第三方的引擎移植无法直接参考。

那就开始搞吧，拉了一个分支版本，二百万行代码，无从入手，先编译通过再说吧。

我建立了 Xbox360 的项目，开始编译，不停修改编译错误，一时搞不定的大问题，就先把整个模块注释掉，做好笔记以备后续修复。

当时开发环境也比较差，Xbox360 编译器 Bug 还挺多，而且预编译头文件设置有 Bug，预编译头文件非常小，且无法通过参数扩大。

这就导致大量代码无法放入预编译，偏偏 Unreal 的结构重度依赖预编译，我的代码编译速度极慢。编译的时候就只能看看文档，什么都做不了干着急。

我没日没夜搞了 1 个多月都没有完全编译通过项目。每次开周会的时候，都觉得自己快死了，翻来覆去就只能汇报说自己还在和编译器搏斗。

游戏引擎的前期移植，不比大规模开发，前期移植通常只能让很少的人参与，基本无法并行操作，你都编译不过，别人怎么插手。

如果我搞不定，就要换一个人来搞，浪费很大。估计老板也是心里骂娘但嘴上不说，鼓励几句让我继续搞。

心理压力是一方面，能力短板也是另一方面的问题。虽然我做了很多引擎技术的提前储备，真正面对整个引擎规模的移植，还是发现缺口不少。

我在业余时间拼命补课，把不懂的东西学会，才能推进。但很快又碰到新问题，有些领域是 Unreal 专业领域的知识，并非通用知识，很难学习，也找不到人咨询，而且涉及到的面比较广，没有办法在短时间里面全部看透。

这就需要我在信息不完备的情况下做技术决策，这个模块大致应该往什么方向做，如果出了问题怎么办，我可以怎么回溯。

做一两个决策还好，但往往是一个决策套着一个决策，前后的技术决策有依赖关系，要回溯就要一起推翻。

没有什么坚实落地的技术决策，就好像走在半空的索桥，每一次摇晃，都在动摇我信心的根基，做到后来都怀疑人生，觉得这活真不是人干的。

好在终于还是编译通过了...然后就是调试程序，要让引擎运行起来，哪怕没有渲染也不要紧，只要有主循环跑起来就好了。只有那样，更多的同事才能参与进来帮忙。

后面断断续续又有了很多的障碍，Xbox360 的内存模型以及 Alpha Kit 的 Bug，序列化的 Big Endian 和 Little Endian 的区别，Fix Function Pipeline 在 Xbox360 里面完全被去除了，性能的问题等等。

硬着头皮一一搞定，终于勉强在电视屏幕上画出点像素，虽然各种飞面，光照全错，一会就会 Crash，但至少把主循环跑起来了，当然也是基于很多不知道是正确还是错误的技术决策。

先快速走通流程，比什么都重要，铺好了路，咱们的大部队就能一起来和我并肩作战啦。

当时已经和主干的开发版本分开两个多月了，于是又花了 2 周来 Merge 最新的改动，整个开发团队那时候就有 20 多个程序员，几十个美术和 10 多个关卡策划疯狂的上传，Merge 的过程也是非常不顺利。

Merge 了几轮，才勉强追上项目的进展。然后趁大家周末休息的时候，一口气上传了所有的改动，还要抓紧测试看看主干版本，带上了 Xbox360 的代码，是不是还能编译，是不是还能正常运行。相关的工具也都需要简单测试一下。

忙完这一切以后，自己有了非常大的变化。最重要的变化，是终于有了技术上的自信。觉得没什么是自己搞不定的了，只要给我足够的时间。

尼采说过，杀不死我的，只会让我更坚强。做过一个规模足够大的工作，在绝望里挣扎过，这样的经历非常能锻炼人。

那几个月整天低头 Coding，基本不用和别人说话，一坐就是一天，和编译器斗，和 Xbox360 Kit 斗，和 Unreal 斗，经常陷入困境，也时不时会有突破，随时进入心流状态，收获自信和满足。

现在回忆起来，那几个月也成为我技术历程中最大的一个飞跃。

今后的很多工作中，有了这个自信，就开始敢在技术上决策，在团队里面，有些事情自己搞不定的话，别人也很难搞定，也就不再想太多。和团队也逐渐建立起了信任，大家就更愿意让我做决定。

做到这一步，整个引擎勉强能跑，但没什么东西是正确的，渲染模块还是一团混沌，逻辑方面都没有正确工作，还需要艰苦的工作。

后续还需要把我一路 Rush 过程中欠下的技术债一一偿还，把整个版本弄成 Xbox360 上可以顺利跑起来，再做架构调整，适应新主机的新架构，充分利用多核框架。

2005 年搞多核引擎框架，还是个高科技。很多可以做的，很多可以学习的。非常可惜，由于工作上的调整，我被调离了这个项目，去另一个 FPS 小项目做 AI Leader。

这个经历下面接着聊，主题就是从 Senior 程序到 Leader 的过程中，又有什么是重要的。

快速总结一下中心思想：

• 公司不为你的野心买单，为你的能力买单。你想要什么，先让自己能配得上它。
• 经历过绝望挣扎，才能变得更强大，迎接挑战，建立你的技术自信。

如何做好技术管理？

上面聊到，好不容易转职，做了一阵子引擎移植，涨了很多经验，结果做了一半被公司调动去做另一个项目的组长。

技术专精到技术管理，并不是那么顺利。不是能做好技术攻关，就能做好技术管理。这里聊聊在这个过程中的收获和成长。

我接手的团队大约有 10 人左右，在一个 Unreal 引擎开发的 FPS 项目中做 AI 逻辑。整个项目团队规模不到 100 人，程序团队就分了三组，引擎、网络和 AI 逻辑。

新角色的定位，是一个冲在一线的技术管理职位。这也是我第一次做 Leader。

对我来说，摆在面前的难题有几个：

• 团队融入
• 个人效率
• 大局观

团队融入

先要做的是团队融入。UBISOFT 那段时间的人员流失不多，国内强力的网游公司不多，没竞争力，所以组长级别以上的都是熟人，合作多年，不存在什么问题。但组员就比较麻烦，多数都是新加入公司的，不知道能力。

和软件开发一样，我融入方法是小步迭代，逐步了解团队成员的能力。对不熟悉的同事，分配一点简单的工作，了解能力的同事，可以领一点更困难的工作。然后定期跟进后续的，过一段时间差别就很明显了。

如果把开发者能力作为 Y 轴，把积极性作为 X 轴的话，我们就可以构建四个象限，把开发者们一一对号入座：

• 积极且能力强的，明显学有余力，保质保量完成工作，而且非常积极，主动来要新的任务。
• 积极但能力弱的，做得很努力，不是很能跟得上节奏，但也是非常投入。
• 不积极但能力强的，能比较快做完安排的任务，然后也不帮别人，也不来汇报，自己在角落 happy。
• 又不积极且能力弱的，组里倒是没发现，也是万幸。

了解了几类人，就可以分别用不同的形式管理：

• 积极且能力强的，可以给更难的任务，让他放手去做，然后主动汇报进展即可，平时也不用太多催他，能搞定的自然能搞定，不能搞定的他也会提前汇报。
• 积极但能力弱的，给一些稍简单的任务，同时加强辅导，帮助他在技术上能提高，多回答他的问题，给他更好的个人发展方向。
• 不积极但能力强的，是比较难处理的。任务可安排稍难的，但要特别注意回避那些需要多方沟通、模糊地带的任务。
• 此类同学往往比较懒，不善于或者不愿意推动事情，经常会卡住。然后要多跟进，除了正常的 daily/weekly 的汇报，还要常常关心一下他的进展，让他了解到，Big brother is watching you。
• 不积极且能力弱的，试试能不能挽救，不行也只能放弃了。

那怎么能准确的判断员工是哪种属性呢？新团队的磨合，其实就是一个彼此试探的过程。

你做得好，就领更多的任务，我对你信任+1；你做砸了，我就给你更简单的任务，信任-1。

主动积极汇报和领任务有印象分+1，看见你偷懒进度慢就印象分-1。细心观察一阵子，就很快有准确结论了。

而且猜错也没有关系，这是一个持续调整和逼近的过程，这次错了，下次改回来就好了。

这是一个主观判断，也许有些同事和你合作就是表现不好，有些同事和你工作就会有超常发挥。但没关系，管理就是一个比较主观的事情，在你的团队里，怎么用人还是由你来判断的。

个人效率

下一个问题是个人效率管理问题。之前做开发者，同一时刻需要跟进的事情并不是那么多，一个简单的 To Do List，或者往桌上贴点报事贴，基本就能把要关心的、要搞定的事情都跟踪起来了。

做了 Leader 以后明显不一样，同时要关心很多事情，而且不同的事务，轻重缓急不同，时间属性不一样。

怎么对任务进行合理的分类管理，是摆在面前的一个大问题。我尝试了很多个人效率管理的手段，最后找到 GTD 系统，能满足我的需求，这是我的一个非常重要的 Life Changer。

我翻了国内外论坛的几千篇 Mailinglist，接触到各种奇奇怪怪的 Lifehack 理念，尝试了几次，成功实践起这个流程，极大地改变了我的生活和工作。

个人效率管理系统，本质上，是一个减压系统，降低你的焦虑，帮你跟进琐事，让你把精力聚焦在真正需要思考的事情，而不用担心又遗忘了什么承诺。

很多人会觉得个人效率管理太麻烦，生活不就应该是自由自在的吗？我认同的却是，自律才能得到自由，个人效率管理是通向自律的一扇窗。

对每一个认真对待生活和工作的职场人，应该要去了解一下适合自己的个人效率管理系统。

GTD 也许太庞大，太重度，不适合你，那就做个更简化的系统，很多理念是有价值的，当你知道了，实践了，就再也回不去原来那个纷乱无序的生活。

GTD 系统就不展开说了，书籍、讨论非常多，也有很多以 GTD 为核心做了精简的管理系统。

只提几个重要的观念：

• 好的个人管理系统，可以帮助大脑减压，把对他人或对自己的承诺记下，就可以从脑中 unload 这些承诺，降低了记忆负担，真正可以做到Mind like water，关注手头工作。
• To Do List 是有 context 的，本质上是为了减少使用 list 时候的无效精力开销。这个我模模糊糊也知道，但一直不知道如何合理分类。

GTD 给了非常好的示范，类似 Errands、Waiting For 列表，给很多不知如何分类的任务以最好的归宿，真正做到以尽可能低的成本，跟进尽可能多的事情。

• Next Action 是推进很多事情的关键，但凡执行一件事稍有阻碍，我们就可能拖延。分解 Next Action 可以降低这个阻碍。

当然我见过好多有才能的人，并不重视个人效率管理，依然取得了巨大的成绩。

每个人有自己的活法，一套好的个人效率管理系统，会增加你人生的吞吐量，要想富先修路，没有 I/O 怎么能升职加薪呢。平凡的我们，通过合理的效率管理，也许就能在职场上走得更远一点点。

大局观

大局观是一个比较难培养的能力，不在其位，不忧其心，就不会有机会锻炼。

第一个和大局观有关的是跨团队协作。项目中不只有你一个团队，AI 逻辑团队作为一个中央枢纽，要把关卡策划服务好，对接 UI 美术，把引擎功能包装整合，配合 Online 组开发 Match Making，和每个组都有或多或少的联系。

很多时候，本团队工作安排最优不代表全项目工作安排最优，跨团队的合作，该强硬的时候要强硬，该让步的时候要让步，一切以项目利益最大化为目的。

由于 Leader 们私交都不错，合作多年，相对来说跨团队合作都还好，没有太大的问题。

第二个和大局观有关的问题是对自己团队工作的把握。什么时候该鼓励团队探索一些先进技术，并且在研究不顺利的时候决定继续还是喊停，什么时候应该保守一点，收敛需求，确保能完成相关特性，这就是一个典型的例子。

这方面要做好，需要有广泛的领域知识，也需要一些跨界知识，更需要多个项目的经验。

因为做决定的时候，也是在信息不完备的情况下，一个好的决定也需要一点点运气。

第三个和大局观有关的问题是控制团队工作节奏。要试图理解整个项目阶段，我们团队的工作对项目交付有什么影响，什么时候我们是瓶颈，要加速做，什么时候我们有闲暇，可以放松一下，做点长远技术投资或是清偿一下技术债。

当然，AI 和逻辑团队永远都是瓶颈，所以也不用想太多，努力工作就是了。

第四个和大局观有关的问题是组内的工作交付问题。有些同事虽然很努力，但总不能交付理想的成果，是换人来做，还是只好选择原谅他？

换人来做意味着新同事要重新熟悉这一块的工作，老同事会觉得很沮丧，不被组织信任。换了新人如果搞不定怎么办？

有几种可能，要么这件事就是不容易搞定，要么第二个同事还是不给力。所以换人做的话，一定要确保新接手的同事是信得过的，避免再次出现换人。只要新接手同事没做成，就告诉自己此路不通，我们想办法绕路。

第五个和大局观有关的问题是你要控制你自己。Leader 相对来说总是一个团队技术最好的，看见大家搞不定事情总想着要冲上去帮忙，找一下智商优越感。

也很正常，人总是希望做自己擅长的事情。一起干活本没有错，也能很好提高团队士气，但是时机和工作内容要选好。

千万不要选择在关键路径上的任务，如果搞不定会影响整个项目进展。因为 Leader 在中前期总有各种重要的技术选型和决策要做，在中后期总是陪加班和调配资源，应付突发事件，哪件事都比上去搞定几个任务重要。

如果手头有关键路径任务，往往都是最难的，工作中又无法抽出整段时间专心做，很可能会拖累整个项目。

找点可以独立的事情，可以是比较难的长线任务，也可以是没有太多依赖的疑难问题 Debug，或者是做做优化，这些事情既能找到满足感，没时间搞定，也不会对项目有太大冲击。

总结一些中心思想：

• 了解好组员，用最适合的方式管理大家。
• 个人效率管理对提高个人吞吐量至关重要，降低自己的焦虑，帮助自己成为一个更可靠的人。
• 培养大局观，做好协作，把握工作方向，控制工作节奏，关注组内同事交付，控制自己想做技术的冲动。

缓解焦虑，走出舒适区

做完那个项目的 AI 团队 Leader，后续继续回 Splinter Cell 组做引擎相关工作。

Leader 已经做好了多线程的架构，我进一步在 Xbox360 上做优化，很多有趣的优化点或者高难度的 Bug，在 Bug 往事那里都说过，就不重复了。

后续项目在一个很小的项目里面做主程序，目标是 4 个月完成 Rayman 疯狂兔子的 Wii 到 Xbox360 移植，并提交审核。

之前的积累效果就显示出来了，一开始还是只有我一个人做前期工作，移植 Wii 版本的 Jade 引擎到 Xbox360。有了信心，就不再惊慌，加上运气不错，一个多星期就完成了初步移植。

但总体来说，今后的 2-3 年里面，没有突破性的提升，无论是技术上还是管理上：

• 从管理上来说，外企普遍有的玻璃天花板，在 UBI 也存在，中方员工在发展上总是吃点亏。
• 在技术上，没有机会从头做一个引擎，总是遗憾。

UBISOFT 是一个很强的技术公司，内部技术相当出色。但对引擎程序员，有一个非常大的限制，就是基本没有机会从头参与开发一个引擎。

你的选择，无法在已有的 Unreal 为代表的商业引擎，或者法国人做出的 Open Space 以及相关各种分支引擎，或者加拿大分公司的一堆引擎里面选择。

而当时国内公司，各种自研引擎已经满天飞，面试招聘的时候经常碰到各路小团队 CTO、技术指导，表示做过某某引擎，还有人语重心长的劝我，表示做引擎没啥难的，想做就做一个呗！

大多数此类引擎的水准，大致停留在 10 年前，往往只有渲染部分处在 5 年前的”领先”水准，工具链、跨平台、多人协作等各方面，都没有看见什么深入的考虑。

但另一方面，在 UBI 这样的公司呆久了，不自觉的对从头做一个引擎有着巨大的恐惧感，公司内部有足够多的好选择，必要性不大，而且见过了一流的引擎，庞大的工具链，会不由自主高估困难性。

但内心的蠢蠢欲动，还是推动着我，走出下一步。2009 年结束的时候，来到了腾讯。先去各个部门打了一下酱油，了解了一下公司，然后参与了天涯明月刀 OL 项目。

对我而言，这个项目是我第一个正规的网游项目，虽然在前公司也参与过一个网游项目，但外企在思路转型上远远谈不上到位，国内免费游戏都做了很多年了，外国老板表示还有免费模式，真能行吗？

这个项目也是一个好机会，让我有机会带团队真正从头做一个现代的引擎。

天涯明月刀的引擎和游戏开发经历按下不细说，和咱们这个主题不一致。还是围绕个人成长，展开说说。

一到腾讯的时候就非常紧张，过来的时候 Title 是高级架构师，我有着极其强烈的不能胜任感。

对我来说，有一些领域是全新的，首先在客户端领域接触到了国内常用的 Game byro 等引擎，和 UBI 一系技术完全不同，当时也无从判断究竟 Game byro 之类的引擎是不是代表了先进方向。

其次在服务器领域也是见到了国内常用的技术，在协议处理等角度来看，是相当简单粗暴的，习惯了欧美一套复杂处理方法，非常不适应。

更大的挑战在于，以前大量项目都是基于移植或者成熟大型引擎，现在一下子拥有更大的技术发挥自由度，在更简陋的开发环境中，反而不知道从何做起了。

在这么多年的个人发展中，总在那些关键时刻，有一些不能胜任感，然后奋起直追，让自己慢慢胜任。

直到前些年在腾讯的经历，才让我意识到这适度的焦虑给我带来的帮助，我也开始更刻意的让自己常常有一些不能胜任感，以避免自己过于安逸。这个不能胜任感，换另一个说法可能更能被人接受，叫做走出自己的舒适区。

为了缓解焦虑，开始了疯狂的学习。那两、三年的阅读量非常大，每天都有 3-4 小时在看技术资料，做笔记，分析和思考。

先要补上自己的短板，把自己不熟悉的领域熟悉起来。好在孩子还没有读书，也有足够精力，我每天早上提前一个多小时就到单位晨读，晚上回家还会抽出很多时间阅读。出差时，晚上或者周末也在酒店阅读。

几年的高强度学习，逐渐缓解了我的焦虑，系统的阅读了大量主题书籍、Gems 类型书籍和会议 PPT 等，大致找到了感觉。可以和别人侃侃而谈，不再会在拿出名片的时候脸红于架构师的 Title 了。

从一个技术指导（Tech director）的角度上，我不需要事事都会做，自有优秀的同事来搞定，我只是偶尔需要在必要时刻，保持一定的突击能力，可以冲在一线解决困难的问题。

但我必须事事了解，知道技术大致的 Tradeoff，知道复杂度，知道和其他系统的关系。换句话说，这个时刻，技术广度对我来说，比深度更重要。

技术深度的方法可以通过突击学习，广度积累当然也可以，但还有其他方法可以做到。

毕竟这时候我也工作了十几年了，不如刚毕业的时候精力旺盛，孩子也是一个精力黑洞，如何多快好省的培养自己能力，提高效率，变得更重要了。

介绍一些有趣的实践方法，可以帮助积累技术广度：

面试学习法

我常年负责游戏客户端领域的技术通道面试，技术通道面试可以简单理解成对面试者定级别的复试。

同时我自己的团队也招了很多人，面试非常多。从 HR 的反馈来看，被面试的人，表示我面试时候领域知识问得深入，且范围很广。

在面试时，面试官有巨大的优势，面试者的经历简单扫一遍后，就可以随意发问。

我有主动权，可以声东击西，选擅长的深入问，不懂的可以简单带过，保证不露怯。

也可以长驱直入，对自己感兴趣的领域，让面试者深入讲讲，听个大概，成为自己事后了解这个领域的入门材料。

可以左右互搏，对于一些面试者的有趣观点，随手记下，下次可以问另一个面试者怎么看这个问题，让他们的观点彼此 PK。

可以温故知新，顺便和面试者讨论讨论一些主题问题，把平时学习的新技术用上，如果他回答不出来，正好复述一遍，既帮他开拓眼界，也可以加深自己对这个技术的印象。

面试学习法很适合快速拓展知识面，每次面试都是一次技术切磋，如果有机会面试级别高的开发者，更是一个很好的成长经历。

项目评审学习法

公司内部的项目评审技术评审，也是一个不错的学习途径。腾讯的内部游戏开发，有较完善的流程，除了产品评审环节，也有技术评审环节。

我做了几年技术评委，通过参加评审，我有机会了解每个项目大致面临的技术难题，也经常能看见一些闪光点。

比起面试学习法，技术评审接触的都是公司内部同事，即使有什么东西当时没有理解正确，或是过了很久想到这个技术，细节都忘了，也可以找到当时的同事请教。

职级晋升学习法

公司内部对程序员的技术能力升级，有一整套考核，到了一定的职级，就需要有正式的答辩环节。

我常年负责技术评审，申请晋级的同事们会准备自己的工作成果展示，我能看见大量技术问题的分析和解决方案。

和项目评审中的学习有所不同，项目评审时角度更宏观，具体技术细节不会涉及太多，而自己职级评审中，每个同学都是竭尽所能，从各个角度介绍自己的技术，有问必答，还有事后给面试官送补充说明材料的。

刚参与技术评审的时候，两天评审中，往往能有 2-3 个技术点让我眼前一亮。

当然这个学习的衰减速度非常快，前几年的评审，往往两天听完，也没有什么有趣的技术点了。

业界会议学习

游戏圈子比较开放，每年的 GDC 或者其他开发大会，都会有开发者无偿公布很多新的技术，或者总结自己项目的得失，介绍好的实践。

参与这些会议，是最好的手段，可以快速和国际顶尖水平开发者对齐。你需要的只是一张来回机票，几天住宿，一张门票和英语听力。

每次参加完会议，总是特别兴奋，有很多好想法想和团队分享，有很多改进可以做进我们自己的引擎。

如果没有那么好的条件可以去现场参加会议，也可以关注会后放出来的免费材料，或是购买付费会员账号。

上述的学习实践，本质上就是多听多看多聊，和其他项目多社交，多聊聊技术，出去多看看其他公司怎么做项目，坚持做一阵子，自然就有了技术广度理解。

即使做到了自学成才主攻技术深度，也做到了多社交主攻技术广度，依然有可能有不足。

群体学习

上面聊到扩展自己的知识广度，可以通过社交化手段（面试、评审等），或是参加专业会议来达成。

我们的学习方法，还差一个环节。进一步可以做的是群体学习。发动团队的力量，大家一起来学习，补足自己精力的缺失，也帮助团队提高能力。

以前在项目组，会做一个每周分享的活动。不管 Senior 还是 Junior，按照姓名排序，轮流来做一个 30 分钟的分享。

涉及主题可以是新技术，可以是工作中解决的重要问题，可以是外部的有趣技术分享，可以是展会、读书心得，找自己擅长的就可以。

每周两个同事分享，占用整个团队 1 小时左右，因为团队人比较多，轮一遍要好几个月，所以这个活动对听众是一个很好的放松，也不会对分享人造成非常大的压力。

做这件事，无论是对个人，还是对团队，都有很大的意义：

• 扩展广度：可以充分发挥团队力量，开拓视野，经常能看见一些让人眼前一亮，但自己扫描的时候被疏漏的技术点。
• 提高学习质量：逼着大家在阅读之余做总结归纳。一个知识如果看完了只是模模糊糊有所了解，那么说明你对它的了解还不够深刻。

如果能总结出来，分享给别人，那你肯定就能深入了解它了。最好的学习，就是把这个知识教给别人。

• 锻炼表达能力：程序员往往内向不善表达，促进大家分享，也是一个好机会可以教大家怎么和人沟通，怎么把知识点更好的表达出来。软性技能在个人发展的中后期非常重要，但却往往被人疏忽。
• 促进团队交流：促进团队间互相了解，比起吃喝类型的团建，这类活动更能让大家在工作上达成默契。

有时候工作中碰到某个技术，想起前段时间有别的同事分享过，就可以翻出 PPT 再看看，看不懂也可以直接和这位同事沟通，得到进一步的帮助。

• 减少团队流失：促进学习氛围建设，也能稳定团队。游戏开发总是很忙，如果没有机会让大家有所提升，做几年技术人员很容易荒废。

看上去很美的团队学习，实行一段时间以后，也发现了不少问题：

• 能力不匹配：团队能力和精通领域参差不齐，导致很多话题，一些人聊得津津有味，另一些人完全听不懂；或是 Senior 对很多初阶主题明显不感兴趣，给 Junior 程序员很大的心理压力。
• 有些员工分享能力实在不行，很好的选题，但讲的时候就是平铺直叙，不考虑目标听众的理解。
• 工作进度有压力，不能一直坚持。轮到某个里程碑版本要冲刺，就很难保证分享活动持续进行了。
• 大家随意分享，广度有了，系统性不足。

针对这些问题也可以做一些改进：

• 能力不匹配，可以想办法通过提前审核选题，来确保题目是多数人感兴趣的，也可以通过小范围组织分享，找更合适的小团队来群体学习。
• 分享能力不够，可以通过更多的辅导，帮助串起技术、提炼分享线索、考虑受众接受度、提前准备逐字稿等方法提高质量。
• 工作进度压力客观存在，真坚持不了分享，就暂停一阵子，等忙完再恢复好了，对学习来说，来日方长，不争朝夕。
• 系统性不足，可以通过组织主题学习的方法，或者有专人扫描某一次会议所有议题，或者一起深入读一本好书，轮流分享其中章节，或者针对某一技术领域，遍读相关文章，做全面介绍。

坚持团队学习大原则的前提下，细节上可以灵活把握，变着花样，让大家有新鲜感，养成良好的学习习惯，也能从队友的进步上有所收获。

另一个容易被忽视的地方，是整个流程一定要足够的轻，越轻，越容易推动，太重的流程，容易胎死腹中。

专业领域的积累差不多就聊这些，作为技术总监，还有更多的软性技能需要锻炼。

从技术，走向一线的技术管理，遇到的最大问题是个人效率。而从一线技术管理走向间接的技术管理后，新的问题又涌现。

随着级别提高，管理范围的扩大，个人的工作逐渐呈现碎片化和间接化。对事的管理，渐渐变为对人的管理，也给我带来了很多的困扰。

碎片化是首当其冲的问题。在新的岗位上，业务复杂性大大增加，精力会被极大地碎片化。

大公司的流程本来就复杂，除了项目，还会有各种其他部门和外部公司，为了满足他们的 KPI，来占用你”一点点”的时间。

每个团队真的只会占用你一点点的时间，但架不住团队多。这是外部复杂性，如果咬咬牙还能避免困扰，大不了在最忙的时候，就拉下面子全推掉所有的邀约，也能有个清静。

外部复杂性可以翻脸，但是内部复杂性是无可避免的。做组员的时候，会觉得项目开发是有周期的，有忙有闲，除了最终版本是持续冲刺，其他时候很明显会有段落节奏感。

但在新的岗位上，再也没找到过节奏感。我当时主岗不在项目，天涯明月刀项目是兼岗。

往往是项目冲刺的时候一起熬夜，搞完一阵子大家放松了，我开始处理主岗的积压工作，差旅奔波。

组员回血的时候，我在回顾上一阶段得失，在制定一下阶段规划，接下来该做什么，该怎么做，如何动员内部资源，是不是要引入外部资源协助。组员加班冲刺的时候，也要跟着一起往前跑。

而且大项目，总有这样那样的问题，天天忙着救火，这里消停了，那里又出问题了，要轮流去关注，经常去支持。

工作中对碎片化问题需要特别警惕。技术学习需要不被打扰的 Unbroken Time 技术管理和决策更需要 Unbroken Time。

但在工作中，技术管理者是很难享受到不被打扰的时间。在开放的办公环境，人来人往，大家向着你的工位，带着他的疑问和诉求，希望能分享你的一点点时间，来让整个项目变得更美好。

你又怎么忍心拒绝他们，关闭心门？最常见的做法，当然就是割下你的一小片时间，分给你的队友，换取和谐和共同进步。

悄悄的他走了，正如他悄悄的来

他挥一挥衣袖，留下了一只猴子（注1）

注 1：[别让猴子跳回背上(豆瓣)]，有趣的个人效率管理理论，把任务比作猴子，每个人身上都爬满了猴子，上级要避免把下属的猴子接过来。

这是一部关于职场陷害和反陷害的书，反映了资本家管理者和白领员工不可调和的结构性矛盾。

但当你的时间支离破碎，你就没有办法去做高质量的技术决策，没时间思考项目方向，没精力考虑团队管理。那些才是你更重要的职责，对团队会产生更长远的影响。

工作中的幸福程度，和你同时需要关注的事情成反比。

by 某总监

让我们一起来做些什么，打响反碎片化的第一枪：

• 带上笔记本电脑，从工位上消失。写报告、做 PPT、做规划的时候，这一招最有效。

相当于你有一个虚拟的会议，这个会议就是你和自己的约定，说好了这次一定要搞定的呢，别给别人打断你的机会。

• 和大家沟通，说明自己的情况，然后约定沟通的方式和时间段，把同步的沟通变为异步的沟通，小事留言，大事发邮件，天塌下来才可以找我。

当然本质上这是影响其他人效率的，所以适可而止，只在最需要的时候才用这招。

• 每周空出一段固定的时间思考，不约会议，不排任务，身体和灵魂，总要有一个在思考，如果不是两个都在思考的话。

时间是有弹性的，每次面临出差或是休假，总能在最后几天把任务全部 Close 掉，效率会得到提高，同理，如果每周预留出一个时间段给自己来思考，那剩下的时间无疑会更高效。

当然实际没有那么理想化，总有这样那样的例外，总有不合适的时机。但只要有这个意识，试图给自己留出一些高质量的思考时间，就会有帮助。

碎片化不可避免带来了焦虑和压力。专业能力上我逐渐找到了感觉，但在面对压力时，还是会恐慌。

本质上来说，压力来源于目前的能力不足以支撑你的野心。无论是我早期的引擎移植中遇到的专业能力，还是做这个项目遇到的管理压力，都来自己能力的不足。

治大国若烹小鲜(肉)

by 老子，道德经

没有太好的手段来解决压力和焦虑，举重若轻的自信，来自于更高维度的能力。

对我而言，第一次成功的引擎跨平台移植后，面对新的类似任务，压力就小很多。管理过 30 人以上的程序团队，回头再管理 10 人团队，也不会有什么焦虑。

没有捷径可以不焦虑，但有一些简单的方法缓解焦虑：

• 短期来看，良好的作息习惯。如果天天加班，回家就好好休息吧。别总是觉得公司加班的时间是留给公司的，晚上回家一定要给自己留点时间，熬夜玩一下。没什么是晚上早早睡觉不能解决的，如果有，那就再补一个午睡。
• 中期来看，搞点体育锻炼，据说 XX 能很好改善精力，且有巨大快感。这一点我深表怀疑，因为从我有限的运动经历来看，每次运动完，我都没有那种酣畅淋漓的感觉，一般的感觉都是更累了。

考虑到时代在变，白领们装的方式也在变，现在就是流行说自己爱锻炼，锻炼包治百病，想来体育运动对缓解焦虑应该也有一定的帮助吧。

• 长期来看，当然就是提高自己的能力，让自己配得上这个岗位。至于怎么做，这个系列你都看快看完了，还要问我这个问题？