Systemudvikler om rejsekort: Enhver projektleder ville løbe skrigende væk

Kig lige en ekstra gang på illustrationen til denne artikel. Den er hevet ud af en rapport om rejsekort-projektet, som it-konsulentfirmaet Gartner skrev for Transportministeriet for to år siden, og som Ingeniøren for nylig har fået aktindsigt i.

Illustrationen er it-konsulenternes forsøg på at forklare, hvem der har ansvaret for hvad under udviklingen af de elektroniske bus- og togbilletter. Skemaet er fyldt med så mange punkter, at det fremstår, som om alle har ansvar for alting.

Gartner formulerer det i rapporten sådan:

'Der er ikke et entydigt billede af, hvem der træffer hvilke beslutninger om hvad. Opfattelsen er derfor, at de fleste interessenter har mulighed for at beslutte på tværs af it-domænerne.'

Læs også: Her er rejsekort-rapporten, som ministerium forsøgte at skjule

Det vil den selvstændige systemkonsulent og Ingeniøren-blogger Poul-Henning Kamp gerne skærpe. Han faldt straks over skemaet, da Ingeniøren bad ham læse Gartner-rapporten igennem, fordi han i mange år har fulgt rejsekort-projektet.

»Det er fuldstændig håbløst at prøve at udvikle et it-system under de vilkår. Det går amok i det system, hvor alle har fingrene i alting, og udviklerne skal hele raden rundt for at spørge om lov til at ændre noget,« siger han.

»Hvis du viser det her til en hvilken som helst kandidat til et job som projektleder, så løber vedkommende skrigende væk,« tilføjer Poul-Henning Kamp.

Læs også: Rejsekort fik lov at droppe formålet om enklere priser

Han håber, at skemaet kan gradbøjes, så udviklerne har lov til at rette en fejl uden at spørge. Men i det hele taget tror han slet ikke på, at skemaet afspejler virkeligheden, som efter hans vurdering snarere er, at alle gør, som de selv tror er bedst.

»Ét er, hvad man gør, noget andet er, hvad man siger, og noget tredje, hvad man har lovet,« som Poul-Henning Kamp udtrykker det.

Derfor mener han, at Henning Christophersen, bestyrelsesformand for Metroselskabet, rammer rigtigt, når han - uden held - har forsøgt at få erfarne projektledere ind i bestyrelsen i stedet for direktørerne for de danske bus- og togselskaber.

»Det er noget af det mest fornuftige, der står i det materiale, I har fået aktindsigt i,« lyder det fra Poul-Henning Kamp.

sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først

1 ansvarlig har 100 % ansvar. 2 ansvarlige har 45 % ansvar hver. 3 ansvarlige har 25 % ansvar hver. 4 ansvarlige har 15 % ansvar hver. 5 ansvarlige har 10 % ansvar hver.

Og så fremdeles?

  • 0
  • 0

1 ansvarlig har 100 % ansvar. 2 ansvarlige har 45 % ansvar hver. 3 ansvarlige har 25 % ansvar hver. 4 ansvarlige har 15 % ansvar hver. 5 ansvarlige har 10 % ansvar hver.

Og så fremdeles?

Jeg bruger flg. formel: Ansvaret deles med antallet af ansvarlige, og resultatet multipliceres. 2 ansvarlige har således 50%x50%= 25% ansvarlighed og 75% uansvarlighed. Altså 1/n opløftet i n'te potens. Et projekt med 5 ansvarlige har da 1/3 promille ansvarlighed i alt.

  • 1
  • 0

Tjah, eller 1 ansvarlig har 100% ansvar, 2 har 100% ansvar hver, og 200% ialt, og så fremdeles. Desto flere der er, desto mindre er risikoen for fejl. Det, som er kunsten, er at opnå strukturer og fordelinger, der netop virker "fejlkorrigerende", således at risikoen mindskes betragteligt, ved at have flere ansvarlige.

At skulle spørge, før der rettes fejl, er en god idé. Langt de fleste fejl rettes forkert - fordi dem der retter er inkompetente, ikke selv har skrevet koden, ikke fatter hvad der foregår, og "tror" at det andre, som ved hvad de laver, er forkert. Sandsynlighed for, at fejlrettelser sker til den forkerte side, er 90 - 98%. Og den bliver ikke bedre af, at netop dem, der elsker at rette de andres fejl, er dem der råber højt, og kan mindst. Derfor, er en god idé, at alle fejlretninger - der ikke er i ens egen kode - går igennem adskillige andre først, der analyserer det, og at man i fællesskab erkender, at det faktisk er fejl. Det er også godt, hvis den oprindelige programmør er inde over det - selvom den sædvanlige strategi er, at fyre disse, før de kan få lov, at begrunde det de har lavet. Men normalt, er det dem, der oprindeligt laver koden, der har tænkt mest over den, og kender bedst til de problemer, der er taget højde for, og såvel årsag, som fejlmulighederne. Dem der kommer herefter, læser bare, og retter det de lige tror skal være på en anden måde, fordi det er lavet af de andre, der er bare er "dumme".

