[ALG] hoe meet je prestaties van een programmeur

[Cuball]

Ik had graag es geweten hoe er bij bedrijven de prestaties van een programmeur gemeten wordt. Binnen ons bedrijf worden voornamelijk J2EE applicaties geschreven. Aanvaanlijk werd er eerst overwogen om het aantal "genormeerde" schermen als maat te gebruiken, maar dit is uiteraard bijna niet meetbaar, en niet elk scherm heeft even veel code natuurlijk en hoe definieer je dan ee "genormeerd scherm". Volgende voorstel van het management team was om een project (deel) in te delen in blokken van uren, bv 40 - 80 - 120 - 160 ofzo, die kennen ze dan toe aan een project (deel), en jij als programeur kan dan kiezen hoeveel tijd je nodig zal hebben voor het deel, bv een deel dat 80 uren is toegewezen, kan jij als programmeur zeggen dat je er 40 uren zal over doen, dit is dan een maat van prestatie. Maar dit is uiteraard zeer moeilijk mede omdat we een beginnend bedrijf zijn en volledig nieuw in de technologie. Probleem bij veel van deze voorstellen is dat het controleren van de prestaties ook een tijdrovende bedoening is wat natuurlijk gepaard gaan met kosten...

iemand nog andere ideeën ?

[djlinsen]

Waarom wil je als een schoolmeester de prestaties van je werknemers zo nauwkeurig volgen? Denk je dat ze dan harder gaan werken? Natuurlijk moet je in de gaten blijven houden dat er geen mensen heel de dag uit hun neus zitten te vreten, maar normaal gesproken zijn werknemers volwassen genoeg om dat zelf in te zien. Het is natuurlijk ook een kwestie van vertrouwen, hoe denk je dat het bij je werknemers overkomt als je geen vertrouwen in hun prestatie hebt?

[Macros]

Als je het weet mag je het zeggen . Dit is 1 van de grote problemen in de industrie.
Overal heb je aan de hand van de hoeveelheid regels (K-lines) en de hoeveelheid function points. Beide zijn niet zaligmakend.
Persoonlijk ben ik dan altijd voor een meer sociale manier. Als student assistent moest ik regelmatig achterhalen hoeveel werk elk persoon in een 4 mans groepje had verricht om te bepalen hoe hoog de individuele cijfers moesten zijn. Ik vroeg de groepjes of ze de auteur(s) van elke source file in de file wilde opnemen. Sommige deden dat dan toch niet, en dan moest ik achterbaksere manieren bedenken. Dus vertrouwens band met iemand opbouwen en dan in een normale discussie vragen hoe hij vond dat de andere groepsleden werkten.Vaak schafte dat redelijk veel inzicht in de groep, beter dan en automatische interview tool wat ze in moesten vullen.
Als je zelf in zo'n team zit dan kan je het beste op je gevoel af gaan. Hoe complex is het programmeer probleem, hoe groot is het, hoe snel deed hij er over en hoeveel bugs zaten er dan nog in. Hoe 'elegant' was zijn oplossing. Deze dingen dan een wegings factor geven aan de hand van wat jij belangrijk vind en dan werk van programmeurs beoordelen op een schaal van 1 tot 5 ofzo en je hebt een duidelijk overzicht en momentopname.

[elnino]

Cuball schreef op 04 september 2004 @ 12:07:
bv een deel dat 80 uren is toegewezen, kan jij als programmeur zeggen dat je er 40 uren zal over doen, dit is dan een maat van prestatie.

Bedenk wel dat sneller niet altijd beter hoeft te zijn. Vaak is het mogelijk om in een paar uur een 'quick and dirty'-oplossing ergens voor te vinden die ook wel werkt, maar bijvoorbeeld later slecht uitbreidbaar blijkt te zijn.

Ik denk zelf, eerlijk gezegd, dat het vrij lastig wordt programmeurs op een objectieve en onbetwistbare manier te beoordelen, maar goed ik ben zelf ook geen expert op dit gebied.

[Zoijar]

Je kan moeilijk aan code meten. Er is namelijk ook nog simpele en moelijke code; je kan bv 500 regels schrijven in een uur als het om iets simpels gaat. Maar het komt ook voor dat je een stuk of 20 hele moeilijke regels moet schrijven en dat een hele dag duurt. Daarom is dat uren idee ook lastig. Het is moeilijk van te voren in te schatten hoe lang iets gaat duren.

[gorgi_19]

* gorgi_19 zou zich er eigenlijk ook niet zo druk om maken....

Er is een bepaalde taak; die gedaan moet worden. Die is NIET in uren uit te drukken, hoe maf dat ook klinkt. Dat wil je ook niet. In drukke tijden zal je het bijvoorbeeld erg waarderen als iemand ipv 40 uur 45 uur maakt. In rustige tijden moet je dan ook niet moeilijk doen als iemand 35 uur draait ipv 40.

Gewoon geregeld teamoverleg, vragen waar iedereen mee bezig is. Je kan beter zorgen voor een goede bedrijfssfeer, waarin iedereen wil werken, 'eigenaar' te maken ook van het product. Ik vraag me af of je blij wordt van mensen die alleen maar naar de hoeveelheid output kijken.

Trouwens, wat is lang? Ik heb wel eens een dag gedaan over 200 regels code, omdat er nogal wat onderzoek bij kwam kijken. Aan de andere kant kan ik dmv van een makro 600 regels code in 10 seconden genereren.

Je moet mensen beoordelen in het algemeen functioneren, niet op de prestaties per uur. Blijkt hij in een project niet mee te kunnen en 'te langzaam' te werken of 'te weinig' te doen, dan kan je eens een gesprek met hem aangaan, kijken waar het probleem ligt. Blijkt het dat hij gewoon ondermaats presteert, dan is het jammer Voor de meesten zal dit alleen niet nodig zijn

[ Voor 33% gewijzigd door gorgi_19 op 04-09-2004 12:26 ]

[djengizz]

Puur op tijd lijkt mij een beetje kort door de bocht. Ik kan heel snel code opleveren vol met defects. In mijn ogen zou dit een combinatie van code profiling (ook complexiteit van code kan tot op zekere hoogte geprofiled worden), hoeveelheid werk en aantal defects in dat werk.
Dan nog wordt het zeer moeilijk om een sleutel hiervoor te bedenken! Zeker omdat er binnen J2EE complexere en mindere complexere onderdelen zijn. Ook zouden bepaalde keuzes voor oplossingen (bv. patterns) en technieken mee moeten wegen.
Het gekke is wel: ik werk zelf ook met J2EE en ik weet precies wie er bij ons de betere en wie de mindere programmeur is. Dit is verder nooit meetbaar gemaakt maar dit principe op onderbuik gevoel ('hij voetbalde een goede wedstrijd') is in mijn ogen de meest objectieve.
Nadeel hiervan is wel dat de mensen die jou het meest aan het werk zien vaak niet de mensen zijn die jou ook beoordelen. Er moet dus een manier gevonden worden dat deze mensen (het liefst meerdere) zwaarwegende input leveren aan jouw beoordelaar (denk ook aan collegiale reviews).

[Alarmnummer]

Funtie Punt Analyse is een techniek om te bepalen hoe groot een bepaalde klus is. Ik neem aan dat het ook gebruikt kan worden om te bepalen hoe efficient een programmeur is. Je kunt dan vergelijkingen maken tussen de tijd/functiepunt bij de programmeurs.

Maar of dit nou zo`n goed meetinstrument is.

[-FoX-]

Dit is absoluut niet te meten.. en zou ook niet mogen.

Een team moet ook een team blijven, waarom moet iedereen in een team even goed kunnen programmeren? Als er een persoon niet zo goed kan programmeren en algoritmen kan bedenken... maar deze persoon is wel heel inventief en creatief, waardoor de rest van het team het probleem sneller kan oplossen. Is dit dan niet beter dan een groep goede programmeurs die er lang over doen om een oplossing te bereiken?

En ik denk, indien er zich een zwak element in een team bevind, dat deze wel snel aan het licht komt.

Een goed punt om je op te baseren is volgens mij veel interactie met het team/programmeurs, op deze manier voelen zij zich niet gecontroleerd (en blijven dus gewoon verder presteren)... voelen ze zich gewaardeerd (aangezien er interesse blijkt waarmee zij bezig zijn), en krijg je een heel goed zicht over de kwaliteiten...

[Anoniem: 113889]

Cuball schreef op 04 september 2004 @ 12:07:
... Maar dit is uiteraard zeer moeilijk mede omdat we een beginnend bedrijf zijn en volledig nieuw in de technologie. ...

iemand nog andere ideeën ?

Doe in geen geval fixed-price projecten. Doe geen grote projecten (we zien wel hoe het afloopt). Begin klein en bouw ervaring op.

[Cuball]

djlinsen schreef op 04 september 2004 @ 12:19:
Waarom wil je als een schoolmeester de prestaties van je werknemers zo nauwkeurig volgen? Denk je dat ze dan harder gaan werken?

ik ben niet de schoolmeester, ik ben een programmeur binnen het bedrijf. Waarom prestaties meten, wel heel eenvoudig, binnen het bedrijf werken we met een variabel loon, die aangepast wordt naargelang de prestaties van de werknemer. Voor andere diensten is dit veel eenvoudiger te bepalen, bv volledig uit de lucht gegrepen: dienst klantenbeheer heeft enkele afspraken en eentje ervan is dat prestaties gemeten worden naargelang het aantal afgewerkte dossiers (elke dossier neemt ongeveer een zelfde tijdsduur in beslag) dus dit is gemakkelijk te meten...

maar dienst informatica is nu een speciaal geval, en daar zijn ze op zoek naar een min of meer bruikbare manier van prestatie meten.

het is niet zo gemakkelijk allemaal, natuurlijk wil iedereen dat dit niet ingevoerd wordt, maar het management team wil iets bruibkaar op papier zien.

[Alarmnummer]

Cuball schreef op 05 september 2004 @ 02:25:
[...]
ik ben niet de schoolmeester, ik ben een programmeur binnen het bedrijf. Waarom prestaties meten, wel heel eenvoudig, binnen het bedrijf werken we met een variabel loon, die aangepast wordt naargelang de prestaties van de werknemer.

Ik vraag me af of dit wel zo`n verstandige oplossing is omdat niet iedere developer exact dezelfde rol binnen een team speelt. Hierdoor zou je een situatie kunnen creeeren waardoor mensen belangrijke niet programmeer aspecten links laten liggen puur om beter loon te krijgen.

[Cuball]

