Norkart Sommer – Lillehammer 2023
Fra venstre: Emil, Even, Marianne og Maren
Sommerstudentene på vårt Lillehammerkontor fikk i oppgave å se på en løsning for bedre arbeidsflyt for renovasjonsarbeidere i felt. Hva er deres største utfordringer i arbeidshverdagen, og hvilke verktøy kan vi forbedre og utvikle for å bidra til enda bedre flyt i oppgavene?
Introduksjon
Denne sommeren har vi fått muligheten til å prøve oss på et prosjekt i regi av Norkart Sommer, avdeling Lillehammer. Her fikk vi utgjøre et eget team bestående av fire sommerstudenter. Tre av sommerstudentene har bakgrunn fra NTNU Gjøvik hvor Maren nettopp er ferdig med en bachelorgrad i Interaksjonsdesign, Marianne begynner på siste året på en bachelor i webutvikling og Even begynner siste året på en bachelor i programmering. Emil er midt i et studieløp på NTNU Trondheim hvor han fullfører en master i industriell matematikk.
Med utgangspunkt i oppgaven om å utvikle en webløsning, ble det rom for en naturlig rollefordeling innad i teamet. Maren fikk ansvar for innhenting og bearbeiding av innsikt fra brukere og å designe et nytt brukergrensesnitt. Marianne fikk ansvar for utviklingen av applikasjonens front-end. Even fikk ansvar for utviklingen av API, som utgjør applikasjonens back-end. Til sist, fikk Emil ansvar for å få innsikt i dataene vi hadde tilgjengelig, bearbeide dataen og se på mulighetene for å trene en KI-modell ut ifra dette.
Prosjektet
Oppgaven vår var å jobbe med en ny feltløsning for renovasjonsarbeidere. Dette har innebåret å sette seg inn i arbeidshverdagen til en renovasjonsarbeider så langt det har latt seg gjøre. For å innhente denne innsikten har vi hatt intervjurunder hvor vi har fått snakke med ulike kunder av renovasjonstjenester levert av Norkart, og fått høre om problemstillinger de har i dag knyttet til teknologiene de benytter seg av. Vårt prosjekt har dermed handlet om å utvikle en ny webapplikasjon som kan løse noen av problemstillingene de ulike kundene kom med.
For å ha en realistisk plan for hvor mye vi fikk utrettet på 6-7 uker, innsnevret vi problemstillingene til følgende: Hvordan kan avviksregistrering og beholderarbeidsliste samles i en løsning som er brukervennlig? Webapplikasjonen skulle kunne vise kjøreruter for tømminger og kjøreruter for arbeidslister (innhenting og utplassering av beholdere). Kunne registrere avvik på tømminger og kvittere tømminger og arbeidslister som utført. Når vi arbeidet med dette fokuserte vi også på et brukervennlig grensesnitt med respons i appen for at renovatører skulle unngå feilregistreringer i felt.
Maren og Even diskuterer løsninger
Teknologi
Appen er en progressiv webapplikasjon utviklet med ReactJS, som gjør den til en nedlastbar, plattformuavhengig app. PWA teknologien åpner også for muligheten til å implementere ulike fordeler som blant annet offline funksjonalitet og opplevelsen av at appen laster data raskere.
API-et er et .Net API som bruker EntityFramework og Linq for å sende spørringer mot databasen, en anonymisert kopi av RiG sin KOMTEK-database. API-et i seg selv er ganske enkelt, men spørringene den gjør mot databasen har krevd en del arbeid for å finne ut hvilke tabeller som inneholder hvilken informasjon.
Løsningens brukergrensesnitt følger Norkarts designsystem, og er universelt utformet. Designet er utformet slik at brukeren har tilgang til nødvendig informasjon ved få tastetrykk. Løsningen ble utformet i designprogrammet Figma, hvor det er mulig å prototype slik at løsningen kan testes med alle funksjoner før løsningen er kodet og programmert. Det er også designet for toveiskommunikasjon mellom renovatør i felt og på kontor. Samtidig er det mulig for renovasjonsarbeideren å rette opp i feil, dersom et avvik skulle bli feilregistrert.
Kundene som samler inn vektdata ønsker at dataen skal være så fullstendig som mulig, og uten åpenbare feilregistreringer. Som et ledd i å oppdage feilregistreringer, enten det er feilregistrerte beholdere, ødelagte sensorer eller feilsortering av avfall, har vi implementert en outlier-detektor. En outlier er et datapunkt som skiller seg signifikant fra de andre datapunktene i en populasjon. Vår modell benytter Median absolute deviation som et mål på populasjonsvarians, fordi den, i motsetning til utvalgsvarians/standardavvik er robust mot outliers. Det er en statistisk læringsmodell som ikke krever mye datakraft, og er god på å detektere outliers i univariat data. Modellen ble implementert i Python, det ble i tillegg implementert et enkelt API i Flask slik at når .NET-APIet får en tømming fra klienten vil nødvendig data for å trene modellen bli hentet fra databasen og oversendt til Flask APIet sammen med den nye tømmingen. Beregningen gjøres og resultatet sendes tilbake til .NET-APIet som oppdaterer tømmingen i databasen.
Arbeidshverdagen
I løpet av sommeren har vi fått jobbe fulltid på Lillehammer kontoret til Norkart i 6-7 uker. I løpet av denne perioden hadde vi møte med veiledere hver mandag for å planlegge uken og bestemme/avklare ukens arbeidsoppgaver. På slutten av hver uke hadde vi oppsummeringsmøte med veiledere, hvor vi sammenlignet hva vi faktisk fikk utrettet av de oppgavene vi satte for oss selv på mandagsmøtet tidligere i uka.
Fordi alle team-medlemmene har hatt egne spesifikke ansvarsområder, har arbeidet med prosjektet i tiltagende grad vært individuelt. I startfasen hadde vi en del møtevirksomhet: med ressurspersoner i Norkart, såkalte Discovery-møter hvor vi fikk innsikt både i hvordan Norkart har jobbet med renovasjonsfeltet tidligere og hvilke løsninger de allerede tilbyr, men også i hvordan et typisk KOMTEK-produkt ser ut og fungerer på et teknisk nivå; med kunden, Renovasjon i Grenland, for å kartlegge deres erfaringer, ønsker og behov; og sist men ikke minst hadde teamet mange planleggingsmøter der vi diskuterte problemstillingen, utfordringer og løsninger for å finne et så godt design som mulig for produktet.
Ettersom designet utkrystalliserte seg og det ble tydeligere hva som måtte implementeres for å realisere det, både teknisk, designmessig og i form av innsiktsarbeid, ble det gradvis mer og mer selvstendig arbeid. Likevel har appen og API-et blitt utviklet parallelt, og selv om kodingen har foregått individuelt, har utformingen av begge elementene vært et samarbeid. Med parallell utvikling av design, app og KI-materiale har vi fått stabile utgangspunkter som viser til realiseringspotensiale til produktet for videre utvikling og integrering.
Vi ble oppfordret i starten til å pusse litt på foosball ferdighetene, for å se om vi etter hvert kunne slå noen av de faste på kontoret. Imidlertid falt forkjærligheten til teamet for et annet spill, Klask. Klask ble vår desidert største teambygging strategi denne sommeren, men vi så oss etter hvert nødt til å ta opp tråden med foosball igjen mot slutten av perioden for å i det hele tatt ha noe sjans mot konsulentskuddene.
Avsluttende tanker
Denne sommeren har vi fått lov til å se hvordan teorier og metoder vi har lært om på våre respektive studier utspiller seg i arbeidslivet. Vi har også fått erfare noen av effektene av et godt in-house miljø på kontoret på Lillehammer som vi tar med oss videre. Vi har lært at det er viktig å holde tungen rett i munnen når man skal inn i en ny verden av terminologier, og like viktig, om ikke enda viktigere, at teamet har en felles forståelse av denne terminologien. Diskusjoner om hva en kjøreplan egentlig betyr og om tømmeliste, og om bestillinger egentlig var del av arbeidslister, har virkelig holdt oss påskrudd gjennom arbeidsdagen.
Vi fikk jobbet mye selvstendig som et team som er blitt muliggjort, takket være Norkarts ressursbase. Vi har hatt Norkart APIer, designsystemer og andre hjelpemidler lett tilgjengelig hele veien. Vi utviklet for eksempel front-end i Monorepoet som gjorde det veldig enkelt å benytte seg av ressurser som allerede var importert inn i Monorepoet. Læringsutbytte av dette er at produksjon i arbeidslivet ikke handler om å finne opp hjulet på nytt, noe som gir rom til å benytte tiden til å forbedre kvaliteten på produktene som utvikles i stedet.
Lignende erfaringen med Monorepoet, var det fordelaktig å jobbe med Toitsu, Norkarts designsystem, hvor alle nødvendige grafiske komponenter lå klare til bruk og oppgaven var å sette sammen puslespillet. Denne metoden å jobbe på sparer en hel del tid og tillater oss å fokusere på andre utfordringer ved et brukergrensnitt, som for eksempel universell utforming.
For backend-utviklingen har kanskje arbeidet med databasen vært det mest overraskende og lærerike. Kopien av RiG-databasen vi har lekt med inneholder et hundretalls tabeller og flere millioner tupler, mens man i skolesammenheng ofte jobber inn mot SQL-databaser med 5-6- tabeller og noen titalls tupler. Da sier det seg selv at arbeidet vi har gjort inn mot databasen i sommer er av en annen størrelsesorden når det gjelder kompleksitet, og mye tid har gått med på å stirre på tabeller og lure på hvordan systemet henger sammen. Gleden er selvfølgelig tilsvarende stor når spørringene blir riktige og man får kodet et system som knytter sammen frontend med reelle data.
Alt i alt, har vi hatt en innholdsrik sommer som har vært utfordrende og gøy å få være med på! Med dette vil vi takke Norkart for god veiledning, utallige foosball-turnerninger og aller mest en spennende og lærerik sommer!