Hvis vi kunne komme fejlretninger til livs, vil meget kode fungere.

  • 0
  • 0

Helt rigtigt. En af mine første erfaringer som helt ung ingeniør gik netop på dette. Der lød ikke godt. En underlig kvalt lyd fra røgventilatoren efterfulgt af et hårdt smæld, hvorefter processen gentog sig. En fejl, nemlig at røgventilatorens reguleringsspjæld ikke modulerede efter belastningen, var forsøgt rettet ved af sætte en kontakt til tvangslukning. Mirakuløst overlevede anlægget. Det samme gjorde både min kollega og jeg. Men den ufuldstændige forbrænding der var et resultat af fejlen, kunne have udløst en eksplosion af røggassen

  • 0
  • 0

1 ansvarlig har 100 % ansvar. 2 ansvarlige har 45 % ansvar hver. 3 ansvarlige har 25 % ansvar hver. 4 ansvarlige har 15 % ansvar hver. 5 ansvarlige har 10 % ansvar hver.

Og så fremdeles?

Normalt er det sådan at hvis to skal dele et ansvar bliver der 10 % til hver.

  • 0
  • 0

Når der inden for nær fremtid skrottes, vil det være nærmest umuligt at placere et ansvar, så ingen kommer ned med nakken af den grund.

Men er ansvarsplacering relevant?

Det, som er væsentligt, er hvor fejlen er placeret. Ikke hvor ansvaret er placeret. Fejlen skal rettes. Ansvaret skal tages.

Når det går helt galt, går man den modsatte vej. Fejlen tager ansvaret. Og ansvaret rettes, ved at f.eks. personen fjernes.

Det, som er væsentligt, er metoder, til at sikre at resultatet er fejlfrit. Og, nogle tager ansvar for, at have metoderne til det, og kunne sikre det. Det, at nogen tager ansvaret, betyder også, at de har metoderne til, at sikre at der ikke går noget galt i den sidste ende. En person, der har et ansvar, har ofte en plan B. De sørger for, at der er nogen, som tjekker tingene. Og de har metoder, hvor måske flere personer, sættes på samme opgave, hvis de vurdere, at opgaven giver problemer, eller kræver flere forskellige løsninger, der kan vurderes. Som regel, er ansvar opdelt i et hiraki, så en person, der tager ansvar, gør det ved at have andre, der tager ansvar, indenfor hver sit speciale, hvor de har særlig kunnen, der gør at de kan sikre, at tingene som de sættes til at have ansvaret for, vil fungere. Hvis de løser denne opgave, så er det i orden. Måske, vurderer dem, der har et overordnet ansvar, at dette ansvar, hellerikke kan klares af en enkelt person alene, og der kan godt være flere, til at tage ansvar for samme område.

  • 0
  • 0

[quote]1 ansvarlig har 100 % ansvar.

2 ansvarlige har 45 % ansvar hver.

3 ansvarlige har 25 % ansvar hver.

4 ansvarlige har 15 % ansvar hver.

5 ansvarlige har 10 % ansvar hver.

Og så fremdeles?

Normalt er det sådan at hvis to skal dele et ansvar bliver der 10 % til hver.[/quote] Ansvar skal ikke deles. Når flere, tager ansvar, så deler de ikke ansvaret. Så deles de om ansvaret. At deles om, betyder at alle har 100% ansvar. Men, hvis noget går galt, så går det trods alt trods det. Altså, det samlede ansvar, er over 100%. Og derfor, går et ikke galt, selvom det bliver 100% mindre, hvis en enkelt ansvarshavende ikke lever op til sit ansvar. Er ansvaret for stort, kan det uddeles. Så bliver ansvaret mindre, fordi ansvarsområdet indskrænkes, men er stadigt 100%, indenfor dette område.

Der skal altid være plads til, at noget går galt, og viser sig problemer, vil det kunne være nødvendigt, at dupplere funktioner, grupper, eller opgaver. Det kan være nødvendigt, at have personer i reserve. At have en plan b - som nødplan - hvis noget går galt. Plan B, kan måske være at købe noget færdigt, der er dyere, og koster mere end oprindeligt planlagt, eller det kan være at opnå mindre, end oprindeligt ønsket - dog indenfor det som accepteres. Normalt, vil sættes resourcer og økonomi af, til sikkerhed. Værste tilfælde, er naturligvis at alt går galt - og at man som ved IC4, måske skal ud at købe nye tog, hvis det var plan-b. I de fleste tilfælde, vil det være mindre delopgaver, der måske forsinkes, ikke lever helt op til specifikationerne og skal gøres om, eller der på anden måde, bliver nødvendigt med lidt ekstra resourcer, for at løse den pågældende opgave. Eller, måske er muligt, at betale sig fra den pågældende opgave, f.eks. ved at købe den i byen, eller på anden måde sikre, at problemet ikke medføre et problem for projektet.

  • 0
  • 0

