1

Så kostnadsestimerar du din mobila satsning

Vi är en design & innovationsbyrå som hjälper våra kunder att skapa morgondagens digitala tjänster och produkter.

2

VÅRA TJÄNSTER

User Insights & Advisory ServicesService DesignUser ResearchMobile StrategyStrategic Advisory ServicesUX Management Advisory Services Business Innovation Trends & ForecastsBusiness growth / Conversion Optimization

Design InnovationUser ExperienceInteraction DesignConcept DevelopmentInterface DesignResponsive DesignCreative ServicesCopywriting

Product DevelopmentProject ManagementTechnical DevelopmentMobile DevelopmentTechnical PlatformsContinuous IntegrationsLifetime & Maintenance

3

URVAL AV VÅRA KUNDER

4

Mobilstrateg & AffärsansvarigReza Assareh+46 (0)706 85 01 92reza.assareh@screeninteraction.com

Den kanske vanligaste frågan våra mobilstrateger får från företag är vad en mobilsatsning kommer att kosta. Svaret vi ger är alltid detsamma: det beror på. Precis som när du köper en bil eller spelar in en film kan du nå målet med både en liten och stor budget – med ett resultat därefter. Frågan är snarare vad du behöver och hur vi kan hjälpa dig nå dit. Och när du pratar om kostnader, vad är det egentligen du lägger in i begreppet?

I två delar kommer vi att bryta ner och visa dig vilka faktorer som påverkar kostnaden. Del 1 handlar om de största besluten du kommer behöva fatta. I del 2 förklarar vi hur du konkret kan avgöra projektets storlek – och därmed kostnad med hjälp av några enkla verktyg.

5

Sex primära kostnadsfaktorer

1. Vilken typ av mobila enheter och operativsystem ska lösningen stödja? 

2. Vilken teknik bör du använda? 

3. Vilka är säkerhetskraven? Hur känslig information kommer du att hantera? 

4. Är mobillösningen fristående eller ska den kommunicera med exempelvis intranät och affärssystem?

5. Leveransalternativ. Kommer du att distribuera appen via de stora app-butikerna eller företagets egen lösning? 

6. Förvaltning. Vilka framtida behov av support, underhåll och förbättringar kommer att finnas?

6

Om företaget förser alla anställda med samma telefonmodell behöver du bara ta hänsyn till ett operativsystem. Däremot får du direkt en högre hårdvarukostnad. Om de anställda istället använder sina egna mobiler undviker du hårdvarukostnaden, men behöver istället stödja olika typer av enheter och operativsystem. Tänk på att företagets säkerhetspolicy kanske förhindrar privata mobiltelefoner från att ansluta till interna stödsystem.

1. Mobila enheter och operativsystem

Native innebär att mjukvaran är utvecklad specifikt för ett visst operativsystem, medan HTML5 är en webbstandard och därför fungerar på de flesta mobila enheter. I reflektionen delade vi även med oss av en mall för att lättare kunna fatta rätt beslut.

Valet av teknik beror exempelvis på användarnas behov, säkerhetskrav och den planerade livslängden hos mobilsatsningen. Generellt är en HTML5-lösningen det billigaste alternativet medan en native-app ger dig högre prestanda och säkerhet.

2. Välj rätt teknik

7

En säkerhetslösning har alltid två sidor. Det uppenbara är att den behöver vara tillräckligt säker för det tänkta användningsområdet. Ännu viktigare är att den är enkel att använda. Risken är annars stor att användarna väljer bort tjänsten.

Om du hanterar känslig data, där appen är kopplad till andra stödsystem, behöver du givetvis tänka på användarprofiler, inloggningar och krypteringar – som alla kan ha stor påverkan på kostnadsbilden.

3. Säkerhetskrav

Kopplingar mot affärssystem, databaser och intranät är stora kostnadsfaktorer. Ibland är en fristående applikation både billigare och mer passande. Men oftast vill företag ge anställda eller kunder ett eget större ansvar för att själva sköta sin ärenden – som att logga in på banken, betala räkningar och överföra pengar. Ett annat vanligt syfte med mobila satsningar är att effektivisera verktygen du redan har genom ett nytt arbetsflöde och just mobilitet.

