^{Publisert: 21.06.2022
Skrevet av: Francisca Concha}

For å markere utrullingen av et nytt fagsystem vi har utviklet sammen med bruktbilkjeden MyCar, har jeg samlet noen refleksjoner rundt mitt første samarbeid som UX designer i Avo med vårt tjenesteområde Rapid App Development (RAD). Full avsløring: Før jeg startet i Avo hadde jeg aldri jobbet i prosjekter drevet av lavkodeutvikling og smidig prosjektmetodikk. Tvert imot, jeg hadde erfaring med prosjekter drevet av en tradisjonell fossefall-metodikk, der designere jobber nesten isolert fra utviklere frem til overlevering av skisser. Før jeg visste ordet av det var jeg den eneste designeren i et helt nytt RAD-prosjekt – noe som betyr raskere utvikling enn hva jeg var vant til. Hvordan skulle jeg takle et mye høyere tempo og samtidig få det beste ut av samarbeidet i et nytt team?

I denne artikkelen deler jeg noen tanker om hvordan vi har jobbet med lavkodeutvikling, samt noen refleksjoner rundt den omstillingen vårt team har gått gjennom for å sikre en smidig prosess.

Vi i Avo er egenerklærte “teknologi-agnostikere” – vi låser oss ikke fast i spesifikke teknologier for å løse et problem. Etter et halvt år involvert i dette prosjektet vil jeg påstå at vi også er “metodikk-agnostikere”. Ved å hente inspirasjon fra Agile, Lean, UX og Scrum, har vi funnet vår egen tilnærming til smidig utvikling underveis i prosjektet – uten å henge oss opp i definisjoner. Det som har stått i fokus hele veien, er å ferdigstille et fungerende produkt som viser at vi sitter på evnen og verktøyene til å løse kundens smertepunkter raskt og trygt.

Lavkode, lav risiko

Vi er et kjerneteam på syv personer (fire utviklere, en teknisk arkitekt, en forretningsutvikler og en designer) som har jobbet sammen i dette prosjektet. Oppdraget vi fikk var å erstatte systemet kunden bruker til daglig drift med en løsning som tilrettelegger for en stadig mer digitalisert kundereise i bilbransjen. Kunden ønsket en omfattende satsing, samtidig som de forsto at oppgaven innebar en stor risiko. Lavkodeutvikling reduserer denne risikoen med rask tidslinje fra idé til fungerende applikasjon.

Prosjektet har vært delt opp i kvartaler med kortvarige faser på 2-3 uker, noe som vi kaller for sprinter. Hver sprint starter med å prioritere hvilke oppgaver vi skal gjennomføre og avsluttes med en demo. På slutten av kvartalet får kunden mulighet til å vurdere progresjonen. Muligheten til å avslutte oppdraget uten forbehold har de også på dette tidspunktet. Det er altså ikke stort rom for hverken sløseri eller misforståelser fra vår side. Vi må jobbe samkjørt for å sikre at kunden vil velge oss om og om igjen.

Vi jobber tett sammen – på ekte

Rollene i dette prosjektet oppleves mer flytende enn andre prosjekter jeg har vært involvert i tidligere. Dette har vist seg å fungere bra så lenge alle har eierskap til prosessen, målet og resultatet . En viktig årsak er at vi utelukkende bruker verktøy som tilrettelegger for samhandling. Blant de viktigste er Jira for oppfølging og prioritering av oppgaver og omfang, Miro for koordinering og innsamling av innspill, Figma for design og Appfarm for lavkodeutvikling. Med et slikt opplegg er det ikke sjeldent vi ser utviklere prøve seg som designere og forretningsutviklere som kodere, samtidig som alle “pusher” piksler. Vi utfordrer og støtter hverandre, og lærer utrolig mye av hverandres fagområder.

Byråkrati og smidig utvikling er ikke gode venner. _{Francisca Concha}

En annen faktor som har vist seg å være helt avgjørende for å sikre en god prosess er kunden sin involvering i prosjektet. Det er en forutsetning i smidig produktutvikling å kunne ta beslutninger hyppig og veldig fort. Vi starter arbeidsdagen med vårt "daily scrum” – et 20 minutters møte der kjerneteamet pluss representanter fra kundens side forteller hva de holder på med. I tillegg har vi kontinuerlig dialog med kunden for å ta kjappe avklaringer i løpet av dagen. Dette er meget effektivt for oss, men krever at kunden har både tid og mandat til disposisjon. Byråkrati og smidig utvikling er ikke gode venner, så vi må sørge for å ha tilgang til de personene som kan ta de valgene som må til for å komme seg videre.

Samtidig som vi oppfordrer kunder til å tilslutte seg vår metodikk, streber vi etter å være en tilpasningsdyktig leverandør, blant annet når det gjelder rigg av teamet. Vi kobler inn de riktige ressursene til riktig tidspunkt - enten interne eller gjennom samarbeidspartnere. I perioder med ekstra trykk har for eksempel vår respons vært å oppskalere teamet.