Det minder meget om:

Patientjournalsystemet. IC4. Politisystemet. O.S.V.

Det offentlige er inkompetente, de laver kravspecifikationer der automatisk ikke kan ansvarsplaceres, hvis noget går galt.

  • 0
  • 0

Har nogen tal på, hvor mange skattekroner der vil være spildt, før systemet fungerer? Altså for hvor meget projektet kunne være gennemført, hvis der havde være kompetente personer i ledelsen?

  • 0
  • 0

Det minder også mig om DeMars, forsvarets IT system og SLS, statens lønsystem, som begge var under konstruktion, da jeg var medlem af FT. At få en IT kontrakt med staten, er som Jesper Dohrup skriver:

Hvis du viser den til et konsulentfirma vil det løbe efter projektet med alt hvad det har - det er gader af guld og honning i linde strømme. Meget stor faktureringsgrad, meget lille risiko, og fantastisk after-sales marked. Og du vil få ros for at være helhedsorienteret, kundeinddragende, velforberedt og moderne.

Inkompetance og kongedømmer, der for alt i verden skal bevares, er en af årsagerne. Skrækkeligt.

  • 1
  • 0

....Inkompetente menes der vel :o)

Hvordan finder man kompetente personer ? Vi afholder valg senest hver fjerde år, men trods af det er det åbenbart blevet sværere at finde nogen kompetente

Som jeg ser det, er det da yderst kompetente personer der har stået for rejsekortet, de står da ikke tilbage for vore politikere. Her gælder det bare at holde rø...(numsen) fri af gulvet og paraderne oppe, når man sender sit vederlagskrav, til helvede om produktet virker :o)

  • 0
  • 0

Ingen ? Der ryger trods alt ikke skattepenge (direkte) i systemet, så vidt jeg ved ? Til gengæld ryger der jo nok en ganske pæn regning videre til os, der har holdt fast i at rejse med den kollektive trafik.. Tror ikke det er manglen på kompetente personer i ledelsen, der er problemet, snarere blot, at der er alt for mange af dem - færre havde nok lettet arbejdet en del :=) ?

  • 0
  • 0

Det offentlige er inkompetente, de laver kravspecifikationer der automatisk ikke kan ansvarsplaceres, hvis noget går galt.

De har vel advokatvirksomheder, til at gøre det, på samme måde som private virksomheder.

Når det går galt hos det offentlige - så hører vi om det. Når det går galt, hos private virksomheder, så hører vi om aktiekursfald, at der er krise i erhvervslivet osv. Og søger du at ansvarsplacere krisen, så får du samme problem, som ved ansvarsplacering hos det offentlige. Forskellen er, at her er der ingen der har ansvaret, eller burde have ansvar. Det manglende ansvar, er derimod en "feature" ved det kapitalistiske system.

  • 0
  • 0

Det, jeg sådan set ville frem til, var kendsgerningen, at det kan lade sig gøre, at overholde både tidsplan og budgetter i projekter, hvor det offentlige er involveret. Ganske vist var Sønderborg-motorvejen et OPP-anlæg, men blev færdig før tiden og så vidt jeg husker, kom der ikke nogle ekstraregninger snigende. Sydbus søsatte et satelitstyret billet- og buspositioneringssystem, der blev otte eller ti år forsinket.

  • 0
  • 0

Når man starter på et projekt, så er chancen for succes størst, hvis:

  1. Man kan leve uden, hvis det "går i hegnet'"
  2. Man er klar over hvor meget det må koste (indkøb+drfit) uden at det bliver irrelevant
  3. Man forstår at det ikke giver hæder at undlade at kvæle et fejlslagent projekt.
  • 0
  • 0

Når man starter på et projekt, så er chancen for succes størst, hvis:

  1. Man udpeger en ansvarlig arkitekt, hvis opgave det er at få projektet i mål og hvis midler er tilstrækkelige til at opnå dette mål.

Den mest centrale fællesnævner for alle de offentlige IT skandaler jeg har haft fingrene i, er netop at der ikke er én person der har det arkitektoniske ansvar & overblik.

17000 krav i er i bedste fald 8 tykke ringbind og der er med garanti ingen person på køber-siden af rejsekortet der har kunnet de 8 tykke ringbind uden ad.

Derfor fejlede projektet.

  • 1
  • 0

17000 krav i er i bedste fald 8 tykke ringbind og der er med garanti ingen person på køber-siden af rejsekortet der har kunnet de 8 tykke ringbind uden ad.