En fristående applikation utan kopplingar mot affärssystem eller höga säkerhetskrav är billigare och går snabbare att utveckla. Frågan är om den ger dig rätt affärsnytta.

4. Fristående eller integrerad lösning

8

Det finns två kategorier av appar för företag. De som distribueras öppet via Apples, Googles och Microsofts marknadskanaler, och de som är interna arbetsverktyg/tjänster och bara relevanta inom företaget. Givetvis kommer de två varianterna med olika för- och nackdelar.

Om du vill nå så många som möjligt bör appen vara tillgänglig på App store, Google play och Windows store. Det är inte svårare än att ansöka om en utvecklarlicens – som kostar drygt 700 kronor per år – och skicka in appen för godkännande. Men det är också i godkännandeprocessen du kan stöta på problem. Eftersom appen kommer att finnas i de stora nätbutikerna behöver den följa deras riktlinjer och krav på säkerhet och innehåll.

Är appen däremot enbart relevant inom företag – och kanske bara för vissa anställda – är den bästa lösningen antagligen att distribuera den själv. Det finns färdiga lösningar för detta.

5. Appstore eller egenlösning

Utvecklar man kampanjappar är projektet ofta färdigt efter lanseringen. För arbetsrelaterade appar med en livslängd på 3–4 år kommer du däremot att behöva göra uppdateringar när nya versioner av operativsystemet släpps. Och bara för att appen är lanserad är den inte färdig. Det är nu du har stora möjligheter att optimera den, baserat på användarnas beteende och synpunkter.

6. Förvaltning och support

9

Genom att tänka på appens hela livscykel redan i planeringsstadiet är det lättare att överblicka och förstå den totala kostnaden – inte bara den för utvecklingen. Rätt mobilstrategi skapar affärsnytta och gör att ditt företag undviker onödigt integrationsarbete.

Nu är det dags att introducera (25+50+25)*1.25-regeln. Tänk på att den här kostnadsfördelningen är ungefärlig och kommer att se olika ut beroende på ett flertal variabler: hur ditt företags mobilkultur ser ut, hur avancerade användarinteraktioner du vill ha, hur prototypen kommer att se ut och ifall du vill använda native-teknik eller inte.

(25+50+25)*1.25-regeln

10

Sandbergit.no

Ett sätt att förenkla kostnadsberäkningen är att skapa en grundtidslinje för utvecklingen av appen. När man har en grund att utgå ifrån kan man justera den utifrån projektets komplexitet och tidigare erfarenheter, men låt oss titta på hur (25+50+25)*1.25-regeln ser ut i sitt ursprungsutförande:

·     De första 25 procenten går till planering, kravspecificering, att ta fram användarfall, undersöka arbetsflöden och skapa en prototyp som man kan visa upp för olika intressenter.

·      De 50 procenten i mitten av processen går till design och teknisk utveckling. Man utvecklar användbarheten, testar och felsöker mobillösningen fristående från resten av systemet. Det kanske låter enkelt men är ett mycket tidskrävande moment.

·      De sista 25 procenten består av att testa hela det integrerade systemet. Fokus ligger på säkerhet, användbarhet och prestanda. Man testar ifall mobilsatsningen möter kravspecificeringen och slutanvändarens förväntningar. Under den här fasen arbetar utvecklarna med beskrivningar av appen, till exempel med skärmdumpar och begripliga förklaringar av appens olika funktioner, som kan användas i App Store, Google Play eller de interna kanalerna.

·      Slutligen multiplicerar du den totala tiden med 1.25, du lägger alltså på 25 procent för projektledning, kommunikation med olika intressenter och andra administrativa uppgifter.

En tumregel för tidsåtgången när man arbetar med en ny mobilsatsning är ungefär en veckas arbetstid för varje skärmbild i systemet. Det är visserligen sant att det inte finns något ”normal” tidsåtgång för en app, men det här är ändå en bra fingervisning.

11

