Dette indlæg er alene udtryk for skribentens egen holdning.

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

8. maj 2014 kl. 16:3013
Artiklen er ældre end 30 dage
Manglende links i teksten kan sandsynligvis findes i bunden af artiklen.

Nogle mener at det offentlige er for dårlige til at bestille it-projekter.
Andre mener, at leverandørerne ikke er dygtige nok.
Den sande historie er selvfølgelig begge dele, og så hører det også med, at det private ganske enkelt er bedre til skjule, når det går galt.

Fortæl "din værste historie"

Der følger tit en selskabsleg med, når jeg holder workshops om agil udvikling. Den hedder "Fortæl din værste historie".
Det er en meget simpel øvelse. Man stiller sig i en rundkreds, og hver deltager har 90 sekunder til at fortælle den mest tåbelige historie fra et udviklingsprojekt.
Gennem årene har jeg hørt mange historier om dårlig projektledelse, forkerte måder at købe ind på, rumraketten til fast pris og chefer, der skulle bestemme det hele. Også det, de ikke vidste noget om.
En enkelt historie har bidt sig fast. Den vinder.

Afregningssystemet

Forestil dig et system, der skal afregne forbrugsafgifter for danske forbrugere. Med rigtig mange nuller bag, når vi taler om den samlede, årlige fakturering.
Ingen nævnt, ingen glemt. Jeg nævner hverken branche, type, platform, leverandør eller noget andet. Men et stort system.
Systemet er udviklet for mange år siden. Af én person. Og siden videreudviklet af mange, men med opfinderen som arkitekt og idémand.
Organisationen udvides, alt vokser, og der skal reorganiseres. Hvem skal så være hans chef?

Det er tosset

Nogle gange overgår sandheden fantasien. Nej, ledelsen kan ikke blive enige om, hvem der skal være hans chef. Så man fyrer ham.

Artiklen fortsætter efter annoncen

(Pause)

Siden bruger et team af udviklere flere år på at finde ud af, hvordan systemet hænger sammen. Fakturaer, der udsendes, er ikke nødvendigvis korrekte. Man ved, at systemet ikke kan regne. Og man holder det hemmeligt.

Store systemer = store fejl

Vi har ikke set det sidste "Amanda", "Polsag", "Proask" fordi mange har en drøm om at købe/levere/designe "det store system". Bigger is better. Og kombinationen af store systemer og menneskelig idoti er en giftig cocktail. Derfor.

Ordet er frit. Fortæl "din værste historie" her på siden, eller i din udviklingsafdeling. Det er sundt nok.

13 kommentarer.  Hop til debatten
Denne artikel er gratis...

...men det er dyrt at lave god journalistik. Derfor beder vi dig overveje at tegne abonnement på Version2.

Digitaliseringen buldrer derudaf, og it-folkene tegner fremtidens Danmark. Derfor er det vigtigere end nogensinde med et kvalificeret bud på, hvordan it bedst kan være med til at udvikle det danske samfund og erhvervsliv.

Og der har aldrig været mere akut brug for en kritisk vagthund, der råber op, når der tages forkerte it-beslutninger.

Den rolle har Version2 indtaget siden 2006 - og det bliver vi ved med.

Debatten
Log ind eller opret en bruger for at deltage i debatten.
settingsDebatindstillinger
4
9. maj 2014 kl. 13:08

Her er en interessant en.

Jeg vil prøve at holde det i nogenlunde generelle termer for at beskytte de uskyldige (og skyldige...)

Historien omhandler et stort offentligt system som du har hørt om.

Dette offentlig system var som så mange andre blevet forsinket ganske meget. Dette var et rent praktisk problem for dem der skulle bruge det nye system fordi licenserne på det gamle system som det skulle erstatte var ved at løbe ud og var gevaldigt dyre at forny. Derfor blev et mindre konsulenthus kontaktet for at høre om de ikke kunne lave et system man kunne bruge indtil det nye blev færdigt.

En svinedygtig programmør jeg har arbejdet sammen med (og hørt historien fra) blev ansat som underleverandør for at bygge det. Fremgandsmåden var følgende:

  1. Byg API'er til at hente og sende data til og fra de relevante databaser systemet skulle snakke med.
  2. Snak med brugerne om hvad de skal bruge.
  3. Byg systemet
  4. Deploy det på en generisk linux box med webbaseret (krypteret) adgang.
  5. Ret småfejl, snak med brugere, iterer et par gange.
  6. Launch

