Wie arbeitet man erfolgreich zusammen? Eine Frage, die sowohl Entwickler als auch deren Auftraggeber immer wieder umtreibt. Vor allem dann, wenn es um die Erforschung von Brustkrebs geht, um einen spielerischen Ansatz, um das Crowdsourcing der Datenanalyse und das mobil. Ein solches Projekt hat die Cancer Research UK angestoßen und ausgeschrieben.
Das Ergebnis “Play to Cure: Genes in Space” (iTunes) (Android) ist ein voller Erfolg, über den u.a. bei “wired” berichtet wurde.
Alex, einer der Gründer von “Guerilla Tea“, die dafür verantwortlich zeichnen, gibt ein paar Einblicke in die Zusammenarbeit mit der Cancer Research UK an diesem ambitionierten Projekt.
Guerilla Tactics – Handling Unfamiliar Terrain – How to deal with Clients
So, let’s talk about clients. I know a lot of indie game devs frown at the very thought of working for hire. And let’s be honest here, if we could just do our own stuff without ever having to worry about how we pay next month’s rent or get food on the table, most of us wouldn’t even bother talking to someone outside the industry. But the reality is, we’re still running a business and we need to make money. And unless we’re producing the next Flappy Bird or whatever magical timesink is currenly floating on top of the app store charts, we need to have an eye on our revenue stream.
Now, I’m no expert, but we’ve been around for about 2.5 years now and worked with a whole bunch of different clients from a variety of industries. The most notable ones were DC Thomson and of course Cancer Research UK, with whom we developed the hugely successfull Play to Cure: Genes in Space – the world’s first mobile game that actively helps with finding a cure for cancer (seriously, how epic is that?!). But all of that still doesn’t make us the ultimate authority in the field of B2B relations, so don’t take everything I’m writing here as gospel. It’s just how we do things at Guerilla Tea because we found they work for us, and our clients.
Now, with that said, let’s get to the question. How do we deal with clients that don’t have a games background but want to develop a game? (Note: most of this is applicable to pretty much any client regardless)
1. Know the territory!
This is probably the most important part when working with a new client. Do your homework! It’s a bit like a job application; the better you know who and what you’re dealing with, the easier the whole process will be and the less friction will occur once you actually start working on the project.
The first thing we did when putting together the pitch for Genes in Space was researching the other companies involved, their experience, past projects and so on. For example, we knew CRUK had already sucessfully launched a serious game on the web called Cell Slider together with Zooniverse (of Galaxy Zoo fame), so we knew they had some experience working with external developers and had people with the technical background to understand the implications of running a backend system for several hundred thousand users. This was great for us since it allowed us to be more technical and therefore precise when writing the pitch. If your client doesn’t have a technical background, it takes a lot more effort to explain what and why you’re doing things, so be careful and make sure you adjust your language appropriately (and *never* try to hide knowledge gaps behind tech lingo)!
Maybe even more important than researching your client is doing the research for the project itself. What is it? Why do they want it? What and who’s problem does it solve? How? For Genes in Space, this involved me digging through every academic research paper on BAF Data, detection of Copy Number Variations and related subjects that I could get my hands on. I didn’t become a Geneticist overnight, but at least I got a good enough understanding to be confident about the project requirements. As a side note here, don’t be afraid of researching subjects that you don’t have previous experience in. My knowledge on genetics before that was basically 7th grade biology and watching Jurassic Park, but by constant cross referencing and a lot of help from Wikipedia I still managed to get a decent enough understanding of the subject. You don’t need to know everything about it – that’s your client’s job – you just want to know enough to communicate effectively and make sure you understand what it is you’re supposed to be doing.
At the end of the day, this will keep both you and your client happy because you will have a lot less misunderstandings that cost time and money to resolve. The more you know about your client and the subject, the easier it is for both parties to find and realise a common vision!
2. Control communication!
Keeping clients in the loop is important. Keeping clients that don’t know about games development in the loop is a lot more important. Look at it from their perspective: they just shelled out a lot of money to a company they never worked with to build a product they don’t fully understand. Of course they are nervous, so the better you keep them informed about the project, the happier they will be.
We acomplish this in multiple ways. The first one is to have regular conferences with the client (usually weekly). If possible do face to face meetings, but if the distance is too large, Skype and Google hangouts are two viable options we use regularly for that purpose. The more often you communicate directly, the easier it will be for both of you to spot problems and address them before the project veers off track.
You also want to give your clients at least some access to your internal scheduling tools. Trello and Asana are really good for that, but if your tool of choice doesn’t support this behaviour, an up to date spreadsheet on Google docs will do the job as well (you should still get a better tool though, because yours is obviously crap). This will reduce unnecessary communication overheads because everyone involved knows what you’re currently working on and when a certain feature is supposed to be implemented.
Finally, having an iterative development methodology works incredibly well with that. This way your client always has the latest stable version of the game for testing, and necessary changes can be fit into the schedule with very little friction. You don’t have to use any of the heavily formalized methodologies like SCRUM for that. We’re using our own homebrew mixture of agile and waterfall which gives us enough stability in terms of cost and time projections, but still allows us to act and react very flexible on changing requirements. Anything that gives your client enough input into the development process should work.
In addition to keeping up client communication, make sure you don’t forget to talk to the most important group of people: your target audience. Most of the time this will be your players, but it doesn’t have to be that way. For Genes in Space, our main audience were not the people who played the game but the researchers that had to use the analysed data. We therefore made sure to run any changes we made to the data analysis by them first to verify that it was still accurate enough. We also sent them regular samples of the data to see if we needed to improve anything. That’s not to say that we didn’t do regular playtesting sessions as well to make sure the game was fun and accessible, but those were not our main priority
3. Hold your ground!
The last lesson we leant when dealing with clients was probably the most difficult one, but it’s absolutely crucial if you don’t want your project to turn into a nightmare of Lovecraftian proportions: you need to learn to say no. I know this is hard. It requires being somewhat confrontational and it can be incredibly scary because that clients money could be the only thing keeping your company from going belly up. But if you think that a client not getting the feature they wanted is bad news, wait till you see what happens when the deadline slips for the 3rd time because the project is choking from feature creep, you’re nine months late and your code has more bugs than a roadside motel bed because all those nifty little features were glued together by spit and good hopes, without any proper planning whatsoever. That is when you should be scared.
Now, I’m not saying you should just tell your client to bugger off when they have an idea for a new feature. But if it doesn’t fit into the schedule or would be too costly to implement or is just a generally bad idea, you’ve got to deal with that. Explain the situation. Look for compromises. Maybe you can get that new feature in if you remove another one that is less valuable. Maybe you can come up with something that is less costly but emulates almost the same functionality. In the worst case, tell them that you will have to adjust the schedule and costing of the project if they really want the feature in. Whatever you do, just don’t simply say “yes” because the client asked for it; that’s the express lift to developer hell. Stay focused on your goals. Keeping the project on time and on budget is infinitely more valuable for everyone involved in the end than a little disappointment every now and again.
Also, don’t just watch out for the client. Your team members are just as prone to come up with potentially damaging features. However, they are usually easier to deal with since they have a better understanding of the development process. When we were building Genes in Space, Charlie (our designer) had a lot of ideas that I’m sure would have made the game a lot more exciting to play. Making a game fun is his job after all. However, we needed to shoot a lot of them down because they would have meddled with the accuracy of the data analysis. For these cases, I recommend having one team member as a dedicated “guardian”. The job of the guardian is to make sure that whatever is proposed does not interfere with the main goal of the application; a bit like a vision keeper, but with a much narrower focus. Take the person with the best understanding of the project’s goals and give him the authority to veto every new feature if it violates these goals.
Now, as I said at the beginning, this is just the way we do things. It took us a while to get there, but for now it works pretty well – for us and our clients! However, we’re still prone to making mistakes at one point or the other, so if you use a different process that might help us or have a good idea that might improve the ones we have, we’re looking forward to hear about them. Maybe in a year or so I’ll write an update for this post to see what we’ve learnt in the meantime.
Alex out.