What makes a good lead programmer

原文地址：https://zhuanlan.zhihu.com/gu-yu/20232566

声明1：本文不影射任何行业产品、从业人员，请勿对号入座，保留删除评论权利。

声明2：本文侧重于大游戏开发中的leader岗位，indie game，爱怎么做怎么做

吐槽灵感不足，”为什么”系列文章先搁置一下，写点严肃的东西。

前些天在罗辑思维每天60秒的音频中，听到一句话：

话说多年前我问过一位前辈，什么叫工作能力强，回答是，看一个人的工作能力，就是看他能不能迅速把大目标拆成小目标。

当时非常有感触，也联想到了游戏开发的技术管理工作，道理是相通的。今天我们来聊聊一个苦逼的主程序。

一个游戏的开发中，需要各种工种，由于隔行如隔山，会针对每个团队设Leader，来管理相应的职能团队。对于一个Lead programmer（主程序），最重要的素质是什么呢？不同的项目有不同的要求，最常见的相关素质包括：

• 专业能力无疑是非常重要的，主程序在一个团队里是技术能力比较强的，如果不是最强的话。没有相应的能力，无法服众，分配工作、验收工作方面都会碰到很多问题。游戏开发领域如此的广，没有谁是通才，至少我没见过，对于主程序，至少需要在大多数重要的领域，能和团队开发人员顺畅的沟通。主程序的开发知识可以有不足，但不能有盲点。这一点一般不会有什么异议。
• 沟通能力也是一个重要的因素，团队越大，越需要良好的沟通能力。这部分能力会被低估，很多主程序会觉得程序就应该是一个宅男，专心写代码，以不会讲话、不懂沟通、情商低为荣。事实上在正规团队，良好的沟通能力，对任何人都应该是一个怎么强调都不为过的素质。向下的沟通决定了能否执行，横向的沟通决定了如何协作，向上的沟通决定了如何汇（邀）报（功）。忽悠的能力也是很有必要的，如何吸引高质量人才加入项目，如何在大boss面前把技术包装得深入浅出，既浅显易懂又高深莫测（貌似很难做到...），让听众能有一种智力上的优越感，觉得哇靠这么难的技术我都能听懂原理，我真是天生奇才，又有一种不明觉厉的哀伤，觉得虽然不明白你在说些什么但小伙子你们做得不错。这些沟通能力都能在各个层面对项目产生实质性的帮助。
• 管理能力，由个人管理和团队管理两部分组成，都是至关重要的。对于个人管理，包括是不是有良好的个人效率管理能力，能不能做到其他人托付的事情不被遗漏，定期给予进展的反馈，长期任务能合适的跟踪，短期任务可以快速处理，合适的优先级区分，投资重要不紧急的工作，极强的抗压能力，乐观积极的心态等等。这部分软性技能，对所有的工种都是相通的。团队管理就更容易理解，如何管理下属工作，跟进进展，作为一个团队的接口人，随时掌握团队工作进展，了解自己的团队能做什么不能做什么，关心组员个人发展，确保整体进度正常，提前预知风险等等。对于一个leader，上述能力怎么强调都不为过，可惜很多团队的主程序会更强调自己的技术能力，认为这些管理的工作，随便找个人就能做了。在大公司里面，往往会把Leader和Tech director分开，一个强调管理能力，一个强调技术能力，小团队不能做到这么奢侈，希望两个角色是同一个人，但两者定位是有区别的，如果没有二合一的人才，那要提前想办法弥补。

上述能力都是很重要的基础能力，而听了罗辑思维那段话之后，觉得还有更重要的能力，就是目标分解的能力。对于主程序，所谓的目标，自然不应该局限于一城一地的得失，应该更多着眼于整个项目在技术上能否顺利完成，对其他团队有没有起到合适的支持作用，对于制作人和策划的要求，能否顺利的完成，整个开发流程是不是足够高效，整个程序有没有足够健壮，而不是津津乐道于某个技术有多牛，虽然吹嘘技术往往是大家最喜欢做的事情。技术的单点突破永远不是Leader应该炫耀的事情，而是Tech director的主职，如果一个leader只炫耀自己的能力，不关注团队的整体产出，那就是一个不合格的leader。

所谓的目标分解能力，我自己一直有一个不正规的解释，就是主程序需要有一种没事找事的能力。这个能力会体现在下面几个地方：

