作者：Lee Winder

对于一支优秀的运作和生产团队来说，成功的交流和沟通是最重要的因素之一。如果员工，管理者，发行商以及其他参与游戏开发的人员之间缺少了足够的交流，这个团队的表现就会很成问题了。

如果开发者对自己的工作缺乏自信，不理解自己的工作对于游戏的整体开发有何意义，甚至不知道自己的存在价值在哪，那么这个开发团队只能生产出一些劣质产品，并且团队氛围也将始终笼罩在相互猜疑和摩擦之中。如果沟通不畅，我们很可能要为因此而犯下的错误付出惨痛代价。

以下是我过去几年在团队中试过的改善交流方法：

团队百科

team wiki(from gamasutra)

建立一个团队百科文库去收集信息和内容，这是一种长久存放文件和信息的好办法，但并不适合保存那些短期内容易失效的信息。

如此，团队成员便能很容易地在百科文库中找到开发过程中的各种相关文件，并且如此也不会影响团队的日常工作。虽然成员们仍必须持续去寻找一些长期有效的信息，但并不需要定期搜索新信息。

不过这种方法虽然很有用，但却不能有效地改善团队成员的日常交流。

博客

我们有一个团队博客，每周更新两三次，更新内容是关于日常工作的讨论，游戏截图以及游戏开发现状等。这种方法让我们能够更简单地向团队成员传达信息，但是前提是，所有成员都必须进入博客中才能进行团队交流。

讨论可以呈现每个员工的工作生活，并以此衡量他们的工作，不过这么做并不能用于评估项目成果。

微博

利用内部微博工具如Yammer（商务社交网络和交流平台）或Status.net（开源微博服务）能够快速公开关于自己的工作，遇到的问题或者其它关于团队信息。微博最厉害之处便在于这是一种很好的交流工具，人们可以频繁地更新内容，并接受关注者的反馈评价。

但是直到今天，利用微博去调动团队氛围仍然是我的一大薄弱点。

并不是因为这个方法不好，而是我很难找到一个平台去迎合绝大多数用户，并且我也很难判断哪些信息是用户所不愿意看到的。但如果你找不到更好地筛选有益信息的方法，那么你所公开的内容可能只会被当成没有帮助的垃圾信息，根本不可能帮助改善团队沟通氛围。

展示墙

展示墙真的是一个很有帮助的工具，特别是在统间式办公室里，但人们往往容易忽视这面墙的作用。在工作室里设置一堵显眼的展示墙能够更好地在团队中传递一些重要信息。

例如，我现在所参与的游戏开发团队有一个很明确的时间安排计划，包括发行时间，开发进度，功能特点描述以及目标要求等。除此之外我们还设有一扇“冲刺墙”，这是最能够展示我们工作状况的地方。而这扇墙的位置更是非常重要，但我们却将其设置在巨大的电视，转动电扇以及众多服务器之间，这削弱了它的影响力。尽管如此，我还是认为展示墙的重要性不容忽视，因为我们确实很难找到一个比它更折衷，更容易让人亲近的方法了。

晨会

晨会能够帮助我们更好地在团队中传递信息，但是为了体现出这种会议的真正价值，你必须遵循一些规则。

尽可能地缩小开会人数。我曾经参加过多次有20多人参与的“站立会议”，但是我却发现大多数参会者都面露疲倦或者只是无聊地等着自己的发言。如果开会人数太多，你便很难准确地将所有重要信息传达给全部参会者。

让参会者集中注意力。如果你的会议是让少数人分别阐述15分钟的执行细节，那么其他参加者肯定会迫切希望早点结束会议回到自己的工作中。

不要把会议变成一种汇报过程。如果每个人在会上都是面向着一个人（特别是经理级任务）作汇报，那么请暂时把那位经理请出会议室，而让汇报者面向所有人说话，这样参会者才能更容易地理解他的内容。

重要事记评论

与玩游戏一样，我们总是喜欢讨论哪里做得好，哪里做得不好，或者怎么做才能变得更好。但这种方法若使用不当，很容易变成无足轻重的讨论。

而如果这些讨论缺乏焦点，或者就像是一个普通的时间表，人们也许就不知道如何发表评论，甚至不知道自己到底在做些什么了。你必须确保人们能够轻松地做出评论并应对任何糟糕情况。

但是如果使用得当的话，我们便能够从这些评论中看到需要改进的内容以及一些有价值的信息。除此之外这还能够让评论者看到自己对于开发团队的帮助和贡献，让他们知道自己的想法的重要性。

结语

由管理者制定时间表并交给开发者执行的日子已经一去不复返了。

提前让几个开发人员聚在一起讨论并规划工作能够让团队成员更加清楚自己的工作职责。

并且，如果成员们在如何执行工作，如何分配任务以及安排时间方面拥有发言权，这会对团队内部的信息传播以及开发工作更加有利。（本文为游戏邦/gamerboom.com编译，拒绝任何不保留版权的转载，如需转载请联系：游戏邦）

Opinion: Communication Is Key

