I have been running my web development company by myself for the last 6 or so years (and as added background, I have never worked in a development team as I am currently a university student and have only just run my own business, so I have no experience in that regard as of yet), but I am gearing up to take on something a little more ambitious and am currently working on setting up a small team. I'm quite proficient and used to what I do as a single unit, but don't know where to start when it comes to setting up the work environment and generally managing a project with more than one person working at the same time. I know it will be important to setup with SVN, but other than that what should I know? Also, if it is important, most likely all team members will be local, but one or possibly two could be virtual team members.
The fact that you're asking this question goes a long way to show that you're already going to be a good leader. If I had to answer in just one word, it would be communicate.
Communicate constantly, verbalize and verify every assumption that you'd normally take for granted, and insist that your team do the same.
On the administrative side, set expectations up front about who will be responsible for what, how it will be done, by when, and at what cost. If you're the lead, then you get to decide whether this will be a dictatorship or a democracy, but make sure everyone knows exactly what is expected and then write it down where everyone can see it. Use a pencil, a whiteboard, a wiki, or any tool that works for your environment. And be sure to update assumptions, requirements, schedules, and problems as they change. As you mentioned, a repository with tracked changes (and off-site backups!) and a defect-tracking system are essential; plenty of very good open-source tools are available.
To manage the project, hold short status meetings at least daily, at which each member will tell the others what s/he's accomplished since the last meeting, what the current and next tasks will be, if any new risks or problems have arisen that might impact the schedule, and whether any help is needed from the other members. Keep the schedule updated, understand the critical path, and try to anticipate and solve potential problems before they occur. Organize the project so you'll know early where the problems are likely to be, and so you'll have a good feel for the final product. Choose some milestones, and perhaps schedule a demo as soon as the "shiny" parts are ready for feedback, to ensure you're meeting the customer's expectations. Do whatever you can ahead of time: obtain tools, line up meetings with experts, configure a test server, etc, to maximize your productivity.
On the technical front, perhaps the most important steps are to divide the project appropriately between your team members, and to define your interfaces. Segment the project so each team member can work as independently as possible, completing and testing each component without depending on another's work. Decide up front how the components will interact with each other: define the APIs, the expected (and unexpected) inputs and outputs, and several test cases. The ability to treat each others' work as "black boxes" will speed and simplify integration and debugging. At the same time, reviewing each other's work will help you better understand exactly how the final product will function, and if you should find yourself in the unfortunate position of needing to replace a team member, it will be easier to make the transition.
And, finally, remembering that everyone is human, encourage each team member to take responsibility for and pride in his/her work. Treat problems as objectively as possible and collaborate to overcome them. Cheer each other on as you progress, appreciate each other's talent, and celebrate each little win along the way!
Good luck -- and lots of success!
Four things that work wonders:
- SVN or other version control software (if the team is bigger then I'd suggest thinking about a distributed one like Git)
- A bugtracker system (I'd suggest Trac as it has integrated SVN and a Wiki for documentation)
- Written, accepted, finalized and policed Coding Conventions
- A clear list of responsibilites
this is just a comment, not so much an answer, but I would really look into git over svn. you can still setup a central repository, but the workflow with git is nicer I think, there is less of a concern of corruption, and the fact that each repository is a legitimate repository that you can use offline is huge.
If you doing a bit of code beyond html pages then: In addition to using SVN (a good choice, it's free/open source, does great things), consider Test Driven Development and Continuous Integration
In addition to some very good suggestions already listed, I would also seek out constructive criticism from your new team. Also, build consensus when you have ideas.