• 配合好每一个周边团队：多个不同工种的团队进展速度不一样，很有可能会出现有些团队空下来，或者有些团队非常忙。在项目刚开始，会有策划大量讨论策划案，没空管程序团队，或者美术讨论美术风格，各种原画大比拼。在这样一个阶段，主程序是不是可以给程序团队找到足够的事情，而不是让大家自由发挥，其实是很考验主程序对项目的把握能力，对产品开发周期的理解，以及对技术的敏感度的。程序团队可以参与实现玩法原型，帮助策划理清思路，可以提前开发工具，可以评估各种引擎中间件，闲着发呆不是一个好的选项。项目中期，实现了功能，教给策划去制作内容，你可以不停的改进工具，可以观察留意策划使用工具的情况，提供对工具的改善，是不是需要提前优化一部分内容，整个版本构建流程能否改进，加点便于debug的基础特性，都是不错的工作方向。有些主程序就表示，程序的事情都做完了，接下来全是美术和策划的事情了，这个很不合适。主动多想一下，承担部分灰色地带的工作，才能让项目更好的推进。而不应该看着策划美术加班，在糟糕的流程和工具上挣扎，一边哈哈大笑说他们都是SB，一边说老板你赶紧推进一下偷懒的策划和美术，又拖我们后腿。
• 让每个组员忙起来：团队内部同事的工作进展速度不一样，难免会有空闲下来的同事。如何调配组员间的工作，给空下来的同事安排新的工作，给能力一般的同事安排简单的工作，给钻研能力强的同事安排有技术深度的工作，并准备好他研究技术失败后的plan B。项目后期，大家都在一个crunch状态，特别是作为整合内容的最后环节的一些程序岗位，是不是可以通过优化流程，合理的把一部分工作分配给其他更轻松的岗位的员工，也是leader可以考虑的。组内也可以通过调配资源，让更多程序去支持其他岗位，避免出现有人撸啊撸，有人过劳死的局面。
• 能针对组员情况细化目标：对于大目标，也就是项目顺利进行，有自己的了解，预判项目的节奏，对技术可能的要求，提前安排相关的人手做预研。每一个大特性，如何切分比较合理，可以充分发挥每一个团队的能力，不耽误工期，工作流程上也更容易顺畅进行。每个分解后的小目标，大约要多少时间可以完成，以自己组员的能力，又需要多少时间来做？如果程序组内有几个万能的救火队员，可以胜任多数岗位的工作，那主程序的这部分工作压力就会小很多。
• 不盲目追求新技术，也不轻易浪费灵感：开发过程中会有各种灵感，无论是在技术上、流程上还是玩法上，作为一个成熟的技术管理者，是不是该放任大家去追逐新的技术新的想法？项目有自身运作的规律，进度压力摆在那里。该做还是不做，需要具体问题具体分析，即使是暂时不做的灵感，应该记录下来，确保不遗漏，并在有同事有空的时候去安排开发。尽力做到不挫伤员工的积极性，又不影响团队的进展，合理的安排开发。

没错，主程序其实不应该沉迷于什么上流的技术，这是一个非常苦逼的职位：

• 他应该是团队最后的保险，承担救火队员的职责，出现在每一个最需要他的技术领域，前期新产品孵化，哪里缺人去哪里，后期debug，什么bug难调就由他去搞定；
• 他应该是团队的先知，了解技术趋势，关注兄弟项目或是业界发展，能随时找到适合自己的方案或者找来能帮助自己的外援；
• 他应该承担起沟通职责，是团队和外界的一个技术接口，既能在外部把整个引擎和逻辑底层变成一个其他人能轻易了解的黑盒，又能在内部理解白盒的每一个技术细节，和开发组员沟通具体实现；
• 他应该在冲刺milestone的时候战斗在一线，和兄弟们一起熬夜，提供最坚实的技术支持；
• 他应该在冲刺完milestone后，思考后续节点技术方向如何改进，是不是要重构，有什么重点技术方向需要突破，还有哪些明显的技术短板需要弥补；
• 他需要有common sense，了解一个技术的生命周期和开发难度，不会盲目乐观也不消极悲观；
• 他要为组员发展尽心尽力，让大家有一个好的个人发展，尽力做到项目好、大家好。

大家忙，他也忙，大家闲，他还忙。

说了这么多，不代表我能全部做到，但我会尽力要求自己向这个方向努力。以此文向每一个做过主程序或想要做主程序的朋友共勉。