Tänkbar utvecklingsprocess för e-tjänsten Voddler

1. Affärsplan
Det första steget måste rimligen vara att ta reda på om marknaden efterfrågar en VOD-tjänst (Video On Demand), och om man kommer fram till att så är fallet får man genom till exempel intervjuer/enkäter ta reda på lite mer i detalj vilka behov som kunderna har och vad de är beredda att betala för att få dessa tillfredsställda. Man måste givetvis också analysera eventuella konkurrenter för att se vad dessa levererar och till vilket pris. Det gäller ju att skapa en tjänst som tar kunder från konkurrenterna och/eller attraherar kunder som tidigare inte använt sig av VOD-tjänster. I fallet med VOD-tjänster är detta nog inte helt lätt på grund av konkurrensen från piratkopieringen. Men det är alltså här man måste börja, med en realistisk och genomtänkt affärsplan. Innan man spikar affärsplanen måste man också se till att den är tekniskt genomförbar, det vill säga att de funktioner man planerar att erbjuda kunderna verkligen går att utveckla rent tekniskt.

En tjänst liknande Voddler är beroende av en mängd andra företag och detta är givetvis något som man måste ta med i beräkningen redan från början. För en VOD-tjänst är det ju till exempel helt avgörande att ha ett gott samarbete med film- och tv-bolag, men även andra samarbeten kan vara aktuella, till exempel med företag som tillhandahållet elektroniska betalningar. Man kan även tänka sig att det finns en koppling mellan kundens konto på VOD-tjänsten och sociala nätverk så som till exempel Facebook. Alla dessa avtal och samarbeten bör finnas på plats så tidigt så möjligt, helst innan man spikar affärsplanen. En affärsplan för en VOD-tjänst är knappast värd mycket innan man har avtal klara med film- och tv-bolag.

2. Prototyparbete och referensgrupp
Innan jag började med själva den tekniska implementationen skulle jag arbeta mycket med prototyper, det vill säga skapa en enkel version av sajten utan bakomliggande logik. Denna skulle jag sedan bolla dels internt på företaget och dels med en referensgrupp. Referensgruppen skulle i det här fallet bestå av personer utan koppling till företaget och av skilda åldrar, kön och datorvana. Genom att arbeta med prototyper går det snabbt att göra förändringar utifrån de synpunkter man fått och sedan göra ny tester med referensgruppen. På detta sätt undviken man dyrbara justeringar efter lanseringen och man kan dessutom vara ganska säker på att tjänsten kommer att motas positivt av kunderna. Resultatet av denna fas blir en beskrivning av hur användargränssnittet ska se ut samt vad som ska hända då användaren interagerar med de olika funktionerna. Här är det viktigt att även ta med sådant som inloggningsförfarande, betalningsrutiner samt eventuellt olika plattformar. Just detta med möjligheten till olika tekniska plattformar (dator, mobil, surfplatta etc.) är ju en av fördelarna med e-tjänster, men det gäller att fokusera på de plattformarna som verkligen efterfrågas. I prototyparbetet, som ju är relativt billigt, är det alltså lämpligt att ta fram prototyper för en mängd olika plattformar.

3. Teknisk implementation
3a. Teknisk specifikation och fastställande av IT-arkitektur
Här skapar man först en teknisk specifikation av e-tjänsten utifrån den beskrivning som skapades i föregående fas, det vill säga här beskrivs i detalj all logik som finns bakom användargränssnittet. För att kunna göra detta måste även IT-arkitekturen fastslås. IT-arkitekturen ska innehålla sådant som val av programmeringsspråk, databas och servermiljö samt hur dessa ska kommunicera med varandra. Dokumentationen från denna fas ska vara så pass bra att teknikerna och utvecklarna sedan exakt vet vad som ska göras.

3b. Uppsättande av teknisk miljö
Utifrån de specifikationer som togs fram i föregående fas så sätts den tekniska miljön upp. I den tekniska miljön ingår till exempel servrar, nätverk och utvecklingsmiljö för utvecklarna. En VOD-tjänst är antagligen mycket krävande när det gäller server- och nätverksmiljön då video tar mycket lagrings- och bandbreddsutrymme.

