Vraag naar ict-personeel groeit met 11 procent

Het aantal vacatures waarin gezocht wordt naar ict-personeel is in de eerste helft van dit jaar gestegen met 11 procent in vergelijking met dezelfde periode een jaar geleden. Vooral softwareontwikkelaars zouden gewild zijn.

Dat meldt Yacht, een wervingsbureau dat periodiek de arbeidsmarkt voor ict'ers onderzoekt. Volgens de onderzoekers is de vraag naar hoogopgeleide ict-specialisten, zoals managers, testers en projectmanagers, in de eerste helft van dit jaar opnieuw gestegen. Met name softwareontwikkelaars worden gezocht: Yacht telde meer dan 27.000 vacatures voor developers, een stijging van 11 procent ten opzichte van de eerste helft van 2013. Opvallend is de toegenomen vraag naar security managers: voor dergelijke functies steeg de vraag maar liefst met 93,5 procent. Toch gaat het nog om circa 800 vacatures.

Volgens Yacht worden er steeds minder vaak grote ict-projecten gestart om de kosten beter in de hand te krijgen. Bedrijven zouden steeds vaker kiezen voor kleinere projecten omdat deze beheersbaarder en wendbaarder zijn. Daarbij wordt vaak gewerkt met agile-softwareontwikkeling op basis van bijvoorbeeld Scrum. Hierdoor is de toegenomen vraag naar ict-managers van 23 procent volgens de onderzoekers te verklaren: zij moeten dergelijke projecten in goede banen leiden.

Nederland ICT stelde in mei in zijn jaarlijkse ICT Marktmonitor nog dat het verwacht dat de vraag naar ict'ers in de komende vijf jaar met achttien procent zal toenemen. Daardoor zal de vraag groter zijn dan het aanbod.

Reacties (209)

[Croga]

Daarbij wordt vaak gewerkt met agile-softwareontwikkeling op basis van bijvoorbeeld Scrum. Hierdoor is de toegenomen vraag naar ict-managers van 23 procent volgens de onderzoekers te verklaren: zij moeten dergelijke projecten in goede banen leiden.

En daarmee blijkt maar weer hoe enorm veel "Agile in name only" er gedaan wordt....
Implementatie van Agile stap 1: Ontsla alle managers!

Managers hebben in Agile geen rol. Managers die Agile in goede banen leiden is dan ook een contradiction in terminus. Managers leiden Agile de afgrond in. Coaches kunnen de teams helpen om Agile in goede banen te leiden, managers moet je daar uit de buurt houden!

[Vengeful]

Ik dacht precies hetzelfde. Aangezien in Agile alle de gehele planning in handen is van het uitvoerende team, is daar al meteen geen ruimte meer voor een manager. Aangezien teams niet alleen zelfsturend zijn, maar ook de commitment aan een product doen, is er ook geen ruimte meer voor een manager om met de eer te strijken, want het succes (en het falen) is altijd de verantwoordelijkheid van het team. In deze houdt zelfsturend ook in, als er een teamlid is wat om de een of andere reden niet mee kan komen met de rest van het team (moeilijk in de samenwerking, lui, of gewoon niet goed genoeg) kan het team zelf tot de conclusie komen dat het beter is als desbetreffende persoon het team gaat verlaten. Weer geen manager voor nodig.

En nee, de Scrummaster is geen manager. Hij helpt om het Scrumproces in goede banen te leiden, niet om een project of groep mensen te managen.

Short; short version: Scrum rocks.

[MBV]

En wie doet dan resource management, oftewel: resources verdelen over de scrum-teams die aan verschillende projecten werken? Wie coordineert de verschillende scrum-teams, en wie coordineert de architectuur? Alle managers eruit gooien lijkt mij wel erg ambitieus.

Ik heb bij een bedrijf gewerkt waarbij scrum zeker niet 'in name only' werd toegepast, en waar op een gegeven moment zeker 100 man in diverse scrum-teams aan een product werkten wat in een jaar af moest zijn. Dan komen alle slechte kanten van SCRUM naar boven: geen coordinatie tussen teams, code die elke 2 maanden gerefactored wordt van alternatief A naar B en weer terug, 'skip the requirements, just start writing code', enzovoort.

SCRUM kan goed gaan, als je developers van hoog niveau hebt, maar vooral als je goede Product Owners hebt. En die vervullen dan vaak weer de rol die een manager vroeger had. Ken jij een bedrijf, misschien met uitzondering van Prowareness, waar dat goed gaat?

Shor; short version: Scrum rocks, maar zet die roze bril wel af

[Reactie gewijzigd door MBV op 22 juli 2024 19:44]

[Vengeful]

Je werkte met met 100 man aan een product wat in een jaar af moest zijn? Dus, vaste deadline voorbij het einde van de sprint? Dat is dus wel degelijk scrum in name only.

En ja, resourcemanagement heb je tot op zekere hoogte nog wel nodig, maar dat is slechts een van de legio managementrollen die je traditioneel gezien nodig zou hebben.

Even simpel gezegd, dat je SCRUM ruk implementeert, is niet de fout van het framework. Iedereen die denkt dat je code iets kunt gaan bouwen zonder requirements is een (excuse my french) gigantische flapdrol. Hoe kun je ooit een tevreden klant krijgen als je geen requirements hebt? Is er geen coordinatie tussen teams? Dat had na de eerste sprint al duidelijk moeten zijn, laat staan de tweede of derde. Waar heb je de scrum of scrums voor? En als dat niet genoeg is, zoek je een andere oplossing. Na elke sprint heb je een retrospective, daar kun je aangeven wat beter zou kunnen. Als een punt terug blijft komen, dan ga je toch actief een oplossing zoeken?

SCRUM kan goed gaan als iedereen de mindset heeft. Er zijn stapels goede developers die je absoluut niet in een SCRUM-team kan plaatsen en er zijn stapels minder ervaren mensen die daar goed functioneren. Tuurlijk, ervaren developers hebben vaak een hogere velocity, maar ervaring doe je op door te doen.

Short, short version: Ook zonder roze bril rockt scrum, maar je moet wel meerocken

[Croga]

En ja, resourcemanagement heb je tot op zekere hoogte nog wel nodig, maar dat is slechts een van de legio managementrollen die je traditioneel gezien nodig zou hebben.

Nuhhuh! Er is een Product Owner die kijkt hoeveel geld er naar buiten zou mogen vloeien en daarvoor de mensen inhuurt. En dat is precies waar het op houdt. Er is géén "resource" management in Scrum. Er is een team. Dat team wordt aan het begin opgezet en daarna verandert het niet meer van samenstelling! Doe je dat wel dan heeft de historie van de velocity geen enkele waarde meer en gooi je het belangrijkste onderdeel van Scrum (voorspelbaarheid) overboord.

[Vengeful]

Hiero, nou, I stand corrected. Dus, de Product Owner is een nog drukker baasje dan ik al dacht.

Bedankt voor de info trouwens, dit was iets wat ik in de praktijk nog niet geimplementeerd heb gezien.

[Croga]

Hiero, nou, I stand corrected. Dus, de Product Owner is een nog drukker baasje dan ik al dacht.

Yip.... Vandaar ook dat de Product Owner normaliter ondersteund wordt door een team specialisten. En vandaar ook dat de rol Product Owner het grootste probleem is van de meeste scrum implementaties

[MBV]

Welcome to the real world: zo nu en dan komt er een klant langs bij een bedrijf in de embedded software die zegt: als jullie dat-en-dat over een jaar afhebben krijgen jullie een grote zak met geld, hoe je dat organiseert moet je zelf weten.

SCRUM in name only doet wel wat te kort aan de situatie waar ik naar keek: het leek nog vrij veel op scrum, en er was ook een scrum of scrums. Scrum in name only denk ik eerder aan de opdracht waarbij de manager scrum invoerde om te zien hoeveel progressie er was, waarbij hij elke dag zei dat dat ene briefje toch belangrijker is dan die andere, of aan de opdracht waarbij elk briefje wordt toegewezen aan 1 persoon en de sprints 2 maanden duren.

[Croga]

En wie doet dan resource management, oftewel: resources verdelen over de scrum-teams die aan verschillende projecten werken?

Resources verdelen doe je zowieso niet. Binnen Agile werken we om te beginnen met Mensen, niet met resources. Daarnaast zet je een team op en daarna blijf je er met je klauwen van af, iets waar Managers heel slecht in zijn.

Wie coordineert de verschillende scrum-teams

De Scrum of Scrums. Dat is zelf organiserend en heb je geen manager voor nodig.
Oh, en natuurlijk de Product Owner die zorgt dat het werk verdeelt wordt op een manier die zorgt dat er zo min mogelijk afhankelijkheden en dus zo min mogelijk coördinatie nodig is.

en wie coordineert de architectuur?

De Architectuur chapter. Daar heb je geen manager voor nodig.

Ik heb bij een bedrijf gewerkt waarbij scrum zeker niet 'in name only' werd toegepast, en waar op een gegeven moment zeker 100 man in diverse scrum-teams aan een product werkten wat in een jaar af moest zijn. Dan komen alle slechte kanten van SCRUM naar boven: geen coordinatie tussen teams, code die elke 2 maanden gerefactored wordt van alternatief A naar B en weer terug, 'skip the requirements, just start writing code', enzovoort.

Daar komt de slechte kant van een slechte scrum inderdaad naar boven.
- Skip de requirements is een teken van slechte scrum
- Geen coördinatie is een teken van slechte scrum
- Een product wat "in een jaar af moet zijn" is een teken van slechte scrum
Het spijt me je illusie te moeten breken maar je werkte wél bij een bedrijf wat Scrum in name only geimplementeerd had.

SCRUM kan goed gaan, als je developers van hoog niveau hebt, maar vooral als je goede Product Owners hebt. En die vervullen dan vaak weer de rol die een manager vroeger had. Ken jij een bedrijf, misschien met uitzondering van Prowareness, waar dat goed gaat?

Ik ken heel veel bedrijven waar het net niet goed gaat. Ik ken heel veel bedrijven die de voornoemde Scrum coach nog nodig hebben. Ik ken geen enkel bedrijf waar managers iets zinvols toevoegen aan Scrum.

[Reactie gewijzigd door Croga op 22 juli 2024 19:44]

[reinouts]

Bij Mendix loopt dat anders aardig goed.

Disclaimer: ja daar werk ik.

[QQ2]

Sorry maar als een manager inderdaad alleen die dingen doet moet je als bedrijf eens goed achter de oren krabben.

Laatste keer dat ik Scrum master was was ik maar wat blij met de project manager die zaken regelde als: Project finance, end user training en het hele bredere roll out en support plaatje,stakeholder management, organisatorische impedements weg nemen etc etc

Een software project is meer dan alleen de software schrijven. Voor dat laatste is scrum geschikt,voor de rest heb je toch echt een goede manager (en veel verschillende andere teams) nodig

[Croga]

Wat jij daar als "Project Manager" omschrijft is de taak van de Product Owner. Dat is de enige die in staat is te overzien wat de gevolgen van al die dingen zijn.

Dus nee, ook daar wil je geen Manager hebben!

[BoringDay]

De managers zorgen er anders wel voor dat er genoeg werk is en nemen taken op zich die je als ontwikkelaar zelf er niet bij wil hebben. En als het goed is dan is de manager part of the team. Professioneel programmeren is niet alleen maar code kloppen er komt veel en veel meer bij kijken.

[Reactie gewijzigd door BoringDay op 22 juli 2024 19:44]

[Croga]

Zorgen dat er genoeg werk is: Product Owner. Geen Manager voor nodig.
Taken die je als ontwikkelaar niet bij wilt hebben: Product Owner of Scrum Master. Geen Manager voor nodig.

De oude wereld is zo enorm lastig los te laten.... Maar probeer het eens. Ga nou eens analyseren welk werk een Manager doet wat daadwerkelijk waarde oplevert, wat niet door de rollen in Scrum gedekt is.... (okay, okay, de Product Owner rol moet wel heel erg veel doen volgens Scrum maar dan nog is er geen Management nodig.)

[BoringDay]

Ik hou van plain & simpel en niet zo van al die vak termen die uiteindelijk weinig zeggend zijn.

Als heb het even op gezocht:
- Product owner: betalende klant;
- Ontwikkel team;
- Scrum master: het loop jongetje van de ontwikkelaars;

Kijk het komt allemaal op het zelfde neer, niks bijzonders en al die termen heb je niks aan. Het staat leuk op papier en thats it!

[Croga]

Jij houdt van plain en simpel. Mooi. Scrum is simpel! Managers zijn dat niet.

Je hebt al gespot dat Scrum maar 3 rollen kent. En zoals je gemerkt hebt zit daar geen Manager bij. Die is namelijk niet nodig. Je beschrijving van de rollen is niet helemaal correct (een Product Owner is zeker geen betalende klant! Een Scrum Master is zeker geen loopjongen) maar je zit dicht bij de kern. Dan zou het je dus ook duidelijk moeten zijn dat Managers hier geen rol in hebben.....

[BoringDay]

Als scrum maar 3 rollen kent ga ik toch behoorlijk twijfels krijgen over de kwaliteit van de ontwikkeling en het niveau.

[Croga]

Als iemand meer dan 3 rollen nodig heeft binnen software ontwikkeling ga ik sterk twijfelen....nee... wacht.... we doen het al jaren met meer dan 3 rollen en Het Werkt Niet. Ik hoef niet te twijfelen, alle cijfers wijzen uit dat scheiding van taken contraproductief werkt als het gaat om complexe processen.

[BoringDay]

Contra productief?
Een goed fundament is op langer termijn altijd minder werk en zorgt voor nettere code. Je kan beter iets goed doen en er 3 weken langer over doen dan er een slap aftreksel ervan maken.

Spaghetti code en afhankelijkheden moet je vermijden en leuk al die cijfers maar die vind ik niet spannend. Een goed product is belangrijker dan zo productief mogelijk. Soms moet je er gewoon eenmaal de tijd er voor nemen.

[Reactie gewijzigd door BoringDay op 22 juli 2024 19:44]

[Croga]

Errr... ik heb geen flauw idee wat je relaas met scheiding van taken te maken heeft... Nog sterker: Scheiding van taken zorgt voor spaghetti code, combineren van taken zorgt voor nettere code.

Zo productief mogelijk gaat niet zonder een net product. Nog sterker: Scrum heeft dat geformaliseerd. In tegenstelling tot andere methodes is kwaliteit de enige constante in Scrum: Alles wat afwijkt van nette, foutloze code wordt automatisch een probleem van het team.

[BoringDay]

Er staat niks vermeld over scheiding van taken dat tot spaghetti code leidt. Wat ik zeg je moet extra veel aandacht aan het fundament besteden zodat die flexibel en consistent is en dat betekent dat je al in het begin stadium ook rekening moet houden met bepaalde details die later in het traject een grote rol gaan spelen.

[Eminus]

amen..

[Falcon10]

Prijzen van IT'ers zijn ook belachelijk hier !
Bijna 550 ex BTW voor een junior engineer per dag !
Ik als ZZP'er ( doe projecten en manusje van alles bij klant ), kom nog niet eens aan dat bedrag per dag. Als ik project management bij diezelfde consultingfirma vraag, ben ik zelfs dik 1000 euro ex BTW kwijt !

