Laisvai samdomas specialistas dingo, o automatizacija sugedo: pirmiausia susigrąžinkite prieigą

Automatizacija mėnesius veikė gerai. Tada kažkas sugedo, parašėte ją sukūrusiam žmogui ir negavote atsakymo. Savaitę jokio atsakymo. Galbūt vieną „šiuo metu užimtas, pažiūrėsiu kitą savaitę“, ir tiek. Tuo tarpu sistema veikia tik iš dalies, nesate tikri, su kuo ji susijusi, ir net nežinote, ar galėtumėte prisijungti pažiūrėti.

Pusė taisymų, kuriuos vertinome, prasidėjo būtent taip: kūrėjas dingęs, o visos paskyros jo vardu. Situaciją galima ištaisyti, ir dažniausiai nepradedant visko iš naujo. Tačiau tvarka svarbi, o noras iškart pradėti taisyti yra klaidingas pirmas žingsnis.

Kai laisvai samdomas specialistas dingo, pirmiausia paskyros

Surašykite visas paskyras, su kuriomis dirba sistema: automatizavimo platformą (n8n, Make, Zapier), serverį (VPS, Railway, debesų paskyrą), domeną ir DNS, AI tiekėją, duomenų bazes ir kiekvieną prijungtą paslaugą, pavyzdžiui, CRM, kalendorių ir tai, kas siunčia el. laiškus. Apie kiekvieną atsakykite į vieną klausimą: ar kas nors Jūsų įmonėje gali prisijungti šiandien?

Paprastai atsakymai pasiskirsto į kelias grupes. Paprasčiausios yra Jums priklausančios paskyros, prie kurių kūrėjas turėjo prieigą. Pakeiskite slaptažodžius, pakeiskite API raktus, pašalinkite jo naudotoją, ir viskas.

Pavojingiausia grupė yra kūrėjo vardu registruotos paskyros, kuriose veikia Jūsų verslo procesai. Workflow yra jo n8n ar Make paskyroje, arba OpenAI raktas susietas su jo kortele. Jei jis nustoja mokėti, baigiasi bandomasis laikotarpis ar jis, tvarkydamasis, ištrina paskyrą, Jūsų automatizacija dingsta be jokio įspėjimo. Išsiųskite vieną aiškią žinutę: perkelkite nuosavybę arba eksportuokite workflow, už valandą Jūsų laiko sumokėsime, terminas toks. Stebėtinai daug dingusių laisvai samdomų specialistų šią vieną užduotį atlieka, nes ji leidžia tvarkingai užbaigti bendradarbiavimą. O jei jie tikrai dingo, eksportas svarbus mažiau, nei atrodo. Prijungtos paslaugos yra Jūsų. Iš naujo sukurtas workflow, nukreiptas į Jūsų CRM ir kalendorių, atkuria viską, išskyrus logiką, o logiką atkurti padeda dokumentacijos žingsnis.

Dar būna paskyrų, kurios, įtariate, egzistuoja, bet jų nerandate. Įmonės pašto dėžutėse paieškokite registracijos ir sąskaitų laiškų iš įprastų platformų. Mokėjimų laiškai yra Jūsų sistemos žemėlapis.

Visa tai padarykite prieš liesdami ką nors techninio.

Pirmiausia žurnalai ir įspėjimai, tik tada pataisymai

Šiuo metu nematote, ką sistema daro, todėl negalite pasakyti, ar pakeitimas padeda, ar kenkia. Žurnalai, įspėjimai ir paskirtas žmogus, kuris juos skaito, yra realiam naudojimui paruoštos sistemos kontrolinio sąrašo pagrindas, o perimta sistema paprastai neturi nė vieno iš jų. Prieš pirmą pataisymą:

• Įjunkite vykdymų žurnalus platformoje ir patikrinkite saugojimo nustatymą. Kai kurios nesėkmingus vykdymus saugo tik kelias dienas.
• Gedimus nukreipkite į Slack kanalą ar pašto dėžutę, kurią žmogus skaito kasdien, ir įsitikinkite, kad kas nors tikrai skaito.
• Užsirašykite dabartinį gedimų dažnį: kiek vykdymų per dieną, kiek gedimų per dieną. Tai Jūsų atskaitos taškas. Po savaitės jis parodys, ar padėtis gerėja, o šiandien parodo, ar sistema daugiausia veikia, ar daugiausia neveikia, ir nuo to priklauso, ką daryti toliau.
• Prieš keisdami bet kurį workflow, padarykite jo ekrano nuotrauką.