3c. Utveckling av mjukvara
När den tekniska miljön finns på plats så kan man börja utveckla själva mjukvaran enligt den specifikation som togs fram tidigare. Här ingår till exempel programmering av webbsidor, programmering av bakomliggande komponenter, anrop till databaser men även framtagandet av grafik för layouten.

3d. Tester
Att testa igenom hela tjänsten innan lansering är givetvis mycket viktigt. Det är många olika typer av tester som måste göras, till exempel kontrollera att rätt användarinput ger rätt output samt att svarstiderna är acceptabla även vid hög belastning. Det är även lämpligt att låta referensgruppen testa den färdiga tjänsten, det kan ju hända att de har några ytterligare synpunkter som eventuellt kan hinnas få med till lanseringen.

3e. Rättning av eventuella fel
Om det visar sig i testerna att det finns fel i tjänsten eller att referensgruppen kommit med några allvarliga invändningar så måste dessa rättas. Efter rättningarna görs nya tester. Sedan itererar man på detta sätt tills tjänsten fungerar som det är tänkt.

4. Lansering
4a. Teknisk lansering
Här öppnas tjänsten upp för kunderna. En bra idé är att öppna upp tjänsten stegvis, det vill säga låta ett antal pilotkunder använda tjänsten först för att på så sätt upptäcka eventuella fel man missad i testfasen
.
4b. Marknadsmässig lansering
De potentiella kunderna måste ju få reda på att tjänsten existerar, d.v.s. någon form av marknadsföring behövs. Marknadsföringen kan givetvis påbörjas innan tjänsten lanseras.

5. Uppföljning
Uppföljningen bör ske på flera olika plan. Dels bör man följa upp det tekniska utvecklingsarbetet och lära av sina misstag så att eventuella nästkommande versioner av tjänsten blir billigare och går fortare att ta fram. Dels bör man ta reda på hur kunderna upplever tjänsten, något som till exempel kan göras genom intervjuer och enkäter. Man bör också kolla upp vad som eventuellt skrivs om tjänsten på forum och andra sociala media. Det är också lämpligt att ha någon form av analysverktyg som analyserar hur kunderna använder tjänster. Självklart måste man också följa upp det ekonomiska, det vill säga intäkter och utgifter.

6. Förbättring av tjänsten
Lanserar man en e-tjänst riktad mot den privata marknaden får man nog räkna med att kunderna är lättrörliga och väljer den tjänst som för tillfället är bäst, att skapa ett konto på konkurrentens VOD-tjänst tar inte mer än någon minut. Och eftersom e-tjänsterna lever i en snabbt föränderlig teknisk miljö så gäller det att hela tiden följa med i utvecklingen och vara redo att snabbt göra förändringar. Det kan till exempel handla om att snabbt byta streamingteknik eller att lansera tjänsten på någon ny plattform. Exakt vad som behöver förändras ges av resultatet från föregående fas (uppföljningsfasen).

När man har beslutat vad som ska förändras så går man tillbaka till fas 2 eller 3 och gör om hela utvecklingskedjan. Beroende på hur omfattande förändringarna är kan man hoppa över vissa faser. Är det bara mycket små förändringar kanske man inte behöver kalla in en referensgrupp (fas 2) eller genomföra någon marknadsföring (fas 4b). Likaså kanske inte små förändringar innebär förändringar i arkitekturen (fas 3b) eller hårdvaran (fas 3a).

Kundtjänst/support
Att en seriös VOD-tjänst behöver en supportfunktion är självklart. Jag har dock inte nämnt något om support tidigare på grund av att jag inte ser uppsättandet av en sådan som en distinkt fas utan mer något som dels sker löpande under utvecklingsarbetet och dels ingår som en del i många av de andra faserna. När man designar tjänsten ska man givetvis ta hänsyn till supportfunktionen, till exempel genom att skapa backofficesystem där supporten kan följa kundernas betalningar och annat som kan vara av intresse.