Tevens zijn de vacatures van veel firmas gewoon niet realistisch.
Men wil een java developer, die ook nog een goede kennis heeft van Linux serverbeheer, en liefst ook nog met een Cisco Certified Network Architect diplomatje ofzo. Is beetje overdreven, maar daar kotm het soms bijna op neer he.

[janwillemCA]

Volgensmij is dat laatste niet heel erg gek. Stel je bent een C of C++ developer in de Embedded kant. Dan is het toch ook niet zo gek dat je kennis moet hebben van bijv: Linux, Embedded Linux? En dat je dan ook kennis moet hebben van bijv de TCP/IP stack?
Volgensmij is die extra kennis alleen maar wenselijk

[Reactie gewijzigd door janwillemCA op 22 juli 2024 19:44]

[codebeat]

Is wenselijk ook noodzakelijk dan? Het lijkt er wel op dat je tegenwoordig er niets meer bij kan leren. Het is allemaal zo specs gerelateerd tegenwoordig.

[Reactie gewijzigd door codebeat op 22 juli 2024 19:44]

[hackerhater]

550 exc btw. dat is inderdaad te hoog voor een junior (68/uur). Voor een medior/senior zou het een goed bedrag zijn.

Als mensen mij inhuren komen ze ook makkelijk aan dat bedrag. Ik weet niet wat voor lage uurlonen jij dan hebt? Als de overheid een niet de helft van dat bedrag zou inpikken...........

[RuudVisser]

Inderdaad, geleuter. Komt meestal van personen die niet iets toevoegen aan het produktieproces van de IT. Managers en personeelswervers herkennen goede IT'ers niet zelfs als de nog nieuwe te bouwen ruimtetelescoop in Chili erop gericht zou zijn. Omdat ze in het geheel niet weten waar ze het over hebben. Welnu, dan maar Agile, Lean en Scrum. Niet gehinderd door ook maar enige kennis van zaken.

[Aardwolf]

Amen! Alleen vraag ik me af of dit niet in algemene zin zo is. Het is natuurlijk prachtig als een manager wat verdiepend weet, maar hoe vaak is dat werkelijk zo? Volgens mij kan dat procentueel op 1 hand tellen, in elk vakgebied wel.

[Verwijderd]

"Zeg jongeman, je hebt deze taak voorheen geschat op 60 uur. Als we nu die taak Agile gaan doen, dan kunnen we hem in 30 uur doen, toch?"

Zoiets?

[arjankoole]

zelfs als de nog nieuwe te bouwen ruimtetelescoop in Chili erop gericht zou zijn.

open deur: iets met line of sight

on-topic: je hebt gelijk, er zijn gelukkig uitzonderingen, en die heb ik meegemaakt. Dat zegt nog lang niet alles, maar het helpt al een boel.

[codebeat]

