Gå til innhold

DEBATT: – Det går ikke an å jobbe smidig i gjennomføringsfasen til et vannfallsprosjekt


Anbefalte innlegg

Videoannonse
Annonse

Veldig bra. Accelerate burde vært lovfestet av DFØ, digdir og Riksrevisjonen. Det er galskap å ikke følge den boka, som i realiteten er empiri over hva som fungerer og hva som ikke fungerer for IT utvikling. Til eksempel er det vist at tilstedeværelse av CAB er korrelert med lavere kvalitet. Det er jo mildt sagt litt ironisk, med mindre du har forstått LEAN. Da er det logisk.

Endret av Anders Jensen
  • Liker 4
Lenke til kommentar

Takk for en velskrevet artikkel! Denne burde være forståelig selv for ikke-IT-personer! Liker brumetaforen godt. Det blir feil å dele opp prosjektet i deler som ikke gir verdi i seg selv (eks: et betongfundament, rekkeverk, asfalt, osv.). Dette vil bare legge grunnlaget for et kommunikasjonskaos uten like - "a recipe for disaster" :(

Endret av henrikho
feilstaving
  • Liker 2
Lenke til kommentar

Jeg lurer veldig på hvordan det er mulig å drive et større IT prosjekt på denne måten i dag. Eller fra en annen vinkling: Hvordan kan det være mulig å starte noe sånt uten at det blir sablet ned av fagmiljø innen IT? Eller en annen vinkling: Hvordan kan en ledelse godkjenne et slikt prosjekt uten at beslutningsgrunnlaget inneholder solid støtte fra IT fagmiljø? For det koker vel egentlig ned til følgende?: Slik gjør man det rett og slett ikke lengre fordi det er dyrt, tungvint og gammeldags!

  • Liker 1
Lenke til kommentar

Var mye bra her. Men vi må også slutte å snakke om "IT-prosjekt" som om dette var en enhetlig ting. Det er stor forskjell på et prosjekt som skal levere en sikker klientplattform for 20.000 brukere, og et prosjekt som skal utvikle en sky-basert tjeneste for de samme 20.000.  Fleksibiliteten i utviklingen av en tjeneste er en helt annen enn fleksibiliteten i utviklingen av en klientplatform, både når det kommer til planlegging i forkant og mulighetene til å snu fort om det skulle bli behov for det. 

Trakk frem to ytterpunkter her, men det er også flere nyanser man må ha i bakhodet når man omtaler "IT-prosjekter". :)

Lenke til kommentar

Hverken brukere eller utviklere trenger "plattformer" i sin arbeidshverdag. Mye av det jeg anbefaler handler nettopp om å unngå å skulle lage disse "fleksible plattform"-løsningene som skal kunne brukes av alle til alt mulig. De blir fort veldig komplekse - både å utvikle og å bruke. En bruker trenger applikasjoner som understøtter de behov han eller hun har iløpet av sin arbeidsdag. En utvikler som skal lage disse applikasjonene trenger ofte å integrere med eksterne tjenester for å få nødvendig funksjonalitet på plass, men disse eksterne tjenestene trenger ikke være del i "en plattform".

Gode "plattformer" blir til over tid, når man jobber med å løse konkrete behov og finner bedre og bedre måter å sammenkoble forskjellige ting på. Man bør ikke begynne med å skulle lage en generisk plattform. Man bør alltid fokusere på faktiske brukerbehov.

  • Liker 4
Lenke til kommentar

Godt innlegg Christin. Jeg er enig i din fremstilling og analogier til byggeprosjekter. Men jeg er noe usikker på hvor mye utvikling det egentlig er i AKSON. Jeg tipper det meste arbeid består i anskaffelser, integrasjoner og forvaltning. Jeg er også enig i brukergruppevinklingen, der vi setter brukeren i sentrum og gradvis åpner opp for mer, men hvordan dette prinsippet kan overføres til statens standard avtaler, der man helst skal spesifisere det meste på forkant, kan muligvis være en forklaring til det som er gjort så langt.

Lenke til kommentar

"Integrasjoner og forvaltning" er utvikling. Dette er kanskje den største misforståelsen med denne typen prosjekter. Man tenker at "dette er ikke utvikling" - men tilpassing av hyllevare det ér utvikling i aller høyeste grad. Og selv der man kan kjøpe inn ferdig hyllevare, tenker jeg det er mest hensiktsmessig å dele arbeidet inn per brukergruppe. Anskaffelser og utvikling bør ha klart fokus på en bestemt brukergruppe

  • Liker 1
Lenke til kommentar

Tipp topp Christin, og strålende analogi med broer.

Statens metode funker ikke for store IKT-prosjekter. Bare se på MOD i NAV - samme historien. Masse forarbeider som produserte bunker av papir og null kode og ikke minst null modning i organisasjonen, så da de begynte å konstruere opererte man i et vakuum. Det samme ville vært tilfelle med AKSON- men der ville man forsøkt å tre et amerikansk system ned over hodene på norsk helsevirkelighet.

Når det gjelder helsedata tar du dog feil, Christin. Helsedataplattformen handler om sekundærbruk. That´s different :-)

 

Lenke til kommentar

På hvilken måte tar jeg feil om "Helsedataplattformen"? (Har jeg sagt noe om den i det hele tatt? Mener du det som tidligere ble kalt Akson Samhandling, og som nå ikke skal være en del av Akson likevel?)

Hva gjelder Epic (Amerikansk system tredd nedover hodene til folk), så trodde også jeg at dette måtte være grunnen til at prosjektet var lagt opp slik det var. Men i et møte så fortalte representanter for direktoratet for e-helse meg personlig at de på ingen måte ønsket å innføre Epic, de ga inntrykk av at de virkelig håpet å få inn andre alternativer, og at Epic evt var noe de ble "nødt til å kjøpe inn" dersom ingen foreslo noe bedre (som de jo håpet at noen ville gjøre)

Lenke til kommentar

Opprett en konto eller logg inn for å kommentere

Du må være et medlem for å kunne skrive en kommentar

Opprett konto

Det er enkelt å melde seg inn for å starte en ny konto!

Start en konto

Logg inn

Har du allerede en konto? Logg inn her.

Logg inn nå
×
×
  • Opprett ny...