Hver gang et digitalt produkt går live, bekymrer produktejerne sig om, hvordan det vedligeholdes. Det er en almindelig og berettiget bekymring. Oftere end ikke er dette det øjeblik i produktets livscyklus, hvor det har brug for mest support. Det er dog sædvanligt, at ingeniør- og designteamet på dette tidspunkt udfases, og det er ikke økonomisk rentabelt for produktejeren at holde teamet fuldt tildelt projektet.
På den ene side skaber dette et problem for produktejeren, da det originale produktteam ikke vil være tilgængeligt til at håndtere et presserende problem. På den anden side, hvis du bruger et agentur, vil dette projekt også have problemer med at håndtere regelmæssige, uplanlagte supportanmodninger. Holdet bliver nødt til at håndtere presserende anmodninger om det nyligt lancerede produkt, mens de arbejder på yderligere projekter. Dette tvinger teamet til at ændre kontekst under en brandslukningssituation og vil påvirke fristerne for ethvert yderligere projekt. I de fleste tilfælde lider alle produkter, både dem, der blev leveret, og de nye, som teamet er fuldt fokuseret på nu.
Et ideelt scenarie for begge sider overvejer en afbalanceret proces, der giver produktejere mulighed for at have et team i tider med behov, og projektteams, der ikke konstant afbrydes, efter at et projekt er udfaset. For bedre at forstå, hvordan vedligeholdelse på projekter fungerer, skal man dykke dybere ned i, hvad der virkelig skal opnås, når et projekt er leveret.
Der er flere opgaver, der skal udføres, når et produkt er live, og dermed er i det, der kaldes en vedligeholdelsesfase. At forstå arten af disse opgaver er afgørende for den daglige drift af ethvert digitalt produkt. De er normalt organiseret som følger:
Lad os se detaljeret, hvordan hver af disse situationer fungerer.
I enhver af de situationer, der falder ind under forebyggende og korrigerende vedligeholdelse, har produktejeren brug for et team til at håndtere eksisterende problemer. Men i modsætning til hvad de fleste mennesker tror, har størstedelen af digitale produkter ikke brug for et team, der arbejder 24/7. Alt, hvad de har brug for, er et team, der er i stand til at holde øje med systemet og gribe ind, når alt går sydpå. Men når de rette foranstaltninger er på plads, er moderne teknologi stabil nok til kun at fremme support i åbningstiden.
Den tid, der er dedikeret til vedligeholdelse, kontraheres normalt via en holder. For at maksimere effektiviteten holder teamet normalt øje med flere forskellige produkter og har optimeret processer til tjenester som serverovervågning og sikkerhedspatching, bare for at nævne et par.
Men i nogle særlige tilfælde har du muligvis brug for 24/7 support, og denne service er et dyr i sig selv. I dette tilfælde bør man være parat til at betale en præmiepris, normalt til et firma, der kun er dedikeret til vedligeholdelseskontrakter. Agenturer, der ikke er dedikeret til denne service, vil have problemer med at levere en 24/7 service, da det kræver komplekse procedurer, der kun fungerer i meget større skala.
Under alle omstændigheder er det afgørende at bedømme situationen korrekt og være i stand til at finde den rette løsning. Der er forskel på at korrigere fejl og opbygge et helt system for at styrke en bestemt sårbarhed. At ansætte et fuldtids supportteam er næsten aldrig svaret på nogen af dem.
Opgaver af den tredje type - udviklende vedligeholdelse - vedrører hovedsagelig forretningsvækst og forbedring af serviceydelser. Normalt kan disse støtteprojekter planlægges og udføres rettidigt. Ideelt set vil du sammensætte en liste over opgaver og derefter bede din teknologipartner om at samle et team og håndtere det i et par sprints.
Et almindeligt spørgsmål vedrørende vedligeholdelse er, hvor meget man kan forvente at bruge på det. Branchenumre peger normalt på 10-20% af de samlede produktomkostninger pr. År til forebyggende og korrigerende vedligeholdelse. Tallene vil sandsynligvis være forskellige for evolutiv vedligeholdelse, da disse opgaver ofte er bundet op til, hvor meget produktet vil vokse med hensyn til brugere og funktioner.
Stil altid følgende spørgsmål, når du starter et nyt produkt:
Arbejd på svaret fra dag nul med din softwareudviklingspartner. Vær åben om dine bekymringer, forvent at stort set alt kan være oprindelsen til et fremtidigt problem, og forudse så meget som muligt alt, hvad der kan gå galt. Dette vil hjælpe med at undgå en situation, hvor du, efter at produktet er gået i brug, ender med et problem, der ikke kan løses uden konflikt. Når dette sker, vil de første, der lider, være dine brugere og følgelig din virksomhed.
Fandt du denne artikel interessant? Du kan måske også lide disse!
CEO @ Imaginary Cloud og medforfatter af bogen Product Design Process. Jeg nyder mad, vin og Krav Maga (ikke nødvendigvis i denne rækkefølge).
People who read this post, also found these interesting:
.webp)
