Wat ik hier vorige week aankondigde, blijkt dus werkelijkheid te worden.

Technisch projectleider 2 weken in verlof, en plotsklaps vallen er lijken uit de kast. Niet een kleintje, maar een hele bos.
Ze stinken gelukkig niet al te hard. Das ergens een voordeel.

Plotsklaps blijkt de verwerking van een van onze businessprocessen te traag te zijn.
En dan mag je dus beginnen graven. Vooral heel tof als je, net als ik in dit geval, er feitelijk niks mee te maken hebt gehad.
Als je bijvoorbeeld de analyse gemaakt hebt van dat onderdeel, of je hebt de programmatie zelf gedaan, dan kan je hier normaal je weg redelijk eenvoudig in vinden. Wanneer je enkel een uitleg hebt gekregen (en in feite mag je dan al van geluk spreken) om het zootje te onderhouden, dan is dat dikke miserie. Wanneer er dan een call binnenkomt in de stijl van : “het is te traag, maar je kan het sneller doen op deze manier”, dan kan je het gaan herschrijven.

Ow, hoor ik u denken. Herschrijven, is dat niet een beetje vlug?
Tja, wanneer de klant je een andere manier van werken aanreikt en die manier blijkt te kloppen, en het enige argument je hebt om het niet te doen is “we werken normaal zo niet”, hoe lang hou je dan zo een argument vol?

Nu heb ik vandaag dus het grootste deel reeds herschreven, en ik ben ervan overtuigd dat ik het probleem wel opgelost krijg, maar toch : AAAARGH!
Sorry hiervoor, moest er even uit.

Ik durf me dan soms wel enkele vragen te stellen.
Ok, het is onze verantwoordelijkheid om de eisen/vragen/problemen van de klant in te willigen/te beantwoorden/op te lossen, maar is het nu echt zoveel gevraagd dat klanten nu eens leren om alles zo eens een beetje tijdig uit te testen?
Kwestie dat op zijn minst die problemen kunnen opgelost worden door iemand die er iets van kent. En niet alles in de nek geduwd wordt van die ene pechvogel die overblijft op het einde.

Ik weet, gebruikers van IT programma’s ter velde, dat u zich hier geen zak van aantrekt. Het is tenslotte uw zaak niet (en al helemaal uw fout niet). U vindt gewoon een probleem. U meldt dit, en wie dit oplost doet er voor u niet toe. Of hoe hard die mens afziet. Of welke louche trukken hij daarvoor uit zijn hoed moet toveren.

Maar toch, hoop ik ergens dat al wie dit leest (waarschijnlijk ijdele hoop), en ooit nog eens een wijziging aan een bestaande applicatie aanvraagt, dat u deze wijziging dan ook zo snel mogelijk grondig test nadat deze is opgeleverd. Kwestie van asap de mogelijke errors/problemen bij de juiste ontwikkelaar te krijgen. En niet 2 maand later bij een pechvogel.

Ik dank u.

Ken je de situatie waarin er iemand van je project afgaat?

Plotsklaps blijken er in de stukken die hij/zij het beste kende een aantal lijken uit de kast te vallen.
En wie mag de miserie dan oplossen? En uitzoeken hoe het precies in elkaar zit?
Inderdaad, de overblijvende(n). Diegene die de pech heeft om iets langer op het project te zitten, en dus wordt verondersteld om het volledig te kunnen onderhouden.

“Jamaar, je had toch overdracht gekregen over die stukken? Dan weet je toch hoe die in elkaar zitten?”, krijg je op zo een moment van je functioneel projectleider te horen.

Dat belooft voor volgende week, dan is mijn technisch projectleider 2 weken in verlof…