Straipsnio vertimas buvo parengtas specialiai kurso studentams .
Intercom misija yra individualizuoti internetinį verslą. Bet jūs negalite suasmeninti produkto, kai jis neveikia. . Veikla yra labai svarbi mūsų verslo sėkmei ne tik todėl, kad klientai mums moka, bet ir todėl, kad mes patys naudojame . Jei mūsų paslauga neveikia, tiesiogine prasme jaučiame savo klientų skausmą.
Sklandus veikimas priklauso nuo daugelio veiksnių, tokių kaip programinės įrangos architektūra ir kasdienio darbo kokybė. Tačiau gana dažnai viskas susiveda į tai, kad į skambučius atsiliepia visada bendraujantis žmogus . Tokio tipo techninė pagalba gali būti galingas į klientą orientuotas įrankis, kuris sujungia inžinierių pagalbą su tuo, ką klientai gauna pirkdami jūsų produktą. Tai taip pat puiki galimybė mokytis ir augti, nes juk nesėkmės ir klaidos gali būti gera proga lavinti įgūdžius ir suprasti sudėtingus veikimo mechanizmus.
Buvimas „visada įjungtas“ ne darbo valandomis neigiamai veikia jūsų gyvenimą.
Tačiau tuo pat metu buvimas „visada įjungtas“ gali turėti neigiamos įtakos jūsų gyvenimui. Turite būti pasirengę greitai ir kompetentingai reaguoti į įspėjimą, kad kažkas sugedo. Net jei bet kuriuo momentu nesate ieškomas, buvimas „visada įjungtas“ gali sukelti nerimą, kaip žinau iš asmeninės patirties. Dėl to ypač stipriai pablogėja miego kokybė. Reguliarus buvimas prieigos zonoje bet kuriuo paros metu gali sukelti perdegimą, apatiją arba apskritai norą daugiau niekada nebematyti kompiuterio.
„Visada prijungto“ būsenos „Intercom“ istorija
Pačiomis „Intercom“ veiklos dienomis mūsų techninis direktorius Ciaran vienas visą parą, XNUMX dienas per savaitę, tiek biure, tiek už jo ribų, teikė visą techninės pagalbos komandą. „Intercom“ augant buvo sukurta darbo grupė, kuri padėtų Ciaranui. Netrukus po to naujos kūrėjų komandos pradėjo kurti daug naujų funkcijų ir paslaugų bei perėmė visas techninio palaikymo pareigas.
Bet kuriuo momentu buvo per daug budinčių žmonių.
Tuo metu toks požiūris atrodė nesąmoningas, nes tai buvo paprastas būdas akimirksniu išplėsti techninės pagalbos komandą, jis atitiko mūsų vertybes ir tiko mūsų . Galiausiai be jokių planų gavome keturias ar penkias komandas, kurios nuolat bendraudavo su klientais ne darbo valandomis. Likusios kūrimo komandos neturėjo daug sudėtingų problemų, dėl kurių galėjo kilti klaida, todėl joms buvo skambinama retai, jei iš viso.
Supratome, kad atsidūrėme tokioje situacijoje, kai turime techninės pagalbos mechaniką, kuria negalėjome didžiuotis, ir daug svarbių problemų, kurias norėjome išspręsti, pvz.:
- Bet kuriuo metu buvo per daug žmonių, pasiruošusių priimti iššūkį. Mūsų infrastruktūra nebuvo pakankamai didelė, kad be įprastų poilsio dienų dirbtų mažiausiai penki kūrimo inžinieriai.
- Mūsų pavojaus signalų ir skambučių procedūrų kokybė nebuvo vienoda visose komandose, todėl naudojome ad hoc procesus, kad peržiūrėtume naujus ir esamus įspėjimus apie problemas. Vadovėlyje pateiktos instrukcijos (kurios turi būti laikomasi, kai pranešama apie problemą) dažniausiai buvo pastebimos dėl to, kad jų nebuvo.
- Priklausomai nuo komandos, kurioje dirbo inžinieriai, jie turėjo prieštaringų lūkesčių. Pavyzdžiui, tik pati pirmoji techninės pagalbos komanda gavo kompensaciją už budinčias pamainas ir sutrikusius savaitgalius.
- Atrodė, kad bendras tolerancijos lygis nereikalingiems skambučiams nelyginėmis valandomis.
- Galiausiai, toks darbas tinka ne visiems. Gyvenimo aplinkybės kartais parodydavo, kad pareigų pamainos žmonėms nepadarė geriausio poveikio.
Tinkamos „visada įjungtos“ būsenos radimas
Nusprendėme sukurti naują virtualią komandą, kuri kiekvienai komandai atliktų techninio aptarnavimo darbus ne darbo valandomis. Komanda bus sudaryta iš savanorių, o ne šauktinių iš kokios nors organizacijos komandos. Virtualios komandos inžinieriai keisdavosi maždaug kas šešis mėnesius ir praleisdavo savaites „pagal iškvietimą“. Laimei, mums nebuvo sunku rasti pakankamai savanorių, kad suburtume virtualią komandą.
Dėl to mūsų palaikymo komanda sumažėjo nuo 30 žmonių iki 6 ar 7.
Tada komanda susitarė ir apibrėžė, kaip turėtų atrodyti problemų įspėjimai ir aprašymai, ir apibūdino įspėjimų persiuntimo naujajai palaikymo komandai procesą. Jie apibrėžė visus įspėjimus kode naudodami Terraform modulį ir kiekvienam pakeitimui pradėjo naudoti tarpusavio peržiūrą. Įvedėme budinčius pareigūnus gana tenkinantį savaitinės pamainos atlyginimo lygį. Taip pat sukūrėme antrojo lygio eskaluotą komandą, kurią sudarė tik vadovai. Ši komanda turėtų būti vienintelė techninės pagalbos inžinierių eskalavimo vieta.
Turėjome keletą mėnesių sunkaus darbo, per kurį sukūrėme šį procesą, todėl dabar budėjo ne 30 inžinierių, kaip anksčiau, o tik 6 ar 7. Darbo valandomis komandos savarankiškai sprendžia iškilusias problemas, susijusias su savo funkcijomis arba paslaugos, ant Šiuo metu dažniausiai įvyksta daugiausiai gedimų, tačiau kitu metu techninę pagalbą teikia savanoriai.
Ką išmokome
Įkūrę virtualią techninio palaikymo komandą, tikėjomės naujų užduočių, pvz., problemų priežasčių tyrimo ar susibūrimo, kad išspręstume vieną problemą, dėl kurios nutrūko, antplūdžio. Tačiau mūsų kūrėjų komandos prisiėmė visą atsakomybę už veiksnius, sukėlusius gedimus, ir bet koks tolesnis atsakas paprastai buvo nedelsiant. Taip pat reikėjo išvengti situacijos, kai techninės konsultacijos užduotis būtų siunčiama atgal komandai, iš kurios ji atėjo, kad nebūtų priversti inžinierių susisiekti po darbo valandų.
Skambučių po darbo valandų skaičius sumažėjo iki mažiau nei 10 per mėnesį.
Mūsų eskalavimo procesas buvo retai naudojamas formaliai. Labiau paplitęs įsitikinimas, kad inžinieriui neoficialiai padėjo komanda, kuri šiuo metu buvo prisijungusi, ypač mūsų vaikinai San Francisko biure. Daugelis problemų buvo pašalintos arba sumažintos dirbant komandoje ir jas sprendžiant greitai.
Mūsų San Francisko biuro inžinieriai prisijungė prie komandos visu etatu ir neapsiribojo įprasta technine pagalba. Susidūrėme su tam tikromis pridėtinėmis išlaidomis, tačiau palaikymo komandos narystės paskirstymas keliuose biuruose buvo naudingas, nes pasirodė esąs geras būdas užmegzti ryšius, juos sustiprinti ir sužinoti daugiau apie technologijų krūvą, su kuria visi dirbame.
Intercom kūrėjų darbas mūsų komandose tapo nuoseklesnis, todėl galime drąsiai kalbėti apie sistemų inžinieriaus naudą mūsų svetainėje. , teigdamas, kad nebūtina visada būti prisijungusiam, nebent jūs to norite.
Be pagrindinių darbų, skirtų stabilizuoti ir išplėsti mūsų duomenų saugyklas, nuolatinis dėmesys problemų sprendimui parodė, kad skambučių ne darbo valandomis skaičius sumažėjo iki mažiau nei 10 per mėnesį. Labai didžiuojamės šiuo skaičiumi.
Mes ir toliau dirbame, kad išlaikytume ir tobulintume savo techninės pagalbos komandą, o augant „Intercom“ gali tekti persvarstyti savo sprendimus, nes tai, kas veikia šiandien, nebūtinai veiks kitą kartą, kai mūsų darbuotojai padvigubės. Tačiau ši patirtis buvo nepaprastai teigiama mūsų organizacijai ir labai pagerino mūsų plėtros inžinierių gyvenimo kokybę, atsakymų į skambučius kokybę, o svarbiausia – klientų patirtį.
Šaltinis: www.habr.com