Forskjell mellom versjoner av «Programvareanbud»

Fra Piratpartiets Wiki
Hopp til: navigasjon, søk
(Created page with "Offentlig programvareutvikling på anbud medfører svært ofte ekstremt kostbare prosjekter hvor sluttresultatet i beste fall er halvgodt, men sjeldent bra. Vi nevner i fleng...")
 
Linje 5: Linje 5:
 
* All kode utviklet på offentlig anbud må frigis som åpen kildekode.
 
* All kode utviklet på offentlig anbud må frigis som åpen kildekode.
 
* Mange korte, små prosjekter er bedre enn noen få store prosjekter.  Med åpen kildekode er det i allefall teoretisk mulig å ha åpne anbudsrunder på vidreutvikling av eksisterende programvare.
 
* Mange korte, små prosjekter er bedre enn noen få store prosjekter.  Med åpen kildekode er det i allefall teoretisk mulig å ha åpne anbudsrunder på vidreutvikling av eksisterende programvare.
* Alt av offentlige anbud bør ut på offentlig høring for å få til en best mulig spec.
+
* Alt av offentlige anbud bør ut på offentlig høring for å få til en best mulig kravspesifikasjon (heretter ''spec'').
 
* Kontraktene må legge opp til fleksibilitet og bruk av "agile"-metodikk.
 
* Kontraktene må legge opp til fleksibilitet og bruk av "agile"-metodikk.
  
Linje 19: Linje 19:
 
== Vidreutvikling ==
 
== Vidreutvikling ==
  
Programvareutvikling kan ikke sammenlignes med en maskin som skal avskrives i løpet av fem år og så byttes ut.  Programvare er noe som krever kontinuerlig vedlikehold og vidreutvikling, og det er ofte svært dyrt å bytte ut programvare - både pga kostnad med datakonverteringer, motvillige ansatte som må kurses.  Ofte kan nye mål realiseres ved å vidreutvikle eksisterende programvare.  Det bør være innlysende at åpen kildekode er helt nødvendig for at man skal kunne ha åpne anbudsrunder for vidreutvikling og vedlikehold.
+
Programvareutvikling kan ikke sammenlignes med en maskin som skal avskrives i løpet av fem år og så byttes ut.  Programvare er noe som krever kontinuerlig vedlikehold og videreutvikling, og det er ofte svært dyrt å bytte ut programvare - både pga kostnad med datakonverteringer, motvillige ansatte som må kurses.  Ofte kan nye mål realiseres ved å vidreutvikle eksisterende programvare.  Det bør være innlysende at åpen kildekode er helt nødvendig for at man skal kunne ha åpne anbudsrunder for vidreutvikling og vedlikehold.
  
 
== Dårlig spec ==
 
== Dårlig spec ==
Linje 33: Linje 33:
 
=== Endringer underveis i kravspek ===
 
=== Endringer underveis i kravspek ===
  
Programvareutvikling kan heller ikke sammenlignes med f.eks. å bygge en bru.  En bru er en typisk ting hvor man først lager byggeplaner ned i den minste detalj og så bygger brua.  Programvareutvikling behøver ikke være slik - i løpet av utviklingen vil det som regel dukke opp mange nye idéer, behov og problemstillinger som man ikke tenkte på (eller som ikke var aktuelle) da kravspesifikasjonen (heretter ''spec'') ble skrevet.  Det vil ofte være en viss kostnad forbundet med å endre på design og legge til nye features underveis - men i mange tilfeller vil endringene som foreslås medføre en vesentlig heving av produktkvaliteten.
+
Programvareutvikling kan heller ikke sammenlignes med f.eks. å bygge en bru.  En bru er en typisk ting hvor man først lager byggeplaner ned i den minste detalj og så bygger brua.  Programvareutvikling behøver ikke være slik - i løpet av utviklingen vil det som regel dukke opp mange nye idéer, behov og problemstillinger som man ikke tenkte på (eller som ikke var aktuelle) da kravspesifikasjonen ble skrevet.  Det vil ofte være en viss kostnad forbundet med å endre på design og legge til nye features underveis - men i mange tilfeller vil endringene som foreslås medføre en vesentlig heving av produktkvaliteten.
  
 
==== Forslag: Kontrakter må legges opp til dialog underveis ====
 