Alarmnummer schreef op 05 september 2004 @ 08:54:
[...]

Ik vraag me af of dit wel zo`n verstandige oplossing is omdat niet iedere developer exact dezelfde rol binnen een team speelt. Hierdoor zou je een situatie kunnen creeeren waardoor mensen belangrijke niet programmeer aspecten links laten liggen puur om beter loon te krijgen.

inderdaard misschien niet zo verstandig, maar het is nu eenmaal zo. Had graag nog enkele invals wegen gezien

[Anoniem: 70687]

djlinsen schreef op 04 september 2004 @ 12:19:
Waarom wil je als een schoolmeester de prestaties van je werknemers zo nauwkeurig volgen?

-FoX- schreef op 04 september 2004 @ 12:45:
Dit is absoluut niet te meten.. en zou ook niet mogen.

Onzin, zonder te weten hoe "goed" een team presteert kun je nooit een goede projectbegroting opstellen. Hoe je het ook bekijkt, het meten van prestaties gebeurt overal. Ik moest best wel lachen toen ik deze thread las en merkte dat bij sommigen de nekharen direct overeind springen.

Een "kort door de bocht" voorbeeld: van een productiemedewerker in een fietsfabriek wil men exact weten hoeveel fietsen hij per dag van een voorwiel kan voorzien. Van een ander hoeveel tijd hij nodig heeft om het zadel te monteren enz. Zo kan men nagaan hoeveel fietsen "het team" per dag kan produceren. Hier kan men vervolgens prognoses op bijstellen en de productiecapaciteit vastleggen en meten.

Bij een software ontwikkelaar ligt dit niet veel anders. Je wil immers weten voordat een project wordt gestart wat de verwachtte doorlooptijd is en wie er het meest geschikt zijn om aan het project deel te nemen. Hiervoor heb je kennis nodig van de prestaties (en wensen) van iedere programmeur.
Darnaast leven we nu eenmaal in een tijd waar alles om het snel opleveren van (tussentijdse) producten draait, ik heb dan ook al enkele "mindere" programmeurs zien plaatsmaken voor "betere" programmeurs. Puur bedrijfsmatig gezien is dit eigenlijk ook heel logisch.

En dan heb je nog het individuele ontwikkel aspect van een programmeur; als hij weet hoe hij presteert ten opzichte van de vastgestelde norm, kan hij hier een persoonlijk leerdoel/actieplan voor opstellen om zo te trachten om zijn prestaties te verbeteren. En hier heeft iedereen wat aan!

Het heeft echt niks te maken met "schoolmeestertje" spelen.

Wel nu, er zijn verschillende technieken om prestaties te meten (de functiepunt werd al genoemd), maar belangrijk is dat je de menselijke aspecten hierbij betrekt; feedback rondes houden met individuen maar ook gezamenlijk. Zo kan men feedback (en soms opbouwende kritiek) leveren op andermans prestaties, op zó'n manier dat hij of zij kan reflecteren op het eigen functioneren en hier wat mee kan in de toekomst. Ik vraag me af of mensen hier op dat gebied enig ervaring hebben (afgaande op enkele reacties niet dus).

*kijkt ondertussen even in de boekenkast*

Zoek eens op internet naar "projectmatig creëren" en "ps-tb" (problem solving team building). Zal morgen even kijken welke boeken ik nog meer kan aanraden (kheb ze gelezen hoor, maar weet de titels niet meer exact uit mijn hoofd)
Oja, cap gemini heeft hier uitstekende trainingen voor en die zijn ook niet al te duur, zie het als een investering in de toekomst!

[Tomatoman]

Het idee dat je de prestaties van een programmeur objectief zou kunnen meten is totaal onrealistisch. Bij lopende-bandmedewerkers wil dat nog wel lukken, maar aangezien bij programmeurs het eindproduct niet 'standaard' is, is de daarvoor benodigde inspanning ook niet te normeren. Zo simpel is het nou eenmaal. Een management team dat dit niet wil geloven, is mijns inziens een beetje wereldvreemd.

Stel dat een progrommeur op een dag 1000 regels code produceert. Is hij dan een goede programmeur? Nee! Iemand die zoveel code op een dag aflevert, heeft waarschijnlijk buitensporig veel niet-relevante code geschreven, die ook in veel minder regels had kunnen worden geschreven. Hij produceert voornamelijk kwantiteit (in tegenstelling tot kwaliteit). Nu spreek je hem daarop aan en wat blijkt? Hij heeft die dag een groot aantal standaardformulieren in elkaar gezet, waarbij de compiler een heleboel code voor hem heeft gegenereerd. In werkelijk hij heeft hij die dag de ballen uit zijn broek gewerkt.

Stel dat zijn collega op een dag 20 regels heeft geschreven. Is dat dan beter? Waarschijnlijk niet, want de kans is groot dat hij die dag gewoon weinig heeft gedaan. Maar bedenk wel dat het ook mogelijk is dat hij een ongelofelijk ingewikkeld probleem heeft opgelost (bijvoorbeeld een paar duizend regels code heeft doorgelopen op zoek naar een onvindbare bug).

Welk van beide collega's heeft nu het meest gepresteerd, de man die zoveel regels code heeft geproduceerd of degene die nauwelijks code heeft opgeleverd? Het zal duidelijk zijn dat hierop geen sluitend antwoord is te geven. Toch zijn het heel herkenbare situaties die bepaald geen uitzonderingsgevallen zijn.

Het grote probleem is dat je kwaliteit wilt meten, maar dat je nu op zoek bent naar een maatstaf voor kwantiteit. Kwantiteit is voor een lopende-bandmedewerker misschien een goede maatstaf, maar voor een programmeur helemaal niet. Variabel loon baseren op zoiets als het aantal opgeleverde aantal schermen is derhalve zeer dubieus.

Het zou zelfs een averechts effect kunnen hebben. Het is namelijk een fantastische stimulans voor programmeurs om zo veel mogelijk schermen af te leveren en daarvoor een beetje kwaliteit in te leveren. Waar ze vroeger altijd zorgvuldig puzzelden op de optimale layout, gooien ze nu alle schermcomponenten zonder nadenken op het scherm. Dat levert immers wat tijdwinst op en dus een hoger variabel salaris. Het managementteam zal aanvankelijk heel blij zijn, want de productiviteit stijgt een stukje. Dat zal echter snel voorbij zijn wanneer de klanten gaan klagen over de matige kwaliteit van het werk. Het is maar één van de vele mogelijke scenario's die ik hier schets, maar het moge duidelijk zijn dat loon gebaseerd op de hoeveelheid afgeleverd werk voor mensen met een creatief beroep totaal verkeerd kan uitpakken. Hier zijn al heel wat ondernemingen aan failliet gegaan.

[ Voor 3% gewijzigd door Tomatoman op 05-09-2004 13:56 ]

[misfire]

De prestaties van een ontwikkelaar meten met een absolute metriek is onbetrouwbaar. Ten eerste is er geen enkel stukje werk wat een ontwikkelaar doet dat altijd een consistente moeilijkheidsfactor per werkeenheid heeft. Regels code, aantal bladzijdes documentatie, aantal bugfixes kunnen allemaal zeer verschillende hoeveelheden inspanning nodig hebben om te maken. Ten tweede zul je regelmatig in de situatie komen waarbij meerdere mensen samen aan één werkeenheid werken. Hoe meet je dan nog de individuele prestaties?

Het kan zelfs gevaarlijk zijn om op prestaties af te rekenen op een vaste metriek. Ontwikkelaars zullen zich anders gaan gedragen om beter te scoren op de metriek, maar dit komt nooit ten goede van de totale prestatie. Zodra je gaat meten op het aantal regels code wordt er niet meer gekeken naar code hergebruik, bladzijdes documentatie en er worden enorme kletsverhalen opgehangen, enzovoorts. Het kan zelfs botsen met je software ontwikkel methodiek. In verschillende methodieken zijn individuele programmeurs niet verantwoordelijk voor een stuk code, maar is het een team inspanning. Als je meet op het aantal gevonden bugs in code van een programmeur dan wil hij wellicht voorkomen dat bepaalde tests pas in een aparte cyclus plaatsvinden.

Metrieken als functie-punt analyses zijn bedoeld om de complexiteit van een project in te schatten, en daarmee dus de benodigde resources en tijd. In FPA gaat men echter uit van een standaard afwijking per functie-punt, die elkaar opheffen in het grote geheel (gemiddeld doe je dus x tijd over een fp, maar dit wil niet zeggen dat iedere fp ook x tijd moet kosten). Om per werk-eenheid exact vast te stellen wat een redelijke inspanning er voor zou zijn zijn FPA's dus geen goede metriek.

Op Joel On Software is een aantal interessante artikelen te vinden waar dit probleem uitgebreider besproken wordt. Het houdt veel mensen bezig omdat het heel makkelijk zou zijn om volgens een objectieve metriek beoordeeld te worden. Ik denk dat dit niet kan, en ook dat er maar zeer weinig beroepen zijn waar dit mogelijk is, ook niet voor de andere voorbeelden die je aanhaalde (over dossiers enz.).

Wat is dan wel een manier om prestaties te meten? Een goede manager weet wat hij aan zijn werknemer heeft, en kan op basis van die kennis een gefundeerd oordeel geven over zijn prestaties. Als een werknemer goed werk aflevert, op tijd is, meedenkt en meewerkt met het totaal, goed communiceert over problemen en een goede inzet toont dan zou een manager dit moeten kunnen zien, net zo goed als iemand die zit te prutsen op zou moeten vallen. De roep om prestatie-metrieken komt echter vaak vanuit zwak management, en prutsers die met een paar leuke cijfers een wanprestatie willen goedpraten.

Conclusie: als je management en collega's blijven doorgaan met het invoeren van prestatie-metrieken, en niet beoordelen op de dagelijkse ervaring, dan weet je met wie je te maken hebt.

[EfBe]

Cuball schreef op 04 september 2004 @ 12:07:
Ik had graag es geweten hoe er bij bedrijven de prestaties van een programmeur gemeten wordt. Binnen ons bedrijf worden voornamelijk J2EE applicaties geschreven. Aanvaanlijk werd er eerst overwogen om het aantal "genormeerde" schermen als maat te gebruiken, maar dit is uiteraard bijna niet meetbaar, en niet elk scherm heeft even veel code natuurlijk en hoe definieer je dan ee "genormeerd scherm". Volgende voorstel van het management team was om een project (deel) in te delen in blokken van uren, bv 40 - 80 - 120 - 160 ofzo, die kennen ze dan toe aan een project (deel), en jij als programeur kan dan kiezen hoeveel tijd je nodig zal hebben voor het deel, bv een deel dat 80 uren is toegewezen, kan jij als programmeur zeggen dat je er 40 uren zal over doen, dit is dan een maat van prestatie. Maar dit is uiteraard zeer moeilijk mede omdat we een beginnend bedrijf zijn en volledig nieuw in de technologie. Probleem bij veel van deze voorstellen is dat het controleren van de prestaties ook een tijdrovende bedoening is wat natuurlijk gepaard gaan met kosten...
iemand nog andere ideeën ?

Ja, denk na over wat je werkelijk wilt.

Wat je voorstelt lijkt erg sterk op het 'aanwezig==werken' gedachte. Is het niet gewoon zo dat een werknemer gewoon targets moet halen, bv een op de planning gezette milestone waarbij een developer zijn deel van de functionaliteit af moet hebben?

Dat is nl. veel efficienter: je hoeft mensen niet achter de broek aan te zitten en de werknemers weten waar ze aan toe zijn. Verder is het precies wat je ook vraagt van je werknemers: doe werk, nou dat doen ze. HOE is voor jou niet interessant, immers als het maar afkomt met de gestelde kwaliteit voor ogen.

Afvinken dat iemand een theoretische hoeveelheid items af heeft, x-uur aanwezig is en andere bullshit werkt niet en geeft alleen schijninzicht in de materie.

Hoe dacht je hoe microsoft dit soort dingen regelde? -> per functionaliteit onderdeel wordt een persoon benoemd die verantwoordelijk is daarvoor en zn ontwikkelaars aanstuurt mbv planning voor dat onderdeel. De ontwikkelaars werken dus binnen de grenzen gesteld voor dat functionaliteitsonderdeel en moeten dat afhebben in de gestelde tijd. That's it.

Bovenal gaat overigens 'communicatie'. Veelal hebben de wat grotere ondernemingen die software development doen grote moeilijkheden hiermee: een club middenkadermanagers doet de planningen, communiceert louter naar boven maar niet naar beneden en er is geen feedbackverwerking van development in de planning: wanneer een developer averij oploopt tijdens de ontwikkeling (een feature loopt uit, wordt op een spoedklus gezet etc.) dan wordt zelden de planning echt aangepast, botweg omdat er niet goed wordt gecommuniceerd.

De ideeen die jij aandraagt werken echt voor geen meter. Het tellen van schermen, regels en andere ongein is onzin, wat telt is wat de developer afheeft van wat hij af MOET hebben.

[misfire]

@DoktorAnders: Ik denk dat iedereen het er hier over eens is dat het goed is prestaties van ontwikkelaars te evalueren en op basis hiervan teams te vormen, verbeterprogramma's op te stellen, en ontwikkelaars die geen nuttige bijdrage leveren te verwijderen uit de organisatie.

De vraag was alleen, hoe evalueer je dat dan? Wat is dan die "vastgestelde norm"? De vergelijking met een fietsenfabriek is niet correct. Daar is immers een duidelijk gedefinieerde complexiteit per werk-eenheid, en ook een duidelijke metriek om geleverde kwaliteit te meten. Voor software ontwikkeling ligt dit totaal anders.

Ik vind de verwijzing naar een Cap Gemini training ook niet erg sterk. Reclame voor een/hun bedrijf maken is imho niet zo'n nuttige bijdrage aan een discussie, zeker als je niet eens bondig er bij verteld hoe ze je in zoon dure training zouden kunnen leren prestaties te meten...

[ Voor 4% gewijzigd door misfire op 05-09-2004 14:46 ]

[EfBe]

Alarmnummer schreef op 04 september 2004 @ 12:33:
Funtie Punt Analyse is een techniek om te bepalen hoe groot een bepaalde klus is. Ik neem aan dat het ook gebruikt kan worden om te bepalen hoe efficient een programmeur is. Je kunt dan vergelijkingen maken tussen de tijd/functiepunt bij de programmeurs.

Maar of dit nou zo`n goed meetinstrument is.

