Appen är lanserad – vem tar hand om den nu?

Lanseringsdagen känns som mållinjen, men för produkten är den startskottet. Från dag ett börjar operativsystem uppdateras, beroenden åldras och användare hitta saker som borde bli bättre. Frågan är inte om produkten behöver tas om hand, utan vem som gör det, vad det får kosta och hur avtalet ska se ut.

Förvaltningens fyra beståndsdelar

• Felrättning. Buggar som upptäcks i produktion ska hittas, prioriteras och åtgärdas – med tydliga förväntningar på hur snabbt.
• Uppdateringar. Nya versioner av operativsystem, säkerhetspatchar, uppdaterade beroenden och tredjepartstjänster som ändrar sina gränssnitt. Det osynliga arbetet som håller produkten vid liv.
• Support. Någon som svarar när något ser konstigt ut, tar emot felanmälningar och kan skilja användarfel från riktiga fel.
• Mindre vidareutveckling. Små förbättringar och justeringar som inte motiverar ett eget projekt, ofta hanterade via en timbank.

Gränsen mellan förvaltning och vidareutveckling är den vanligaste källan till missförstånd. En enkel tumregel: förvaltning håller produkten i det skick den lanserades i, vidareutveckling gör den bättre.

Drift är däremot en egen post utanför förvaltningen: servrar, domäner och licenser som kostar även om ingen människa rör produkten. Håll isär den från förvaltningen i budgeten – det gör både offerter och fakturor lättare att granska.

Vad kostar förvaltningen per år?

En vanlig tumregel är 15–25 procent av den ursprungliga utvecklingskostnaden per år för ren förvaltning. Vill ni dessutom utveckla produkten aktivt tillkommer en vidareutvecklingsbudget, ofta 20–40 procent av byggkostnaden per år. Som månadsavtal landar förvaltning typiskt på 10 000–50 000 kr beroende på omfattning och servicenivå.

Ett konkret räkneexempel: en app som kostade 1,2 miljoner kr att bygga bör ha en förvaltningsbudget på ungefär 180 000–300 000 kr per år, alltså 15 000–25 000 kr i månaden. Är appen affärskritisk med krav på beredskap utanför kontorstid hamnar ni i den övre delen – eller över.

Reaktiv förvaltning eller aktiv produktutveckling?

Reaktiv förvaltning betyder att någon rycker ut när något går sönder. Det är billigast på pappret, men produkten står stilla och den tekniska skulden växer tyst tills en uppgradering blir ett projekt i sig.

Aktiv produktutveckling betyder löpande kapacitet varje månad: buggar rättas, beroenden hålls aktuella och en prioriterad backlog betas av. Produkten förbättras i takt med att ni lär er av användarna.

Vår rekommendation är att aldrig gå under nivån “reaktiv förvaltning med planerad uppgraderingstakt”. Är produkten viktig för affären bör ni räkna på den aktiva modellen – skillnaden syns i vad produkten är värd om tre år. Mellanlägen finns också: många börjar reaktivt med kvartalsvisa uppgraderingsfönster och växlar upp när produkten bevisat sitt värde.

Er egen roll i förvaltningen

Ett förvaltningsavtal sköter sig inte självt. Utse en intern ägare som prioriterar timbanken, samlar användarnas återkoppling och fattar beslut när leverantören behöver svar. Utan den rollen används timbanken till det som råkar ropa högst, och avstämningarna blir en genomgång av gamla ärenden i stället för en plan framåt. Räkna med några timmar i veckan – det är den billigaste kvalitetssäkringen i hela upplägget.

Så konstruerar du avtalet

• Definiera vad som ingår i månadsavgiften – och lista exempel på vad som inte gör det.
• Sätt servicenivåer för svarstid och åtgärdstid per allvarlighetsgrad, och skilj noga på de två begreppen.
• Reglera timbanken: storlek, vad den får användas till och om oanvända timmar rullar vidare.
• Säkra ägarskap löpande: ni ska äga konton, ha tillgång till kod och få dokumentation uppdaterad kontinuerligt, inte bara vid avslut.
• Bestäm uppsägningstid och exit: vad som lämnas över, i vilket format och till vilken kostnad.

Bestäm förvaltningen före lanseringen

Den bästa tidpunkten att rigga förvaltningen är innan produkten går live, medan kunskapen är färsk och incitamenten sunda. Vi på Weapp föredrar att förvaltningsupplägget tas fram som en del av utvecklingsprojektet, inte som en eftertanke när något redan har hunnit gå sönder. Vill du ha hjälp att sätta en rimlig nivå för er produkt? Hör av dig så resonerar vi kring den.