Medewerkers ergeren zich het meest aan trage software op de werkvloer. Bijna één op de vijf (19 procent) ziet een trage reactietijd van software als grootste ergernis. Daarnaast storen werknemers zich aan de snelheid van het internet op kantoor (14 procent) en internetstoringen (13 procent).
Dit blijkt uit onderzoek van SPS, specialist in it-beheer en ontwikkelaar van it-beheersoftware Gensys, onder ruim duizend medewerkers uit verschillende branches.
Volgens de onderzoekers ervaart 12 procent hinder door verouderde apparatuur waarmee zij werken. Slechts 1 op de 10 respondenten (9% procent) zegt helemaal geen last te hebben van it-ergernissen op kantoor. Van de ondervraagden besteedt 45 procent meer dan een half uur per week aan problemen met de ict-voorzieningen. Bij 25 procent van de respondenten is dat meer dan een uur per week.
Linda Verweij, coo van SPS, licht toe: ‘Het is zorgwekkend om te horen dat werkend Nederland zoveel last heeft van ict-problemen op kantoor. Dat zou vandaag de dag niet meer voor mogen komen. Op nummer een staat de reactietijd van software, terwijl dit tegenwoordig eenvoudig in kaart te brengen is. Het is niet meer nodig om zelf een diagnose te stellen op basis van wat de eindgebruiker vertelt.’
Online tools
Ze wijst erop dat it-professionals er met online tooling voor kunnen zorgen dat zij real-time inzicht hebben in de performanceproblemen die eindgebruikers ervaren en de achterliggende oorzaak hiervan. Verweij: ‘Door echt te weten wat de eindgebruiker ervaart, wordt de eindgebruikerstevredenheid verhoogd en performanceproblemen voorkomen.’
Wat ik me dan toch afvraag: hebben deze werknemers internet echt nodig voor hun werk dan?
Veel van de internetschermen die ik op kantoor zie wijzen toch vooral naar nieuws-sites, muziek en social media.
Tsja, vind je het gek dat ze klagen over performance problemen? Welke programmeur begrijpt hoe een computer werkt (in grote lijnen)? Welke programmeur leert wat een applicatie snel maakt, en wat je zoveel mogelijk moet voorkomen in een applicatie? Geen enkele, ze moeten kijken naar ‘functionaliteit’, of de ‘business rules’ er goed in zitten etc. Hoe het er in zit maakt niet uit, als het te langzaam is dan koop je gewoon snellere hardware was het credo.
Dat de functionaliteit er in zit is vanzelfsprekend, dat wordt immers gevraagd? Het is de taak van de programmeur om zo efficiënt mogelijke programma’s te schrijven, en de taak van de systeembeheerder, storage beheerder, netwerkbeheerder etc. om all resources optimaal in te zetten. In plaats daarvan hebben we graag Fisher Price interfaces, je klikt een beetje en klaar is kees. Wat er onder water gebeurd, niemand die het weet. Dat is mooi, want dan heb je geen gekwalificeerd personeel nodig, dus dat spaart kosten. Dat de hele organisatie vervolgens last heeft van trage applicaties, en onnoemlijk veel uren verstookt, dat snappen we niet.
Ik heb zonder de applicatie te wijzigen systemen 10 keer zo snel gekregen, gewoon door beschikbare resources goed in te zetten, instellingen te wijzigen enz. Het is geen rocket science, maar je moet gewoon weten hoe alles functioneert, en aan welke knoppen je kunt draaien. ICT zou een ambacht moeten zijn, en dat zijn we vergeten met al die hypes en bloatware van tegenwoordig.
Helemaal mee eens, Dirk. Ik ben zelf als assembler programmeur begonnen en begrijp hoe het werkt onder de motorkap.
De laatste jaren hebben we zelf een aantal .net programmeurs in huis begeleid om al die overwegingen die jij opnoemt mee te nemen (maar denk ook aan schaalbaarheid, wat gebeurt er als ik niet 2 maar 200 gebruikers aangelogd zijn). Op school (HBO) wordt dat ze niet bijgebracht. Ondertussen zien ze ook de noodzaak hiervan en hebben we met een klein team goeie mensen heel veel bereikt. We mogen niet generaliseren, maar over het algemeen is de kwaliteit van opgeleverde software dramatisch. Ik denk dat we rond de 20 programmeurs in (tijdelijke) dienst hebben gehad die heel slechte kwaliteit leverden (we zijn bijna klaar met het opruimen van de wrakstukken). Ik vrees dat dat de standaard is, want al deze lui draaien al jaren mee. Ik gebruik zelf ook vaak de kreet ‘ambacht’ als het om ICT gaat.
Optimalisatie is een ondergeschoven kindje geraakt. Met frameworks op frameworks die weer op frameworks werken, is programmeren lekker snel en makkelijk geworden en de hardware is toch snel zat? Toch?
Misschien een idee om dan ook eens wat meer aandacht te hebben voor eigenschappen van de verschillende soorten netwerken? Zeker nu we met zijn allen steeds meer op een wolk leven en werken?
Je zult verbaasd zijn hoeveel ontwikkelaars en testers me aankijken alsof ze het in Keulen horen donderen als ik ze vraag of ze met hun non-functionals ook rekening hebben gehouden met trage netwerken van 100 ms en meer – iets wat over grotere afstanden eerder regel dan uitzondering is.
Om vervolgens toch een applicatie op te leveren die honderden turns nodig heeft voor de uitvoering van een willekeurige gebruikersactie.
🙂
Ah ja, die wolk, ook zo’n prachtige hype. Je leest dan van die prachtige verhalen van enthousiastelingen die alle storage in de wolken willen hebben, want dan is zo goed voor je TCO, en dat is het belangrijkste. Dat je gemiddelde random database IO geen 10ms kost maar 200ms, en je applicatie dus 20 keer langzamer wordt, dat begrijpen ze dan niet. Of ze willen het oplossen met een snellere internet verbinding.
Die mensen lopen dus met hun hoofd in de wolken en zien geen hand voor ogen.
Dirk, helemaal mee eens.
Het probleem is uiteindelijk dat de klant wel kan beoordelen of iets wel of niet werkt (functioneel) maar de efficiency en performance niet kan beoordelen. Hiervoor is of technisch inhoudelijke kennis nodig, of mogelijkheid oplossingen te kunnen vergelijken. Dat is bij maatwerk vrijwel nooit het geval. En ‘certificaten’ bieden een schijnwerkelijkheid. Certificaten zijn in feite ook een soort Fisher Price voor Managers. Het is de vraag of Managers niet altijd moeten worden bijgestaan door technische consultants bij opdrachtverstrekking van IT opdrachten, zoals een leek meestal een makelaar in de arm neemt om een huis te kopen of verkopen.
Het overgrote deel van de .NET/Java ontwikkelaars die ik ken hebben geen benul van waar ze mee bezig zijn. Dat is de keerzijde van managed code die zorgt dat slordigheid veel minder snel en hard wordt afgestraft. Hogere programmeertalen zijn het probleem evenmin als rekenmachines dat zijn, maar rekenmachines zijn er niet om rekenvaardigheid overbodig te maken maar enkel voor efficiency. Daarom leer je op school eerst rekenen zonder rekenenmachine en mag je pas een rekenmachine gebruiken als je weet wat je aan het doen bent en waarom.
Ik heb mij altijd voorgesteld dat er vroeg of laat een soort energie-label moet komen voor software (lagere efficiency betekent immers lagere efficiency, performance en slechtere gebruikerservaring en alles bij elkaar lagere productiviteit, en dan hebben we het enkel nog over performance terwijl er in de praktijk daardoor veel meer incidenten zijn en workarounds en allerlei extra kosten op hardware en mankracht. Ook geeft het hogere CO2 uitstoot). Alleen met zo’n energielabel zou er aandacht komen voor kwaliteit.