游戏邦注：本文作者是Henrik Markarian，他是拥有20年经验的开发元老，曾在Mindscape和NovaLogic任职。Markarian在文中分享其多年积累是开发经验，旨在提高开发效率和企业文化。

我觉得游戏开发的艺术性和科学性各占一半，所以管理游戏项目也是艺术和科学各占一半。显然若其完全由科学主导，那么行业的表现就不尽人意，10年来完全来停滞不前——大家无非就是瞥眼事后分析，看到相同模式周而复始。

游戏需富有趣味和粘性，能够在头2秒吸引用户眼球，然后促进他们持续体验。这些要求使得设计总监和项目经理任务艰巨，他们需要量化“趣味”，然后决定在某些地方植入大量趣味元素，顺利发行游戏。

复杂问题体现在固定预算、短暂期限和应对团队活力。所有这些以及围绕合作型软件工程项目的诸多问题是游戏项目如此以难管理的主要原因。

虽然这没有明确答案，但显然有某些最佳解决方案。文章主要概述我在开发过程中积累的经验，这些经验若应用得当，能够帮助我们有效控制和管理棘手项目任务。

game development team(from becker.edu)

1.保持小规模团队

“我们拥有最幸福的员工，这里的所有成员都对设计有所贡献！”

你听过这个多少次？或者也许你曾在面试表现突出的面试者前说过此话？这是个常见话题，常在面试中讨论。

虽然这理论上听起来不错，但其实际操作问题重重。由小规模核心团队带领的游戏项目是最成功的项目（游戏邦注：就像其他娱乐项目）。这并不意味着团队每次都能够制作出轰动巨作，但能够确保成员具有一致发展目标，反过来能够提高成功机率。

组建优秀小规模团队，赋予他们进行最终决策的权利，同时免受内外各种不同意见的干扰。若你只想从中借鉴1条经验，就是这点。

2.制作简短游戏

在参与过的许多项目中，我都遇到这样的情形：开发团队要负责制作持续几小时的游戏机制。曾经有家在RPG领域颇具威望的发行商要求我们设计一款以太空为背景的动作游戏。我们被要求要制作持续40多小时的内容，而非适合动作类型的目标体验。

简单来说，这是造成灾难的因素。通常为满足这些预期，核心玩法体验都会通过冗长系列事件进行延伸，而这最终只会导致用户离开。类似方式是通过许多不自然的迂回曲折进行扩展，这最终致使玩家与原始情景或主要目标失去联系。

不妨同电影进行比较，鲜有电影工作者会选择超过2小时的电影。显然2小时电影模式有其商业原因，但这带来一个有趣的附属结果：电影工作者知道自己吸引和保持用户注意力的时间有限，那些无法服务最终目标的内容都是多余信息，会伤及整体体验。

让我们从娱乐价值视角切入：游戏价格通常比电影票价高出4-5倍，那么期望从50美元的游戏中获得10多小时娱乐是否合理？游戏和电影不同，但娱乐价值却大同小异。这存在例外情况（游戏邦注：例如MMO游戏），但本质理念却非常一致：瞄准优质简短体验，而非冗长普通体验。深知如何取悦用户的Walt Disney所说的“让用户期待更多内容”其实也是基于这个原理。

3.摆脱“怪人&常人”观念

在我入行的第一份工作中，我们的办公室有两层：所有开发人员都在一层，所有办公部门都在二层（财务、营销和行政等）。其格局分化导致公司出现楼上（西装革履人士）&楼下（怪人）心理界限，这个思维模式挥之不去，影响整个公司的创造性。怪人&常人是个过时观念，行业要发展就得抛弃这个想法。

开发、营销和销售部门的目标有时存在分歧可以理解，但这个属于组织结构上的失误，而非部门成员间存在的固有差异。

销售和营销部门须理解开发团队所面临的挑战，开发部门也要清楚财务和营销部门所面临的行业压力。当3个部门携手共进，项目成功的希望也就大大增加。

那么我们要如何拉近这些部门的关系？从项目初始就让所有部门参与至每周一次或两周一次的状态更新。

