How to handle a "Team" for your project

Started by Yitcomics, Sat 08/04/2017 06:03:23

Previous topic - Next topic

Yitcomics

For the first time ever I've just posted a thread on the recruitment section. I'm not sure whether it's gonna get any response,
but after 4 years in freaking development, I think I might need some help. But the things is, I'm kinda of a lone wolf, I've
never handled a "Team" before.

So I'm not sure what is expected from me, what I'm trying to say is, are there any advice you give to me as the Project leader.
Such as keeping the morale of a "Team", communication, do and don't, etc.

Danvzare

I'm a bit of a lone wolf too. But I've noticed a few things I prefer from helping other people with their projects: keep in constant communication with them, and tell them what they need to do (always give them a new task when they've finished one). Also remember that it'll take them quite a while to figure out the details of what you've got so far. So make sure to constantly summarise and give them the necessary details whenever you give them a task. Don't expect them to study the current design documents for hours on end to figure it all out.

Oh, and find somewhere to communicate easily and quickly. Facebook, Slack, a Google Doc.

Good luck. :-D

Grundislav

After being used to working alone and handling pretty much all aspects of game development since I started using AGS in 2001, my first real team project was Shardlight. I learned a lot from that experience, and can offer you a few points of advice.

1. Most important, and hardest: learn to let go. You're used to doing everything yourself. You want to have complete control and micromanage everything, but you can't. You have to realize that there are other people on the team who are just as dedicated and capable (sometimes more so) than you are. If you have an amazing idea that you love, and everyone else on the team thinks it doesn't work, it's most likely because the idea is no good, not because the rest of the team is wrong. Be receptive to feedback and don't get upset when things don't go your way. It's not your project, it's the team's.

2. Communication is vital. Nobody can read your mind. You have to be SUPER CLEAR about everything you want. Don't be afraid of sounding condescending (but obviously, don't actually be); what seems obvious to you may not be to anyone else. If you have a specific vision, make it as clear as possible to the other team members. If you're doing a sketch for a background to provide to your artist, for example, make sure you indicate what everything is. If that door absolutely has to be in that specific spot, point that out. Otherwise it's just going to lead to confusion and anger. Send a weekly email outlining what you did on the project, and encourage the rest of the team to do the same. This helps keep up morale and motivation.

3. Be flexible. Games never end up exactly as you plan them, and this is amplified even more when working on a team. There's a lot of new ideas and opinions that are going to be floating around. Listen to them. Embrace them.

4. Make a point of focusing on the positive. It's very easy to just be in critique mode 24/7, but that can get tiring very fast. For every "I think this needs work," make sure to emphasize something with "you did a great job on this!"

Hope that helps!

Crimson Wizard

#3
I wanted to give a big +1 to Grindislav's post. :)

These points are something you realize very soon when you switch from working alone to a team work. And if you won't adjust to the change, your project will descend into depressing chaos.


One thing I would like to add and empasize, "project lead" is not simply a fancy title, it is a work position just like any other (artist, programmer). So, if you feel that you cannot efficiently combine being a lead (organize and test other peoples work) and doing something else you wanted to (scripting or drawing), then you better choose either one or another. If it is your project, you are the one responsible to keep it on right tracks at all times. If you fail, everything will fall apart.


Learn to enjoy NOT doing everything :).


Another thing... as a coder (and part time tester in the past) I learnt that writing a design specification early is very important even for small team projects. What I mean, is the document describing game rules, how game should react to user input and and how characters and other entities must behave in game. They also mean to ensure that similar actions and events go same way everywhere in game. Even if something dummy created as the first design variant and improved later.
This task may seem boring and excessive at first, but such documents help team coders to organize the code (especially important when there is more than one coder/scripter), team artists to know which character states/animations are required, and team testers to know what is the expected game behavior.

Yitcomics

#4
Quote from: Grundislav on Sat 08/04/2017 13:02:08
1. Most important, and hardest: learn to let go. You're used to doing everything yourself. You want to have complete control and micromanage everything
Quote from: Crimson Wizard on Sat 08/04/2017 14:55:46
Learn to enjoy NOT doing everything :).
This might be the hardest part, just thinking about it already made me scared to take the next step. But I know I got to, I need the help.

Thanks for these wonderful advice. ;) 

[delete}

#5
I should've sticked to these advice too. Like AGS as a whole, my team project has fallen into said state of depressing chaos.

Mandle

Best of luck with the team project!

I have nothing really to add to the excellent advice already on offer except perhaps this:

Don't be afraid of letting the whole team down!

Spoiler
Be terrified!
[close]
:P

Danvzare

Quote from: Crimson Wizard on Sat 08/04/2017 14:55:46
I wanted to give a big +1 to Grindislav's post. :)
Same here. That advice is almost definitive with how great it is. :-D

There's only a few posts here, but this thread is already incredibly useful.

SMF spam blocked by CleanTalk