Prevod članka je bil pripravljen posebej za študente tečaja .
Poslanstvo Intercoma je narediti spletno poslovanje osebno. Nemogoče pa je prilagoditi izdelek, ko ne deluje. . Čas delovanja je ključnega pomena za uspeh našega poslovanja, ne le zato, ker nas naše stranke plačujejo, ampak tudi zato, ker jih uporabljamo . Če naša storitev ne deluje, dobesedno čutimo bolečino naših strank.
Nemoteno delovanje je odvisno od številnih dejavnikov, kot sta arhitektura programske opreme in kakovost vsakodnevnega dela. Vendar pa pogosto pride do tega, da na klice odgovarja oseba, ki je vedno v stiku . Ta tehnična podpora je lahko zmogljivo orodje, osredotočeno na stranke, ki združuje pomoč inženirjev s tem, kar stranke dobijo, ko kupijo vaš izdelek. Odpira tudi odlično priložnost za učenje in rast, saj so neuspehi in napake lahko dobro polje za vadbo veščin in razumevanje zapletenih delovnih mehanizmov.
Ostati »vedno v stiku« izven delovnega časa je škodljivo za vaše življenje.
Toda hkrati lahko »vedno povezani« škodljivo vpliva na vaše življenje. Na obvestilo, da je nekaj pokvarjeno, morate biti pripravljeni hitro in kompetentno odgovoriti. Tudi če te v tistem trenutku ne pokliče pozivnik, stanje "vedno vključeno" vzbuja občutek nelagodja, sam to vem iz lastnih izkušenj. Predvsem zaradi tega se poslabša kakovost spanja. Redno bivanje v območju dostopa kadar koli v dnevu lahko vodi v izgorelost, apatijo ali na splošno željo, da nikoli več ne vidimo računalnika.
Zgodovina stanja "vedno vzpostavljene povezave" v interkomu
V zelo zgodnjih dneh Intercoma je bil naš tehnični direktor Ciaran sam celotna ekipa za tehnično podporo XNUMX/XNUMX, tako v pisarni kot zunaj nje. Ko je Intercom rasel, je bila ustanovljena delovna skupina za pomoč Ciaranu. Kmalu zatem so nove razvojne ekipe začele ustvarjati številne nove funkcije in storitve ter že prevzele vse odgovornosti tehnične podpore.
V vsakem trenutku je bilo preveč ljudi »na liniji«.
Takrat se je ta pristop zdel nesmiseln, saj je bil preprost način za povečanje naše ekipe za tehnično podporo v danem trenutku, bil je v skladu z našimi vrednotami in je zadovoljil naše . Tako smo brez načrtov dobili štiri ali pet ekip, ki so redno kontaktirale stranke v prostem času. Preostale razvojne ekipe niso imele veliko težkih točk, ki bi lahko povzročile napako, zato so jih poklicali redko, če sploh kdaj.
Spoznali smo, da smo v situaciji, ko imamo mehanike tehnične podpore, na katere smo lahko ponosni, in številne kritične težave, ki smo jih želeli obravnavati, kot so:
- V vsakem trenutku je bilo preveč ljudi pripravljenih sprejeti izziv. Naša infrastruktura ni bila dovolj velika, da bi zahtevala vsaj pet razvojnih inženirjev, ki bi delali brez običajnih prostih dni.
- Kakovost naših opozoril in postopkov klicanja ni bila dosledna med ekipami, uporabili smo ad hoc postopke pregleda za nova in obstoječa opozorila o težavah. Navodila v priročniku (ki jih je treba upoštevati, ko se pojavi vprašanje) so bila večinoma opazna zaradi odsotnosti.
- Odvisno od skupine, za katero so inženirji delali, so imeli nasprotujoča si pričakovanja. Na primer, samo prva ekipa tehnične podpore je imela kakršno koli nadomestilo za dežurstva in prekinjene počitnice.
- Izkazalo se je, da obstaja splošna stopnja tolerance do nepotrebnih klicev ob neparnih urah.
- Navsezadnje ta vrsta dela ni za vsakogar. Življenjske okoliščine so včasih pokazale, da dežurstva na ljudi ne vplivajo najbolje.
Iskanje pravega stanja "vedno povezan"
Odločili smo se, da ustvarimo novo virtualno ekipo, ki bo opravljala delo tehnične podpore za vsako ekipo, ko ima prosti čas. Ekipo bodo sestavljali prostovoljci, ne naborniki iz katere koli ekipe v organizaciji. Inženirji v virtualni ekipi so se zamenjali približno vsakih šest mesecev in tedne preživeli »v stiku«. Na srečo nismo imeli težav z iskanjem dovolj prostovoljcev za sestavljanje virtualne ekipe.
Posledično se je naša ekipa za podporo zmanjšala s 30 ljudi na samo 6 ali 7.
Skupina se je nato dogovorila in opredelila, kako naj bi izgledali opozorila o težavah in opisi tekočih knjig, ter orisala postopek za posredovanje opozoril novi ekipi za podporo. Z modulom Terraform so identificirali vsa opozorila v kodi in za vsako spremembo začeli uporabljati strokovni pregled. Uvedli smo višino nadomestila za tedensko izmeno, ki je dežurnim zelo ustrezala. Ustvarili smo tudi eskalirano drugonivojsko ekipo, ki so jo sestavljali samo vodje. Ta ukaz bi moral biti edina točka stopnjevanja za inženirje tehnične podpore.
Imeli smo več mesecev trdega dela, v katerem smo vzpostavili ta proces, posledično zdaj ni ostalo v stiku 30 inženirjev kot prej, ampak le 6 ali 7. Med delovnim časom ekipe samostojno rešujejo težave s svojimi funkcijami ali službami, na ta čas običajno predstavlja največje število okvar, preostali čas pa za tehnično podporo skrbijo prostovoljci.
Kaj smo se naučili
Ko smo zagnali našo virtualno ekipo za tehnično podporo, smo pričakovali poplavo novih nalog, kot je raziskovanje vzrokov težav ali splošno srečanje za reševanje posamezne težave, ki je povzročila zrušitev. Vendar pa so naše razvojne ekipe prevzele polno odgovornost za dejavnike, ki so povzročili zrušitve, vsak kasnejši odziv pa je bil običajno takojšen ukrep. Prav tako smo se morali izogniti situaciji, v kateri bi bila naloga tehničnega svetovanja vrnjena ekipi, iz katere je prišla, da ne bi bili prisiljeni inženirjev stopiti v stik po urah.
Klici izven delovnega časa so se zmanjšali na manj kot 10 na mesec.
Formalno je bil naš postopek stopnjevanja redko uporabljen. Bolj splošno mnenje je bilo, da je inženirju neuradno pomagala ekipa, ki je bila trenutno na spletu, zlasti naši fantje v pisarni v San Franciscu. Veliko težav je bilo odpravljenih ali zmanjšanih s skupinskim delom in sprotnim reševanjem.
Inženirji v naši pisarni v San Franciscu se pridružijo ekipi kot celotna ekipa in presegajo redno tehnično podporo. Vključenih je bilo nekaj režijskih stroškov, vendar nam je razširitev članstva naše ekipe za podporo na več lokacijah šla v prid, saj se je izkazalo za dober način za vzpostavljanje odnosov, njihovo krepitev in učenje več o tehnološkem sklopu, s katerim vsi delamo.
V naših ekipah je delo razvijalcev interkomov postalo bolj usklajeno in z gotovostjo lahko govorimo o prednostih položaja sistemskega inženirja na naši spletni strani. , ki pravi, da ni potrebe, da ste vedno v stiku, če tega sami ne želite.
Skupaj s temeljnim delom stabilizacije in povečanja naših podatkovnih skladišč je stalna osredotočenost na reševanje težav privedla do zmanjšanja klicev izven delovnega časa na manj kot 10 na mesec. Na to številko smo zelo ponosni.
Še naprej si prizadevamo vzdrževati in izboljševati našo ekipo za tehnično podporo, in ko Intercom raste, bomo morda morali ponovno razmisliti o svojih odločitvah, kajti tisto, kar deluje danes, morda ne bo delovalo naslednjič, ko se bo število naših zaposlenih podvojilo. Vendar je bila ta izkušnja izjemno pozitivna za našo organizacijo, saj je močno izboljšala kakovost življenja naših razvojnih inženirjev, kakovost naših odzivov na izzive, predvsem pa izkušnje naših strank.
Vir: www.habr.com