Waarom tijdzone belangrijker is dan tarief

Een laag uurtarief in een verre tijdzone kan je meer kosten dan het scheelt. De factuur rekent in uren, maar de vertraging zit in de vragen: elke vraag die een nacht blijft liggen, kost een dag. Met een team in dezelfde tijdzone kost dezelfde vraag een kwartier. Daarom kijk ik bij het kiezen van een team eerst naar de overlap in werkuren en pas daarna naar het tarief.

Hoeveel overlap je overhoudt

Stel dat beide kanten van 9 tot 17 uur werken. Dan houd je per dag deze overlap over:

Met vier uur overlap stel je een vraag, krijg je dezelfde dag antwoord en lukt een vervolgvraag ook nog. Bij twee uur lukt dat één keer, als iedereen op tijd reageert. Daaronder wacht bijna elke vraag een nacht, tenzij iemand zijn werktijden verschuift. Ik zou er niet op bouwen dat iemand jarenlang 's avonds werkt om met jou te overlappen.

Een vraag die een nacht wacht

Developers stellen vragen, over een ticket dat niet helemaal duidelijk is of over een randgeval dat niemand had voorzien. Zit je team in jouw tijdzone, dan antwoord je in Slack en gaat het werk binnen een kwartier verder.

Ligt er een nacht tussen, dan wordt elke vraag een dag. Een ticket met drie open vragen duurt zo drie dagen langer. Bij code review gebeurt hetzelfde. Een pull request die aan het eind van hun dag binnenkomt, krijgt jouw opmerkingen pas als zij al naar huis zijn, en de aanpassing komt de dag erna. Nog een ronde, en er zijn twee dagen voorbij voor een wijziging van tien regels.

Terwijl ze wachten, pakken developers iets anders op of gaan ze gokken. Het eerste betekent meer werk tegelijk open en meer contextwisselingen, het tweede soms dat werk opnieuw moet.

De kosten die niet op de factuur staan

Een factuur toont uren maal tarief. Wat er niet op staat:

• de dagen doorlooptijd die verloren gaan aan wachten
• de extra tijd die jij kwijt bent om alles vooraf tot in detail uit te schrijven
• overleg op onhandige tijden, voor jou of voor hen
• een productieprobleem dat ontstaat terwijl je team slaapt

Dat laatste weegt zwaar. Gaat er bij jou om tien uur 's ochtends iets mis, dan wil je iemand die de code kent en wakker is.

Opschrijven is op zich goed: een team op afstand werkt beter met duidelijke tickets, ook in dezelfde tijdzone. Bij een groot tijdsverschil moet alleen alles vooraf af zijn, omdat je tussendoor niet even kunt bellen. Wat je opschrijft en wat in een call kan, beschrijft Boris in async werken: wat schrijf je op.

Zomertijd maakt het rommeliger

In de EU begint de zomertijd op de laatste zondag van maart en eindigt hij op de laatste zondag van oktober. De Verenigde Staten zetten de klok om op de tweede zondag van maart en de eerste zondag van november. Een paar weken per jaar is het verschil met de Amerikaanse oostkust daardoor een uur kleiner dan normaal, en schuiven vaste overleggen mee.

Werk je met een land zonder zomertijd, dan verandert het verschil twee keer per jaar met een uur. Dat is te overzien, maar het is wel weer een agenda die je moet bijhouden.

Servië zit in dezelfde tijdzone als Nederland, ook in de zomer, dus daar speelt dit niet. Meer over de praktische kant lees je in werken met developers in Servië.

Wanneer een groot tijdsverschil wel werkt

Een groot tijdsverschil werkt als het werk goed af te bakenen is en weinig vragen oproept, zoals een losse module met een duidelijke specificatie. Het werkt ook als het team aan de andere kant een eigen productowner en lead heeft en complete features oplevert. Voor support kan het zelfs handig zijn dat iemand wakker is terwijl jij slaapt.

Een developer die midden in je eigen team meedraait en dagelijks met je productmensen afstemt, heeft overlap nodig. Zo werken wij: onze developers zitten in het team van de klant, op dezelfde uren.

Zo vergelijk je aanbieders eerlijk

1. Tel de overlap in werkuren, en kijk ook naar de weken rond de zomertijd.
2. Vraag wie er om vier uur 's middags (jouw tijd) antwoord geeft op een vraag.
3. Meet in een proefperiode de doorlooptijd per ticket, van start tot merge.
4. Reken de kosten per opgeleverd ticket uit, naast de kosten per uur.

Bij ons duurt die proef twee weken, en werkt het niet, dan betaal je niets. Hoe het daarna loopt, staat bij onze werkwijze. Wat een developer in totaal kost, ook als je zelf werft, zet Bas op een rij in zelf werven of nearshore.

Bronnen

• Europese Commissie: zomertijd in de EU
• NIST: Daylight Saving Time rules