Priežiūra ir vystymas po paleidimo
Svetainių ir sistemų priežiūra
Priežiūra dažnai perkama kaip „palaikymas“ ir tik vėliau paaiškėja, kad abi pusės tą žodį suprato skirtingai. Todėl naudingiau susitarti ne dėl pavadinimo, o dėl keturių dalykų: kokie darbai įeina, kokie neįeina, per kiek laiko atsakoma ir kas turi prieigas. Ketvirtas punktas svarbiausias – jei prieigos ir atsarginės kopijos priklauso tik vykdytojui, priežiūros sutartis tampa priklausomybe, o ne paslauga.
Aptarti priežiūros apimtįTrumpai: ką reikia susitarti
Prieš pasirašant naudinga atsakyti į tris dalykus. Ar priežiūra apima tik veikimo išsaugojimą, ar ir naujų dalykų kūrimą – tai dažniausias nesusipratimas. Kuo skiriasi atsakymo laikas nuo išsprendimo laiko, nes tai nėra tas pats ir tik vienas iš jų realiai pažadamas. Ir kas turi prieigas prie domeno, prieglobos bei atsarginių kopijų. Jei šie trys punktai užrašyti, likusi sutartis tampa detalėmis.
Kada priežiūra yra tinkamas sprendimas
- Svetainė ar sistema jau naudojama versle, todėl neveikimas turi realią kainą, o ne tik nepatogumą.
- Reikia žinoti, kas atsakys, kai kažkas nustos veikti vakare arba prieš savaitgalį.
- Naudojamos bibliotekos ir platformos sena versija – atnaujinimai reikalingi net nekeičiant funkcijų.
- Norite palaipsniui vystyti produktą, o ne užsakinėti atskirus projektus kiekvienam pakeitimui.
Kada pakanka paprastesnio sprendimo
- Sistema nekritinė ir keičiama retai – gali pakakti atskirų užsakymų pagal poreikį, be nuolatinio susitarimo.
- Turite savo komandą, kuriai reikia tik konsultacijos ar peržiūros – tada tinka ribotas patariamasis darbas.
- Naudojama tik uždara platforma, kurią palaiko jos tiekėjas – tada priežiūros apimtis lieka tik jūsų turinys ir nustatymai.
Priežiūros apimties variantai
Žemiau pateiktas iliustracinis susitarimo tipų palyginimas, padedantis pasiruošti pokalbiui. Tai nėra kainų lentelė ir ne pasiūlymas: konkreti apimtis priklauso nuo sistemos, jos amžiaus ir to, kaip greitai reikia reaguoti. Trečiame stulpelyje nurodyti kaštų veiksniai, ne sumos.
| Susitarimo tipas | Ką apima | Ribos ir kaštų veiksniai |
|---|---|---|
| Tik veikimo išsaugojimas | Atnaujinimai, atsarginės kopijos, saugumo pataisos ir sutrikimų taisymas. | Neapima naujų funkcijų; jos užsakomos atskirai ir planuojamos atskirai. |
| Priežiūra ir smulkūs pakeitimai | Tas pats plius nedideli turinio ir sąsajos pakeitimai per sutartą laiko apimtį. | Reikia sutarti, kas laikoma smulkiu pakeitimu, kad riba nebūtų aiškinama kaskart iš naujo. |
| Priežiūra ir nuoseklus vystymas | Veikimas plius planuojamas naujų dalių kūrimas pagal prioritetų sąrašą. | Reikalauja jūsų dalyvavimo nustatant prioritetus; apimtis planuojama ciklais. |
| Tik reagavimas į sutrikimus | Įsitraukiama tik tada, kai kažkas nustoja veikti. | Prevencijos nėra, todėl sutrikimų būna daugiau; taisymas užima ilgiau dėl nesuprantamos būklės. |
| Perdavimas jūsų komandai | Dokumentacija, prieigų inventorius, mokymas ir laikinas palaikymas pereinant. | Terminuotas darbas su aiškiu pabaigos tašku, ne nuolatinis susitarimas. |
Kaip vyksta darbas
- 01
Būklės peržiūra ir prieigų inventorius
Pirma išsiaiškiname, kas realiai veikia: kokios versijos naudojamos, kur yra atsarginės kopijos ir ar jos kada nors buvo atkurtos. Tuo pačiu surašome prieigas ir jų savininkus. Be šio žingsnio bet koks atsakymo laikas būtų spėjimas.
- 02
Apimties ir reagavimo susitarimas
Užrašome, kokie darbai įeina, kokie neįeina ir kuo skiriasi atsakymo laikas nuo išsprendimo laiko. Atsakymo laiką galima planuoti; išsprendimo laikas priklauso nuo problemos, todėl jis aprašomas kaip eiga, o ne kaip pažadas.
- 03
Prevencija ir stebėjimas
Reguliariai atnaujinamos bibliotekos ir platformos versijos, tikrinamos atsarginės kopijos ir jų atkūrimas. Sutrikimų fiksavimas įjungiamas taip, kad problema būtų pastebėta anksčiau nei ją pastebi naudotojas.
- 04
Vystymas ir pasirengimas perdavimui
Pakeitimai planuojami ciklais pagal jūsų prioritetus, o dokumentacija atnaujinama tuo pačiu metu, ne pabaigoje. Taip perdavimas kitai komandai bet kuriuo momentu lieka įmanomas ir nėra atskiras projektas.
Kas lemia kainą ir trukmę
- Sistemos amžius ir naudojamų bibliotekų versijų atsilikimas – kuo didesnis atsilikimas, tuo daugiau darbo pirmajame etape.
- Reikalaujamas reagavimo laikas ir ar reikia darbo ne darbo valandomis.
- Ar priežiūra apima tik veikimą, ar ir naujų dalių kūrimą.
- Integracijų su išorinėmis sistemomis skaičius – kiekviena riba turi savo sutrikimų atvejus.
- Dokumentacijos ir testų būklė perėmimo metu – jų nebuvimas ilgina kiekvieną vėlesnį pakeitimą.
Ką verta apsvarstyti prieš pokalbį
- 01Ar priežiūra turi apimti tik veikimo išsaugojimą, ar ir naujų dalių kūrimą?
- 02Kokiu laiku realiai reikia reagavimo ir ar reikia darbo ne darbo valandomis?
- 03Kas šiandien turi prieigas prie domeno, prieglobos ir atsarginių kopijų?
- 04Ar atsarginė kopija kada nors buvo atkurta, ar tik kuriama?
- 05Kas nutinka susitarimui pasibaigus: kaip ir per kiek laiko perduodamos prieigos?
Aptarkime priežiūros apimtį
Pakanka parašyti, kokia sistema naudojama ir kas šiandien kelia daugiausia rizikos. Nesiųskite prisijungimų, slaptažodžių ar tikrų klientų duomenų – bendras aprašymas yra tinkamas pradinis taškas.