确保销售和营销代表直接从开发人员那里获悉项目的核心内容，同时确保开发团队了解项目在竞争激烈环境中所面临的营销和销售挑战。

毫无疑问各个部门在项目中投入的时间各不相同：开发团队可能在项目中投入2年以上时间，而对营销和销售部门来说，这个项目不过是其中之一。

这是出现怪人/常人分化的主要原因，所以公司应花时间培训团队成员，在整个项目进展过程中培养沟通氛围。

这还能够建立信任，让各部门能够更好把握游戏本质和定位，以及项目所面临的挑战。全公司达成的共识无疑是笔宝贵财富。

4.在项目周期中调整项目管理方案

是否采用Scrum（游戏邦注：Scrum是种迭代式增量软件开发过程），这是个问题。或者是吧？Agile & Waterfall已给此方案&彼方案利弊讨论创造众多有趣话题。

在游戏开发中，真正答案是两种方案都适用，因此能够应用用到同个项目中——只是它们需要应用于项目周期的不同阶段。在前制作阶段，需要反复测试各种构思，Agile是最佳管理方式。

但随着项目逐步完成整个制作过程，管理模式就由Agile转变成Waterfall。Agile非常适合快节奏的建模阶段，而waterfall在制作末期则非常重要，在此阶段完成项目是重中之重。

Agile Methodology Chart( from blogspot.com)

5.保持团队协调性

我们如何定义开发团队的“协调”？让我们退一步来看，探究协调对游戏开发团队而言是否是个优点？

我偶然听到有业内人士称适当的不和谐能够促使成员保持敏锐眼光和专注精神。我觉得这是个错误管理出发点。一方面，我们无法控制冲突的程度，更重要的是，我们无法把握这带给团队各成员的影响。

所以虽然初衷是带动团队成员，但结果通常违背创建具有凝聚力团队的长远目标——这样的团队能够不断执行复杂游戏项目。

团队协调是创建成功游戏的必要元素，需要像对待项目期限那样给予充分关注。

所以，让我们回到最初的问题：如何定义团队协调？这不是说团队成员和睦相处，而是说团队成员都专业化，把握成为专业人员的必要条件。

成为专业人员与入行时间长短无关。相反这涉及把握团队结构，团队成员的合适位置，角色的相应职责，以及将团队利益置于个人考虑之前。

项目经理适时检验团队成员，确保他们按预期方式工作非常重要，这关乎团队结构是否能够最大化成功机会（游戏邦注：这与决定手边的游戏好坏不同）。

这很自然地会延伸到根据问题调整人员配置。这是个棘手问题，没有简单解决方案，而我从中学到的一个惨痛教训是不要牺牲长远的团队协调性换取短期制作回报。

6.关键时刻

若你已入行一段时间，定有过熬夜、连续7天工作及各种垂死挣扎的经历。某些业内人士甚至还把这当作一种荣耀——令人联想起《大白鲨》经典场景：鲨鱼捕猎者讨论彼此的疤痕，看看哪个更醒目。

普遍观念是如果你以开发游戏为生，长久工作时间就不可避免。我个人觉得这种评价有损游戏名誉。其贬低游戏开发工作，将其同体验游戏等同起来。制作游戏是个有趣而有益的体验，但并不意味着这很简单或容易。

紧凑工作非常有效率，但只能维持短时间（游戏邦注：2-3天）。若这种爆发式的工作方式过于频繁，其效果就会消失，或者若目标发生偏移，其结果更糟。作为产品经理，行业传统促使你设定关键时刻，但你应反对这种举措，因为无数事实证明紧凑工作弊大于利。

将团队成员视作堵专业人士，创造工作生活始终保持平衡的环境。团队成员会觉得非常舒心，工作更有效率，最重要的是会继续留下来参与下个项目。

最后是针对团队成员的简单问题：你觉得他们的工作是系列流水任务或者是左右脑并用的创造性工作？我觉得通过后者我们可以得出如下结论，缩紧时间无法推进项目发展。（本文为游戏邦/gamerboom.com编译，如需转载请联系：游戏邦）

Lessons from the Trenches

by Henrik Markarian