Functie punt analyse is een van de grootst mogelijke bullshit van de software industrie. Het is niet een empirische grootheid, je kunt het niet empirisch testen. Het valt nl. om wanneer je de functie punten verkeerd toekent, en het lullige is, je kunt dat alleen achteraf doen, want alleen dan weet je de werkelijke complexiteit van een onderdeel, doordat een subsystem bv met zoveel zaken te maken krijgt dat je dmv top-down development de zaak moet aanpakken omdat je bij aanvang niet alle details KUNT weten.

Het is niet voor niets dat Functie punt analyse louter gebezigd wordt door mensen in het middenkader die het verschil tussen een toetsenbord en een muis nauwelijks weten.

[misfire]

@EfBe: Ik zou FPA zeker niet wegschuiven als totale bullshit. Het is een schatting op basis van de verwachte totale complexiteit van een project. Die schatting wordt gedaan op basis van de gekozen randvoorwaardes voor het project, ervaringen bij andere bedrijven met vergelijkbare problematiek, en ervaringen bij de eigen organisatie. Je moet hiervoor dus wel een wat breder inzicht en ervaring hebben in de markt om genoeg input te hebben voor een FPA, waardoor het moeilijk is om er één te maken.

Het is geen exacte wetenschap, en de initiële FPA blijft meestal niet in de totale loop van een project geldig, omdat allerlei input voor de FPA verandert. Het bedrijf waar ik werk doet echter altijd een FPA voor inhouse klussen en ook voor projecten in de organisatie van de klant. Het verschil tussen de geschatte tijd en de daadwerkelijke tijd tot een acceptabel product blijkt dan verrassend klein te zijn. Misschien ook omdat ook met dit soort mechanismes er op de schatting gestuurd wordt, en het dus een self-fullfilling prophecy wordt. Maar er is in ieder geval wel een doel om op te sturen wat in de praktijk een redelijk realistisch doel is. En dat is beter dan niks of een beetje natte-vinger-werk.

[EfBe]

Anoniem: 70687 schreef op 05 september 2004 @ 13:27:
Onzin, zonder te weten hoe "goed" een team presteert kun je nooit een goede projectbegroting opstellen. Hoe je het ook bekijkt, het meten van prestaties gebeurt overal. Ik moest best wel lachen toen ik deze thread las en merkte dat bij sommigen de nekharen direct overeind springen.

Ik moet zeggen dat ik best wel gelachen heb bij het lezen van jouw reply

Een "kort door de bocht" voorbeeld: van een productiemedewerker in een fietsfabriek wil men exact weten hoeveel fietsen hij per dag van een voorwiel kan voorzien. Van een ander hoeveel tijd hij nodig heeft om het zadel te monteren enz. Zo kan men nagaan hoeveel fietsen "het team" per dag kan produceren. Hier kan men vervolgens prognoses op bijstellen en de productiecapaciteit vastleggen en meten.

Tuurlijk. Het punt is dat de activiteiten van de productiemedewerker absoluut te definieren zijn, en dus empirisch kan worden gemeten en bewezen of de medewerker efficient bezig is (je weet nl. precies wat er gedaan moet worden, welke tijd daarvoor staat, wat de theoretische tijd is die men minimaal nodig heeft en je hebt je formule).

Bij een software ontwikkelaar ligt dit niet veel anders. Je wil immers weten voordat een project wordt gestart wat de verwachtte doorlooptijd is en wie er het meest geschikt zijn om aan het project deel te nemen. Hiervoor heb je kennis nodig van de prestaties (en wensen) van iedere programmeur.

Als het zo theoretisch lag, dan was er niet veel aan de hand. Het punt is dat je, anders dan bij jouw fietsemakertje, niet absoluut kunt definieren wat er gedaan moet worden, voordat een project aanvangt. Je hebt wel globaal een idee (NA een grondige analyze, wat al vaak niet gedaan wordt), maar niet meer dan dat: technische details die een project erg kunnen vertragen zijn bv erg moeilijk vooraf te voorspellen.

Je kunt dus geen formule opstellen omtrent wat de meest efficiente werknemer voor tijd nodig zal hebben.

Darnaast leven we nu eenmaal in een tijd waar alles om het snel opleveren van (tussentijdse) producten draait, ik heb dan ook al enkele "mindere" programmeurs zien plaatsmaken voor "betere" programmeurs. Puur bedrijfsmatig gezien is dit eigenlijk ook heel logisch.

Of iemand een 'mindere' programmeur is doet er niet toe eerlijk gezegd. Een mindere krijgt ook minder betaalt, dus wordt ook minder van verwacht, wat inhoudt dat hij / zij dus ook minder hoeft op te leveren.

Maar aangezien je niet vooraf expliciet kunt definieren wat er in detail opgeleverd moet worden, dus welke theoretische doorlooptijd er minimaal (omdat je bv expliciet kunt definieren dat onderdeel x minimaal y tijd kost in theorie) gerekend moet worden, kun je wel andere variabelen invullen, maar je krijgt nooit een exact antwoord. Aangezien dat wel gewenst is, is de benadering niet bruikbaar.

En dan heb je nog het individuele ontwikkel aspect van een programmeur; als hij weet hoe hij presteert ten opzichte van de vastgestelde norm

Wat is een vastgestelde norm? Hij kan zoveel functionele eenheden per uur implementeren?

kan hij hier een persoonlijk leerdoel/actieplan voor opstellen om zo te trachten om zijn prestaties te verbeteren. En hier heeft iedereen wat aan!

Erg leuk, maar dit heeft geen moer met het probleem te maken

Het heeft echt niks te maken met "schoolmeestertje" spelen.

Nee eerder met dom project-management.

Wel nu, er zijn verschillende technieken om prestaties te meten (de functiepunt werd al genoemd), maar belangrijk is dat je de menselijke aspecten hierbij betrekt; feedback rondes houden met individuen maar ook gezamenlijk. Zo kan men feedback (en soms opbouwende kritiek) leveren op andermans prestaties, op zó'n manier dat hij of zij kan reflecteren op het eigen functioneren en hier wat mee kan in de toekomst. Ik vraag me af of mensen hier op dat gebied enig ervaring hebben (afgaande op enkele reacties niet dus).

Mwah, ik zou niet zo hoog van de toren blazen, ik vind jouw redenaties echt van een hoog nattevingerwerk getuigen.

