Want create site? Find Free WordPress Themes and plugins.

5 fælder I let kan undgå som offentlig virksomhed, når I skal have ny hjemmeside

Af Adam Osbirk Moe, Capgemini Sogeti

For nylig blev jeg spurgt, hvilke fejl offentlige virksomheder oftest begår, når de skal udvikle websites. Det er naturligvis subjektivt, men her har du en uofficiel top-5 over fælder, jeg har set igen og igen gennem mange år. Er der gode nyheder? Ja, de er nemmere at undgå, end man måske skulle tro. Læs selv!

I uprioriteret rækkefølge:

1. End-to-end systemer uden et MVP perspektiv

Mange projekter starter naturligt nok med en vision eller en udfordring, der skal løses. Men hvis du blot springer ud i at skrive en detaljeret kravspecifikation efter vandfaldsmodellen, går du glip af at lære i løbet af processen. I forhold til en proces hvor du bygger løsninger af mange mindre dele, der kan fungere hver for sig.

Hvis I arbejder med små entiteter og små pilotprojekter, kan I 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 I lave agile projektforløb og sige: ”Nu starter vi med at løse opgaverne i disse 3-4 user cases, og vi går efter at lancere et Minimal Viable Product (MVP) – altså i dette tilfælde en hjemmeside, som i første omgang kun kan det mest nødvendige.”

Med den tilgang kan I 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 I bruger Micro-services og en Service-orienteret arkitektur, kan selv store 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 store platforme, som findes i den offentlige sektor. Men jeg tror, at et MVP mindset vil få jer til at anerkende fejl som en lærende faktor, når I skal digitalisere nye områder. 😊

2. Kravspecifikationer der er for detaljerede

I dag baseres de fleste it-systemer på standard- eller rammesystemer, som bliver tilpasset kundens særlige forhold og ønsker. Jeg ser ofte, at en kravspecifikation ligger for tæt op ad et system fra en enkelt leverandør. Det betyder, at andre leverandører har svært ved at leve op til konkrete krav, selv om deres system måske reelt ville understøtte organisationens behov bedre. Det er naturligvis ok at blive inspireret. Men pas på at jeres grundighed ikke ender i at gøre jeres muligheder mindre.

Mange er så ivrige efter at få det hele med, at specifikationen bliver lang og kompleks. Og hvis ikke den færdige løsning lever op til forventningerne, er det oven i købet ens egen skyld, for man har jo forklaret hver en lille detalje. I stedet for specifikke krav anbefaler jeg, at I tager udgangspunkt i de arbejdsgange, der skal udføres. Og user cases kan ikke overvurderes.

User cases synliggør behovet uden at være for produktspecifikke. De kan forklare formålet med de krav, I stiller, og de er velegnede til at afstemme ønsker, når I vil have tilbud fra flere leverandører. Især når I kombinerer user cases med problembeskrivelser, har I et effektivt værktøj i hænderne.

3. Overdreven grundighed

Ironisk nok kommer mange fejl af kontraproduktiv perfektionisme. Man dækker sig ind, måske af frygt for at fejle. Hvorved man kommer til at overse, at det netop er gennem fejl, man opdager, hvad der virker. Idéen i prototyper og MVP’er er faktisk, at man fejler og i næste sprint justerer krav og løsning for at imødekomme det, man har lært, netop fordi man har lavet fejl.

Min erfaring er, at det er bedst, når kunde og leverandør skaber løsninger i tæt samarbejde, hvor begge parter tager ansvar for at teste ideer tidligt. Så man undervejs udvikler processer, eller den måde man har tænkt sig at løse opgaverne på. Jo før man kan lancere en prototype, jo bedre. For virkeligheden viser altid, at jo flere kræfter, der er lagt i en prototype, jo mindre villig er man til at lave den om. Vi skal simpelthen vænne os til at se på fejl, som det der forhindrer, at omkostningerne til udvikling bliver for store. ”Hvor mange fejl har vi opdaget i dag?”

4.  Man tror for meget på standard-løsninger

Lad det være sagt klart: Generelt er det sikrere at køre med standard-løsninger, end det er at udvikle løsninger fra bunden. For standard-systemer har jo i højere grad overstået deres børnesygdomme. Og det hjælper selvfølgelig også, hvis man har lavet sine user cases, udviklet MVP’er og prototyper, og i det hele taget ’spist elefanten i små bidder’.

Men standard-løsninger kan give falsk tryghed. For hvis man opvejer valget af en standard løsning ved at holde for stramt på at tilpasse systemet til sine eksisterende arbejdsgange, kan man efter projektet stå tilbage med en alt for kompleks kodebase, der er svær at vedligeholde og opdatere over tid.

Jeg har set mange eksempler på, at man i stedet for at benytte indbyggede features har fået bygget sine egne skræddersyet løsninger på standard systemet, som har gjort hele løsninger umulige at opdatere. Så virksomhederne stod med, det vi kalder for, teknisk gæld. Det er klassisk og desværre mere almindeligt, end man måske skulle tro.

5. Krav som ingen rigtigt har stillet …

Hvis man ikke får afstemt de forretningsmæssige målsætninger med de specificerede krav, kan man ende med de krav, der ikke er funderet i de forretningsmæssige målsætninger, også kaldet herreløse krav. Mange kravspecifikationer siger for eksempel, at der skal sendes en PDF-kvittering, når en borger har gennemført en proces. Men hvis den egentlige forretningsmæssige målsætning er at digitalisere salgsprocessen, hvad skal man så med en pdf?

Nu skal leverandøren indarbejde en PDF-generator i løsningen for at leve op til kravet. Den skal testes i forskellige mail-klienter, en driftsdokumentation skal udarbejdes. Ja, måske skal der endda betales licens for pdf-generatoren, hvilket der skal laves en særskilt plan for. Så man ikke glemmer det, og systemet gør opmærksom på en uheldig incident. Sådan er det jo med it – systemerne gør, hvad vi sætter dem op til.

Men i et MVP mindset, kan du måske i fællesskab med jeres samarbejdspartner fjerne de krav, der ikke kan mappes til de forretningsmæssige målsætninger, og dermed kun arbejde med det, der giver værdi for løsningens mål.

 

 

Did you find apk for android? You can find new Free Android Games and apps.