作者：Samuel Rantaeskola

当人们面对着一些共同责任时，总是不能做出最佳表现——这并不是一次突破的发现。已经存在着许多有关这种现象的案例，最典型的便是，在纽约发生了一起谋杀案时，周围的38名目击者都对这一罪行孰若无睹（游戏邦注：这便是所谓的“旁观者效应”）。也许这个例子太过激进，但是不管怎么说出现这种情况的原因都是相同的：当人们在面对一些共同责任时，总是不能做出最佳表现。

我敢保证在进入游戏制作领域前我便了解这种现象。不幸的是这同样也告知了我另一个事实：人类总是不擅长从别人的错误中吸取教训。我们总是在不断犯错中成长。

而这便引起了我的种种困惑，并推动着我写下这篇文章。

我真心希望通过写下自己所犯的错误能够帮助我进一步明确其中的经验教训。

我还可以回想起自己在意识到问题出现时的情形：当我发现游戏建造遭遇了失败时，我向所有的程序员发送了一封电子邮件，希望他们能够帮助我解决这一问题。但是在几个小时过后却没有人给予我答复，而这时候游戏仍然在崩溃。所以我便主动找到一名程序员，并拜托他检查游戏。他只用了不到1分钟的时间便解决了问题，从而让我们能够继续进行游戏建造。

根据我的经验，游戏产业中的制作人总是未拥有多少好名声。根本原因便在于任务的委托。在我进行深入分析前我想先说说我对于制作人这一角色的看法。我认为制作人在游戏制作中的作用便相当于机器中的石油。他们并不是一个团队的领导者，但是却能填补着开发过程中的种种缺口。就像只有确保石油的供应才能保证机器的正常运转。

如果从责任角度来看，制作人是面向于整个团队（或子团队）进行工作，他们需要不断地寻找缺口，并想办法填补它们，并确保今后不会再出现这些缺口。

而失败的游戏建造让我开始意识到共享责任便这一问题。所以解决方法是什么？我进入制作领域的时间并不长，所以如果没记错的话我并未彻底解决这一问题。从而导致失败的建造问题屡次出现在我的桌面上。如果我是一名真正优秀的制作人，我便会将责任分配给团队中的某个人，从而确保失败的建造问题能够立刻得到解决。

delegating(from businesslearningsolutions)

确保团队顺畅地工作便是优秀制作人的主要任务。除此之外，保证问题不会反复出现也是这一角色工作的重中之重。做到这些并不困难，并且是有价值的，能够帮助他们更好地解决所有问题。不幸的是，制作人总是会不断地堆积问题，并很容易因此出现瓶颈。所以有效地分配任务并继续追踪问题的解决方法便是成功的制作人必须掌握的有效技巧。在这块领域的出色表现能够推动着他们在今后的工作中更有效能。

很少有人能够快速明确问题的所在并进行修复，特别是制定一些长期的解决方法。这时候，有经验的制作人便会将这一责任有效地分配给团队中的某些成员。

大多数人所扮演的制作人角色都是短暂的，因为他们总是会在团队中快速发展而获得提升。很多人都不能忍受制作人工作中的压力，并发现这一职位不能为自己带来多少好处。这便意味着在游戏产业中，任何时刻都存在着许多“绿色”制作人。

对于团队成员来说，失败的任务分配将会导致所有权的不明确。一些精力充沛的制作人便会通过投入自己的更多精力去掩盖这种分配失败的问题，并推动着团队继续向前发展，但是这却不是长远之计。在团队中缺少明确的所有权便会促使成员们产生挫败感，并缓慢地进行发展。而成功的任务分配则会帮助团队更好地承担任务并获得最终成功。

总之，我发现大多数制作人的任务都是在明确一些所有权不明确的范围，确保责任的有效分配以及成员们愿意接受这些责任等。而共享责任并不能成为这些问题的解决方法。

当我第一次意识到这一问题时我已经掉入这一陷阱无数次了，但是现在我已经将其牢牢记在心中了。当我听到一些有关共享责任的内容时，我的内心便会响起警报铃。