[Henrik Markarian, a veteran developer with over 20 years in the industry, including stints at Mindscape and NovaLogic, shares production secrets he's learned over the years -- best practices aimed at improving efficiency and studio culture.]

I believe that making a game is part art and part science, so it’s no wonder that managing a game project is also part art and part science. Clearly if it was all science then the industry would get a collective F for not having made any significant progress over the last decade – all one has to do is just glance at the published postmortems to see that the same patterns are repeated over and over.

A game has to be fun, engaging, grab users in the first two minutes and also keep their attention for countless more hours. These requirements place a very difficult burden onto design directors and project managers who are tasked with quantifying “fun” and then determining that at some point in the project enough fun elements have been introduced into the game so that it can actually ship.

Complicating matters are fixed budgets, tight timelines and dealing with team dynamics. All of this combined with the well-documented issues surrounding collaborative software engineering are the chief reasons why game projects are so difficult to manage.

While there are no clear-cut answers, there are obviously best practices. The goal of this article is to outline numerous lessons learned from the trenches of game development that when applied properly should help control and manage a process that by nature doesn’t want to be controlled or managed.

Limit the Chefs in the Kitchen

“We have the happiest employees around because EVERYONE here contributes to the design!”

How many times have you heard this? Or perhaps you were the one saying it, when trying to hire a promising candidate? It’s a common theme, and one that is often discussed during interviews.

While this sounds great in theory, in reality its execution is fraught with problems. Game projects (much like other entertainment properties) are most successful when guided by a small and focused group. This doesn’t mean that the group will make a hit every time out, but it does ensure a cohesive vision for the game that in turn increases the likelihood of success.

Put together the best small team possible and empower them to make the final design decisions, while avoiding the temptation of introducing multiple points of design direction from inside or outside. If you take only one lesson away from this article — this should be the one!

Make a Short Game

On numerous projects I’ve come across situations where the development team is saddled with delivering a gameplay experience that must last an inordinate number of hours. In one particular example, a publisher with a solid hold within the RPG realm tasked our team with designing a space-based action game. There was pressure in delivering a game that provided 40-plus hours rather than concentrating on a targeted experience befitting the action genre.

Put simply, this was a recipe for disaster. Most often, in order to meet these types of expectations the core gameplay experience is stretched through such a lengthy sequence that the impact is lost on the player. Similarly the story is stretched through so many unnatural twists and turns that at the end the player has little connection to the original premise or the main goal.

If we compare this with movies, rarely would a filmmaker opt for a movie that’s over two hours long. Clearly there are business reasons behind the two hour movie format (number of showings in theaters, etc.) but there is a wonderful byproduct: filmmakers know that they have a limited amount of time to grasp and maintain the attention of the consumers and that anything in the movie that is not driving towards the ultimate goal is extraneous and possibly harmful to the overall experience.

Let’s view this from an entertainment-value perspective: Games generally cost four to five times the cost of a movie ticket, so is it fair to expect more than 10 hours of entertainment from a $50 game? Games are different from movies, but the entertainment value aspect is not that different. There are exceptions (e.g. MMOs), but the overall lesson is solid: aim for a great short experience, rather than a lengthy mediocre experience. Walt Disney, a man who knew a thing or two about entertaining audiences, had the right idea when he said “Always leave ‘em wanting more.”

Get Beyond “Suits vs. Geeks”

In my first job in the industry, our office was on two floors: the entire development staff was on the first floor and all other departments (accounting, marketing, executive, etc.) were on the second floor. The physical office layout alone led to a downstairs (geeks) vs. upstairs (suits) mentality that was difficult to overcome and counterproductive to the entire company. Geeks vs. Suits is an antiquated notion that the industry has to leave behind in order to grow.

It’s understandable that the goals of the development, marketing, and sales departments are not always properly aligned, but that’s a failure in the organizational structure rather than a stereotypical difference in the individuals within those departments.

While it’s imperative that sales and marketing understand the challenges faced by the development team, it’s equally important for the development team to understand the financial and marketing challenges in the industry. Chances of a project being successful are greatly increased when these three departments work in concert.

So how can we bring these entities closer? Involve all departments (development, sales, marketing, etc.) in weekly or bi-weekly status updates from the start of the project.
Make sure the sales and marketing representatives understand the prime essence of the game directly from the folks that are making the game, but also make sure the development team understands the difficulties in marketing and selling into an ultra competitive landscape.

It goes without saying that the amount of time spent by different departments on a singular project is never going to be equal: the development team will likely spend two or more years on the project while for marketing and sales the project is one among many.

This fact is generally the primary cause for the geek / suit balkanization, so take time to educate the team and foster good communication throughout the life of the project.
This will build trust and enable each department to get a far better grasp on the overall essence and positioning of the game and the challenges facing the project on the whole. That company-wide understanding will be an incredibly valuable asset.

Alter Project Management Approach through the Life of a Project

To Scrum or not to Scrum, that is the question. Or is it? Agile versus Waterfall has provided for numerous entertaining discussions about the virtues and merits of one approach versus the other approach.

The real answer for game development is that both methodologies are applicable and therefore should be used on the same project — they just need to be used at different times in the project lifespan. In pre-production, where numerous ideas are tried and re-tried there is no solution to the management approach other than Agile.

However, as a project moves into full production the management dial has to slowly turn from agile to Waterfall. Whereas Agile is well-suited for the rapid prototyping phase, waterfall is equally important to the end phase of the production cycle where completing the project is of paramount importance.

Team Harmony

How exactly do we define “harmony” for a development team? For that matter, let’s take a step back and ask if harmony is even a good thing to have within a game development team.

I’ve occasionally heard the argument from people in the industry that a little bit of discomfort is desired in order to keep everyone sharp and focused. From my perspective that’s a completely flawed management position. For one thing, it’s difficult to dial a certain level of discomfort, and more critically, it’s impossible to fully realize the impact of that discomfort on the different personalities within the team.

So while the intent may simply be to push the team on the current project, the results are often counter to the long-term goal of establishing a cohesive team — one that’s capable of executing complex game projects on an ongoing basis.

Team harmony is an essential component of making a successful game, and should be managed with the same intensity as, for example, the milestone deliveries.
So, let’s get back to the initial question of how to define harmony in a team. It’s not about everyone on the team getting along, it’s actually about everyone on the team being a professional — and understanding what it entails to be a professional.

Being a professional has nothing to do with the number of years one has spent in the industry. Instead it has everything to do with understanding the structure of the team, where individuals fit within that team, what is expected of their role and putting the good of the team ahead of any personal agendas.

It’s critical for project managers to continually review the makeup of their team to ensure that they are performing as expected — this is different from determining whether the game at hand is good or bad — it’s about whether the team is structured in such a way to maximize success.

A natural extension of this discussion is contemplating adjustments to the personnel upon identifying problems. This is a thorny issue and there are no simple answers, but a hard learned lesson from my perspective is to not sacrifice long-term team harmony for short-term production returns.

Crunch Time

If you’ve worked for any appreciable length of time in the game industry then you’re sure to have some tales of late nights, seven-day work weeks and endless death marches. Some in the industry even wear it as a badge of honor — swapping stories reminiscent of the famous scene in Jaws when the shark hunters discuss their scars to see who has the most impressive one.

There is a popular notion that if you make games for a living, then the long hours just come with the territory. I personally find this type of assessment to be insulting to the craft. It trivializes the work by equating game development with playing games. Making games can be a fun and rewarding experience, but that doesn’t mean that it’s simple or easy.

Crunching can be effective, but only in short (two to three days) targeted bursts. The effect is quickly lost if the bursts are too frequent, or in the absolute worse case if the target is moving! As a project manager, the history of the industry will sway you towards imposing crunch time, but you should fight against that as it’s been shown time and time again that crunching does more harm than good.

Treat your team as professionals and create a setting that provides a consistent work-life balance. The team members will appreciate it, work more efficiently, and most importantly stay onboard for the next (and the next) project.

Ultimately it’s a simple question for your team: do you consider their work to be an assembly line series of tasks or a creative endeavor requiring a healthy combination of left- and right-brain utilization? I believe it’s the latter which leads me to conclude that crunching does little to advance the creative push of a project.（Source：gamasutra）