Måske har I allerede en portal, et administrationssystem eller en hjemmeside. Medarbejderne vil kunne se dagens opgaver på telefonen, tage billeder hos kunden og afslutte arbejdet med det samme. Det er et godt udgangspunkt — hvis I afklarer, hvad der skal virke i praksis, før I taler om skærme og funktioner.
1. Start med opgaven, ikke platformen
“Vi skal have en app” er en løsning, ikke en kravbeskrivelse. Beskriv i stedet én arbejdsdag: Hvem åbner appen? Hvilken opgave skal personen kunne se? Hvad sker der, når der tages et billede, et mål registreres eller en kunde beder om ændring? Og hvad skal kollegaen på kontoret kunne gøre med resultatet bagefter?
Den gennemgående prøve kan være en tekniker, der åbner en serviceopgave hos kunden. Hun skal se den rigtige adresse og opgavehistorik, udføre arbejdet, tilføje billeder og sende en status hjem. Hvis hun mangler forbindelse, skal I have aftalt, hvad der sker. Det er den type svar, der bestemmer arkitektur og test — ikke om knappen er grøn eller blå.
2. Hvad kan genbruges fra den eksisterende løsning?
En eksisterende løsning kan være et stærkt fundament, men den er ikke automatisk klar som mobilapp. Gennemgå data, login, rettigheder og den del af arbejdsgangen, som skal fungere på telefonen.
Den første version behøver ikke løse alt. Det kan være mere værdifuldt, at én type opgave kan afsluttes korrekt i felten, end at fem halvfærdige moduler ligger klar i menuen.
3. Afklar data, roller og ejerskab
Skriv ned, hvor oplysningerne bor, hvem der må se dem, og hvilke konti virksomheden selv skal have kontrol over. Det omfatter typisk domæner, hosting, kode, App Store Connect, Google Play Console og de tjenester, der håndterer data eller notifikationer. Leverandøren kan have den adgang, opgaven kræver; virksomheden bør kunne overtage løsningen.
Rettigheder skal testes som en del af løsningen: En montør må måske se sine egne opgaver, mens en driftsleder skal se hele virksomheden. Det er ikke en detalje til sidst. Det er en forudsætning for, at en app med kundedata kan bruges forsvarligt.
4. Test hele arbejdsdagen på rigtige telefoner
En skærm, der ser korrekt ud i en browser, er ikke nødvendigvis brugbar i felten. Test den samlede handling på de telefoner og systemversioner, I faktisk vil understøtte. Brug en aftalt testliste, så aflevering ikke bliver en mavefornemmelse.
- Login, log ud og de aftalte brugerroller fungerer.
- Brugeren ser kun de sager og filer, rollen giver adgang til.
- Kamera, notifikationer og afviste tilladelser håndteres forståeligt.
- Ændringer ved dårlig eller manglende forbindelse er afprøvet.
- Et link eller en notifikation åbner den rigtige opgave.
- Kontoret kan se det, der blev registreret i felten.
5. Test, udgivelse og drift er tre forskellige ting
Et testbuild er ikke det samme som en app, kunder eller medarbejdere kan hente. Udgivelse kræver blandt andet konti, korrekte metadata, adgang for review og et fungerende bagvedliggende system. Apple kræver, at en indsendt app er færdigtestet, at eventuelt login kan afprøves, og at backend-tjenester er tilgængelige under review. Se Apples aktuelle retningslinjer →
For Android afhænger test- og udgivelsesforløbet blandt andet af kontotype og distributionsform. De konkrete Play-krav kan ændre sig, så de skal bekræftes i den konto, der skal eje appen, før en tidsplan loves. Se Googles aktuelle testkrav →
Aftal derfor præcist, om leverancen slutter ved testversion, indsendelse, udgivelse eller efterfølgende drift. Ingen leverandør kan garantere en butiks godkendelse på forhånd, men processen kan være forberedt ordentligt.
6. Brug denne appbrief før første estimat
Et godt første estimat kræver ikke en færdig kravspecifikation. Men disse seks svar gør en første fase mulig at afgrænse:
- Hvilken konkret arbejdsopgave skal blive lettere?
- Hvem bruger den første version, og hvor arbejder de?
- Hvilke data og systemer skal appen bruge?
- Hvad skal kunne ske uden stabil forbindelse?
- Hvilke roller og adgangsgrænser er nødvendige?
- Hvad betyder aflevering: test, indsendelse, udgivelse eller drift?
KILDER OG AFGRÆNSNING
Denne guide er CM Systems’ praktiske anbefalinger til afklaring af en app-opgave. Krav hos Apple og Google er deres egne og skal genlæses før indsendelse.