作者：Lee Winder

当我们一开始进入一个团队时并不会产生太多消极情绪，但是当我们努力去发展一个团队并开始鼓舞团队士气和斗志时，这种消极情绪便会一点一点渗透出来。以下内容并非对于世界各地开发团队的深度研究，而是我在过去10几年来通过管理和观察各种团队所获得的经验教训。

当我们着眼于一个团队的构成时，它总是会包含一些能够有效完成游戏创作的人以及某些会糟蹋了整体游戏的人。任何一个项目开发总是会汇聚一些个体，然后询问他们是否愿意为了达到一个共同目标而暂时一起工作。而这些不同个体所具有的不同个性有可能会促就一款成功的游戏，也有可能会彻底毁掉一款游戏。

很明确的一个现实便是，比起使用各种有效的方式去完善团队，任何个体总是能够更加轻松地摧毁一个团队。也就是消极性总是能够以燎原之火般的速度在团队中迅速蔓延，而积极性却如糖浆一般难以扩散。

negative(from robertfagan.com)

这是为什么？

工作中的个体总是更容易产生消极态度。消极做事，大谈团队的坏话甚至是破坏游戏的行为总比创造更多优秀的内容，对自己的工作负责，走出一个定义清晰的角色或完成任何有意义的工作简单得多。

消极开发者的定义是什么？

开发者将会以多种不同的方式带给一个团队消极影响。最明显的便是他们对于当前项目所持有的态度，如无端的抱怨，莫名地推脱工作要求或在上班时间偷懒等。

他们可能在开发过程中未能呈现出更多技能，或影响了开发产品的质量。

有时候这些开发者的态度并不能体现出团队所追求的精神。也许你要求开发者对自己的工作（游戏邦注：包括设计与执行）承担更大的责任，但是某些开发者却只会执行上头所交付的相关工作。

可能开发者并未参加日常会议，或者只是含糊地陈述了一些观点，并明显透露出对别人工作的毫不关心。

不管怎样，我们能够很容易明确开发者的消极态度对于一个团队的影响。这也是我们在开发过程中最难处理的一块领域。

团队开发

让我们通过一定的情景进行分析，绿色代表“积极”开发者，红色则代表“消极”开发者。

在第一种情景中，两位开发者将并肩工作，一名开发者表现良好，而另外一名则没有多大成效。也许其中一名开发者是抱着消极的态度，也许他只是不想争取更好的结果。不管出于何种原因，他对团队所做出的贡献始终都不如积极开发者。

developers(from gamasutra)

大部分情况下，这种情景只会促成一种结果。积极开发者在看到搭档总是逃避工作并且未投入足够的努力后，他便也会慢慢产生怠倦心理，并逐渐变成消极开发者。

通常情况下消极开发者并不会因为看到积极开发者的辛勤工作而转变自己的态度。所以最终你便只会同时拥有两名消极开发者。

developers(from gamasutra)

什么情况下态势才会发生改变？什么时候消极开发者才会认清事实并开始努力发展游戏？我想这些答案都不会有多大的激励效果。

以下是另一种情景：

developers(from gamasutra)

这是一种较为平衡的情景，但是同时开发者也更容易忽视产品的质量而不是想办法去完善它，即他们很容易走上错误的发展方向。

developers(from gamasutra)

基于各种观察，你最终获得好结果的比例为3:1，但是这仍是一种具有风险的方法，因为当积极开发者开始出现态度转变时，这一比例将重新回到之前的1:1。

developers(from gamasutra)

如果你所拥有的积极开发者和消极开发者的比例为4+:1，你便需要努力确保其他开发者不会出现态度动摇的情况。在很多情况下，消极开发者并不能凭借自己的力量做出改变，其他开发者也不会因为比自己更优秀的开发者所带来的同侪压力而发生改变。

developers(from gamasutra)

积极开发者

但是不管是面对何种情景，我都不敢保证积极开发者始终都能够带给团队积极影响。优秀的开发者并不能轻易放松，他必须更加努力地工作，不断创造出更优秀的内容，并带着更大的雄心而发展。

让我们再看看以下的情景：

developers(from gamasutra)

