Denne casestudien vil være annerledes enn andre casestudier der ute. Den kommer ikke til å være så skinnende og glorifisert, men vi mener det er viktig og interessant å dele.
La oss dykke inn i det.
1. Forespørsel
Forespørselen kom fra en venn i Norge som allerede hadde vært vår kunde tidligere.
Oppgaven var å lage en integrasjon mellom to apper. Den ene var et massivt webbasert styringssystem for administrasjon og kvalitetsstyring – la oss kalle det App A. Den andre var en mobilapp som var laget slik at brukeren raskt og enkelt kunne samle data fra en byggeplass – vi kaller den App B.
Integrasjonen skulle sende innsamlede data fra B til A for videre behandling.
2. Grunnlag
Som Rocksoft dannet vi et team ansvarlig for utviklingen, og deretter hadde vi kickoff-møter med kundens representant.
Vi begynte å teste begge applikasjonene innenfor det omfanget som var nødvendig for integrasjonen vår. Vi tok en nærmere titt på brukstilfellene vi skulle dekke.
På overflaten virket løsningen enkel. Vi trengte å bygge en enkel tjeneste som skulle være ansvarlig for kommunikasjonen mellom de to systemene.
Etter en dypere forståelse av systemene og deres kapabiliteter, oppdaget vi de viktigste spørsmålene og punktene vi måtte være oppmerksomme på, som: datasynkronisering, modellforskjeller, identifikatorkartlegging, motstandsdyktighet mot feil i begge systemene.
Etter denne analysen arrangerte vi møter med representanter fra begge applikasjonene som tjenesten måtte integreres med. Formålet med møtene var å bli enige om formen på kommunikasjonen mellom systemene og finne svar på tvil og potensielle problemer som fulgte av analysen.
3. Hva skjedde før planlagt oppstart?
Etter at vi hadde grundig diskutert de mest sannsynlige brukstilfellene med ingeniørene fra begge app-leverandørene, kommuniserte vi vårt syn på prosjektets kompleksitet.
Det var fredag kveld da vi fikk svar fra kunden. Det sa i hovedsak: «Hei, stor takk for samarbeidet så langt. Estimatet er fem ganger større enn budsjettet vårt. Vi må stoppe prosjektet til vi finner en betalende kunde for denne integrasjonen.»
4. Hvordan kan man unngå slike misforståelser (og skuffelser)?
Hvis du kommer til et softwarehus med et problem og har et budsjett for dette, kommuniser det med en gang. Dette gjelder både for agile og fossefallsprosjekter. Kanskje funksjonen du ønsker ikke er så enkel å implementere som du tror?
Du trenger ikke være redd for å avsløre budsjettet til et agilt team. Hvis det virkelig er agilt, kan du stoppe arbeidet når som helst.
Hvis du trenger en fastpris, vil du sannsynligvis ende opp med å betale mer enn nødvendig på grunn av marginen som en utvikler må legge til hvert fastprisprosjekt.