Laatst nog gesolliciteerd. Technisch was ik helemaal prima (nog zo'n test gedaan) maar wist niets van SCRUM. Je raadt het al, ben het niet geworden. De commercie verschuift richting de ontwikkelafdeling, heeft niets meer met het beroep programmeur te maken. Bezopen, nu ben ik technisch uitstekend maar uitgerangeerd omdat ik niet op de hoogte ben van SCRUM, althans niet gebruik. Waar gaat het over zeg, het gaat alleen om output te genereren te gunste van de omzet.

Je moet al zoveel weten voor deze functie. ICT-managers verdienen meer en weten minder waardoor er allerlei regeltjes worden opgesteld zodat deze managers het hoofd boven water kunnen houden. Een manager snapt niets van de programmeur met passie voor het vak (omdat de manager niet weet wat het gevoel is).

Ben geen voorstander van deze methodiekgekte, dit verhaal ondersteund mijn gevoel:
http://www.projectpro.com/letters/MethodologyMadness.htm

Dus ja, kan het wel groeien maar als het alleen maar van die lopende band functies worden.... Wanneer deze trend zich blijft voortzetten zie ik het voor mijzelf somber in. Daar gaat je jaren technische ervaring, het is niets meer waard. Bestaat het straks alleen maar uit trendy hippe jojo's.

[Reactie gewijzigd door codebeat op 22 juli 2024 19:44]

[Vengeful]

Het spijt me, maar dat stukje is geschreven door een zure ontwikkelaar die echt geen enkel benul heeft waar hij over praat. Het meest opvallende is wel het wanneer hij zegt dat ze in SCRUM tijdens de sprint gewoon al het werk omgooien omdat de requirements veranderd zijn. Dat is een leugen, en een grove ook nog. Je commit aan stories als je de sprint begint, als die stories wijzigen is je commitment waardeloos, want er zal opnieuw gepland, ontworpen, gecodeerd en getest moeten worden. Voordat een sprint begint worden de stories goedgekeurd en die worden gebouwd zoals ze goedgekeurd zijn. Als binnen twee weken de gebruiker ineens wat anders wil, mogen ze wachten tot de sprint over is en er een nieuwe gaat beginnen. Krijg je de change de volgende sprint. En als dat keer op keer gebeurt, heb je een probleem met de gebruiker, niet met de methodiek. En met zulke gebruikers wil je absoluut geen watervaltraject ingaan. Die zeggen dat ze graag een Ford Focus willen, maar bedoelen eigenlijk een broodje kaas met geintegreerde grafische chip. Lachen man, als je na drie jaar met je auto aankomt. Deze meneer denkt dan vast dat de klant met waterval wel tevreden was geweest.

Ik snap je frustratie wel. Als er ergens SCRUM echt word toegepast, heeft dat impact op de organisatie. En het ligt je of het ligt je niet. De mensen die er een positieve ervaring mee hebben, zijn er vaak ook echt enthousiast over. Als zij de keuze hebben tussen iemand die niet weet wat SCRUM is en iemand die de functie wil hebben juist omdat het SCRUM is, dan zal de laatste gewoon beter in de organisatie passen.

[codebeat]

Ik hoop niet dat je mij als zure ontwikkelaar bestempeld en refereert naar het stuk achter de link. Ik zie wisselde verhalen, (overdreven) positief en behoorlijk negatief. Kan ook nergens een klanttevredenheidsonderzoek vinden bijvoorbeeld.

Je schrijft:

Als binnen twee weken de gebruiker ineens wat anders wil, mogen ze wachten tot de sprint over is en er een nieuwe gaat beginnen. Krijg je de change de volgende sprint. En als dat keer op keer gebeurt, heb je een probleem met de gebruiker, niet met de methodiek.

Kijk dat is nu precies wat ik bedoel, het probleem wordt nu bij de klant gelegd zoals jij aangeeft want het is niet de schuld van de methodiek. Dat is makkelijk, je geeft de klant de schuld, jij bent toch de professional met verstand van zaken? Je had het ook NIET kunnen doen bij twijfel. Nu heb je dus een traject opgestart waarvan je mogelijk kon weten dat het niet vruchtbaar zou zijn en dat de klant geld kost, dan uiteindelijk is de klant nog de schuldige ook. Maar ja, nu is er iets opgeleverd en kun je als softwarebureau toch cashen en valt je als bureau juridisch niets te verwijten omdat er een prestatie is geleverd.

Wat hou je dan over? Een tevreden klant? Denk meer een klant die zich belazerd voelt. Het is erg Amerikaans om over lijken te gaan om geld te verdienen. Ik hou er niet van, het gaat dus meer om het produceren en dus geld verdienen. Het is niet erg om geld te verdienen maar niet ten koste van.

[Reactie gewijzigd door codebeat op 22 juli 2024 19:44]

[Vengeful]

Nee, de schrijver was de zure ontwikkelaar.

Soms ligt het probleem ook bij de klant. En dat is geen verantwoordelijkheid afschuiven, daar hebben we waterval voor (hoe denk je dat de overheid het stelselmatig voor elkaar krijgt om tientallen miljoenen in een project te stoppen en daar niks aan over te houden?) In SCRUM ga je, wanneer je tot de conclusie komt dat de klant het probleem is, de klant opleiden. Je helpt ze om uit te zoeken wat ze nodig hebben. En dat gaat een stuk sneller dan met Waterval. Waarom? De hoeveelheid contactmomenten met je klant, na elke sprint heb je de demo om aan te tonen wat je hebt opgeleverd. Wat je hebt opgeleverd hoort nuttig te zijn voor de klant. Als het niet nuttig is, ga je kijken wat er mis is gegaan om te zorgen dat het niet nog een keer gebeurt. Als ontwikkelaar, tester, analist binnen SCRUM word je constant geconfronteerd met degene die jouw werk moet gaan gebruiken, dan wil je niks anders dan die persoon iets leveren waar hij of zij wat aan heeft. Verder heb je in SCRUM ook gewoon te maken met voortschrijdend inzicht. Requirements kunnen verschuiven, dat is nu eenmaal de realiteit. In waterval komt dat er op neer dat er nog een jaar extra gewerkt moet worden om alles in het originele ontwerp om te gooien. In SCRUM kun je dat werk na een paar sprints gewoon oppakken, dus de klant heeft veel sneller resultaat.

Hoe je een tevreden klant krijgt is heel simpel, door met de klant te werken in plaats van voor de klant. Hij heeft wensen, maar hij heeft ook hulp nodig. Betrek ze bij je proces, laat ze zien wat goed gaat, maar hou ze ook op de hoogte van wat niet goed gaat. Is er een probleem waardoor je oplevering in gevaar komt? Dan vertel je dat METEEN aan de Product Owner (dat is de klant). Het aantal keren dat ik non-agile heb gewerkt en een kwartier voor oplevering kreeg te horen dat het een maand later opgeleverd (of erger, niet, omdat hun interne prioriteiten waren veranderd) zou worden is niet meer te tellen onderhand. Je kunt met SCRUM maar beter een verdomd goede reden hebben om de klant niet te geven wat ie wil, want als SCRUM-team ben je eindverantwoordelijk voor wat je oplevert. Geen Manager die de kolen uit het vuur gaat halen, maar de mensen die het werk doen zijn verantwoordelijk.

En als je klant zich belazerd voelt? Dan pleurt ie je er na de sprint uit, in plaats van een jaar later. Dat bespaart dan in elk geval maanden kosten voor iets wat ie niet wil hebben.

[BoringDay]

Je moet de klant nooit als een probleem zien en ook nooit daar het probleem neerleggen. Zorg ervoor dat je de klant hebt goed begrepen door terugkoppeling. Bel de klant desnoods tijdens het ontwikkelen als je vragen hebt. Lijkt me sterk dat je dan pas na twee weken erachter komt dat je iets maakt wat de klant niet wil.

Maar daar hebben we helemaal termen als Scrum voor nodig want het is al vanzelf sprekend.

[Reactie gewijzigd door BoringDay op 22 juli 2024 19:44]

[Willybubba]

Wat Scrum doet heeft niks met geen requirements oid te maken. Binnen het Scrum proces worden je requirements voor elke sprint juist heel strak omkaderd, en als er zaken bijkomen dan zullen er andere zaken afvallen, of gaan die mee met een volgende sprint.

Het is wel degelijk zo dat je de klant kan aanspreken als ze zaken missen: je geeft na elke sprint (bij mij 2 weken) weken een demo (en liefst zet je ook elke 2 weken iets live). Bij elke demo zit "de klant" ook. En als je het dan nog voor elkaar krijgt om iets te bouwen wat de klant niet wil dan heeft 'ie niet op zitten letten.

Scrum: Epic -- lange termijn plan, vaag omkaderd. Sprint -- korte termijn, strak omkaderd plan.

Scrum is eigenlijk niks meer dan een opeenvolging van korte projectjes. En het werkt, kost ook stukken minder dan de grote monoliet projecten van vroeger. En ik ben nog wel een beheerder!

[codebeat]

Ah, okay. Kun je mij aangeven hoe zo eerste gesprek verloopt dan? Ik kan mij daar helemaal niets bij voorstellen namelijk wat daar dan zo anders aan moet zijn. Ik kan uit een eerste gesprek heel veel informatie te weten krijgen en dan kan ik ook zo zien of het zin heeft. Bijvoorbeeld als iemand echt niet weet wat ie wil (dat merk je snel genoeg) dan begin ik er vaak niet eens aan.

Het is net als een bedrijfsauto kopen. Iemand die zich laat informeren koopt vaak niets en iemand die zich heeft 'laten' informeren (internet, concurrenten etc) heeft een beter idee wat hij of zij wil. In het laatste voorbeeld is de persoon al verder 'in het traject' om het zo maar even te zeggen, heeft een beter beeld.

Ik kan mij niet voorstellen dat er op voorhand niet inhoudelijk over de opdracht gesproken wordt. Dus hoe verloopt dat dan?

Nog iets. Hoeveel tijd is een programmeur bezig met rapportage, meetings e.d. in procenten. Hoe zit het met de creativiteit en het toepassen van oplossingen. Worden alleen de dingen gemaakt die nodig zijn zodat uitbreidingen meerwerk is en worden er nog bibliotheken aangelegd en/of gebruikt?

[Reactie gewijzigd door codebeat op 22 juli 2024 19:44]

[Dennis van der Stelt]

Dat zijn een heleboel vragen

- Hoe verloopt een eerste gesprek
Dat is afhankelijk van de situatie. Ik heb het geluk de laatste jaren enkel met interne klanten te werken. M.a.w. afdelingen binnen het bedrijf waar ik werk. Die weten over het algemeen waar ze het over hebben en wat ze willen, maar zelfs dan zitten ze vaak 80% naast wat we uiteindelijk opleveren. Buiten het feit of ze weten wat ze willen of niet, moet er ook altijd nog besloten worden of het überhaupt gemaakt gaat worden. En als ze niet weten wat ze willen, kun je ze zéér zeker terug sturen.

In Scrum komen product owners eigenlijk altijd vanuit de klant. Hier heb ik zelf heel veel moeite mee, omdat die vaak geen product owner training hebben gehad en niet weten wat er van ze verwacht wordt. Hebben ze die wel gehad, is het vaak nog steeds moeilijk en moet je hier ervaring mee krijgen. Een product owner zijn/haar taak is het om informatie te verzamelen bij verschillende personen. Het liefst werk ik met product owners die weten dat ze eind-verantwoordelijk zijn voor het product, én weten hoeveel invloed ze hebben. Ze kunnen beslissingen nemen om bepaalde zaken helemaal te laten vallen. Uiteraard doen ze dit niet zomaar, maar kunnen ze beargumenteren waarom dit zo gebeurd.

Wat je ook vaak ziet is dat product owners hun werk niet goed doen. Het ERGSTE wat je dan als developer of team kunt doen, is gaan raden wat er verwacht wordt en maar aan de slag gaan. Dat betekent dat het de developers aangerekend wordt als er iets fout gaat, ipv de product owner. Daarnaast zal de product owner nooit zijn werk goed gaan doen. Een product owner zijn kost veel tijd. De meeste mensen besteden hier niet veel tijd aan, omdat ze hun eigen werk belangrijker vinden. Heel simpel, ga zitten gamen of ga naar huis. Laat management maar boos worden en zeg dat je niet wéét wat je moet bouwen en geen zin hebt om 6 weken van je baas z'n tijd te verspillen aan iets wat achteraf toch niet of anders gebouwd had moeten worden.

Ik kan mij niet voorstellen dat er op voorhand niet inhoudelijk over de opdracht gesproken wordt. Dus hoe verloopt dat dan?

Er wordt ALTIJD inhoudelijk gesproken. Anders stap je op uit de meeting en ga je aan je werk!

Hoeveel tijd is een programmeur bezig met rapportage, meetings e.d. in procenten.

Zo weinig mogelijk. Liever werkbare software, dan veel documentatie. Betekent niet dat er geen documentatie is, maar wat heb je aan veel documentatie, maar geen software?

Je hebt niet voor niets index-cards (kleine kaartjes) met een simpele beschrijving van wat er moet gebeuren. Het verschuiven van die kaartjes over het bord (ik werk eraan, ik ben ermee klaar) is de rapportage. Betere rapportage bestaat niet!!!

Hoe zit het met de creativiteit en het toepassen van oplossingen.

Daar wordt véél meer aandacht aan besteed binnen Scrum, dan dat jij tot nu toe ooit in je leven gedaan hebt.

Worden alleen de dingen gemaakt die nodig zijn zodat uitbreidingen meerwerk is

JA!!!

Eérst de dingen die 'business value' opleveren. Niet eerst wat PersoonA leuk vind, of wat developers denken dat nodig is. Maar wat BUSINESS VALUE oplevert. Dan zul je zien dat wat 'vroeger' als meerwerk gekenmerkt werd, nu al gebouwd is vóórdat het project klaar is. En dat dingen die nu als meerwerk gekenmerkt zouden kunnen worden, ineens helemaal niet nodig zijn. In de ideale gevallen plan je met een klant 6 maanden werk in, ben je na 4 maanden klaar met 60% van alle features gebouwd en heeft de klant besloten dat de overige 40% niet nodig is. Als je slim bent, spreek je dan fixed price af met een klant voor 6 maanden en zeg je, dat als je eerder klaar bent, de klant 50% van de kosten betaald. Dan krijg je dus 1 maand extra betaald terwijl alle developers al naar een andere klus kunnen!

[codebeat]

Aha, dat is duidelijke taal Dennis! Bedankt! Kijk, ik werk veel met bibliotheken en leg deze ook aan zodat ik niet steeds het wiel opnieuw hoef uit te vinden. Wat is de positie van bibliotheken binnen het geheel, het gebruik van een framework en dergelijke. Hoeveel aandacht wordt daaraan besteedt?

Je geeft aan dat alleen dingen worden gebouwd die nodig zijn maar betekend dat dan dat er geen rekening wordt gehouden met eventuele uitbreidingen. Wanneer je gebruik maakt van een bibliotheek is het vrij eenvoudig om dingen toe te voegen maar waarbij je niet de hele code niet opnieuw hoeft te schrijven wanneer je dat al een keer hebt gedaan. Wanneer je iedere keer het wiel opnieuw moet definiëren lijkt mij dat niet heel efficiënt. Buiten dat vergroot het dan ook de kans op fouten (bugs). Een Bibliotheek is een solide basis.

Hoe flexibel is de opzet van een project. Word het helemaal vanaf scratch af aan opgezet of maakt men gebruik van bibliotheken?

[Dennis van der Stelt]

Alles binnen Agile (Scrum, XP, etc) zegt zo'n beetje dat je de toekomst niet kunt voorspellen. Dus als je het de eerste keer bouwt, ga er niet vanuit dat je de ideale oplossing bouwt. Want morgen komt er een feature request vanuit de business, die niemand kon voorzien, waardoor jij je zojuist gebouwde library volledig om moet gooien.

Dat was dan beetje zonde van de tijd. Vandaar dat je het eerst normaal bouwt en als je het nog een keer nodig hebt, kun je er iets slimmers van maken. Dat ligt volledig bij de developers. De developers leveren een schatting af, waarbij developers kunnen meenemen dat de library gebouwd moet worden.

Dat is een heel lastig punt, vooral als je product owners en/of managers hebt die inmiddels door hebben hoe snel je iets bouwt. Wat je veelal ziet bij werkgevers is dat ze douwen, douwen, douwen om iets af te hebben. Ik heb meegemaakt in de detachering dat ik 75% bovenop mijn eigen schattingen legde, omdat ik wist dat ze de schatting gingen halveren. Dat kan natuurlijk niet.

Als er vertrouwen onderling is, bepalen de developers wanneer een dergelijke library gebouwd wordt en hoe ver. Je kunt ook een deel van de library implementeren, maar sommige nice-to-have features in je library later toevoegen in een andere user story. Zo voorkom je dat een story (een feature) die normaal een halve dag bouwen in beslag neemt, niet uitloopt naar een week, omdat je een library moet bouwen. Een ander alternatief is dat je een team opzet van een klein aantal mensen die een dergelijke library bouwt. Hoewel ik daar niet zo gecharmeerd van ben, om meerdere redenen.

Nogmaals, het vertrouwen is nodig. De business en management moeten wat toegeven in bouwtijd. Als development bewijst dat ze hard werken en nette features opleveren waar de business om gevraagd heeft (meeste business value bouw je eerst) dan worden ze snel meer tevreden en gunnen ze weer wat terug. Zo groeit het vertrouwen dat developers doen wat het beste voor de business is.

Vooral als ze kwaliteit willen. Er zijn talloze studies en praktijk voorbeelden dat winst in korte termijn, enorme schuld opbouwt voor lange termijn. Hoeveel projecten ik niet heb zien vastlopen omdat er in het verleden verkeerde keuze's zijn gemaakt, ten behoeve van sneller opleveren van software. Daardoor worden alle schattingen automatisch 100% tot 200% hoger, door de technical debt.

Uiteraard is dit ook iets van vertrouwen en geven en nemen. Als business toegeeft om meer tijd aan kwaliteit te besteden, moeten developers op hun beurt leveren. Zélf ook voor kwaliteit gaan, code reviews, en af en toe crunchen om iets tóch op tijd af te hebben. Met een 9-5 mentaliteit kom je er dan niet. Maar op andere dagen betekent het juist dat je in de 9-5 werkt aan dingen die je wél leuk vindt, en vroeger wellicht niet had.

Zonder wederzijds vertrouwen kom je nergens.

[codebeat]

Dennis, weer hulde voor je heldere uiteenzetting. +3, kan het niet geven omdat het mijn eigen 'onderwerp' is.

De derde alinea van onder, "value versus kwaliteit versus duurzaamheid" klinkt mij heel bekend in de oren. Ik heb heel veel projecten gezien waarbij het hele project opnieuw moest worden opgezet/gebouwd omdat er in het verleden van alles inghacked is en waardoor het een onoverzichtelijke zooi is geworden. Vaak komen bij dit soort projecten ook hele rare bugs voor. Dus die value is wel leuk maar wat doet het op langer termijn.

Zeker omdat het traject onzeker is, "Hoe gaat het zich ontwikkelen in de toekomst" vind ik deze value aanpak eigenlijk zorgelijk. Want hoe vaak is niet gebleken dat na verloop van tijd verwachtingen worden bijgesteld en wanneer de code daarop niet berekend is kan dat tot grote problemen leiden. 90% van de websites is gelijkwaardig, het ziet er alleen wat anders uit dus waarom zou je dat niet standaardiseren? Dan wordt de opbouw van een project eenduidig, dat is herkenbaar door de programmeurs en zijn bugs gemakkelijker op te lossen ook al is het project wat ouder.

Met het value (korte termijn denken) ben je eigenlijk weer terug bij af. Vind het ook raar dat er wordt gesteld "wanneer men kwaliteit wil", je moet gewoon altijd kwaliteit willen. Kan hier dus uit afleiden dat het niet gaat om codekwaliteit maar om output. Wanneer het werkt dan is het goed ongeacht hoe het is opgezet. Dus qua productie en verdiensten is het wel kosteneffectief maar het zegt dus niets over de kwaliteit op langer termijn. Kan mij zo voorstellen dat er dubbele dingen voorkomen of eenvoudig niet efficiënt zijn opgezet met alle gevolgen van dien wanneer het project een langer leven krijgt.

Ik snap niet dat softwarebedrijven op langer termijn willen denken. Het kost in het begin wellicht iets meer tijd maar uiteindelijk haal het er dubbel en dwars uit. Dan kun je de uren die er normaal voor staan wel declareren terwijl je eerder klaar bent. Dan blijft er meer tijd over om te testen en/of meer aandacht te besteden aan nieuwe onderdelen of je kunt alvast beginnen aan een ander project. Tevens zorgen deze 'standaarden' binnen de organisatie voor meer stabiliteit (code dat op een gegeven moment uitontwikkeld is en uiterst stabiel is) waardoor je in staat bent snel te schakelen en het is van goede kwaliteit waardoor de vraag "als ze kwaliteit willen" eigenlijk er al niet meer toedoet omdat het altijd van goede kwaliteit is. Voorwaarde is natuurlijk wel dat het flexibel is opgezet en dat het eenvoudig in te passen is. Modulaire opzet dus.

Voorbeeld is een webshop. Heb eens een project gehad van een collega waar deze sublieme webshop in zat. Alleen was zo verweven in het project dat ik het niet kon gebruiken voor een ander project met het gevolg dat ik hele nieuwe webshop moest bouwen. Kijk, dat is zonde van de tijd want wanneer het modulair was opgezet had ik het kunnen gebruiken. Dan had het bij het modulair opzetten wel iets meer tijd gekost maar dat had je dus terug kunnen verdienen bij een tweede soortgelijk project. Dan had men dus de normale tijd dat het kost om te bouwen kunnen declareren terwijl het mij minder tijd kost om te implementeren.

Dat is ook geld verdienen maar op een andere manier, het gaat tenminste niet ten koste van de kwaliteit. Op deze manier blijft er dan genoeg tijd over voor 'leuke' en 'nieuwe' dingen te ontwikkelen terwijl de kwaliteit constant blijft.

De value strategie is begrijpelijk maar uit commercieel oogpunt en geld verdienen op kort termijn door dingen weg te laten. Dus niet uit het streven naar efficientie, het optimaliseren van de prodcuctielijn om het zo maar te zeggen.

Als mijn conclusie klopt ben ik bang dat SCRUM niet bij mij past. Het is te commercieel commercieel als je begrijpt wat ik bedoel.

[Reactie gewijzigd door codebeat op 22 juli 2024 19:44]

[Dennis van der Stelt]

Ik heb nooit de bedoeling gehad om te zeggen dat kiezen voor kwaliteit een optie is. Dat zegt geen enkele agile methodiek, ook Scrum niet.

Ik schrijf ook "Er zijn talloze studies en praktijk voorbeelden dat winst in korte termijn, enorme schuld opbouwt voor lange termijn."

Alleen zie ik twee dingen , waar ik het niet helemaal mee eens ben, als mensen dit aandragen.

kwaliteit
De business zal kwaliteit meestal geen steek uitmaken. Uiteraard kun je een product maken waar men jarenlang mee doet. Ik heb een werkgever gehad waar software na 10 jaar nog actief was. Dan is kwaliteit van essentieel belang en zal management toch overtuigd moeten worden om niet constant shortcuts te maken.

Aan de andere kant is het vaak de schuld van developers dat de business shortcuts neemt. Hoe vaak wordt er niet gevraagd : "Kan dit niet sneller?". En het antwoord is niet zwart wit, maar een developer zal het toch zo stellen. "Ik wil het niet sneller, maar het kán wel." Dat is veel te zwart wit. Het kan wel sneller, maar niet enkel en alleen door op kwaliteit van je code in te leveren. Het kan ook door features te versimpelen of volledig te schrappen. Het kan ook door zaken in fases op te leveren. Initieel iets simpels, heel snel opleveren. Daarna een volgende fase waarin een uitbreiding en tegelijk een verbeterslag komt.

Ik heb ook een werkgever meegemaakt die iets héél complex wilde. We hebben toen gewaarschuwd dat dit complex was, maar dat we 70% van zijn features in een maand volledig konden opleveren, met een eerste versie na 2 weken. Daarna bléven de wensen komen om 100% en wellicht zelfs meer te leveren. Dat duurde in totaal 8 maanden.
Het trieste is dat die werkgever enkel nog maar kon onthouden dat de gebouwde functionaliteit 8 maanden duurde en heeft dit veelvuldig gebruikt. 90% van alle werknemers zei hier niets van. Ik heb de CEO met interne en externe klanten keihard verteld (uiteraard wel beetje politiek correct ) dat er na 2 weken functionaliteit al live stond.

Moraal is dat werkgevers opgevoed dienen te worden. En soms negeer je ze gewoon en zeg je dat iets 4 weken duurt, ook al kan het in een week. Maar je wilt gewoon iets netjes opbouwen. Maar nogmaals, het is niet zwart/wit. Soms moet je water bij de wijn doen.

herbruik/modulair
Ik ben sterk mee oneens dat herbruik van modulair opgebouwde software haalbaar is. Uiteraard zul je copy-paste doen en ervaringen gebruiken uit vorige projecten. En Wordpress is ook herbruikbaar. Maar in het overgrote deel van de gevallen kun je een praktisch gelijkwaardige project doen, maar toch eigenlijk niets fatsoenlijk kunnen her-gebruiken. Dus daar zou ik weinig tot geen effort in steken.

Wil niet zeggen dat je niet modulair moet bouwen. :-)

Maar laat je vooral niet tegenhouden om Scrum te gebruiken. Scrum gaat je ook niet helpen software beter te bouwen, dat moet je zelf doen. Het gaat je (en daarbij management, etc) wel minimaal helpen om inzicht te geven en beter te kunnen plannen. Terwijl je als developer nog meer vrijheid krijgt om te bouwen zoals je het wilt. Het is alleen lastig om andere developers, projectleiders, management, etc. mee te krijgen.

Mooiste vind ik dat we vroeger waterval deden en projecten 6 tot 12 maanden duurden voordat de eerste oplevering komt. Tegenwoordig hoor ik vaak dat iteraties van 2 weken te lang duren. Maar ondertussen wil men wel waterval blijven doen. Af en toe vraag ik me af waar ICT naartoe gaat!

[BoringDay]

Grote projecten moet je groot uitdenken, dat red je niet binnen twee weken dan gaat er iets structureel mis. Daarbij mag je de netheid v.d. code en flexibiliteit niet uit het oog verliezen. En haastig spoed is zelden goed en dat komt heel vaak naar voren in een programmeer omgeving.

[Willybubba]

Je denkt ze ook groot uit. Althans, in grote lijnen. De details komen zodra je aan een bepaald stukje gaat werken.

[BoringDay]

En dan kom je achteraf ergens achter waar vooraf bepaald had moeten worden? Maar goed dat is ook een manier.

[Willybubba]

Is een risico.

En andersom dan? Een helemaal uitgemolken traject van 2 jaar waar je er na anderhalf jaar achterkomt dat je niet meer maakt wat de klant nodig heeft omdat de behoeften en de omgeving ook veranderen?

Wij werken nu een paar jaar met Scrum, en echt, je merkt het. Goedkoper, beter, meer gemotiveerde mensen, deadlines die ook echt gehalld worden (want die hou je soms, ook wegens druk van externe partijen of wetgeving oid). Give it a try.

[BoringDay]

Nee want je doet zoiets als voorstudie/informatie voorziening?

[Willybubba]

Wat bedoel je precies?

[BoringDay]

Als je iets maakt wat de klant niet wil dat er een communicatie probleem is. Er is namelijk wel een algemeen communicatie model met daarin 'feedback' zodat je kan bijsturen. Komt allemaal op hetzelfde neer en al die vaktermen wordt het niet duidelijker door en zijn ook geen super middelen. Het is niks anders dan een stappen plan ... dus waarom scrum noemen ipv stappen plan? In mijn opleiding noemden we het gewoon 'Plan van aanpak'

