Prosjektet Nasjonal reiseplanlegger er et offensivt offentlig prosjekt med masse kompleksitet og, ikke minst, stor innvirkning på alle landets kollektivselskaper som produserer data og betjener kollektivtilbudet. De færreste hadde antakelig reagert nevneverdig hvis prosjektet hadde ramlet sammen lenge før mål. Det har skjedd tidligere, men ikke her, og prosjektets tilnærming er kanskje noe av forklaringen?
Nasjonal reiseplanlegger ble etablert etter ønske fra Regjeringen om å utvikle en komplett reiseplanlegger for all kollektivtransport i Norge. Fra april 2017 ble det flyttet inn i Entur, et statlig selskap under Samferdselsdepartementet, der løsningene har blitt videreutviklet.
«Reisesøk-as-a-Service, til egne webber og apper, og Staten tar regningen.»
Prosjektet har arbeidet under en frisk målsetning og med en enda friskere ambisjon: Å samle inn all tilgjengelig kollektivdata og tilby disse åpent ut igjen, kvalitetssikret og harmonisert. I tillegg har prosjektet tatt mål av seg å tilby et åpent reisesøk-grensesnitt (API) som offentlige og private skulle kunne plugge seg på, og lage eller berike egne tjenester. Reisesøk-as-a-Service, til egne webber og apper. Og Staten tar regningen, som del av moderne infrastruktur.
Positiv oppmerksomhet i norske medier viser at Entur leverer på hjemmebane. I tillegg er satsningen godt mottatt ute i verden. Sverige og Danmark vurderer å ta i bruk hele eller deler av “tjenesteriggen” i sine nasjonale løsninger. Frankrikes store vinregion, Nouvell Aquitane med 6 millioner innbyggere, har allerede satt løsningen i produksjon og bidradd med pull-requester. Og til våren er Entur vertskap for communitien til den internasjonalt utbredte reisesøkmotoren for kollektivtransport, OpenTripPlanner (OTP), en løsning Entur har engasjert seg godt og grundig i.
Og dette er kjernen: Et offentlig prosjekt basert på egenutvikling, Open Source, deling og åpenhet har lykkes. Først litt om bakgrunnen til dette, så litt om hvorfor dette ser ut til å gå rett til hjertet på dagens utviklere - og hva vi kan lære av det.
«OK Google, kan jeg sykle til jobb i dag?»
Slik lagde han sin egen Google Assistant-app for Bysykkel.
Prosjektmandatet i reiseplanleggerprosjektet nærmest ropte på Open Source og egenutvikling. Årsakene til dette er flere.
Kollektivtrafikk er en offentlig subsidiert bransje der mange parter søker samarbeid både på lokalt, nasjonalt og internasjonalt nivå, og der deling av programvare faller naturlig. Nærmest “alle” land jobber med reiseplanleggere på kollektivtransport, og de færreste motiveres av å finne opp kruttet på nytt og på nytt. Dermed er det åpenbart at slike prosjekter potensielt kan «gi tilbake» mye mer enn bare data. Programvare som server tjenester vil potensielt være interessant i seg selv, for deling og videreutvikling. Slik har det også blitt.
En annen viktig gruppe faktorer er at reiseplanlegging, og gjerne i kombinasjon med mobilitetsløsninger, er et område i sterk utvikling. Her er det ofte vanskelig å forutse utviklingen, men du vet du har behov for å “snu deg” når ting skjer. Rask respons og evne til smidig tjenesteutvikling blir essensielt, og i en verden av stor og plutselig endring blir umiddelbar oversikt og innsikt vesentlig. “Black Box” vil rett og slett ikke fungere, da manglende kontroll over datagrensesnitt og kode fort gjøre at datakvalitet utilsiktet kan bli forringet. Og i en nasjonal reiseplanlegger, med utallige datakilder og kontinuerlige dataflyter, er det datakvaliteten som definerer slutttjenesten.
Fra mitt perspektiv som team-lead og prosjektleder danner dette et viktig bakteppe for mitt andre og store spørsmål: Hvorfor har prosjektet gått rett til hjertet på utviklerne og hva vi kan lære av dette?
Min første tanke er at utviklere liker Open Source fordi det gir bedre kode. Forklaringen er antakelig enkel. Når utviklere jobber med Open Source er min oppfatning at man i fellesskap og implisitt «presser frem» bedre kodekvalitet. Koden ligger åpent tilgjengelig og skal gjenbrukes av andre. Dette disiplinerer, og ekstra oppmerksomhet betaler seg ved å bli møtt med samme høye krav fra andre i teamet som du stiller til deg selv. At dette samtidig hindrer at raske eller enkle “snarveier” sniker seg inn i løsningen, kan fort spare deg og prosjektet for opphoping av teknisk gjeld. Dette liker utviklere.
Norske utviklere jobber dårligst i åpent landskap
kode24 har undersøkt, og tallene overrasker ikke ekspertene.
Et annet element som løfter Open Source er at det er en selvstendig kilde til økt sikkerhet. Erfaringen viser at hver enkelt lettere fokuserer på å holde avhengigheter og rammeverk oppdatert. I praksis blir det slik at teamets enkeltmedlemmer systematisk sikrer hverandre bedre rammevilkår og dermed hever kvaliteten i prosjektet. Det blir det miljø, stolthet og tillit av.
Til slutt vil kryssfunksjonelle team der kode deles, med agile arbeidsprosesser og raske MVP-leveranser på dagesorden, gjøre det morsommere å gå på jobb. Det legger grunnlag for gode leveranser og resultater, og gjør Open Source til en utvikler-attraksjon som i et presset marked fort kan bli utslagsgivende. Skal du trekke til deg de beste folka, kan Open Source bli den store forskjellen.
Det åpne, transparente, selvregulerende ved Open Source er en morsom måte å jobbe. Dette trives utviklere med og skaper motiverte team. Noe som gir fokus på kodekvalitet, sikkerhet og raske leveranser. Ikke tro vi ikke har gjort noen tøffe lærdommer på veien. Og i likhet med alt annet innenfor systemutvikling, “there is no silver bullet”. Men det er mye å reflektere over her, og det store spørsmålet jeg sitter igjen med er: Kan det være sånn at høy frihetsgrad, som Open Source gir, egentlig er et must for å få vellykkede utviklingsprosjekter?
Og PS, for interesserte: All utviklet kode knyttet til innsamling, kvalitetssikring og eksponering av rute- og sanntidsdata, samt kode for reiseplanleggingslogikk, ligger åpent på www.github.com/entur. OTP finner du her: www.opentripplanner.org
