NYHED
DCX

5 fælder offentlige organisationer skal undgå, når de udvikler websites

Nogle faldgruber frister tilsyneladende offentlige virksomheder mere end andre. Kan du gætte hvilke det er? Læs om dem her, hvor du også får råd om, hvad I kan gøre for at undgå dem. Så I kommer i mål med den bedst mulige hjemmeside uden dyre fejltagelser.

Af Adam Osbirk Moe, Capgemini Sogeti

Indrømmet: Meget KAN gå galt, når man udvikler websites, selv om alle involverede faktisk gør et godt job. Det er som bekendt essensen af Murphy’s berømte lov. Tid og budget kan skride, der kan være bugs, krav kan blive ændret undervejs, så websitet til sidst ikke kan det, som var meningen. For nu blot at nævne et par eksempler, som enhver, der arbejder med it, har prøvet på egen krop.

Men når der nu er så mange fejl at vælge imellem, er der jo ingen grund til at begå de samme igen og igen. Derfor kan du her læse om 5 fælder, som jeg på uvidenskabeligt grundlag har bemærket, ofte er i spil, når offentlige virksomheder skal udvikle websites. God fornøjelse! 

1) For detaljerede kravspecifikationer

De fleste it-systemer, der leveres i dag, er baseret på standard- eller rammesystemer, som bliver tilpasset kundens særlige forhold og ønsker. En klassisk fælde er, at en kravspecifikation ligger for tæt op ad en enkelt leverandørs system. Det betyder ofte, at andre leverandører har svært ved at leve op til de præciserede krav, selv om deres system måske overordnet set ville understøtte organisationens arbejdsprocesser og ønsker bedre. Det er naturligvis ok, at blive inspireret. Men pas på at inspiration ikke ender i indsnævring af mulighederne.

Mange er så ivrige efter at få det hele med, at de er for detaljerede i deres krav. Specifikationen bliver lang og kompleks, og hvis ikke den færdige løsning lever op til forventningerne, står man endda selv med hele ansvaret. Man har jo forklaret alt i mindste detalje. I stedet for specifikke krav anbefaler jeg, at man tager udgangspunkt i de arbejdsgange, der skal udføres. For eksempel user cases, som findes i forskellige varianter.

User cases er gode af flere grunde. De er på den ene side præcise beskrivelser af behovet, og på den anden side ikke for produktspecifikke. De kan bruges til at forklare formålet med traditionelle produktkrav, og de er velegnede til at afstemme ønsker, når man vil have tilbud fra forskellige leverandører. Især hvis du kombinerer user cases med problembeskrivelser, får du et stærkt og brugbart værktøj.

2) End-to-end systemer uden et MVP perspektiv

Mange projekter starter med en vision eller et problem, der skal løses. Men hvis man herefter skriver en detaljeret kravspecifikation efter vandfaldsmodellen, går man glip af at lære i løbet af processen, hvor man bygger løsninger af mange mindre dele, der kan fungere hver for sig.

Med små entiteter og små pilotprojekter kunne man i stedet løbende få erfaringer med det, der er kerne-problemet eller hovedformålet med sitet. Så i stedet for en komplet end-to-end tilgang kan man lave agile projektforløb og sige: ”OK, nu sigter vi præcist mod det problem, der er beskrevet i disse 5-8 user cases, og vi går efter at launche et Minimal Viable Product(MVP).”

Med den tilgang kan man lave en smal vertikal løsning fra frontend over rammeværket til integrationen og så i efterfølgende iterationer bygge løsningen ud horisontalt. Som vist her:

Hvis det er tænkt ind i løsnings-designet fra starten, og man arbejder med Microservices og en Service-orienteret arkitektur, kan store, komplekse, offentlige it-løsninger stykkes sammen af flere MVP’er. Et for hvert kerne-flow. Jeg vil naturligvis ikke påstå, at jeg kan løse alle de problemer, der findes i udviklingen af Inddrivelsessystemer, Polsag, Sundhedsplatformen mm. med et fingerknips. Men jeg tror, at et MVP mindset vil gøre, at vi anderkender fejl som en lærende faktor, når vi skal digitalisere nye områder.

