Samenwerken met Indische IT/Engineering bedrijven

Het valt me op hoe weinig mensen hier eigenlijk echt open staan om samen te werken met Indiërs. Ik heb er nu 12 jaar mee samengewerkt, en het helpt ook gewoon om hun cultuur wat te leren begrijpen (je verwacht exact hetzelfde van hen he...)
1) Dat "ja-zeggen" ook al begrijpen ze iets niet: In India is het onbeleefd om tegen uw "meerdere" te zeggen dat je zijn uitleg niet begrepen omdat dat voor hen wil zeggen dat jij het slecht uitlegt. Dat los je op door ofwel ze daarna het zelf te laten uitleggen, ofwel door er voor te zorgen dat ze u niet als hun meerdere zien maar als een vriend/collega.

2) De helpdesk... no offence, maar bel eens naar een random helpdesk van pakweg Telenet he... Ook niet bepaald de hooggeschoolde IT-ers...

Ik heb het in mijn eigen teams ook gezien, Indische collega's die on site in de teams zaten, maar die nog altijd stiefmoederlijk behandeld werden (als in: niet uitnodigen op teamdrinks etc). Ik heb het bij meerdere collega's gehad die mij nadien kwamen bedanken omdat ik hun eerste Belgische vriend was. Ik vind dat echt schrijnend, dat zijn gewoon collega's zoals anderen, je kan daar perfect ook eens mee lachen enzo he.

Zie hierboven precies "hun werk was nooit AF." en dan een paar zinnen later "na 3 tot 6 maanden waren ze terug weg"... Ik heb nog NOOIT op een project gezeten waar ik op minder dan 6 maanden volledig was ingewerkt in de materie, maar je verwacht wel van iemand die zelfs niet op locatie zit om dat wel te zijn...
Akkoord. Je ziet erg duidelijk hoe weinig mensen hier enigszins effectief kunnen samenwerken met andere culturen. Best schrijnend. Het is altijd makkelijk om het op 'die Indiërs die niets kunnen' te steken.
 
Zie hierboven precies "hun werk was nooit AF." en dan een paar zinnen later "na 3 tot 6 maanden waren ze terug weg"... Ik heb nog NOOIT op een project gezeten waar ik op minder dan 6 maanden volledig was ingewerkt in de materie, maar je verwacht wel van iemand die zelfs niet op locatie zit om dat wel te zijn...
Als je duidelijk gelezen hebt, kon je wel zien dat deze personen bij ons wel op onze locatie zaten.

Maar als je op 6 maand geen materie kunt oppakken als developer dan ligt het probleem vooral bij jou. Wij waren een team van C# devs. Geef mij eender welke applicatie geschreven in C# en ik kon daar gewoon aan werken. High en low level designs waren trouwens ook al volledig voorgekauwd, dus het was puur een kwestie van code kloppen.

Dit heeft ook niks te maken met niet kunnen omgaan met een cultuur. Wekelijks gingen we met het team iets drinken/eten op vrijdag. Maandelijks deden we een team event. Ze zijn zelfs op onze prive BBQ's geweest buiten werk om. Dus daar zal het zeker niet aan gelegen hebben.

Wij als team vroegen expliciet geen junior, maar senior. Ze hadden de gekskte titels tot Phd toe, maar code kloppen en iets testen tot het bugvrij was, nee dat zat er bij de meeste gewoon niet in. Hier en daar was wel eens een goeie, maar die waren zeer zelfzaam. Het gevoel dat wij hadden: Ze komen hier voor een gratis opleiding, voor op de CV te kunnen zetten dat ze "in het buitenland" gezeten hebben en weg waren ze.
 