[Reactie gewijzigd door BoringDay op 22 juli 2024 19:44]

[Willybubba]

Allemaal wel termen uit de oude wereld, ik heb genoeg projecten meegemaakt die niet meer bij te sturen waren. Maar daarentegen beweer ik ook niet dar Scrum de heilige graal is hoor, ik zeg alleen dat wij er goede ervaringen mee hebben

[BoringDay]

_{[list]
• Getting your requirements right initially is far cheaper than changing them in the design phase.
• Getting your design right initially is far cheaper than changing it in the implementation phase.
• Getting your implementation right initially is far cheaper than discovering bugs in the testing phase.
• Discovering bugs during internal testing is far cheaper than letting the customer discover them.
[/list]}

Ik ben het anders met al deze punten volledig eens.
Leuk dat men termen als Agile en Scrum allemaal weten te bedenken maar die punten hierboven zijn voor een goed project toch veel interessanter. Het is je thuisfront, je gereedschap en je fundament.

[Reactie gewijzigd door BoringDay op 22 juli 2024 19:44]

[codebeat]

Inderdaad, iets wat Falcon10 hier ergens boven ook al aangeeft. De reden dat iemand zo vreselijk duur is, is om alle overhead te dekken, inclusief wat jij hier nu aankaart. Voor de klant kan SCRUM nadelig uitpakken, zich vertalen in hogere kosten. Vind het ook zo gek om een project te beginnen terwijl je nog niet weet wat er exact moet gaan komen. Daarvoor kan ik maar één ding bedenken waarom je dat zou willen als softwarehuis. De gegarandeerde inkomsten.

Niets is vervelender dan een klant die niet weet wat hij wil. Op deze manier voorkom de kosten die dit kan veroorzaken maar met wat voor doel, de klant wordt er niet beter van. Kan vaak goed gaan maar het kan ook vreselijk fout gaan. Je kunt natuurlijk ook zeggen: "We doen het niet" ipv er toch geld uit proberen te slepen.

Het is wel heel Amerikaans om het wel te doen, het gaat dan om de verdiensten en niet om het resultaat voor de klant. Begin maar en we zien wel waar het schip strand en dan kunnen we ondertussen toch de nodige uurtjes declareren. De 'opdrachtgever' kan dan niet zeggen dat het geen prestatie heeft gezien voor het geld ook al is het niet van functionele waarde voor de opdrachtgever Kortom: heel erg slim om geld te verdienen en juridisch goed dicht getikt maar of het voor de klant goed uitpakt is maar de vraag. De vraag is dan ook of een tevreden klant belangrijker is dan de verdiensten. Ik denk het laatste en daar hou ik dus niet van. Kosten wat het kost gaat die portemonnee open. Geld verdienen is niet erg maar niet ten koste van.

[hackerhater]

True, wij gebruiken doorsnee een mengelmoes.
Eerst moet het grootste deel bekend zijn a la waterval en tijdens implementatie wordt er op scrum overgeschakeld zodat de klant kan bijsturen zonder hele hoge kosten.

[jecede]

Klopt. In de praktijk blijken dit echter stuk voor stuk onhaalbare zaken. Vandaar dat men met scrum werkt, want dan kun je het project opdelen in behapbare brokken. En dan als je een goed proces hebt kun je al die 4 punten iedere sprint afvinken:).

[BoringDay]

Het is wel degelijk haalbaar zolang je er maar aandacht aan besteedt.
En bij een goed fundament moet je helemaal niet bezig houden met afvinken.
Daar moet je bezig houden met een goed concept.

[Reactie gewijzigd door BoringDay op 22 juli 2024 19:44]

[Dennis van der Stelt]

Ik ben het behoorlijk met Vengeful eens, je klinkt wel een beetje als een zure ontwikkelaar.

Wat ik altijd verbazingwekkend vind, is dat hele volksstammen ICT'rs denken dat een bedrijf is opgericht om een ICT afdeling in stand te houden. De mooiste dag zal komen als ICT'rs overbodig worden, want die gasten kosten klauwen vol met geld.

Het is héél goed dat er passie is voor het vak, maar managers zijn er echt niet voor niets. Vaak om ICT'rs met passie in te tomen, omdat ze anders los gaan en na 6 maanden in een hok gezeten te hebben, nog steeds niet hebben opgeleverd wat de klant wil. Ik weet ook dat managers heel vaak dingen willen om de verkeerde redenen, maar een goede manager is echt wel een zwik developers waard. Bijvoorbeeld een manager (of scrum master of product owner) die het team beschermt van alle vragen en eisen die uit de business komen. Eentje die faciliteert, zodat er hardware & software is om optimaal te werken. Een manager/scrum master die zorgt dat product owners hun benen uit hun lijf rennen om user stories op tijd duidelijk te hebben. Of iemand die zorgt dat developers en operations samen kunnen werken. Mensen kinderen, hoe vaak ik managers daar niet in heb zien falen. Met als resultaat de projecten zwaar over budget gaan. Heeft niets met techniek te maken, enkel met management skills.

Als je een goede manager hebt, waardeer 'm dan maar! Die mensen krijgen alle shit van boven én van beneden. Zowel vanuit upper-management als vanuit alle mensen onder hen.

[Verwijderd]

zou zeggen volg een scrum cursus. het enige verschil tussen scrum en lang project is dat er werk ende software wordt opgeleverd aan het eind van een sprint. (2-3 weekse cyclus)

Ook wat de meeste waarde heeft voor de klant wordt als eerste gemaakt. bv een klant wil 10 functionaliteiten hebben. ipv een lang project van 20 weken wordt er per week bv 2 user stories afgeleverd en er worden demo's gegeven voor de stakeholders.


Het kan best zijn dat voor de klant de prioriteit anders wordt, dus kun je er sneller op in spelen. Dus je krijgt een snelle terugkoppeling. Het development / test werk blijft min of meer hetzelfde

[Verwijderd]

wat zou de oorzaak zijn van het kleine aanbod?

[hardwareaddict]

Boven de 3000 euro bruto per maand is enorm riskant voor yacht om iemand aan te nemen.

De gemiddelde ITer in Nederland verdiende echter jaren geleden al meer dan 52k euro per jaar, wat stevig meer is dan 3k per maand.

Yacht is een ontzettend onbetrouwbaar bedrijf in dat opzicht en heeft zelf juist mensen lopen ontslaan afgelopen jaren.

Doen alsof het beter gaat is dus wel een beetje onzin lopen rondspuien. Het tegendeel is waar.

[Vengeful]

Mijn ervaring is precies tegenovergesteld. Ik ben tester, heb zojuist een nieuwe baan gevonden en ik kon kiezen uit 9 bedrijven (waaronder meerdere grote detacheerders, je weet wel, degenen die aan 't begin van de crisis de helft van hun mensen ontslagen hebben en een wervingsstop hebben ingezet.)

Ik ben trouwens niet de enige, veel van mijn collega's worden op de laatste paar maanden ook benaderd door andere bedrijven. Tuurlijk, er zitten ook recruiters tussen, maar ook bedrijven zelf. Een jaar geleden was dat wel anders.

[Venator]

Yacht was ooit best OK, sprekende uit eigen ervaring. Ik heb er ongeveer 8-9 jaar gewerkt en heb het ware gezicht helaas ontmoet tijdens de crisis. Ze hebben tijdens de crisisjaren best wel wat mensen ontslagen of via een "gesprek" in goed overleg bewogen om iets anders te zoeken. Daar zaten ook wel een hoop mindere goden tussen, om het netjes te houden. Ikzelf ben na iets meer dan een jaar daarna maar zelf gegaan, net als wat anderen, inclusief onze opdracht.

Sociale bewustzijn van het bedrijf was ook compleet weg, Randstad uitzendbureau mentaliteit en korte termijn visie, als er al een visie was. Vooral niet luisteren naar de eigen medewerkers die als eerste de problemen met de nieuwe aanpak signaleerden. Geen leads willen of kunnen oppakken, te veel luisteren naar managementruis. Moederbedrijf Randstad is het ook geweest die Yacht haar het huidige imago heeft gegeven en dit soort acties maken het er niet beter op. Maar goed, dat blijft mijn mening en persoonlijke ervaring, we dwalen af.

Dit verhaal op zichzelf is uiteraard een behoorlijk gekleurd marketingverhaal met als spil juist de mensen waar men zich bij Yacht op focust vanwege het iets hogere uurtarief in de markt. Even wat populaire termen koppelen en hoppa, mooi berichtje. Toeval? De WC-eend vergelijking is echt niet zo gek. Als er ook maar 5% van hun doelmarkt naar deze rommel luistert, nemen ze weer wat extra mensen aan en is het doel gehaald (het lijkt wel het hitpercentage van spammail). Maar ja, kan het een bedrijf ook niet kwalijk nemen om geld te willen verdienen ;-) Of indirect mensen voor deze functies te werven met de belofte op een directe tewerkstelling.

[King4589]

heb je het artikel wel goed gelezen? het is niet yacht die iemand zoekt, zij zeggen gewoon dat de uitkomst van een onderzoek is dat de vraag naar ICT-ers met 11% is gegroeid. niet dat zij mensen zoeken of dat ze betrouwbaar zijn en helemaal niet over het loon van de gemiddelde it-er jaren geleden

[hardwareaddict]

"Wij van wc-eend hebben onderzocht hoe vuil de WC's zijn en hebben geconcludeerd dat de WC's steeds vuiler worden, daarom adviseren wij wc-eend om de zaak beter schoon te wassen".

[markkie95]

De lage kwaliteit van het onderwijs op ICT gebied misschien?

[BoringDay]

Denk je dat je na ICT opleiding ineens een specialist bent?
Is dat nu niet het probleem juist, het echte werk begint pas in de praktijk.

Hoe moet iemand ervaring opdoen als alleen maar ervaren mensen gezocht worden?
Die specialisten moet men zelf creëren zodat een junior een senior kan worden.

Nee het probleem is niet zozeer het onderwijs maar meer het probleem hoe met nieuwkomers wordt omgegaan. Het is al sinds de eind jaren 90 zo en men heeft nog steeds er niks van geleerd en nu loopt men er tegen aan.

[markkie95]

Ik moet eerlijk bekennen dat ik op school vrij weinig leer, maar alleen op satge ervaring opdoe. klinkt logisch, is het ook. Maar het wordt wat minder als je op stage dingen leert die school niet weet ?!

[BoringDay]

Men mag ook niet verwachten of eisen dat men na een opleiding alle kennis heeft.
Dat is namelijk niet mogelijk en het is ook veel geduld hebben om een voet tussen de deur te krijgen om een kans te krijgen.

[markkie95]

Weet ik, maar ik erger me er aan dat ik dingen leer nu waar school geen kaas van heeft gegeten

[BoringDay]

"Al doende leert men"

[eelco74]

Dat niet alleen, maar de gemiddelde student doet liever een pret studie als rechten of een andere aantrekkelijke (lees niet te moeilijke) studie, om dan vervolgens klaar gestoomd te worden voor werkeloosheid. Ik zie het om mij heen wat ze allemaal kiezen. Terwijl wiskunde afstudeerders veel weggekocht worden door buitenlandse bedrijven en in de V.S. veel geld verdien. Maar ja dat is een veel te moeilijke studie.

Ik ben in 1988 aan de HTS Informatica opleiding begonnen en ik had een propaedeuse jaar met meer dan 800 studenten. Daar zijn er uiteindelijk maar 100 van afgestudeerd. Maar dat zijn er altijd nog meer dan die paar die de haagse hogeschool dit jaar had.

de HHS had ook een opleiding commercieel ingenieur waar ze nu mee stoppen vanwege te weinig studenten. En als er nou ergens behoefte aan is, is eens schakel tussen techniek en de bedrijfs-organisatie.

[arjankoole]

De lage kwaliteit van het onderwijs op ICT gebied misschien?

of totaal geen intresse.

[Gamebuster]

Ik heb mensen uit IT onderwijzen zien rollen die echt totaal niets kunnen. En dan bedoel ik niet dat er enkelen zijn.

[Aetje]

Mja, tegen de tijd dat een ICTer zijn opleiding afrond is de kennis die hij heeft opgedaan alweer achterhaald. Je kunt mensen concepten aanleren, maar applicatiespecifiek worden in een ICT opleiding is nutteloos.

[Gamebuster]

Iemand die 10 jaar geleden Java, C of C++ heeft geleerd kan nu nog prima meedraaien, zelfs als ze 10 jaar onder een steen hebben gelegen. Bovendien, een degelijke ITer heeft een andere taal of omgeving in no-time opgepakt.

[Reactie gewijzigd door Gamebuster op 22 juli 2024 19:44]

[PureTryOut]

Programmeren op MBO niveau is inderdaad beroerd. Nu is MBO natuurlijk zoiezo al niet zo hoog, maar mijn school heeft het echt beroerd...

[gimbal]

Toen ik op het MBO zat nog niet, vele jaren geleden. Ik heb tijdens mijn MBO niveau 4 technische informatie opleiding meer toepasbare kennis opgedaan dan toen ik een paar jaar later nog even HBO informatica erbij ging doen

Maar goed, IT leer je grotendeels juist niet in de schoolbanken. Enkel als je tijdens je opleiding het ook echt in de praktijk gaat toepassen rol je uit als iemand die direct in het bedrijfsleven kan intreden met minimale junior training. Het gros mag na de schoolbanken beginnen met te leren hoe het echt zit. Vrij kostelijk iets voor bedrijven, gezien job-hoppen een redelijk standaard iets is in de ICT en je dus vaak juniors opleid zodat ze die kennis kunnen toepassen bij de concurrentie.

[atacama]

Deze ervaring heb ik zelf ook. Ik heb op mijn MBO meer opgestoken dan mijn HBO. Nu kan je daar natuurlijk meerdere verklaringen voor hebben.
Wat ik vooral merk is dat mensen met MBO en HBO wat practischer (misschien wel realistischer) ingesteld zijn. Zij kijken, vaak, ook naar de omgeving waar HBO'ers dat minder zien. Uiteraard moet iedereen werk ervaring opdoen en kan dat ik de loop van de tijd veranderen.

Maar ik moet ook toegeven dat er MBO opleidingen zijn waar veel minder word geleerd dan ik heb gedaan. De verschillen tussen verschillende MBO instellingen zijn echt verbijsterend. En als ik de documentatie zie waar een school aan moet voldoen voor een opleiding, dan kan ik mij daar ook wel wat bij voorstellen. Voordat je dat papier werk hebt gelezen en begrepen ben je al erg lang bezig, laat staan dat je dit ook nog op de goede manier gebruikt voor een goed onderwijs programma....

[Sinned123]

De opleiding MBO informatica op ROC Zadkine Hofplein was toen van hoog niveau waar menig HBO opleiding nog een puntje aan kan zuigen.
Dat is later helaas veranderd.

[CAPSLOCK2000]

Lage salarissen? IT wordt in Nederland maar slecht betaald in vergelijking met het buitenland. Er is hier maar weinig waardering voor techniek. In Duitsland of Engeland kun je veel meer verdienen. Nu zullen de meesten geen vak kiezen op grond van het salaris, maar op de achtergrond speelt het wel mee. Salaris bepaald ook of mensen bij hun vak blijven of over stappen naar een beter betaalde baan in een andere sector.

