The Individual Roles Within a Software Development Team
November 17, 2011When it comes to any one problem to solve, place to get to, goal to achieve, there are limitless ways to get there, especially when it comes to software. Those differences can be in technology used, development lifecycle, team size, test-driven, you name it, there’s a different way to do it.
One aspect, which is likely the most important aspect of them all, is your team’s structure and the different roles that people take and how those roles fit into getting things done well. Even when the team is really just one person, that one person has to take on those different roles. Though there are many different names for these roles, I’ll give them the most generic classifications possible and then give examples of those kind of roles and their relationship to the features or requirements needed for a project or effort.
Source – Examples: Client, Business Analyst
This is the person who has the inspiration or idea for what should be created and at least some vision of what that will look like. This could be a client who needs a website made, a developer with an idea for the next killer app or a business requirement coming from management. I tend to think of them as “the Source” because they are where the work or project is coming from.
Refiner – Examples: Project Manager, Lead Developer, Designer
Here we have the person who really delves into what needs to happen to make something useful and compelling. They either can be the Source who refines their own idea, or they could have a back-and-forth with the source to really find out what is going to happen, what’s needed and what benefit the idea is going to provide.
Architect – Examples: Technical Lead, Lead Developer
After the Source and Refiner have done their jobs and come up with what should be built, the Architect decides how it’s going to be built and how it’s going to happen. That can include deciding the technology or methodology that will make the idea into an actual project and how it’s going to be completed.
Builder – Examples: technical Lead, Developer
The Builder will take what the Architect, Refiner and Source have put together and make it a reality. They will take the project and actually build or complete it, likely with a fair amount of interaction with the above three as unforeseen or unplanned events, complications or considerations come into play.
Tester – Examples: End User, Project Manager, Client, Developer
Once the Builder believes they have finished creating the project, or at least portions of it, someone checks to make sure it’s behaving and works as expected. This Tester will often go back and forth with the Builder when unintended problems are found or missing features are discovered or additional requirements that weren’t thought of before are found.
User – Examples: General Public, Employee, Client
Finally, once the project has been completed, there is the actual user of that project. This is the person who the project was built for and who should be the main consideration throughout the project, making their life easier or more enriching in one way or another.
Now that we have these different roles defined, I hope to go into what an ideal structure would be on a given project in a follow-up post.