Zie hierboven precies "hun werk was nooit AF." en dan een paar zinnen later "na 3 tot 6 maanden waren ze terug weg"... Ik heb nog NOOIT op een project gezeten waar ik op minder dan 6 maanden volledig was ingewerkt in de materie, maar je verwacht wel van iemand die zelfs niet op locatie zit om dat wel te zijn...
Bij ons krijg je een dag tot een paar dagen tijd om je in te werken, geen 6 maand hoor :p
Degenen die remote zitten (los van welk land het is) krijgen wat extra respijt. Maar ook meer dan een week is dat niet.
De offshore teams waarmee ik werk zijn ofwel voor zaken te programmeren waarbij we de spec meegeven die zeer goed beschreven moet zijn, daarvoor heb je helemaal geen inwerktijd nodig, want je hoort al te kunnen programmeren voor je begint.
En voor degene die helpdesk doen, geven we gedetailleerde handleidingen mee. De moeilijkere zaken komen dan bij ons terecht.

Business analisten en andere functies die wel grondige kennis vereisten van de materie, gaan we niet uitbesteden aan remote teams. Dat is om miserie vragen.
 
Bij ons krijg je een dag tot een paar dagen tijd om je in te werken, geen 6 maand hoor :p
Degenen die remote zitten (los van welk land het is) krijgen wat extra respijt. Maar ook meer dan een week is dat niet.
De offshore teams waarmee ik werk zijn ofwel voor zaken te programmeren waarbij we de spec meegeven die zeer goed beschreven moet zijn, daarvoor heb je helemaal geen inwerktijd nodig, want je hoort al te kunnen programmeren voor je begint.
En voor degene die helpdesk doen, geven we gedetailleerde handleidingen mee. De moeilijkere zaken komen dan bij ons terecht.

Business analisten en andere functies die wel grondige kennis vereisten van de materie, gaan we niet uitbesteden aan remote teams. Dat is om miserie vragen.

Maar "programmeren" is toch maar 1 deel van de job. Als je verwacht dat ze onmiddellijk meekunnen, moet je er ook mee kunnen leven dat alles wat niet letterlijk in de specs staat, ook niet zo gaat gebeuren.
Voorbeeldje uit ons project, een proces om een adres aan te passen. Adres standaard gemodelleerd in dorp/straat/huisnummer.
Er stond in de specs "het adres wordt geupdate", ja dan mag je verwachten dat ze een update statement doorvoeren en geen lookup naar het nieuwe adres als je niet specifieert dat die adresdata master data is uit een ander systeem ...

De meeste Belgen gaan direct zeggen "ja, ge gaat uw adres niet updaten he, ge update de referentie naar het adres he..." Maar voor een Indiër is een referentie van een adres gewoon absurd...
 
Maar "programmeren" is toch maar 1 deel van de job. Als je verwacht dat ze onmiddellijk meekunnen, moet je er ook mee kunnen leven dat alles wat niet letterlijk in de specs staat, ook niet zo gaat gebeuren.
Voorbeeldje uit ons project, een proces om een adres aan te passen. Adres standaard gemodelleerd in dorp/straat/huisnummer.
Er stond in de specs "het adres wordt geupdate", ja dan mag je verwachten dat ze een update statement doorvoeren en geen lookup naar het nieuwe adres als je niet specifieert dat die adresdata master data is uit een ander systeem ...

De meeste Belgen gaan direct zeggen "ja, ge gaat uw adres niet updaten he, ge update de referentie naar het adres he..." Maar voor een Indiër is een referentie van een adres gewoon absurd...
Dat zijn zaken die in de spec horen te zitten. Zeker voor nieuwe mensen en remote teams.
Iemand die al lang op het project zit, kan je je permiteren om daar vage specs voor te schrijven.
 
Dat zijn zaken die in de spec horen te zitten. Zeker voor nieuwe mensen en remote teams.
Iemand die al lang op het project zit, kan je je permiteren om daar vage specs voor te schrijven.
Dat werd destijds evengoed onthaald op een "die Indiërs kunnen niks, code zit vol met bugs" en dan een wekenlange discussie of het een bug of een change request was.
 
Ik vermoed dat we het over een ander niveau van “slecht zijn” hebben. Bugs of misverstanden als het geval met het adres kan altijd, en dat kan iedereen overkomen. Ook Belgen.

