Amanda, Polsag, Proask, [indsæt selv]...

Hej Max ... jo, MEGET tankevækkende. Kunne man f.eks. køre en normal udbudsproces, gøre som du beskriver ovenfor og efterfølgende lukke det store udbudsproces når der ikke længere er brug for det :-))

Jeg tror jeg ville angribe det anderledes hvis det var mig der sad og skulle have udviklet et eller andet system.

Hvis man skærer alt fedtet væk og kommer ind til kernen er næsten alle offentlige systemer (og langt de fleste private) journaliseringssystemer. Input af data, visning af data, samt en eller anden form for samkøring og kommunikation med eksterne systemer. Det er ikke rocket science. Det er faktisk relativt enkelt. (selvfølgelig med nogle undtagelser)

Som jeg ser det er der tre problemer med den måde store offentlige systemer bliver lavet på:

1. Kunden. Dem der bestiller systemet aner ikke hvad de egentlig vil have, og aner ofte ikke noget om hvordan man udvikler IT systemer. Det er dem der skriver kravsspecifikationen der derfor bliver uforholdsmæssigt lang og kompliceret, ofte med modsatrettede krav, og ofte med fatale undladelser som der ikke lige var nogen der tænkte på.

2. Udbudssystemet. Den måde udbudssystemet fungerer på idag er grundlæggende (som jeg forstår det) at man skriver kravsspecifikationen, sender den i udbud og er tvunget til at vælge dem der på papiret bedst kan løse den beskrevne opgave. Du må ikke under udbudsprocessen kommunikere med nogen af dem der byder. Det er måske den mest elendige måde overhovedet at lave software på, specielt jvf. punkt 1 der fastslår at kunden ikke ved hvad han vil have, og/eller hvad der kan lade sig gøre. Prøv at forestille dig at du skal indrette dit hus og skal specificere præcis hvilken farve væggene skal have, hvor sofaen skal stå, hvilke skabe gryderne skal stå i, hvilke blomster der skal være på verandaen, og hvilket rum kattebakken skal placeres i. Hvorefter du giver opgaven til en gut du aldrig har snakket med, og beder ham om at indrette huset efter den manual du har skrevet i 4 ringbind. Det er en helt håbløs måde at indrette hus på - og en lige så tåbelig måde at lave software på. Der er ikke nogen der ved om Petunier eller roser ser bedst ud på verandaen før de har set det. Ofte ændrer man og ombestemmer sig undervejs. Nogen gange kan sofaen ikke komme ind ad døren, eller katten nægter at pisse i kattebakken med mindre den står under trappen. Du har ikke en chance for at definere det hele på forhånd, dels fordi der altid er ukendte faktorer, dels fordi du får gode ideer undervejs, og dels fordi det er komplet umuligt at først specificere alt, og derefter implementere det.

3. Politik. Dem der udtænker systemerne og skriver kravsspecifikationerne er som oftest ikke dem der skal bruge det endelige system, og ofte har de en politisk og/eller økonomisk agenda. Jeg vil godt vædde på at i mange af de omtalte skandalesystemer er den endelige slutbruger aldrig blevet spurgt.

På den baggrund ville jeg gøre følgende:

1. Definer hvilke eksterne datakilder der er brug for at læse/skrive fra.
2. For hver af disse find et lille firma der for et rimeligt beløb (der ligger under grænsen for EU udbud) kan skrive et API der kan kommunikere med datakilden i et let forståeligt format, f.eks. JSON.
3. Få et lille web design firma med nogle gode UX folk til at lave et webbaseret mock-up af systemet baseret på samtaler med dem der skal bruge det til daglig. Det behøver ikke at være perfekt. Brug dummy-data.
4. Vis din mock-up til brugerne. Bliv forbavset over hvor meget indsigt de rent faktisk har i forhold til dyrt betalte software arkitekter fordi de sidder med det hver dag. Skriv ned hvad de har af forslag og kritik.
5. Iterer over 3. og 4. indtil brugerne af systemet synes det ser fornuftigt ud.
6. Du har nu en HTML mockup der fungerer som en strålende kravsspecifikation. Definer en række funktionaliteter på baggrund af denne. F.eks: "hent "foo" data fra "bar" API'et, præsenter det for brugeren i dummyen, og giv ham adgang til at gemme data gennem "bar" API'et hvis han har de rette credentials."
7. Sæt et lille firma til at implementere et par funktioner i mock-uppen. Sørg for at tilbuddet fra det lille firma ligger under EU udbudsgrænsen...
8. Vis det til brugerne og sppørg dem om det er OK. Hvis ikke ret det til.
9. Iterer over 6. 7. 0g 8. indtil du har et brugbart system.
10. Launch det på en linux box i et fornuftigt datacenter der står i Danmark.

Der er mange fordele ved at gøre det på denne måde, b.la.

1. Det er OK at kunden ikke helt ved hvad han vil have. Det kan man finde ud af efterhånden som man bygger mock-uppen.
2. Du ved altid hvor du står, og om projektet er forsinket fordi der er tale om let overskuelige delopgaver.
3. Hvis der er en leverandør der ikke kan levere kan du fyre ham og finde en anden, eftersom der er tale om små enkeltstående leverancer.
4. Du ender med et system som brugerne næsten med garanti vil være glade for, eftersom det er dem der har defineret kravene.
5. Du ender med et system der er funktionsopdelt i små enheder, hvilket gør det lettere at opdatere/rette til.
6. Du støtter små Danske virksomheder :-)

Jeg er ikke ekspert i EU udbud og jura, så det er muligt at der er huller i min model der gør at det ikke kan lade sig gøre. I bekræftende fald vil jeg super gerne høre hvad.

Og ja, jeg har gjort brug af ovenstående model, og det fungerer. Jeg har gået og tænkt over at det kunne være interessant at prøve af med en offentlig myndighed. Hvis der er nogen der har nogle gode ideer eller leads til hvem der kunne være interesseret i at prøve noget nyt vil jeg meget gerne høre det (og/eller hvis der er nogen der er interesseret i en eller anden slags samarbejde) Det kunne være rigtigt sjovt at vise nogen af mastodonterne hvor dyre og dårlige deres løsninger egentlig er.

Beklager at det blev en utrolig lang kommentar...

Jeg har skrevet noget om HTML prototyping her: http://www.maximise.dk/html-prototyping/