Sprendimas prieš darbą
Technologijų auditas ir konsultacijos
Dažniausiai auditas užsakomas ne todėl, kad reikia dokumento, o todėl, kad reikia priimti sprendimą: perrašyti ar taisyti, keisti tiekėją ar likti, pradėti kūrimą dabar ar palaukti. Tokiam sprendimui reikia nešališkos nuomonės, todėl šis darbas atskirtas nuo įgyvendinimo. Jei išvada bus, kad esama sistema tinkama arba kad darbo pradėti neverta, tai ir bus išvada – tai dažnas ir visiškai normalus rezultatas.
Aptarti vertinimo apimtįTrumpai: kas tai yra ir kas ne
Tai vertinimas ir rekomendacija, o ne darbų pradžia. Gaunate atsakymą į konkretų klausimą, pagrindimą ir aprašytas alternatyvas su jų rizikomis – tokia forma, kad sprendimą galėtų priimti ir tas, kas nedirba su technologijomis kasdien. Įgyvendinimas yra atskiras sprendimas, ir jį galite atlikti su bet kuo. Vertinimas nėra pasiūlymo dalis ir nėra pardavimo pokalbis su priedu.
Kada vertinimas yra tinkamas
- Reikia pasirinkti tarp esamos sistemos taisymo ir kūrimo iš naujo, o abi pusės skirtingai vertina riziką.
- Perimama sistema, kurios istorijos niekas nežino, ir reikia suprasti, kas joje yra.
- Prieš didesnę investiciją norima nešališko vertinimo iš žmogaus, kuris jos neįgyvendins.
- Yra pasikartojantys sutrikimai ar greičio problemos, bet neaišku, ar priežastis architektūroje, ar naudojime.
Kada pakanka paprastesnio sprendimo
- Problema jau žinoma ir aiškiai apibrėžta – tada vertinimas tik atidės sprendimą, kurį galima priimti dabar.
- Reikia tęstinio darbo su esama sistema – tam tinkamesnė priežiūra ir vystymas.
- Klausimas yra dėl matomumo paieškoje – tada tikslingiau SEO darbas, kuriame techninė patikra jau įeina.
Nuo sprendimo iki išvados
Vertinimas apibrėžiamas pagal sprendimą, kurį reikia priimti, o ne pagal patikros sąrašą. Žemiau iliustraciniai pavyzdžiai. Tai ne kainų lentelė ir ne pažadas dėl išvados turinio – išvada priklauso nuo to, kas bus rasta.
| Sprendimas, kurį reikia priimti | Kas tikrinama | Ką gaunate |
|---|---|---|
| Taisyti ar kurti iš naujo | Kodo ir duomenų būsena, priklausomybės, kiek sistemos dalių galima atskirti ir keisti palaipsniui. | Rekomendaciją su etapais ir sąlygomis, kada kūrimas iš naujo pasiteisina, o kada ne. |
| Ar perimti nežinomą sistemą | Kas yra kode, kokios prieigos ir teisės, ko trūksta, kad sistemą būtų galima prižiūrėti. | Perėmimo sąlygų sąrašą ir žinomas rizikas, įskaitant tas, kurių išspręsti negalime. |
| Kodėl sistema stringa | Greičio ir stabilumo elgesys, duomenų bazės naudojimas, kur laikas realiai praleidžiamas. | Priežasčių sąrašą pagal poveikį, atskiriant architektūrą nuo konfigūracijos ir nuo naudojimo. |
| Ar techninė būsena leidžia būti randamiems | Indeksavimo kliūtys, adresų struktūra, nukreipimai, dublikatai, atsako laikas. | Kliūčių sąrašą pagal svarbą; jei kliūčių nėra, tai taip pat išvada. |
| Ar planas apskritai įgyvendinamas | Apimtis, prielaidos, priklausomybės nuo trečiųjų šalių ir kas nutinka, jei jos nepasitvirtina. | Nešališką vertinimą, įskaitant rekomendaciją nepradėti arba pradėti mažesne apimtimi. |
Kaip vyksta darbas
- 01
Sprendimo apibrėžimas
Pirma susitariame, kokį sprendimą vertinimas turi palengvinti ir kas jį priims. Be šito auditas tampa bendrų pastebėjimų sąrašu, kurio niekas nenaudoja. Čia taip pat aprašoma, ko vertinimas neapims.
- 02
Patikra su prieigomis
Peržiūrime kodą, duomenų struktūrą, aplinkas ir tai, kaip sistema naudojama kasdien. Kalbamės su tais, kurie ją naudoja – dalis svarbiausių dalykų kode nematoma. Prieigos suteikiamos tik tokios, kokių reikia, ir grąžinamos baigus.
- 03
Išvada ir alternatyvos
Aprašome, kas rasta, kokį poveikį tai turi ir kokios yra galimybės su jų rizikomis bei apytikre apimtimi. Alternatyvos aprašomos sąžiningai, įskaitant variantą nieko nedaryti ir variantą rinktis kitą tiekėją, jei taip būtų teisingiau.
- 04
Sprendimo pokalbis
Išvada pristatoma sprendimą priimantiems žmonėms suprantama kalba, kad būtų galima užduoti klausimus. Įgyvendinimas nėra šio darbo dalis ir nėra jo tikslas; jei nuspręsite jį patikėti mums, tai atskiras susitarimas.
Kas lemia kainą ir trukmę
- Kiek konkretus yra sprendimas – vienas aiškus klausimas vertinamas gerokai greičiau nei bendra būsena.
- Sistemos apimtis ir ar yra dokumentacijos; jos nebuvimas didžiąją laiko dalį paverčia tyrimu.
- Ar galima gauti prieigas ir pasikalbėti su naudotojais, ar vertinama tik iš kodo.
- Ar reikia įvertinti duomenų kokybę, ar pakanka struktūros vertinimo.
- Ar išvadą reikia pristatyti platesnei grupei, ar pakanka dokumento.
Ką verta apsvarstyti prieš pokalbį
- 01Kokį sprendimą reikia priimti ir iki kada?
- 02Kas priims sprendimą ir kokios informacijos jam trūksta?
- 03Ar galima suteikti prieigą prie kodo ir aplinkų vertinimo laikui?
- 04Kas šiandien naudoja sistemą ir su kuo galima pasikalbėti?
- 05Kokį variantą jau laikote tinkamiausiu ir kodėl?
Aptarkime vertinimo apimtį
Pakanka aprašyti sprendimą, kurį reikia priimti, ir kas jį priims. Jei paaiškės, kad vertinimo nereikia ir atsakymas jau žinomas, tai ir pasakysime.