Dette indlæg er alene udtryk for skribentens egen holdning.

Hvordan håndterer man forskelle mellem teammedlemmer?

12 kommentarer.  Hop til debatten
Blogindlæg14. januar 2009 kl. 05:27
errorÆldre end 30 dage

Alle der har arbejdet i grupper har prøvet problemstillingen med at ikke alle i en gruppe er lige hurtige i optrækket og ikke lige produktive. Der findes masser af undersøgelser som viser at der er en kæmpe forskel på hvad selv programmører med samme erfaring og baggrund kan udrette - en (kritiseret) undersøgelse fra 60'erne viser en produktivitetsforskel med faktor 20 mellem programmører uden at finde en forklaring i erfaringsniveau, domæneområde eller kodekvalitet (se f.eks. dette blogindlæg).

Det er altså sandsynligt at en (eller flere) på dit programmeringsteam ikke bidrager særlig meget til kodebasen sammenlignet med de andre og det kan skade retfærdighedsfølelsen i teamet og give negative følelser overfor det uproduktive (underproduktive) teammedlem og hvordan håndterer man det?

Tager man en snak med det uproduktive teammedlem om der er noget der hæmmer produktiviteten' Tager man en snak med team for at løse op for de negative tanker og få dem til at acceptere personlige forskelle' Tager man det uproduktive teammedlem ud af teamet' Eller noget helt andet'

12 kommentarer.  Hop til debatten
Fortsæt din læsning
Debatten
Log ind for at deltage i debatten.
settingsDebatindstillinger
1
C Frigaard
14. januar 2009 kl. 09:14

Jeg har også hørt om tilsvarende analyser, dog med en faktor 10 i produktionsforskel.

Så skaf en projektleder, der skaffer to højproduktive programører eller tilsvarende 20 lavproduktive aber!

Desværre kunne man forstille sig at de højproduktive programmører også har en indbygget frastødning fra andre højproduktive; et fænomen ala "primadonna programmør".

Så et socialt velfungerende team kunne måske kræve både høj og lav produktive kodere---de lavproduktive kunne jo evt være højproduktive med vittigheder, kaffesnak og lign.

Men igen er det vel en rent ledelsesmæssig opgave?

  • more_vert
    • insert_linkKopier link
3
Poul-Henning Kamp
14. januar 2009 kl. 10:33

Der er sådan set ikke noget problem at håndtere. Man skal bare indrømme at det forholder sig sådan, istedet for at foregøgle sig selv og hinanden at "alle er lige" og tilsvarende børnehavebavl.

Find ud af hvem der er gode til hvad, find ud af hvad der er er critical path, fyld de bedste personer på den del og hyg jer så med at både de store og små forskelle er et Hurra værd.

Resten af teamet sidder naturligvis ikke bare og klapper takten, de fylder på det kodeskelet som kodekarl producerer.

Læs koden, lær af den, stil spørgsmål hvis I ikke forstår den -- der er gode chancer for at I har fundet en fejl.

Og kodekarl skal naturligvis huske at han er medlem at et team, alt hvad der kan uddelegeres uden at skade tidsplanen bliver det naturligvis.

Læs evt. om "The surgical team" i "The Mythical Man-Month".

Poul-Henning

  • more_vert
    • insert_linkKopier link
4
Nicolai Lundgaard
14. januar 2009 kl. 11:42

Tja, sådan forholder det sig nok mange steder. Der er også stor forskel på hvor meget vi betaler i skat, hvor faktoren er væsentlig højere end 20. Men som PHK siger, skal man nok bare lære at acceptere at der er sådan.

  • more_vert
    • insert_linkKopier link
5
Therese Hansen
14. januar 2009 kl. 14:10

Da Carsten skrev Primadonna-programmør tænkte jeg ligesom PHK på The surgical team i the Mythical Man-Month :-). Jeg kender mange som ville passe som kirurgen i det scenario og drømmer om at prøve det - selv har jeg det bedre med samarbejde.

Og for mange alfa-programmører på et team kan være et problem såvel som en der sakker bag som dansen - en Omega-programmør :-).

Måske er det et ledelsesproblem at håndtere netop dette, men de gange jeg har prøvet det har været i selvkørende teams, som altså ikke har en leder til at håndtere problemstillingen. Og så er det nødvendigt at finde ud af hvad en leder ville gøre i den situation, så man selv kan forsøge at løse op for situationen.

  • more_vert
    • insert_linkKopier link
6
Martin Falck-Hansen
14. januar 2009 kl. 20:25

Infoq har også omtalt en nærliggende diskussion Handling Your Team's "Rotten Apple":

http://www.infoq.com/news/2009/01/handling-your-underperformer;jsessionid=3D086381DDC15A4E3A6C262D10FC25D9