[hardwareaddict]

Er is weinig variatie in salaris hier, dat klopt.

Prutsers krijgen hier zo maar 60k euro per jaar en mogen zich manager noemen, terwijl iemand die echt 10x beter is op 55k zit per jaar.

Duitsland betaalt inderdaad FACTOREN beter, Engeland niet. De salarissen voor ICT liggen daar echt stuk lager. Uitzondering is The City, maar die baan ga jij niet krijgen. Dat krijgt alleen iemand van het old-schoolboys network daar en we praten over enorm beperkt aantal banen dan.

Je moet het simpeler vergelijken. Een gemiddelde huisarts zit tegen de 2 ton per jaar.
Een gemiddeld universitair opgeleide IT-er die heeft factor 3 minder in Nederland.

In USA is dat anders. De betere IT'ers daar zitten op zelfde salaris als een huisarts. Gemiddeld vangen die huisartsen dan nog steeds meer - maar dat is ook logisch natuurlijk, want die zijn ALLEMAAL universitair opgeleid.

[arjankoole]

In USA is dat anders. De betere IT'ers daar zitten op zelfde salaris als een huisarts. Gemiddeld vangen die huisartsen dan nog steeds meer - maar dat is ook logisch natuurlijk, want die zijn ALLEMAAL universitair opgeleid.

de IT'ers daar toch ook? Al wat ze zoeken is minimaal een bachelors degree in CS.

[Verwijderd]

Misschien het feit dat je na 4 jaar studie (en natuurlijk jaren zelf hobby'en) slechts 2000-2500 euro bruto verdient en je daarvoor soms wel 3 uur per dag moet reizen van en naar de klant? Dan heb ik liever geen auto van de zaak, want zo hou je weinig tijd over voor jezelf en/of je gezin.

[BoringDay]

Als het zo nu en dan voor komt, dan is dat geen ramp toch?
Je kan natuurlijk ook als part-time call center medewerker aan de slag gaan, dan heb je veel tijd maar geen cent te makken

Er zijn heel veel mensen die wel eens meer tijd kwijt zijn dan kantooruren.

[Verwijderd]

Soms duren die projecten 3/4 jaar... Dan zit ik liever in een callcenter om de hoek voor het minimumloon. Ik bedoelde dat die 2000-2500 ook geen vetpot is namelijk.

[BoringDay]

Dat is een keuze die aan jezelf is maar soms moet je er wat voor over hebben om hogerop te komen.

[Verwijderd]

Dan zou ik toch rechten gaan doen of iets in de zakelijke dienstverlening. Dan verdien je zo 4x meer.

[blouweKip]

Dubbeltje op de eerste rij syndroom + bedrijven willen niet meer investeren in personeel.

[hardwareaddict]

Geleuter van de hoogste plank.

Als je kijkt op de vacaturesites zijn het alleen de werving en selectieburo's die al die vacatures zogenaamd in beheer hebben.

Juist de ICT is goed in zichzelf wegautomatiseren en meer en meer projecten worden weggezet richting India.

[Verwijderd]

India komt men steeds vaker van terug. Op papier lijkt het misschien te werken maar als men de effectiviteit onderzoekt dan is (mis)communicatie een groot probleem met projecten die in India ontwikkeld worden.
Standaard werk (vlgs protocollen/gestandaardiseerd) werkt denk ik erg goed in India maar zodra er aangepast (creatief) werk moet worden geleverd dan is India niet zo'n goede optie in mijn ervaring.

[Tjeerd]

Ik zie het bij mijn werk ook terug, het liefst al het progarmmeerwerk uitbesteden aan andere partijen. Als het al een Nederlands IT-bedrijf is dat de projecten mag doen dan hebben die zelf vaak al weer mensen in Oost-Europa zitten. En daarnaast projecten binnen het bedrijf die rechtstreeks worden uitbesteed aan buitenlandse bedrijven, die ook vaak in Oost-Europa zitten. De grootste reden is "Nederlandse softwareontwikkelaars zijn te duur in verhouding met de kwaliteit die ze leveren", plus de werkmentaliteit en het feit dat je door het op projectbasis te doen makkelijker kan opschalen naar meer ontwikkelaars en daarna weer terugschalen. Oftewel, minder vaste lasten dan wanneer je vast personeel hebt.

Of het allemaal een goede ontwikkeling is betwijfel ik, het is maar net vanuit wie zijn standpunt je het bekijkt.

[flossed]

Ik ben het met je eens dat dit wel de tendens is in onze maatschappij, veel korte termijn denken, snel succes boeken, promotie maken en doorgaan, en als er ellende uit komt dan is dat voornamelijk de incompetentie van degene die de rommel moet opruimen. Ik denk dat voor een lifecycle van een product de meeste kosten nog steeds tijdens de beheerfase gemaakt worden, en dat vanuit dat perspectief de winst tussen in het buitenland bouwen vs hier bouwen relatief beperkt zal zijn. Het probleem ligt meer in de wijze hoe men er naar kijkt. Als voorbeeld: Als een PM bij een portfolio board komt voor een budget van 1.000 euro, dan gaat men hem aan alle kanten besnuffelen om te zien of dat niet minder kan, maar men neem vaak de totale beheerkosten niet mee als onderdeel van de rekening. vroeger claimde men dat beheer 99% van zijn kosten van de hele lifecycle voor zijn rekening nam. dat zou in dit voorbeeld 99.000 euro zijn. dan maakt een ontwikkel besparing van 100 euro ook niet meer uit. Terwijl die besparing in potentie wel tot meer beheerkosten kunnen leiden. De kosten komen vaaak terug als management kosten bij het extern zetten, en die zullen in verhouding toch hoger zijn dan een FTE aan boord die alles voor zijn rekening neemt. Tot zover de ratio, en nu verder tot de orde van de dag.

[Verwijderd]

Ik meen gelezen te hebben dat bij een gemiddeld software produkt/project, slechts 10% van de totale life cycle kosten uit de project kosten bestaan. Toch ligt alle nadruk op het omlaag brengen van die 10%.

[Distrax1988]

Ben ik het mee eens, bij Capgemini gewerkt, flinke partij waar de 2de en 3de lijn is geoutsourced naar dit soort landen, vervolgens de communicatie onderling en ''hence fixing the ticket'' het werkte bij de standaard dingen prima.

Maar voor unieke problemen waar geen template voor was liep het stuk, ook de onderdanigheid en het niet durven vragen vanuit de cultuur werkte vaak negatief, (lees: niets te nadelen van deze cultuur maar op werk gebied niet prettig)

[Verwijderd]

Helemaal mee akkoord, werk op dagdageljkse basis met de Indiatak van Cap Gemini en qua communicatie loopt dat altijd verkeerd.

[Verwijderd]

Ik werk ook dagelijks ermee samen, en ik heb toch een andere ervaring. Het begin loopt inderdaad stroef qua communicatie (vooral het verzwijgen van problemen is een groot probleem), maar eens een Indische collega lang genog op project zit, betert dit enorm. Ik denk eerder dat het probleem is dat de concurrentie bij IT-bedrijven in India moordend is waardoor bijna nooit iemand langer dan enkele maanden op een project zit. Een Belg die maar 3 maand ergens zit, kan meestal ook nog niet mee...

[Juicy]

Het jammere is dat het redelijk uniek is dat een Indische collega lang genoeg op het project zit ... Het zijn jobhoppers eerste klas en als ze 3 maanden extra op hun CV hebben staan zijn ze zo snel mogelijk weer gevlogen.

[Verwijderd]

Klopt, momenteel worden ze gebruikt als "wegwerpresources" en dan is het doodnormaal dat ze nooit echt goed ingewerkt raken. Hier zijn 2 oorzaken voor:
* Al die IT bedrijven liggen naast elkaar, na elk project dat ze doen kunnen ze ergens anders opslag krijgen en dan veranderen ze
* Vanuit het moederbedrijf is er enorme druk dat ze niet te lang op 1 project mogen zitten want dat is niet goed voor carriere.

Ik vind het ontzettend jammer dat er zo'n negatieve indrukken zijn, terwijl mijn project echt aantoont dat met wat inzet langs beide kanten er wel degelijk kwaliteitsvolle en goeikope software kan gemaakt worden. Mijn vorige project hebben we zelfs zo ver gekregen dat het nu volledig in India wordt uitgevoerd zonder tussenkomst van een Belg.

[chaoscontrol]

Ik ben nu bezig met Capgemini India om bij een klant een simpel mail probleem met onze software op te lossen. Ondertussen zijn we 3 weken en 3 conference calls verder en ze snappen blijkbaar nog niet dat de applicatie server over poort 25 moet kunnen praten met de mailserver.

Bij klanten die hun eigen inhouse (of in ieder geval NLse) automatiseerder/systeembeheerder hebben, spelen deze dingen nooit.

[Aetje]

CapGemini is niet de enige grote ict provider die zo werkt. Bij KPN kunnen ze er ook wat van - met exact dezelfde problemen. Communicatie met de mensen is niet mogelijk en ze begrijpen de probleemstellingen die in helder engels aangeleverd worden, gewoon niet.

[hardwareaddict]

En welk 'creatief' werk doet de ICT dan in Nederland volgens jou?

[Dannisi]

Als er iets niet 100% volgens de specs of requirements gemaakt kan worden, logisch nadenken ipv in de pauze stand gaan.

[hardwareaddict]

En wat moet dan niet volgens de specs gemaakt worden?

Geef eens een voorbeeld.

D'r zijn enorm weinig bedrijven die nieuwe stukjes software nodig hebben.

ASML is 1 van de weinige uitzonderingen in Nederland.

[Oyxl]

Ik zie dat je veel kritiek uit, maar heb jij dergelijke zaken wel eens in de praktijk meegemaakt? Want óf je hebt hier totaal geen ervaring mee, óf je bent een manager die uitfaseren naar het buitenland heeft verkocht en nog steeds de illusie heeft dat het werkt.

Ik ga verder niet in op de klussen waar ik werk, om verscheidene redenen, maar ik kan je uit de praktijk het volgende vertellen:

India en omstreken willen graag en hebben soms zelfs veel theoretische kennis (universiteit), maar zijn cultureel gebonden aan bepaalde communicatie vormen die niet stroken met de Westerse wereld. Dit betekent o.a. dat bij problemen sprake is van totale ontkenning van de problemen (of eigenlijk radio stilte) totdat men gaat informeren over de status.

Ook hebben ze er een handje van om geen kritiek te uiten, of te incasseren. Men zal altijd bevestigend reageren, want oneens zijn met een werkgever is not done en aangeven dat je iets niet begrijpt is beschamend voor zowel de werknemer als de werkgever. Het kan namelijk zomaar suggereren dat de werkgever het verkeerd uitlegt.

Dit betekent dat je op communicatief gebied niet snel ver komt en sommige projecten zich veel langer voort slepen dan bij lokale uitbesteding.

Daarnaast heb je te maken met de mate waarin logisch en creatief kan worden nagedacht. Aangezien het de ICT betreft, kun je nog zo uitgebreid documenteren, maar problemen doen zich 4 op de 10 keer toch voor. Bij probleemoplossing kun je het vergeten in India. Het begrip Google kent men daar niet, laat staan dat men in logische programmatisch/pragmatische concepten denkt.

Simpel voorbeeldje: Scripting; 'Net use' inbouwen vanuit CMD in een applicatie, maar sommige gebruikers hebben geen rechten op de locatie van de Net Use, met als gevolg dat het script blijft hangen (wacht op wachtwoord). Men komt hier niet uit, want Net Use heeft geen timeout argument.

Men komt er totaal niet op om Net.EXE aan te roepen, met de parameters los daaraan vast, omdat je een EXE wel kunt monitoren en een timeout kunt meegeven in je script, waardoor deze dus gewoon door loopt. Dergelijke zaken zijn creatieve oplossing en die hoef je uit India niet te verwachten.

Langzaam komen steeds meer bedrijven terug op hun beslissing de ICT uit te faseren naar buitenland. In veel gevallen door alleen standaardisatie uit te voeren in India, waarbij men alleen letterlijke documenten hoeft te volgen. En ook daarin worden slordige fouten gemaakt.

[Reactie gewijzigd door Oyxl op 22 juli 2024 19:44]

[Vengeful]

Jouw voorbeeld schetst een goed beeld van enkele grote problemen met het outsourcen naar een land als india. De realiteit is dan ook meestal dat het op papier goedkoper is, maar in de praktijk kan het wel tot een factor 20 duurder uitvallen.

Los van alle problemen rondom communicatie, de indische cultuur is ook een probleem. De kastensamenleving hebben ze prachtig weten te spiegelen in het bedrijfsleven (met als enige verschil dat je promotie kan verdienen door goed werk te doen.)

Elke grote indische partij heeft duizenden mensen in india zelf zitten, het voetvolk. Mogelijk wel veel theoretische kennis, maar nagenoeg geen praktijkervaring. Daar kun je dus niet bijster veel van verwachten. Dan heb je de mensen die enkele jaren code-aapje zijn geweest, die krijgen inderdaad het privilege om bij de klant te komen. Heb je lang genoeg bij de klant gezeten, dan MOET (niks mogen, moeten) je manager worden.

Het grote probleem met dit systeem is als volgt, ze hebben legioenen aan mensen in dienst die gewoonweg niks kunnen. Zit je support in india? Dan heb je een probleem en kun je het beter zelf proberen op te lossen. De mensen die bij de klant zitten hebben ervaring, dat wel, maar dat zegt niks over of ze wel of niet goed zijn. Op mijn allereerste klus als pure tester zat ik met een indier die al 10 jaar in het vak zat, had stapels certificaten, was volgens z'n kaartje projectmanager. Nadat ik daar twee weken zat moest ik hem uitleggen hoe hij zijn werk moest doen. Kon niet eens zijn eigen taken managen, compleet hopeloos. Wat gebeurt er dan? Dan komt je leidinggevende je de huid volschelden, zo hoort dat blijkbaar in India. Ze doen nog net geen percussieve motivatie (klap op je bakkes), maar je een paar keer in een open ruimte omringd door je collega's je uitmaken voor rotte vis, dat zou toch wel het gewenste effect moeten hebben, toch?

Gevolg is, Indiers zijn in de praktijk heel passief. Ze doen een taak eerder niet, dan dat ze een risico nemen, want dan maken ze in elk geval geen fout.

En hey, je meest ervaren mensen wegpromoveren is altijd goed natuurlijk. Zo heb ik ook met een indier samengewerkt en dat was een echte tovenaar. Die jongen was verschrikkelijk goed. Zat al 5 jaar in nederland, dus gewend aan onze manier van werken, zei ook als ie iets niet snapte, of als iets niet mogelijk was. Klus zou aflopen, hij moest terug naar India, want manager worden. Niemand gaf er een drol om dat hij niet geschikt zou zijn als manager, want hij was het meest in z'n element als iemand hem vertelde wat hij moest doen, tevens was hij niet bijster alpha. Gevolg? Hij heeft ontslag genomen en is bij een nederlands bedrijf gaan werken, want daar mocht hij wel gewoon code blijven kloppen.

Dus, barbaarse managementmethoden, vaak werk verkeerd of niet opleveren, want communicatieproblemen en een leger prutsers en alle goede developers vluchten of worden nutteloos gemaakt als manager. Er is een reden dat india zoveel goedkoper is, dat mag duidelijk wezen.

Disclaimer: Ik heb tot nog toe op vijf klussen met India te maken gehad, dit is niet een unieke situatie, zo werkt het gewoon. Elke manager die nu nog durft voor te stellen om te outsourcen naar India omdat het geld zou besparen moet op staande voet ontslagen worden.

[Verwijderd]

2 uitstekende reacties hierboven. Voor mij niets nieuws onder de zon: ik werk al meer dan 10 jaar samen met offshore partijen en in nog geen enkel geval heeft het iets toegevoegd: het is niet sneller, niet beter, en niet goedkoper. Ik beschouw dergelijke projecten als dweilprojecten: niets dan opruimen en corrigeren, zoveel dat je het beter zelf had kunnen doen.

Ik vraag me wel af hoe jullie er bij komen dat deze offshoring trend aan het afnemen is? Incidenteel hoor ik dat in het nieuws, maar in de praktijk zie ik het alleen maar versnellen.

Zoals hierboven al beschreven is cultuur een grote oorzaak. Een nog niet genoemd punt is de ICT markt terplekke. De ICT is er een enorme markt, een van de weinige sectoren die booming is, om mensen verlegen zit, en welke goed betalen. Het gevolg hiervan is dat hele massa's mensen de ICT ingaan die er geen aanleg of interesse voor hebben. Dat is een totaal andere markt dan in Nederland.

[Oyxl]

Ik kan er niet helemaal op in gaan, maar laat ik het zachtjes verwoorden. Er was ooit een moment dat offshoring interessant leek, op papier. Kritiek werd afgedaan als scepsis zonder basis. Bagatelliseren (wow die moest ik toch even in het woordenboek opzoeken, schrijf 'm nooit voluit) die hap en projecten doorduwen.

We zijn al lang voorbij het 'point of no return' in dat opzicht. Niet alleen zijn de meeste bedrijven nu procesmatig zo nauw verweven met hun offshore activiteiten, dat het onmogelijk wordt deze uit te faseren zonder heel veel 'kennis' te verliezen, maar er wordt vanuit het hoger management nog steeds krampachtig vast gehouden aan de illusie dat het goedkoper kan en kwalitatief goed blijft. Zaken zoals communicatie zijn niet te kwantificeren, met als gevolg dat deze zaken niet terug te vinden zijn in de cijfers. Terwijl communicatie, en dus informatie, juist één van de zwaarste eisen is binnen de IT. Zonder informatie ben je aan handen en voeten gebonden. Met foutieve informatie door taalbarrières, wordt chaos gecreëerd, welke over het algemeen moet worden opgelost door een intern of lokaal crisis team.

Het verschil, althans dat gevoel heb ik, is dat los van de technici, steeds meer middenmanagement openlijk kritiek durft te uiten op offshoring en die kritiek landt dan voornamelijk weer bij hun managers. Dat kom ik persoonlijk steeds vaker tegen en die geluiden zijn steeds moeilijker te ontkennen.

Bij mijn huidige klus wordt zo veel mogelijk gestandaardiseerd in het buitenland en wordt het maatwerk uitgevoerd in Nederland. Volledig verwijderen van processen die door het buitenland worden opgeknapt is in de huidige situatie onmogelijk, maar door zoveel mogelijk basis taken uit te laten voeren in het buitenland, met goede documentatie en een strak proces, worden de risico's geminimaliseerd. De technische 'hoogstandjes' worden vervolgens opgepakt door specialisten in NL. Die daardoor ook nog eens de interesse in hun werk niet verliezen. Op zich onder aan de streep nog een positief effect dus.

Wat mij betreft is het keyword hier 'Awareness'. Het besef dat langzaam groeit, dat de wat technischere zaken niet zo makkelijk zijn uit te voeren door goedkopere krachten met de nodige theoretische ervaring, maar een gebrek aan praktijk ervaring en een gebrek aan creatieve breinen. Volgens mij een van de zaken die opgroeien in bijv. India met je doet. Alle creativiteit wordt uit je gezogen. Zolang dat besef blijft groeien, gaat het de goede kant op.
----
Wat werk betreft; Ik moet zeggen dat ik voor een niet-afgestudeerde (heb slechts VWO) redelijk terecht ben gekomen, met een boven modaal salaris en een leuke auto onder m'n kont (althans, m'n nieuwe moet nog komen), dus ik ben best tevreden in de IT. En misschien ga ik over een paar(~10) jaartjes wel het management in. Hoef ik i.i.g. geen begrip voor de materie te faken

[Reactie gewijzigd door Oyxl op 22 juli 2024 19:44]

[Armin]

En hey, je meest ervaren mensen wegpromoveren is altijd goed natuurlijk

Komt nog bovenop dat in Nederland een ingenieur/techneut niet meer mag verdienen dan zijn baas. Dus op een gegeven moment sta je als ingenieur/techneut voor de keuze of het management in, of aan je salarisplafon zitten voor de rest van je leven.

In andere landen zoals de USA, is het wel mogelijk om als techneut verder te groeien, en in een team de manager die het project leidt niet diegene is die het meeste verdient.

In Nederland kennen we zoiets enkel bij voetbal

[Timoo.vanEsch]

Hé, dat klinkt bekend in de oren!
Ik kijk mijn ogen uit bij mijn huidige werkgever. Als external zie ik mensen met serieuze begaafdheden code kloppen tgen startersloon,omdat ze enkel via het carrièrepad van management hogerop kunnen komen.

Ik sta compleet perplex, omdat ik niet kan begrijpen dat vakmensen minder MOETEN verdienen dan diegenen die hen sturen.

Kijk, een echte ICT manager is goud waard. Iemand met zowel gedegen ICT kennis als serieuze management kwaliteiten. Die krijgen zomaar 6k per maand of meer. Maar de praktijk leert, dat het veelal doorgegroeide kantoorklerken zijn, die manager worden. En die moeten dan ICT projecten leiden. En spreken over de salarisschalen van 'hun' werknemers.

De huh?

[Verwijderd]

Ik stond onlangs te praten met een vers aangenomen programmeur. Ikzelf heb veel programmeer ervaring en ben inmiddels meer een architect, maar binnen de specialisatie waar het over ging, was deze nieuweling, toegegeven, even goed zoniet beter dan ik.

Toch zit ik 3 salarisschalen hoger. Waarom? Papiertje en ergens langer zitten. Of je het nu over HR, recruitment of management hebt, allen hebben geen flauw idee wat een programmeur doet, hoe deze te beoordelen, hoe produktiviteit of kwaliteit te meten. Dus wat doet men? Men doet dit alles op indrukken.

Hierbij wat gratis carriere advies. Het is ratten advies in feite. Je kunt 2 dingen doen: klagen over dit onrecht, of het spel meespelen en uitbuiten.

Het enigste wat je hoeft te doen om boven de lijn te komen is om je zichtbaarheid te vergroten. In een groep van programmeurs (die niet bekend staan om extravert gedrag) is dat kinderlijk eenvoudig om te doen:

- Team meeting? Reageer actief op de inhoud. Stel vragen. Steek je vinger op als vrijwilliger wanneer er iets moet gebeuren. Je zult een van de weinigen zijn die het doet en het stuurt een ijzersterk signaal naar management: deze kerel wil vooruit, en trekt zich dingen aan.

- Organiseer pro-actief iets wat weinig tijd kost maar veel zichtbaarheid oplevert. Organiseer bijvoorbeeld een kennissessie. Geef eens wat presentaties over onderwerpen waarin je specialist bent. Doe het ongevraagd. Wederom zul je een van de weinigen zijn.

- Nog vreemder: help actief je manager. Zo ben ik visueel redelijk sterk en verbeter ik de Powerpoints weleens van diverse managers.

Al deze dingen kosten nauwelijks tijd en vergroten je zichtbaarheid enorm, en daarmee ook je waardering en salaris. Kort samengevat: zorg dat je in de "hofhouding" van management komt. Management zal nooit oog hebben voor jouw tech skills, want die begrijpen ze uberhaupt niet.

Het bovenstaande is enigzins "rattengedrag", maar het is wel hoe de wereld werkt. Het is niet wat je weet, het is wie je kent en zichtbaar maken wat je weet.

[Timoo.vanEsch]

Goede tips idd, Fledder.
Delen ervan heb ik zelf ook al mogen ervaren als succesrijk, idd ;-)

