Hvor mye skal første versjon gjøre?
En enkel liste som bare vises på telefonen, er en annen oppgave enn en liste som deles mellom brukere, virker uten nett og håndterer endringer fra flere personer samtidig. Skjermen kan se nesten lik ut, mens behovet for lagring, tilgangsstyring og testing er forskjellig.
Beskriv hovedoppgaven fra start til slutt. Skill mellom det første versjon må inneholde og det som kan komme senere. Be om at tilbudet forteller hvilke forutsetninger som gjelder, hva som leveres, og hvilke ønsker som ligger utenfor avtalt omfang.
Hvilke systemer må appen snakke med?
Innlogging, booking, betaling og data fra et fagsystem kan gi egne avklaringer og oppgaver. Finn ut om det finnes dokumentert tilgang til systemene, hvem som eier kontoene, og om et testmiljø er tilgjengelig. En nødvendig integrasjon bør undersøkes tidlig.
Tenk også på arbeidet bak appen. Noen må kanskje publisere innhold, rette en registrering eller behandle en bestilling. Et administrasjonsverktøy kan være en del av løsningen selv om kundene aldri ser det. Beskriv denne arbeidsflyten i samme bestilling.
Hvem skal bruke den, og på hvilke enheter?
Valget mellom en iPhone-app, en Android-app og en webapp påvirker hvordan løsningen utvikles, testes og distribueres. Flere plattformer gir flere kombinasjoner å kontrollere. Delte tekniske deler kan være nyttige, men hele opplevelsen må fortsatt fungere på enhetene dere velger.
Ta med brukssituasjonen i vurderingen: Er appen for korte oppgaver ute på farten, lengre arbeid ved en skjerm eller begge deler? Behov for særskilt maskinvare, avansert grafikk eller bruk uten nett bør avklares før plattformen låses.
Hva inngår i design og kvalitetssikring?
Avklar om leveransen omfatter utforsking av brukerflyt, visuell utforming, tekster og testing med målgruppen. En ferdig profil kan gi et utgangspunkt, men sier ikke nødvendigvis hvordan en feilmelding, tom liste eller vanskelig registrering skal fungere.
Et budsjett bør også romme kontroll av den ferdige løsningen. Test vanlige oppgaver, feiltilfeller og relevante enheter. Apple beskriver testing på faktiske enheter og under realistiske nettverksforhold som en del av forberedelsene til App Review. Planlegg for feilretting før utgivelse.
Skill mellom bygging og videre drift
Et utviklingstilbud og de løpende kostnadene bør være lette å skille. Spør hvilke eksterne tjenester som brukes, hvordan de prises, hvem som følger dem opp, og hvordan vedlikehold og nye funksjoner avtales. Be også om en tydelig avklaring av tilgang til kildekode, kontoer og dokumentasjon.
Et godt grunnlag trenger ikke være en lang kravspesifikasjon. Begynn med en kort prosjektbeskrivelse som gjør antakelser og åpne spørsmål synlige. Da blir det lettere å sammenligne tilbud på samme grunnlag.
- Hvem skal appen hjelpe, og med hvilken oppgave?
- Hva må være med i første versjon?
- Hvilke plattformer og integrasjoner er nødvendige?
- Hva er budsjett, ønsket tidspunkt og viktigste usikkerhet?
Ta ideen et steg videre.
Vil du avklare omfanget av en appidé? Send prosjektbeskrivelsen til hello@rasklabs.no. Vi kan starte med behovene og finne ut hva som må undersøkes før et konkret tilbud.
Fortell om appideen