Het werken met hybride remote teams inclusief voorbeeldberekening

Bij Digital Value Creators zijn we begonnen met het experimenteren met hybride teams.

Het komt erop neer dat een team van nearshore developers wordt gecombineerd met een Nederlandse Product Owner en een set van contractuele werkafspaken met onze klant.

De setup ziet er zo uit:

  • De developers vormen de uitvoerende kern van de te onderhouden applicatie. Dit kan een mix zijn van meer senior, medior en junior developers. Zowel front-end, back-end of full stack.
  • Vanuit Nederland is er altijd een Product Owner betrokken, met alle bekende voorkomende werkzaamheden, deze is de facto eindverantwoordelijk. 
  • Vanuit klantzijde is er betrokkenheid in de vorm van (ten minste) inhoudelijke betrokkenheid en gebruikers.
  • Werkafspraken worden gemaakt om commitment en verwachtingen over en weer te borgen tussen developers, Product Owner, betrokkenen en stakeholders. Denk aan het bijwonen van meetings of het concretiseren van abstracte items.

Hoe pakt dit model in de praktijk uit?

Stel een klant wil een applicatie realiseren of een bestaande applicatie verder uitbouwen en/of onderhouden.

Op basis van een inhoudelijke intake wordt de scope en omvang van een applicatie uitgewerkt in een globale roadmap waar ook planningsaspecten aan bod komen.

Hierdoor is er een team samen te stellen met een bepaalde skillset en van een bepaalde omvang passend bij de specifieke scope en planningsaspecten van het project.

Bij kick-off en in de eerste periode van het project zal de mate van betrokkenheid relatief hoog zijn. Na een aantal sprints zal dit afnemen en in een normale sprint cadans terecht komen.

De contractuele kant 

In de contractuele werkafspraken zijn alle events, verantwoordelijkheden in detail afgesproken. Een paar voorbeelden:

  • inspanning leverancier: beschikbaarheid technische team minimaal 90% per week
  • inspanning klant: inhoudelijk betrokkene, minimaal 8 uur per sprint.
  • Beide: Aanwezig bij minimaal 90% van alle Scrum events
  • Beide: Doorlooptijd besluiten prioritering maximaal 1 dag.

Door deze afspraken transparant en helder te maken, zowel aan leverancier als aan klantzijde geeft dit een belangrijke bijdrage aan heldere verwachtingen over en weer. Dit komt de kwaliteit en doorlooptijd ten goede.

Een contractduur kan worden aangegaan voor ten minste 6 maanden met specifieke opzegbepalingen aan beide zijden. 

Een rekenvoorbeeld

Stel een applicatie is begroot op 6 maanden voor een klein team van 3 developers en bijbehorende begeleiding. 

De ‘formule’ is om met een team van tussen de 3-6 developers te werken en daarnaast een Product Owner. De inzet van de Product Owner zal bij kleine teams 0,4 FTE zijn en kan bij grote projecten oplopen tot 1 FTE.

Stel er is sprake van een middelgroot project met 3 developers en o,5 Product Owner

Uitgaande van een fulltime werkweek van gemiddeld netto 34 uur en een maand van gemiddeld 4,3 weken

Een berekening volgens Nederlandse tarieven:

((34 x 3 x 85) + (34 x 0,5 x 100)) x 4,3 = afgerond € 45k / mnd

Een berekening volgens nearshore tarieven:

((34 x 3 x 45) + (34 x 0,5 x 100)) x 4,3 = afgerond € 25k / mnd

Dit model heeft in dit rekenvoorbeeld 55% van de kosten ten opzichte van een in-house model. Vanzelfsprekend kan dit niet per se als een directe kostenbesparing van 45% worden gezien. Vergeleken met Nederlandse in-house developers kan een remote team bijvoorbeeld een stijlere leercurve hebben of minder ervaren zijn met specifieke context of materie. Daarnaast speelt 100% remote ook een rol.

Naast een kostenvoordeel is er een voordeel in stabiliteit en continuïteit. Er is minder last van een krappe arbeidsmarkt en verloop van personeel dan bij in-house teams.

 
Comments are closed.
Stel uw vraag direct via WhatsApp