Een softwareproductteam is niet zomaar “een aantal developers.” Is de structuur niet op orde, dan bouwen zelfs sterke individuele developers uiteindelijk langzaam de verkeerde dingen.
Hieronder lees je hoe een goed gestructureerd team er per rol uitziet.
De kernrollen in een softwareproductteam
Product leiderschap
Iemand moet het “waarom” bewaken. Dat is de Product Manager (of Product Owner, afhankelijk van de teamgrootte, zie ons artikel over het verschil tussen de twee), die bepaalt wat er gebouwd wordt en waarom dat relevant is voor het bedrijf.
Developers
De mensen die de software daadwerkelijk bouwen. De meeste teams splitsen dit in front-end (wat gebruikers zien en waarmee ze interacteren) en back-end (de logica, data en infrastructuur erachter), soms gecombineerd in full-stack developers.
Design
Vertaalt de roadmap naar iets bruikbaars, en bepaalt hoe een feature er daadwerkelijk uitziet en werkt voordat een developer er een regel code voor schrijft.
Quality assurance
Vangt op wat er kapot gaat, voordat je gebruikers dat doen. Bij sterke teams is QA geen laatste check voor livegang, maar een vast onderdeel van het hele proces.
Hoe deze rollen samenwerken
Een gezonde structuur is minder een hiërarchie en meer een kringloop: product leiderschap bepaalt wat het waard is om te bouwen, design bepaalt hoe het moet werken, developers bouwen het, en QA controleert of het ook echt doet wat het moet doen.
Ontbreekt een van deze rollen, dan zie je dat voorspelbaar terug. Geen product leiderschap betekent developers die prioriteiten moeten gokken. Geen design betekent stroeve, door developers ontworpen interfaces. Geen QA betekent bugs die echte gebruikers bereiken.
Hoe groot moet een productteam zijn?
Kleiner dan de meeste mensen verwachten. Eén product, ook een behoorlijk complex product, is meestal goed geholpen met twee tot vier developers, één product lead, en QA- en designondersteuning die pas fulltime hoeft te worden zodra het team verder groeit.
De fout die we het vaakst zien is niet te weinig developers, maar een team developers zonder enige toegewijde product leiderschap, precies waar snelheid verandert in efficiënt het verkeerde bouwen.
Deze structuur opbouwen zonder voor elke rol apart te werven
Apart werven voor product leiderschap, developers, design en QA kost maanden, en de meeste bedrijven hebben dat niet vanaf dag één allemaal fulltime nodig.
Een Wise Minds product unit heeft deze structuur al staan: developers, product leiderschap en QA die vanaf dag één samenwerken, precies op maat van wat het werk nodig heeft.
Heb je al developers en mis je vooral de structuur eromheen, bekijk dan software detachering. Begin je vanaf nul, bekijk dan developer inhuren.
Realistisch gezien minstens één developer en iemand die de productbeslissingen bewaakt. Daaronder bouw je zonder richting, of zonder de capaciteit om ernaar te handelen.
Niet per se een aparte hire, maar de verantwoordelijkheid moet wel ergens liggen. Bij kleine teams wordt dit vaak gedeeld, in plaats van eigendom van een specialist.
Voor alles wat gebruikers zien idealiter wel. Developers kunnen basale designbeslissingen dekken, maar toegewijd designwerk levert meestal merkbaar beter resultaat op.
Rollen die gedeeld of parttime waren, worden toegewijd. Een developer die meerdere petten draagt, wordt meerdere specialisten, en product leiderschap splitst zich meestal in een Product Manager en een of meer Product Owners.