Thanx!

[analog_]

Ook in het leger is het mogelijk in lagere rang orde meer te verdienen dan je overste door specialisatie.

[Verwijderd]

Hoe kom je daar nu weer bij? Het salaris is juist alleen van de rang afhankelijk. Zie o.a.: http://www.servicepuntdef...rt%202012_tcm4-855544.pdf

Daarnaast is het in het leger ook 'up or out'. Dus als je van soldaat niet hogerop naar kaderfuncties gaat, vlieg je er toch echt uit...

[amatoer]

of je gaat zelf de baas worden, a.k.a. zzp'er worden

[Oyxl]

Top stukkie, goed leesbaar en sommige feiten voor mij ook nieuw. Ik wist (natuurlijk, min of meer) van de kasten systemen en de implementatie daarvan in het bedrijfsleven, maar was niet bekend met de MOET in het manager-wezen.

Nu ben ik erg sterk voor managers die WEL enige kennis hebben van de materie (de quote dat een manager niets hoeft te weten over de materie waar ie op managed, is de grootste bullshit die ooit is verzonnen om management voor de volstrekt onwetende klant makkelijker te verkopen), maar de betreffende persoon moet nog steeds manager materiaal zijn.

Het is in ieder geval zo bizar en scheef in vergelijking met de Westerse samenleving dat het simpelweg niet KAN werken. Althans, niet efficient, of kwalitiatief hoogstaand.

[Floor]

Toen outsourcen nog hot en trending was heb ik ook zitten tellen om projecten in India neer te leggen. Ik kwam al snel tot de slotsom dat het niet rendabel was. Behalve door het cultuurverschil is voor een goed project regelmatig de koppen bij elkaar steken van cruciaal belang. Zo weet iedereen waar hij/zij aan toe is, komen problemen snel boven water enz enz.
Dat gaat niet via de mail (VOIP met een indier is ook niet altijd optimaal of ze moeten echt goed Engels spreken).

[reinouts]

Offtopic, maar moet toch even opmerken dat het India en Indiaas is, niet Indië en Indisch. Dat laatste verwijst naar de voormalig Nederlandse kolonie tegenwoordig bekend als Indonesië.

[Nnoitra]

Er zijn er meer dan jij denkt.
Dat jij c.q. een klant daar niets van ziet is heel groot.
Veel nieuwe software is backend spul.

Voorbeeld: als een willekeurige provider een nieuwe dienst aan gaat bieden, zal er in 99 van de 100 gevallen toch echt nieuwe software moeten komen om die dienst werkend te krijgen.
Bijvoorbeeld om de dienst; aan te kunnen maken, wijzigen, verwijderen, koppelen aan (bestaande) klanten, etc etc.

[CH4OS]

En wat moet dan niet volgens de specs gemaakt worden?

Geef eens een voorbeeld.

D'r zijn enorm weinig bedrijven die nieuwe stukjes software nodig hebben.

ASML is 1 van de weinige uitzonderingen in Nederland.

In de ICT is heel veel maatwerk. Het is wellicht wat krom verwoord, maar geen enkel maatwerk is standaard te noemen. Ik denk dat Kabal dat bedoelde. Ik neem aan, dat er dan geen voorbeeld (aka onderbouwing) meer nodig is?

[Plep]

Er wordt steeds vaker gewerkt met een globale spec en vanuit daar (samen met de softwareontwikkelaars en -testers) verder werken. Scrum, RUP, AUP zijn allemaal methodes waar niet van te voren de spec helemaal uitgeschreven is.

[Timoo.vanEsch]

De 'lol' is: hoe automatiseer je automatisering?
Ik zie steeds vaker maintenance worden uitbesteed, met initial development ter plaatse.

[flossed]

Huh?? vanuit welke invalshoek redeneer jij?
In Nederland zijn er ongeveer 400.000 bedrijven, vrijwel allen hebben software gekocht waarvan vele maatwerk bij leveranciers besteld om voor hun businessproces het juiste te doen. En dat is zeker niet alleen ASML.

in vele bedrijven zie je het probleem dat het bedrijf waarvoor iets gemaakt moet worden niet in staat is om een sluitende specificatie te maken voor datgene wat er gebouwd moet worden (waar een ontwikkelaar zonder creatief vermogen dus blindelings mee aan de slag kan gaan en bouwen). Reden daarvoor is dat een heleboel grote en kleine ondernemingen voor het compleet specificeren van een aanpassing de benodigde kennis niet (meer) aan boord hebben, Bijvoorbeeld er moet een tekst getoond worden als een gebruiker een verkeerde input invoert. Een specificatie zal moeten zijn welke tekst wordt waar getoond op welke manier, moet dat tijdens het invoeren al getoond worden of nadat een gebruiker het invoer veld verlaten heeft, moet de tekst verdwijnen als de gebruiker het veld heeft aangepast of gebeurt dat pas nadat er een poging gedaan wordt om de pagina te verlaten. Op welke plek vindt er validatie plaats? wat is een correcte invoer wat is een verkeerde.

Met zulke vragen loop je snel tegen muren van onwetendheid aan waarbij gezegd wordt, joh kan je dat niet doen zoals je dat met andere dingen doet?
en dan moet een ontwikkelaar creatief genoeg zijn om een eindgebruiker op weg te helpen.

[Niosus]

Zelfs voor veel onnozele websites komt er veel maatwerk aan te pas. Ik ben bezig aan een project waarbij een paar concepten gemengd worden. Na veel opzoekwerk blijkt dat er geen enkel pakket is dat dit out of the box ondersteunt. Ik heb dus de closest match gekozen en ben bezig met het uitbouwen van de missende features en het te koppelen aan een verschillende databases. Projectje van max 100 uur werk maar toch gaat er een groot deel custom code nodig zijn.

Een framework of pakket is meestal niet meer dan een goede start. Leuk dat je wat documentatie hebt en de basics niet meer moet uitzoeken, maar het echte werk is het product uitbouwen en aanpassen zodat het exact is wat de klant nodig heeft. Dat is zeker niet altijd evident en er komen gegarandeerd complicaties naar boven waarbij het niet meteen duidelijk is wat de beste keuze is. Goede communicatie is essentieel en dat gaat nu eenmaal veel beter met mensen die in de buurt of zelfs in hetzelfde gebouw werken.

[HetMes]

> D'r zijn enorm weinig bedrijven die nieuwe stukjes software nodig hebben.

Wut?

[likewise]

De hele high-tech industrie in ieder geval. Alles is maatwerk.

[BikkelZ]

Als je software laat ontwikkelen in het buitenland dan denken mensen dat ze wat specs over de heg kunnen kieperen en dat er dan goede software uit komt rollen. Veel bedrijven die outsourcen zijn totaal niet bij machte hun eigen organisatiestructuur aan te passen en te committen naar de partij waarnaar ze outsourcen.

[sebastienbo]

Helemaal waar, er lijkt geen enkele ICT job echt uitbesteed kunnen worden met als volgende redenen:

1) Benelux is ingewikkeld, je moet minstens 3 talen kennen voor support te kunnen bieden of te kunnen programmeren met talen ondersteuning.
2) Bovendien heb je een heel grote cultuur verschil, bij programmere is het zeer belangrijk dat de programeur deze cultuur goed begrijpt en aanvult of anders kan het programeer werk zeeeer lang duren (zie belastingen in belgie 15 miljoen naar de prullenbak omdat het gewoon niet van de grond kwam, en dat was goedkoop naar india uitbesteden...)
3) Lonen in china en India zijn maar liefst 350% gestegen in 2 jaar!!!
4) India en china betekend ook meteen minstens 8 uur tijdverschil, probeer dat maar eens aan te sturen als project manager!!!! je verliest elke keer een volledige dag tegen dat je feedback krijgt.
5) Chinese diplomas vallen nog mee, maar die van India daarentegen die zijn echt niets waard, verwacht niet dat een ingenieur gelijkwaardig is als die van West-europa
6) In west-europa word er van werknemers verwacht dat ze autonoom kunnen werken, wel ik heb al in een 13 tal bedrijven gewerkt die uitbesteding hadden geprobeerd in China of India en ze zijn alles behalve autonoom!!!

Elke maanger dat nu nog durft uit te besteden naar ginder moet in een gat geleefd hebben de laatste 5 jaar want het nieuws zit vol met uitbestedings flaters ...

Ze zijn wel goed voor repetitief werk of procedurieel werk, maar al de rest niet dus...

[beany]

Het is inderdaad zo dat bepaalde vacatures 15x (en soms meer) aanwezig zijn, allen van een andere recruiter. Omdat de bedrijfsnaam er niet bij staat is het erg lastig om te zien of het om unieke vacatures gaat.

Ondanks dat zal het aantal vacatures groter zijn dan het aanbod ICT'ers. Toch is het als ICT'er erg lastig om in de vacatures te zoeken vanwege die recruiters. Er zou eigenlijk een vacature site moeten komen waar alleen de bedrijven vacatures mogen plaatsen als het om vacatures in dat bedrijf gaat. Recruiters dus uitgesloten. Ook al omdat de meeste recruiters als cowboys handelen wat erg nadelig is voor de werkzoekende als het bedrijf dat personeel zoekt.

[hardwareaddict]

Die recruiters zijn alleen bezig met in hun database zoveel mogelijk namen opnemen. Logisch dat dus meer vacatures verspreiden dan lijkt alsof er meer banen zijn.

Yacht betaalt veel te weinig en is een onbetrouwbare bron.

"wij van wc-eend adviseren wc-eend"

[Iblies]

Het zou veel realistischer zijn om bedragen te zien.
Alleen zullen bedrijven daar erg voorzichtig mee zijn.

[HetMes]

Recruiters verdienen geen hond aan een grote database, alleen aan hoeveel man ze kunnen wegzetten.

Maar je hebt een punt, misschien is het juist wel omgekeerd. Er zijn minder en minder ICT'ers nodig, dus krijgen de recruiters het lastig en gaan zij meer lijntjes uitzetten.

[BoringDay]

Zo zijn ze niet allemaal er zitten enkele tussen die wel degelijk hun mauw uit de handen steken en geregeld je benaderen of je ergens interesse in hebt. Het is daarom ook wel slim om dat contact in stand te houden voor een 'just in case' scenario. Daarbij heb ik eigenlijk nog nooit van Yacht gehoord .....

[Tjark]

Helaas betalen die recruiters goed voor hun accounts op die sites en vinden die sites het helemaal prima juist: veel vacatures (kijk, wij de de grootste vacaturesite) en lekker betalende klanten (de recruiters)

[Gamebuster]

Zelf wel eens een project proberen te delegeren naar een Indiër? Het faalt simpelweg.

Goed IT personeel is lastig te vinden. Crap IT personeel vind je als stoeptegels aan de straat.

[hardwareaddict]

Alles zit online tegenwoordig, dus zelfs systeembeheer laat ik door Indiers doen vanzelfsprekend. Dat gaat steeds genialer tegenwoordig. Ze hebben alleen een password nodig en rootpassword van een server en de rest wordt geregeld!

India is zeker niet de goedkoopste met 2.50 dollar per uur.

Uitbesteden richting filippijnen is goedkoper. Dat kost daar 1.11 dollar per uur.

Hetzelfde hier kost al snel 75 euro per uur of meer, terwijl dan een MBO'er vaak de zaak mag opknappen, of iemand die echt van toeten noch blazen weet.

In Nederland is men wel zo verwend geraakt door hoog opgeleide Indiers, dat men zich niet goed realiseert wat goed personeel in Nederland kost.

Er is veel te weinig variatie in betaling richting ICT/ers en programmeurs in Nederland.
Logisch dat er zoveel crap dan geproduceerd wordt hier.

Vanzelfsprekend moet je goed weten wie je inhuurt, al helemaal als je met buitenland zaken doet en nog meer als je met een derde wereldland zaken doet.

Heb al heel veel bedrijven daar 't schip zien ingaan. Echter veel van die bedrijven bestaan hier niet meer, want dat hele product is gewoon in zijn geheel uitbesteed richting India.

Als we kijken naar de prijzen waarvoor veel bedrijven iets opgelost willen hier in Nederland, dan begrijp je ook meteen hoe onmisbaar 3e wereldlanden en met name India is geworden in de software wereld. Je kunt simpelweg niets voor elkaar krijgen in Nederland voor de prijs die men bereid is te betalen. Men betaalt simpelweg factor 10 te weinig om projecten uit te voeren in Nederland.

[Gamebuster]

Dat is ook mijn punt; als je klusjes hebt die niet heel complex zijn, kan je het beter uitbesteden inderdaad. Maar als je echt complexe problemen op te lossen hebt, heb je gewoon een goede developer/beheerder nodig, en die zijn zeldzaam en erg prijzig.

[Eminus]

"ze hebben alleen het root password nodig" ...

ja..

Daarom heb je security partijen die op basis van tijd en server ID je een Sudo geven. Gedurende die tijd worden acties gemonitord.

[Verwijderd]

"Men betaalt simpelweg factor 10 te weinig om projecten uit te voeren in Nederland. "

Dan ben ik benieuwd naar de aard van dat project. In de zakelijk wereld is de meest optimistische besparing voor een offshore project die ik ooit gezien heb een factor 2, niet een factor 10.

[gimbal]

Zie ook de diverse fora over programmeren; een groot deel van de vragen zijn van de soort "hello dears, I need to build this and this software. How to do this. Example code would be best. Thank you, <indian name>".

EDIT: dat is wellicht wat lastig als on-topic te zien; ik bedoel daarmee te zeggen: dat zijn dus de mensen aan wie het werk uitbesteed wordt omdat het 'zo goedkoop is'.

[Reactie gewijzigd door gimbal op 22 juli 2024 19:44]

[ZpAz]

Ik dacht dat veel bedrijven die projecten uitbesteedden naar India al weer huilend terug kwamen omdat er altijd "Ja" werd gezegd, ook al was het niet haalbaar. En omdat de kwaliteit van code ondermaats was in vergelijking met projecten die wel in eigen land bleven.

[hardwareaddict]

Welke software op jouw computer is in Nederland ontwikkeld?

Ik zie hier hele bende nieuwe programma's op mijn computer echter die allemaal in India zijn geproduceerd.

Zelfs veel van de telecomsoftware is nu in handen van Chinese bedrijven, dus ook die software is nu weg.

[Lampie]

Verwar de consumentenmarkt niet met de zakelijke markt.

[hardwareaddict]

De zakelijke markt produceert Nederland steeds minder software voor.

Ondertussen heeft China daar in de telecom ook stevig toegeslagen richting EU, terwijl grote bedrijven hier gevestigd die eerst nog eigen stukje software ontwikkelden, die zijn bezig met standaardiseren. Die opdrachten haalt geen enkel Nederlands bedrijf binnen.

[Nnoitra]

Er is meer 'software' (programmatuur is een betere benaming in deze) dan wat er op jouw computer staat.

De (backend) systemen van banken, gemeenten, telecom providers, etc etc moeten ook ergens op draaien.
Of dacht je dat ze klanten(mutaties) en dergelijke op een windows 7 machine met excel bijhielden?

[Kevinp]

Al het software spul bij ons bedrijf wordt in Nederland gemaakt.

In India doen ze het makkelijke werk, maar wat veel tijd kost. Wat allemaal duidelijk binnen de lijntjes valt. (genereren van PLC code bv)

[BoringDay]

Onzin er zijn genoeg software bedrijven in Nederland die maatwerk ontwikkelen.
Zelfs Blender is van Nederlandse bodem. Als je denkt dat ze allemaal in India zitten dan ben je denk ik niet zo goed op de hoogte. Zoek eens op maatwerk software in Nederland, je komt een hele waslijst tegen

[arjankoole]

ik merk juist dat projecten regelmatig in India landen, en dan terugkomen naar Nederland vanwege de ermbarmelijke kwaliteit. Als je wilt outsourcen vanwege de kosten, kom je van een koude kermis thuis.