这些开发者之所以优秀都是有原因的，要么具有较高的个人自豪感，要么具有较强的野心，或者是纯粹地享受着工作带给自己的乐趣。而如果优秀的开发者长期待在一个满是消极开发者的空间，那么最终结果也是可想而知了。

developers(from gamasutra)

如果积极开发者处在一个充满了消极开发者的工作环境中，或者积极开发者很难在此感受到真正的推动力量，他们的态度便会很容易出现动摇。而一旦你失去了更多的积极开发者，你便会发现有越来越多开发者意识到自己不再有积极工作的必要了。

解决问题

面对团队中的消极开发者主要有两种方法。第一种方法较为强硬，但是如果你身处的区域具有健全的劳动法，你便不适合使用这一方法。

即辞退这些开发者。

developers(from gamasutra)

老实说我并不推荐这种方法。因为这么做虽然能够解决问题，但是却会在团队中留下一些漏洞，你之所以会雇佣这些开发者肯定是出于某种原因，那么你何不尝试着去找回他们身上的这些亮点？

而组织内部的执行管理结构（如果使用得当的话）不仅能够解决这一问题，同时还能帮助消极开发者重新正视游戏并努力成为团队中的佼佼者。

明确问题的来源。是因为开发者不喜欢游戏还是他们在工作以外的时间遇到了某些困难，是因为他们不认可上司的工作分配还是他们根本不想待在这一团队中？

基于这些回答，你才能采取更合适的应对方法。。

明确目标。设定那些能够扭转局面的目标，不要只是设定好便不再搭理。每周或每两周去审查目标的的落实情况，设定一些短期目标与长期目标形成互补。

设定一个明确的截止时间。不要因为一些微小改进而不断拖延时间，只有明确的截止期限才能让你更加重视自己的工作。

明确最终结果。不管他们是否有机会去尝试其它工作或者只能终止合约，你都必须让团队成员清楚在完成目标或错失目标时会出现何种结果。

保持稳定的记录。记录下每次会议的内容，并且每天去记录所有目标的发展过程或最终结果。

辞退他们。尽管这么做较为残忍，但是如果你所采取的任何方法都没有成效，你便别无选择了。如果你一直在尝试着解决这一问题但是开发者却对此无动于衷，你便只能采取这一方法了。

在健全的劳动法律条款下，如果你所遵循的是绩效管理策略，你便可以在改造开发者无效的前提下与之解除合约。

消极开发者的消极性是基于他们对于团队目标的影响，以及对于其他开发者所带来负面影响。消极态度的蔓延速度总是会大大超出你的想象，并且将会导致你的团队中的其他人拉低了自己的真实能力标准，或最终选择离开团队。

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

Opinion: Negative developers and team stability

By Lee Winder

It doesn’t take much for negative feelings to start to seep into a team but it takes a lot more to turn a team around and start to raise morale and motivation. The following isn’t based on an in-depth study of development teams across the world but on my own personal experience of managing and observing a number of teams over the last 10 years.

Take of that what you will…

When you look at the make-up of a team, it will always be staffed by people who raise the game and by some who only bring it down. It’s the nature of taking a group of individual people and asking them to work together for a period of time towards a common goal. It’s the individuality of these people who can take a project and make it fly or cause it to crash and burn.

One thing that’s clear is that it’s much easier for a single individual to bring a team down than it is for an individual to improve the team in any significant way. Negativity will spread like wild-fire through a team whilst positivity acts more like treacle and can be much harder to spread around.

But why?

A negative attitude to work is a whole lot easier. Doing less, talking badly about the team, or rubbishing the game is much easier than creating excellent content, taking responsibility for your work or stepping outside your defined role and doing something great.

What defines a negative developer?

There are many ways in which a developer might have a negative effect on a team. The most obvious is through their general attitude to their current project, be that general low-level complaining, pushing back against work requests for no good reason, or general slacking off during the day.

It could be a lack of skill development or even a backsliding in the quality of the work they are producing.

But it could also be an attitude that doesn’t gel with the general ethos the team is aiming for. Maybe you want your developers to take more responsibility for their work and how it’s designed and implemented, and one or two developers will only work when they are told exactly what they need to do.

Maybe it’s a developer who doesn’t get involved with the daily meetings, mumbling through and obviously not interested in what other people are doing.