De ervaringen die ik heb zijn code opleveren die niet compileert, de applicatie die niet meer start na de wijzigingen, tot code waarvan je na 2 seconden op het zicht kan zien dat die gewoon nergens op slaat (van het kaliber een rekeningnummer in een adres proberen te steken of zo).

Als dat dan maanden aanhoudt is mijn goesting om er nog iets van proberen te maken ook wel over.
 
Na het lezen van een paar van de laatste berichten begrijp ik het, veel van de bedrijven waar het hier in de thread over gaat werken nog in een project-structuur met een typische project manager die de kudde 'code monkeys' moet opvolgen en aansturen met een business analyst ertussen die 'de business vertaalt naar developer taal' in een specificatie document van 30 pagina's lang. Dat in tegenstelling tot een product-structuur met een team bestaande uit een Product Manager + Developers zoals er bij Google en dergelijke tech bedrijven is.
 
Na het lezen van een paar van de laatste berichten begrijp ik het, veel van de bedrijven waar het hier in de thread over gaat werken nog in een project-structuur met een typische project manager die de kudde 'code monkeys' moet opvolgen en aansturen met een business analyst ertussen die 'de business vertaalt naar developer taal' in een specificatie document van 30 pagina's lang. Dat in tegenstelling tot een product-structuur met een team bestaande uit een Product Manager + Developers zoals er bij Google en dergelijke tech bedrijven is.
De structuur van een bedrijf maakt toch niet uit. Als een developer code klopt die niet werkt, werkt het niet. Simple as that. Plots in scrum, Agile of Safe gaan werken gaat dat probleem niet oplossen. Geen idee welk probleem dat zou oplossen.

Ter info, ik zit in zo een berdijf dat de switch heeft gemaakt. De devs waren niet plots beter... Het enige verschil is dat de miserie eerder opgemerkt wordt.
 
Ik vermoed dat we het over een ander niveau van “slecht zijn” hebben. Bugs of misverstanden als het geval met het adres kan altijd, en dat kan iedereen overkomen. Ook Belgen.

De ervaringen die ik heb zijn code opleveren die niet compileert, de applicatie die niet meer start na de wijzigingen, tot code waarvan je na 2 seconden op het zicht kan zien dat die gewoon nergens op slaat (van het kaliber een rekeningnummer in een adres proberen te steken of zo).

Als dat dan maanden aanhoudt is mijn goesting om er nog iets van proberen te maken ook wel over.
Dat heb ik nu wel nog niet voorgehad met offshore teams. Meestal werkt alles gewoon.

Soms heb ik wel voor dat de code enorm slecht geschreven is, maar dat ligt dan aan hun niveau ipv het land waar ze vandaan komen.
Genoeg Belgen die hetzelfde doen.

