Trafik i Göatunnel i Göteborg (fotokredd: Marcus Österberg Tavelin)

Prestandabudget – nytt sätt att dokumentera kvalitetsfaktorer

Webbförvaltningen har under 2014-2015 jobbat rätt hårt med att ta fram en måttstock kring våra externa webbplatser – vad som är den regionala ”standarden”, eller tekniska lägsta-nivå. Ett sätt att dokumentera detta kallas för prestandabudget, då direkt översatt från engelskans ”performance budget”. Performance kan även tydas som prestation, så ha det i åtanke när du läser vidare.

Vi har redan tre stycken prestandabudgetar samlade på vårt Github-repo för webbanalys. En för sökfunktionen vi nu utvärderar, en för blivande externwebben vgregion.se och en för våra mikrowebbar. Ambitionen är att ha en prestandabudget för varje större webbprojekt. Alternativet är att anamma den övergripande prestandabudgeten, i och med att alla inte har kompetens eller tid att avgöra exakt vilken nivå man behöver.

Beställaren till utvecklarna: ”Tar ni gift på att sajten lever upp till vår prestandabudget?”

Vad är då poängen med en prestandabudget? Jo, att man som beställare inte ska behöva fundera på teknikaliteter som utvecklarna, teknikerna, IT-folket och andra rimligen är bättre på jämfört med godtycklig person inom verksamheten. Nu kanske man kan hålla en mildare ton till folk än huruvida de tar gift på webbplatsens kvalitet, men att man menar allvar med sina krav bör man inte behöva skämmas över.

På VGR har vi inte med prestandabudget i några avtal (än så länge). Däremot har vi stämt av dem och utvecklat dem tillsammans med våra webbkonsulter. Särskilt för den pågående uppgraderingen av vgregion.se har vi (som kan en massa webbteknik) haft ett riktigt bra utbyte; hur tolkas kraven, metoder för mätning och intressanta avvägningar specifikt för den plattform vår webb ligger på.

Prestandabudget 101 för beställare

Det man som icke-tekniker behöver veta är att det handlar om en budget. Den kan övertrasseras på vissa punkter (konton?) men det ska då helst vägas upp på andra håll. Exakt hur nitisk man är kan säkert variera beroende på vilken kvalitetsfaktor det handlar om.

På tal om budget behöver man förstå att första gången man introducerar en prestandabudget kan det medföra vissa merkostnader. Ju fler krav man har desto dyrare lär det bli, om man nu inte enbart har krav leverantören redan överträffar med bred marginal. Det är i mitt tycke helt naturligt, om man vill ha en viss kvalitet måste det få kosta pengar. Så påbörja gärna arbetet med en prestandabudget med ett fåtal men ytterst viktiga krav. Tryter inspirationen kan du börja fundera på hur ni vill leva upp till lagstiftningen. Sedan januari 2015 täcker diskrimineringslagstiftningen in bristfällig tillgänglighet, det vill säga man måste tillgodose de med funktionsnedsättnings behov även på webben. Början på en lösning är punkt 1 nedan.

Har man inte egen kompetens för att ta fram en prestandabudget kan man be sina utvecklare/konsulter ta fram denna lägsta-nivå åt en. Eller så går det förstås bra att ta en kopia på VGR:s och bolla den med sina utvecklare. Det man som allra minst behöver klargöra är följande frågor:

  1. Vilken nivå av tillgänglighet förväntar beställaren sig? Som minst dokumenterar man vilken nivå av WCAG som avses, många kommer nog köra med kravet WCAG 2.0 nivå AA.
  2. Hur långsam får webbplatsen vara från en snabb uppkoppling, samt från en långsammare 3G-uppkoppling?
  3. Hur tänker man runt mobila användare? Ett mätbart förhållningssätt är att Googles test för mobilvänlighet ska klassa sidan som mobilvänlig.

Vill man sedan förvalta sin prestandabudget internt är det någon som kan gränssnittsprogrammering man söker, alternativt en teknisk analytiker. Denna dokumentation är bra att ha innan ett projekt drar igång så man är överens om kriterierna på förhand.