Tai atrodo kaip delsimas, bet iš tikrųjų sutaupo laiko: kai koks nors pataisymas tyliai sugadins ką nors kita, o nedokumentuotoje sistemoje taip nutiks, tai pamatysite būtent iš atskaitos taško.

Dokumentacija

Atidarykite kiekvieną workflow ir paprastais žodžiais užrašykite, kas jį paleidžia, iš kurių paslaugų jis skaito ir į kurias rašo ir ką jis daro, kai viskas veikia. Kiekvienam workflow užtenka vienos pastraipos. Pažymėkite viską, kas netikėta, ypač workflow, apie kuriuos niekas nežinojo (tokių rasite), ir į kodą įrašytas reikšmes, pavyzdžiui, el. pašto adresus ir skaičiuoklių ID, paslėptus logikos viduryje.

Taip sudarote žemėlapį, su kuriuo kitas žingsnis tampa saugus, ir nebepriklausote nuo to, ką žino tik vienas nepasiekiamas žmogus.

Stabilizuokite, tada tobulinkite

Pirmiausia sutvarkykite tai, kas skubu: sugedusį vykdymą, pasibaigusį prisijungimą, neveikiančią integraciją. Mažiausias įmanomas pakeitimas, patikrintas pagal atskaitos tašką. Nemaišykite patobulinimų su stabilizavimu. „Kol jau esame viduje“ yra būdas, kaip vienos dienos pataisymas virsta trijų savaičių prastova. Kai sistema savaitę ar dvi veikia be gedimų, tada pridėkite pakartojimus, klaidų apdorojimą ir pertvarkymą, kurio jai greičiausiai reikia.

Kai naujas tiekėjas siūlo viską perkurti

Kai ateina kitas laisvai samdomas specialistas ar agentūra, atkreipkite dėmesį į štai ką: jie dešimt minučių pažiūri į esamą sistemą ir pareiškia, kad tai netikęs darbas, kurį reikia perkurti nuo nulio, dar šią savaitę, jų mėgstamomis technologijomis. Kartais perkūrimas yra teisingas sprendimas, ir kai taip yra, tai pasakome diagnostikoje, nes kriterijus, ar sugedusią sistemą taisyti, ar kurti iš naujo, yra tai, ar kas nors gali įvardyti sugedusį pagrindą. Bet profesionalas prie tokios išvados prieina pirmiausia supratęs, kas yra, ir gali konkrečiai pasakyti, kas negerai dabartiniame sprendime ir kodėl jį taisyti brangiau nei pakeisti. „Su šiuo įrankiu nedirbu“ yra asmeninis pasirinkimas, o ne argumentas. Pasiūlymas kurti iš naujo pirmą dieną, kai dar net neišspręstas prieigos klausimas, yra pardavimas, ir jis vidutinę problemą paverčia didele sąskaita ir kelių savaičių prastova.

Dvi taisyklės kitai sistemai

Samdyti laisvai samdomą specialistą buvo normalu, o pasirinkimas tarp laisvai samdomo specialisto, agentūros ir savo darbuotojo priklauso nuo to, kas po šešių mėnesių vis dar bus šalia, o ne nuo įgūdžių. Trūko dviejų taisyklių. Visi raktai ir workflow nuo pirmos dienos yra Jums priklausančiose paskyrose, o kūrėjas pakviečiamas kaip naudotojas. Ir dokumentacija yra apmokamas rezultatas, todėl sistema nelaikoma baigta, kol nepažįstamas žmogus negalėtų jos valdyti pagal dokumentaciją. Abi taisyklės yra perdavimo kontroliniame sąraše, kurį naudojame baigdami kiekvieną sistemą. Įrašykite jas į sutartį prieš kito projekto pradžią, ir dingęs kūrėjas taps tik nepatogumu.

Viena išlyga. Jei sistema nedidelė, vienas Zap ar dviejų mazgų workflow, praleiskite žurnalų ir dokumentacijos žingsnius ir dar šią popietę perkurkite ją savo paskyroje; aukščiau aprašyta tvarka skirta sistemoms, kurių neįmanoma apžvelgti iš karto.

Jei norite, kad perėmimą atliktų žmonės, kurie tai daro reguliariai, siūlome raštišką diagnostiką už 450 €. Per dvi darbo dienas gaunate aprašą, kas yra, kokios būklės, kurių prieigų trūksta, ir fiksuotą stabilizavimo kainą, o ši suma įskaitoma į darbo kainą. Dauguma perėmimų kainuoja 1 400-3 700 € ir užtrunka 1-2 savaites. Pradėkite nuo mūsų taisymo paslaugos arba papasakokite, su kuo susiduriate.