Nogmaals: het eigen functioneren is niet zo aan de orde, dat is nl. allang bepaald: via toetsing vanuit het bedrijf wat iemand kan en wat daartegenover staat. het is heel simpel hoor, een werknemer heeft een contract met het bedrijf: de werknemer levert een dienst en het bedrijf betaalt geld daarvoor. Als die dienst niet goed omschreven is, kan het bedrijf eigenlijk niet uitbetalen of toetsen of de werknemer wel voldoet. Je ziet dan ook dat dit wel goed gebeurt. Welnu, omdat dat gedaan is, weet je wat je van je werknemers kunt verwachten, toch? Je vereist immers van hen, contractueel! dat ze een dienst leveren.

Als er dus een project moet worden doorlopen, en een projectteam moet worden samengesteld is dit niet echt moeilijk. Wat moeilijk is is het bepalen wat gedaan moet worden. Omdat dit alleen tot op het niveau van 'aanname' of 'schatting' kan worden gedaan, kun je dus niets expliciets zeggen over hoe iemand's geleverde diensten overeenkomen met het totale project.

Je kunt alleen de functionaliteiten opdelen, met de ontwikkelaars zelf daar een planning voor opstellen en uitloop incalculeren en met de ontwikkelaars harde afspraken maken over de te leveren diensten mbt het project. Deze afspraak is echter niet 1 richtingsverkeer: de ontwikkelaar moet er zeker van kunnen zijn dat hij/zij de dienst voor het project ook kan leveren in de tijd die voor de ontwikkelaar gereserveerd is: iemand telkens opzadelen met systeembeheerklusjes, kleinigheidjes die 'toch maar 1 uurtje kosten' en andere zut, zorgt ervoor dat de ontwikkelaar zn target niet kan halen. Is dat zichtbaar? Alleen als het bedrijf eerlijk is en toetst wat het de ontwikkelaar aandoet, dus feedback terugvraagt.

*kijkt ondertussen even in de boekenkast*

Zoek eens op internet naar "projectmatig creëren" en "ps-tb" (problem solving team building). Zal morgen even kijken welke boeken ik nog meer kan aanraden (kheb ze gelezen hoor, maar weet de titels niet meer exact uit mijn hoofd)
Oja, cap gemini heeft hier uitstekende trainingen voor en die zijn ook niet al te duur, zie het als een investering in de toekomst!

Als er 1 bedrijf is dat niet het recht van spreken heeft omtrent project management dan is het cap gemini wel. Of moet ik een meeting aanhalen waarbij iedere werknemer werd opgedragen 'langzamer' te werken? Ik hoop het toch niet.

[Tomatoman]

Na mijn verhaal over wat er mis is aan het meten van productiviteit in de vorm van kwantiteit, ben ik natuurlijk verplicht een alternatief aan te bieden dat wél werkbaar is .

Aangezien beoordeling van programmeurs subjectief is, kun je daar een subjectieve methode aanhangen. Het subjectieve oordeel kan aan het eind van het jaar worden geveld door de leidinggevende. Die geeft dan zijn - subjectieve - beoordeling op basis van vooraf vastgestelde criteria. De criteria moeten vooraf zijn vastgesteld en moeten alle aspecten van het werk omvatten. Bij een programmeur kun je denken aan aspecten als werktempo, kwaliteit, klantgerichtheid en samenwerking met teamleden. Aan elk van deze aspecten hang je een beoordeling, bijvoorbeeld
• A = beneden verwachting
• B = wat van iemand op dit niveau verwacht kan worden
• C = boven verwachting
Het subjectieve element zit erin dat de leidinggevende aan elk van de beoordelingsaspecten een A, B of C moet toekennen. Je mag echter van hem verwachten dat hij dit naar behoren doet (anders is het geen goede leidinggevende). Het is tevens het enige subjectieve aspect aan deze methode, de rest is volledig objectief. Op basis van alle A's, B's en C's komt er een totaalbeoordeling, die direct gekoppeld is aan de beloning. Vooraf moet met de medewerker zijn afgestemd welke beoordelingscriteria in welke mate meewegen in de totaalbeoordeling. Aangezien werktempo voor het managementteam van de topcistarter blijkbaar erg belangrijk is en daardoor zwaar zal meetellen in de totaalbeoordeling, kan dat criterium worden gesplitst in subcriteria, zodat er een evenwichtig oordeel wordt gevormd.

[EfBe]

misfire schreef op 05 september 2004 @ 15:00:
@EfBe: Ik zou FPA zeker niet wegschuiven als totale bullshit. Het is een schatting op basis van de verwachte totale complexiteit van een project. Die schatting wordt gedaan op basis van de gekozen randvoorwaardes voor het project, ervaringen bij andere bedrijven met vergelijkbare problematiek, en ervaringen bij de eigen organisatie. Je moet hiervoor dus wel een wat breder inzicht en ervaring hebben in de markt om genoeg input te hebben voor een FPA, waardoor het moeilijk is om er één te maken.

Ok, even wat achtergrondinfo. Bij CMG hebben ze dit dus jarenlang wel als exacte wetenschap benaderd. Terwijl dat niet zo is. Jij geeft goed aan dat het schattingen zijn, aannames en geen exacte wetenschap. Maar zo wordt het niet gebruikt, helaas. Het is erg moeilijk een onderdeel op complexiteit te toetsen, en de enigen die dat kunnen doen zijn degenen die het werkelijk implementeren, terwijl de schattingen juist worden gedaan door de mensen die nauwelijks iets weten van hoe complex een functioneel onderdeel werkelijk is. Dat maakt de hele materie waardeloos en onbruikbaar. Ik ken ook geen een software engineer die FPA gebruikt, alleen managers.

Het is geen exacte wetenschap, en de initiële FPA blijft meestal niet in de totale loop van een project geldig, omdat allerlei input voor de FPA verandert. Het bedrijf waar ik werk doet echter altijd een FPA voor inhouse klussen en ook voor projecten in de organisatie van de klant. Het verschil tussen de geschatte tijd en de daadwerkelijke tijd tot een acceptabel product blijkt dan verrassend klein te zijn. Misschien ook omdat ook met dit soort mechanismes er op de schatting gestuurd wordt, en het dus een self-fullfilling prophecy wordt. Maar er is in ieder geval wel een doel om op te sturen wat in de praktijk een redelijk realistisch doel is. En dat is beter dan niks of een beetje natte-vinger-werk.

Ik zie niet echt verschil tussen FPA en natte-vinger-werk hoor. En zoals ik al zei: alleen achteraf kun je de FPA werkelijk gebruiken maar dan heb je hem niet meer nodig. Tijdens een project de FPA bijstellen lijkt me ook niet echt nuttig, je hebt dat ding toch voor de berekeningen vooraf?

Het hangt er wel vanaf wat voor software je maakt. Is het lopende band werk met een CMS waarbij je dus in kunt schatten hoeveel werk een website is want je hebt er al 100 gemaakt, dan zijn schattingen vooraf redelijk betrouwbaar. Echter de meeste mensen maakt maatwerk. Bij maatwerk kan de FPA direct het raam uit, want je hebt totaal geen referentiekader. Bij inhouse producten nog minder, zeker als ze wat complex zijn.

Nu ben ik geen kleine jongen mbt software development, maar zelfs ik had grote moeite om bv in te schatten hoeveel tijd een functioneel onderdeel als synchronization of fk-pk fields during a recursive save of an entity graph zou gaan kosten, botweg omdat dat het echt een mega-complex onderdeel bleek te zijn, waarbij je niet kunt refereren aan een referentiekader, want dat heb je gewoonweg niet. Als ik dat al niet kan, verwacht jij dat een manager dat dan wel kan? Ik in ieder geval niet.

[misfire]

@tomatoman: Dat is bijna precies hoe ze het bij ons doen (alleen is het dan A t/m E). Dit systeem werkt denk ik het beste, zolang je er maar op kunt vertrouwen dat de leidinggevende inderdaad een goed oordeel kan geven over je prestaties. Als de leidinggevende dat niet kan heb je zowieso een groot probleem...

@EfBe: laten we het er op houden dat een FPA net zo goed is als degene die hem opstelt.

[EfBe]

misfire schreef op 05 september 2004 @ 15:26:
@EfBe: laten we het er op houden dat een FPA net zo goed is als degene die hem opstelt.

hehe Ik kan me daar wel in vinden

[Tomatoman]

misfire schreef op 05 september 2004 @ 15:26:
@tomatoman: Dat is bijna precies hoe ze het bij ons doen (alleen is het dan A t/m E). Dit systeem werkt denk ik het beste, zolang je er maar op kunt vertrouwen dat de leidinggevende inderdaad een goed oordeel kan geven over je prestaties. Als de leidinggevende dat niet kan heb je zowieso een groot probleem...

Volgens mij heb je daar de belangrijkste reden te pakken waarom managers graag van die zogenaamd objectieve meetcriteria willen gebruiken zoals het aantal geproduceerde 'genormeerde schermen'. Veel managers zijn gewoon bang om een medewerker te vertellen dat hij/zij ondermaats presteert. Ze verschuilen zich liever achter een of andere statistiek. (Het zijn trouwens niet alleen managers die bang zijn om slecht nieuws te verkondigen, er zijn ontzettend veel mensen die hier last van hebben.) Verder weten veel managers absoluut niet hoe goed 'hun' programmeurs functioneren, daarom willen ze graag een of ander meetmiddel hebben dat hun eigen onvermogen compenseert.

offtopic:
Ik nomineer dit topic voor de topic-met-de-langste-replies-trofee

[Verwijderd]

EfBe schreef op 05 september 2004 @ 15:04:
Als er 1 bedrijf is dat niet het recht van spreken heeft omtrent project management dan is het cap gemini wel. Of moet ik een meeting aanhalen waarbij iedere werknemer werd opgedragen 'langzamer' te werken? Ik hoop het toch niet.

Of een red. recht toe recht aan project wat Cap Gemini totaal wist te verkloten waarna ze de opdracht maar bij ons neerlegden Zonder enige inzicht gaan roepen dat ze maar vooral Sharepoint moesten inzetten Een looptijd van 1 jaar, en pas in de laatste 2 maanden in allereil 2 developers op locatie neerzetten die van toeten noch blazen wisten. aha..

[Anoniem: 70687]

EfBe schreef op 05 september 2004 @ 15:04:
[...]

Ik moet zeggen dat ik best wel gelachen heb bij het lezen van jouw reply


Enzovoorts enzovoorts

