'Psychische problemen onder it'ers vier keer zo hoog als gemiddeld'

Maar het stellen van grenzen hoort ook bij je baan. Ik zeg: jij kan geen nee zeggen. Dat is pas erg.

[Reactie gewijzigd door pennywiser op 14 juni 2008 21:40]

Eventjes een response op je vaststellingen SirDarkAngel:

"Je beschrijft dan ook een bedrijf waar totaal geen structuur in zit."

Ik beschrijf een bedrijf waar een enorme structuur in zit. Dit is een firma met maar mensen:

- 2 Bazen ( nooit aanwezig in de firma, beide hebben hun eigen banen ).
- 1 Manager ( om de paar weken een paar uur aanwezig, en verkoopt de grootste onzin )
- 1 Office Manager ( Taken: Analist, Communicatie Klant, Opleidingen, "Ja" knikker )
-- 4 Perl Programmeurs ( CRM programming, Support, Servers onderhoud enz ).
- 1 Grafische designer ( CSS, Layout, graphics, ... ).
- 1 Verkoper ().

Dit is de structuur. Alles van de programmeurs moet via de OM gaan. De OM gaat naar de Manager, de Manager gaat naar de 2 Bazen, en via versa. De verkoper & designer zijn de buitenbeentjes. Zoals je ziet, een kleine firma die puur designed is als een multinational, met allemaal leuke niveau's van communicatie.

"Het is niet de taak van de projectleider om hier extra dagen bij op te gaan tellen"

Het spijt me, maar dat is juist wel de taak van de Project Leider. Deze persoon staat in voor het in goede banen leiden van de taken. Zoals je ziet, is er op zich geen Project Leider in de firma ( was er ooit, maar deze is snel verwijderd geweest ).

Onder normale omstandigheden zal een PL kijken naar de dagen die x programmeur voorstelde. Deze weet dan welke de capaciteiten zijn van zijn of haar programmeurs. En vaak zal een goede PL de tijdbestek met 1.5* verhogen, afhankelijk van de capaciteiten van zijn/haar programmeurs. Dit dat meer of minder zijn, maar 1.5 is zowat een regel.

"zal hij deze analyse niet moeten accepteren".

Dit is idd al meerdere malen gebeurt. Weet je wat het response hierop is?

a) Je neem het op met de Office Manager. Deze geeft aan de Analyse meer dan goed genoeg is. Hij heeft ze gemaakt, verwacht je een ander antwoord?
b) Je gaat over zijn hoofd, en je spreekt met de Manager. Deze kijkt een beetje verwilderd, komt af dat het niet kan, smeert je een beetje boter op de boterham, en doet niets. Zijn taak zoals hij zelf aangaf, is "vuurtjes blussen".
c) Je gaat rechtstreeks naar de baas, en klaagt deze onwerkbare analyse aan:
c1) Al je communicatie wordt genegeerd.
c2) Als men reageerde, wordt er not to the point gereageerd.
c3) Het is uw eigen schuld dat je niet om kan met de analyse.

Dit is de realiteit...

"Een programmeur zal hier weinig van mogen merken."

Dit is ook zo een zaak. De financiën. Als programmeur weten we welke punten in de analyse staan, en welke niet. We weten welke zaken extra's zijn ( en buiten het contract vallen, zodus extra voor betaald moet worden ). Normaal is het de Project leiders taak om deze extra's te melden.

In praktijk zoals je zag geen Project Leider, maar een Office Manager, en deze meld deze weinig tot niet. Ondanks dat we het genoeg gemeld hebben. Gevolg, er wordt enorm veel buiten gesmeten "gratis". Tja, het is makkelijker als je gewoon ja knikt naar de klanten, en het gratis uitvoert, dan dat er een discussie ontstaat of men wel of niet moet bijbetalen he...

Je hebt gelijk, in theorie als programmeur zou je je in normale omstandigheden niet moeten bezighouden met de financiën, slechte planningen, enz. De praktijk is anders dan de theorie niet waar...

"Hierbij moet een programmeur ook niet van iedereen accepteren wat er wordt gezegd."

Het spijt me SirDarkAngel, maar dit alleen geeft aan dat je idd nog nooit gewerkt hebt als programmeur...

Het is zo dat je kan later zeggen: "Jammer, ik heb gezegd voor xxx project yyy tijd, en in praktijk was er maar yyy/2 gegeven"... En nu? Leuk dat je gelijk hebt... Maar wat nu???

