Programvareanbud

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.

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

 * Tobias Brox
 * Vegard Solheim
 * Øyvind A. Holm
 * Erikwt

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.
 * Øyvind A. Holm: Helt klart. Dette bør være en av kjernesakene.
 * Bård Ove Kopperud : Åpenbart.