At the end of the day, identifying a developer generating a negative effect on a team is usually pretty easy. They’re the ones who are difficult to deal with in usually many aspects of the development process…

Team development

Lets have a look at a few situations where a green developer is a ‘positive’ developer, red a ‘negative’ one.

In the first situation, we have two developers working side-by-side, one working well and another not doing so great. Maybe one of them has a bad attitude, maybe they don’t want to really push what they are doing. Either way, their contribution to the team is much less than that of the positive developer.

In most cases, this will go only one way. The good developer, seeing their partner being allowed to get away with not working so hard and not having to put in as much effort, will eventually start to slow down and equalize with the poorer developer.

It’s much less likely that the poorer developer who is getting away with poor work or a bad attitude will see the better developer and decide to put in that extra work. As a result, you now have two bad developers rather than one.

When does it go the other way? When does the poor developer look around and start to raise their game? The answer isn’t very encouraging.

Take the following situation:

Theres a tight balance here, but since it’s much easier for a developer to reduce the quality of their work rather than improve it, it’s easier to slide the wrong way, and at that point it’s very easy to see where this will go.

Based on a number of observations, it seems at though while a 3:1 ratio might get you some good results, it still brings risks because should one developer start to slip, it then becomes 1:1, which puts us right back at the start.

In most cases you can only really guarantee that other people will not slip if you have a 4+:1 ratio between positive and negative developers. In a number of cases, the negative developer didn’t change their attitude without help, but other developers didn’t slip due to the peer pressure of the other better developers.

Positive developers

But in all these situations, I’m not giving these positive developers enough credit. A good developer won’t always slack, they’ll continue working hard, producing great content and generally continue to fly high.

But take the following situation…

These developers are good for a reason, be that personal pride, ambition, or sheer enjoyment of the work they are doing. And if a good developer finds themselves in the minority for a long period of time, the outcome is inevitable.

Great developers won’t stick around if those around them are not working to their potential or failing to create an environment in which the better developers feel themselves being pushed. And once your great developers leave, you have a much higher chance of those left realizing they don’t need to actually work that hard to get through the day.

Solving the problem

There are two ways to deal with poor developers on a team. The first is the most drastic, but initially not an option if you’re working in a region with sane labor laws.

Just drop them.

To be honest, I wouldn’t recommend this anyway. Simply letting someone go generally removes the problem, but it can leave a lot of holes on the team, and you hired this person for a reason, why not try and get that spark back?

Performance Management structures (you do have a Performance Management process don’t you?) within an organization can, if done correctly, not only resolve the problem but allow the poor developer to raise their game and become a star on the team.

Identify the source of the problem. Does the developer just not like the game, are they having a difficult time outside of work, do they disagree with how work is being allocated, or do they just not want to be there?

Depending on what their answers are, you’ll have a good idea of where to go next.

Make sure goals are set. Define goals designed to turn the situation around, but don’t just set and forget about them (which happens far to often). Monitor them on a weekly or bi-weekly basis, setting very short-term goals to complement the longer term ones.

Define a fixed period of time. Don’t just let things drag on with only small improvements here or there, have a deadline at which point things will get more serious.

Make it clear what the end results will be. Whether they are the chance to work on something different or whether it’s a termination of the contract, make it clear so everyone knows what will happen when the goals are reached or missed.

Keep constant records. Make sure every meeting is documented and the progress or results of all the goals are recorded daily.

Let them go. While it is drastic, if improvements are not being made given all the opportunities you’ve given them, then there really is no other option. If you’ve bent over backwards to try and solve the problem and the developer hasn’t taken you up on the offer, then there really is nowhere else to go.

And even with those sane labor laws, the documentation you’ve been keeping over the Performance Management period mean you can release the developer from their contract knowing you tried your best and they didn’t want the help.

So negative developers, whatever is defined as negative based on the goals of your team, are almost guaranteed to have a bad effect on a group developers. Negative attitudes to work and development can spread much faster than you might think and will either cause people on your team to normalize at a level far below where they need to be or will simply leave.

It’s vital that as a group these developers are tackled fast, rather than when their effects start to be felt.(source:GAMASUTRA)