Når design blir en flaskehals

Ingen morsomme oppdrag skal være uten utfordringer og det finnes et par jeg synes er spesielt verdt å nevne fra et design-perspektiv. Allerede før vi sparket i gang med prosjektet var jeg klar over en typisk utfordring andre opplever i våre RAD-prosjekter, nemlig at design oppfattes som en flaskehals i prosessen.

Å samle inn innsikt fra ekte brukere er en tidkrevende prosess som kan gjøre at teamet ser seg nødt til å skifte konsept og begynne på nytt på noen funksjonaliteter i systemet. Samtidig er det viktig å sikre at vi tar hensyn til den reelle konteksten brukerne jobber i. Dermed har vi større sjanse til å oppdage kritiske forutsetninger for bransjen. De fleste som jobber med brukeropplevelser vet at man aldri stopper å finne ut nye ting om brukernes atferd – så jo tidligere teamet kommer i gang med innsiktsarbeid jo bedre er det for sluttresultatet.

Mitt team har testet ut parallelle løyper i prosessen, der det konseptuelle arbeidet og innsamling av innsikt gjerne ligger 1-2 uker i forkant av produksjonen som foregår i Appfarm. Når designer og forretningsutviklere – altså vi som jobber tettest med konseptskisser – føler vi sitter på et godt nok grunnlag til å lage en første utgave eller iterasjon, tar utviklerne over den oppgaven. Mens de setter opp funksjonalitet går vi videre til neste steg i løypen. Erfaring vi har opparbeidet gjennom prosjektet har lært oss at denne fremgangsmåten er mest effektiv og gir de beste resultatene. For det har vært situasjoner der vi har hoppet rett inn i utvikling av funksjonalitet og likevel endte opp med mye tid brukt på rette opp feil forårsaket av antagelser.

Fra makro til mikro og tilbake

Å være den eneste designressursen i et slikt prosjekt innebærer å stadig jobbe med oppgaver som pågår på ulike aggregeringsnivåer. På den ene enden har man typiske oppgaver for en UX-rolle, der designeren bidrar til å synliggjøre helhetsbildet og skape en logisk arbeidsflyt i et system. På den andre enden skal man ta stilling til spesifikke detaljer på størrelser og farger for å sørge for brukervennlige grensesnitt. Da er det fort gjort å skifte fokus fra den ene enden til den andre flere ganger i løpet av en dag. Dette i sin tur pleier å gå ut over produktiviteten. Kontekstbytting kan oppleves som en reell utfordring til tider, spesielt når man jobber i parallelle prosjekter for andre kunder. Til tross for dette er mangfold av kundesektorer og oppdrag etter mitt syn noe av det morsomste ved å være designer i Avo.

Så hvordan lære seg å håndtere den kognitive belastningen som det medfører å stadig bytte fokus, som hverken er synlig for andre eller målbar? Dele opp dagen i blokker, dempe ulike kanaler man ikke bruker den dagen og avtale sparringsrunder med kolleger i kalenderen er eksempler på tiltak, men kanskje viktigst av alt er å si ifra til teamet og sammen tilpasse mengde eller type oppgaver. Man trenger ikke prøve å løse alt på egen hånd.

Viktige læringspunkter:

• Ikke hopp over den første fasen med UX arbeid: Ofte oppfattes denne fasen som en flaskehals fordi det går mer tid før utviklingen starter. Velger du imidlertid å hoppe over denne fasen, risikerer du likevel å måtte bruke den tiden senere for å fikse problemer – hvis ikke mer tid.
• ‍Smidig utvikling kan ikke lykkes uten engasjerte kunder: Kundens kontaktperson må ha kapasitet og mandat til å bistå daglig med avklaringer og innsikt. Hvis ikke kan det fort bli mange runder med oppfølging som spiser opp tid i prosjektet
• Si ifra tidlig: Prosjekter der vi bruker lavkodeverktøy har et høyt tempo og de krever ofte å ha mange baller i luften samtidig. Du må da tørre å si ifra når forventningene ikke lenger er realistiske. Det er tross alt vanlig innen smidig prosjektmetodikk å inngå kompromisser.

Vi jobber fortsatt med å legge til seksjoner og funksjonalitet i systemet og dermed vokser også kompleksiteten. Veien videre er å sørge for å opprettholde den tette dialogen vi har hatt med kunden frem til nå. Mindre tid brukt på utvikling gir oss en enorm fordel fordi den tiden vi sparer der kan brukes til å ta bedre informerte valg. Vi bruker mindre tid på hvordan løse problemer og heller mer på hvorfor.

Klar for å starte din reise med utvikling innen No-Code?

Vi hadde nylig et webinar med Appfarm og MyCar Group om hvordan en kan starte reisen med å utvikle med no-No-Code. Vi var innom temaer som:

• Hva er No-Code og hvordan fungerer det?
• Hvorfor bør du gjøre No-Code til en del av strategien din?
• Kundehistorie: Å utvikle et helt nytt produkt uten å bruke kode

Se gjerne på webinaret her.