En heel veel HR mensen van intressante ICT partijen vinden tegenwoordig de mensen direct via linkedin merk ik, daar komt steeds minder een werving en selectiebureau aan te pas. ( dat is ook niet verwonderlijk als ik zie hoe vaak die bureau's een mismatch doen met waar ze mij voor aanschrijven, iets wat de HR mensen van bedrijven zelf stelselmatig niet doen ).

[SnowDude]

Tja als ik bij ons kijk zie ik gewoon dat er echt een groot te kort is aan echte specialisten.

En met een specialist bedoel ik geen mbo'er met een ICT opleiding. Maar mensen die echt kunnen ontwikkelen en echt kunnen testen.

[wildewouter]

Dit jaar afgestudeerd als Software Engineer en al mijn klasgenoten en ik hadden al voordat we ons diploma echt op zak hadden een baan. Wegautomatiseren gebeurt echt niet zomaar. Software ontwikkelaars zullen toch echt nodig blijven en er zijn er nu veel te weinig van.

[HetMes]

Nonsens. Dat hele outsourcing-sprookje is wel een beetje over. Er is enorme vraag naar ICT-ers en uit armoede worden sommige projecten dan maar geoutsourced. Ja, dan lijkt het booming, omdat daar de rek zit.

[Verwijderd]

Tijd voor loonsverhoging in die sector...

[GeoBeo]

Wat ik dan weer niet snap is dat met het altijd over India/Asie heeft. Alsof dat het enige lage lonen land is? Er zijn landen/culturen die veel meer lijken op die van ons dan India, hele lage lonen hebben en heel hoog opgeleide mensen kennen. Mexico, Brazilie, Colombia, Chile, Zuid Afrika, Polen, Roemenie, Kroatie, etc etc etc. En nee, taal is geen probleem IMO. Als je kunt programmeren betekend het dat je voldoende Engels beheerst.

[Verwijderd]

Helemaal geen geleuter.
Op de kop af werk ik nu 16 jaar in de ICT en ik kan je vertellen dat er vraag zat is op het moment.
Als jij nu Citrix specialist bent, of Sharepoint specialist en je hebt je linkedin profiel netjes bijgewerkt, dan weten de recruiters je te vinden.

India is oud nieuws (en zijn de grote KPN-en en Atossen etc van deze wereld, clubs waar ik zo en zo niet wil werken)
Dat is een tendens en heeft alleen met concurrentie te maken: De een start ermee en de rest moet wel volgen omdat ze anders niet scherp genoeg aan kunnen bieden. En nu komt men er weer van terug. Je weet dat dat gaat gebeuren, managers gaan richting Bangalore, indische mensen krijgen een opleiding in NL en het is allemaal een markt dingetje. Daarom vind ik het zo treurig.

Als ik een ding heb meegekregen is het dit: De ICT gaat zich niet weg automatiseren, het werk verschuift alleen, aan de ICT-er de taak om mee te schuiven.

[Lampie]

Die trend van outsourcen naar India is alweer een beetje geweest. Communicatieproblemen, tijdsverschil en cultuurbrug blijkt vaak toch wel een ding.

[Willybubba]

Nee dat komt door Scrum en andere Agile methoden. Dan heb je geen projectmanagers meer nodig.

[Ceased2Be]

Daarbij zijn er ook teveel projectmanagers van twijfelachtige kwaliteit. De goede kan ik, na 15 jaar, nog steeds op 2 handen tellen.

[Willybubba]

Ook dat inderdaad

De meesten kijken enkel en alleen naar het opleveren op datum, maakt geen zak uit WAT ze opleveren.

[janwillemCA]

Ervaring van huis uit leert mij dat ervaren IT'ers met 20-25+ jaar ervaring hebben toch nog lastig te vinden zijn. Dan heb ik het vooral over (Embedded)Software Engineers en Architecten met uitgebreide kennis van zaken en verschrikkelijk veel ervaring.
Wanneer men dan een kandidaat vindt welke in dit plaatje past, is het salaris vaak ondermaats (Voornamelijk in het noorden). Veel meer dan 60 - 65k per jaar zit er vaak niet in.

Al met al is het aanbod van goede IT'ers naar mijn inzicht nog altijd aan de krappe kant.
Opleidingen op het MBO zijn dan ook zwaar ondermaats. Ook op HBO niveau is er nog zeker veel werk aan de winkel.

[Reactie gewijzigd door janwillemCA op 22 juli 2024 19:44]

[Blaatpraat]

60 - 60k per jaar: 5k per maand.
En dat vind jij ondermaats betaald?

Ik krijg op mijn job (in de IT) momenteel 3k/maand (of 36k in jouw termen).
Vind ik ruim voldoende als iemand in de categorie 20-25...

[Herko_ter_Horst]

Lezen? Het gaat om iemand met 20-25 jaar ervaring, niet om iemand van 20-25.

[Blaatpraat]

Maakt op zich niet veel uit.
Iemand met 20-25 jaar ervaring verdient sowieso meer, maar om recht te hebben op 60-65k per jaar?
Lijkt mij nog steeds enorm veel...
En dan klagen dat hoogopgeleiden nooit werk vinden.

Hier op m'n werk klagen ze al dat ik meer verdien dan de rest omdat ik hoogopgeleid ben, en terwijl de jongste werknemer.

[Herko_ter_Horst]

Er is natuurlijk geen sprake van "recht hebben op". En uiteindelijk doet het er ook niets toe hoe oud je bent, hoeveel jaar ervaring je hebt, of wat dan ook. Uiteindelijk gaat het erom hoeveel waarde iemand toevoegt aan het bedrijf. Opleiding en ervaring zijn indicatoren voor die waarde, en daarmee vooral belangrijk om mensen op te selecteren voordat je ze binnenhaalt.

Als iemand nu vers van de opleiding met nauwelijks ervaring 36k verdient, denk je dan niet dat iemand met 20-25 jaar ervaring 2x zoveel waard is voor het bedrijf?

Kijk, het moge duidelijk zijn, dat een vakkenvuller bij de supermarkt nooit zoveel meer waarde gaat toevoegen, dat een salaris veel hoger dan het minimumloon te verantwoorden is. Dus een vakkenvuller met 25 jaar ervaring zal niet heel veel meer kunnen verdienen dan eentje met 5 weken ervaring.

Maar in een complex, kennisintensief werkveld zoals de ICT, zijn opleiding en ervaring in het algemeen belangrijke factoren voor goed functioneren = waarde toevoegen. Het vergaren van die kennis kost veel tijd en inspanning en daar wordt uiteindelijk voor betaald (en m.i. mag je ook verwachten dat daar voor betaald wordt). En dan is 65k voor iemand met een bak ervaring helemaal niet zo gek, zeker niet als je het vergelijkt met wat er in andere specialistische werkvelden (bijv. advocatuur, medische specialismen) en in andere landen wordt betaald.

[janwillemCA]

Ik ben van mening dat dit soort mensen welke tevens een academische achtergrond hebben zeker meer verdienen. Maar misschien is Nederland daar niet het juiste land voor. Natuurlijk is 60-65k zeker niet slecht, maar het is jammer dat dat blijkbaar toch de grens lijkt te zijn.

[Aaargh!]

Da's zwaar onder de maat voor iemand met zoveel ervaring. Zeker als je bedenkt dat er zat nutteloze managers rondlopen die >10k/maand vangen en een negatieve productiviteit hebben.

[BikkelZ]

In de VS verdient een fatsoenlijke programmeur met 8 jaar ervaring $100.000,- en dan heb ik het niet alleen over San Francisco en de echte goudhaantjes. Gewoon iemand die zijn werk op een normale manier doet. De echte toppers gaan daar nog dik over heen.

[ravenberg]

Ik ben zelf net geslaagd voor Applicatieontwikkeling niveau op het mbo college amsterdam. Daar leerde ik werken met JavaScript en PHP. Tijdens het examen lag de lat best hoog. Er moest een ecommerce web app gebouwd worden in 4 examensessies van 8 uur. Weinig die de app af kregen. Helemaal weinig die uberhaupt mochten deelnemen aan het examen.

Ik moet zeggen dat het niveau daar zo hoog ligt als je het zelf wilt maken. Je leert daar niet veel. Wat je leert pluk je van andere boeken/videocursussen via persoonlijke projecten/stage.

Wat ik voornamelijk heb geleerd is dat er geen opleiding is die je een software engineer maakt. Je moet het denk ik hebben van je eigen interesse en motivatie die je inzet in je jarenlange pad naar meesterschap.

heb me wel ingeschreven voor hbo hoor. Nu die nieuwe leenstelsel er nog niet is grijp ik mn kans .

[janwillemCA]

Uiteraard, Ik zit in het zelfde scheepje als jouw begrijp ik.
Het is maar net hoe hoog je de lat zelf legt. Echter is mijn ervaring van MBO(4) uit dat de "Vakdocenten" echter veel te wensen over laten. Dit was zowel bij Applicatie Ontwikkeling als bij Systeem/Netwerk beheer.

[eehbiertje]

ik heb zelf mbo 4 gedaan (3/4 jaar vol gemaakt dus niv 3 behaald)

docenten kon je het bij ons niet echt noemen..
je kreeg gewoon je "opdrachten" en die moest je aan het eind van het jaar af hebben..

had je vragen dan kon je bij je "babysitter" in het lokaal terecht om als antwoord te krijgen dat je moest wachten tot meer mensen hetzelfde probleem hadden / met die opdracht bezig waren..

les/uitleg kregen we niet helaas

nu stimuleert dat niet echt en waren wij ook meer bezig met ongein op het netwerk dan de opdrachten zelf.. (omdat dit veel interessanter was)

hier heb ik meer dingen geleerd dan in mijn opleiding zelf..
heb ik er iets aan? persoonlijk wel op "professioneel/werk" gebied niet..
omdat ik er geen papiertje voor heb wordt ik daar helaas ook op afgewezen bij werkgevers..

verder merk ik ook gewoon dat veel vacatures gewoon werving / database aanvullen zijn..

[Reactie gewijzigd door eehbiertje op 22 juli 2024 19:44]

[eelco74]

65K per jaar is meer dan 2 keer modaal, dan behoor je tot een select gezelschap...

[aval0ne]

Hangt er vanaf of je het over netto of bruto bedragen hebt.

[eelco74]

modaal is 2900 en en beetje bruto per maand. Dus dan is 65K bruto 2 keer modaal en 65K netto hebben we het dan maar niet over. Want dan is het statement dat ICT'ers onderbetaald zijn helemaal niet aan de orde.

[freedzed6]

Modaal is dit jaar bruto 2585 euro...dus je praat mooie weer.

[eelco74]

Het modaal inkomen 2014 volgens het CPB is € 34.500.
Dat is 2875 per maand

[Verwijderd]

Altijd bruto...

[janwillemCA]

Bruto uiteraard

[Wailing_Banshee]

Ervaring van huis uit leert mij dat ervaren IT'ers met 20-25+ jaar ervaring hebben toch nog lastig te vinden zijn.

Vind ik op zich niet zo heel erg vreemd. De groep ICT'ers met die 20-25+ jaar geleden begonnen was natuurlijk nog maar redelijk klein. Het is pas echt een beetje op de kaart gezet met het Y2K probleem. Dus de groep 15-20 jaar ervaring zal iets groter zijn (nu is natuurlijk de vraag hoeveel mensen die toen de ICT in gegaan zijn, er nu nog steeds iets me doen...)

[bitshape]

Y2K erin, 8 jaar later opgestapt en ICT vaarwel gezegd. Alleen nog kleinschalig cq. prive-ICT hier voor mij. Vooral het ganse disrespect, 'een nummertje zijn' & 'als vuil behandelt worden' hebben daar sterk aan bijgedragen.
Bevalt me nu prima zo! Ze zoeken het maar uit...

[sanane]

Waarom merk ik daar na 143 sollicitaties nog niks van!!
ik kan nergens beginnen als starter..

elke keer zelfde onzin..

[hackerhater]

Welke richting heb je gestudeerd?
Toen ik afstudeerde (2 jaar geleden) kon ik kiezen uit 12! bedrijven en nu ik 2 jaar later rond het kijken ben heb ik weer tich reacties.
Inclusief aanboden van 3000+ per maand + auto.

[Niosus]

Als student die freelance werk doet krijg ik veel meer aanvragen dan ik tijd voor heb, en ik zoek zelfs niet eens actief. Gewoon mensen en bedrijven die via via bij mij uitkomen en interesse hebben. De vraag is er echt wel, zowel om vast aan te nemen als voor freelance projecten.

Als je toch geen werk kan vinden zou ik aanraden om wat ervaring op te doen. Werk zelf een paar dingen uit zodat je dat op je CV kan zetten. Eenmaal dat je een minimum aan ervaring hebt en kan aantonen zou het toch echt wel los moeten lopen. Ikzelf ben begonnen als vrijwilliger bij een website. Heel onnozel maar daardoor heb ik meer werk gevonden, waardoor ik meer connecties had, waardoor ik meer werk kon vinden etc etc.

Je kan ook aan wat opensource software bijdragen zolang je nog geen baan hebt. Dat geeft sowieso een veel beter beeld tijdens het solliciteren dan als je een tijd "gewoon werkloos" bent geweest. Als ze op je Github account zien dat je de laatste 6 maanden aan open source hebt gewerekt weten ze direct dat je passie en motivatie hebt en zo kan je je kansen weer verhogen.

[Reactie gewijzigd door Niosus op 22 juli 2024 19:44]

[BoringDay]

Netwerken

[biglia]

Als starter is het inderdaad moeilijk. Kijk niet naar het loon en probeer gewoon ergens binnen te geraken. Bouw twee jaren ervaring op en je kan op meerdere plaatsen beginnen.

Start nu even een privé projectje als je nog een tijd werkloos bent. Je kan hierover vertellen op je sollicitaties en ze zien meteen dat je gemotiveerd bent en bereid bent om te leren.

[Reactie gewijzigd door biglia op 22 juli 2024 19:44]

[Maulwurfje]

En hoe zit het met de MBO groep? Vaak hoor ik toch vaak de vraag voor hoger geschoolde mensen, terwijl er ook een grote groep MBO'ers is die zitten te wachten op werk.

[AllSeeyinEye]

En daar zit m het probleem, dat overigens in veel meer beroepsgroepen het geval is. Er zijn simpelweg teveel MBO'ers. Dus is het aan die MBO'ers om door te gaan studeren voordat ze de arbeidsmarkt opduiken!

[Maulwurfje]

Ik beweer niet dat intelligentie rekbaar is. En het Nederlands onderwijs systeem is geweldig stapelbaar. Alleen toch, iemand met MBO3 gaat niet naar het HBO.

[Sinned123]

Een HBO opleiding heeft niet alleen met intelligentie te maken, maar ook met werkhouding,samenwerken enz enz.
Ik kan me niet voorstellen dat een HBO zorg inhoudelijk zwaarder is dan een BI opleiding.

[hackerhater]

Vergis je niet daarin.
HBO SO krijg je veel dingen die je richting de architect-rol duwen.

[tweaker2010]

Dat dus. En er zijn teveel HBO'ers die momententeel MBO werkzaamheden verrichten. Wat er dus voor zorgt dat de net afgestudeerde MBO ICT-ers amper aan de bak komen. Het is een vicieuze cirkel.

[Kaw]

Ik werk bij een bedrijf met ongeveer 500 ICT'ers. Daar zie ik geen toename in het aantal aanvragen voor nieuwe ICT'ers. Meer en meer wordt uitbesteed aan Nederlandse grootmachten die het weer uitbesteden aan Indiers.
Het is de dienstverlening en doorlooptijd niet ten goede gekomen en de kosten zijn omhoog gegaan. Om over bureaucratie en problemen met geldpotjes en SLA's maar helemaal te zwijgen.
Het management is overigens best tevreden. De flexabiliteit (kuch) is er enorm op vooruit gegaan en de regiefuncties (vriendjes) zijn verdubbeld. (om over het vermoeden van nieuwe badkamers en rijkelijke kerstpakketten maar te zwijgen)

Toch hebben we de afgelopen jaren een paar SE'ers proberen aan te nemen. Dat ging gek genoeg behoorlijk stroef. Er kwamen maar weinig goede brieven binnen en meestal waren het ouderen zonder aanwijsbare diploma of ervaring met wel heel veel bedrijven. Ik had in feite de afgelopen 2 jaar wel 4 keer aangenomen kunnen worden bij dit bedrijf, omdat ik veel beter zou zijn als het aanbod. En dat terwijl ik mezelf acht als een doorsnee HBO ICT'er. Ook ben het afgelopen jaar een paar keer gevraagd door gezanten van een externe partij of ik interesse zou hebben in een overstap.

Al met al denk ik dat de vraag niet echt toeneemt, maar tegelijk dat het aanbod van gekwalificeerd personeel nog steeds redelijk krap is. Oftewel nog prima kansen voor de gemiddeld afgestudeerde ICT'er.

@Astrix, ik denk dat je met een MBO ICT diploma nauwelijks nog aan de bak komt. Nederlandse ICT functies verschuiven steeds meer naar architectuur, management (regie over de externe partijen) of specialisme wat niet uitbesteed kan worden.
Als ik nu HBO student zou zijn, dan zou ik me specialiseren in een hoog technisch specialisme. Er is ruimte op bijv. het gebied van GeoICT, embedded technology, BI systemen (erg hot nu) en in mindere mate ook nog wel op bijv. SAP.
Universitaire studenten hebben de ruimte om architect te worden of zich bedrijfskundig te specialiseren in een regiefunctie. Neem er bijvoorbeeld eens een ICT & Recht vak bij.
Probeer ook eens of het mogelijk is om bijv. een Prince2 foundation opleiding er bij te doen. Bedrijven zien dat wel als een plus.

[Reactie gewijzigd door Kaw op 22 juli 2024 19:44]

[Astrix]

Dus waar het eigenlijk op neer komt, er zijn vele kandidaten die een ICT opleiding volgen, maar er zijn onder groep afgestudeerde ICT'ers te weinig goed gekwalificeerde ICT'ers waar het bedrijfsleven echt wat aan heeft. Of de gehanteerde ICT opleiding sluit niet goed aan, op de eisen van het bedrijfsleven....

[twkr18526]

Wat zijn die eisen waar kandidaten niet aan voldoen?

En wat kunnen ze er zelf aan doen?

[Verwijderd]

Precies, misschien wordt "gekwalificeerd" momenteel ook wel erg overdreven door werkgevers.

[Astrix]

De eisen waar aan kandidaten aan moeten voldoen zijn heel simpel, ervaring, dienstverlenend, en probleemoplossend, goed kunnen luisteren, communicatieve vaardigheden, maar hoe krijg je die sociale vaardigheden. Investeer in jezelf.
.
Door jezelf als vrijwilliger aan te melden voor klussen, mensen helpen met hun computerprobleempjes, waar? Nou gewoon in een buurthuis, of wijkcentrum. Zo leer je sociale vaardigheden, die je nog niet had, of nog niet goed beheerste.
Want een buurtbewoner (particulier) met zijn/haar computerprobleem, en later in de praktijk het bedrijfsleven een (betalende) klant dat een probleem heeft met een computer verschillen niet zoveel van elkaar, ze kunnen allebei in hun onwetendheid wat dat betreft even moeilijk doen. en (on)begrip hebben. Je leert te luisteren naar hun verhaal, en hun computer problemen. En doet ervaring in het oplossen van diverse computer problemen.
.
En wanneer je die vrijwillige activiteiten weet te combineren met je studie, dan doe je een zee aan ervaring op. En die ervaring, aan het einde van je studie, kan weer een pluspunt zijn, bij eventuele sollicitatie, omdat je al weet hoe je effectief onder allerlei omstandigheden, problemen moet oplossen, hoe je moet omgaan met klanten, want dat leer je niet bij de ICT studie.
.
Want het bedrijfsleven klant wil maar één ding, en dat is dat het systeem of het nou een server is of wat dan ook. En dat is, dat, het betreffende ICT apparaat, het gewoon doet, eigenlijk het zelfde als die buurtbewoner met zijn pc/laptop. Want reken maar dat een buurtbewoner die met zijn/haar defecte laptop langskomt, die het gisteren nog gewoon zou hebben gedaan. Ook behoorlijk lastig kan zijn. Maar het verschil met het bedrijfsleven en een buurtbewoner is, dat die buurtbewoner nog waardering toont als je het probleempje hebt weten op te lossen. Het bedrijfsleven, betaald ervoor, vindt het niet anders dan net zo vanzelfsprekend als dat de zon elke dag opkomt en weer onder gaat.
.
Maar als je na je studie, bij sollicitaties kan aantonen, dat je gedurende je studie, als vrijwilliger een paar uurtjes buurtwerk hebt gedaan, door belangeloos, in een buurthuis of wijkcentrum mensen te helpen met hun computerprobleempjes, of ouderen hebt helpen leren om te gaan de computer of iets dergelijks. Dan toon je initiatief, maatschappelijke betrokkenheid, en dergelijke. En je laat zien dat je al wel de nodige praktijk ervaring hebt opgedaan. Zo investeer je in jezelf, en zorg je, dat je past, in het profiel van het type ICT'er, waar het bedrijfsleven naar op zoek is. Door nu al tijdens je ICT studie te investeren in dergelijke sociale vrijwilligers activiteiten, verhoog je, in de toekomst na het slagen, wel je kansen om uiteindelijk aan de slag te kunnen bij een ICT bedrijf. ICT vaardigheden bestaan uit meer dan alleen maar dat diploma, En denk niet wanneer je eenmaal binnen bent, in de ICT sector, ik ben er, blijven bijscholen, om de ICT ontwikkelingen bij te kunnen houden. De ICT blijft altijd in beweging.