Om din app till exempel har åtta huvudsakliga skärmbilder kan vi uppskatta tidsåtgången till åtta veckor. Enligt (25+50+25)*1.25-regeln kan du då dela upp tiden så här: två veckors prototyparbete, fyra veckors utveckling och två veckor för sluttester och sedan ytterligare två veckor (multiplicera med 1.25) för projektledning under hela processen.

När vi har gjort en grunduppskattning av tidsåtgången för din mobilsatsning måste vi räkna in de faktorer som vi nämnde tidigare och justera vår tidslinje efter dem. Här är de vanligaste faktorerna, som vi kan betrakta som ”tillägg” till vår tidslinje:

12

Faktor Uppskattad tidsåtgång

Företagsspecifika faktorer / utvecklingskultur + 1 till 3 veckor

Komplex funktion i gränssnittet + 1 till 3 veckor

Login funktionalitet . t.ex signering/verifiering + 2 till 4 veckor

Offlinesynkronisering + 1 till 2 veckor

Support för dynamiskt innehåll (CMS-gränssnitt) + 2 till 3 veckor

Utveckla för en ny plattform Dubbel utvecklingstid

Detaljerad varumärkesanpassning + 2 veckor

Skärmstorleken påverkar självklart utvecklingen av mobilapplikationer. Att anpassa en app efter både porträtt- och landskapsvy (stående och liggande vy) tar också extra tid. Man måste anpassa alla objekt och marginaler för att de ska fungera i olika vyer. I vissa fall ändras appens funktion när man vänder på enheten och hamnar i en ny vy, till exempel när en kalender ändrar från månadsvy till dagsvy. De här förändringarna ökar komplexiteten och därför också tidsåtgången.

Om du vill att en iPhone-app ska fungera även på iPad är det överlag bara små grafiska förändringar som behöver göras om du använder ”2X”-metoden. Android kräver större förändringar eftersom de grafiska förhållandena är relativa och varje skärmbild måste anpassas manuellt. Ju fler Android-enheter du vill att din mobilsatsning ska stödja, desto större blir tidsåtgången eftersom varje skärmbild måste göras om eller i varje fall uppdateras. Dessutom krävs mer testning vilket också tar tid.

I vårt exempel med två veckor för att göra en prototyp av appen, kan det lätt växa till tre veckor före och efter programmeringen ifall vi lägger till fler Android-enheter eller om appen beter sig annorlunda på telefon respektive surfplatta. Det blir allt vanligare att man utvecklar separata appar för telefon och surfplatta, så att man utnyttjar det tillgängliga utrymmet på skärmen maximalt och matchar användarnas förväntningar på appen.

Skärmstorlek och operativ version

13

Appar som är fristående och inte integreras med andra företagssystem fungerar överlag bra i vår grundtidslinje. I de fall man vill ha användarsignering/verifiering, eller integration för att säkra systemet bakom företagets brandvägg (t.ex. CMS-gränssnittet) eller använda andra externa interaktioner, krävs extra arbetsresurser till programmeringsdelen av projektet.

I vårt exempel med fyra veckors utvecklingstid för en enkel mobilapplikation, skulle det krävas ytterligare en heltidsresurs för att inte påverka tidsåtgången ifall appen kräver en säker integrering. Eftersom vi skapar appar som skall användas internt hos företag är kryptering och säkra överföringar en ofta naturlig del av integreringsarbetet.

Integrationer med webbtjänster och affärssystem

14

En app som är byggd med native-teknik för två operativsystem är i själva verket två appar. Android-kod kan inte användas direkt i andra operativsystem och vice versa (t.ex. iOS, Symbian och Windows). Skärmarna ser olika ut, Photoshop-tiden fördubblas om vi behöver utveckla appen till två operativsystem. Koden är på ett annat programmeringsspråk, så tiden för programmering och testning fördubblas.

Endast vissa delar är i regel återanvändbara: - arbetsflöden och viss interaktionsdesign- till viss del testplanering - externa integrationer

I övrigt blir det alltså i princip en dubblering av arbetsbördan.

Den största kostnadsfaktorn: antal operativsystem du utvecklar för

15

Mobile Operating System Market Share 2012, icrossing.co.uk

