Ar DI sistema paruošta kasdieniam darbui: šeši patikrinimai, kurių demonstracija neparodo

„Paruošta kasdieniam darbui“ yra bene dažniausiai be pagrindo vartojama frazė DI automatizavimo pasiūlymuose. Dažniausiai ji reiškia tik tai, kad demonstracija vieną kartą suveikė. Paruoštumą turėtų rodyti savybės, kurias galite patikrinti nebūdami techniniu specialistu. Pagal šį sąrašą vertiname ir savo pačių realiai veikiančias sistemas. Įteikite jį bet kuriam rangovui, taip pat ir mums, ir paprašykite prieš perdavimą patvirtinti kiekvieną punktą. Tai, kaip rangovas reaguoja į sąrašą, pasako beveik tiek pat, kiek jo atsakymai.

1. Patikimumas

Demonstracijos vyksta idealiomis sąlygomis. Realiame darbe sistema susiduria su API sutrikimais, netvarkingais el. laiškais ir dubliuotais webhook. Skirtumą rodo keturi dalykai.

• Pakartotiniai bandymai. Kai išorinė paslauga trumpam sutrinka, o taip nutinka visoms, darbo eiga bando dar kartą, užuot praradusi įrašą. Paklauskite, kas nutinka, jei 3 val. nakties CRM penkias minutes neveikia.
• Laiko limitai. Žingsnis, kuris be galo laukia lėtos paslaugos, užblokuoja viską, kas eilėje už jo.
• Nepavykusių įrašų tvarkymas (dead letter). Įrašas, kuris nepavyksta net po pakartotinių bandymų, patenka į matomą eilę, kur jį peržiūri žmogus. Paklauskite, kur patenka nepavykę įrašai ir kas juos tikrina.
• Idempotentiškumas, ilgas žodis paprastam pažadui: jei tas pats įvykis suveikia du kartus, klientas negauna dviejų sąskaitų. Paklauskite, kas nutinka, jei tas pats įvykis su tais pačiais duomenimis ateina du kartus. Dubliuoti webhook pasitaiko taip dažnai, kad juos laikome įprastu dalyku.

2. Kažkas sužino, kai sistema sugenda

Jei automatizacijos veikimo nematote, ji genda niekam nepastebint. Būtinas minimumas yra kiekvieno vykdymo žurnalas (kas atėjo, kas išėjo, kas nepavyko), kad klientui pasakius, jog negavo patvirtinimo, kas nors per kelias minutes galėtų išsiaiškinti kodėl. Apie gedimus turi būti pranešama ten, kur konkretus žmogus tikrai skaito: Slack, el. paštu, SMS žinute. Ataskaitų skydelis, kurio niekas neatidaro, nieko neapsaugo.

Pigiausias ankstyvas įspėjimas yra savaitinis vykdymų skaičius. Jei darbo eiga paprastai apdoroja 200 įrašų, o staiga tik 12, kažkas sugedo ankstesniame žingsnyje, ir kiekio pokytis leidžia tai pastebėti anksčiau nei klientas.

3. Kokybė

Visur, kur kalbos modelis rūšiuoja, rašo juodraščius ar ištraukia duomenis, turi būti realių atvejų su žinomais teisingais atsakymais testų rinkinys ir išmatuotas rezultatas. „Dažniausiai pataiko“ yra įspūdis. „94 iš 100 pagal Jūsų paskutinių trijų mėnesių realius el. laiškus“ yra rezultatas.

Prieš perdavimą sistema taip pat turi būti susidūrusi su Jūsų netvarkingais duomenimis: klientu, kuris rašo didžiosiomis raidėmis, sąskaita su trūkstamu lauku, šonu nuskenuotu PDF, atsakymu, kuriame cituojamas visas susirašinėjimas. Jei ji matė tik švarius pavyzdinius duomenis, tikrasis testas įvyks paleidimo dieną, su Jūsų klientais.

4. Sistemą galėtų perimti kitas specialistas

Patikrinimas paprastas. Ar kompetentingas specialistas, niekada nebendravęs su kūrėju, galėtų perskaityti dokumentaciją, suprasti, ką sistema daro, ją paleisti iš naujo ir pakeisti nustatymą? Jei viskas yra tik kūrėjo galvoje, Jūs nusipirkote ne sistemą, o priklausomybę nuo žmogaus.

Nustatymai, kuriuos norėsite keisti (el. laiškų šablonai, kainų ribos, gavėjų sąrašai), turi būti laikomi ten, kur juos galite redaguoti patys, kad nedidelis pakeitimas netaptų apmokamu užsakymu.

5. Nuosavybė

API raktai, automatizavimo platforma ir duomenų bazės registruoti Jūsų įmonės vardu ir apmokami Jūsų kortele. Repozitorijos ir darbo eigų eksportai laikomi ten, kur juos valdote Jūs. Perdavimo metu gaunate visus prisijungimus ir raktus, surašytus raštu; išsami versija yra dešimt dalykų, kuriuos turite gauti perdavimo metu. Jei rangovas rytoj dingtų, viskas toliau veiktų, o kitas pasamdytas specialistas galėtų perimti darbą. Patys ne kartą buvome tas kitas specialistas: ar taisymas truks savaitę, ar mėnesį, dažniausiai priklauso nuo to, ar ši pastraipa atitinka tiesą. Kai kūrėjas dingsta, sistemos perėmimas prasideda nuo paskyrų, ir jis įmanomas tik tada, jei jos priklauso Jums.

6. Po paleidimo

• Konkretus atsakingas žmogus. Vienas konkretus asmuo, Jūsų ar rangovo pagal priežiūros sutartį, kurioje įvardyta stebėsena ir taisymo terminas, kurio pareiga yra pastebėti, kai sistema veikia netinkamai. „Visi stebėsime“ reiškia, kad nestebės niekas.
• Mėnesio ataskaita su skaičiais. Vykdymų skaičius, gedimai, sutaupytos valandos ar apdoroti įrašai, veikimo kaina. Be jos sistema pamažu tampa viena iš tų automatizacijų, kurios techniškai dar veikia, bet praktiškai nieko nebedaro.

Kada sąrašas netaikomas

Scenarijui, kurį vienas žmogus penktadienio popietėmis paleidžia rankiniu būdu, nereikia nei nepavykusių įrašų eilės, nei mėnesio ataskaitos, ir mes jų nesiūlytume. Sąrašas skirtas viskam, kas veikia be žmogaus priežiūros ir susiję su klientais ar pinigais. Tarpiniais atvejais sprendžiama pagal aplinkybes. Mes stebėsenos linkę diegti daugiau nei mažiau, nes sugedusioms sistemoms, kurias vertinome, dažniausiai trūkdavo būtent jos.

Kaip juo naudotis

Nusiųskite jį kartu su užklausa pasiūlymui ir paklauskite, kurie punktai įeina į kainą, kurie kainuoja papildomai ir kuriuos rangovas laiko nereikalingais. Naudingi visi trys atsakymai. Jei rangovas sako, kad stebėsena „tokio dydžio projektui nereikalinga“, tikėtina, kad jo sistemos genda niekam nepastebint. Jei rangovas pažymi visus punktus, bet nė vieno negali paprastai paaiškinti, jis juos pažymėjo tik tam, kad parduotų.

Mūsų kuriamos sistemos atitinka visą sąrašą, po perdavimo taikoma 30 dienų klaidų garantija, o visos paskyros ir repozitorijos nuo pirmos dienos registruojamos kliento vardu. Jei Jūsų esamai automatizacijai trūksta kelių šių punktų, tam skirta mūsų DI sistemų taisymo paslauga.