==== Forslag: Kontrakter må legges opp til dialog underveis ====
Linje 70: Linje 70:
  
 
* Tobias Brox
 
* Tobias Brox
 +
* [[user:Vegard Solheim | Vegard Solheim]]
  
 
== Motstandere ==
 
== Motstandere ==
Linje 82: Linje 83:
  
 
* Tobias Brox: ja, helt klart!  Dette er absolutt kjernepolitikk!
 
* Tobias Brox: ja, helt klart!  Dette er absolutt kjernepolitikk!
 +
* [[user:Vegard Solheim | Vegard Solheim]]: Uten tvil! Dette er rein Piratpolitikk, og om vi kan tvinge det offentlege til å bruke open source er det ein enorm bonus.
  
 
[[Category:Forslag]]
 
[[Category:Forslag]]

Revisjonen fra 1. des. 2021 kl. 11:19

Offentlig programvareutvikling på anbud medfører svært ofte ekstremt kostbare prosjekter hvor sluttresultatet i beste fall er halvgodt, men sjeldent bra. Vi nevner i fleng Flexus (Oslos elektroniske billettsystem), AltInn og NAVs datasystemer som skrekkeksempler. I tillegg til at det koster mye og at resultatet blir halvgodt, blir koden svært sjeldent offentliggjort, og i mange tilfeller sitter produsenten praktisk talt på enerettigheter til å vidreutvikle produktet - leverandøren får bokstavelig talt et sugerør inn i statskassa.

Forslaget er at man må reformere prossessene rundt utvikling av offentlig programvare, her er noen konkrete tanker:

  • All kode utviklet på offentlig anbud må frigis som åpen kildekode.
  • Mange korte, små prosjekter er bedre enn noen få store prosjekter. Med åpen kildekode er det i allefall teoretisk mulig å ha åpne anbudsrunder på vidreutvikling av eksisterende programvare.
  • Alt av offentlige anbud bør ut på offentlig høring for å få til en best mulig kravspesifikasjon (heretter spec).
  • Kontraktene må legge opp til fleksibilitet og bruk av "agile"-metodikk.

Disclaimer

Forslagsstiller har lite kjennskap til anbudsprossesser og utvikling på kontrakt for det offentlige - kommentarer og konstruktive endringer er velkommen!

Denne artikkelen ble lang, det ble mange delforslag, og det var vanskelig å følge forslagsmalen - jeg kommer antageligvis til å splitte dette opp i separate forslag.

Årsaker til at offentlige IT-prosjekter er pengesluk

Reglene rundt offentlige anbud er lite egnet for programvare - de fungerer nok bedre for bruer, maskiner og bygninger enn for programvare.

Vidreutvikling

Programvareutvikling kan ikke sammenlignes med en maskin som skal avskrives i løpet av fem år og så byttes ut. Programvare er noe som krever kontinuerlig vedlikehold og videreutvikling, og det er ofte svært dyrt å bytte ut programvare - både pga kostnad med datakonverteringer, motvillige ansatte som må kurses. Ofte kan nye mål realiseres ved å vidreutvikle eksisterende programvare. Det bør være innlysende at åpen kildekode er helt nødvendig for at man skal kunne ha åpne anbudsrunder for vidreutvikling og vedlikehold.

Dårlig spec

Manglende bestillingskompetanse