Den största kostnadsfaktorn består alltså av appens stöd för olika operativsystem, låt oss därför ta en titt på vilka valmöjligheter som finns och vilka beslut du måste ta för att kunna använda dig av flera operativsystem. Hur man väljer att göra här är en vattendelare bland programmerare, det finns många olika åsikter om vad som är ”rätt” och ”fel”, därför ska vi försöka se på alternativen så objektivt vi kan.

Om det bara vore en kostnadsfråga vore det enkelt, men eftersom valet också påverkar användarupplevelsen måste man väga in helheten när man gör sitt val. De viktigaste skillnaderna mellan de olika alternativen är:

Native-teknikDet dyraste alternativet både att utveckla och underhålla, men ger också den bästa användarupplevelsen. Om vi använder native-teknik kan vi använda respektive operativsystems fördelar maximalt, både mjukvaran och hårdvaran (kameran, lokala databaser, GPS osv.). Eftersom användarna ofta jämför alla appar mot deras favoritappar ligger ribban högt vad gäller användarupplevelsen, vilket talar för native-tekniken.

HTML5Kostar minst att utveckla och att underhålla. Det mesta av ”systemet” finns på en extern server istället för i den mobila enheten, innehållet anpassas bara efter skärmen. HTML5 har bra stöd för till exempel videovisning och nu när HTML6 börjar ta form finns det hopp om att webbapplikationer kommer att närma sig native-tekniken vad gäller integrering.

16

Utmaningarna med HTML5 är bland annat hur man ska hantera enhetsspecifik hårdvara, databaser, nätverksanslutningar och olika användarkommandon som i dagsläget varierar mellan de olika operativsystemen.

Multi-plattformutvecklingsverktyg för apparMulti-plattformutvecklingsverktyg för appar är en lösning som ligger någonstans mellan native-teknik och HTML5 vad gäller pris. Lösningen erbjuder möjligheten att dela kod mellan olika plattformar. Tänk på att kvaliteten mellan olika alternativ här varierar mycket både vad gäller användarupplevelse och vilken typ av appar de har stöd för.

Utvecklingen går fort på det här området och utvecklarna vill så klart komma så nära native-tekniken som möjligt i användarupplevelse utan att behöva använda native-kodning. Ofta använder man sig av till exempel JavaScript för att skapa appens kärnfunktioner, och gör sedan anpassade ”skins” för de olika enheterna/operativsystemen för att imitera native-upplevelsen. De flesta användarna har inte koll på hur teknologin bakom appen fungerar, men de uppfattar ofta appen som ett slags mellanting mellan native och HTML5.

17

För att kostnadsestimera din mobila satsning finns flera olika verktyg och mått att utgå ifrån. Ett sätt att uppskatta tidsåtgången och fördelningen är att använda (25+50+25)regeln, där antalet huvudsakliga skärmbilder i systemet kan vara en fingervisning för det totala antalet veckor. Förutom grundtidslinjen tillkommer också några vanliga tilläggsfaktorer som förlänger utvecklingstiden (till exempel offlinesynkronisering, login eller ny plattform) och därmed kostnaden.

Om du vill få konkreta exempel på hur de här uträkningarna kan se ut i verkligheten, läs gärna våra tre fallstudier nedan.

Sammanfattning

18

Det finns många faktorer som kan påverka kostnaden för ett mobilutvecklingsprojekt. De övergripande faktorerna och utvecklingsmöjligheterna som vi diskuterat ovan hjälper dig att ta bra affärsmässiga beslut.

I våra beräkningar nedan utgår vi från ett timpris på 1000 SEK/h och en arbetsvecka på 40 timmar per FTE (heltidsanställd). För enkelhetens skull bortser vi från faktorer som utvecklingsteamets kompetens, erfarenhet och outsourcingmöjligheter. Dessa faktorer kan påverka kostnaden för projektet med ungefär +/- 30 %.

Varje utvecklingsprojekt är unikt och beräkningarna är grovt generaliserade. Därför kan estimeringarna variera mellan apputvecklingsbolag och team.

