mboost-dp1
newz.dk
Hos oppositionen mener man ikke overraskende, at regeringen bærer ansvaret for rodet.
Uden at det skal gå hen at blive flamebait, så skyldes det jo nok at det er den pågældende minister der har det overordende ansvar for dette - uanset partifarve og navn :-)
Derud over så synes jeg det er sjældent - offentligt eller privat - man hører om projekter der rent faktisk overholder budgettet bare nogenlunde? For mig virker det som om der sidder nogle økonomer og planlæggere der ikke ved hvad det egentligt koster koster f.eks. udvikle ét styk software eller et boligkompleks.
Måske fordi de følger alle mulige matematiske, poltiske og samfundsvidenskabelige modeller fremfor "bare" at spørge manden på gulvet "Hvor langtid vil det tage dig at udvikle/bygge dette og hvad vil den umiddelbare pris være?" Eller hvertfald i det mindste rådføre sig lidt med dem - Så kan man altid ligge lidt "bufferbudget" i :-)
Naturligvis er der situationer man ikke kan forud sige - men man må jo da kunne give et realistisk bud på prisen og tiden..?
Det er selvfølgelig ærgelig, men det er nu stadig et nødvendigt onde, da disse implementeringer på længere sigt vil medføre en større effektivitet og gennemsigtighed i det offentlige.
Men spørgsmålet er så hvordan de kan lave nogle bedre pris-vurderinger. Det lyder umiddelbart meget forkert at man går ud og vurderer 3 år for lidt.
Men spørgsmålet er så hvordan de kan lave nogle bedre pris-vurderinger. Det lyder umiddelbart meget forkert at man går ud og vurderer 3 år for lidt.
Generelt så tror jeg at kunderne (som er embedsmænd, ikke politikere) er alt for IT-dumme og naive og primært tænker på at få det så billigt som muligt, hvilket IT-virksomhederne selvfølgelig udnytter og giver en så lav pris som muligt i udbudsrunden.
Nu sidder jeg selv på et af de overskredne statslige projekter, dog fra udvikler siden, og jeg kan sige at det hovedsagligt handler om at det offentlige ikke ved hvad fanden de vil have... på 3 og et halvt år har vi haft over 100 (hundrede) kontrakt ændringer.
Fra hvor jeg sidder det handler det om 3 ting.
1. Det offentlige beder typisk om store løsninger der ikke har været lavet tilsvarende før. Hvilket giver en stor usikkerheds faktor, når man tidsestimere.
2. Der ligger meget sjældent (kun omkring 10 procent af offentlige projekter) en business case, der gør det muligt at fastlægge success kritierier.
3. De mangler kvalificerede folk der kan lave ordenlige kravspecifikationer. At sige "Den skal understøtte Firefox 2.0, og netscape 7.0" på et projekt der spænder over flere år, er dybt useriøst.
Det sagt, det gamle motto "Consulting: If you ain't part of the solution, there is good money in prolonging the problem" gælder for de udviklings huse der sidder på projekterne. Jeg ved flere af de store huse, budgetere med bøder for tidsoverskridelser, når de laver et tilbud, fordi konkurencen er så hård, så måske skulle man være lidt mere.. Aggresiv på det punkt fra statens side..
Fra hvor jeg sidder det handler det om 3 ting.
1. Det offentlige beder typisk om store løsninger der ikke har været lavet tilsvarende før. Hvilket giver en stor usikkerheds faktor, når man tidsestimere.
2. Der ligger meget sjældent (kun omkring 10 procent af offentlige projekter) en business case, der gør det muligt at fastlægge success kritierier.
3. De mangler kvalificerede folk der kan lave ordenlige kravspecifikationer. At sige "Den skal understøtte Firefox 2.0, og netscape 7.0" på et projekt der spænder over flere år, er dybt useriøst.
Det sagt, det gamle motto "Consulting: If you ain't part of the solution, there is good money in prolonging the problem" gælder for de udviklings huse der sidder på projekterne. Jeg ved flere af de store huse, budgetere med bøder for tidsoverskridelser, når de laver et tilbud, fordi konkurencen er så hård, så måske skulle man være lidt mere.. Aggresiv på det punkt fra statens side..
Jeg sidder på den anden side af #4 og vil sige at jeg heller ikke er overrasket over det. Jeg er selv igang med en udliciterings fase af mit arbejde, og skriver kravspecifikationer. De bliver så lagt ind i det færdige udbud.
Lad mig sige det på den her måde; Hvad jeg har skrevet og hvad der er i udbudsmaterialet er for det meste stærkt bøjet, og har i nogle tilfælde været helt forkerte.
Efter min opfattelse, så er det ligeså snart der kommer en politisk enhed ind som mellemled at det går galt.
Lad mig sige det på den her måde; Hvad jeg har skrevet og hvad der er i udbudsmaterialet er for det meste stærkt bøjet, og har i nogle tilfælde været helt forkerte.
Efter min opfattelse, så er det ligeså snart der kommer en politisk enhed ind som mellemled at det går galt.
ja, plus at det altså er meget komplekse løsninger. jeg har både siddet på og set mange projekter løbe langt over deadlines og budgetter, og selvom der er en masse ting man kan blive klogere på og dygtigere til, så er det ikke min opfattelse at der er nogle nemme løsninger.
der er dog nogle steder jeg har lagt mærke til at det ofte skrider:
1) ansvar. det er nærmest umuligt at få nogen til at tage ansvar eller til at leve op til det.
2) kommunikation. "jeg har altså lavet min del til tiden" hjælper jo lige fedt hvis den passer ind i projektet som en kæp i mudder.
3) kompentence. på alle niveau'er..
og
4) politik. ak, ja, i den sidste ende er det nok det største problem. der går altid politik i tingene på et eller andet tidspunkt, nogle synes pludselig at de mister terræn eller at de bliver forfordelt eller at magt-balancen bliver forskudt, og så sætter de hælene i og al snak om teknologi og rationelle argumenter preller af som vand på gås...
der er dog nogle steder jeg har lagt mærke til at det ofte skrider:
1) ansvar. det er nærmest umuligt at få nogen til at tage ansvar eller til at leve op til det.
2) kommunikation. "jeg har altså lavet min del til tiden" hjælper jo lige fedt hvis den passer ind i projektet som en kæp i mudder.
3) kompentence. på alle niveau'er..
og
4) politik. ak, ja, i den sidste ende er det nok det største problem. der går altid politik i tingene på et eller andet tidspunkt, nogle synes pludselig at de mister terræn eller at de bliver forfordelt eller at magt-balancen bliver forskudt, og så sætter de hælene i og al snak om teknologi og rationelle argumenter preller af som vand på gås...
Jeg synes det er utrolig at det kan være så dyrt at udvikle løsninger. Men høre jo ofte om at nu vil regeringen have lavet et eller andet, og det er så vurderet til at koste 250 mill.
250 mill. For bare et en mill har man monster hardware så den del kan ikke koste meget mere end det.
Selv med udviklere som får 50k om måneden (600K om året), giver det 415 arbejds år. Eller 100 menneske i 4 år. for de resterende 249 mill. Tror sku ikke engang Microsoft har så mange mennesker til at udvikle Windows.
For at berettige en sådan mængde, skal vi altså snakke MONSTER kompliceret systemer, men så skulle man måske kigge et andet sted, også simplicifere lovgivningen, så projektet ikke var nær så indviklet.
Men helt ærlig. Hvor meget kan der være i "Digital Motor Registrering"? Hvad skal de gemme? Type (bil, motorcykel...), model, stelnummer, nummerplade, ejer og en dato. En dags arbejde også er det klaret... Login funktion en ekstra uge (da de jo idag har digital signatur, netID og pinkode løsninger)
[Edit]
Er der nogen som ved, om man kan se kravspecifikationerne på statens IT bestillinger et set?
250 mill. For bare et en mill har man monster hardware så den del kan ikke koste meget mere end det.
Selv med udviklere som får 50k om måneden (600K om året), giver det 415 arbejds år. Eller 100 menneske i 4 år. for de resterende 249 mill. Tror sku ikke engang Microsoft har så mange mennesker til at udvikle Windows.
For at berettige en sådan mængde, skal vi altså snakke MONSTER kompliceret systemer, men så skulle man måske kigge et andet sted, også simplicifere lovgivningen, så projektet ikke var nær så indviklet.
Men helt ærlig. Hvor meget kan der være i "Digital Motor Registrering"? Hvad skal de gemme? Type (bil, motorcykel...), model, stelnummer, nummerplade, ejer og en dato. En dags arbejde også er det klaret... Login funktion en ekstra uge (da de jo idag har digital signatur, netID og pinkode løsninger)
[Edit]
Er der nogen som ved, om man kan se kravspecifikationerne på statens IT bestillinger et set?
#7 Nu skal jeg gerne indrømme at jeg pt. kun er ved at uddanne mig og derfor ikke har praktisk erfaring inde for det men det er mere basale ting der går galt.
Problemet er at der som #4 så korrekt skriver ikke bliver lavet en ordentlig kravspecifikation. Virksomheden der skal udvikle projektet laver det så det opfylder kravspecifikationen de har. Den bliver formentlig ændret en mia. gange under vejs til at skulle tage sig af en smule mere eller gøre tingene på en lidt anderledes måde.
og ja en DRM registrering er ret simpel når man lige kigger på det er næppe heller selve programmeringen af buissneslaget der tager hele tiden. Men man kunne forestille sig at der er en del krav til brugergflader, database struktur, sikkerhed og andre af den slags ting som vi ikke kender til der også skal spille ind. Hvis man så oven i det forestiller sig at det skal kunne snakke sammen med andre systemer også så de ikke laver samme fejl som i sundhedssektoren der pt. er igang med at mindske antallet af programmer så har det også noget at sige.
Endelig kunne man forestille sig at der er nogle performance overvejelser der fylder noget mere i et projekt af den størrelse som DRM har i forhold til det man normalt laver.
Problemet er at der som #4 så korrekt skriver ikke bliver lavet en ordentlig kravspecifikation. Virksomheden der skal udvikle projektet laver det så det opfylder kravspecifikationen de har. Den bliver formentlig ændret en mia. gange under vejs til at skulle tage sig af en smule mere eller gøre tingene på en lidt anderledes måde.
og ja en DRM registrering er ret simpel når man lige kigger på det er næppe heller selve programmeringen af buissneslaget der tager hele tiden. Men man kunne forestille sig at der er en del krav til brugergflader, database struktur, sikkerhed og andre af den slags ting som vi ikke kender til der også skal spille ind. Hvis man så oven i det forestiller sig at det skal kunne snakke sammen med andre systemer også så de ikke laver samme fejl som i sundhedssektoren der pt. er igang med at mindske antallet af programmer så har det også noget at sige.
Endelig kunne man forestille sig at der er nogle performance overvejelser der fylder noget mere i et projekt af den størrelse som DRM har i forhold til det man normalt laver.
Det er jo et almindelig kendt og accepteret problem, at man ikke på forhånd kan beskrive detaljerne af hvad et IT-system skal kunne. Det er udvikling efter den traditionelle vandfaldsmodel, som gang på gang er bevist er utilstrækkelig.
Agile metoder har forsøgt at gøre op med dette problem, på den måde kan kunden løbende være med til at omprioritere hvad systemet skal kunne.
Desværre stemmer agile udviklingsmetoder ikke ret godt overens med offentlige udbud, da loven kræver, at der sendes et udbud ud, som leverandørerne så laver en kravsbesvarelse på.
Så for mig at se, så vil det aldrig blive anderledes, før man accepterer, at man ikke kan beskrive et komplekst system på forhånd (hvilket impiriske studier viser). Så kommer problemet hvordan det offentlige skal vælge en leverandør, når man ikke har noget at sammenligne med - for det offentlige er forpligtiget til at vælge den billigste leverandør hvis ikke der er andre væsentlige ting, der taler for at vælge en anden.
Så jeg er enig i, at det offentlige er dårlig til at administrere IT-projekter, men jeg nægter at tro på at det kan gøres meget bedre under de vilkår det offentlige skal arbejde under.
Agile metoder har forsøgt at gøre op med dette problem, på den måde kan kunden løbende være med til at omprioritere hvad systemet skal kunne.
Desværre stemmer agile udviklingsmetoder ikke ret godt overens med offentlige udbud, da loven kræver, at der sendes et udbud ud, som leverandørerne så laver en kravsbesvarelse på.
Så for mig at se, så vil det aldrig blive anderledes, før man accepterer, at man ikke kan beskrive et komplekst system på forhånd (hvilket impiriske studier viser). Så kommer problemet hvordan det offentlige skal vælge en leverandør, når man ikke har noget at sammenligne med - for det offentlige er forpligtiget til at vælge den billigste leverandør hvis ikke der er andre væsentlige ting, der taler for at vælge en anden.
Så jeg er enig i, at det offentlige er dårlig til at administrere IT-projekter, men jeg nægter at tro på at det kan gøres meget bedre under de vilkår det offentlige skal arbejde under.
#9
Jeg er helt forståelse for at der løbende kan komme ændringer til en kravsspecifikation, som kan hæve slut prisen. Men man høre altid om at nu skal staten til at lave et nyt system til +200 mill. De er ikke engang begyndt endnu, og allerede der er prisen sindsyg. Ændringer til systemet er derfor i de samme sindsyge beløb.
Jeg kan derfor egentlig godt forstå oppositionen når de siger at "ministerier slår alt for store brød op fra starten".
Sæt en max pris på 10 mill på hvert projekt. På den måde kan man netop tage det i små bidder, men lad selvfølgelig "forberedelse til fremtidig integeration" være en del af startfasen. Så laver man hoved programmet, og ser at det fungere som det skal. Man kan så derefter smide yderligere 10 mill i at integrere med et andet system. Og derefter igen med et trejde system.
Jeg vil påstå at man kan lave forholdsvis kompliceret systemer for 10 mill.
Jeg er helt forståelse for at der løbende kan komme ændringer til en kravsspecifikation, som kan hæve slut prisen. Men man høre altid om at nu skal staten til at lave et nyt system til +200 mill. De er ikke engang begyndt endnu, og allerede der er prisen sindsyg. Ændringer til systemet er derfor i de samme sindsyge beløb.
Jeg kan derfor egentlig godt forstå oppositionen når de siger at "ministerier slår alt for store brød op fra starten".
Sæt en max pris på 10 mill på hvert projekt. På den måde kan man netop tage det i små bidder, men lad selvfølgelig "forberedelse til fremtidig integeration" være en del af startfasen. Så laver man hoved programmet, og ser at det fungere som det skal. Man kan så derefter smide yderligere 10 mill i at integrere med et andet system. Og derefter igen med et trejde system.
Jeg vil påstå at man kan lave forholdsvis kompliceret systemer for 10 mill.
Det er selvfølgelig en del af problemet at krav specifikation og løsninger generelt er overkomplicerede (EPJ f.eks. burde slet ikke være et system, men en standard for udveksling af data som udbydere af EPJ programmer så skulle overholde).
Men det hjælper så heller ikke at store IT selskaber kommer med helt urealistisk lave bud for at vinde licitationen, og så spørger om flere penge når de er brugt op.
Men det hjælper så heller ikke at store IT selskaber kommer med helt urealistisk lave bud for at vinde licitationen, og så spørger om flere penge når de er brugt op.
#10
Præcis! Før de holder op med at prøve og designe et kæmpe system på papir, før får de heller ikke nogenlunde styr på prisen og leveringstiden, men er doomed til at gentage historien igen igen. Tvært i mod, hvis de ikke snart tager sig sammen bliver problemet nok endnu større i fremtiden da mere og mere bliver "edbtiseret".
Den eneste mulige løsning, som jeg ser det, er at forsøge, på en eller anden måde, at køre en agile iterativ proces, hvor man hen ad vejen får bygget et produkt op som virker og er brugbart. Det er hele det eksisterende værdigrundlag og rollefordeling som agile software development processen gør op med, og historien syntes jeg har vist igen og igen at det er nødvendigt.
Præcis! Før de holder op med at prøve og designe et kæmpe system på papir, før får de heller ikke nogenlunde styr på prisen og leveringstiden, men er doomed til at gentage historien igen igen. Tvært i mod, hvis de ikke snart tager sig sammen bliver problemet nok endnu større i fremtiden da mere og mere bliver "edbtiseret".
Den eneste mulige løsning, som jeg ser det, er at forsøge, på en eller anden måde, at køre en agile iterativ proces, hvor man hen ad vejen får bygget et produkt op som virker og er brugbart. Det er hele det eksisterende værdigrundlag og rollefordeling som agile software development processen gør op med, og historien syntes jeg har vist igen og igen at det er nødvendigt.
#12 forholdsvis kompliceret system ja. Men før vi siger 10 mill er maks så skal vi have defineret hvad de penge skal gå til. Er det udelukkende penge der skal gå til programmøre og selve udviklingen? Eller er det også dem der skal gå til alle dem der skal lave kravspecifikation og være inde over under hele udviklingen af systemet.
Bortset fra jeg ikke syns man skal sætte en maks pris på så er jeg helt enig. Det offentlige kunne med fordel splitte sin software park op i flere små bidder der kan arbejde sammen evt. med en fælles brugerfalde også.
#13 mht. IT selskaberne så kunne det være interessant at se de kontrakter der laves vi må gå ud fra at hvis der ikke foretages ændringer i kravspecifikationen er det IT selskabet der hænger på det hvis ikke de laver om på det løbende.
Der ud over kan jeg tilføje om EPJ og hele sygehusvæsenets struktur at de er ved at lave om og tænker det ind i nye systemer de laver du kan f.eks. læse National strategi for sundhedsvæsenet
#14 Jeg tror nærmere problemet er dårlige formuleret krav og folk der ikke aner hvad de reelt har brug for fra det offentliges side end det er udviklingsmetoden.
Bortset fra jeg ikke syns man skal sætte en maks pris på så er jeg helt enig. Det offentlige kunne med fordel splitte sin software park op i flere små bidder der kan arbejde sammen evt. med en fælles brugerfalde også.
#13 mht. IT selskaberne så kunne det være interessant at se de kontrakter der laves vi må gå ud fra at hvis der ikke foretages ændringer i kravspecifikationen er det IT selskabet der hænger på det hvis ikke de laver om på det løbende.
Der ud over kan jeg tilføje om EPJ og hele sygehusvæsenets struktur at de er ved at lave om og tænker det ind i nye systemer de laver du kan f.eks. læse National strategi for sundhedsvæsenet
#14 Jeg tror nærmere problemet er dårlige formuleret krav og folk der ikke aner hvad de reelt har brug for fra det offentliges side end det er udviklingsmetoden.
At et budget overskrides er ikke ensbetydende med at projektet er dårligt styret.
Nok nærmere at staten har valgt den billigste pris, som fra starten har været urealistisk, hvilket så resulterer i at firmaet arbejder med skyklapper på, for at overholde en urealistisk deadline og et for lille budget.
Resultat: En ubruelig løsning der skal laves om fra bunden, den opgave ryger så til det firma der gir' den bedste pris, på at rydde op i det projekt der kuldsejlede pga. leverandøren udelukkende blev valgt på pris... og så kører vi i ring derfra.
Der behøver ikke at ha' noget med IT at gøre. Sådan fungerer det offentligt.
Tænk på hvor mange millioner der blev brugt på at sende ambulancekørsel i licitation. Så vælger de et billigt svensk firma der umuligt kan løfte opgaven men som gir' den billigste pris.
Heldigvis gav de så op inden de overhovedet kom igang, men så skal hele udliciteringen starte forfra, med dertil hørende ekstra omkostninger.
Nok nærmere at staten har valgt den billigste pris, som fra starten har været urealistisk, hvilket så resulterer i at firmaet arbejder med skyklapper på, for at overholde en urealistisk deadline og et for lille budget.
Resultat: En ubruelig løsning der skal laves om fra bunden, den opgave ryger så til det firma der gir' den bedste pris, på at rydde op i det projekt der kuldsejlede pga. leverandøren udelukkende blev valgt på pris... og så kører vi i ring derfra.
Der behøver ikke at ha' noget med IT at gøre. Sådan fungerer det offentligt.
Tænk på hvor mange millioner der blev brugt på at sende ambulancekørsel i licitation. Så vælger de et billigt svensk firma der umuligt kan løfte opgaven men som gir' den billigste pris.
Heldigvis gav de så op inden de overhovedet kom igang, men så skal hele udliciteringen starte forfra, med dertil hørende ekstra omkostninger.
#15 I kontakter med det offentlige er der typisk et meget stort antal forudsætninger i de afgivne tilbud der skal være opfyldt for at tallene i kontrakten kan overholdes.
Disse forudsætninger overholdes sjældent og derfor er selskaberne i deres gode ret til at bede om flere penge for opgaverne da omfanget har ændret sig.
En ting er dårligt formulerede krav, noget andet er at man sætter nogle folk til at specificere hvordan ting, som først skal leveres om 2-3 år skal fungere ned i mindste detalje. Det er der sjældent nogen der har den mindste idé om. De gør deres bedste, men har sjældent ret. Det betyder at så skal krav, analyser, design og evt. implementering laves om når man så opdager at det ikke kan lade sig gøre. Derudover har det selvfølgelig også meget at sige hvem der sidder og skriver kravene. Er det overlæger som sjældent selv sidder og bruger systemerne, eller er det ekspertbrugere af de eksisterende systemer inden for de enkelte områder der skriver krav/ønsker til de kommende systemer. Nogle gange har man som udvikler en fornemmelse af at det er de folk med mest magt på stedet som har fået lov at skrive kravene, og ikke nødvendigvis dem med mest indsigt i hvad der er brug for og hvad der er af problemer i de gamle systemer.
Jeg tror at hvis man i stedet havde en lidt mere lean/agil tilgang og fokuserede mere på små leverancer end store big bang implementeringer så vil kunden undervejs have væsentlig større mulighed for at ændre sine prioriteringer. Man kan stadig arbejde med fastpriskontrakter, men kan så justere på scopet i stedet. I sidste ende tror jeg man ender med nogle langt mere tilfredse brugere af systemetm, selvom det måske kun kan 80% af det som idémændene mente der var brug for for 3 år siden. Det kan jo være de 80% er rigeligt og resten var mere nice to have.
Al erfaring viser at når først kunden har haft en løsning i hænderne er der altid dukket forbedringsforslag/ændringsønsker eller lignende op. Hvis der går år mellem leverancer så er det nogle meget store/gennemgribende ændringer man kan løbe ind i som er meget dyre. Hvis man derimod giver kunden muligheden for hele tiden at prøve den seneste løsning af og få deres input så kan man rette ind med minimale eller slet ingen ekstraomkostninger for projektet.
Disse forudsætninger overholdes sjældent og derfor er selskaberne i deres gode ret til at bede om flere penge for opgaverne da omfanget har ændret sig.
En ting er dårligt formulerede krav, noget andet er at man sætter nogle folk til at specificere hvordan ting, som først skal leveres om 2-3 år skal fungere ned i mindste detalje. Det er der sjældent nogen der har den mindste idé om. De gør deres bedste, men har sjældent ret. Det betyder at så skal krav, analyser, design og evt. implementering laves om når man så opdager at det ikke kan lade sig gøre. Derudover har det selvfølgelig også meget at sige hvem der sidder og skriver kravene. Er det overlæger som sjældent selv sidder og bruger systemerne, eller er det ekspertbrugere af de eksisterende systemer inden for de enkelte områder der skriver krav/ønsker til de kommende systemer. Nogle gange har man som udvikler en fornemmelse af at det er de folk med mest magt på stedet som har fået lov at skrive kravene, og ikke nødvendigvis dem med mest indsigt i hvad der er brug for og hvad der er af problemer i de gamle systemer.
Jeg tror at hvis man i stedet havde en lidt mere lean/agil tilgang og fokuserede mere på små leverancer end store big bang implementeringer så vil kunden undervejs have væsentlig større mulighed for at ændre sine prioriteringer. Man kan stadig arbejde med fastpriskontrakter, men kan så justere på scopet i stedet. I sidste ende tror jeg man ender med nogle langt mere tilfredse brugere af systemetm, selvom det måske kun kan 80% af det som idémændene mente der var brug for for 3 år siden. Det kan jo være de 80% er rigeligt og resten var mere nice to have.
Al erfaring viser at når først kunden har haft en løsning i hænderne er der altid dukket forbedringsforslag/ændringsønsker eller lignende op. Hvis der går år mellem leverancer så er det nogle meget store/gennemgribende ændringer man kan løbe ind i som er meget dyre. Hvis man derimod giver kunden muligheden for hele tiden at prøve den seneste løsning af og få deres input så kan man rette ind med minimale eller slet ingen ekstraomkostninger for projektet.
Nyheden (0) skrev:Et eksempel er det digitale motorregister, der skulle have været færdig den 1. januar 2008, men som er blevet udskudt til 2011, hvilket betyder en stor ekstraregning.
Hvordan kan man udskyde software der bare skal REGISTERER ting der STÅR PÅ PAPIR NU, 3 år!
Det er så absurd det ikke er til at forstå.
farmerhe (15) skrev:
#13 mht. IT selskaberne så kunne det være interessant at se de kontrakter der laves vi må gå ud fra at hvis der ikke foretages ændringer i kravspecifikationen er det IT selskabet der hænger på det hvis ikke de laver om på det løbende.
Det varierer, nogle kontrakter er fastpris (men der er så lagt en risikofaktor på prisen), andre er afregnet pr. forbrugt time.
farmerhe (15) skrev:
#14 Jeg tror nærmere problemet er dårlige formuleret krav og folk der ikke aner hvad de reelt har brug for fra det offentliges side end det er udviklingsmetoden.
Det er jo netop det der er hele problemet, man kan ikke definere præcist hvad man vil have - dels fordi man ikke ved det, og dels fordi man bliver klogere løbende, så det man troede man ville have, viser sig, at man egentlig vil have på en anden måde istedet, omverdenen er jo ikke stillestående mens et IT-system bliver udviklet.
Jeg har selv arbejdet på flere IT-projekter, hvor kunden var offentlig. Min generelle opfattelse er, at de offentlige kunder beder om den dobbelte funktionalitet (i forhold til behov) til den halve pris. IT-firmaerne er så dumme nok til at hoppe med på den.
Det kan kun gå galt.
Det største af projekterne skulle kunne det hele. Ikke noget, at man går ud med version 1, der kan give nogen nytte for brugerne, og så kommer med version 2 og 3 senere, der for hver version giver mere værdi. Nej, den offentlige kunde ville have hele funktionaliteten med det samme - inkl. alle de fancy features.
Selvfølgelig blev der også begået fejl fra udviklernes side, det er klart, men jeg tror det ville hjælpe meget, hvis det offentlige havde IT-folk til at styre implementeringen af IT-projekter i eget hus. Det går bare nemmere, når IT-folk taler med IT-folk.
Når det er sagt, så går jeg ind for at man opdeler et projekt i flere små dele og sender dem i udbud (eller i meget små dele, der kan sælges direkte - jeg ved ikke hvor grænsen ligger). Det betyder at de tilbageløb, der vil komme, vil blive mindre og mere håndterbare.
Det kan kun gå galt.
Det største af projekterne skulle kunne det hele. Ikke noget, at man går ud med version 1, der kan give nogen nytte for brugerne, og så kommer med version 2 og 3 senere, der for hver version giver mere værdi. Nej, den offentlige kunde ville have hele funktionaliteten med det samme - inkl. alle de fancy features.
Selvfølgelig blev der også begået fejl fra udviklernes side, det er klart, men jeg tror det ville hjælpe meget, hvis det offentlige havde IT-folk til at styre implementeringen af IT-projekter i eget hus. Det går bare nemmere, når IT-folk taler med IT-folk.
Når det er sagt, så går jeg ind for at man opdeler et projekt i flere små dele og sender dem i udbud (eller i meget små dele, der kan sælges direkte - jeg ved ikke hvor grænsen ligger). Det betyder at de tilbageløb, der vil komme, vil blive mindre og mere håndterbare.
Elsker bare den måde, det offentlige kører på :D
"Nå ja, det kan da godt være at vi har lavet nogle fejl hen ad vejen, men vi er faktisk allesammen ret ligeglade herinde, for det er ikke vores penge"
Når den slags sker i det private, ender det som regel med at der ruller nogle hoveder :)
"Nå ja, det kan da godt være at vi har lavet nogle fejl hen ad vejen, men vi er faktisk allesammen ret ligeglade herinde, for det er ikke vores penge"
Når den slags sker i det private, ender det som regel med at der ruller nogle hoveder :)
PaNiX (20) skrev:Selvfølgelig blev der også begået fejl fra udviklernes side, det er klart, men jeg tror det ville hjælpe meget, hvis det offentlige havde IT-folk til at styre implementeringen af IT-projekter i eget hus. Det går bare nemmere, når IT-folk taler med IT-folk.
Det er så her det også går galt. Jeg kan nævne de første 10 IT ansvarlige i Aarhus Kommune der ikke engang ved at en server kræver køling for at kører optimalt.
Et offentligt projekt der er dårligt styret, overskrider økonomien og højst sandsynligt ender som en fiasko... Det kan da ikke passe..
Politikerne kan pisse vores penge væk som det passer dem, det har absolut ingen konsekvenser alligevel. Bliver det så en sjælden gang lidt for hedt herhjemme så kan man jo altid komme til EU og fylde lommerne der..
Jeg har givet op, stemmer altid blankt, da det er hamrende ligegyldigt hvem der sidder ved magten. De fylder alle lommerne med alt hvad de kan, så ingen har lyst til at lave det om..
Har der nogensinde været mere enige afstemninger i folketinget end når det gælder lønforhøjelse til dem selv?
/sigh
Politikerne kan pisse vores penge væk som det passer dem, det har absolut ingen konsekvenser alligevel. Bliver det så en sjælden gang lidt for hedt herhjemme så kan man jo altid komme til EU og fylde lommerne der..
Jeg har givet op, stemmer altid blankt, da det er hamrende ligegyldigt hvem der sidder ved magten. De fylder alle lommerne med alt hvad de kan, så ingen har lyst til at lave det om..
Har der nogensinde været mere enige afstemninger i folketinget end når det gælder lønforhøjelse til dem selv?
/sigh
Ok. Jeg bliver nød til at trække en af mine tidligere kommetare tilbage:
Microsoft har ca 25 teams, med gennemsnit 40 udviklere på hver. = 1000 personer.
http://blogs.msdn.com/e7/archive/2008/08/18/window...
Men jeg vil stadig påstå at et komplet OS er 100 gange mere kompliceret end noget Staten nogen sinde kan komme på.
...giver det 415 arbejds år. Eller 100 menneske i 4 år. for de resterende 249 mill. Tror sku ikke engang Microsoft har så mange mennesker til at udvikle Windows.
Microsoft har ca 25 teams, med gennemsnit 40 udviklere på hver. = 1000 personer.
http://blogs.msdn.com/e7/archive/2008/08/18/window...
Men jeg vil stadig påstå at et komplet OS er 100 gange mere kompliceret end noget Staten nogen sinde kan komme på.
#24
Fin påståand, har du noget at bakke den op med?
Yderligere kommer du ikke langt for 1 mio kr, hvis du skal server udstyr og ofte indgår driften af det også i prisen.
Dernæst, der er ikke tale om tante oda's frisørsalon der skal på nettet, mange af systemerne er kæmpe store og i en skala hvor meget få kan være med.
Dermed ikke sagt at staten forvalter det godt, men det er ikke bare lige at gøre som du siger.
Hvad er din erfaring med systemudvikling, specifikation og kontraktarbejde i store systemer?
En anden ting er jo at 10% overskridelse i et kæmpe projekt lyder af mange kroner, men det gør det vel ikke anderledes end når man går 10% over på udviklingsprisen af en ny hjemmeside?
Fin påståand, har du noget at bakke den op med?
Yderligere kommer du ikke langt for 1 mio kr, hvis du skal server udstyr og ofte indgår driften af det også i prisen.
Dernæst, der er ikke tale om tante oda's frisørsalon der skal på nettet, mange af systemerne er kæmpe store og i en skala hvor meget få kan være med.
Dermed ikke sagt at staten forvalter det godt, men det er ikke bare lige at gøre som du siger.
Hvad er din erfaring med systemudvikling, specifikation og kontraktarbejde i store systemer?
En anden ting er jo at 10% overskridelse i et kæmpe projekt lyder af mange kroner, men det gør det vel ikke anderledes end når man går 10% over på udviklingsprisen af en ny hjemmeside?
fennec (24) skrev:Ok. Jeg bliver nød til at trække en af mine tidligere kommetare tilbage:
Microsoft har ca 25 teams, med gennemsnit 40 udviklere på hver. = 1000 personer.
http://blogs.msdn.com/e7/archive/2008/08/18/window...
Men jeg vil stadig påstå at et komplet OS er 100 gange mere kompliceret end noget Staten nogen sinde kan komme på.
Kan sige at 35 udviklere, arkitekter m.m. på mit sidste projekt, i snit kostede ca. 3 mill om måneden.. så 100k per ansat..
Og ud fra dine kommentare tror jeg ikke dine erfaringer er særligt store inden for udvikling. At sige at et statsligt projekt er mindre kompliceret end et OS er lidt som at sammenligne pærer og cykler.. ikke rigtig muligt. Hvis du skal sidde og lave et system der skal håndtere økonomisk lovgivning, som det jeg sidder med, er kompleksiteten enorm.
Min holdning er når man siger fra udviklings siden "vi skal ikke forstå arbejds logikken, vi skal bare have en kravspec" for så forstår de ikke hvad det er de skal hjælpe med til at forbedre.
Hos os er vi gået over til SCRUM og testdriven development, personligt mener jeg dog at man burde gå over til Front Ahead Design :)
Mange af systermener er bare digitalisering af papir formularer.Tore (27) skrev:Hvis du skal sidde og lave et system der skal håndtere økonomisk lovgivning, som det jeg sidder med, er kompleksiteten enorm.
Staten lægger bare en masse ekstra lort oven på som ikke er nødvendigt. Og så blæses det helt ud af propertioner.
#28
Nu er problemet jo ikke at gøre papiret digitalt det er langt mere tunge ting der er snak om her. F.eks. noget af det der ligger inde bag ved formuleringen og som den offentlige ansatte skal beregne. I stedet for at en medarbejder sidder og bruger tid og skattekroner på det kan software styre det problem men kompleksiteten er som #27 skriver ganske sikkert enorm i forhold til bare at flytte papiret over på skærmen. (Desuden bør man altid overveje om man kan forbedre noget i stedet for bare at gøre papiret elektronisk når man laver den slags projekter)
Nu er problemet jo ikke at gøre papiret digitalt det er langt mere tunge ting der er snak om her. F.eks. noget af det der ligger inde bag ved formuleringen og som den offentlige ansatte skal beregne. I stedet for at en medarbejder sidder og bruger tid og skattekroner på det kan software styre det problem men kompleksiteten er som #27 skriver ganske sikkert enorm i forhold til bare at flytte papiret over på skærmen. (Desuden bør man altid overveje om man kan forbedre noget i stedet for bare at gøre papiret elektronisk når man laver den slags projekter)
Der er vist en fejl i overskriften. Der burde stå "Staten er også dårlig til at håndtere it-projekter"
Det offentlige og IT går af en eller anden grund meget dårligt i spænd. Tror det har noget med at gøre, at de satser for overambitiøst på at lave altomfattende løsninger, som aldrig bliver færdige og strander når pengene løber ud.
I det private har man ikke en uendelig statskasse at tage af, og derfor er man tvunget til at tage et skridt af gangen og at genbruge dele af eksisterende systemer, og den slags inkrementel udvikling har det med at give langt bedre resultater, både hurtigere og billigere.
Har haft en del med sundhedsvæsnet at gøre på det seneste, og det er utroligt så meget tid de alt for få læger vi har til rådighed har i landet spilder med at bøvle med IT. Hvor en hver normal borger i årtier har kunnet sende en besked fra en computer til en anden øjeblikkeligt tager den slags halve og hele timer inden for sundhedsvæsnet.
I det private har man ikke en uendelig statskasse at tage af, og derfor er man tvunget til at tage et skridt af gangen og at genbruge dele af eksisterende systemer, og den slags inkrementel udvikling har det med at give langt bedre resultater, både hurtigere og billigere.
Har haft en del med sundhedsvæsnet at gøre på det seneste, og det er utroligt så meget tid de alt for få læger vi har til rådighed har i landet spilder med at bøvle med IT. Hvor en hver normal borger i årtier har kunnet sende en besked fra en computer til en anden øjeblikkeligt tager den slags halve og hele timer inden for sundhedsvæsnet.
Ja, men at bruge millioner på at oversætte et Excel ark er ikke acceptabelt.farmerhe (30) skrev:F.eks. noget af det der ligger inde bag ved formuleringen og som den offentlige ansatte skal beregne. I stedet for at en medarbejder sidder og bruger tid og skattekroner på det kan software styre det problem men kompleksiteten er som #27 skriver ganske sikkert enorm i forhold til bare at flytte papiret over på skærmen.
Men det er hvad de gør gang på gang.
Det fleste af de offenlige projekter er digitalisering af gamle papir metoder. Ting som *er* simple! men fejler af en eller anden grund.
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
- ⟨
- Nyheder
Gå til bund