Ik moest ook erg lachen om jou reply.... Je redeneert volgens mij puur uit eigen ervaring en in mijn oren klinkt het niet al te best (ego ding?)... Hier en daar scoor je een punt, maar over het algemeen vind ik je reply een cheap shot om mijn stukkie onderuit te halen, zonder directe aanleiding of wat dan ook. Ik heb bijvoorbeeld nooit gezegd hoe iets aangepakt dient te worden, ik heb alleen mijn mening gegeven op de stelling dat je prestaties niet kán of mág meten! Daarna wauwel ik wat door over wat dingetjes die me te binnen schieten, maar hey, wat verwacht je dan? Een uitgebreide training of wat dan ook op de zondag middag op internet? Laat me niet lachen!

Mijn fietsfabriekje was puur bedoelt als voorbeeld om aan te tonen dat meestal een soort van norm of functiepunten systeem benodigd is om je begrotingen realistisch op te stellen. Ik ben het met je eens, in tegenstelling tot wat ik eerder zei, dat dit niet geheel voor een software bedrijf opgaat. Het was dan ook een "kort door de bocht" voorbeeld. Echter is je stelling "niet absoluut kunt definiëren wat er gedaan moet worden" en daar ben ik het dan weer niet mee eens (eigen ervaring).

Ik heb trouwens nooit gesproken over een formule, ik meen alleen dat je een goed beeld dient te hebben van de kwaliteiten van een programmeur. Je kunt hier allerlei aardige technieken op loslaten, maar de meest waardevolle kennis hierover vind je bij de manager/teamleden/collega's en niet te vergeten de programmeur zelf! (de norm wordt vaak mede hieruit afgeleid). Maar dit is wederom mijn mening!

Daarnaast was mijn opmerking over de "mindere" programmeur puur gebasseerd op mijn observaties. Wat jij hierover zegt is ook waar, maar ik zie niet in waarom je dit wil tegenspreken?!

Tevens merk ik in jou reply dat je meent dat persoonlijke ontwikkeling weinig invloed heeft op de productiecapaciteiten van een projectteam. En ook hier sla je naar mijn mening de plank volledig mis. Het kan wederom aan je eigen ervaringen liggen, immers zien veel bedrijven het belang van empowerment dmv reflectie en ontwikkeling (cursussen en bijscholing, maar ook functioneringsgesprekken (om maar wat te noemen!)) nog niet goed in (ook willen werknemers vaak in eerste instantie niks van dit alles weten).
Een medewerker die zijn eigen sterktes en valkuilen kent is zeer waardevol, met name als je er een soort normsysteem tegenover wil zetten (bijv. KLM en ING werken sinds een aantal jaar volgens een interessante techniek die hier slim gebruik van maakt).
(tijdje terug een goede! training van Cap Gemini gehad hierover, vandaar de verwijzing).

Nogmaals: het eigen functioneren is niet zo aan de orde, dat is nl. allang bepaald: via toetsing vanuit het bedrijf wat iemand kan en wat daartegenover staat. het is heel simpel hoor, een werknemer heeft een contract met het bedrijf: de werknemer levert een dienst en het bedrijf betaalt geld daarvoor. Als die dienst niet goed omschreven is, kan het bedrijf eigenlijk niet uitbetalen of toetsen of de werknemer wel voldoet. Je ziet dan ook dat dit wel goed gebeurt. Welnu, omdat dat gedaan is, weet je wat je van je werknemers kunt verwachten, toch? Je vereist immers van hen, contractueel! dat ze een dienst leveren.

Dit is zó 1950! De werkelijk ligt toch iets genuanceerder hoor!

Alleen als het bedrijf eerlijk is en toetst wat het de ontwikkelaar aandoet

Je begon de alinea sterk en ik kon me redelijk vinden in dit verhaal (ontwikkelmethodieken als DSDM of XP om maar wat te noemen nemen dit indd als uitgangspunt), alleen die laatste zin duidt dan weer op frustraties? Waarom toch? Gebrekkige communicatie? Manager die niet naar je luistert?

Kijk, verwacht nou niet teveel als je hier een topic volgt, er zijn gewoon ontzettend veel factoren die bepalen of en hoe je een succesvol bedrijf/project runt.
Ik kan hier toch onmogelijk verder dan dit serieus op in gaan?
Beste Efbe, hopelijk neem je met interesse kennis van mijn reply, omdat deze net zo onzinnig is als die van jou…

[Verwijderd]

Maargoed, ik ben het wel eens met het punt van Eefbe dat de prestatie wordt bepaald op het behalen van de gestelde targets binnen de beschikbare tijd. Als men mij vraagt "hoeveel tijd heb je hiervoor nodig" en ik geef aan 8 uur, en het wordt 16 uur dan heb ik het verknalt, dan had ik een betere inschatting moeten geven.

[EfBe]

Anoniem: 70687 schreef op 05 september 2004 @ 22:57:
[...]
Ik moest ook erg lachen om jou reply.... Je redeneert volgens mij puur uit eigen ervaring en in mijn oren klinkt het niet al te best (ego ding?)... Hier en daar scoor je een punt, maar over het algemeen vind ik je reply een cheap shot om mijn stukkie onderuit te halen, zonder directe aanleiding of wat dan ook.

Aggossie... Ventje, JIJ begon met het uitlachen van anderen. En mijn ervaringen zijn niet al te best? Druk jezelf eens wat duidelijker uit.

Ik heb bijvoorbeeld nooit gezegd hoe iets aangepakt dient te worden, ik heb alleen mijn mening gegeven op de stelling dat je prestaties niet kán of mág meten! Daarna wauwel ik wat door over wat dingetjes die me te binnen schieten, maar hey, wat verwacht je dan? Een uitgebreide training of wat dan ook op de zondag middag op internet? Laat me niet lachen!

Ik verwacht helemaal niets, maar als iemand anderen gaat zitten uitlachen in zn posting en dan zelf aankomt met hete lucht, linearecta van een of andere management cursus, dan mag ik daar dan toch wel wat van zeggen? Ik kreeg overigens totaal niet de indruk dat jij een stelling had dat je prestaties niet kan of mag meten, in tegendeel! Jij haalt immers de FPA aan en andere zaken, meetinstrumenten, dus waar staat jouw stelling dan?

Mijn fietsfabriekje was puur bedoelt als voorbeeld om aan te tonen dat meestal een soort van norm of functiepunten systeem benodigd is om je begrotingen realistisch op te stellen. Ik ben het met je eens, in tegenstelling tot wat ik eerder zei, dat dit niet geheel voor een software bedrijf opgaat. Het was dan ook een "kort door de bocht" voorbeeld.

Niet geheel? Dat betekent dus toch wel 'bijna volledig', en dat is echt lulkoek. Maak daar maar 'geheel niet' van.

Echter is je stelling "niet absoluut kunt definiëren wat er gedaan moet worden" en daar ben ik het dan weer niet mee eens (eigen ervaring).

Oh, dus jij kunt WEL absoluut definieren wat er gedaan moet worden in een software traject? Volgens mij ben je niet de eerste die dat roept, maar je zult wel de eerste zijn op deze wereld die het ook daadwerkelijk zou kunnen.

Ik heb trouwens nooit gesproken over een formule, ik meen alleen dat je een goed beeld dient te hebben van de kwaliteiten van een programmeur. Je kunt hier allerlei aardige technieken op loslaten, maar de meest waardevolle kennis hierover vind je bij de manager/teamleden/collega's en niet te vergeten de programmeur zelf! (de norm wordt vaak mede hieruit afgeleid). Maar dit is wederom mijn mening!

Lees dit nou eens terug. Je zegt werkelijk helemaal niets! Beetje wollig praten over de kwaliteiten van een programmeur. Tja, goh... en wat heeft dat met het probleem te maken?

Daarnaast was mijn opmerking over de "mindere" programmeur puur gebasseerd op mijn observaties. Wat jij hierover zegt is ook waar, maar ik zie niet in waarom je dit wil tegenspreken?!

Ik spreek niets tegen? ik wilde alleen aangeven dat hoe jij het presenteert, nl. dat je wel moet weten dat iemand wat minder is, vanzelfsprekend is en dat je dat al weet, dus dat je dat niet nog eens hoeft te analyseren.

Tevens merk ik in jou reply dat je meent dat persoonlijke ontwikkeling weinig invloed heeft op de productiecapaciteiten van een projectteam. En ook hier sla je naar mijn mening de plank volledig mis. Het kan wederom aan je eigen ervaringen liggen, immers zien veel bedrijven het belang van empowerment dmv reflectie en ontwikkeling (cursussen en bijscholing, maar ook functioneringsgesprekken (om maar wat te noemen!)) nog niet goed in (ook willen werknemers vaak in eerste instantie niks van dit alles weten).

De persoonlijke ontwikkeling van iemand is iets dat er geen reet mee te maken heeft. Men wil een project doen, heeft daarvoor kennis en kunde nodig en kiest daarop de mensen uit die die kennis en kunde gaan leveren. Wie dat dan zijn weet je aan de hand van wat men kan, geanalyseerd door het bedrijf, wat ze veelal doen tijdens bv functioneringsgesprekken en evaluaties achteraf van eerder werk. Hoe iemand zich dan ontwikkelt is aan de medewerker en alleen achteraf nuttig om te weten want dan kun je die persoon voor een volgend project inzetten maar DAT de medewerker zich ontwikkelt is volledig onbelangrijk. Op het moment dat je het projectteam gaat samenstellen MOET je de kennis en kunde die je nodig DENKT te hebben ook in je project gaan opnemen.

En wat is in vredesnaam empowerment dmv reflectie?

Een medewerker die zijn eigen sterktes en valkuilen kent is zeer waardevol, met name als je er een soort normsysteem tegenover wil zetten (bijv. KLM en ING werken sinds een aantal jaar volgens een interessante techniek die hier slim gebruik van maakt). (tijdje terug een goede! training van Cap Gemini gehad hierover, vandaar de verwijzing).

Geen een medewerker kent zijn eigen sterktes en valkuilen, ga daar maar van uit. Reden: medewerkers zijn nauwelijks geneigd te zeggen dat ze iets niet kunnen, bang om als iemand te worden gezien die iets niet kan (of meer dingen niet kan) en daardoor carierre mogelijkheden mis zal lopen.

Ik vind het verder sterk dat daar dan een 'norm' systeem aan gekoppeld wordt, en mbt software development is dat dan ook nog eens niet bruikbaar, immers HOE kun je voor een zekere complexe functionaliteit dan bepalen of iemand met een zeker norm-level X dat in Y tijdseenheden kan / zal afronden? Als jij beweert dat je dat kunt, weet je echt niet waarover je praat.

[...]
Dit is zó 1950! De werkelijk ligt toch iets genuanceerder hoor!

