Aptarti projektą

Programėlės ir produktai5 min. skaitymo

Programėlės išlaikymo išlaidos po paleidimo

Programėlė nėra vienkartinis darbas. Net jei nekeisite nė vienos funkcijos, platformos kasmet pareikalauja atnaujinimų, o be jų programėlės nebegalima atnaujinti parduotuvėje. Šis vadovas išvardija realias išlaidų kategorijas dvylikai mėnesių, be išgalvotų skaičių.

Autorius
Devnora komanda
Paskelbta
Atnaujinta
Skaitymo laikas
5 min. skaitymo
Kalba
Skaityti angliškai
Šiame straipsnyje
  1. Trumpai
  2. Kodėl „nieko nekeičiame“ vis tiek kainuoja
  3. Išlaidų kategorijos dvylikai mėnesių
  4. Kas priklauso jums, o ne rangovui
  5. Iliustracinis pavyzdys
  6. Kaip planuoti be išgalvotų skaičių
  7. Ko šis vadovas nepasako

Programėlės biudžetas dažnai planuojamas iki paleidimo dienos. Bet paleidimas nėra darbo pabaiga – tai momentas, nuo kurio atsiranda pastovus, nuo jūsų sprendimų nepriklausantis darbas. Net jei nusprendėte nekeisti nė vienos funkcijos, platformos savo taisykles keičia pačios, ir jų grafikas nėra jūsų grafikas. Todėl naudinga iš anksto žinoti, kurios išlaidų kategorijos atsiras net esant „nieko nekeičiame“ scenarijui.

Trumpai

  • Nulinio darbo scenarijaus nėra: platformų reikalavimai kasmet priverčia perkurti ir pateikti naują versiją.
  • Google Play reikalauja, kad programėlės būtų orientuotos į pakankamai naują Android API lygį; reikalavimas atnaujinamas kasmet.
  • Jei reikalavimo neįvykdote, praranda ne programėlė iš karto, o galimybė ją atnaujinti ir būti pasiekiamai naujiems naudotojams naujuose įrenginiuose.
  • Parduotuvių paskyros, pasirašymo raktai ir sertifikatai turi savininką ir galiojimo laiką – tai administracinė, ne programavimo išlaida.
  • Didžiausia nenumatyta išlaida paprastai yra ne funkcija, o palaikymas: atsakymai naudotojams ir klaidų tyrimas.

Kodėl „nieko nekeičiame“ vis tiek kainuoja

Mobilioji programėlė gyvena svetimoje aplinkoje. Operacinės sistemos leidžiamos kasmet, o parduotuvės nustato, su kokiomis priemonėmis sukurtas paketas priimamas. Google Play politika reikalauja, kad naujos programėlės ir atnaujinimai būtų orientuoti į API lygį, esantį per vienerius metus nuo naujausio didelio Android leidimo; šiuo metu tai Android 16 (API lygis 36) arba naujesnis, o reikalavimas įsigalioja kasmet rugpjūčio 31 dieną. Egzistuojančioms programėlėms taikoma atskira riba: nepasiekus jos, programėlė nebeprieinama naujiems naudotojams įrenginiuose su naujesne sistema. Terminų pratęsimo galima paprašyti, bet tai atidėjimas, ne išimtis.

Praktinė išvada paprasta: bent kartą per metus programėlė turi būti perkurta su naujesnėmis priemonėmis, ištestuota ir pateikta iš naujo, net jei naudotojas nepamatys jokio pokyčio. Tai ne funkcija ir ne pageidavimas – tai sąlyga likti parduotuvėje. Prieš tokį atnaujinimą taip pat verta patikrinti, ar dėl sistemos pakeitimų nepakito leidimų elgsena, pranešimai ar veikimas fone.

Išlaidų kategorijos dvylikai mėnesių

Šį sąrašą galima naudoti kaip darbo lapą: prie kiekvienos kategorijos užrašykite, kas ją atlieka ir kaip dažnai. Sumų čia nėra sąmoningai – jos priklauso nuo programėlės apimties ir naudotojų skaičiaus, todėl bet kuris įrašytas skaičius būtų prielaida, ne įvertinimas.

  • Platformų atitikimas: kasmetinis perkūrimas su naujesnėmis priemonėmis, testavimas ir naujas pateikimas į abi parduotuves.
  • Parduotuvių administravimas: kūrėjo programų metiniai mokesčiai, paskyrų valdymas, aprašų ir ekrano nuotraukų atnaujinimai.
  • Sertifikatai ir pasirašymo raktai: galiojimo sekimas ir atnaujinimas laiku – pasibaigęs sertifikatas blokuoja išleidimą.
  • Serverio dalis: priegloba, duomenų bazė, atsarginės kopijos ir jų atkūrimo patikrinimas.
  • Bibliotekų atnaujinimai: saugumo pataisos naudojamuose komponentuose, net jei funkcijos nesikeičia.
  • Klaidų taisymas: tai, kas išaiškėja tik realiuose įrenginiuose ir realiose tinklo situacijose.
  • Naudotojų palaikymas: atsakymai į žinutes ir atsiliepimus parduotuvėse, klausimų tyrimas.
  • Stebėjimas: kritimų ir klaidų fiksavimas, kad problemą pastebėtumėte anksčiau nei naudotojas.
  • Įrenginių testavimas: naujų telefonų modelių ir naujų sistemos versijų patikrinimas.
  • Teisinė ir privatumo dalis: privatumo aprašų atnaujinimai, kai keičiasi duomenų rinkimas arba parduotuvių reikalavimai.