Fallstudierna bör endast användas som riktlinjer och som beslutsunderlag för investering i en mobil satsning och inte till offertförfrågning eller projektspecifikation.

Räkneexempel

19

Enkel app med åtta huvudsakliga skärmbilder för en plattform, utan integrationer med andra webbtjänster.

Användarscenario:Utvecklingsprojektet avser en native-applikation till iOS (iPhone) för beräkning av traktamente. I applikationen kan medarbetarna välja traktamentesbelopp från en skattetabell (sparad lokalt på telefonen) och beräkna sitt skattefria traktamente för varje affärsresa. Traktamentet mejlas sedan till lönekontoret som manuellt för in reseräkningen i bolagets ekonomisystem.

Utgångspunkten är att vi utvecklar för en enhet (iPhone) och en plattform (iOS). Mobillösningen har inga integrationspunkter.

Grundarbetet estimeras till:Cirka 80 timmar för design av flöden och appens användarupplevelse samt att skapa en klickbar prototyp för att testa lösningsförslaget mot målgruppen.

Cirka 160 timmars utvecklingsarbete för iOS-plattformen (Xcode). Cirka 80 timmar av enhetstest, användbarhetstest och slutgiltigt acceptanstest av lösningen.

Slutligen multiplicerar vi den totala projekttiden med 1.25 (adderar ytterligare 25 % till den totala utvecklingstiden) = 80 timmar för projektledning av teamet, kommunikation med beställare, hantering av tidsplan, och så vidare.

Totalt estimeras projektet till cirka 400 timmar med +/- 20 % differens beroende på applikationens test-, kvalitets-, och användarupplevelseambition samt marknadsföring. Kostnaden är grovt räknat densamma oavsett operativsystem såvida det gäller en enhet.

Fallstudie 1

20

Samma specifikation som ovan fast med två integrationspunkter för att hämta aktuell pristabell och autentisering via företagets inloggningssystem.

Användarscenario:Utvecklingsprojektet avser en native-applikation till iPhone 4 för beräkning av traktamente. Medarbetarna kan logga in med samma användarnamn och lösenord som de använder till företagets övriga webbtjänster. Det senaste traktamentesbeloppet och skattetabellen hämtas från en extern webbtjänst. Traktamentet mejlas till lönekontoret som manuellt för in reseräkningen till bolagets ekonomisystem.

Utgångspunkten är fortfarande att vi utvecklar för en enhet (iPhone 4) och för en plattform (iOS). Lösningen kräver två integrationspunkter (mot företagets inloggningssystem och mot den externa webbtjänsten). Användarupplevelsen påverkas i och med en inloggningsvy där alternativa scenarion som felaktiga eller förlorade användaruppgifter (användarnamn och lösenord) måste hanteras.

Grundarbetet estimeras till:Cirka 90 timmar för design av flöden, gränssnittsdesign, appens användarupplevelse samt att skapa en klickbar prototyp för att testa lösningsförslaget mot målgruppen.

Cirka 180 timmars utvecklingsarbete för iOS-plattformen (Xcode).

Cirka 80 timmars integrationsarbete per integrationspunkt (givet att API:er funkar och är testade) krävs. Systemarkitekten behöver designa datastrukturer, definiera REST-protokoll, installera och konfigurera säkerhetscertifikat mot inloggningssystemet. Detta arbete kräver en annan typ av kompetens och kan utföras parallellt med iOS-utvecklingen.

Cirka 90 timmar av enhetstest, användbarhetstest och slutgiltigt acceptanstest av lösningen.

Fallstudie 2

21

Slutligen multiplicerar vi den totala projekttiden med 1.25 för projektledning av teamet, kommunikation med beställare, hantering av tidsplan, och så vidare.

(90+180+80+80+90)*1.25 = 650 timmar

Totalt estimeras projektet till cirka 650 timmar med +/- 20 % differens beroende på applikationens test-, kvalitets- och användarupplevelseambition samt marknadsföring.

22

Samma specifikation som ovan fast för två plattformar till utöver iOS (Android och Windows Phone) samt ytterligare en integrationspunkt för att automatiskt föra in reseräkningen till företagets ekonomisystem.

