Det handler om at ramme en fællesnævner, så software giver mening for alle.
Sådan er god software opbygget, forklarer Bo Carlsson, der er udvikler i ingeniørvirksomheden Niras.
"Hvis du vil have brugeren engageret og motiveret til at anvende et program, så er kodeordet feedback," lyder hans korte vurdering af vejen til god bruger-software.
"Hvis du tænker på et computerspil, bliver folk fuldstændig opslugt af spillet, fordi det giver feedback øjeblikkeligt. Samtidig er der ofte ikke behov for at tænke. Du skal i stedet handle. Det kan man lære meget af som software-udvikler."
Den filosofi ligger til grund for den næste udgave af et program, der hedder DRIVE (en forkortelse for drift og vedligehold), som er målrettet forsyningsselskaberne til vand, fjernvarme og afløb. Et program, der har eksisteret gennem mange år.
Målgruppen er således langt fra it-eksperter, men i stedet eksperter i fjernvarme og vandforsyning.
"Vi må erkende, at de tidligere versioner af DRIVE ikke har været brugervenlige nok, og derfor har vi rystet træet godt og grundigt. Tidligere har vi benyttet en vandfaldsmodel, hvor alt bare er blevet bygget på, men det er ikke den mest hensigtsmæssige vej."
Satte en teknoantropolog på sagen
Niras har således brugt det seneste år på at kigge dybt på data genereret fra programmet.
Hvad bliver brugt mest? Hvilken rækkefølge gør brugeren typisk tingene i? Er der funktionalitet, der bliver brugt forkert? Er der funktionalitet, der slet ikke bliver brugt?
Det er nogle af de spørgsmål, der er blevet stillet i udviklingsafdelingen.
"Vi har også haft en teknoantropolog ude hos kunderne for at undersøge, hvordan de bruger programmet," fortæller Bo Carlsson.
Det har blandt andet givet en erkendelse af, at programmet indeholdt alt for mange funktioner, og at brugerne derfor løb sur i hvilke funktioner, de skulle bruge.
Tre trin til bedre software
DRIVE-programmet har eksisteret siden 2009, men i det sidste års tid er der blevet set på koden fra nye vinkler.
Der er blevet foretaget brugertest baseret på opgaveløsning, programmets database og logfiler er blevet støvsuget for informationer om, hvordan programmet rent faktisk bliver brugt.
Og så har firmaet som nævnt haft en teknologi-antropolog været ude og følge brugerne i felten.
"Antropologens konklusion var blandt andet, at brugerne syntes, det var svært at bruge programmet, og at det gav en fornemmelse af at være 'lavet af ingeniører til ingeniører' og ikke til driftsfolk," siger Bo Carlsson og fortsætter:
"Der har ikke været tradition for bruger-feedback i enterprise-software. I dette segment har man ikke rettet på software-programmet, i stedet har man sendt brugerne på kursus."
Enterprise-softwaren har traditionelt stået i kontrast til de programmer, medarbejderen kender fra sin private telefon og pc, hvor det er afgørende at fange interessen med det samme."
Filosofien er, at det skal være lige så nemt at komme i gang med DRIVE som at spille Farmville - for det dur ikke kun at kigge på chefens behov, når det er medarbejderen, der skal bruge softwaren.
"Software skal være så nem at anvende, at der ikke er behov for en manual."
Byg, mål, lær
Ved at analysere databaserne i DRIVE kan udviklingsfolkene få en oversigt over hvilke funktioner, der bliver brugt.
"Hvis der ikke er data fra et felt i programmet, så bliver det ikke benyttet. Det betyder i grove træk, at det kan slettes, eller at brugernes vej til feltet skal gøres lettere."
Niras har ligeledes koblet et analyse-lag på programmet, så udviklerne kan samle informationer om, hvordan programmet bruges i praksis.
Det gør man ud fra en tese om, at software-udvikling handler om hele tiden at tilpasse programmet.
I praksis sendes en 'rå' udgave ud. Herefter måles på resultaterne, og programmet tilpasses. Ved at gentage denne proces bliver kanterne hele tiden slebet til.
"På den måde reducerer vi kompleksiteten gradvist ved eksempelvis at barbere de felter, der ikke anvendes, væk. Eller ved at fremhæve det næste, logiske skridt i arbejdsflowet. På den måde bruger vi logfilerne aktivt i udviklingsarbejdet. Det er en live-test hver dag."
Brugerne gjorde ikke som vi forventede
Udviklingsfolkene har også hevet brugerne ind til konkrete opgaveløsninger.
"Vi stillede en række specifikke opgaver, og vi havde en forventning til, hvordan de ville gribe opgaverne an."
Gjorde brugerne som I forventede?
Nej, det gjorde de ikke. Derfor brugte vi også resultaterne fra testen til at rette programmets funktioner til, så de passede til de praktiske arbejdsgange."
En konkret funktion, der blev rettet til, var adressefelterne, som tidligere var opdelt i en hel stribe tekstbokse med vejnavn, nummer, sal og så videre.
Det viste sig at være lettere med et enkelt felt til de oplysninger.
"Man kan sagtens stille lidt større krav til brugerne, der jo er tænkende væsner, og ikke bare 'kvæg', der skal klikke i en masse felter med en enkelt information."
Udviklerne har ikke ændret radikalt på den bagvedliggende programstruktur, men har ændret meget på brugerfladen.
"Så må vi i stedet hente de nødvendige informationer til eksempelvis statistik på en ny måde," siger Bo Carlsson.
Er flere brugere begyndt at benytte programmet, efter I har ændret arbejdsgange i udviklerafdelingen?
"Ja, det er der. Der er højere login-rate til programmet og gennemsnitstiden, som programmet anvendes i, er også blevet højere. Men vi er stadig i udviklingsfasen med den nye version. Nu lægger vi kræfterne helt ude ved driftsfolkene, og det håber vi naturligvis giver pote med hensyn til, at programmet vil blive brugt bedre og mere," siger Bo Carlsson.
Selve udviklingen af den nyeste version af DRIVE er i fuld gang med forventet release i første kvartal 2015.
Læs også:
Derfor er agil software-udvikling meget mere end løbende afleveringer
Styrelse dropper kravspecikationer: Satser på agil udvikling
