作者：Samuel Rantaeskola

尽管我一直坚持将自己从错误中所吸取的经验教训记录下来，但却总因为没有时间去实践它们而感到非常郁闷。

游戏工作室的制作人总是非常重视最终结果。甚至有时候，过程对他们来说一点意义都没有，或者他们不会挪出任何时间去思考相关过程。也就是在追求短期成就与长期完善间，他们更倾向于前者。

producer dilemma（from gamasutra）

并且每次当制作人试图去面对这些过程时，残忍的截止期限总会活生生地吞噬了他们的这一想法。你之前的成功实践不一定适用于新的情境，所以你便不得不使用基本的蛮力解决方法。当提交了一款游戏后你将重新回到起点上，并再次重建这一过程。

如果你们的工作室需要发行商提供相关资金，你便会非常依赖于每一次阶段性付款。因为这是制作人需要优先考虑的条件，所以如果他们能够实现长期的过程完善，定能够提交更加出色的游戏。

基于这一点，那些来自小型或中型工作室的制作人便需要同时对结果与过程负责，因为在他们团队中没人能够承担起缺少过程完善的责任。

关于这一问题的解决方法其实非常简单，制作人只需要雇佣一些人去明确任何决定过程是否得以落实，以及任何完善行动是否得以实现便可。在敏捷软件开发中，SCRUM（游戏邦注：一种迭代式增量软件开发过程）项目经理便是非常重要的角色。

根据我的经验，激烈的竞争和资源短缺总是让我们很难去雇佣一名过程所有者。当你需要在聪明的程序员（能够让游戏变得更加出色）和一个无所事事之人中间做出选择，你通常都会选择程序员吧。原因非常简单，程序员总是能够快速创造出有形的结果。而过程拥有者既不能创造出任何结果，更不可能创造出有形的结果。

让我们假设在一个拥有50个人的小组中进行人员选择。通过简单的数学运算我们将清楚，如果每个团队成员的智力增加了2%，那么这种雇佣的效能就相当于雇佣了一名程序员。如果你能够提高2%的团队效能，这便算是一种成功的招聘。如果你能真正理解游戏开发过程，那么提高2%的效能便不是什么难事。

而如果存在SCRUM项目经理这一角色，那么其他人便无需为结果或质量负责了。他们只需要确保团队所设定的规则得到落实，并指导子团队的SCRUM项目经理去执行完善行动便可。

任何组织，敏捷软件开发以及部分敏捷软件开发过程等都能因这一角色而受益。只要你清楚自己的工作方式，你便能够让别人监视你是否遵循了这些规则，并找到任何可行的完善方法。

因为频繁遭遇结果挤兑完善过程的窘境，我认为自己需要暂时摆脱制作人的角色。我需要在其它空间里对自己所犯的错误做出反思，同时想办法找出解决方法。

经验教训

盲目地追求短期利益只会让你离完善的结果越来越远。制作人必须努力找到结果与完善之间的平衡点。

（本文为游戏邦/gamerboom.com编译，拒绝任何不保留版权的转载，如需转载请联系：游戏邦）

The producer dilemma

by Samuel Rantaeskola

Even though I was diligently taking down lessons learnt from mistakes into my little document I constantly felt a huge frustration that I never had time to act upon them.

As a producer at a game studio you are extremely focused on results. Often to the point that the process of getting to them is irrelevant, or at least you have too little time to think about it. The balance between short term wins versus long term improvement is often heavily skewed to the former.

Every attempt at fixing the process typically gets butchered when you approach that tough deadline. The good practices you have been building up does not work in this situation and you have to retort to basic brute force solutions. When the delivery is completed you are back at square one and have to start rebuilding the process again.

Working at a studio with publisher financed productions you are typically very dependent of every milestone payment. Since this has the highest priority, a successful delivery will always be more important that a long term improvement of the process.

To add to this, a producer at a small to medium size studio is typically responsible for both result and process with no one holding him/her accountable for lack of process improvement.

The solution to this should be quite simple, hire someone who’s main responsibility is to own and make sure that the decided process is followed and that improvements are implemented (not found, that is everyone’s responsibility). In agile terms a SCRUM master for the whole organization.

In my experience the cut throat competition and shortage of resources in most game productions makes it really hard to justify the hire of the process owner. When your choice is between adding that brilliant programmer that will make the game look so much better and that boring process guy it will almost always be the programmer. I believe the reason for this is quite simple, a programmer will start producing tangible results (results again) rapidly. A process owner would not produce results rapidly nor will they be very tangible.

But let’s assume that we make that hire in a team with about 50 people. Simple math says that if each team member works 2% smarter the hire is equal to the programmer hire. If you can beat 2% improvement of team efficiency (I hate that word as it has a lot of negative connotations, suggestions for better words to describe this are appreciated) it is a better hire. Naively I believe that improving 2% is quite easy if you have a good understanding for how game development works.

For the organization SCRUM master role to function correctly that person should have no responsibility for results nor quality. He or she should only make sure that the rule set decided by the team are followed and coach the sub team SCRUM masters to find and help facilitate improvement implementations.

Any organization, agile, semi-agile or something else would benefit from this role. As long as you can define the way you work it is reasonable to have someone that makes sure that you follow those rules and also finds ways to improve.

Because of the dilemma that results always wins over improvement I felt that I needed to leave the production role. I needed some space so that I could reflect upon the mistakes I’ve done and hopefully come up with solutions to some of them. Hansoft provided with me with an excellent opportunity to do this with the added benefit that I can hopefully help others to avoid my mistakes (though they are OK).

Lesson learned

The constant hunt for short term gains will prevent you from improving. It’s important to find the balance between results and improvements.(source:gamasutra)