georg strøm bloghoved

Offentlig IT og den filippinske bus

Danske designere af IT-systemer kan lære af de mekanikere som bygger filippinske busser og holder dem kørende. Udfordringerne ligner hinanden, så den filippinske bus er en god analogi, når vi skal diskutere udvikling af IT-systemer.

Illustration: Privatfoto

De første busser blev bygget på jeeps som amerikanerne havde efterladt efter 2. Verdenskrig. De lokale mekanikere tilføjede to bænke til passagerer og satte et tag over. Senere blev jeepneys bygget af dele fra udtjente biler og udstyret med et karosseri af rustfrit stål som kan tåle det varme og fugtige klima.

Nu er det svært at skaffe dele til en bil som blev produceret for en snes år siden, så i stedet for at lede forgæves efter dele til den aktuelle model, køber mekanikerne for eksempel en ny kobling som passer i størrelsen og borer nogle ekstra huller til møtrikker som kan holde den fast.

I dag er det normalt for kostbart og risikabelt af bygge IT-systemer fra bunden af, så det er nødvendigt at bygge IT-system på en tilsvarende måde ud fra den platform og de moduler som er tilgængelige. Vi er bare ikke så bevidste om processen som de filippinske mekanikere. De er så at sige vokset op med at bygge ud fra de stumper der er til rådighed.

Den franske antropolog Claude Levi-Strauss kaldte det for bricolage. En proces hvor de tilgængelige stumper bruges til at løse et aktuelt problem. Det er forskelligt fra den måde vi er opdraget til at løse tekniske problemer. I uddannelser er det normale at starte med at definere målene med opgaven. Det er ikke normalt at bruge tid på at få en dyb viden om kunderne og deres behov, og det trækker normalt ned, hvis der er enkelte mangler i resultatet.

Ved bricolage er det umuligt at undgå mangler i resultatet. Det er nødvendigt at skaffe en dyb viden fra kunderne, så designerne kan afgøre hvilke mangler der har størst konsekvenser, og hvilke det ikke er umagen værd at gøre noget ved. Designerne og ledelsen må ikke være bange for at vælge fra, og de skal føle det er naturligt at udvikle den mindst dårlige løsning med de dele de har er til rådighed. Ellers går det som ofte i danske IT-projekter.

Platformen bliver valgt ud fra politiske hensyn uden nogen analyse af, om det overhovedet er muligt at bygge det ønskede system ud fra den. Prioriteringen bliver tilfældig, så de egenskaber der er gemt til sidst, ikke bliver implementeret. Nogle gange bliver resultatet et system som har funktionerne i kravspeccen, men hvor det er så langsomt at det ikke kan bruges i praksis, Ofte bliver designerne først opmærksomme på hastigheden, når systemet viser sig at være for langsomt.

Brícolage passer godt med en agil udviklingsproces, men der er et problem. Det er umuligt at forudse alle begrænsninger i delene på forhånd, så det er hele tiden nødvendigt at skaffe pålidelig viden om hvad konsekvenserne er, ved at fravælge en egenskab eller at udforme den på en bestemt måde. I praksis kræver det ofte at der er mindst en person, som har til opgave at skaffe den viden i løbet af projektet.

Han eller hun kan samtidig skaffe inspiration til endnu et område hvor udviklerne af et IT-system kan lære af en filippinsk bus. Ud over at klare forhindringerne er den farverig så du kan nyde at kigge på den. Der er ingen grund til at et system er kedeligt, blot fordi det er let at anvende og passer til opgaverne. Tvært imod er det værd at give brugerne af et selvbetjeningssystem nogle gode oplevelser til gengæld for den tid de bruger.


Jeg har tidligere skrevet om bricolage: Regulering af konflikter mellem tekniske muligheder og forretningsmæssige krav. Konflikthåndtering i IT projekter - mediation som mulighed, red. af Pia Deleuran. Jurist og Økonomforbundets Forlag 2011

Kommentarer (2)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Henrik Christensen

... at det offentliges services og forpligtelser skal ligne, opføre sig og være pålidelig eller sikker som en filippinsk bus og mener at kunne se adskillige tegn på en sådan uønsket tilstand allerede. At processen dertil så endda har været langt mere bøvlet og tidskrævende synes jeg ikke retfærdiggør det lave og grundlæggende ubrugelige ambitionsniveau.

  • 1
  • 1
Henrik Winther Jensen

Man kan vel sammenfatte artiklen ved at sige at processen skal være pragmatisk præget og resultaterne som brugerne oplever dem skal prioriteres højest. Det rimer vel meget godt med det syn som brugere og nogen gange ejere af systemet har. Uheldigvis er det som vi ved sjældent det perspektiv der dominerer når systemerne konstrueres. De dominerende perspektiver her er jo politikere (forstået i bred forstand), IT-arkitekter og økonomer, som dybest set er ligeglade med om systemet kan bruges eller ej. Og så bliver resultatet derefter.

Et problem som ikke rigtigt er beskrevet i artiklen er hvordan det enkelte projekt grænser op til andre projekter (genbrug, dataudveksling og sammenhængende oplevelser i forskellige systemer). Men spørgsmålet er om disse egenskaber kan blive dårligere håndteret end de er i dag?

  • 0
  • 0
Log ind eller Opret konto for at kommentere