What structure of a team should one keep in mind when making a team at the starting of the project ? Like what should be the ratio of Senior Software Engg. to Software Engg. or how many freshers should be attached to the team etc. and many other points.
Please share any point that has an importance when deciding the structure of a team.
Atleast 25% of the team should be Senior software engg. with experience of 4 years and more. 60-70% can be software engg. with experience between 1-3 years and the rest can be freshers.
Assign the role and responsibilities accordingly. Further if there are resource avaliable in the same domain as that the project give them weight-age when deciding the team.
Also I think that freshers should be involved in the development of any project. Though they may be assigned easy tasks, but remember you should always think them as future investment for the project. For once the project is complete you may need resources for its maintenance.
Also sometimes the marital status also effects the decision to take a resource or not. It depends upon the responsibilities and workload involved needed in the project. If the project involves late night shifts or frequent client visits then this is always considered especially when the client is geographically far.
Depends on your own preferences but ask yourself this: do you really want people mentoring others at the start of a project? Or do you want the project written and written well?
Get as many seniors as you can afford and maybe have one or two very bright students if you can find them.
Who you have is much more important than their seniority level. Select the right people for the job based on their skills and ability to work together, not on some set of buckets labeled 'senior' and 'junior'. Make sure you understand what it is you are trying to build, how design improvements/alterations will be ratified by the group, and how disagreements will be unwound and resolved.
You need a boss, usually, unless people are okay with being very open about decisions. The boss's job is also to act as a conduit to the rest of the organization. Go read all of Rands In Repose.
Start the team as small as possible. Lots of great software, and many great sites, are the result of a 1-3 person team who really work well together, understand their market, and understand the architecture. ("Never doubt that a small group of thoughtful, committed people can change the world. Indeed, it is the only thing that ever has." -- Margaret Mead) Be loathe to add more people. Beware the n^2 law of communication: for n people, there are O(n^2) channels of communication and relations to manage. While group meetings help this a bit, there is always a need for 1-1s.
And beware the Mythical Man Month and Brook's Law: adding more people won't accelerate a project go as much as you think it will, and can in fact slow things down. The cost of overhead rapidly overtakes the cost of development. Definitely read that book before doing this sort of planning!
Gender has complex interactions, but again, it is more important to look at the specific people in place rather than seeing them as simply an example of their gender. The Liskov Substitution Principle does NOT apply to humans.
Good luck!
The rule used to be 'just enough people so they can jump into the VW convertible and go get a pizza'.
Note the corollaries:
(a) someone has to have a VW convertible (b) they all have like pizza (c) they all have to want to eat together
You can get (a) and (b) fairly easily. (c) is pretty tough these days.
Seriously I agree with the other posters. Ratios are meaningless. You want the best possible team you can put together. Hire the N best interviewees and get the project done. Your only constraint on this is cash flow but the total outgoings are certain to be less than for any other team structure.
One rule I always keep in mind: The team structure and players WILL change, let's not get to hung up on the current one too much. Figure out what you need NOW, adjust and move forward.
Manage the team structure with skills you need. Some senior people can handle lots of juniors (freshers) to mentor/manage, some can NOT.
In no order or anything:(SOME folks can do all, some only one)