3) Herreløse krav

Hvis man ikke får afstemt de forretningsmæssige målsætninger med de specificerede krav, kan man ende med de såkaldte herreløse krav. Et eksempel: Mange kravspecifikationer indeholder et krav om, at der skal sendes en kvittering som pdf, når en ordre er lagt. Men hvis den egentlige forretningsmæssige målsætning er at digitalisere salgsprocessen, hvad skal man så med en pdf?

Det tvinger bare leverandøren til at indarbejde en pdf-generator i løsningen for at kunne leve op til kravet. Området skal testes i forskellige mail-klienter, og der skal laves en driftsdokumentation for, hvordan pdf-generatoren virker. Hvis der er licens til pdf-generatoren, skal der laves en plan for at huske at betale den, så man ikke pludselig opdager, at pdf’er mangler, og at det vil blive betragtet, som en incident. Så meget postyr for et krav, som ikke giver digital mening, Fjollet ikke?

4) Frygten for fejl

Mange af de mest almindelige fejl er altså næsten biprodukter af at gøre sit job for grundigt. Man dækker sig ind og kvæler barnet i perfektionisme eller frygten for at fejle. Idét man overser, at det netop er gennem fejl, man opdager, hvad der virker. Mindsettet omkring prototyper og MVP er faktisk, at man fejler og i næste sprint justerer krav og løsning til at imødekomme det, man har opdaget, fordi man har lavet fejl.

Derfor er det vigtigt at skabe løsninger i tæt samarbejde mellem kunde og leverandør, hvor begge parter tager ansvar for at teste ideer af tidligt, så man opdager, om der er fejl i krav, processer eller den måde man har tænkt sig at løse opgaven på. Jo før man kan lauche protyper, jo bedre. For jo flere kræfter, der er lagt i en prototype, jo mindre er man tilbøjelig til at lave den om. Kast et blik på denne figur over omkostninger forbundet med at rette fejl. Og stil dig selv spørgsmålet: er det ikke fantastisk, hvis vi kan opdage en masse fejl, inden omkostningerne bliver for store? 

5) Standard-løsningernes falske tryghed

Det er generelt sikrere at benytte standard-løsninger, end det er at skræddersy sine løsninger. For ”hvis det virker for 10.000 andre organisationer, virker det nok også for os”. Og det gør det sikkert også, hvis man vel at mærke har lavet user cases, der beskriver arbejdsgange på et forretningsplan, arbejdet med MVP og udviklet prototyper, og hvis man har ”spist elefanten i små bidder” – altså lavet arkitektur principper, der tillader at løsningen består af mange uafhængige løsninger.

Så sejler man i smult vande. Men ellers kan standard-løsninger give falsk tryghed. For hvis man ikke er villig til at ændre sine forretningsgange, så de matcher med stanard-systemet, kan man ende med unødig kompleksitet og en kodebase, der er svær at vedligeholde og opdatere over tid.

Jeg var for nylig ude hos en e-commerce kunde, der havde fået bygget en løsning til mange forskellige forretningsenheder. Men i stedet for at benytte den indbyggede feature til krydspublicering, så havde de fået bygget deres egen krydspublicerings feature, som bare gjorde hele løsningen umulig at opdatere. Så de nu var endt med teknisk gæld. Det var et klassisk eksempel, og desværre langt mere almindeligt, end man måske skulle tro.

Men den største fejl man kan gøre, er som bekendt ikke at gøre noget. Så se at komme i gang. Pas på disse faldgruber og lad dig først og fremmest styre af din sunde fornuft og dit gode humør. Så skal det nok gå.

todo todo
Kontakt
  • Adam Osbirk Moe
    Adam Osbirk Moe
    Web & Portal Lead
    +45 52189557