Derfor fejlede projektet.

Kravene burde stå på 8 tykke stykker papir.

  • 1
  • 0

-1: Man starter med at lave en minimal del først og får succes med den, derefter den følgende minimale del, osv., så man bygger succes oven på succes, og de evt. fejltrin der måtte være i læringsprocessen (hvad er det vi skal have lavet og hvordan gør vi det bedst) er minimale.

Det er ikke en succes at producere tonsvis af krav. Det er en fiasko.

  • 0
  • 0

Med rejsekortets specifikationer, er det i højere grad en udviklingsopgave, end køb af et eksisterende produkt. Dem, der sælger eksisterende produkter er sælgere, og har et produkt de ønsker at sælge. Har kunden nogle særlige ønsker, så accepterer sælgere stort set alt, for at sælge deres produkt. Og de aner intet om, hvad de siger ja til. De får for, at få handlen igennem.

Ved en udviklingsopgave, er det oftest en bedre idé, at udvikle specifikationerne i samarbejde med udviklingsvirksomheden, som skal løse opgaven. Ofte, er en fordel, hvis virksomheden kender kundens behov - f.eks. vil en dansk udviklervirksomhed, der har ansat ingeniører, som bruger det offentlige system, være bedst. Forslagene, må gerne komme fra udviklervirksomheden til kunden - det viser, at udviklervirksomheden, har en entausiasme og arrangement i det, som de skal udvikle for kunden, og kan sætte sig ind i kundens problem. Eventuelt kan udviklervirksomheden tilbyde flere løsninger, og udarbejde flere løsningsforslag, som de mener løser kundens problem, og kunden kan vælge iblandt disse, og fortælle hvilke problemer de mener er med løsningerne, hvis de ikke er iorden.

Når først, at opgaven startes, skal specifikationerne helst være forstået, og godkendt, fra begge sider. Og udviklerne, har måske idéer, der er værd at tage med. Skal specifikationerne ændres - så skal de helst ændres af udviklerne, og godkendes af dem der udbyder projektet. Måske, har udviklerne opdaget komplikationer undervejs, der nødvendiggør en ændring i specifikationerne, som enten forbedrer produktet, eller gør, at noget vil være et stort problem, og må løses på en anden måde. Den modsatte vej, hvor udbyderen ændrer specifikationerne, giver problemer for udviklerne. De har brugt tid, og resourcer, på at leve op til de pågældende specifikationer, og pludseligt ændres de, og meget arbejde, skal måske gøres forfra. Måske, vil de nye specifikationer, kræve langt større beregningskraft, og kræve helt nyt hardware, eller at meget af softwaren ændres. På den anden side, så er udviklerne måske ikke startet på implementeringen, og så kan være nemt, at ændre på noget, hvis udviklerne syntes, at det er en god idé. Syntes udviklerne ikke om idéen, så er ofte en god idé at tage efter udviklerne, for de vil næppe kunne udvikle noget, med stor entausiasme, og gøre det godt, hvis de ikke går ind for løsningen eller projektet.

Afstanden fra frankrig til Danmark, tror jeg er stor. At få en kontakt igennem, med udviklerne, vil være udelukket. Kommunikationen bliver meget formel, skal foregå via papirer og advokater. Jeg vil have foretrækket en dansk, eller svensk udviklingsvirksomhed, for at opnå en kortere afstand, og bedre kommunikation.

DSB har to muligheder, når de skal købe ind. Enten, kan de vælge at købe noget eksisterende, og uden ændringer. Og henvende sig til dem, der har udviklet det, og sælger det. Skal der laves ændringer, skal de helst være lav-teknologiske, og indenfor det, som produktet er lavet til, at kunne uden ændringer.

Alternativet er, at henvende sig til en udviklingsvirksomhed, og få udviklet løsningen hos dem. Eller, at selv ansætte udviklere.

  • 0
  • 0

Franske tog kører ikke på minuttet, men på sekundet. Rejsekortet er en gang miskmask, og firmaet, som har programmeret det, har tjent styrtende på halvaber i det danske transportsystem. Man starter med EDB og støder så imod muren ADB På Ingeniørakademiet i sin tid lærte vi at man bruger 80% tid på ADB og 20% tid på EDB. (ADB står for administrativ data behandling, d.v.s. forenkling af systemer inden man overfører dem til EDB, elektronisk data behandling.) Med rejsekortet har man brugt 120% på EDB og -20% på ADB. Man har end ikke kunnet skrive en forståelig vejledning for brugerne på nettet. Jeg har således endnu ikke kunnet finde ud af hvor lang tid min rejse på 42 zoner fra Sengeløse til Herning må tage med rejsekortet.?

  • 0
  • 0
Bidrag med din viden – log ind og deltag i debatten