På den måde lykkedes det ham ene mand at bygge et system som slutbrugerne var tilfredse med, som var relativt sikkert, og som blev lavet på ca. 4 måneder for langt under end 1% af hvad det endelige system kom til at koste. Ifølge brugerne var hans system både hurtigere og interfacemæssigt bedre end det endelige system der blev deployet senere.

Han havde den enorme fordel at han ikke var tynget ned af udbudsregler, Djøffere, mellemledere, politik, lokumsaftaler og inkompetence.

Tankevækkende ikke?

5
9. maj 2014 kl. 19:11

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 :-))

7
9. maj 2014 kl. 22:54

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: https://www.maximise.dk/html-prototyping/

13
11. maj 2014 kl. 10:49

Løsningen er vel at ankalge den pågældende for både injurier samt korruption og hive pågældende gennem diverse retsinstanser. Dog er det ærgeligt at det ikke er muligt at trække samtlige EU politikkere gennem retsystemet med en korruptionsanklege, for det er vel egentlig det de fleste i forvejen er skyldige i.

9
10. maj 2014 kl. 11:27

Du må ikke dele et projekt op i bidder for at holde dig under grænsen, så hvis du har et større mål end den enkelte del (som en lille leverandør kunne løfte) giver dig af værdi så bryder du reglerne. Du må gerne kommunikere med dem som byder mens de laver deres løsningsbesvarelse. Det skal blot tilgå alle leverandører på samme tid. Du vil typisk også tillade at de stiller spørgsmål igennem et udbudssystem og give svar til alle leverandører herigennem.

12
10. maj 2014 kl. 21:22

«Du kan godt dele et projekt op i bidder, men hvis det samlede projekt forventes at gå over grænsen, så skal du gå i udbud»... Hvad jeg forsøgte at skrive...

8
10. maj 2014 kl. 09:38

Jeg synes måske ikke, at løsningen er, at prøve noget nyt. I 'gamle dage' havde man en udviklingsafdeling, der kendte forretningen. Resultatet var, at de krav, forretningen stillede, blev forstået af udviklerne. Derfor havnede man ikke i disse katastrofer. En del større firmaer - f.eks. de større banker og sikkert også Nets - har bibeholdt deres egne udviklere, som kender forretningen. Jeg mener i bund og grund, at problemet er:

  • Kunden er ikke god nok til at beskrive sine krav
  • Udviklerne har intet forhold til forretningen
  • Ergo: kunden får ikke det, man forventer
3
9. maj 2014 kl. 11:35

Fra midt90'erne og indtil 2001 deltog jeg som brugerrepræsentant i udviklingsarbejdet med AMANDA. Systemet kostede over en ½ milliard, det skulle være udviklet på et par år og koste det halve, og var næsten ubrugeligt da det blev implemneteret. Jeg og andre "fornuftige" brugerrepræsentanter forsøgt i årevis at forklare projektlederne hos det store amerikanske IT-firma CSC og de ansvarlige fra arbejdsmarkedsstyrelsen, at mange af funktionerne var alt for ringe. I stedet for at tage vores advarsler alvorligt, kørte man systemet i stilling uden hensyntagen til den manglende brugervenlighed, ja en styrelseschef tillod sig endda at kalde undertegnede og andre for nogle "redepissere", fordi vi havde formastet os til at gøre opmærksom på de graverende svagheder ved systemet. Ja, uduelige eller uvidende chefer hader kritik. Resultatet er velkendt, AMANDA er til dato danmarks største IT-skandale. Det bare for at understrege, at man aldrig skal sætte chefer og systemfolk/programmører til at bestemme hvordan brugersystemer skal skrues sammen, det bliver dyrt og af ringe kvalitet.

1
8. maj 2014 kl. 17:01

Det går jo også grueligt galt når det offentlige overlader offentlige opgaver til private, Tænk bare NETS, RKI... At udlicitere til private giver blot et ekstra risikomoment. At udlicitere til udenlandske private giver 2 ekstra risicimomenter.

2
9. maj 2014 kl. 09:37

RKI

??? - hvordan er RKI blevet en offentlig opgave? Det er et privat register over dårlige betalere, som private virksomheder bruger til at undgå at tabe penge.