850 millioner October 16, 2007 05:26 over 4 years ago
Her er et billede af Tinglysningsrettens nye domicil på Majsmarken i Hobro. På en finurlig måde repræsenterer dette på udmærket mine tanker om produktivitet. Byggegrunden skulle være dækket med et tinghus men der blev fundet danefæ i undergrunden og byggeriet blev stoppet. Dog har folkene fra nationalmuseet lovet at arbejde så hurtigt de kan ved at modtage ca. kr. 587.000.-
Det sidste års tid har jeg arbejdet på to store projekter. Tilsammen løber de op på omkring ca. 850 millioner kr. De to produkter henvender tilsammen sig til næste hver eneste dansker og projekterne beskæftiger næsten en ansat for hvert postnummer der findes i Danmark.
Min rolle i disse projekter er både lille og ubetydelig. Ligesom de fleste andre er det meget begrænset med input hvert enkelt individ giver til den slags projekter og heri ligger samtidig den væsentligste årsag til lav produktivitet i store teams.
For et par år siden læste jeg en undersøgelse, udarbejder af det amerikanske militær. Undersøgelsen var sat i gang for at finde den ideelle størrelse på softwareudviklingsteams. Resultatet af undersøgelsen viste at team på mere end 40 personer slet ikke performer og hovedårsagen er den kraftig tiltagende kommunikation for hver ekstra medarbejder. Det er ikke nogen overraskelses at jo mindre jo bedre, men overraskelsen bestod i det faktum at en forøgelse i mandskab fra 50 til 60 personer i et team havde en direkte negativ affekt på den samlede målte fremgang.
Store projekter har det med at leve deres eget liv, gerne et noget ældre liv. Når en forretnings ide er født hyrer man en designer som derefter sider for sig selv i 40 dage. En designer gør ting smukke det ved alle. Når designeren er færdig med layout kan de rigtige serverfolk komme til og fylde data i applikationen. Langt henne i processen opdager en forretnings kyndig at der er noget galt. Krav til brugerforventningerne og flow mellem siderne stinker og der er gået næste to år.
Alle arkitekter stikker hovederne samme og bliver enige om at use casene er for dårligt beskrevet. Der findes en klar tendens til at tro hele applikationens liv er velbeskrevet i use casen. Desværre levere use casen ikke en funktionel beskrivelse. Det betraktes som utopi at have et levende produkt som stille og roligt udvikles i små iterative portioner.
For nogle år tilbage blev alle krav til systemet møjsommeligt skrevet ned inden selve udviklingen gik i gang men nu er vi alle blevet adrætte og kan arbejde uden at have en plan. Langt de fleste løber rundt, smaskforvirret uden et enligt mål for øje. En dag under et scrum møde fik jeg dette spørgsmål, “skal alle være dygtige på et adræt projekt”? Hvordan kan man svare på dette? Alle folk på alle projekter bør være dygtige! Den eneste forskel mellem et agile projekt kontra et vandfaldsprojekt er at man hurtigere opdager de svageste led/deltagere i et agile projekt.
Udvikleroplevelsen hos de ansatte er ligeledes et totalt overset punkt. Alle processer og værktøjer er valgt på det grundlag at alt bør være besværligt og tidskrævende. Nej måske ikke, men det virker sådan. Der ses ikke med milde øjne på udviklere som tager ansvar og griner mens de udføre deres respektive fag. Eller som det ofte sker, arbejder med noget andet end det i de første omgang var ansat til. Word eller XML. Lad os gøre det på den mest besværlige måde.
Efter min mening gør vi projekter alt for komplekse. Store som små. Vi gør det for at retfærdighedens vores tidsforbrug og vores konservative holdning til softwareudvikling.
Ingen maskiner kan afløse rå tankekraft ligegyldigt hvor mange CPU’er der findes.
Min pointe er at disse projekter slet ikke lever op til de krav som burde stilles fra projektejernes side og den forventede kvalitet udebliver. Vi bygger helt nye systemer men med en stor legacy-arv i form at traditionelle metoder og handlingsmøstre. Som samfund har vi udviklet os fra et information samfund til et videns samfund men det reflekteres ikke i vort arbejde.
By Frank Vilhelmsen - 1 tag: politik - Add comment