next »

[Mikademus]

Real project management, as in when you try to organise the efforts of several people to a common goal, can be a real bitch for several reasons, all of which boils down to people.

Some people a enthusiastic and natural team players. Some are patient and bring out the best in others. If they're also skilled and communicative these people are worth their weight in gallium and should be treasured. They are very few and far between...

Most people one will come across in software projects bring something else to it: Some people are overambitious or overcompetitive. These usually want to make the project theirs and decide, and they will usually be sources of conflict and disruptive dispute. Some people are passive, lazy or freeriders. Some are stop blocks. Some will believe in their own superiority and in others' incompetence. Some will be passive aggressive, incommunicative or create a bad atmosphere for other intra-personal reasons. And some will simply be incompetent.

Project management is about orchestrating the skills of different people into a process of complementary efforts. It is about making the co-workers motivated to work and work in the right direction. And it is about prioritising what needs to be done, or to create work processes that will result in that and that everyone are aware of the priorities. All these things are hard and there is no general guide how to achieve it and coupled with that most co-workers will fit more in the second than the first group there you have the reason that as much as 80% of all real-life (as in "business") software project fails...

That said, for smaller indie game projects some good rules of thumb are:
* Have a game document at least describing the game's intent, story and mechanics. Make certain everyone has read it and agrees with it.
* Make everyone know there is one principal visionary behind the game. This person should understand that the project is not only 'his' and that he is not a dictator and should listen to everyone's ideas, but everyone should accept that his word weights heavier in game design decisions.
* Set up short-term goals and make certain everyone agrees on these and contribute to them.
* Be positive and constructive, and always remember to appreciate each other for the effort you all put in. Negativity or placing blame can ruin everything faster than you might imagine.

[Vino]

I'm actually developing some software that among other things is designed to help indie developers manage their projects. I'm trying to nail down exactly what kind of project management tool is best for indies. Many (like me) just want a good to do list, and others want something that helps them coordinate a bunch of people. Can you guys give me a good idea of what the perfect web based project management for an indie game developer would be?

[flavio]

Can you guys give me a good idea of what the perfect web based project management for an indie game developer would be?

I can only speak for myself, but maybe it helps.

• a system like a wiki, to collaboratively write and maintain (design) documents;
• a (micro)blog system to maintain the other parties up-to-date about your state;
• a blog system to inform the team about the important news of the project;
• forums;
• a chat;
• a place for sharing files;
• an issue tracker;
• plugin system to customize specific needs;
• a private area where you can store private resources (private messages, private tasks, private bookmarks, private contacts, private files, private calendar);
• an overview/roadmap of the project - to show which issues are required to be solved to reach each milestone;
• a code browser (typically connected to a VCS).

Ok, this is a lot more than an indie may need (very often a text file is enough), but maybe you can find something useful here and there.

[Average Software]

Can you guys give me a good idea of what the perfect web based project management for an indie game developer would be?

My first requirement would actually be that it not be web based.  I would want a real program that interacts with a local database.

[J-Snake]

Some will believe in their own superiority and in others' incompetence.

That's not a problem as long as others accept it.

[PompiPompi]

Probably 99% of the programmers think they are really great and smart, and only 1% are actually that.
Yea, you can code and make stuff, we get it. No, it doesn't make you brilliant...
(At least from my short experience in working in a "real job")

[Mikademus]

Some will believe in their own superiority and in others' incompetence.

That's not a problem as long as others accept it.

I know that you're trolling as always but it actually is a severe problem because it leads to a bad atmosphere, feelings of entitlement, decreasing communication and suffering code quality and project direction. In general less experienced developers overrate their own competence and underestimate that of others, while experienced developers will promote the team because it is more efficient than doing everything themselves.

[Jasmine]

My question is simple, how do you do your project management for your games?

I tend to just keep a "picture" of the project in my head, and because I'm a global thinker, that's my preferred method of management.
 
But as my projects have grown bigger I feel a need to write some thoughts down, knowing that sometimes I can forget them. So I often end up making a rough list of things that need to be done. Then periodically rewriting the list as some points get done/partially done/divvied up.

So clipboard and trusty retractor pencil suffice for project management.

[InfiniteStateMachine]

For personal projects I usually just have a notebook and drawer for that project. I put various list and design stuff in there. I usually write a list of my weeks goals and more often than not a lot of those are left over the next week. I just rewrite the list about once a week.

For group projects over the internet. I personally just like to use a forum and IM's. Maybe trace attached to SVN for bug tracking.

I've worked on teams that have used a whole suite of products like basecamp etc. On of the problems with that is that people forget to use all of them and they ultimately go unused. Getting new team members up to speed on those apps takes time.

[J-Snake]

Divide and Conquer is really the gold-tip here. I cannot imagine any other concept how to deal with complexity since it simply doesn't exist.