Huh? Volgens mij ligt de werkelijkheid helemaal niet genuanceerder maar is het zo simpel, kijk je eigen contract maar na of lees eens een boek over arbeidsrecht.

[...]
Je begon de alinea sterk en ik kon me redelijk vinden in dit verhaal (ontwikkelmethodieken als DSDM of XP om maar wat te noemen nemen dit indd als uitgangspunt), alleen die laatste zin duidt dan weer op frustraties? Waarom toch? Gebrekkige communicatie? Manager die niet naar je luistert?

Ik ben al 7 jaar eigen baas, dus een manager die niet naar mij luistert heb ik niet echt. Ik weet niet echt welke laatste zin je bedoelt, wellicht moet je die dan even quoten, wel zo makkelijk. Ik ken DSDM niet, en XP vind ik niet een juiste methodiek maar dat is persoonlijk.

Ik loop nu al meer dan 10 jaar mee als professional en wat ik bij bedrijven gezien heb is louter ellende mbt communicatie tussen management en degenen die het werk uitvoeren. De oorzaak is ALTIJD dezelfde: klant wil een vast bedrag betalen voor iets dat flexibel moet zijn aangezien de klant eisen/wensen wil / gaat bijstellen en deze eisen worden overgenomen door verkoop/accountmanagement. Het punt is dat de deal met de klant gedaan wordt door mensen die niet betrokken zijn bij project management en ontwikkeling. Je krijgt dan dus een vooraf voorgeschreven raamwerk waarin de projectleider en zn medewerkers zich in moeten passen. Dit levert in 10 van de 10 gevallen ellende op: er wordt teveel werk gevraagd in een tekorte tijd.

Dit is geen lulkoek, maar ervaring die in 10 jaar niet is veranderd. Ik moet je zeggen dat ik daar zo langzamerhand behoorlijk genoeg van heb. Ik weet nl. waar het aan ligt: het middenkader-management dat al grafiekentekenend zich een weg naar boven wil werken maar zich niet betrokken voelt bij wat het beste is voor de klant. Het is alleen zo verschrikkelijk vervelend als daar dan maar nooit een verandering in komt. Bij kleinere bedrijfjes heb je deze ellende niet zo, daar zijn de lijnen korter. Bij de grote bedrijven in deze branche is het echter kommer en kwel. Ook bij middelgrote bedrijven trouwens.

Omdat de discrepantie tussen de visie/doelen van verkoop/bedrijfsmanagement aan de ene kant en de visie/doelen van ontwikkeling aan de andere kant niet opgelost wordt, zul je problematiek houden waar je koud van wordt. Jij kunt 10,000 cursussen zelfreflectie mbt empowerment en cap cursussen volgen over normering van mensen die zichzelf van binnen en van buiten kennen, maar daarmee verhul je alleen maar de ware ellende en los je het niet op, in tegendeel.

Er zijn wel bedrijven die het goed doen, maar veelal is het kommer en kwel. Het is op zich wel logisch: een bedrijf heeft er veel meer aan dat een groepje developers een jaar lang bezig is met een project dan dat hetzelfde groepje in 3 maanden klaar is. Maatwerk, lastig, zware klus, extra zware mensen erop gezet want ja de klant is koning, erg hun best gedaan maar dit is het beste wat er nog uit te slepen was etc. etc.

Jij lachte mensen uit in deze thread, wellicht diegene die erg sterk vroeg waarom deze normering/toetsing op deze manier gewenst was. Jij ging niet in op deze vraag, terwijl deze het allerbelangrijkste is: waarom moet degene die zich moet conformeren aan de eisen die verkoop/bedrijfsmanagement stelt mbt een project worden getoetst op het goed functioneren terwijl men dat eigenlijk eerst moet doen bij degene die de eisen neerlegt, immers: de eisen waaraan de developer zich te houden heeft kunnen een project maken en breken en dus ook het functioneren van een ontwikkelaar. "Hoelang denk je hieraan kwijt te zijn?" "2 dagen" "heb ik niet, kun je het in 1 dag doen?" "Nee, alleen met zeer veel mazzel en zonder testen", "Ach dat valt toch wel mee? Zie je, 1 dag". Wie is dan de lul als het 2 dagen worden? Of als het met die ene dag hacken (want 2 dagen kreeg hij niet) de kwaliteit van het project achteruit holt? De accountmanager die deze eisen heeft toegezegd aan de klant? Ha!

Kijk, verwacht nou niet teveel als je hier een topic volgt, er zijn gewoon ontzettend veel factoren die bepalen of en hoe je een succesvol bedrijf/project runt.

Ik kom hier al jaren en al 14 jaar op usenet, ik weet wel wat ik van een topic mag/kan verwachten, trust me . En hoe je een bedrijf runt ook. Ik ben echter ook een vakneuroot. Ik zie al jaren dat softwaredevelopment een erg slechte naam krijgt doordat er projecten mislukken om redenen die helemaal niet hadden gehoeven, doordat project veel te duur worden om redenen die helemaal niet hadden gehoeven. Frustrerend? Ja, zeker omdat de oorzaken van die ellende veelal niet bij de ontwikkelaars ligt maar bij management en verkoop. De ontwikkelaar heeft er echter het meest last van: "Jij hebt significant je planning overschreden" "ik heb vantevoren aangegeven dat het krap werd en wellicht onhaalbaar, toen kreeg ik die kleine klusjes voor de CEO ertussen door en..." ... en dan, dan gaat die manager zeggen: "Je hebt helemaal gelijk, het is mijn fout, ik ga het meteen rapporteren aan mijn baas" ? dat denk ik toch niet.

Vandaar dat het echt zo simpel is, je contract met je werkgever: lever de dienst waarvoor je bent aangenomen en waarvoor je op de loonlijst staat. Doe je meer, eis dan ook meer. Dat is niet 'zoooo 1950!', maar simpelweg realiteit. Daarom werkt het ook veel beter als je werknemers mede-eigenaar laat worden van het bedrijf, ze zijn dan niet louter dienstverlenende werknemer maar ook werkgever.

Ik kan hier toch onmogelijk verder dan dit serieus op in gaan?

Ik heb geen idee, jij begon over het vergelijken van vastgestelde productiewerkzaamheden met softwaredevelopmentwerkzaamheden. Als je dat serieus opingaan vindt, dan waardeer ik je inzet maar kom dan niet aan dat je om mijn mening moet lachen want dan snap je er ECHT gewoon werkelijk niets van.

[EfBe]

Verwijderd schreef op 05 september 2004 @ 23:06:
Maargoed, ik ben het wel eens met het punt van Eefbe dat de prestatie wordt bepaald op het behalen van de gestelde targets binnen de beschikbare tijd. Als men mij vraagt "hoeveel tijd heb je hiervoor nodig" en ik geef aan 8 uur, en het wordt 16 uur dan heb ik het verknalt, dan had ik een betere inschatting moeten geven.

En wat doe je dus? Je geeft een schatting in die gebaseerd is op een lager kunnen dan je werkelijk kan, om jezelf in te dekken, wat nadelig voor je kan zijn, want je kan hierdoor lijken op iemand die niet zoveel kan, jouw planning is altijd het kritieke pad

Je kunt DAARDOOR dus ook stoutmoedig worden en denken "no guts no glory" en een planning afgeven die aangeeft hoe je werkelijk denkt te gaan presteren. Veelal haal je die echter niet, doordat er vanalles tussenkomt: klant belt met niet project-gerelateerd probleem, JIJ moet dat verhelpen etc. etc. Dat doe je 1 keer en dan weet je wel beter.

Je geeft aan: 'de beschikbare tijd'. Hoe is die opgesteld/gedefinieerd? Is die tijd wel realistisch mbt de ingeschatte functionaliteit die moet worden gerealiseerd? Het lullige is dat men dat alleen weet achteraf, niet vooraf, hoe wollig managers ook kunnen praten of gokken.

[Verwijderd]

de eisen waaraan de developer zich te houden heeft kunnen een project maken en breken en dus ook het functioneren van een ontwikkelaar. "Hoelang denk je hieraan kwijt te zijn?" "2 dagen" "heb ik niet, kun je het in 1 dag doen?" "Nee, alleen met zeer veel mazzel en zonder testen", "Ach dat valt toch wel mee? Zie je, 1 dag". Wie is dan de lul als het 2 dagen worden? Of als het met die ene dag hacken (want 2 dagen kreeg hij niet) de kwaliteit van het project achteruit holt? De accountmanager die deze eisen heeft toegezegd aan de klant? Ha!

Dit komt zo bekend voor he Vooral de project manager die per direct zegt dat hij niet meer die tijd beschikbaar heeft. Alsof de developer opeens vier handen extra erbij tovert.

De realiteit is zelfs zo, dat er van de werknemers wordt verwacht dat ze dan maar overuren maken, en dat zorgt voor nog meer irritaties in het al chaotisch geregelde project, met alle gevolgen van dien. De sfeer gaat sterk achteruit, daarbij ook de kwaliteit en concentratie. Ondertussen gaat de operationeel manager een beetje zeuren over inzet, .. en dan is het hek van de dam want de developers weten dondersgoed dat ze er niets aan kunnen doen, dat opbouwende kritiek bij management het linkeroor ingaat en het rechteroor weer uit, en dat de developer er weer op aan wordt gekeken. Het ergste is nog, dat je weet dat het de volgende keer weer net zo gaat, zonder positieve wijziging. Want inderdaad ligt de oorzaak van het probleem niet bij developers, maar mogen ze wel weer de problemen gaan oplossen die ontstaan zijn door:

- het toekennen van functionaliteiten in een project door een account manager zonder dat de beste man of vrouw de ballen verstand heeft van de haalbaarheid.
- het toekennen van functionaliteiten in een project, en "ow.. oops" vergeten door te geven aan de personen die het moeten maken.
- het onvoldoende afkaarten, of documenten van de gemaakte afspraken, klanten willen altijd voor een dubbeltje op de eerste rij zitten zou ik ook doen. Resultaat is uiteraard "maar we hadden destijds toch besproken dat we zus en zo gingen doen?"..
- onvoldoende slagkracht van project managers, alles overleggen met hun manager, halen ze niet alleen een wit voetje maar vegen ze hun eigen bureau ook nog schoon. Dit heeft als gevolg dat verzoeken van de klant aan de projectmanager bijna altijd worden geaccepteerd door de operationeel manager, want de project manager laat het in zijn voordeel graag escaleren, altijd even overleggen. Wie is de lul ... de developer.
- Rommelige planning, 1 uurtje zus, 1 uurtje zo.. over het algemeen ben je meer opstarturen kwijt met zulke planning dan dat je daadwerkelijk aan je werk toekomt.
- Project manager komt naar je toe "dit is belangrijk, moet nu", dit heeft momenteel even prio, of nog erger een operationeel manager die je persoonlijk taken gaat opleggen zonder overleg met de project manager, met als gevolg dat je hele planning in een klap naar de klote is. Baas over baas he.
- etc.etc.