Als de code niet meer compileert of de applicatie kapot is, dan zouden die wel rap buiten liggen (of op z'n minst van het project afgehaald worden en mogen ze verder factureren zonder dat ze enig werk doen :/ )
 
De structuur van een bedrijf maakt toch niet uit. Als een developer code klopt die niet werkt, werkt het niet. Simple as that. Plots in scrum, Agile of Safe gaan werken gaat dat probleem niet oplossen. Geen idee welk probleem dat zou oplossen.

Ter info, ik zit in zo een berdijf dat de switch heeft gemaakt. De devs waren niet plots beter... Het enige verschil is dat de miserie eerder opgemerkt wordt.
Ik had het eerder over dat het lijkt dat veel bedrijven hier een specificatie document naar wat developers gooien en dan hopen dat het juist ontwikkeld wordt. Als de code niet werkt is zeer simpel -> terugsturen van code review naar de developer met de uitleg er bij. Als het daarna nog een paar keer op rij niet goed is kan je eens praten met die persoon wat er scheelt. Dan dat probleem samen oplossen, ofwel laat je hem gaan. Ik snap niet hoe die mensen 3-6 maanden blijven steken op zo'n project zonder iets te kunnen doen als het zo slecht is. Dan lijkt me dat er grotere problemen binnen dat bedrijf zijn.
 
Soms heb ik wel voor dat de code enorm slecht geschreven is, maar dat ligt dan aan hun niveau ipv het land waar ze vandaan komen.
Genoeg Belgen die hetzelfde doen.
Ik ga er nu ook wel van uit dat ze die fouten niet maken omdat ze van Indië komen.

Maar dat ze die fouten maken omdat ze een brakke opleiding gehad hebben, in combinatie met een opvoeding die samenwerken bemoeilijkt (dat van ons zien als de grote baas waar je geen nee tegen zegt). Dan durf ik die opvoeding niet eens slecht noemen, want wie ben ik om te zeggen dat dat slechter is dan onze opvoeding. Ik merk gewoon dat het de samenwerking veel moeilijker maakt doordat de opvoeding zo verschillend is.

De opleiding van veel Indiërs durf ik wel slecht noemen. Daardoor ook extra respect voor de Indiërs die het wel goed doen. Die hebben het mogelijk met diezelfde slechte opleiding moeten stellen. Ik durf ook stellen dat 90% van de Indiërs waarmee ik samengewerkt heb op één of andere manier gefraudeerd heeft bij het halen van hun Java certificaat. Want ze hebben het allemaal, maar het gros weet niet eens wat bijvoorbeeld overerving is.

Ik had het eerder over dat het lijkt dat veel bedrijven hier een specificatie document naar wat developers gooien en dan hopen dat het juist ontwikkeld wordt. Als de code niet werkt is zeer simpel -> terugsturen van code review naar de developer met de uitleg er bij. Als het daarna nog een paar keer op rij niet goed is kan je eens praten met die persoon wat er scheelt. Dan dat probleem samen oplossen, ofwel laat je hem gaan. Ik snap niet hoe die mensen 3-6 maanden blijven steken op zo'n project zonder iets te kunnen doen als het zo slecht is. Dan lijkt me dat er grotere problemen binnen dat bedrijf zijn.
Bijvoorbeeld omdat de samenwerking met Indië een prestigeproject is, en omdat niemand aan de grote baas (die in België) durft te vertellen wat een puinhoop die samenwerking is. Vaak wordt ook enkel naar de cijfers gekeken, en de tijd die de Belgen nodig hebben om de boel recht te trekken staat daar dan niet bij. Als ze dan op papier 20% besparen geven ze elkaar schouderklopjes, zonder te beseffen dat een deel van de kost niet in die cijfers zit (tijdsverlies om het handje vast te houden, hogere toekomstige kosten door technical debt, ....).
 
Ik had het eerder over dat het lijkt dat veel bedrijven hier een specificatie document naar wat developers gooien en dan hopen dat het juist ontwikkeld wordt. Als de code niet werkt is zeer simpel -> terugsturen van code review naar de developer met de uitleg er bij. Als het daarna nog een paar keer op rij niet goed is kan je eens praten met die persoon wat er scheelt. Dan dat probleem samen oplossen, ofwel laat je hem gaan. Ik snap niet hoe die mensen 3-6 maanden blijven steken op zo'n project zonder iets te kunnen doen als het zo slecht is. Dan lijkt me dat er grotere problemen binnen dat bedrijf zijn.
Ik zou willen dat ik het zelf zo kon beslissen, maar zo werkt het niet in grote multinationals. Je krijgt de mensen en daar moet je het mee doen. Omdat het team hier met de shit zit lossen we het probleem dan maar gewoon zelf op.

De managers op hoger niveaus kijken alleen naar opex reductie. En naar de groene, oranje en rode kleurtjes in een sheet.
 
Maar in uw DoD zitten toch sowieso unit tests? Die werken niet als uw code niet compileert he...

Slecht geschreven code, dat gaat van het bedrijf afhangen, je hebt (Net als hier) inderdaad consultancy bureaus die mensen een opleiding van 5 dagen geven en ze dan expert noemen...

Ik heb zowel mijn beste als mijn slechtste collega's uit India gehad.
 
Bij ons zijn de Indiërs toch ook om te huilen hoor. Allemaal buitenlanders, en er is maar 1 soort die systematisch alles verkloot, tenzij het apenwerk is wat een 3 jarig kind ook kan.
 
Alleen bij Telenet even in aanraking gekomen met Indiërs en dat was een ramp.

Van mensen bij KBC ook geen positieve verhalen gehoord ivm samenwerking met Indiërs, idem met bpost
 
Alleen bij Telenet even in aanraking gekomen met Indiërs en dat was een ramp.

Van mensen bij KBC ook geen positieve verhalen gehoord ivm samenwerking met Indiërs, idem met bpost
Hangt er gewoon enorm van af wie je hebt. Ik heb daar ook heel goeie gezien (die ondertussen gewoon een vaste job in NL hebben trouwens)
 
@anders.
Ik vind het niet helemaal correct om te roepen dat we niet open staan. Als ik voor mijn eigen spreek, ik vind het heel tof en leerzaam om met mensen te werken die aan de andere kant van de planeet leven en een totaal andere cultuur hebben. Maar na 3 projecten (in feite 4) viel het me gewoon op dat ik totaal geen positieve WERKERVARING mee heb. Ik zet dit in drukletters want ik vond het wel altijd leuk werken met hun.

@Mountain-Djinn
Probleem met code reviews en dergelijke is dat het enkel nuttig is (al thans in mijn ogen) als je over mensen beschikt van een bepaald niveau. Ideaal zou zijn, je doet een code review van een junior je merkt wat dingen op, je schrijft erbij waarom en hoe ze dat kunnen verbeteren en normaal zou die zijn plan kunnen trekken. Tot nu toe is het mij opgevallen dat het bij mij een ping pong verhaal is geworden (en dit heb ik niet uit één ervaring). Ik schrijf wat review comments en ze maken totaal andere fouten. Dan doe ik dat weer en dat maken ze weer een hele hoop andere fouten, alsof ze niet leren (wat niet waar is maar....)

Alle ik wil hier nu niet mijn gelijk halen maar ik denk dat het ook belangrijk is om naar andere mensen hun ervaringen te luisteren want ik merk dat uw ervaringen als die van @anders. helemaal anders zijn als die van mij en dat is niet erg, daarmee dat ik deze topic ook gemaakt heb. En dat is ook goed want ik was in feite op zoek naar mensen die positieve ervaringen hebben en die kunnen delen!


Nu ik heb ergens wel een beetje spijt dat ik nu echt Indische bedrijven viseer, een bedrijf waar ik ooit voor werkte had ook zo eens slechte ervaring met een Vietnamees bedrijf. Maar dat was maar één keer dat ik zoiets hoorde. Dus voor al onze Indische vrienden of mensen met Indische roots mijn excuses wat niet de bedoeling! 😅
 
Ja, mijn reactie was niet specifiek op mensen hier hoor, eerder naar mijn ervaringen die ik hoorde bij andere collega's. Naar mijn ervaring verandert heel die samenwerking enorm als je ze persoonlijk leert kennen.
Mijn eerste projectmanager was ook een Indiër die al 12 jaar in België woonde, dus die kon ook heel veel dingen uitleggen qua verschil in cultuur etc...
 
Ja, mijn reactie was niet specifiek op mensen hier hoor, eerder naar mijn ervaringen die ik hoorde bij andere collega's. Naar mijn ervaring verandert heel die samenwerking enorm als je ze persoonlijk leert kennen.
Mijn eerste projectmanager was ook een Indiër die al 12 jaar in België woonde, dus die kon ook heel veel dingen uitleggen qua verschil in cultuur etc...
Geen probleem, dat had ik niet door!

Ik moet wel toegeven dat ik jaren geleden met iemand heb gewerkt die uit India kwam en die hier al zeer lang woonde. En die gast was kei goed, geen developer maar project manager. Maar die regelde alles tot in de puntjes en die had ook de nodige people skills!
 
Terug
Bovenaan