於是我天真地參加了Cambridge Startup Weekend希望能夠接觸到一些投資者。結果我遇到比我想象中更多的投資者。於是我便創建了一家初創公司giftgaming。
TechCrunch Startup BattlefieldAfter的Nick Hatter參與了劍橋賈吉商學院的Accelerate Cambridge課程，在這裏我學到了如何籌集資金，如何宣傳，如何提防法律問題，如何聘請員工（與解僱員工），所有的這些都是開始一項新業務所必要的元素。
Playfish倫敦工作室總監Jeferson Valadares及其團隊肩負沉重使命。他們的任務是：理清社交遊戲的未來發展方向。在Valadares看來，這意味着他們需在遊戲中融入更多社交情 感和故事元素。Valadares表示，“第一代遊戲主要關乎競爭和排行榜元素，我們正在觀察這類遊戲的未來發展態勢及要如何充分利用Facebook有 所變化的用戶體驗。”Valadares在某次採訪中談及如何將團隊視作企業單位進行管理，分析社交遊戲領域的下步發展，及要如何在全球範圍內經營公司文化。
作者：Marcelo Spiezzi Raimbault
很多情況都有可能導致團隊的失敗。可能是個人的原因也有可能是組織的原因。理解爲什麼一支團隊會遭遇失敗比了解如何促成團隊的成功更加重要。交流不順可能會破壞團隊工作：《Dark Side of Teams》便是一篇總結了可能導致團隊失敗的不同問題的優秀論文。而在本文中我將討論這一論文中所提到的2大問題，即發生於學生所開發的項目《Cult》的開發過程中，並且這些問題也很有可能出現在任何遊戲開發團隊裏。
篇目1，How to not fail in scale
by Samuel Rantaeskola
As game teams are growing in scale there are some severe pains in coordinating these efforts. As an industry, we are quite capable and efficient at moving small scale projects from concept to a finished product. When the team sizes eclipse the century mark, many more obstacles and hindrances both seen and unseen begin to rear their ugly head. The general lack of production experience of running projects at this larger scale is handicapping us as an industry at large.
I am not claiming that the solution I’m proposing here is rocket science in anyway, but rather these are the common pain points I see and hear continuously within the games industry.
1. Unify what to do and how to do it
In a small team, continually communicating the vision of the project with each member is a battletested way to keep everyone inspired, motivated and on the same page. However, solely relying on that method when working in the hundreds and adding to that having a game design document that nobody reads, is a sure path to failure. A tight connection between the game design and production plan is one way on how you can approach breaking down the game from a high level vision into actual work. In this video, I talk about a method for achieving that: http://vimeo.com/51747636
Connecting what and how will only take you half way there. The overarching method of getting to the end goal should be basic enough to be easily explained and understood by the entire team. Within that method, the teams should be able to select the best working formula for them moving forward whilst still feeding in to the whole project.
2. Decide on a structure
In the early phases of production, you should think of how to structure your entire project. How are you going to troubleshoot it when it’s being built? Bear in mind that it needs to scale appropriately as you will add teams to it. It is also a good idea to iron out workflows early on, instead of defining them on-demand. This process will help you plan how to track progress as you are getting into production mode.
3. Subdivide the problem
For most in our industry this is given, but there are a lot of teams out there that are looking at the project as one gargantuan jig-saw puzzle. They spend a lot of effort trying to optimize resources and dependencies to the smallest detail and in that jungle of information it is impossible to make good decisions. The challenge is to create sub problems that are as independent as possible from each other.
4. Build teams around the problems
Everyone seems familiar with the concept of cross functional teams in theory, but in practice evolving to a cross functional organization is extremely arduous. Historically, it has much to do with the outdated culture in the games industry, where the tradition has been to sit with peers in silence. A cross-functional organization scales nicely, and adding a team does not increase the complexity as much as in a departmentalized organization. Resolving dependencies is within the teams and the management overhead can remain fairly sparse.
5. Decentralize decision making
Accept that you will lose control. A top down driven management style and structure “works” in small environments, but is extremely slow and error prone in large scale development ecosystems. You will quickly realize that this strategy is fraught with hazards and will need to be corrected, if not eliminated outright. Large scale development teams have a lot to learn from the casual game studios’ “shotgun approach”, in so far as, the concept of having independent teams which are the decision makers within their domain. In this kind of environment, there are no external bottlenecks which slow down the teams’ progress. Naturally, casual games lend themselves well to this style. However, with an early sub division of the problem and delegation of ownership, it can work in more complex games as well.
6. A team is the smallest unit
Don’t go on a duck hunt to optimize the hours. Trust your teams to make good calls within their area. Every now and then one of the guys in a team will be short on project specific tasks, because he’s waiting for the other guys in the team to finalize the level. Trust me; he can probably think of a million things that he could do that will add value to the game. After all you’re probably hiring talent.
篇目2，From Indie Dev to CEO: 10 Indie Pitfalls
by Nick Hatter
Before I founded giftgaming, I was just like you; I loved games. I loved them so much I started developing them. First in DarkBASIC, at the age of 13 years old. By 18, I was building Tetris in Java. By 21, I was using Unity. And by 23, Marmalade. Somehow, my life kept going back to game development.
In the last 10 years I’ve developed a number of games, everything from Casual to FPS. After finishing my BSc in Computer Science, I started a big J-RPG project codenamed “Pilgrim”, which took a lot of inspiration from Final Fantasy VIII (cliche inspiration; superb game). It was coming on great, with a fully fledged camera, battle, inventory and saving system.
There was just one big problem: I didn’t have the funds to pay myself to do it full-time or to pay artists.
So I naively went to Cambridge Startup Weekend to “make investor contacts”. But instead, I got much, much more than I bargained for. I gave birth to a startup: giftgaming. I became The Pilgrim.
Nick Hatter on TechCrunch Startup BattlefieldAfter being accepted on to the Accelerate Cambridge programme at Cambridge Judge Business School, I was taught everything from how to raise funds, how to pitch, legal issues to watch out for, how to hire (and fire) — all the staples needed for a new business.
The next thing I know, I’m getting press coverage from publications like TechCrunch and Management Today. Then I appear in WIRED Magazine. Everything moves so fast. It’s crazy. Only last week my startup was named as one of 10 Companies From Cambridge To Watch In 2015. I’m also pitching for ￡300,000 in 2 weeks time. I forget I’ve only been doing this for just over a year…
(Image above of me from TechCrunch’s Startup Battlefield)
It has been a “baptism of fire” as one of my mentors says. But in this one year, I have learnt a lot. About business. People. Myself. Life. Going from an indie developer to a CEO requires a “quantum leap”.
Before embarking on the journey to becoming an indie game studio/company, take heed of the following…
Top 10 Pitfalls to Avoid (IMHO):
0. Thinking it has to be perfect
I’ve made over 7 complete games. How many did I actually publish though? Just one (Thundrclap). Because I was too afraid of making the others imperfect. Ship something. Anything. And ask yourself, is that feature really necessary? Will users actually notice? You’d be very surprised.
1. Evenly splitting equity in the founding team
No no no! We are not all equal. Unfortunately. What tends to happen is that people bring different value to team in experience, time commitment, skill and so forth. One good way to assign equity is to use “Distributive Justice”, ie. to slice the pie is to take into account all of the aforementioned metrics, weight them, then have the team grade each other on points out of 10 on each area. Then divide each members points by the points of the entire group. This gives you the equity split for each team member.
2. Letting founders walk off with equity
It’s a very good idea to have each founder sign a Shareholder Agreement with a “Vesting Schedule”. The vesting schedule basically says “if you leave before x years, you only get to keep y% of your shares”. Ideally, you would let founders “vest” (keep) around 25% of their shares for each complete year of service. So if a founder leaves before a year, then potentially they leave with nothing. Sound harsh? It’s not. It’s fair. I have seen other startups been screwed over by cofounders leaving with huge chunks of equity, forcing them to close down. Investors will not like founders leaving with big chunks either. You can get a tailored Shareholder Agreement for a very reasonable price from Lawbite who provide an online legal service for small to medium enterprises.
3. No formal Intellectual Property (IP) ownership
If anyone does any work for your game, you must make sure it’s clear who actually owns what. Even if you pay them, they still own it. An IP Transfer Agreement allows you to formally assign “moral” (ownership) rights over. As always though, seek legal advice.
4. Too much time on competitions
Competitions can be great PR. But they can also take a lot of time, and also cause you to lose focus. I get confused whenever I see entrepreneurs who already have startups going to startup weekends to come up with another startup idea. Makes no sense to me. That’s almost like being married and going to a speed dating event. The same can go for gamejams. Yes, they’re fun. But you will get distracted. So, if you’re working on a game, especially in a team, stick to that game. It’s your significant other and you wouldn’t want to cheat on it. If you don’t keep focus, you may end up with a lot of unplayed and unpublished games like me.
5. Not sleeping or exercising enough
“Creative people suffer the worst” as one of my mentors tells me on the subject of sleep deprivation. You must get enough sleep and exercise. Both have been proven to improve well-being and thinking. When you’re in the right psychological state of mind ie. relaxed, that’s the prime time for creativity. It is very hard to be creative when you’re a sleep-deprived zombie. Trust me. I have been there.
6. Not pursuing your passion
Sounds obvious, doesn’t it? But I see it happen. Some people only care about the bottom financial line, rather than enjoying their job. Again, the same goes for your game development. Build games that you want to build, that are your true passion, even if they’re not a money-making clone game. Statistically, the chance of your game being successful is low (as is any startup), so you might as well enjoy it at least. And if it is your passion, you’re more likely to keep going even when times get tough, and you’re more likely to work harder than ever before to make it succeed. Success doesn’t have to be financial by the way — it is how you define it, whether that is critical acclaim, having a niche fanbase, your own game brand and so forth.
7. Thinking you can do everything
As a CEO, I’m guilty of this one. But unfortunately, no matter how multi-talented you are, there will always be things that you’re simply not an expert at. And you can’t be an expert at everything. It actually makes more sense to find people who are experts, tell them what you need them to do, then step back so they can do their job. There are simply do not have enough hours in the day, especially if you’re a part-time indie developer. Get a team. You need one. Yes, there are a few successful solos, but your odds of being successful as a team and not burning out is much higher. Plus a team is more fun. Do you want to be all alone every night behind a screen? Or would you rather be working on your awesome game with your friends and having a good time?
In addition, a team is absolutely essential for raising funds. Hardly any investors will invest in individuals (there are exceptions to every rule though…)
8. Thinking the live demo will work
I remember going to show my mentor an early prototype of giftgaming. In the 30 minute meeting I had with her, I spent all of the time trying to get it to work. What I should have done is recorded a video of gameplay, and taken some screenshots. “Huh, it was working last night” — A phrase I’ve heard many times. Use screenshots or video in presentations. If you absoultely have to do a live demo, have screenshot backups ready. Technology and multimedia will usually fail you when you most need it.
9. Listening to naysayers
Someone said to me when I first started giftgaming that it would never work. In their words, “why the hell would a brand and a game publisher ever come to you when they can do a direct deal?” The answer is time. It takes a lot of time to close a big deal with a brand direct. Brands and game publishers (certainly smaller ones) do not have the time to manage all these relationships, not to mention finding the appropriate brands to put in their game. That’s something giftgaming does. And don’t underestimate how long it takes to build a robust ad platform.
We now have over 15 major brands onboard and we have started receiving self-service signups from game studios worldwide. What if I had listened to that guy? What if I hadn’t done my research? My life may have stayed the same. Naysayers are dangerous, and are an enemy to innovation. Be careful listening to them if you have a new concept for your game. That one new concept could change everything.
10. Not taking constructive feedback onboard
Also known as “My baby is not ugly!” Contradicting my last point, it is also important to spot when someone is giving you helpful feedback. Listen to early feedback for your game. Perhaps the mechanic needs a bit of rethinking. Maybe the controls or gameplay aren’t as intuitive as you thought. Good or bad, take all constructive feedback onboard. Learn from it. It is painful to have to listen to criticism sometimes, but it’s more painful when your game or product is shunned because you didn’t listen.
So, that’s actually 11 pitfalls. And unfortunately, there are more. Many more. But if you can dodge these ones, I think you can be successful in any venture, not just indie games.
And maybe, just maybe, my baby might enable you to make enough money so you don’t have to look for early-stage funding (without dirtying your game up with more intrusive ad solutions). It’s best to get a team and prototype well-developed with some customers before you try to raise funds, or you end up giving too much of the business away.
篇目3，Using independent teams to scale a small company: A look at how games company Wooga works
By Jesper Richter-Reichhelm
Jesper Richter-Reichhelm is Head of Engineering at social games company Wooga. Here he gives an insight into the firm’s internal organization.
At the end of last year, a document was published that described how Spotify works using a decentralized approach of tribes and squads. Since then, the article stuck with me. It made me realize we were not alone in this approach of fostering independent teams and with this article I want to contribute to the discussion and challenge a few conceptions.
I also want to explain that it is possible to have a truly agile work environment based on small, autonomous teams. It’s no small feat though, it takes effort everyday to keep this structure working smoothly. The following is a work in progress summary of how keeping teams independent can help scale a company, using my experience at Wooga as an example.
Wooga – now and then
Wooga was founded 2009 with a vision that by 2020, everyone will be playing games. Four years ago we had around 20 employees and now there are more than 250 employees from 40 nations all working in our Berlin office.
While that employee growth is a byproduct of economic success, in the process of growing it was a big challenge to not lose the company culture we had built. In the early days everyone in the company worked closely together and were not slowed down having to wait for approvals. Normally as a company grows this changes as management layers are added, and work simply becomes less efficient.
How did we hold onto that culture? The answer: centering everything around independent game teams. We had doubts about this approach, but we believed it would be worth the effort to at least try.
Wooga is a collection of many small, independent teams. Each team is responsible for making and running a single game and is expected to make their own decisions while being cross-functional and autonomous. They should freely share learnings and don’t compete with each other, meaning they effectively act like small, independent start-ups within a larger framework.
It’s completely up to them if they want to listen or ignore outside advice – even if it’s from one of the founders. This is only possible by having great people. So hiring the right people is the single most important thing we do at Wooga. We believe in the mantra, “If in doubt, don’t hire.” That works very well.
Teams are at the heart of how Wooga is organized. 70% of employees are working in a game team. There are departmental heads, such as the Head of Engineering of which we have two who take care of different parts of that field, and others that look after their respective departments.
The rest are providing central services like marketing, customer care and localization (20%) or others like HR, PR, Finance, Business Analytics and teams that maintain simple services for persistence of games. “Service” is the key word here – those teams serve the game teams and not the other way around. For example there are no artificial budget processes and game teams can decide release dates themselves.
Each game team is led by a product lead that has the final decision for the team. This ensures a fast decision is always possible and the company can scale without top management becoming a bottleneck. In essence this is a delegation of power from central management to the teams. This starts with the type of game a product lead wants to make and ends with the way the teams organize themselves internally.
Teams start small with 1-3 people, with the first always being the future lead and providing the initial concept of the game. They develop a prototype that can be reviewed and most importantly, play tested. If it’s not good enough, the team starts afresh. If it looks promising, the team is ramped up slowly, keeping it below 10 people for as long as possible.
After going live the team size can remain stable or be increased. Further feature development does not slow down the development process but as extra information is derived from live metrics, a/b testing becomes possible and the whole game needs to be operated.
An important point is that even though teams are independent and compare KPIs, they do not compete with each other. There is a constant exchange of knowledge and lessons learned between them. This is how we leverage the innovations made by individual teams (and compensate risks individual teams take).
On one level this is done by each team being asked to provide a 5-10 minute weekly meeting where they report their progress to the rest of the company and explain their learnings, which could be from something like previous a/b tests or new feature announcements. There are no limits or off areas regarding which information can be shared as long as others can benefit from the information.
Also, these meeting are open for every employee to attend. This way we can try out new things in one game, and when they work, that knowledge is spread to other teams. This works quite organically.
Another level of knowledge exchange is between members of the same discipline. We organize monthly internal lightning talk rounds called “5 minutes of fame” where anyone in the company can give a short talk regarding something they want to share and everyone can attend these talks. It’s a good way to spread knowledge and start discussion throughout the company and increase networking. We have specialized meetups for backend development, frontend development, game design, business analytics and art.
Whenever a topic is too complex to handle it in a lightning talk we do brown bag talks. This is a lunchtime talk where participants get a free lunch after the 25-minute talk. Half of the company usually attends these talks of which we have about one per month.
The brown bags are held in our auditorium area where our weekly company meeting takes place every Monday morning. It’s a 15-minute meeting where new hires get a warm welcome, company strategy is presented and announcements like game releases are made. It’s an important start to the week, and helps to keep everyone in the company connected and informed.
Since teams are cross-functional there is a wide range of skills to utilize and good teams organize themselves with members working closely together. Again the idea is not to have a single person knowing and deciding everything, but making it the responsibility of every team member to push the game forward.
Teams themselves are autonomous and do not depend on other teams to create and run their game. As a result teams do their own analytics while using a shared service provided by the Business Analytics service team and a few standardized KPIs. Similarly there is no operation/admin team to operate the servers or other parts of infrastructure. Those who write the software operate it themselves. Engineers are not forced to share or reuse code, so there is no central framework that everyone must use.
Instead, private and public repositories emerge on github when engineers want to reuse code, but they also have the option to start from scratch. This is a conscious trade-off: we sometimes reinvent the wheel and repeat mistakes, but the company as a whole is much more flexible and innovative. Existing teams are not slowed down when new teams start and the overall communication overhead remains small.
Those who have heard the theory behind Dunbar’s number will know that group coherence will start to dissolve when it grows beyond 150 members. At Wooga we rely heavily on team members proactively reaching out to other game teams to learn from their experiences and be aware of what those other teams have learned in the past. To assist communication we grouped together teams into studios. This is a work in progress strategy but so far it looks good.
We think agile development is not about applying a specific methodology, it is about following the correct principles and to constantly reflect on whether you are aligned correctly and to correct things when necessary.
As a result there is no unified process on how teams should develop their software. Teams decide on their own how to do things, although they usually blend in elements of Scrum and/or Kanban. That means stand-ups in the morning are the standard, although variations do exist.
There are some constraints though:
Teams work in weekly iterations and present progress and learnings in weekly meetings to the rest of the company.
Small prototyping teams need to get a green light to develop a full game. A lot of prototypes do not pass this stage which allows us to play test many new game ideas in a short time. “Failure” at this stage is part of the process. Lessons learned from cancelled games are shared within the company.
All source code is available to everyone in the company.
All KPIs and metrics are available to everyone in the company.
We expect people to think and decide on their own using common sense. We try to avoid formalizing processes as the resulting rule book wouldn’t be flexible enough. There are some common principles to guide individual decisions and sometimes reminders are necessary but overall it works well.
I joined Wooga when we were just 10 employees in 2009. Over time the founders attitude to work lead to an organic evolution of the company based on everyone being responsible for their own work, their own team and ultimately their own company. Being independent and working autonomously are the common threads in every approach we take at Wooga.
This had lead to a culture where taking ownership is emphasized and expected. People are trusted to make the right decisions and they do make the right decisions most of the time. Of course sometimes people do make mistakes but since they don’t try to hide them it’s actually quite easy to fix things.
篇目4，Playfish’s Jeferson Valadares on teams as business units, social game evolution and managing the company’s culture
by Vlad Micu
Playfish London’s studio director Jeferson Valadares and his team have a big task ahead of them. Their mission: figure out what’s next for social games. For Valadares, that means bringing out more social emotions and narrative in games. “The first generation was about competition and leaderboards, but the second generation is more about self-expression,” says Valadares. “We’re still waiting to see what is going to be next and how to make use of the changing user experience on Facebook.” We sat down with him to talk about teams as business units, the next step in social game evolution and managing a company’s culture worldwide.
Little big teams
“We spend a lot of time experimenting on our live games,” says Valadares. “Every week, there’s always something new in a game. The benefit of having a lot of games and big audience is that you can try these things out in different games and see what works.” With each team at Playfish managing their game as a small business unit, this process allows them to easily find out which new features work well. The individual teams then take the successful features and appropriate them into their own game.
“There are teams that are starting new games now, and these are the teams that are trying different types of game concepts,” says Valadares. One of those new teams at Valadares’ studio has started to take a more collaborative approach to playing social games. According to Valadares, the goal was to figure out how this could minimize the amount of friends playing a social game, but increase the social relationship between them. “Instead of doing something with ten people you are just colleagues with, why don’t you do something with three people you’re friends with,” explains Valadares.
Quality > quantity
With an increasing amount of game companies focusing on social games, the social game space has experienced exponential growth in the past couple of years.
Valadares sees the positive side of this growth, not only encouraging his own colleagues to experiment more, but also hoping to see more of that around him.
“When the space gets this big, there is space for people to do some unique things which might not be for everyone,” he argues. “But there are enough people who are interested in that to be successful.”
Aside from experimentation, Valadares is also noticing a rise in projects that involve cooperative game modes. Whether or not that could translate into social games is still not clear. “It could be,” says Valadares. “I’m not sure whether that’s going to happen in the short-term though, just because the more high-end you get, the more computing you need. Unless we move to things like OnLive, where you don’t need a strong computer when those things take off, then we’ll see social high-end as well.”
“Sometimes we look at board games,” admits Valadares. “The value of having good writing, a good story. It’s something that is really compelling to people in general.” There are lots of things Valadares would like to see in the social space. “A really great story-based game, because a story is something that is very strong for humans, always has been, and I suspect always will be. So how can we weave that in with the social experience more strongly? There have been a few shallow attempts.”
Undergoing substantial growth, Valadares’ studio in London is very much struggling to keep their corporate culture in place. “We’ve been growing a lot, there are maybe three people who have left in the last year or so,” says Valadares. “I think that’s pretty good. We’re still hiring a lot. I think the company is four times bigger then when I joined, which was a little over a year ago.”
Because of that growth, Valadares has been constantly asking himself “how we can celebrate success and not forget the reason we do things.” With new offices starting in different areas of the world, a lot of Playfish people are moving around trying to maintain that same culture everywhere. “In London, everybody kind of sees what’s happening, but it’s harder to keep the other studios connected,” admits Valadares. “We’re still trying to grow while maintaining the creative spirit that we had in the beginning.”
But baring in mind the particular cultures of the regions each Playfish office is located in, some of those cultural variations should also be encouraged. “In China, the guys in the office like their particular games,” explains Valadares. “In the past, we tried to make them do Western games, but what we actually realized is that they’re better doing what they understand. That’s exactly why we have an office in the US, Europe and Asia.”
篇目5，Two simple factors that can compromise team productivity
by Marcelo Spiezzi Raimbault
The greatest challenge in game development is not learning new technologies, building the best tool or even finding the fun. The true challenge and nightmare of many developers is how to build and maintain a productive team. By a simple logical perspective, creating games is nothing more than following a series of steps in a correct order. However, games are made by people and not by machines (luckily!), and that’s when things can start to go really bad.
Many situations can lead to a team failing. It can go from the individual level to the organization he belongs. Understanding why a team fails can be much more important than knowing what makes a team succeeds. Communication that Damages Teamwork: Dark Side of Teams is a good paper that summarizes different problems that may lead a team to fail. In this blog post, I’ll talk about two big problems mentioned on the paper that happened during the development of Cult, a student project developed at The Guildhall at SMU, and that are likely to happen in any game development team.
I thought that was right… Ambiguous goals are probably the most critical problem for any project. During development, it is easy to get lost in ideas, processes, details, and forget about what really needs to be done. It is important that all team members clearly see and fully understand the goals for that particular sprint/milestone. When goals are unclear, people are likely to spend their time in unnecessary tasks or even waste time doing the tasks incorrectly.
Unfortunately, this problem may goes unnoticed. First, leads usually have a clearer idea of the project and may assume that the rest of the team also has this same comprehension. Second, team leads can focus only on their tasks and forget to give the proper attention and set clear goals for other tasks.
One important insight for team leaders is that not providing clear goals to all team members can even affect their perception of trust. Team members may think that tasks are not clear/available because the lead does not trust them enough for specific tasks. And a team without trust is a low productivity team.
Without clearly defined goals, there is no way for a team to be autonomous, and only a team with enough autonomy can develop its own path and achieve high levels of productivity.
The feeling of urgency
Deadlines! Although a word that can make any developer cry, deadlines are essential for a team tobe productive. We know that a game is never finished. Games can always be improved and that is exactly why deadlines need to exist.
It is easy to find a successfully backed Kickstarter project or an independent game that failed for not having enough money to finish the project. Usually, undefined development time is the main reason behind these failures. People mainly act based on a feeling of urgency. If there is not enough reason to do something for tomorrow, people probably won’t do it today. We may believe that we are not like everyone else, and that we do all our tasks as soon as possible. However, that is not how things happen in a team project, even more in a creative environment as game development. If there is no feeling of urgency, the project won’t move as fast as it could and may not reach the functionalities needed when the time comes.
Creating short time deliverables is a good way to keep the feeling of urgency always high in the team (Agile development and Scrum really comes in handy here!). Always keep in mind that an essential feature not finished now, is a feature that needs to be finished later.
Deadlines problems also build on top of ambiguous goals. Clear and precise goals are essential for a project to be timed right. It is pointless to have many short time deliverables if their goals are not clear and the team cannot tell when they were achieved or not.
First, understand your problems!
As a last word, there will always be a new “top 10 tips for a successful team”, but the reasons of why a team may fail will never change. The best way to increase a team productivity is to address and remove the issues decreasing it.
篇目6，Creating an Iterative Culture
by Seth Sivak
The following blog post, unless otherwise noted, was written by a member of Gamasutra’s community.
The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.
This is cross-posted from the Proletariat Blog
The best games come from iteration, but how can we build that into our process and culture? This is something we have worked hard to create at Proletariat and we push every day to foster this culture. Here are three important steps to creating a culture of iteration within your own team:
1. Constantly review
Goal: Everyone on the team helps each other create the best work possible in a constructive manner.
The first step in creating an iterative culture is for team members to constantly review their work with the rest of the team. While uncomfortable at first, especially when work is in-progress, it’s critical to establishing feedback loops within the team. At Proletariat, we formally do this on Fridays in our weekly review meetings (which we stream live on Twitch) and informally with smaller groups.
Action Item: Create review steps in the process where people from all different disciplines can give feedback on ideas. Start these formally and then allow them to develop organically.
2. Nothing is ever “done”
Goal: Stay flexible with features so that team members can return to past work and polish it while the game evolves.
The constant review process will get the team comfortable showing work that isn’t complete. The next step is to make it clear that nothing is ever “done”. There’s always room for improvement or polish, whether it is art, design, or code. As the game continues to evolve and features are completed, multiple passes may be required. The idea that it’s not done means that the team can move on knowing they’ll have a chance to return to features later and iterate on them. This only works if the team trusts the producers and the schedule.
At Proletariat, we build lists into our backlog that contain issues the team wants to re-address. At the end of every milestone, we try to leave a week to work on the backlog, which we call a “debt” week. Team members can work on their own, prioritizing the parts of their work they feel need the most attention.
Action Item: Build lists in the backlog with pieces that require polish. Provide frequent breaks during the development process to let the team dig into the backlog.
3. Give it away
Goal: Allow for open and honest feedback and ideas to encourage the team to not hold on to a single personal idea.
It is common to see developers struggle to let go of “their” idea, hurting the process. Instead of focusing on letting an idea go, put the focus on giving the idea away so the rest of the team can build from it.
Everyone on the team is expected to throw ideas into the pile and what comes out is the result of the process. Each member of the team must understand that the moment an idea is spoken aloud to the group it is no longer their idea. This is the same for any art, music, sound, or code. I like to think about this as not letting go of your ideas but instead giving them away to the team. Members are expected to contribute their creative talents and that is a great gift to the final product.
Action Item: Be critical of ideas but not their sources. Develop a process that can objectively analyze options in game context.
Creating a culture of iteration takes time and focus from the entire team. Priorities need to be shifted and changes to the process can certainly take a toll on development. However, once this culture is established, it can enable the team to push each other to create their best work in a positive, collaborative environment.
篇目7，7 Production Guidelines
by Samuel Rantaeskola
Previously I wrote a post about the common mistakes of a producer, which you can find here: Top 6 production mistakes. As with raising children, it is easier to say what not to do than to describe the opposite. Nevertheless, just writing about the mistakes is not helpful unless you take a stab at describing the proper thing to do. So here we go.
We have all heard stories about the hero producers that carried whole productions on their shoulders. The stories include components of great personal sacrifice and extreme commitment. What is often left out is what happened afterwards, a hero that had to recover a year from the stress syndromes and a team in chaos because the engine was not available anymore. This person might be the best solution to get something out the door immediately, but I doubt he is the best to build teams that function in the long run.
Producing is mainly leadership, not project management, and how to lead people differs from person to person. Leaders that are comfortable on stage might execute a lot of their leadership in front of the team, while the ones that prefer intimate environments might want to work more with one-on-ones. The type of leadership required is also highly dependent of the situation. But given that most game studios consists of quite a lot of young people, this article in Forbes about how young people want to be led is a good read if you are an aspiring producer.
Unfortunately there is not a single recipe for successful producing, any advice I can share on this topic has to be focused on how to think rather than exact advice on what to do. Anyone taking on that role of producer will have to find the best solutions for the people and situation they are in. That brings me to the first point of the list.
1. Adapt to the situation
As mentioned earlier there is no generic advice that works in every situation. This means that producers need to be very flexible and good readers of situations. They need to have a wide range of tools that they can adapt to the problem at hand. I know that this is a very hard advice to take in, but this mindset is required to be successful.
2. Be a great listener
A producer’s job is to find the wisdom in the team and make sure that is used. They cannot do that by constantly broadcasting their own message and ignoring the voice of the others. Therefore I am a firm believer that being a great listener is one of the most important traits of a leader. Apart from missing the opportunity to gaining valuable information, the talkative producer ignores the fact that people need to feel listened to in order to accept leadership. The following article explains this in more detail: Leadership & The Power of Listening.
For extroverts, like me, this is a tough advice to apply as speaking is part of our thinking process.
3. Trust people
The feeling of not being trusted will bring down the morale of any person and will also make them less likely to take responsibility for their work. Producer must do their best to show that they trust the judgment of each and every one on the team. Even in instances where they have their internal doubts. This also means that there needs to be tolerance for mistakes as they are part of the growing process. The producer should strive towards helping team members to learn from their mistakes over throwing rants.
4. Be a great teacher
The producer’s ultimate goal is to build a system that works without him, essentially making him redundant. When the team encounters problems that they are struggling with it is often tempting for the producer to take them on personally and ensure they are solved quickly. The great producer will focus his effort on aiding the team on learning from the problem so that they grow. Next time a similar situation comes up the team will be able to get through it without the assistance of the producer.
5. Seek long term solutions
Short term thinking will never get anyone out of a hole for more than a short period. The producer must continuously assess situations and look for long term solutions when problems occur. If he is too engaged in solving the problem it is easy to forget to fix the problem long term. The producer must rely on the team to solve it and spend his energy on devising a plan in collaboration with the team on how to prevent it from reoccurring. This was a big problem for me personally when I was acting as producer, as my itchy fingers really wanted to be in on the fixing.
6. Be goal driven
Everything producers do should be goal driven, as opposed to task driven. When they spend their time detailing the path to the goals and breaking that down to tasks they are usually overlooking the fact that the team is way more capable of this. The challenge lies in describing the goals and helping the team understand why it needs to be done. This brings me to the most important point of this. Producer must remember to explain why to the team. For example, if a new way of working is rolled out in the team it is as important to explain the goals of it as how it works. Without that explanation the buy in for the process will probably be low, as the team members might not see the value. On top of that the producer is missing out on the possible improvements that can come from the team if they are bought into the goal.
7. Obey the rules
This almost goes without saying; producers are part of the team, which means that they should play by the same rules as the rest. If the agreed start time is 10 AM, then the producer better be there. If the team works late for a deadline, the producer better be there. Leaders cannot expect more of the team than from themselves.
Most of the advice I have given in this post is focused on how a producer should interact with the team. These are my views on how they should think in order to build a long term successful team. However, situations differ and I do not think you can follow these guidelines all the time. Producers will often have to diverge from them and get their hands dirty in pressing situations. But they should strive towards making these situations the exception rather than the rule.