Det er lett å lese om ny teknologi og få følelsen av at man burde gjøre noe. Det er sjeldnere klart hva.
Vår erfaring er at de fleste bedrifter ikke taper på å vente med ny teknologi. De taper på å bygge løsninger som gjør det vanskelig å ta den i bruk senere. Samtidig finnes det områder der kunstig intelligens allerede har gitt en konkret gevinst, og de handler overraskende nok om kvalitet framfor hastighet. Vi tar det som allerede virker først, og det som er på vei etterpå.
Testing er blitt noe som faktisk blir gjort
Automatiserte tester er kode som sjekker at appen fortsatt fungerer. Når en utvikler endrer noe ett sted, kjøres testene, og hvis noe annet gikk i stykker, oppdages det umiddelbart framfor av en bruker tre uker senere.
Alle er enige om at dette er riktig. I praksis har det likevel vært det første som ryker når en frist nærmer seg, fordi det er kjedelig arbeid som ikke gir noe synlig.
Her har verktøyene gjort en reell forskjell. Å skrive tester for de mange kjedelige tilfellene, altså tomme felter, uventede verdier, feil rekkefølge, er nettopp den typen forutsigbart arbeid assistenter er gode på. Når terskelen går ned, blir det faktisk gjort.
For dere som kunde betyr det færre feil som når fram til brukerne, og at endringer etter lansering er tryggere å gjøre. En løsning med god testdekning er billigere å videreutvikle, fordi utviklerne tør å endre ting. Det er likevel verdt å merke seg at tester ikke erstatter det å prøve appen selv. En test sjekker at koden gjør det den ble bedt om, ikke at det var riktig ting å be om.
Sårbarheter oppdages raskere
En moderne app bygger på et titalls biblioteker skrevet av andre. Når det oppdages en sikkerhetsfeil i ett av dem, må appen oppdateres.
Dette har tidligere krevd at noen fulgte med. I dag overvåkes avhengigheter automatisk, og varsler kommer når noe må rettes, gjerne med forslag til hvilken versjon som løser problemet. Verktøyene er blitt merkbart bedre til å vurdere hvor alvorlig noe er, og om det faktisk berører måten appen bruker biblioteket på.
Effekten for dere er at sikkerhetsoppdateringer skjer raskere og med mindre manuelt arbeid. Det forutsetter at noen har ansvar for å følge opp varslene, noe som er en av grunnene til at vedlikeholdsavtaler er verdt pengene.
Det disse verktøyene ikke løser
De finner ikke feil i forretningslogikken. Hvis appen regner feil fordi kravene var uklare, sier ingen test fra, for testen er skrevet ut fra de samme kravene.
De finner heller ikke problemer med hvordan tilganger er satt opp. At en bruker kan se data de ikke skulle hatt tilgang til, er en av de vanligste og alvorligste feilene i forretningsapper, og den avdekkes ved at noen tenker gjennom rollene, ikke av et verktøy.
Og de erstatter ikke det å teste med ekte brukere. En app kan være helt feilfri og likevel ubrukelig.
Det som faktisk er på vei
Modeller som kjører på selve telefonen er den utviklingen som sannsynligvis betyr mest for apper de nærmeste årene. Både Apple og Google har lagt inn maskinlæring i operativsystemene sine, og det betyr at enkelte oppgaver kan gjøres uten å sende data ut av enheten.
Det har to konsekvenser som er interessante. Personvernmessig blir en del ting enklere, fordi dataene ikke forlater telefonen. Og driftskostnaden forsvinner for de oppgavene det gjelder, siden dere ikke betaler per forespørsel til en ekstern tjeneste. Begrensningen er at modellene på enheten er mindre og mindre kapable enn de store. De egner seg til avgrensede oppgaver, ikke til å erstatte en fullverdig assistent.
Den andre utviklingen er systemer som utfører oppgaver framfor bare å svare på spørsmål. Dette er fortsatt umodent i praksis, og vi anbefaler forsiktighet: et system som handler på egen hånd i en forretningsapp må ha kontroller rundt seg som ofte koster mer å bygge enn funksjonen selv.
Hvorfor det sjelden lønner seg å være først
Ny teknologi er dyrest i starten. Verktøyene er umodne, dokumentasjonen er tynn, og det finnes få som har gjort det før. Dere betaler for å være dem som finner ut av det.
Er dette kjernen i produktet deres, kan det være verdt det. Er det en funksjon blant mange, er det som regel bedre å vente til bruksmønstrene er etablert og kostnadene har falt. Vi har skrevet om hvordan dette slo ut sist i de største trendene i apputvikling, der flere av de mest omtalte teknologiene aldri ble tatt i bruk i vanlige prosjekter.
Valgene som holder mulighetene åpne
Dette er den praktiske delen. Det finnes noen grep som koster lite i dag og som gjør det billig å ta i bruk nye ting senere.
Hold logikken samlet på serversiden framfor spredt utover i appen. Når reglene for hvordan noe fungerer bor ett sted, kan dere endre hvordan de utføres uten å røre appen, og uten å vente på Apples godkjenning.
Sørg for at dataene deres er tilgjengelige i en form som kan leses maskinelt. Det er nesten alltid datagrunnlaget, ikke teknologien, som avgjør om dere kan ta i bruk noe nytt. En bedrift med ryddige data kan komme i gang på uker. En med alt i PDF-er må gjøre jobben først.
Unngå å bake en bestemt leverandør dypt inn i løsningen. Snakker appen med en ekstern tjeneste gjennom et tydelig avgrenset lag, er det en overkommelig jobb å bytte. Er kallene spredt utover hele kodebasen, er det ikke det.
Og hold avhengighetene få. Hver tredjepartspakke er noe som må følges opp, og en app med mange av dem er tyngre å oppdatere når plattformene endrer seg.
Det som ikke endrer seg
Uansett hvilken teknologi som kommer, vil de samme tingene avgjøre om et prosjekt lykkes.
Omfanget må være avgrenset nok til å komme i mål. Noen hos dere må kunne ta beslutninger raskt. Og dere må se noe som virker underveis, framfor å lese statusrapporter. Brukerne kommer heller ikke til å bry seg om hva som kjører under panseret. De bryr seg om at det de kom for å gjøre går fort.
Hva du bør spørre en leverandør om
Spør om løsningen har automatiserte tester, og hva de dekker. Svaret bør være mer konkret enn ja.
Spør hvordan sikkerhetsoppdateringer i avhengigheter håndteres, og hvem som følger opp varslene. Og spør hvem som har tenkt gjennom hvem som skal ha tilgang til hva. Det er et spørsmål om design, ikke om verktøy, og det bør ha et navn knyttet til seg.
Spør til slutt hvordan løsningen er bygget for å kunne endres. Er logikken samlet og dataene tilgjengelige, står dere godt rustet til å ta i bruk noe nytt når det er modent. Det er en bedre strategi enn å gjette riktig nå.
Vi har skrevet mer om hvordan vi bruker slike verktøy i praksis i slik bruker vi KI i utviklingsarbeidet. Vil du diskutere kvaliteten i en løsning dere har, eller hvordan dere bør bygge for å holde mulighetene åpne? Se hvordan vi jobber med apputvikling og webapplikasjoner, eller ta kontakt.