对于游戏研发来说，似乎技术倾向最重的就是代码团队，然而，最近一名来自独立手游工作室BlackRiver Studios的主程序Ariel Madril Tota5在博客中表示，作为游戏研发团队的主程序，虽然强大的技术是必须的，但或许更重要的是与团队之间的沟通和对团队成员的管理，在博文当中，他分享了处理不同情况以及事情之间的方式，对于中小团队的主程序们来说，或许是非常值得参考的，以下是博文的完整内容：
之所以可以写出这篇博客，主要是因为过去一年多的研发，在此期间我整理了此前做游戏研发的所有经验。在游戏团队里，我担任过很多的角色，从初级到高级程序员，我后来成为了《Jake & Tess Finding Monsters Adventure》手游版研发工作室的主程序，所以，接下来我希望分享一些我的经验。
成为一个主程序，通常意味着你需要纯粹的批判性思维和决策，但是，我们往往忽略的是人性化的方面。我们经常会遇到很多特别擅长优化代码的主程，但真正能够了解该如何与周围同事协作的并不多。
所以，这篇文章主要讲述主程职责的2个方面：与引擎工程师互动、专注于指导、冲突解决并保持团队比较高的工作热情；和其他领域的同事互动、与高层交流。
首先要说明的是，所有的人类都是有感情的。不管一个人的专注度有多高，他的决策、互动以及生产活动都或多或少地受到情绪的影响。如果这还不够的话，那么另一个在代码团队中比较常见的问题就是冒名顶替综合征（imposter syndrome），他们的工作、思考过程、解决方案都暴露在同事的眼皮底下，而且需要重复地被审核。作为一个程序员，这会让他们感到与同事们相比的时候不自信。
而作为一名主程序，你的目标是做出一个稳定的产品，及时地对代码进行高度优化和有序的组织。不过，你所处的环境是会经常发生巨大变化的，这就是游戏行业的常态，很多的游戏功能都会改变，游戏项目的研发计划和发布日期通常也会不断变化。
最重要的是领导团队成员而不是代码
主程序可能只是这个职位的头衔而已，但你通常领导的并不是一个项目，而是做这个项目的人，因此有些事情可能是很多注意不到的，比如：不同资历和经验的人在做同样的代码库；不同的团队成员存在不同的编码风格；不同的区域会直接影响接下来的代码；挫败感是经常存在而且容易被低估的因素，会影响团队写代码的动力；每一个超过3名码农团队的项目都会存在编程技术和风格的巨大差异，尤其是在尝试做同一个代码库的时候。
需要知道的是，他们很大可能会遭受冒名顶替综合症的干扰，特别是与其他团队成员对比的时候。
在一个项目的研发过程中，保证团队的工作动力是一项需要长期维护的工作，与此同时，你还需要保证代码质量、稳定性和优化必须是每一个团队成员都做到的，而这个要求往往会导致有些人遭到批评。
对于主程们来说，批评一个程序员的工作或许是最微妙的事情，如果批评得当，普通的程序员可以变得优秀，但如果不得当的话，很容易导致受批评的程序员出现工作效率低下，甚至是离职或者被炒鱿鱼。
由于程序员们经常会把自己的工作和同事们对比，所以在批评他们的时候把他的代码和其他人对比或许是最糟糕的方式。
非常清楚的是，这个程序员的所有努力都应该是被认可的，而且要让他知道，并不会因为代码出现的错误被惩罚。相反的是，要和他们沟通如何达成更好的结果，并不仅仅是因为公司需要这样，而是团队认为他可以做得到。
即便你希望一个人把工作做好，用消极的语调也会让谈话对象的专注点偏移到不好的方面，而不是如何提高他的表现或者技术。
作为领导者，你需要打造一个舒适安全的环境让团队成员可以成长，避免让他们承担过多的压力，即便是代码方面没有提高也不要让他们觉得会因为一次的错误就被炒鱿鱼。
但是，不要误以为我这么说是让你对人过于温和，在项目开始的第一天，你就需要打造一个安全的环境，指导程序员们做出更好的结果必须是项目主程的日常工作之一。
了解你的团队
对每个程序员的强项和弱点都做一个详细的了解，了解他们的编码风格，当问题出现的时候必须要及时和他们沟通。对每个团队成员可能出错的领域进行提前规划，这可以让指导者和被指导者都养成更好的编程习惯，同时确保游戏代码的稳定性和连贯性。
一个主程序不能把指责不好的编码习惯并要求改变作为最后的方法，因为这样做会导致被批评的人所写出来的代码会出现一系列的波动，他可能会自我辩护或者选择不沟通，最可能出现的后果是，他的代码进度会减缓，因为害怕犯新的错误，但是，越是这么做，犯错的概率就会越大。而且，这种情况下还很容易难以发现他的错误，因为由于不自信，他往往不会主动让其他队员看到自己的工作，不希望成为众矢之的。
相反的是，当一个不好的编码习惯出现的时候，一定要尽快指出，告诉程序员错误所在，当然，最好是通过建议的形式，解释其中的原因以及如何用更好的方式来改变。
亲自指导并找出更好的方法可以让他的工作做的更好，然后认可他的努力并且恭喜他找到了新的解决方案。
如果一个问题的出现是此前发生的，而且是新的领导到来之后才发现的，那最好是做技术讨论，而且应该选择午餐谈话的形式，而非把所有人都叫过来开会。
为什么要像个保姆一样？
可能看到这里会有人问，为什么主程序要做这么多保姆照顾婴儿一样的事情？作为一个成熟的人，难道程序员们不应该自己找出这些问题并解决吗？毕竟他们是技术人员，他们有辩证思维而且知道一个好的代码该是什么样的。然而，人类是习惯性动物，很多人养成了不好的习惯却自己没有意识到。
改变习惯是困难的，如果被人对质的时候往往会引起自我辩护并且不愿意做出改变。作为一个主程序，你必须了解人类的这个特性，养成良好的沟通技巧，不要因为这些问题的沟通带来团队成员之间的冲突。
坦率真诚的交流方式可能对于游戏人是有效的，但这种方式很容易引发领导者和开发者之间的相互不满，往往不会让所有人为了更好的工作而彼此开诚布公。
一个领导者往往不需要强调自己的权威或者告诉别人正确的做事方式，做一款游戏并不像钉钉子那么简单。如果人们不够投入，对于做这个游戏不够有动力或者热情的话，他们很可能不会得出具有创意的解决方案，所以，要打造一个热衷于迎接挑战的团队，提高游戏研发水平。
平衡研发团队和上层管理团队
游戏研发是微妙的，你的团队不仅要完成游戏研发， 还必须为其他项目创造工具，确保稳定性和及时性。成熟的大团队可能在每个研发的细分领域都有专门的团队，但中小团队必须资源共享。不同的项目之间调用程序员并不像调动建筑工人那样简单，在一个新的项目上是需要时间适应并且回到研发状态的。
当高层管理人员想要直接干涉研发过程的时候，开发者们面临最大的问题就是代码质量，因为这个要求会带来比较大的变动，有可能需要重做，还可能带来新的功能，给开发者们带来大量的挫败感。
作为主程，你必须反对不顾后果的改变，让你的团队尽可能避免出现因此带来的骚动，只接受必须进行的改变以及有可能完成的调整。这可能会带来比较大的冲突，还会有人担心因此丢掉工作。
但作为一名主程序，最重要的是有责任感。你需要负责项目的技术决策，如果有些是不合理的，那就不能让步。一旦做不到的话，团队所有的工作都需要做两次，一次是进行不合理的改变，另一次就是纠正这个错误。这样的话，整个过程就是一种损失，会给整个团队带来挫败感。
除此之外，开发者们还会开始怀疑领导者做出的所有决策，因为让这么一个没有意义的决策交给他们实施可能被认为是主程的决定（实际上也是的）。这样的话，你们之间的信任会受到损害，未来的协作也会受到影响，你再交给他们什么任务，团队成员的热情就没那么高了。
如何处理研发团队和其他领域的问题
游戏研发的每个领域都需要或多或少的代码支持，功能方面的要求总是无止尽的，但这完全取决于研发团队能够做出多少。在研发过程中，游戏功能的改变是无法避免的，随着不断地进化，这些功能往往会变成完全不同的事物。所以，代码库也会遭受影响，因为废弃代码会越来越多。为了解决这个问题，如果为了加入一个新功能而需要对旧系统进行过多修改的时候，最好是放弃它，也就是说，你需要重做。
这通常都会遭到制作团队的抵制，因为他们没有这么多的时间完成，所以，这还是主程的工作，你需要确保重做所需要的时间是足够的，这样做的好处其实不止一方面。最明显的好处是代码的稳定性，因为代码会变的有可预测性，而且更可靠。
另外，参与这些任务的程序员们对于这部分的代码会更能接受，他们在做新功能的时候压力和紧张感不会过大。加强代码库的决定意味着游戏项目正变得更成熟，这部分代码的编程会变的更容易和灵活。需要知道的是，如果刚加入一个团队的主程不考虑到这些的话，他很容易就可以感受到来自各个方面的抵制。
一旦项目完成之后，代码的稳定性和bug修复以及优化的便捷性会让所有人都看到他们的努力是值得的，特别是此前从事过大项目研发而且每次都在截止日期前出现很多问题的成员们。这对于大团队的开发者们来说，听起来可能有点夸张，但作为手游团队，尤其是人员刚刚开始增长的工作室来说，这是你们都会遇到的问题。
结论
带领一个程序员团队一开始可能看起来是非常技术向的，但是，团队之间的互动甚至会更加重要。主程有强悍的技术背景是必要的，但是，通常做这个职位的人在社交技巧方面的能力比较低，当这种情况发生的时候，那么主程序就需要完成大多数的代码工作，因为他不能直指导其他人做的更好，所以必须亲力亲为。这样做也会让他和团队之间更有隔阂，给每一个程序员都带来人人自危的心理。
不仅如此，主程序还需要足够成熟，保护自己的研发团队不受外界的干扰，确保一个稳定而具有创造性的环境，让每一个程序员都可以做出更好的结果来。
