När en digital produkt går live oroar sig produktägare för hur den ska underhållas. Det är en vanlig och berättigad oro. Oftast är detta det ögonblick i produktens livscykel där den behöver mest stöd. Det är dock vanligt att ingenjörs- och designteamet vid denna tidpunkt fasas ut, och det är inte ekonomiskt lönsamt för produktägaren att hålla teamet helt tilldelat projektet.
Å ena sidan skapar detta ett problem för produktägaren, eftersom det ursprungliga produktteamet inte kommer att vara tillgängligt för att hantera några brådskande problem. Å andra sidan, om du använder en byrå, kommer detta projekt också att möta problem med att hantera regelbundna, oplanerade supportförfrågningar. Teamet måste hantera brådskande förfrågningar om den nyligen lanserade produkten medan de arbetar med ytterligare projekt. Detta tvingar teamet att ändra sammanhang under en brandbekämpningssituation och kommer att påverka tidsfristerna för ytterligare projekt. I de flesta fall lider alla produkter, både de som levererades och de nya som teamet är helt fokuserat på nu.
Ett idealiskt scenario för båda sidor överväger en balanserad process som gör det möjligt för produktägare att ha ett team i tider av nöd och projektteam som inte ständigt avbryts efter att ett projekt fasas ut. För att bättre förstå hur underhåll på projekt fungerar måste man dyka djupare in i vad som verkligen behöver åstadkommas efter att ett projekt har levererats.
Det finns flera uppgifter som måste utföras när en produkt är live och därmed befinner sig i det som kallas en underhållsfas. Att förstå arten av dessa uppgifter är avgörande för den dagliga driften av alla digitala produkter. De är vanligtvis organiserade enligt följande:
Låt oss se i detalj hur var och en av dessa situationer fungerar.
I någon av de situationer som faller under förebyggande och korrigerande underhåll behöver produktägaren ett team för att hantera befintliga problem. Men i motsats till vad de flesta tror behöver majoriteten av digitala produkter inte ett team som arbetar 24/7. Allt de behöver är ett team som kan hålla ett öga på systemet och ingripa när allt går söderut. Men när rätt åtgärder är på plats är modern teknik tillräckligt stabil för att främja stöd endast under öppettider.
Den tid som ägnas åt underhåll kontrakteras vanligtvis via en hållare. För att maximera effektiviteten håller teamet vanligtvis ett öga på flera olika produkter och har optimerade processer för tjänster som serverövervakning och säkerhetspatching, bara för att nämna ett par.
Men i vissa speciella fall kan du verkligen behöva support dygnet runt, och den här tjänsten är ett odjur på egen hand. I det här fallet bör man vara beredd att betala ett premiumpris, vanligtvis till ett företag som endast ägnar sig åt underhållsavtal. Byråer som inte är dedikerade till denna tjänst kommer att ha problem med att tillhandahålla en 24/7 tjänst, eftersom det kräver komplexa procedurer som bara fungerar i mycket större skala.
I vilket fall som helst är det viktigt att korrekt bedöma situationen och kunna hitta rätt lösning. Det finns en skillnad mellan att korrigera buggar och att bygga ett helt system för att stärka en viss sårbarhet. Att anställa ett heltidssupportteam är nästan aldrig svaret på någon av dem.
Uppgifter av den tredje typen - evolutionärt underhåll - avser främst affärstillväxt och förbättring av tjänsterna. Vanligtvis kan dessa stödprojekt planeras och genomföras i tid. Helst vill du sätta ihop en lista med uppgifter och sedan be din teknikpartner att sätta ihop ett team och hantera det i ett par sprints.
En vanlig fråga om underhåll är hur mycket man kan förvänta sig att spendera på det. Branschsiffror pekar vanligtvis på 10-20% av den totala produktkostnaden per år för förebyggande och korrigerande underhåll. Siffrorna kommer sannolikt att vara olika för evolutionärt underhåll, eftersom dessa uppgifter ofta är bundna till hur mycket produkten kommer att växa när det gäller användare och funktioner.
Ställ alltid följande frågor när du startar en ny produkt:
Arbeta med svaret från dag noll med din mjukvaruutvecklingspartner. Var öppen om dina bekymmer, förvänta dig att praktiskt taget allt kan vara ursprunget till ett framtida problem och förutse så mycket som möjligt allt som kan gå fel. Detta hjälper till att undvika en situation där du, efter att produkten går live, hamnar med ett problem som inte kan lösas utan konflikt. När detta händer kommer de första som drabbas att vara dina användare och följaktligen ditt företag.
Tyckte den här artikeln intressant? Du kanske gillar dessa också!
VD @ Imaginary Cloud och medförfattare till boken Product Design Process. Jag gillar mat, vin och Krav Maga (inte nödvändigtvis i denna ordning).
Människor som läste det här inlägget tyckte också att dessa var intressanta:
.webp)
.webp)
.webp)
.webp)
.webp)
.webp)
.webp)
.webp)
.webp)