För att jobba strukturerat med sin prestandabudget som kravdokument vid utveckling är det viktigt att man sätter upp representativa testsidor. Det är mot dessa sidor man bedömer webbutvecklingen. Den publika startsidan är inte nödvändigtvis en bra sida att testa mot. För att veta att utvecklarna gjort ett gott arbete ber du dem sätta upp en representativ testsida och berätta hur den presterar. Behåll gärna dessa testsidor, det är mot dessa man kan kontrollera att webbplatsen inte råkar försämras över tid.

Vill du löpande ha koll på webbredaktörernas bidrag? Ja, då testar man sidor de skapar.

Har man möjlighet så se till att någon internt följer upp prestandabudgeten och för dialogen med utvecklarna!

Utvecklaren: ”Jo, jag har kollat den nya versionen. Den överträffar prestandabudgeten på samtliga punkter!”

Jag har själv jobbat som webbutvecklare, till och med levererat en hel del webbutveckling gentemot VGR mellan 2007-2010. Så jag ser detta fortfarande lite ifrån både utvecklarens och beställarens intressen. Som utvecklare är det mycket viktigt att veta om exakt vilken nivå kunden förväntar sig. I många fall har man redan en intern dokumentation på krav att leva upp till i de flesta tekniska sammanhang. Vissa firmor har till och med dedikerade testledare som säkerställer varje leverans kvalitet.

Ofta är de testerna automatiska och väldigt ”teknik-nära”. Där kommer en prestandabudget in som lite närmre användarens ände, det som kallas frontend i webbutvecklarsammanhang. Många kvalitetsfaktorer har inget som helst med bakomliggande teknik att göra. Ett exempel på det är att tillgängligheten för en webbplats hänger på det som landar i användarens webbläsare, inte på vad som ligger i en databas.

Att ha en prestandabudget är att minska osäkerheten kring kraven på det som landar hos användaren. Har man dessutom varit delaktig i att ta fram prestandabudgeten blir det troligen färre brister under tiden man bygger.

På VGR provkör vi detta arbetssätt med start hösten 2015. Vårt mål på sikt är att minimera beställarens vetskap om webbkvalitet till en bisats från kundansvarig, nämligen:

”Förresten, självklart överträffas prestandabudgeten, som vanligt.”
– framtida mejl från kundansvarig?

Internt kommer vi förvalta prestandabudgeten i vårt övriga arbete med webbanalys. Framtida tekniska frågor (som beställarna ska slippa höra talas om) vi kommer föra in i prestandabudgeten är när den nya versionen av HTTP införs. Då ändras nämligen praxis för hur många filer man kan kosta på sig att skicka till sina användare per sidvisning. Men som sagt, det är en fråga som kommer leva i förvaltandet av prestandabudgeten och något en projektledare inte ska behöva bekymra sig över. Projektledaren ska bara behöva hänvisa till den senaste versionen av prestandabudgeten så finns uppdaterade krav däri.

Första uppföljningen av en prestandabudget gick…

I dagarna har vi lanserat vår första mikrowebb, den för KOL-skolan som tidigare skrivits om här på utvecklingsbloggen. Därför blev det aktuellt att kolla hur bra den blev mätt från de kvalitetsfaktorer vi satte upp på förhand i prestandabudgeten för alla mikrowebbar.

Det gick bra! Några små övertrasseringar i form av för många Javascript-filer, vilket inte är hela världen. Sen behöver vi optimera bilder lite bättre och akta oss för att ha alternativtext på länkar som är identisk med den klickbara texten.

Jag är minst sagt nöjd med resultatet! Det känns också bra att ha kommit igång med uppföljning av annat än det vi får fram i webbplatsstatistik.

Annonser

Kommentera

Fyll i dina uppgifter nedan eller klicka på en ikon för att logga in:

WordPress.com Logo

Du kommenterar med ditt WordPress.com-konto. Logga ut / Ändra )

Twitter-bild

Du kommenterar med ditt Twitter-konto. Logga ut / Ändra )

Facebook-foto

Du kommenterar med ditt Facebook-konto. Logga ut / Ändra )

Google+ photo

Du kommenterar med ditt Google+-konto. Logga ut / Ändra )

Ansluter till %s