Produktive teams February 27, 2008 08:49 over 4 years ago
Falder produktiviteten i projektet? Fyr halvdelen af dine ansatte. Det lyder måske som en drøm men fakta beviser en anden historie. Problemet er ikke arbejdskraft men måde den bliver brugt på. Store IT projekter rekruttere mange udviklere ude at vide hvad de skal bruges til.
Halvdelen af store softwareprojekter slår fejl eller stagnere indenfor to år. Langt den hyppigste årsag er dårlige ledelse og manglerne social intelligens hos projektdeltagerne.
En altødelæggende tendens i organisationer er at gøre projektteams alt for store. Ofte ses projekter med 100+ udviklere og andet godtfolk. Så mange mennesker passer perfekt samlebåndsarbejde og bil fremstilling men ikke softwareprojekter. Du har helt sikkert haft tanken; hvis de fyre et par stykker kunne vi blive færdige før tiden.
Softwareprojekter fungerer bedst i små produktive teams. En god regel siger at alle deltagere skal føle at deres rolle er vigtig for at kunne præstere. Hvis en opgave er delegeret til for mange fratager man den enkeltes mulighed for at sige; dette tager jeg mig af. Hvis der er få deltager i projektet må de hver tage en støre bid af ansvaret og samtidig falder kommunikations behovet voldsomt. Det bliver nemmere at overskulle opgaverne og så kan man både estimere og måle den enlige produktivitet. Netop heri ligger kimen til mange store projekters fejlslagne strategi.
I små teams er alle mere vigtige. Alle skal føle at projektet afhænger af netop deres indsats og at de bliver belønnet og respekteret for den indsats de yder. Et velfungerende team må have en god fordeling af menneskelige egenskaber og kvalifikationer. Det nytter ikke at nogle har et kæmpe ego og andre det modsatte, der må være en fin balance mellem deltagerne for at skabe den rette stemning.
Kulturelle forskelle kan ødelægge et team. Hvis man kigger på folk som arbejder hos IBM vil man ikke finde ret mange som vil søge job hos Google og omvendt. Det er der en god grund til.
Gode udviklere koster mange penge men de er det hele værd. En virkelig god udvikler koster kun 2 til 5 gange mere end den værste. Produktiviteten hos en virkelig god er 10 eller 20 gange højere. Ofte vil man se at enkelte af de værste ligefrem kan trække produktiviteten i negativ retning og dermed skabe uro i resten af teamet. Vigtige egenskaber hos de enkelte deltager i et godt stærkt team er respekt og ydmyghed. Med disse egenskaber kan det normale stress niveau holdes lavt.
Når man ansætter en udvikler eller programmør er det i orden at teste vedkommende men kun indenfor det felt hvor en indsats forventes. For en programmør kunne man give en opgave der skal løses på 30 min. Hvordan opgaves bliver grebet an giver en klar melding om kvalifikationer. Man kan ikke gå på kompromis med de tekniske kvalifikationer.
Det er vigtigt at alle projektdeltager føler team ånd og at organisationen forstår at skabe samhørighed og kulturel samhørighed. En metode til at højne sammenhold er små daglige møder hvor alle inddrages i alles opgaver.
Geografisk kan man befinde sig i USA eller Danmark, det er ligegyldigt. Det vigtige er at man er tilgængelig i samme tidsrum som resten af gruppen og at kernen i projektet kan sameksistere til enhver tid. Kørende chat og hyppige skype samtaler giver gode holdindtryk og fremme fornemmelse af teamfornemmelsen.
Desværre virker det som mange organisationer ikke har forståelse for store IT-projekter. Store projekter er ikke lig med en masse udviklere. Der findes undersøgelser fra US-militær som viser at teams på 200 udviklere ikke kan præstere mere end teams på 40 udviklere.
Der er to hovedårsager til dette.
En af de altødelæggende faktorer er kommunikationen mellem alle de impliceret parter som øger eksponentielt. Det betyder at kommunikationen overtager den enlige arbejdsproces.
Lige nu i Danmark gør vi det helt forkert.
By Frank Vilhelmsen - 2 tags: agile productivity - Add comment