a good way to organize it might be by the different phases of development.
the tasks change during the different phases of development.
the first phase is the what to build phase. here the tasks are about coming up with game ideas, and evaluating them for popularity, competition, and man-hour cost.
once the question of what to build is answered, there's a lot in the way of design work, concept art, writing of test code for mission critical routines that will be required by the game engine, etc. figuring stuff out. smart teams do this first. most teams don't: "stay calm - keep coding - it'll all be alright".
then things start getting built. at first usually a quick and dirty prototype.
then nature takes over.
like a living creature, the software take on a life of its own. it evolves, get tweaked, features are added. sometimes entire subsystems are upgraded to newer stuff (like switching to a new graphics engine when you're already half way through building it with the old one). The design evolves. As the team works with the product, they think of improvements. Eventually, the design and software evolve into the final product.
testing should be a continual and ongoing process, constantly feeding back into design improvements. at the end, a final phase of mostly testing with few changes puts the final polish on the product.
these are the basic phases of the manufacturing process.
concurrent with these activities, the marketing department should be performing their own duties, such as press releases about the new title in development, creating a web presence for the company and title, including fans sites, developer blogs, and anything else that will build pre-release "buzz" abut the product. The big ad campaign kicks off at an appropriate amount of time before the final release date, and is continued as long as the cost of leads generated is favorable. Marketing should also constantly be searching for new channels, bundle wrap deals, way to licence the company's assets, or any other way to increase revenues.
if a company is REALLY savvy, they have some kind of feedback from marketing and tech support to design. marketing and tech support are the departments closest to the customer, and its often they who hear the customer's feedback.
Oh yes, forgot tech support in the previous list. that phase comes after release (obviously). "After sales service": this might include expansion packs, downloadable content, bug fixes, patches, mods, etc. A lot of companies neglect this, but its crucial to building fan base, and turning your one hit wonder title into a franchise.
needless to say, as the tasks change, the personnel requirements change as well. but its probably better to think of it in terms of tasks than job titles.
another thing to do is be careful of the movie industry model. many larger companies tend to be organized along these lines. But they are forcing a set of roles (assumed
to be required) down from above, instead of defining the roles form the bottom up based on the tasks required.
take a look at the history of some of the early small teams that first made it big like ID software. This will give you a better idea of what needs doing and who does it on a small dev team.
from your other posts, i see this is the second edition, and that you seem to have based the first edition mostly on personal experience. based on your questions i take it you've never been lead/only designer, lead/only coder, or lead/only artist or all of the above on your own project? Just marketing on larger projects (big enough to have a separate marketing person)? if this is the case you'll want to pay extra attention to your research into areas of game design and development where you own hands-on experience is limited. believe it o not, there's a certain amount of us vs them mentality in game development on the part of designers, coders and artists (and between them too!). the two sides are: 1. the designers, coders, and artists, in the trenches, slaving away 18 hours a day on Coke and Pizza's, playing foosball while they wait for the linker, etc. and: 2. everyone else (often referred to as "suits"). this is everyone not directly involved hands on in designing or building the game. if you don't come from group #1, but from group #2, you're better know what you're talking about if you want to reach anyone in group #1. it is all too common for folks from group #2 to tell group #1 how to do their job when they have no clue, cause they've never done it.