Een aantal maanden geleden heb ik een artikel geschreven over wat het wereldwijd werken met teams, offshoring, nearshoring en samenwerken op afstand zo interessant maakt. Ik heb een kritische schoonvader die me vertelde dat ik een aantal valkuilen had beschreven waarin ik was gevallen en hij vroeg me ‘maar wat heb je geleerd van de fouten die gemaakt hebt?’ Deze vraag probeer ik in dit artikel te beantwoorden. Ik geloof dat het kan voorkomen dat anderen dezelfde fouten begaan.
Ik vond het niet leuk om zo veel fouten te moeten maken. De eerste jaren had ik geen idee over wat men moet doen om samen te werken met iemand in India of Oost-Europa. Ik maakte alle fouten die je maar kunt bedenken: het huren van de verkeerde mensen, het werken zonder proces, zonder hulp van een online project management tool werken, het communiceren via chat alleen, werken met leveranciers die niet betrouwbaar waren, vast komen te zitten tussen klant en leverancier, en niet in staat zij om een ??project te leveren aan een klant. En dan nog een berg met fouten gepaard gaande met de opening van een kantoor in India zonder enige voorafgaande ervaring of Indiase contacten.
>Het huren van de verkeerde mensen
Hoewel het gemakkelijk leek om goede programmeurs te huren, je kunt immers objectief de kwaliteit van iemands code beoordelen en redelijkerwijs analytische skills beoordelen, bleek dit in werkelijkheid tegen te vallen. Voor het hebben van een goede samenwerking op afstand zijn technologische en analytische skills slechts deel van de vergelijking. Communicatie is het meest cruciale aspect en het is belangrijk om juist voor die skill te recruiten. Ik heb ook geleerd dat het huren van waarden belangrijk is. Twee van onze kernwaarden die de grootste impact hebben op het succes van ons persoonlijk werk met klanten zijn ‘openheid’ en ‘verantwoordelijkheid’. Ik heb daar eerder ook een artikel aan besteedt.
>Het werken zonder proces
De menselijke spirit is van ‘gewoon door blijven gaan’. We vinden een goede programmeur of team op afstand en sturen de eisen op en verwachten dat het op die manier goed uitpakt. Ik heb geleerd dat het cruciaal is wanneer je werkt met mensen op afstand, cultuurverschillen of een andere taal, dat je afspraken maakt over ‘hoe je te werk gaat’. Als je hier van te voren niet over nadenkt en mensen op dezelfde manier werken zoals ze gewend zijn, tenzij ze bij toeval de juiste routines hebben ontwikkeld, zal je offshore project falen.
>Zonder hulp van een online project management tool werken
Technologische ontwikkelingen hebben hierbij veel geholpen. Veel mensen gebruiken tools zoals Jira, pivotaltracker, github en bitbucket, maar zeven tot acht jaar geleden werd er vooral met email en skype gewerkt. Als je niet vanaf het begin een overzicht maakt, gebruik makende van een online tool dat communicatie, status, bugs, vragen, et cetera, bijhoudt, zal je project na de tijdje ontsporen.
> Alleen communiceren via chat
Het opvallende is dat deze methode absoluut kan werken. We hebben een aantal klanten die alleen via chat werken en tevreden zijn. Maar wat je mist, is de persoonlijke relatie en de verbale communicatie. Ook neemt het meer tijd in beslag dan praten. Het is veilig om achter je pc te zitten, dat geldt zeker voor programmeurs op afstand. Maar het is belangrijk dat je een relatie opbouwt en daardoor efficiënt kunt werken. Scrum is een van de instrumenten die je helpt bij het werken op afstand. Scrum werkt alleen via praten en video en niet met chat.
> Werken met leveranciers die niet te vertrouwen zijn
Toen ik begonnen was met Bridge, werkte ik alleen maar met leveranciers. Degene waar ik mee werkte kregen problemen met het aantal programmeurs dat ze hadden om de hoeveelheden werk te verwerken. Waardoor je uitbreidt naar andere partners. Het is moeilijk om de juiste partner te vinden en dat kost ook tijd. Maar ik heb geleerd dat je daar ook de tijd voor moet nemen. Ik heb ook geleerd dat het voor ons beter werkt om onze eigen mensen te hebben, want zo kunnen we zelf beslissen wie we aannemen. Gebaseerd op skills en kennis, maar ook op waarden, hoe ze werken, hoe we een team spirit op kunnen bouwen en hoe we comfort en geluk creëren in ons team. Daarover heb ik vorig jaar een artikel over geschreven.
> Noodgedwongen tussen klant en leverancier komen
Hier heb ik ook een belangrijke les geleerd: om offshore coöperaties succesvol te maken, moeten er zo min mogelijk managers tussen de klant, die vraagt om de creatie van een software programma, en de persoon die het programma creëert, zitten. We hebben projecten gehad waarin een eindklant een webshop wilde, hiervoor een uitgever inhuurde, die op hun beurt een web agency inhuurde, die vervolgens ons inhuurde, en wij huurden uiteindelijk een nearshore team. Vanuit ieder bedrijf was een project manager betrokken, dat betekent op zijn minst vijf project managers. Als één slaapt, faalt het project. Het beste scenario voor een succesvol project is wanneer de eindklant direct met de programmeur praat. Wanneer de skills hiervoor ontbreken, kan een web-agentschap ingehuurd worden om op afstand te praten met de programmeur. Een positieve bijkomstigheid van deze methodiek is het besparen van kosten!
@Hugo Ik ben totaal geen aanhanger van offshoren, outsourcen of nu nearshoren en ik zou aanraden om de Indiaase en Oost-Europese programmeurs hierheen te halen. Gooi de grenzen maar wagenwijd open. Er gaat niets boven direct contact. Maar wat me wel aansprak was je opmerking dat er voor het goede zo min mogelijk mensen tussen klant en technisch uitvoerders moeten zitten. De rest heb je indrdaad niet nodig terwijl juist dat ict zo kostbaar en ondoorzichtelijk maakt. Ben daar ook voor, zo min mogelijk mensen in projecten en alleen medewerkers die inhoudelijk echt iets bijdragen.
Hugo,
Ik heb ook een kritische schoonvader die mij je artikel zag lezen. Toen zei hij heel boos tegen me:
Luister jongen, als het kostenbesparen de doelstelling van een outsourcingtraject is dan is de kans groot dat dit niet gerealiseerd kan worden.
Hij werd nog veller toen hij me vertelde dat: bij een outsourcingtraject moet je extra op je hoede zijn voor het borgen van de kwaliteit! Niet alleen tijdens project-lifecycle maar zeker na het project dus gedurende product-lifecycle. En dit is juist het probleem want het bouwteam en de outsourcingpartner kunnen tegen die tijd niet meer bestaan of geen tijd voor je hebben of hoge kosten maken. Denk terug aan je doelsteling ” kostenbesparing”!
Hij nam vervolgens een slokje wijn, hij was een stukje kalmer. Toen zei hij rustig tegen me:”Zoon, als je aan outsourcing begint, neem OOK een externe bedrijf in de arm om af en toe een audit op het traject los te laten. Je kunt ook alvast gaan kennis maken met de faillissementswet”
Nou Hugo, wees blij dat je mijn schoonvader niet hebt!
Hugo,
Een schoonvader die je helpt te ‘verschonen’ klinkt alsof je een verstandshuwelijk aangegaan bent om het mestquota te vergroten van de familieboerderij. Want ik vraag me af of je werkelijk lessen getrokken hebt uit je fouten of deze na offshoring met nearshoring toch weer gaat herhalen.
Het valt me ook op dat jij en Reza dezelfde boeken lezen en daar naar referenen maar compleet tegengestelde conclusies trekken. Dat vindt ik interessant omdat je vaak schrijft over culturele verschillen maar nog niet een paard van een koe kunt onderscheiden. Misschien moet je naast de managementboeken ook weer eens wat klassiekers te gaan lezen, Multatuli geeft na schooltijd door later opgedane ervaring namelijk hele ander inzichten. En aangaande je schoonvader, John Cleese heeft ook een leuk boek geschreven over familie relaties.
@Louis
Ik ben het met je eens mits het ‘gelijke monniken, gelijke kappen’ principe gehanteerd wordt want die oplossing die jij voorstaat heb ik al eens gezien en de effecten daarvan zien we nu nog terug in allerlei sectoren.
P.S.
Gezien de merites van Hugo om te reageren is aanhef mogelijk verkeerd.
@Ewout Ik neem aan dat je doelt op de beloning met ‘gelijke monniken, gelijke kappen’ van de Indiaase en Oost-Europese ontwikkelaars? En dat dat bijvoorbeeld in de bouw en de transport al nare gevolgen heeft gehad? Ik vraag me af of je dat kan tegenhouden, zou niet weten hoe.
Over het artikel van Hugo, ik vind het wel van lef getuigen om je kwetsbaar op te stellen en te zeggen dat je fouten hebt gemaakt. Fouten, wie maakt ze niet?
Ewout,
Zou je willen uitleggen wat je met het volgende bedoelt:
“Het valt me ook op dat jij en Reza dezelfde boeken lezen en daar naar referenen maar compleet tegengestelde conclusies trekken”
Reza,
In vorige stukje begon Hugo met: “Een aantal maanden geleden heb ik een boek gelezen genaamd ‘100% succesvolle IT-projecten’, geschreven door Klaas Jung en Gerard van de Looi.” Terwijl jij in een reactie naar Nicole schreef:”Misschien een tip voor jou: Lees het boek “100% succesvolle IT-projecten”
Nu ben ik natuurlijk een ezel maar heilige koeien en oude werkpaarden in de near- of offshoring factorijen …
@Louis
Ik heb het idee dat Hugo enkel de zeilen aan het verhangen is nu de wind uit een andere hoek komt, ik zie niet echt een anti-cyclisch werken waardoor hij nog steeds krampachtig probeert de varkenscyclus uit de jaren 30 in stand te houden.
Ewout,
Ok, nu kan ik de link leggen 🙂
Ik heb dit boek vorig jaar gelezen en ik wist niet dat Hugo ook dit in zijn vorige artikel benoemd had (ik lees niet alles van iedereen op deze site)
In dat boek staan verschillende onderwerpen dus ook stukje over “requirements”, vandaar mijn advies aan Nicole.
Het is toch niet raar dat twee verschillende mensen, met verschillende achtergrond en ervaring, twee verschillende visie en ideeen hebben na het lezen van hetzelfde boek.
Het is te zien aan mijn reactie maar voor de duidelijkheid, ik ben het ook niet eens met de near- of offshoring.
@Ewout Van de varkenscyclus had ik nog niet gehoord, net wat over gelezen maar zie nog niet hoe dat zich tot Hugo’s verhaal verhoudt of het hierheen halen van technisch personeel uit andere landen.
Inmiddels weet ik ook het verschil tussen near en offshoring: het aantal uur vliegen.
http://nl.wikipedia.org/wiki/Nearshoring