En het lompe is, je kunt het ze keer op keer zeggen, maar ze begrijpen de boodschap niet. Hoe ver een project ook over zijn uren heen gaat, ze moeten allemaal toch hun eigen eilandje schoon houden.

[ Voor 7% gewijzigd door Verwijderd op 06-09-2004 10:26 ]

[Anoniem: 69767]

Er is hier een enorm goed boek over geschreven:

Peopleware, Productive Projects and Teams, 2nd Ed.

Want het ziet er naar uit dat het management geen kaas heeft gegeten van het managen van software developers...Dit boek is echt z'n geld waard !!

[ Voor 8% gewijzigd door Anoniem: 69767 op 06-09-2004 10:40 ]

[Verwijderd]

Anoniem: 69767 schreef op 06 september 2004 @ 10:38:
Er is hier een enorm goed boek over geschreven:

Peopleware, Productive Projects and Teams, 2nd Ed.

Want het ziet er naar uit dat het management geen kaas heeft gegeten van het managen van software developers...Dit boek is echt z'n geld waard !!

Ja en wat moet de developer hiermee, of dacht je echt dat het management zijn eigen fouten serieus neemt en zulke boeken gaat lezen? Management is de laatste tak die verantwoording neemt voor fouten, en stom als ze zijn worden de fouten lager neergelegd.

[Anoniem: 88695]

dit is gewoon weer een voorbeeld van mensen die niet durven te investeren, die gaan voor de winst van de dag.

een programeur is geen aardappel raper... je kan niet zeggen jij gaat vandaag 120 Kg aardappels rapen... een programeur is een creatief persoon en hier wil ik niet mee zeggen dat hij of zij zich niet aan de planning moet houden.

programeren in een team kan je vergelijken met een team sport... de programeurs onderling weten erg snel al wie de beste programeur is en wie de slechtste... dat is iest waar je iest mee kan doen... als jij als bedrijf iemand meer verantwoording geeft bijvoorbeeld je maakt iemand van de (senior)programeurs team leider... dan kan je aan die persoon vragen over het functioneren van onder geschikte.

Als buitenstaander (dus iemand die niet in dat team programmeerd) kan je heel erg slecht opmaken wie de beste is en wie de slechtste. of wie wel functioneerd en wie niet.

Oja bij hogergeschoolde werkt over het algemeen niet het schoolmeester principe van ik geef opdracht en jij voert het uit... op die manier heb je geen commitment in je team. geef je team eigen verantwoording en je productieviteit schiet omhoog

uiteindelijk gaat het toch over de productiviteit van de werknemenrs... anders gezegt ik zal nooit willen en kunnen werken bij een bedrijf die verantwoording niet durft neer te leggen op andere plaatsen dan het management en daarmee dus onprofesioneel bezig is... en projet team heeft eigen verantwoording en een eigen beslissingsbevoegdheid binnen een bepaald kader

[D4Skunk]

Ik ben het eens met Marik2000...

Hoe ik het zou oplossen (en ik heb wel een paar jaar relevante ervaring) :
Verleg het probleem naar de personen die het beste de capaciteiten kunnen inschatten : de programmeurs zelf...
Werk met incentives, en laat de mensen zelf hun werk onderverdelen. Hang bv aan elk projectonderdeel een bepaalde 'prijs', en veil die projecten aan 1 of meerdere medewerkers... Laat de opdracht uiteindelijk uitvoeren door de 'goedkoopste'. Geef de mogelijkheid om met meerdere personen op 1 project te bieden.. Zorg er wel voor dat je bij disputen een onafhankelijk bemiddelaar hebt die geschillen kan oplossen.
Commitment zal er zeker zijn... Werk een matrix-beoordelingsmodel uit....

offtopic:
Ik wil anders wel eens een concreet voorstel voor jouw management uitwerken hoor (ik ben freelance consultant).

[Verwijderd]

D4Skunk schreef op 07 september 2004 @ 11:32:

Dat iemand iets goedkoper kan doen betekend niet dat het ook goed wordt gedaan. Ik vind het model wat jij voorstelt iets wat bij een bedrijf als de Lidl of de Aldi past, maar niet bij een bedrijf wat naar kwaliteit streeft. Hiermee geef je de mogelijkheden tot slechte kwaliteit een flinke impuls. Want misschien dat die uur werk minder wel heeft betekend dat er minder controles in broncode worden uitgevoerd, of dat er geen transacties worden gebruikt.

[Creepy]

D4Skunk schreef op 07 september 2004 @ 11:32:
Commitment zal er zeker zijn...

Evenals onderlinge strijd en je houd een lekkere teamspirit over.
Daarnaast bestaat de kans dat als er twee zijn die erg graag een onderdeel willen doen dat ze tegenelkaar op gaan bieden.
Een ontwikkelteam laten bieden op de onderdelen. Leuk voor de commitment op korte tijd, klote voor de teamsfeer.

[Anoniem: 119222]

Programmeer problemen kunnen uiterst complex zijn, ik heb met redelijk wat ervaring bijvoorbeeld 2 dagen nodig, om een firewall te maken in C++ die bijvoorbeeld ook secure socket layer van internet explorer kan aftappen en zo al het encrypte dataverkeer kan lezen. Een visual basic programmeur die op c++ overstapt kan daar wel 1 jaar of langer voor nodig hebben. (Ik schat dat iemand die net begint daar 4 jaar voor nodig heeft voordat ie code op ring 0 kan schrijven zonder het systeem te laten crashen.)

Een verschil van jaren op 1 eenvoudige klus met verschillende programmeurs...

Toch hoeft die andere niet slechter te zijn, helemaal niet, je moet namelijk zoveel weten als programmeur, je hebt jaren ervaring nodig.

[Anoniem: 121179]

Cuball schreef op 05 september 2004 @ 02:25:
[...]


ik ben niet de schoolmeester, ik ben een programmeur binnen het bedrijf. Waarom prestaties meten, wel heel eenvoudig, binnen het bedrijf werken we met een variabel loon, die aangepast wordt naargelang de prestaties van de werknemer. Voor andere diensten is dit veel eenvoudiger te bepalen, bv volledig uit de lucht gegrepen: dienst klantenbeheer heeft enkele afspraken en eentje ervan is dat prestaties gemeten worden naargelang het aantal afgewerkte dossiers (elke dossier neemt ongeveer een zelfde tijdsduur in beslag) dus dit is gemakkelijk te meten...

Kijk eens naar de taken die uitgevoerd worden. Bij ons bedrijf (consultancy, ook redelijk lastig objectief dingen vast te stellen) werken ze oa met een klant-tevredenheidsbonus. Naar gelang de beoordeling van de klant krijg je een extra beloning.

[EfBe]

Anoniem: 121179 schreef op 07 september 2004 @ 12:09:
Kijk eens naar de taken die uitgevoerd worden. Bij ons bedrijf (consultancy, ook redelijk lastig objectief dingen vast te stellen) werken ze oa met een klant-tevredenheidsbonus. Naar gelang de beoordeling van de klant krijg je een extra beloning.

Maar dat werkt wat lastig als je developers hebt die aan de lagere lagen van een applicatie werken: geen prettig ogende plaatjes die hun werk direct tonen aan de klant, dus hoe meet je of een klant tevreden is met hun werk?

[D4Skunk]

Verwijderd schreef op 07 september 2004 @ 11:49:
[...]


Dat iemand iets goedkoper kan doen betekend niet dat het ook goed wordt gedaan. Ik vind het model wat jij voorstelt iets wat bij een bedrijf als de Lidl of de Aldi past, maar niet bij een bedrijf wat naar kwaliteit streeft. Hiermee geef je de mogelijkheden tot slechte kwaliteit een flinke impuls. Want misschien dat die uur werk minder wel heeft betekend dat er minder controles in broncode worden uitgevoerd, of dat er geen transacties worden gebruikt.

Het lijkt me nogal vanzelfsprekend dat het bonussysteem niet alleen afhankelijk is van de code, maar ook van kwaliteit/klanttevredenheid/vooropgestelde termijnen e.d.
Vandaar dat ik ook op het einde van m'n post geschreven had : Werk een matrix-beoordelingsmodel uit....
De bedoeling van deze aanpak is er proberen voor te zorgen dat iedereen zoveel mogelijk achter zijn project staat... en dus ook gemotiveerder zal zijn... Taken die niemand graag uitvoert zullen op termijn dan toch programmeurs vinden: het principe van vraag & aanbod..

quote:
D4Skunk schreef op 07 september 2004 @ 11:32:
Commitment zal er zeker zijn...


Evenals onderlinge strijd en je houd een lekkere teamspirit over.
Daarnaast bestaat de kans dat als er twee zijn die erg graag een onderdeel willen doen dat ze tegenelkaar op gaan bieden.
Een ontwikkelteam laten bieden op de onderdelen. Leuk voor de commitment op korte tijd, klote voor de teamsfeer.

Als er twee op een onderdeel doorbieden, laat ze het dan tesamen uitwerken. Dan zal direct blijken of men het voor het geld doet, of men daadwerkelijk geinteresseerd is in het onderwerp.

Het blijft natuurlijk natte-vinger-werk, maar op deze manier heb je wel een manier om mensen min of meer te betalen naar prestaties, wat de initiële vraag was van de TS. Iemand die in middenkader gewerkt heeft, weet dat het management geen antwoorden verwacht in de trant van : "dat is niet mogelijk, want er is probleem a en probleem b...". het management verwacht oplossingen, geen problemen, anders kunnen ze het net zo goed zelf doen, en is je functie overbodig.
Indien je een beter alternatief hebt, be my guest

[Verwijderd]

D4Skunk schreef op 07 september 2004 @ 13:57:
Indien je een beter alternatief hebt, be my guest

Zorgen dat je het werk doet en anders zoek je maar een andere werkgever?

[D4Skunk]

EfBe schreef op 07 september 2004 @ 12:52:
[...]

Maar dat werkt wat lastig als je developers hebt die aan de lagere lagen van een applicatie werken: geen prettig ogende plaatjes die hun werk direct tonen aan de klant, dus hoe meet je of een klant tevreden is met hun werk?