De klant staat links te roepen, de bazen staan rechts te roepen... Wie moet het weer oplossen? Idd, die dat onderaan de ladder staan. Het is mooi dat je gelijk hebt, maar weet je, het wordt snel afgezaagd als je altijd gelijk hebt, en toch maar constant de problemen mag fixen.

Als je de problemen verschillende malen herhaalt, wordt je afgeschilderd als, ik quote: "Niet loyaal tov de firma". Geen joke. Als je constant zo moet werken, weet je het effect? ...

Ik zal je even een voorbeeld geven van nog geen paar dagen geleden:

Je krijgt een planning voor een aanpassingen dat je dient uit te voeren. Je vraagt waar de analyse is van de aanpassingen? Je krijgt als antwoord: "Die is er niet, gebruik de scope bepaling". Idd, dat is geen grap was ik schrijf.

Of, je moet beginnen aan een project ( zoals gewoonlijk, 1 regel tekst is de planning ). Er is geen analyse te vinden voor de klant ( waar ze hoort te staan ), en de Office manager ( / analist ) is op vergaderingen gans de dag. Wat blijkt, a) analyse is nog op de OM's PC, b) analyse is niet af, c) analyse is niet goedgekeurd door de klant; maar je moet wel beginnen eraan te werken... M.a.w, zegt de klant dat de analyse niet voldoet, en het totaal anders moet, is je werk verspilt...

Ik zal je nog enkele leuke voorbeelden geven van hoe het niet moet:

Een normale ontwikkeling cyclus bevat: x aantal maanden coderen, dan een grondige test procedure, en dan pas releasen naar de klant zijn haar test site, en dan pas naar productie. Dit lijkt mij toch de meest normale procedure stappen?

Onze procedure is: Release alle aanpassingen die je gemaakt hebt voor x klant, iedere dinsdag & donderdag! Ik herhaal, ik zuig dit niet uit mijn duim... Krijg je dinsdag een opdracht, dat is dezelfde dag af, dat moet het dinsdag relased worden.

O ja, en 80% van de releases zijn direct naar de productie site's van de klanten!!! Je wilt niet weten hoeveel tijd we verspillen aan database cleanups, omdat de meest onbenullig bugje de helft van je data begint te corruptere...

Test procedure? Onbestaand... Men verwacht dat alles perfect werkt binnen het tijdsbestek dat je kreeg. Een CMS van 420.000 code regels ( zonder de lege regels, commentaar enz ), dat enorm in elkaar gekoppeld zit...

O wacht, voer deze aanpassing uit, en de Office Manager vind dat 1 uur genoeg is voor het coderen ervan. Met een beetje geluk, en speel coderen, kan je in één uur dat coderen. Maar je kan het niet deftig testen... Maar o wacht, in dat uur kan je ook nog support telefoons krijgen van klanten, je dient de aanpassingen in te boeken, je mag secretaresse spelen, want men is te gierig om een telefoon centrale te kopen, zodus de programmeurs spelen secretaresse, want daar staan de telefoons enz ... M.a.w, ononderbroken werken bestaat niet...

Maar weet je, als je denk dat dit erg is? Hier zijn nog een paar leukere. Als de Office Manger een afspraak heeft met x klant die week, mag je zeker zijn, dat je die week aan x klant zijn / haar projecten zal werken. En als de vergadering is in de namiddag, zal er in de voormiddag nog gecodeerd worden, en released worden naar de productie! site van de klant, zodat de Office Manager kan laten zien aan de klant hoe goed we werken voor hem. Is de vergadering gedaan, plop, laat x klant vallen, en nu naar y klant werken, want men heeft overmorgen een vergadering met y klant...

En ik weet het, je zal roepen: "Jamaar, op je strepen staan, en zo iets niet toelaten". Als je dat doet, blijft men none stop zagen dat je het moet doen. Als je dan nog blijft weigeren of lastig over blijft doen, zal men snel boven je rug gaan, en effen de baas op je dak sturen.

M.a.w, men breekt je wilskracht na een tijdje. Er is een dik verschil tussen op je strepen staan, en het vol te houden in zo een situatie. Als je het een tijdje doet, ben je een slechte werknemer, want je spreekt tegen.

Ik geef toe, deze firma is waarschijnlijk de meest amateuristische wat er bestaat. Een kleine firma die graag doet dat ze groot is. Vele regels, procedures enz, die allemaal bedacht zijn door de mensen die er niet mee moeten werken. What else is new?