Användarscenario:Utvecklingsprojektet avser en native-applikation för beräkning av traktamente till iOS, Android och Windows Phone. Medarbetarna kan logga in med samma användarnamn och lösenord som de använder till företagets övriga webbtjänster. Den senaste traktamentesbeloppet och skattetabellen hämtas från en extern webbtjänst. Traktamentet och reseräkningen registreras automatiskt hos lönekontoret via bolagets ekonomisystem.

Utgångspunkten är att vi utvecklar för tre plattformar (iOS, Android och Windows Phone). Vi har nu två val:

a)    Utveckla de tre applikationerna till native specifikt för varje plattform, det vill säga Xcode för iOS, Java för Android och .NET för Windows Phone.

b)   Utveckla de tre applikationerna med hjälp av multiplattform-utvecklingsverktyg.

Lösningen kräver tre integrationspunkter (mot företagets inloggningssystem, mot externa webbtjänsten, mot företagets ekonomisystem). Den tredje integrationspunkten påverkar inte användarupplevelsen eftersom detta sker i bakgrunden. Design, UX-arbete och test är dock oberoende av utvecklingsverktyg eller

Fallstudie 3

native. Därför ökar projektets fas 1 och 3 i relation med antalet plattformar. Arbetet estimeras då till:

Alternativ a: native-utveckling för varje plattformCirka 90 timmar per plattform för design av flöden, gränssnittsdesign, appens användarupplevelse samt att skapa en klickbar prototyp för att testa lösningsförslaget mot målgruppen.

Cirka 180 timmars utvecklingsarbete per plattform.

Cirka 80 timmars integrationsarbete per integrationspunkt (givet att API:er funkar och är testade) krävs. Systemarkitekten behöver designa datastrukturer, definiera REST-protokoll, installera och konfigurera säkerhetscertifikat mot inloggningssystemet. Detta arbete kräver en annan typ av kompetens och kan utföras parallellt med apputvecklingen för plattformarna.

Cirka 90 timmar av enhetstest, användbarhetstest och slutgiltigt acceptanstest per plattform.

Slutligen multiplicerar vi den totala projekttiden med 1.25 för projektledning av teamet, kommunikation med beställare, hantering av tidsplan, och så vidare.

(90+90+90+180+180+180+80+80+80+90+90+90)*1.25 = 1650 timmar

Totalt estimeras projektet till cirka 1650 timmar med +/- 20 % differens beroende på applikationens test-, kvalitets- och användarupplevelseambition samt marknadsföring.

Alternativ b: utveckling med multiplattform-utvecklingsverktygDen stora skillnaden i det här fallet blir återanvändningen av kod mellan de tre plattformarna (ca 80 % återanvändning av kod). Utvecklingsarbetet estimeras därför enligt:

Cirka 90 timmar per plattform för design av flöden, gränssnittsdesign, appens användarupplevelse samt skapa en klickbar prototyp för att testa lösningsförslaget mot målgruppen.

Cirka 220 timmars total utvecklingsarbete för alla tre plattformar med 80 % återanvändning av kod mellan varje plattform.

Cirka 80 timmars integrationsarbete per integrationspunkt (givet att API:er funkar och är testade) krävs. Systemarkitekten behöver designa datastrukturer, definiera REST-protokoll, installera och konfigurera säkerhetscertifikat mot inloggningssystemet.

23

Detta arbete kräver en annan typ av kompetens och kan utföras parallellt med apputvecklingen för plattformarna.

Cirka 90 timmar av enhetstest, användbarhetstest och slutgiltigt acceptanstest per plattform.

Slutligen multiplicerar vi den totala projekttiden med 1.25 för projektledning av teamet, kommunikation med beställare, hantering av tidsplan, och så vidare.

(90+90+90+180+(180*0.2)+((180*0.2)*0.2)+80+80+80+90+90+90)*1.25 = 1254 timmar

Totalt estimeras projektet till cirka 1254 timmar med +/- 20 % differens beroende på applikationens test-, kvalitets- och användarupplevelseambition samt marknadsföring.

24