Kas priklauso jums, o ne rangovui

Ši dalis nėra techninė, bet nuo jos priklauso, ar po metų galėsite išleisti atnaujinimą nepriklausomai. Parduotuvių paskyros turėtų būti įmonės vardu, o pasirašymo raktai – saugomi jūsų pusėje su atsargine kopija. Praktinė pasekmė paprasta: jei raktas prieinamas tik rangovui, atnaujinimas priklauso nuo jo prieinamumo. Tai ne pasitikėjimo klausimas, o tęstinumo.

  • „App Store“ ir „Google Play“ kūrėjo paskyros įmonės vardu.
  • Pasirašymo raktai ir jų atsarginės kopijos jūsų pusėje, saugioje vietoje.
  • Programėlės kodas ir jo istorija perduodama jums, ne tik sukompiliuotas paketas.
  • Serverio ir duomenų bazės prieigos jūsų valdomos.
  • Parduotuvių aprašų, ekrano nuotraukų ir piktogramų originalai.

Iliustracinis pavyzdys

Iliustracinis scenarijus, ne kliento projekto aprašymas. Įsivaizduokime, kad programėlė paleista ir metus veikia be pastebimų problemų, todėl išlaikymo biudžetas nebuvo planuotas. Po metų parduotuvė nebepriima atnaujinimo, nes paketas sukurtas su per senomis priemonėmis. Tuo pačiu metu pasibaigia pasirašymo sertifikatas, o vienintelė jo kopija yra pas žmogų, kuris projekte nebedirba. Techninis darbas čia nėra didelis – bet jis tampa skubus ir atliekamas ne tada, kai patogu. Būtent dėl to kasmetinis atnaujinimas planuojamas kaip įprastas darbas, o ne kaip incidentas.

Kaip planuoti be išgalvotų skaičių

Naudingiau planuoti ne sumą, o ritmą ir atsakomybę. Kai žinoma, kas atlieka kasmetinį atitikimo atnaujinimą, kas seka sertifikatų galiojimą ir kas atsako naudotojams, biudžetą galima suskaičiuoti, o ne atspėti, ir paprašyti pasiūlymo su konkrečia apimtimi.

  • Užrašykite, kada kasmet atliekamas atitikimo atnaujinimas, ir įtraukite jį į planą kaip pastovų darbą.
  • Susitarkite, kas seka sertifikatų ir raktų galiojimą, ir kur laikomos atsarginės kopijos.
  • Nuspręskite, kaip greitai reaguojama į kritimus – tai apibrėžia palaikymo apimtį labiau nei bet kas kitas.
  • Apsibrėžkite, kurie įrenginiai ir sistemos versijos laikomos palaikomomis, o kurios – ne.
  • Susitarkite, kas atsako į atsiliepimus parduotuvėse, nes tai pastovus, ne vienkartinis darbas.
  • Paprašykite, kad pasiūlyme išlaikymas būtų atskira eilutė su apimtimi, o ne bendra frazė.

Ko šis vadovas nepasako

Jame nėra sumų, procentų ir nėra tipinio išlaikymo įkainio. Išlaidos priklauso nuo programėlės apimties, serverio dalies, naudotojų skaičiaus ir to, kiek platformų palaikote, todėl bendras skaičius būtų prielaida. Konkretūs platformų terminai ir API lygiai taip pat keičiasi kasmet – čia svarbus ne šios dienos numeris, o tai, kad reikalavimas kartojasi kiekvienais metais ir į jį reikia planuoti darbą.

Jei po paleidimo susitarsite tik dėl vieno dalyko – kad kasmetinis atitikimo atnaujinimas yra planuotas darbas su atsakingu žmogumi – dauguma skubių ir nepatogių situacijų nebeįvyks.

Dalintis

Siųsti el. paštu

Kitas žingsnis

Susijusi paslauga

Mobiliųjų programėlių kūrimas

Mobiliųjų programėlių kūrimas: platformos pasirinkimas, veikimas be interneto, pateikimas į parduotuves, palaikomi įrenginiai ir atnaujinimai po paleidimo.

Jei straipsnis aprašo jūsų situaciją, papasakokite, kas neveikia. Atsakysime, ar ir kaip galime padėti.

Toliau verta perskaityti

  1. Priežiūra ir techninė kokybė

    Kaip perduoti svetainę kitai programuotojų komandai?

    Perdavimas nėra failų archyvas. Tai prieigų inventorius, veikianti aplinka ir įrodymas, kad naujoji komanda gali savarankiškai išleisti pakeitimą. Šis vadovas duoda kontrolinį sąrašą ir priėmimo kriterijų, kuris netelpa į frazę „viskas perduota“.

Daugiau šia tema: Programėlės ir produktai