这篇文章主要想探讨一下游戏开发中的团队管理问题，本质上讨论的是团队生产力问题。我做过服务端主程，也做过软件部门的技术经理，对于这个主题是有一些心得可以讲一讲的。
本文将首先讲一下技术团队管理的目标是什么，之后展开讲如何实现这一目标，最后再讲一些疑难问题的处理。
1. 目标是什么
技术团队管理的终极目标是什么？是做出牛逼的架构，写出牛逼的、bug很少的代码吗？
都不是，赢才是终极的目标[1]。对于一个游戏开发团队来说，所谓赢，就是按时完成一个个里程碑节点，做出玩家喜欢的可以给公司带来盈利的游戏，其他的一切都要服务于这个目标。
技术人员容易陷入一种自嗨的状态，被技术限制了视角，把架构，把代码看得过重。在错误的优先级思维下，做出错误的时间规划。
实际上，拆解下来，技术团队的核心任务就是：10x生产力，也就是 Elon Musk 在 Tesla，SpaceX 团队达到的状态。
2. 如何实现目标
这里是从一个技术 leader 的角度来思考如何达成目标。
2.1 解决技术与策划的分歧
很多时候，技术觉得策划的一个方案实现起来麻烦，就百般推脱，以各种理由来拒绝，如果策划强势一些还好，基本上还能实现还原度比较高的方案，如果策划软一点，就会出现在各种折衷之后，实现出一个没啥用的功能。
这个时候，技术 leader 就要发挥作用了，我们的终极目标是赢，得跟策划合作，做出一个理想的玩法，leader 要积极参与需求评审，要多站在项目角度、策划角度去思考问题。这里[1]提到一个更绝的做法：让程序员写一写策划案。通过这种换位，让程序员获得一种策划思维。
2.2 架构
架构最终是会反映到生产力上面的，技术 leader 要有优秀的架构能力，争取在一开始就做出合适的架构设计。
2.3 优先级思维&技术债
一切事情都需要计算优先级，计算 RTO，得具备基本的优先级思维。
为了赶一些时间节点，往往是不得不欠下一些技术债的。技术 leader 在这里的作用就是评估，当下能否欠下这个技术债，它对于终极目标的实现会有何影响。
2.4 团队士气
技术 leader 应该做一个戾气终结者，该威的时候威，该和的时候和，消灭戾气，消灭消极怠工的情绪，要始终强调团队的愿景：按时完成里程碑，做出赚钱的游戏。
2.5 团队能力
能力来源于复盘，要定时的在团队内部做归纳总结，犯的错误不要再犯，一些设计上的经验要沉淀下来。
2.6 PM 视角
作为一个项目组，单纯程序员把活干好是不够的，各个工种都需要协调起来把事情做好，所以一个技术 leader 不应该只局限于管理技术团队，他还需要有 PM 视角，洞察出 PM 没有发现的影响生产力的问题，提出来，并协调解决。
比如策划团队很拉跨，而主策划又没能把团队管理好，怎么办？从赢的终极目标出发，技术 leader 也需要指出问题，并且一起探讨解决办法。
2.7 技术上的选择
经常需要面临一些技术上的选择，这个很考验技术功底，试举几例。
2.7.1 怎么开展优化？
优化是个很危险的东西，正如这个 halo 在 GDC2011 分享[2]里说的：
既然危险，那要怎么开展呢？GDC2011 Halo 的这个分享视频[2]里面也强调了优化的关键在于实测数据，要使用各种工具进行测量得到数据，再对数据进行分析。不要靠猜测或直觉去做任何优化。否则将可能是获得 1% 的优化效果，但却导致一两个星期的 bug fix。
陈硕在他那本《Linux 多线程服务端编程》[3]讲到线程同步的时候也提到了实测数据的重要性：“在没有实测数据支持的情况下，妄谈哪种做法效率更高是靠不住的，不能听信传言或作风感觉"优化"。很多人误认为用锁会让程序变慢，其实真正影响性能的不是锁，而是锁急用(lock contention)”。
聊到这个，就不得不提起我做过的数据库优化了。我的第三份工作是在一个规模较小的游戏公司做高级游戏服务端开发，做的是一款 MMOARPG 游戏，老板也是做游戏服务端出身的，他在开会的时候特别会挑战。入职后我第一次参会的时候就见识到他的威力了，我的同事被喷得特别惨，因为他们做的东西没有数据支撑，基本上是靠猜测的。
而当轮到我对做的数据库优化工作做汇报的时候，我准备得很充足。优化前，我就做了大量的 log 埋点，进行数据收集、数据分析，精准的定位出数据库性能问题，并且还区分了优先级；优化中，扎扎实实的完成了优化；优化后，对优化结果进行量化，确认优化到位。所以，老板对我的工作赞不绝口：）
2.7.2 设计模式的必要性
游戏开发的复杂性特别高，而迭代节奏又飞快，为了高效做出高质量的交付，我们必须降低系统的耦合度，必须提高系统的可拓展性，所以，要在代码中有效的使用合适的设计模式，帮助我们达到这些目标。
千万不要觉得使用设计模式是在增加代码的复杂度，是在过度设计。恰恰相反，合适的使用设计模式，可以帮助我们建立开发秩序。
2.7.3 单元测试是可能的吗
在游戏开发，对于业务逻辑做单元测试是不太可能的，除非有大量人力。为什么这么说，因为需求改了，测试代码也要相应改，那这样子怎么保证测试代码本身也是健壮的呢？
所以，除非是需求非常稳定的，否则写单元测试其意义已经不大，或者说代价太高了。
那什么地方适合写呢？就是很稳定的那些底层系统，这些可以写单元测试，而且可以写的全面一些。
3. 管理上的疑难问题
接下来的大多是一些老生常谈的问题。
3.1 遇到刺头怎么办？
作为 leader，是不能听任刺头破坏团队纪律，影响 10x 生产力的。我觉得处理步骤可以如下：
1、直接面谈，具体指出问题，并且与其探讨具体需要怎么改进，如果对方做出合适的改变，那么刺头改造结束，否则进入第2步；
2、无法改变刺头，只能解雇，这里要分两种情况，即:
2.1 刺头不是关系户，那么直接有请 hr 帮忙，妥善的解雇；
2.2 刺头是关系户，就跟更上一层沟通清楚所有的厉害关系，如果最终判定刺头的存在，对于我们实现终极目标是会有正向作用的，那么只能忍着了。
3、如果对于 2.2，自己无法接受，那么找机会跑路就是了：）
引出另一个问题，为什么刺头会被招聘进来，是否能在面试环节筛选掉？
大部分情况下，我们是可以通过面试的沟通中觉察出对方的不对劲的，但会人总会失误的，或者说人总会变的。并且刺头也可能是个关系户，这个在小公司比较常见。
3.2 空降到一个团队，要怎么开展工作
一、摸底
了解当前的团队战斗力情况，存在什么不足，列出整改的优先级。当然，还是以赢为目标去思考一切应该如何做。
摸底可以从一对一面谈开始。沟通总是从谈话开始的，不要以浪费时间为由而不去做这个事情。跟 pm、主策划，主美面谈，了解他们对于技术团队的看法，记录他们的吐槽。跟技术团队每个人面谈，收集每个人的想法、困惑。
二、对齐目标
把 “赢” 这个目标在技术团队内部对齐，让大家理解你的一切决定的出发点，取得共识。
不要因为网上抨击的大厂黑话里包含“对齐颗粒”，“对齐xx” 之类的，就对“对齐”这个词抵触起来了。实际上对齐是十分重要的，很多事情都败在信息差上，我们必须尽最大努力消灭信息差。
4. 参考
[1] 安柏霖. 实战型开发1/3–结果&业务导向. Available at https://blog.csdn.net/toughbro/article/details/133531099, 2023-10-08.
[2] David Aldridge. I Shot You First: Networking the Gameplay of Halo: Reach. Available at https://www.youtube.com/watch?v=h47zZrqjgLc, 2011.
[3] 陈硕. Linux 多线程服务端编程. 北京: 电子工业出版社, 2013-3(2):52.
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