by Lee Winder

Successful communication is one of the most important aspects of a well functioning and productive team. Without good communication between peers, managers, publishers, and anyone else involved in the game development process, a team will not perform at it’s best.

If developers do not feel confident in the reasons behind their work, if they don’t fully understand how their work will fit into the project as a whole or indeed when it will be required, the team will produce lower quality work with last minute changes and requirements fostering an atmosphere of distrust and crunch.

But communication is one of the most difficult things to get right but so costly when it’s done wrong.

The following are methods I’ve used over the years to try and improve communication within the team. I’d be very interested to hear other ways people have tried too!

Team Wiki

Having an open Wiki that people can contribute information and notes is a good idea for documentation and persistent information. It is not a good tool for perishable short term information.

Documentation on team processes (getting the latest build, creating submissions, setting up PC’s etc.) is usually the kind of information that finds a home on a wiki, and while it’s useful, it’s not something that affects the team on a daily basis. And as it requires people to physically search for the information in the long term people don’t bother looking for new information on a regular basis.

As a result, the Wiki is useful but doesn’t actually improve the day to day communication on a team.

Blogs

We have a team blog that people update about 2 or 3 times a week, usually discussing their recent work, posting up screenshots or letting people know the state of the project. It’s a nice simple way to push information to the team, though it does require everyone to contribute to the blog to get good cross team communication going.

Discussions can take on a life of their own, which is actually a good way to gauge buy in into a project but can’t be used to judge the success of the process.

But you’d be amazed how many people don’t have any kind of RSS feed reader set up…

Micro-blogging

Internal mico-blogging tools like Yammer or Status.net allow people to quickly thrown up what they’re working on, problems encountered or general team information. The best thing about micro-blogging is it’s push communication style with people’s updates being automatically feed to clients, which people can update as much as they want (I usually recommended at least twice a day).

But so far I’ve had very little success with micro-blogging tools in a team environment.

Not because the idea was bad (when it worked it worked well), but I’ve yet to find a service where the official client is anywhere near usable and able to filter out the information people don’t want to read. Without a good way to filter and push information where you want it (like all the best third party Twitter tools do), it either becomes an information overload or a sea of noise, neither of which improves communication.

Wall Displays

Walls are valuable real estate, especially in an Open Plan office, and I’ve rarely seen them used to their full potential. But highly visible walls in the middle of a team area are one of the best ways to communicate information across a team.

As an example, on my current project we have the entire timeline of the project (it’s only a short one) with dates/deliverables clearly indicated, a ‘where we are right now’ marker and a description – feature by feature – of what is required for a given milestone.

Next to that, we have our sprint wall, which is our most ‘live’ wall display. But position is key, and in our case, the sprint wall’s impact on the team is reduced due to it’s rather awkward position between a big TV, a constantly spinning fan, and quite a lot of server machines. But I did say wall space is valuable real estate, and it’s always hard to find a compromise between distance from team and accessibility.

Morning Meetings

Morning meetings are one of the best ways to push information across a team, but I’ve found that you need to follow a few rules to make them really valuable.

Keep the groups small. I’ve lost count of the number of 20+ people stand-up meetings I’ve seen where the majority of the ‘participants’ are looking bored or simply waiting for their turn. If your groups are not small, the information is less targeted and much less relevant, meaning more information is lost than actually passed around the team.

Keep them focused. There is nothing worse than 1 out of the 6 people speaking for 15 minutes about the most intimate implementation details, leaving everyone else itching to get back to their seats to carry on working.

Don’t make them reporting sessions. If everyone is talking at a single person (usually their manager), take the manager out for a while and get people used to talking to each other as it makes it much more likely for people to take in what is being said.

Milestone Reviews

I love the concept of a milestone review. Everyone playing the game, lively discussions about what went right, what went wrong, and what we can do better next time. But it’s easy for these to be less than stellar if not approached in the right way.

If these reviews are not focused, maybe even as structured as a schedule or points to cover, people may start to feel unsure as to what they can comment on or what exactly they should be doing. You’ve also got to make sure that people feel comfortable both giving and taking criticism and manage the situations when that goes pear shape (and sometimes it will).

I’ve found that when done right, when people contribute to discussions and when people can (importantly) see change as a result of these reviews, the quality of information coming out of them is invaluable. It also has the added bonus of making people feel like they are making a difference to the team and allowing their thoughts to be heard.

Sprint Planning

The days of managers sitting in a room building up a schedule and dishing it out to the developers is (almost) long gone. And there’s good reason for it.

Getting a group of developers (again with the morning meetings it needs to be small and focused) to discuss, schedule and plan the work ahead significantly improves the knowledge people have of what is happening across the team.

Again, if people feel that have a say in how work will be implemented, how it will be assigned and when it’ll be done by is vital to spreading information about the project and the work being done.

So those are a couple of methods I’ve used to try and improve communication and information across the team. I’m sure there are plenty more (and I’ve tried a few which have been colossal failures) so what methods have you used and how well did they work out?（source:gamasutra）