Det kreves en ekstremt god bestillingskompetanse for å skrive en god kravspec. Man må ha god kjennskap til faget og rutiner, men man må også ha god teknisk innsikt, og en viss nese for hva fremtiden vil bringe. Dersom en domeneekspert på gamle papirrutiner skal skrive en spec, ender man fort opp med en digitalisering av eksisterende manuelle rutiner. I stedet for en søkeknapp ber man kanskje om en alfabetisert liste slik at det skal være lett å bla seg frem til riktig rad, etc.

Manglende dialog mellom bestiller og leverandør

Mens spec blir skrevet, og når anbudet er blitt lagt frem, så skal ikke potensielle leverandører ha noen mulighet til å påvirke resultatet - og det gir jo litt mening at f.eks. en bussleverandør ikke skal fortelle Ruter at idéell busslengde ligger mellom 18.74 og 18.75 meter. Det er imidlertid ikke uvanlig at en leverandør sitter på bedre bestillerkompetanse enn bestiller - og dette gjelder kanskje i særdeleshet når det kommer til programvareutvikling. Spec' og anbud har som hovedregel stor fordel av å være utsatt for offentlig diskusjon - og når det kommer til programvare er det særdeles viktig at leverandørenes tanker, idéer og synspunkter blir hørt og tatt hensyn til. Dersom det skjer på en transparent, åpen og rettferdig måte bør det ikke være noe problem i dette.

Endringer underveis i kravspek

Programvareutvikling kan heller ikke sammenlignes med f.eks. å bygge en bru. En bru er en typisk ting hvor man først lager byggeplaner ned i den minste detalj og så bygger brua. Programvareutvikling behøver ikke være slik - i løpet av utviklingen vil det som regel dukke opp mange nye idéer, behov og problemstillinger som man ikke tenkte på (eller som ikke var aktuelle) da kravspesifikasjonen ble skrevet. Det vil ofte være en viss kostnad forbundet med å endre på design og legge til nye features underveis - men i mange tilfeller vil endringene som foreslås medføre en vesentlig heving av produktkvaliteten.

Forslag: Kontrakter må legges opp til dialog underveis

Det er vanskelig å finne en balansegang mellom rettferdige og reelle anbudsrunder og mulighet for gjensidig påvirkning underveis i utviklingsprossessen - men man skal ikke undervurdere viktigheten i det siste.

Motivasjon hos utviklere

Gode utviklere og programvaredesignere vil ha meninger rundt spec'en er, og de vil ha idéer og forslag til forbedringer. Dersom spec'en er gjennområtten og man ikke har noen mulighet til å påvirke sluttresultatet, så er det ekstremt demotiverende. Gode utviklere skyr slike jobber. Resultatet er at man er nødt til å sette inn overbetalte halvgode programmerere i stedet.

Manglende forståelse og kursing av sluttbruker

Kanskje den som skrev spec'en hadde noen gode idéer - men den jevne sluttbruker skjønner ikke hvordan det fungerer. De skjønner ikke hvordan man bruker funksjonaliteten for "digital signering", de vil fortsatt skrive ut dokumenter, stemple dem og scanne dem inn igjen, og skjønner ikke hvorfor det er så vanskelig i den nye programvaren.

Diskusjon

Fordeler med forslaget

Når man ser på mye av det som foregår innenfor "offentlig IT" er det ganske opplagt at det må gjøres noen grep.

Ulemper med forslaget

Problemstillingene rundt offentlige anbud er komplekse, og mange av reglene er skrevet for å unngå korrupsjon. Man skal være veldig forsiktige med å gjøre for mange endringer.

Andre tanker

...

Se også

Mailtråd på mailinglista med subject "Alpha utkast partiprogram PPUK".

Avstemning

Støttespillere

Motstandere

(ingen så langt)

Agnostikere

(ingen så langt)

Bør piratpartiet mene noe om dette?

  • Tobias Brox: ja, helt klart! Dette er absolutt kjernepolitikk!
  • Vegard Solheim: Uten tvil! Dette er rein Piratpolitikk, og om vi kan tvinge det offentlege til å bruke open source er det ein enorm bonus.