Adhv de gebruikers van die laag, maw de programmeurs die er mee werken

[D4Skunk]

offtopic:
[quote]Verwijderd schreef op 07 september 2004 @ 14:12:
[...]


Zorgen dat je het werk doet en anders zoek je maar een andere werkgever?[/quote]

Hoe hoger je in de maatschappelijke ladder opklimt hoe meer dit het geval is.
Iemand met een zeer hoge functie heeft niet de vrijheid om zijn doelstellingen te kiezen, maar wel de manier waarop ze gerealiseerd worden. (dit in tegenstelling tot wat de meesten denken : mijn baas die voert maar wat uit...)

[Bobco]

EfBe schreef op 05 september 2004 @ 14:41:
[...]
Hoe dacht je hoe microsoft dit soort dingen regelde? -> per functionaliteit onderdeel wordt een persoon benoemd die verantwoordelijk is daarvoor en zn ontwikkelaars aanstuurt mbv planning voor dat onderdeel. De ontwikkelaars werken dus binnen de grenzen gesteld voor dat functionaliteitsonderdeel en moeten dat afhebben in de gestelde tijd. That's it.

Interessant dat je dat noemt. Zodra het over roadmaps bij MS gaat lijkt het meest gebruikte woord 'uitstel' en 'feauture doorgeschoven naar volgend release'. Dit betekent overigens niet dat ik wel weet hoe je goed planned of meet hoe produktief een programmeur is.

Het is in deze thread al heel vaak opgemerkt: de ene programmeur is de andere niet en het ene project is ook het andere niet. Helaas nemen klanten geen genoegen met de opmerking 'het kost wat het kost en het is klaar wanneer het klaar is'. OP dat vlak ligt er dus een schone taak voor een verkoper/account manager die eigenlijk alleen maar als taak heeft om de klant tevreden te houden. De technicie zouden geen weet moeten hebben van de afspraken over tijd en geld en zich moeten concentreren op de functionaliteit.

[ILUsion]

Volgens mij is het voor development beter om per project te bekijken wat er gedaan moet worden en daar aan vast (in samenspraak met de teamleider) het team een bepaalde tijdsduur toe te kennen en een prijs per uur bv. En afhankelijk van de tijd die het team gezamelijk nodig heeft alles uitrekenen (voor de deadline: meer, na de deadline: verantwoording en herevaluatie of minder loon (maar dat is niet goed voor moeilijke projecten met bugs etc.). Per team nog een briefing na het werk waarbij elk teamlid bij de teamleider klachten/verbeteringen kan melden en ook kan melden als een bepaalde klus in het team door een persoon slecht uitgevoerd werd of te lang duurde (of omgekeerd natuurlijk) zodat er nog bijsturingen gedaan kunnen worden.
Anders kun je ook gewoon een loon geven aan de hand van de projectprijs: grote:moeilijke projecten meer en kleine/makkelijke projecten minder betaald door de opdrachtgever en de programmeurs hun vaste stuk daaruit als alles binnen de deadline blijft of de vertragingen verantwoord kunnen worden. Zo kun je natuurlijk ook het loon schalen ten opzichte van wat het bedrijf als geheel presteert zonder aantal regels code te hoeven tellen.
Als laatste alternatief is goed bijhouden wat ieder doet: geschreven code wordt waarschijnlijk in een CVS-achtig systeem opgeslagen en daar kun je waarschijnlijk wel logs van hebben, alle andere taken (onderzoek, vormgeving, ...) laat je controleren door een teamleider en de duur ervan opschrijven; nog steeds geen garantie, maar in zo'n job heb je geen garanties...

[justmental]

Het is altijd lastig om als dienstenleverancier een bonusstructuur op te stellen waarin het belang van de klant gediend wordt.
Sowieso wisselen de doelstellingen per klant, de een gaat voor TCO op een systeem, de ander misschien voor het minimaliseren van business risico's.
Daarnaast is het belang van de leverancier lang niet altijd in elke termijn in lijn met het belang van de klant. Een leverancier zal vaak graag meer omzet zien in zijn contract met de klant, een bonusstructuur op omzet wakkert dit alleen maar aan.
Ook werk je meestal met teams aan een oplossing. Binnen de teams is het aandeel in de kwaliteit/kwantiteit/communicatie/klanttevredenheidetc erg moeilijk te bepalen. De ene bouwer bouwt misschien wel een prachtfunctie met een snelle tijd op de klok waar de ander de FO-er aanspreekt om een discrepantie in het ontwerp waardoor de hele functie terug naar de tekentafel moet.

Al met al is mijn ervaring dat dergelijke bonusregelingen in de lange termijn de zaken alleen maar benadelen.
Wat wel meespeelt is dat de sales van de leverancier meestal al een bonusregeling heeft waardoor de negatieve effecten al niet meer voorkomen kunnen worden.

Als alternatief kun je bijvoorbeeld nadenken over een regeling gebaseerd op professionele ontwikkeling. Dit stimuleert de werknemer in de ontwikkeling op z'n vakgebied.
Zo had ik bij mijn vorige bedrijf een bonus gebaseerd op artikelen schrijven en lezingen geven.

[djengizz]

Ik blijf erbij dat het beoordelen van een programmeur een objectieve niet absoluut meetbare waarde is en ook zo behandeld moet worden. Het belangrijkste in mijn ogen is dan ook nog steeds dat de 'objectieve beoordeling' op een eerlijke manier verloopt. Het meten van de objectiviteit en eerlijkheid van een beoordeling zijn volgens mij makkelijker vast te stellen en moeten gewaarborgd zijn. Ik ben het ook met tomatoman eens dat angst voor eerlijkheid

tomatoman schreef op 05 september 2004 @ 15:40:

hierin vaak een beperkende factor is, maar ook dit is op te lossen met 'meetbare waarden' (meerdere beoordelaars bevoorbeeld).
Nogmaals, binnen een (project) groep weet iedereen best wie de betere programmeur is. De kunst om dit boven water te krijgen is veel belangrijker en hoeft niet absoluut te zijn.
Om dit buiten software development te trekken: Hoe beoordeel je een wetenschapper die zoekt naar een medicijn voor een ongeneeselijke ziekte en misschien nooit het medicijn zal vinden?

[Verwijderd]

Bobco schreef op 07 september 2004 @ 18:07:

Dat is niet een kwestie van planning, maar een kwestie van het opnieuw bepalen van de prioriteiten. Ik neem aan dat je doelt op Longhorn, maar dat was gewoon een kwestie van het verplaatsen van resources omdat de prioriteit van SP2 hoger werd gelegd.

[misfire]

ILUsion schreef op 07 september 2004 @ 18:28:
Volgens mij is het voor development beter om per project te bekijken wat er gedaan moet worden en daar aan vast (in samenspraak met de teamleider) het team een bepaalde tijdsduur toe te kennen en een prijs per uur bv. En afhankelijk van de tijd die het team gezamelijk nodig heeft alles uitrekenen (voor de deadline: meer, na de deadline: verantwoording en herevaluatie of minder loon (maar dat is niet goed voor moeilijke projecten met bugs etc.). Per team nog een briefing na het werk waarbij elk teamlid bij de teamleider klachten/verbeteringen kan melden en ook kan melden als een bepaalde klus in het team door een persoon slecht uitgevoerd werd of te lang duurde (of omgekeerd natuurlijk) zodat er nog bijsturingen gedaan kunnen worden.
Anders kun je ook gewoon een loon geven aan de hand van de projectprijs: grote:moeilijke projecten meer en kleine/makkelijke projecten minder betaald door de opdrachtgever en de programmeurs hun vaste stuk daaruit als alles binnen de deadline blijft of de vertragingen verantwoord kunnen worden. Zo kun je natuurlijk ook het loon schalen ten opzichte van wat het bedrijf als geheel presteert zonder aantal regels code te hoeven tellen.
Als laatste alternatief is goed bijhouden wat ieder doet: geschreven code wordt waarschijnlijk in een CVS-achtig systeem opgeslagen en daar kun je waarschijnlijk wel logs van hebben, alle andere taken (onderzoek, vormgeving, ...) laat je controleren door een teamleider en de duur ervan opschrijven; nog steeds geen garantie, maar in zo'n job heb je geen garanties...

Dat klinkt allemaal leuk en aardig maar nu ga ik even lastige vragen stellen:

Hoe bepaal je de tijdsduur en "prijs per uur" voor een project? Wat zijn "moeilijke projecten" en wat zijn "kleine/makkelijke projecten". Wat zijn "vaste stukken"? Welke metrieken uit je SCM systeem gebruik je om een uitspraak over prestaties te doen?

Dit zijn precies de vragen die je jezelf niet moet gaan stellen. Het kost heel veel moeite om iets te verzinnen voor deze metrieken wat iedereen accepteert. Zoals je zelf zegt biedt het geen enkele garantie of waarde. Het zijn alleen maar getallen die altijd eerst in een bepaalde context moeten worden gewogen. Deze context wisselt echter zeer sterk per situatie en per probleem, dus je weet niet waarop je de getallen moet toetsen.

Het is precies hetzelfde als dat je je afvraagt: deze persoon weegt 80 kilo, is deze persoon te zwaar? Je weet niet of het een man of een vrouw is, hoe lang of hoe oud ie is. En stel dat je weet dat het een kerel van 30 is die 1.75 is, moet ie dan mee doen aan een bokswedstrijd, hardlopen of bierbuiken duwen? Pas als je de totale context weet weet je of het uberhaupt relevant is om op gewicht te toetsen, en welke gegevens je al dan niet nog meer nodig hebt.

Waarom moet er een overleg ná het werk zijn waarop een teamlid naar de teamleider moet stappen? Waarom kan de teamleider niet zélf beoordelen wat de prestaties wat zijn teamleden zijn? Je zou hierin de teamleider beter moeten vertrouwen dan zijn leden, anders heb je een slechte teamleider.

Het zijn allemaal mechanismes om verantwoordelijkheid af te schuiven van de managers. Zij moeten echter wel beslissen wat voor het bedrijf het meest productief is om mee bezig te zijn, en wie dit moet doen. Zij moeten ervoor zorgen dat mensen gemotiveerd blijven, en weten wat ze moeten doen. Is het dan zo vreemd om te verwachten dat zij ook een duidelijk beeld heeft van wie ook productief bezig is, wie gemotiveerd is, en wie doet wat zij zeggen zonder dat ie het verprutst? Volgens mij is het gewoon zo simpel, en als het niet zo simpel is, dan is het veel te ingewikkeld en gaat je organisatie binnen no time naar de knoppen.