I mange af de teams jeg har været en del af, har der været de personer som helst ville kode (og dermed var med til at bidrage mest til kode basen) og så andre som var med til møder bl.a. for at afklare krav, ændringsønsker og andet. Dertil kommer at man ikke bare kan kigge på de "rå" kodeliner for at sige hvem der bidrager mest. Visse dele af koden er mere kompleks end andre.

  • more_vert
    • insert_linkKopier link
7
Therese Hansen
14. januar 2009 kl. 20:55

Fedt link til InfoQ. Som der også står i den artikel, så vil jeg tøve med at kalde et underproduktivt teammedlem for et råddent æble, men ikke desto mindre er det en interessant diskussion.

Selvfølgelig har forskellige mennesker noget forskelligt at byde på, men jeg har samtidig også set et eksempel på et programmeringsteam, hvor et teammedlem ikke bidrog med noget andet end de andre, men stadig var underproduktiv, og det gav en så dårlig stemning at de andre teammedlemmer udøvede noget der minder om mobning mod det underproduktive teammedlem.

Der skulle selvfølgelig have været nogle der sagde fra før det kom til mobningsstadiet. Men hvad skulle der have været gjort før det kom så vidt?

  • more_vert
    • insert_linkKopier link
8
Torben T. Nielsen
14. januar 2009 kl. 21:14

Jeg har engang i et projekt reduceret antal kodelinier fra 45.000 til 15.000 på to uger.

Det endte med meget mange færre fejl, fjernelse af mange memory leaks og nemmere vedligeholdese af den resterende kode. Og med den samme funktionalitet!

De 30.000 linier fjernet kode var lavet af den mest produktive kodekarl eller hvad?

Mvh Torben.

  • more_vert
    • insert_linkKopier link
9
Poul-Henning Kamp
14. januar 2009 kl. 21:56

Jeg har engang i et projekt reduceret antal kodelinier fra 45.000 til 15.000 på to uger.

"bidrage til kodebasen" skal ikke læses på PHB måden hvor Wally kan "skrive sig en minibus i eftermiddag".

Det er faktisk oftest på evnen til ikke at skrive kode man kender de produktive programmører.

Poul-Henning

  • more_vert
    • insert_linkKopier link
10
Therese Hansen
14. januar 2009 kl. 22:20

I InfoQ-artiklen måler de produktivitet i User Story Points. Det er nok meget sigende.

  • more_vert
    • insert_linkKopier link
12
Lars Bengtsson
25. januar 2009 kl. 16:14

I InfoQ-artiklen måler de produktivitet i User Story Points. Det er nok meget sigende.

Mener du at det ikke er en god måde at måle produktivitet på? Nu kender jeg ret lidt til den viden der er på området, men jeg har da selv arbejdet i et agil-agtigt projekt, og kan egentlig ikke forestille mig nogen sytematiseret metode til at måle produktivitet på. Det nærmeste jeg kan komme det er at man kan lave en subjektiv vurdering ud fra opgavens sværhedsgrad og de mere eller mindre heldige forsøg programmøren bruger på at løse opgaven. Med held så mener jeg dels at der ofte optræder nogle tekniske problemer i de frameworks som man bruger. Og dels at man kan være heldig med at vælge en successfuld løsningsmodel, hvilket det ikke altid er muligt at analysere sig frem til i starten af opgaveløsningen.

Man kan selvfølgelig mene at programmørens evner til at håndtere disse parametre ikke bare er held, men er der ikke nogen gange hvor det er held? Så kan man sige at over et længere forløb så kan det ikke bare være held der gør at en programmør er mere eller mindre produktiv end andre.

  • more_vert
    • insert_linkKopier link
11
Kaspar Lundsby
15. januar 2009 kl. 11:57

Med fælles kodeejerskab og parprogrammering bliver det sværere at identificere enkeltpersoner som værende "tunge". Et af formålene med parprogrammering er jo at gøre udviklerne mere ensartede inden for et team, så så længe disse individer kan lære noget af deres makkere, vinder teamet ved at bundniveauet bliver hævet.

//K

  • more_vert
    • insert_linkKopier link
2
Torben Mogensen
14. januar 2009 kl. 10:29

Jeg er enig med Carsten i, at det i den sidste ende er en ledelsesopgave. En leder bør kende sine medarbejderes styrker og svagheder og sætte dem til arbejde, der udnytter deres styrker og ikke hindres af deres svagheder. Hvis dette ikke kan lade sig gøre, så skal lederen enten efteruddanne arbejderen for at eliminere svaghederne (eller bibringe nye styrker) eller fyre vedkommende, hvis dette heller ikke kan lade sig gøre.

Ellers bliver det rent Dilbert.

  • more_vert
    • insert_linkKopier link