Some friends of mine came up with an idea for a web application which we (so far) think could be great. I made the analysis and all the early stages of the development process and I'm about to start the coding. I'm talking about something that is barely a mid-level project, so I consider one developer (myself) should be enough.
The thing is that we are trying to assign roles to each one of us so we can be focused on our duties and have clear our responsibilities within the team. We are a crew of four people, three of us (my friends) are business people who would do the marketing, customer relationship, management and accounting stuff and I'm basically the developer. I have in mind to get them involved into the development process by giving them documentation to write and use them as testers, all of that besides the management duties they have.
Perhaps someone out there have been in the same situation, so I would appreciate if the experience is shared so we can effectively give ourselves positions in the project based on what I explained above. Which are the essential roles or the optimal team layout so the idea can be developed successfully? The question is not strictly about programming, but it's related to build a software entrepreneurship beyond the code, that is something that I'm sure plenty of us are looking.
Any help is really appreciated! Regards.
Best Answer
When my friends and I (7 of us) began such a project, the one thing we agreed on was that no matter what happened, we would still be friends at the end of the project.
Now that the warm and fuzzy stuff is out of the way (-: here is how we managed things:
Strong team leader: Someone with a vision of the project, and someone to center us when the discussions got side tracked. Ours happened to be an officer in the Army/WestPoint. He kept us on track!
Weekly deliverables & documentation: We were responsible for completing items like requirements gathering (business & technical), to creating use & test cases (based on requirements), UML diagrams, mock ups, prototypes, etc., along with the relevant documentation. Having this document (about 400 pages at the end in our case) was very helpful.
Play to skill sets: Each one of us had very specific set of skills, and we were assigned/took aspects of the project that fit us the best. At the same time, several of us stepped in for others for whatever reason. We were respectful to not take over someone else's portion, but offered help/suggestions when we saw things weren't moving or getting off track.
Break project in manageable tasks: From Project Management, Data Model/DB design, Coding, UI, etc. Try not to be too granular, but that we found was more art than science.
Prototype early & often In retrospect, since we were doing this on a tight timeline, we should've created a prototyped and adjusted the requirements as needed. We used the waterfall approach, which worked in our case, but I think a rapid prototyping was more what we should've used.
Breaking the impasse: There will be a time when you will not agree on what path to take or what to do next. Give someone the authority to be the tie-breaker if things come to that.
Passion & Trust: We believed in our project, its goals and values. That kept us going with our work when the times got tough. And we knew we could rely and trust on others on the project -- not just to do their job, for us to have a honest discussion about various aspects of the project without any negative implications (If only I could bottle that up ... )
While our project didn't launch (another company beat us to it), we learned a lot from it. And yes we are friends to this day. (-:
HTH, good luck!
KM