本文作者拥有多年游戏开发经验，参与并领导了《Finding Monsters Adventure》从手游移植到VR平台的全过程。今天主要为大家分享作者一路从菜鸟到领导人的经验。
说起主程首先联想到的就是具有批判性思维并有过人的决策能力，但常常会忽视其中的人性部分。我们总觉得主程都非常清楚要如何处理代码，却不善于处理与周围同事的关系。
本文主要介绍主程需要注意的两方面：
多与工程师交流，专注于更好的指导，解决冲突并保证尽可能高的开发效率；
多与其它部门及上级领导交流。
首先，人都是情绪化的。不论一个人如何镇定，情绪都会或多或少的影响决策的制定、与他人的交流及工作效率。
冒充者综合症久很好的说明了团队中与代码打交道的人会出现的问题。他们的工作进度和思维方式都完全暴露给同事并且不断地审查。作为程序员，他们相比同事会更缺乏自信。
作为领导的目标就是完成稳定的产品，按时交付最佳优化和组织过的代码。
这些都要在一个激进且易变的环境下进行，游戏开发过程中，功能需求可能随时变化，所以开发流程和交付节点也会随之改动。
多指导人，少编程。
主程只是一个职称，要领导的并非程序，而是制作程序的这群人。所以主程可能忽略了一些事：
级别、资历和经验不同的开发者共同维护一个代码库；
存在不同的编码风格；
不同职位的人直接干涉下一步要编写的代码；
挫折是永远的坏蛋，它影响编码进度。
每个项目都至少有3位程序员，这就可能会面临着技能等级和编码风格不同却希望共同完成一个条理清楚的代码库的问题。
要时刻注意，这些人很可能正在遭受冒充者综合症的折磨，不停与团队成员比较自己是否做的够好。
保持开发进度及开发人员的激情，是在项目开发的整个过程中都要持续的，同时还得要求各个成员都注意代码质量、稳定性及优化，这会涉及到考评。
对于主程来说最需要小心翼翼的就是考评程序员的工作。考评成功与否就在于，是将一个平庸的程序员变成了很厉害的，还是将他打入冷宫然后自己离职或被离职。
由于程序员已经有了与同事攀比工作成果的倾向，所以以代码来评判程序员的工作可能是主程最坏的决定。
一定要非常清楚，一个程序员做出的所有努力都要被赞赏，但不去惩罚他在代码中犯的错误（也不要将错误展示在他面前）。而是与他交流，告诉他你所期望的最好的结果，并不仅仅因为公司要求，同时也表示团队相信他可以做到。
尽管团队所有人都期望能获得好的考评结果，以消极的口吻来传达结果也会让他更专注于当前的情况有多糟，而不是如何提高自己的能力。
作为领导，你可能想创造一个利于大家成长的舒适而安全的环境，帮助大家抵抗外部压力并且在结果不太理想的情况下保护大家不被开除。
而这很可能会被误解为“软弱”。
这种安全的环境要从项目第一天开始就建立好。而主程的日常任务也会包括督查以产生良好结果这一项。
了解团队
分析团队各成员的强项和弱点，编码风格，并且必要时在发现不好的习惯就立即帮他们改正。
规划团队各成员可能会在短期内上手的内容，这能帮助领导及成员们形成良好的编码习惯，并能保持代码库的稳定性和一致性。
消息公开
领导是避免不了要为坏的编码习惯和变动的需求收尾的。而这个过程相当于是对涉事程序员的花式吊打。
他可能会从此进入防御状态并自我封闭。由此可能会出现的状况就是项目开发效率降低又出新错，该程序员的出错率会增加。但也很难发现，因为他会倾向于向大家隐藏自己的工作。
所以在发现坏习惯时要及时出面改正，但不是直接对他说“你这里错了”，而是以建议的形式，告诉他为什么以及如何以另外的方式来做会更好。
坐在他旁边并让他自己想明白如何以更好的方式完成同样任务，可以帮助他更好的工作。然后要清楚他的努力并在他发现新的解决方案时表达祝贺。
如果你是新来的领导，而项目出现问题是因为之前留下的坏习惯，这时候就有必要进行“技术讨论”来。而这个应该是以交流会的形式而非把大家叫过来听你讲。
为何那么多保姆行为
你可能认为团队成员应该足够成熟，可以自己搞清楚问题，毕竟大家都是搞技术的，拥有批判性思维也知道好代码是什么样的。然而，人都是习惯性动物。所以他可能有着自己没有意识到的坏习惯。
习惯是很难改的。改变过程中可能面临触发自我防御机制和自我封闭的问题。
作为领导要理解这种人性，并拥有很好的技能在解决冲突的同时不会出发防御机制。
坦率而真诚可能会对某个人有用，但这更可能会导致领导与成员间的积怨，而非让大家关系更亲密，所以为了完成更好的产品就要让大家都打开心扉。
领导不能只考虑自己的晋升或直接指出“实现它的最佳办法”。做游戏不像钉钉子，如果成员对做游戏不够投入、没有激情和动力，他们也想不出什么有创意的解决方案。要力争提高并创建一支对挑战充满渴望的团队。
开发团队与高级管理层
游戏开发是很精细的过程。团队不仅要制作游戏，还要制作用于其它项目的工具，同时还要保证稳定性并按时交付。
一些大的比较成熟的工作室可能有专门的团队来支持开发过程中各个阶段的需求，但小团队必须共享资源。
项目组的程序员调动不像建筑工的调动。适应新项目并开始开发肯定是需要时间的。
开发者面临的一个主要问题是高层管理要直接介入开发时可能会牺牲代码质量。这会导致混乱，可能要返工，或是新加一堆功能，并让开发者们非常失望。
作为主程这时就要站出来反对这种胡乱修改。他必须保护开发者们不受这种混乱的干扰，只接受必要的变化并尽可能接近最终的结果。
用越来越多的“不行”回答问题可能会面临强大的冲突甚至是丢掉工作的风险。
这里的关键因素就是责任心。
领导是要为项目的技术决定负责的。如果某个需求是不合理的，领导绝不能妥协。
如果领导反对失败，就会造成双重工作量：一遍是完成不合理的需求，一遍是修复。
这会浪费大量时间并导致开发人员情绪低落。
更糟糕的是，开发者们会开始质疑领导的决策，因为在他们看起来如此不合理的需求也是主程制定的（确实是）。这时领导会失去大家的信任，不利于后续的开发进度，而领导提出的需求大家也不再有激情来回应。
开发团队与其它部门
每个部门都对代码抱有期望。功能需求永无止境。这都是由开发团队的产出来决定的。
游戏开发过程中需求会不断变化，这些需求都会先加进来再变成其它内容。
而代码库绝对会堆积越来越多的代码。
为了与之抗衡，不论何时老系统在添加新功能时如果要经历一些大修，就要勇敢的舍弃它，也就是说必须重做系统。
这会给开发带来很大的阻力，因为一般项目不会预留修复系统的时间。
所以又是领导的责任了，要保证耗时很短即可重做这些代码。
这样做可以带来不少好处。
第一个显而易见的好处就是稳定性。代码变得更加可预测、更解耦也更可靠。
另外，参与整个过程的开发者也会觉得改过后的代码更舒服，面对牵涉进来的新功能做起来也会更轻松。巩固代码的决定也表示项目进入更成熟的阶段，继续编写这部分代码也会更简单更流畅。
要意识到如果是新加入团队的领导没有这样的观念，可能会感受到来自四面八方的阻力。
第一个项目完成后，代码稳定性以及修复或打磨产品的简易程度都会清楚表明之前的努力是值得的，尤其是对于那些之前经历过项目混乱导致各种崩溃和延期的程序员来说。大型工作室的成员对此可能会觉得不可思议，但小型团队可能这才意识到很多人都面临着这样的问题。
结论
主程咋看起来可能是技术优先的职位，但它对于人力资源交流上的要求可能更高。
主程必须有很强的技术背景，但社交技能不强的人也很难胜任这个职位。这种人只会导致最后他自己做了大量的编码工作，因为他不能监管下属更好的工作。这加剧了他与团队成员间的隔阂，也间接造成了成员们与“老板”间的战争，因为代码写得太烂或达不到更好的要求会顶着被开除的压力。
不仅如此，主程还要足够成熟保护成员们不受外部风暴的影响创造一个稳定而丰富的环境，让他们可以更好的完成工作。
