mboost-dp1
1,5 mia kroner for at udvilke en app
.. til rejsekort: https://ing.dk/artikel/utaalmodige-politikere-vil-...
Hårrejsende håbløst langsomt og dyrt grænsende til at håret simpelthen letter fra issen og man efterlades skaldet.
Drop dog appen og indfør at man kan bruge betalingskort i standerne. Det vil kunne simplificere hele systemet helt ekstremt. Usability for lokale såvel som for besøgende fra udlandet vil stige fra ~1% til 100% og man vil kunne overføre betalingskortet til telefonens NFC og den oprindelige idé er på plads.
Nå nej, det var vist for enkel og billig en løsning, den går ikke.
Ifølge Transportministeriet er der bruttoudgifter ved projektet på op mod 1,5 milliarder kroner, og en Rejsekort/Rejseplan-app vil tidligst kunne downloades i 2025, mens fløden først for alvor kan skummes efter 7-9 år.
Hårrejsende håbløst langsomt og dyrt grænsende til at håret simpelthen letter fra issen og man efterlades skaldet.
Drop dog appen og indfør at man kan bruge betalingskort i standerne. Det vil kunne simplificere hele systemet helt ekstremt. Usability for lokale såvel som for besøgende fra udlandet vil stige fra ~1% til 100% og man vil kunne overføre betalingskortet til telefonens NFC og den oprindelige idé er på plads.
Nå nej, det var vist for enkel og billig en løsning, den går ikke.
Typisk når staten skal have en IT-løsning. Altid over 1 milliard, altid over 3 års udvikling (edit: Jeg glemte at tilføje at der som regel kommer ekstraregninger på ca. 200% af det originale estimat, og at det tager ca. dobbelt så lang tid som først angivet...). Hvordan kan det koste så meget, og tage så lang tid? Jeg ved givetvis ikke noget om udvikling af større IT-projekter, men er opgaven her virkeligt så stor? Ville en privat virksomhed ikke kunne komme langt for 5 millioner og et år?
Google Maps har jo allerede meget af infrastrukturen på plads for at sammensætte en rejse med offentlig transport (den er ikke altid lige nøjagtig, men er mere omfattende end rejseplanen).
Google Maps har jo allerede meget af infrastrukturen på plads for at sammensætte en rejse med offentlig transport (den er ikke altid lige nøjagtig, men er mere omfattende end rejseplanen).
#3 Jeg vil give mit bud på en forklaring:
Store offentlige projekter med mange interessenter ender med en kravspecifikation med en masse politiske aftaler skrevet ind. Denne kravspec er typisk alt for detaljeret og ufleksibel og tillader ikke den bedste teksniske løsning, men definerer en masse særkrav som komplicerer og fordyrer.
Så kommer de private firmaer på banen og byder på opgaven med enormt høje priser fordi det er bøvlet at levere noget ud fra en gigantisk kravspec. Så bliver det hele forsinket fordi kravspec fører til noget forfærdelig stiv og umedgørlig teknologi der er svær at få til at virke ordenligt.
Løsningen ville have været en stærk projektleder der kunne skære igennem og få alle interessenterne til at klappe kaje og give dem et ultimatum: Vil I være med i denne nye forenklede moderne løsning eller vil I være fri? Projektlederen skal også kunne se stort på råb og skrig i medierne om social massegrav fordi nogle rejsende kommer til at betale et par kroner mere og nogle et par kroner mindre. Dansk millimeterretfærdighed er så afgjort en ting.
Men sådan en projektleder findes bare ikke og man ender med et kludetæppe af et rejsekort der er ekseptionelt kompliceret og bygget på forældet teknologi. Og så koster det 1.5e9 kroner at lave en f..ing app til det. Halleluja.
Store offentlige projekter med mange interessenter ender med en kravspecifikation med en masse politiske aftaler skrevet ind. Denne kravspec er typisk alt for detaljeret og ufleksibel og tillader ikke den bedste teksniske løsning, men definerer en masse særkrav som komplicerer og fordyrer.
Så kommer de private firmaer på banen og byder på opgaven med enormt høje priser fordi det er bøvlet at levere noget ud fra en gigantisk kravspec. Så bliver det hele forsinket fordi kravspec fører til noget forfærdelig stiv og umedgørlig teknologi der er svær at få til at virke ordenligt.
Løsningen ville have været en stærk projektleder der kunne skære igennem og få alle interessenterne til at klappe kaje og give dem et ultimatum: Vil I være med i denne nye forenklede moderne løsning eller vil I være fri? Projektlederen skal også kunne se stort på råb og skrig i medierne om social massegrav fordi nogle rejsende kommer til at betale et par kroner mere og nogle et par kroner mindre. Dansk millimeterretfærdighed er så afgjort en ting.
Men sådan en projektleder findes bare ikke og man ender med et kludetæppe af et rejsekort der er ekseptionelt kompliceret og bygget på forældet teknologi. Og så koster det 1.5e9 kroner at lave en f..ing app til det. Halleluja.
Her i Stockholm har vi skiftet vores SL (Stockholms län, dvs. amt) rejsekort ud med alm. betalingskort her til sommer. Så nu kan vi bare tap på læseren der hvor vi brugte kortet før for at betale.
Rejsekorts løsningen i Danmark er helt klart "visions of grandour" fra de fjolser der har fået lov at lede projektet gennem tiden.
Rejsekorts løsningen i Danmark er helt klart "visions of grandour" fra de fjolser der har fået lov at lede projektet gennem tiden.
#4
Der er en tendens til at lægge ansvaret for offentlige IT skandaler på brug af waterfall model.
Men virkeligheden er nok lidt mere kompleks.
Det offentlige har haft agile standard kontrakter tilgængelig for IT leverancer i mange år.
Og jeg synes ikke at den typiske offentlige IT skandale matcher waterfall.
Med waterfall vil man have en kontrakt med:
* X tusind sider detaljerede krav - funktionelle krav på kontrakttidspunkt T og ikke funktionelle krav
* en leverings tid N
* en pris M
Når man når til T+N vil man enten have et system som opfylder funktionelle krav T og ikke funktionelle krav eller man vil have en erstatninsgbetaling fra leverandøren.
Man er ikke i hus fordi:
- man mangler funktionelle krav ændringer mellem T og T+N
- en del af bruger interfacet er håbløst
Det koster f.eks. 6 måneder og 15% oven i prisen at få det fixet. Men der er næsten ingen risiko for at noget går galt. Og bagefter så virker det.
Det synes jeg ikke matcher med billedet af offentlige IT skandaler. De går flere år over tiden. De går 50 eller 100 eller 150 procent over i pris. Nogle bliver opgivet fordi de simpelthen ikke virker.
Det er populært i visse agile kredse at tale om waterfall camoufleret som agile.
Men jeg tror at det vi har i de store offentlige IT skandaler er agile camoufleret som waterfall.
Man ved ikke hvad man vil have ved projekt start. Men man producerer N tusind sider kravspec med tilfældige krav som alle godt ved ikke er et komplet endeligt sæt krav. Så estimerer man det til at koste M og får en bevilling. Og så går man i gang med projektet. Og de funkltionelle krav justeres løbende. Leveringstiden N og prisen M opjusteres løbende efterhånden som man kommer omkring kravene. Og viser det sig at de nye funktionelle krav ødelægger de ikke funktionelel krav, så er projektet dødsdømt.
Der er en tendens til at lægge ansvaret for offentlige IT skandaler på brug af waterfall model.
Men virkeligheden er nok lidt mere kompleks.
Det offentlige har haft agile standard kontrakter tilgængelig for IT leverancer i mange år.
Og jeg synes ikke at den typiske offentlige IT skandale matcher waterfall.
Med waterfall vil man have en kontrakt med:
* X tusind sider detaljerede krav - funktionelle krav på kontrakttidspunkt T og ikke funktionelle krav
* en leverings tid N
* en pris M
Når man når til T+N vil man enten have et system som opfylder funktionelle krav T og ikke funktionelle krav eller man vil have en erstatninsgbetaling fra leverandøren.
Man er ikke i hus fordi:
- man mangler funktionelle krav ændringer mellem T og T+N
- en del af bruger interfacet er håbløst
Det koster f.eks. 6 måneder og 15% oven i prisen at få det fixet. Men der er næsten ingen risiko for at noget går galt. Og bagefter så virker det.
Det synes jeg ikke matcher med billedet af offentlige IT skandaler. De går flere år over tiden. De går 50 eller 100 eller 150 procent over i pris. Nogle bliver opgivet fordi de simpelthen ikke virker.
Det er populært i visse agile kredse at tale om waterfall camoufleret som agile.
Men jeg tror at det vi har i de store offentlige IT skandaler er agile camoufleret som waterfall.
Man ved ikke hvad man vil have ved projekt start. Men man producerer N tusind sider kravspec med tilfældige krav som alle godt ved ikke er et komplet endeligt sæt krav. Så estimerer man det til at koste M og får en bevilling. Og så går man i gang med projektet. Og de funkltionelle krav justeres løbende. Leveringstiden N og prisen M opjusteres løbende efterhånden som man kommer omkring kravene. Og viser det sig at de nye funktionelle krav ødelægger de ikke funktionelel krav, så er projektet dødsdømt.
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Software
Gå til bund