Hvis dui ønsker å lage et nettsted eller en applikasjon, bør du stole på fagfolk. Få selskaper bestemmer seg for å bygge sitt eget team for å utføre slike oppgaver. Derfor er samarbeid med sofware house det beste valget . På denne måten vil du bruke ferdighetene, kunnskapen og erfaringen til et selskap som lignende prosjekter er daglig brød for. Hva må du forberede deg selv på under implementeringen?
Behovsanalyse
Før arbeidet med programvaren eller nettstedet begynner, må software house lære om kravene dine. For dette formål skal det gjennomføres et omfattende intervju med deg. Det kan også være verksteder (workshops), hvor du blir kjent med software house team og nøyaktig bestemme omfanget av arbeidet og dine behov med dem.
Før et møte med software house, bør vi bestemme:
hovedforutsetninger for prosjektet
Svar deg selv på spørsmålene: hvilke brukerbehov skal produktet dekke? Hvorfor ønsker du å implementere det? Hvordan skal det se ut? Skriv ned alle dine krav, og spesifiser hovedforutsetningene for prosjektet. Du kan også bruke mind maps, prototyper (tegnet på papir eller laget ved hjelp av programvare, for eksempel gratis Framer), tegninger eller user stories.
User stories er korte beskrivelser av utvalgte funksjoner fra brukerens synspunkt. De inneholder svar på spørsmålene "hvem?" (f.eks. en butikkkunde), "hva vil han gjøre?" ("ønsker å legge produktet i handlekurven") og "hvorfor?" ("for å kjøpe det senere").
target
Når du lager et digitalt produkt, bør du fokusere på brukere og deres behov. For dette formål, bygg opp personas, dvs. en beskrivelse av fremtidige brukere.
Hver persona bør bestemmes ved hjelp av parametere som for eksempel.: demografiske data (alder, bosted, yrkessituasjon, utdanning eller forholdsstatus), behov, ønsker, ambisjoner eller livsstil (f.eks. i hvilke situasjoner og forhold personen skal bruke produktet, for eksempel på vei til jobb).
konkurrenters produkter
Løsninger brukt av andre selskaper kan være et forbilde for oss. Samtidig fokuser på deres mangler for å kunne introdusere funksjoner på vår nettside eller applikasjon som overgår konkurranseprosjekter. Software house vil også gjennomføre sin egen analyse av produktene angitt av oss.
Faktureringsmodeller
Tid og materiale
Den består i å gjøre opp med kontraktoren basert på antall arbeidstimer. Dette er måten å avgjøre på når du ikke klarer å definere omfanget av prosjektet fullt ut eller anta at kravene dine kan endres over tid.
Time&Material gir fleksibilitet i utførelsen av arbeidet. Takket være dette kan vi enkelt forme produktet, tilpasse det til dine krav. Denne typen oppgjør brukes oftest når software house bruker smidig utvikling som er basert på iterasjoner.
Etter hver iterasjon blir effekten av arbeidet evaluert og mulige endringer for å forbedre produktet er gjørt. Dette lar oss tilpasse tidligere forutsetninger slik at programvaren eller nettstedet i enda større grad kunne oppfylle dine behov. Vi vil kunne forme produktet dynamisk ved regelmessige tester.
Time&Material-modellen lar oss også lage en enkleste brukbare produkt (MVP). Dette er en versjon som inneholder grunnleggende funksjonalitet, men som allerede utgjør verdi for brukeren. Vi kan raskt introdusere det til markedet og deretter utvikle produktet.
Ulempen ved Time&Material-modellen er at vi ikke har mulighet til å bestemme budsjett og tidsplan for prosjektet på forhånd. Under arbeidet etter smidig utvikling metodikken vil du også regelmessig måtte kommunisere med kontraktoren.
Fast pris
Denne modellen består i å sette en pris for å gjennomføre et bestemt prosjekt. Arbeidsplanen blir også definert. Fast priset blir valgt når våre krav er definert eksakt – dette kan for eksempel være en tilfelle ved en nettsted som er basert på et konkret design ved bruk av standardløsninger eller konkurrenters produkter.
Ved valget av Fast Pris-modellen, må du lage et SRS-dokument (Software Requirements Specification). Dette er en detaljert beskrivelse av programvaren som spesifiserer f.eks. dens formål, de viktigste parametrene og funksjonene. For å lage den, vil du trenge hjelp fra fagfolk, noe som vil utsette deg for kostnader og være tidkrevende. I tillegg kan dokumentet ikke endres uten gjensidig samtykke fra kunden og kontraktoren. Potensielle endringer innebærer ofte modifisering av budsjettet.
Prosjekter gjort opp på denne måten krever ikke mye engasjement fra deg, fordi du får effekten av arbeidet etter at det er ferdig. Du trenger ikke å teste nettsted eller applikasjon under oppdraget eller kommunisere med selskapet jevnlig.
Ulempen ved Fast Pris-modellen er at du kan overvurdere prosjektkostnadene, noe som vil utsette deg for noe ekstra utgifter. Kontraktoren antar vanligvis en viss feilmargin for å sikre seg mot tap, noe som gjør muligens verdsettelsen overdrevet.
Fremfor alt vil du imidlertid ikke være i stand til å utforme produktet jevnt under development-prosess. Hvis det til slutt ikke oppfyller forventningene dine, vil endringer fortsatt kreve ytterligere kostnader. Du kan også bli tvunget til å presentere til software house en svært detaljert kravanalyse (selvfølgelig kontraktoren kan hjelpe å utarbeide den).
Development
Når programvarer eller mer komplekse nettsteder byyges opp, mest ofte den smidig utvikling metodikken er brukt. Den består, som vi allerede har nevnt, i iterasjoner, dvs. repeterende aktiviteter. Etter hver av dem kan du bli bedt om å teste produktet og gi tilbakemelding.
I første omgang utarbeides et applikasjonsprosjekt ved bruk av UX (User Experience) og UI (User Interface) mock ups. Vanligvis er det bare sistnevnte som er mottatt for testing. De gjenspeiler formen til den fremtidige applikasjonen og er opprettet i spesiell programvare som du vil få tilgang til. Du bør sjekke nøye om utformingen av produktet passer deg og legge ut alle observasjoner i form av kommentar eller skrive dem ned og presentere til utviklerne.
Hvis applikasjonen må korrigeres, gjentas iterasjonen på nytt. Selvfølgelig vil du ikke være de eneste testerne av løsningen. Det kontrolleres også av software house og eksterne testere.
Hele samarbeidsprosessen er den samme for prototypeutgaver av applikasjonen.
Kreativt samarbeid
Du må regne med at når en kontraktor bruker smidig utvikling, måtte du engasjere deg i produktutviklingsprosessen. Dette gjør det imidlertid mer sannsynlig å oppfylle dine krav, for en smidig tilnærming vanligvis bidrar til å bygge bedre nettsteder og applikasjoner. Imidlertid bør du vanligvis avvente oppgjør i Time & Material-modellen.
Ved enklere prosjekter blir du selvsagt ikke tvunget til å være veldig aktiv. Da vil også Fast Pris-modellen fungere, noe som gjør at du lettere kan bestemme budsjett og arbeidsplan.
Men uansett hvordan samarbeidet er, bør du velge din kontraktor nøye, for hele prosjektets suksess avhenger av det. Et profesjonell software house med lang erfaring bekreftet av en portfolio, vil være en partner som du får mulighet til å skape et vellykket produkt med.