不管是在家庭中，工作上还是体育团队内部也都存在着共享责任的现象。但是一般情况下它都是促成糟糕结果并导致人们心情沮丧的根源。使用短期解决方法虽然能够不断指出问题所在，但是却只能扑灭“灌丛之火”。而长期解决方法则能够扑灭“森林大火”并让人们从自己的错误中吸取教训。

经验教训

向许多人分配任务便意味着未能向任何人分配任务。切忌将一个单一领域的共享任务分配给多个人，因为最终将没人愿意去承担这一责任。

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

Delegating to many means delegating to no one

by Samuel Rantaeskola

I think this is first lesson I took down into the document.

This is definitely not a revolutionary discovery in any way — that people don’t behave well in situation with shared responsibility. There are several examples on the subject, the most known is probably this one, about a murder in New York with 38 witnesses but no one stepping in. This actually formed a term called Genovese Syndrome. The analogy might be a bit drastic, but the root cause is the same: People don’t behave well in situations of shared responsibility.

I’m pretty sure I was aware of this phenomena before starting in production. Unfortunately, this also shows another thing that I have known of for quite a while: We are not very good at learning from other people’s mistakes. We learn way better by making the mistakes ourselves.

This causes quite a conundrum for me, given the purpose of this blog.

Hopefully, writing about my own mistakes will at least reaffirm the lessons for me.

I can recall the time when I realized this: The game build was failing, and I sent out a mail to all programmers asking if someone could fix the issue. After a few hours with no response, and a build still broken, I walked over to one of the programmers and asked him to take a look. The issue was fixed in less than a minute, and we had a working build again.

In my experience, the producer role in the game industry has a pretty bad reputation. I think a common failure in delegation could be the root cause for this. Before we dig deeper into this, I need to share my view of the producer role. I see the producer role as the oil the machinery. They are not sitting on top of the team, but rather making sure that the gaps are filled. The machinery must always run without interruptions.

If we look at this from a responsibility perspective, I see the producer as the person that looks at the whole team (or sub-team), finds holes, patches them and hopefully makes sure that they don’t appear again long term.

The failed build sitaution, which made me realize that shared responsibility is an issue, was pretty simplistic. So was the solution. I was pretty new to the producer role, and if I recall things correctly I did not fix the root cause. Failed builds probably ended on my table many more times. Had I been a better producer, I would probably have given out the responsibility area to someone in the team, to make sure that failed builds were adressed immediately.

Having the team working smoothly, without interruptions, should always be the main concern of any good producer. However, keeping problems from reoccuring is also an important part of the role. It is very easy, and rewarding, to be the solution to all problems. Unfortunately, they will stack up pretty rapidly, and the producer will become the bottleneck. Succesfully delegating and following up on solutions to discovered problems is one of the most powerful skills producers can possess. Good performance in that area will keep them efficient for an extended period of time.

Quite a few people can do the identification and quick fix part of the producer role, the long-term solutions are more difficult. Being able to succesfully delegate responsibilities to team members is something that comes with experience.

The producer role is generally a transitory position, where people excelling climb pretty fast in the organization. People that have a hard time with it typically can’t stand the pressure and find something more rewarding to do. This means that at any given moment we have a lot of green producers in the industry.

From a team member perspective, failed delegation of responsilbity will lead to unclear ownership. A highly energetic producer can cover the failure in delegation by commiting a lot of personal energy to continuously keep the team moving, but it doesn’t scale well. The absence of clear ownership in the team will lead to frustration and slow progress. Succesful delegation will help the team take responsibility and excel.

To sum it up, I see the most crucial role of a producer as identifying important areas where ownership is unclear, making sure that they are delegated, and that responsibility is accepted. Shared responsbility will not be the solution to the problem.

Since my first realization of the problem I’ve fell into the trap countless number of times, but I think I know this by heart now. As soon as I hear something that sounds like a shared responsibility, alarm bells goes off in my head.

There are shared responsility sitautions everywhere, at home, at work, in sport teams etc. Typically they are bad and cause frustrution. Applying the short term solution to it would be to constantly point them out, but that would be like putting out brush fires. The long term solution is to let them happen and hope that people learn from their own mistakes.

Lesson learned

Delegating to many means delegating to no one. Don’t delegate a shared responsibility of one single area to several people, most likely no one will take responsibility for it.(source:GAMASUTRA)