for DEVELOPMENT: designer, coder, artist, soundguy. those are the 4 basic skill sets (hats to wear).

the designer designs the game, often delegating some amount of design details to the implementor (coder, artist or soundguy).

the coder, artist and soundguy just build the design.

to SELL:

marketing, and order fulfillment. marketing may require a web presence which may require a coder and an artist.

your typical small team consists of a coder, an artist, and one other person (a level designer, 2nd coder, 2nd artist, etc). all contribute to the design, with one member being the game concept originator, and therefore design lead, and team lead. Often times it seems this person is the coder. I suspect this is due to the fact that for most games, there's more man-hours of code work than there is man-hours of artwork or sound work. so the coder has more work to do. if the coder isn't the creator, its hard to keep them slaving away at someone else's vision. between the three of them they have soundguy skills or have a soundguy buddy.

Honestly, I would include marketing tasks right from the beginning. Someone with marketing sense should be looking at your Game Design Doc, to help make sure your focusing on salable features, instead of white noise. Naturally, anyone can take on that kind of task, but the more experience the better.

I have another post, I opened 20 minutes ago on Roles and tasks/responsibilities associated with those roles. At this moment, it has no submissions, but I'll start posting some of my knowledge to it shortly. http://www.gamedev.net/topic/638677-roles-and-tasks-needed-in-video-game-development/ I think its good to consider the value of all the responsibilities you don't have someone to cover, and at least keep those in mind to begin with.

Honestly, I would include marketing tasks right from the beginning. Someone with marketing sense should be looking at your Game Design Doc, to help make sure your focusing on salable features, instead of white noise. Naturally, anyone can take on that kind of task, but the more experience the better.

yes, if a project is going to be for-profit, then that affects everything: what to build, platform choice, tool choice, available graphics engines, libraries, etc, and skills in the use of those. Also, a for-profit project should continually strive to achieve "buzz" about the product, starting from the first day of conception of the game idea.

As for marketing influences on the design doc, i take that with a grain of salt. Yes, it is good to evaluate the feature set based on selling point potential. However, while an experienced marketer can say what sells well, there is often a tendency to attempt to modify designs to increase profitability at the expense of the design itself. IE make it more of a "this, that, or the other" type of game cause that sells well. If the original game type and the "sells well" game type are too dissimilar, the result is a compromise that appeals to fans of neither type. Its also possible that market driven design will overlook profitable but "less than best return" titles, or pass on the next new killer game app cause its not the current "sells best" game type. In the end games must be approached from a gamer point of view, not a marketing, coding tour-de-force, artwork, or storyline point of view. Bottom line: cool games are what sells. And a gamer is more likely to know whats cool than anyone else - including marketers and publishers. After all, gamers are in this for the "love of the game", marketers and publishers are just in it for the money.