Kuinka muutimme aina yhteyden tilan estääksemme burnoutin

Artikkelin käännös on tehty erityisesti kurssin opiskelijoille "DevOps-käytännöt ja -työkalut".

Kuinka muutimme aina yhteyden tilan estääksemme burnoutin

Intercomin tehtävänä on personoida verkkoliiketoimintaa. Mutta et voi personoida tuotetta, jos se ei toimi. miten. Suorituskyky on kriittinen liiketoimintamme menestykselle, ei vain siksi, että asiakkaamme maksavat meille, vaan myös siksi, että käytämme itse tuotteesi kanssa. Jos palvelumme ei toimi, tunnemme kirjaimellisesti asiakkaidemme tuskan.

Sujuva toiminta riippuu monista tekijöistä, kuten ohjelmistoarkkitehtuurista ja päivittäisen työn laadusta. Kuitenkin melko usein kaikki johtuu siitä, että aina yhteydessä oleva henkilö vastaa puheluihin Hakulaite. Tällainen tekninen tuki voi olla tehokas asiakaslähtöinen työkalu, joka yhdistää insinöörien avun siihen, mitä asiakkaat saavat ostaessaan tuotteesi. Tämä on myös loistava tilaisuus oppimiseen ja kasvuun, sillä epäonnistumiset ja virheet voivat olla hyvä tilaisuus harjoitella taitoja ja ymmärtää monimutkaisia ​​toimintamekanismeja.

"Aina päällä" oleminen työajan ulkopuolella vaikuttaa haitallisesti elämääsi.

Mutta samaan aikaan "aina päällä" oleminen voi vaikuttaa haitallisesti elämääsi. Sinun on oltava valmis reagoimaan nopeasti ja asiantuntevasti varoituksiin, että jokin on rikki. Vaikka sinua ei haettaisi minäkään hetkenä, "aina päällä" oleminen voi aiheuttaa ahdistusta, kuten tiedän henkilökohtaisesta kokemuksesta. Tästä johtuen unen laatu heikkenee erityisen voimakkaasti. Säännöllinen pääsyvyöhykkeellä oleminen mihin aikaan päivästä tahansa voi johtaa loppuunuuttumiseen, apatiaan tai yleensä haluun olla koskaan enää näkemättä tietokonetta.

Intercomin "aina yhteydessä" -tilan historia

Intercomin alkuaikoina tekninen johtajamme Ciaran tarjosi yksin koko XNUMX/XNUMX teknisen tuen tiimille sekä toimistossa että sen ulkopuolella. Intercomin kasvaessa luotiin työryhmä auttamaan Ciarania. Pian sen jälkeen uudet kehitystiimit alkoivat luoda monia uusia ominaisuuksia ja palveluita, ja he ottivat hoitaakseen kaikki teknisen tuen vastuut.

"Päivystäviä" oli liian monta joka hetki.

Tuolloin tämä lähestymistapa tuntui järjettömältä, koska se oli helppo tapa skaalata teknisen tukitiimimme hetkessä, se vastasi arvojamme ja sopi meille. omistajuuden tunnetta. Lopulta ilman suunnitelmia päädyimme neljään tai viiteen tiimiin, jotka ottivat säännöllisesti yhteyttä asiakkaisiin heidän vapaa-aikanaan. Muilla kehitystiimeillä ei ollut monia monimutkaisia ​​ongelmia, jotka voisivat aiheuttaa virheen, joten niille soitettiin harvoin, jos koskaan.

Ymmärsimme, että olimme tilanteessa, jossa meillä oli teknisen tuen mekaniikka, josta emme voineet olla ylpeitä, ja useita kriittisiä ongelmia, jotka halusimme korjata, kuten:

  • Liian monet ihmiset olivat valmiita ottamaan haasteen vastaan ​​milloin tahansa. Infrastruktuurimme ei ollut tarpeeksi suuri vaatimaan vähintään viisi kehitysinsinööriä työskentelemään ilman säännöllisiä vapaapäiviä.
  • Hälytysten ja soittomenettelyjemme laatu ei ollut johdonmukainen eri tiimeissä, ja käytimme tilapäisiä prosesseja uusien ja olemassa olevien ongelmahälytysten tarkistamiseen. Ohjekirjan ohjeet (joita on noudatettava, kun niistä ilmoitetaan ongelmasta) olivat enimmäkseen silmiinpistäviä niiden puuttuessa.
  • Riippuen tiimistä, jossa insinöörit työskentelivät, heillä oli ristiriitaisia ​​odotuksia. Esimerkiksi vain ensimmäisellä teknisen tuen tiimillä oli korvauksia päivystysvuoroista ja häiriintyneistä viikonloppuista.
  • Näytti olevan yleinen toleranssi tarpeettomille puheluille parittomina aikoina.
  • Lopuksi, tämäntyyppinen työ ei sovi kaikille. Elämänolosuhteet osoittivat joskus, että työvuorot eivät vaikuttaneet ihmisiin parhaiten.

Oikean "aina päällä" -tilan löytäminen

Päätimme luoda uuden virtuaalisen tiimin, joka tekisi jokaiselle tiimille teknistä tukea työajan ulkopuolella. Ryhmä koostuu vapaaehtoisista, ei varusmiehistä mistään organisaation joukkueesta. Virtuaalitiimin insinöörit vaihtuivat noin kuuden kuukauden välein viettäen viikkoja "päivystykseen". Onneksi meillä ei ollut ongelmaa löytää tarpeeksi vapaaehtoisia kokoamaan virtuaalisen tiimin.

Tämän seurauksena tukitiimimme määrä väheni 30 henkilöstä vain 6 tai 7 henkilöön.

Tämän jälkeen tiimi sopi ja määritti, miltä ongelmavaroitusten ja -kuvausten tulisi näyttää ohjekirjassa, ja kuvaili prosessia hälytysten välittämiseksi uudelle tukitiimille. He määrittelivät kaikki koodin hälytykset Terraform-moduulin avulla ja alkoivat käyttää vertaisarviointia jokaisessa muutoksessa. Otimme käyttöön päivystäviä upseereita varsin tyydyttävän viikkovuoron korvaustason. Loimme myös toisen tason eskaloidun tiimin, joka koostui vain esimiehistä. Tämän tiimin tulisi olla teknisen tuen insinöörien ainoa eskalaatiopiste.

Meillä oli useita kuukausia kovaa työtä, jonka aikana perustimme tämän prosessin, minkä seurauksena insinöörejä ei ollut nyt 30 päivystyksessä kuten ennen, vaan vain 6 tai 7. Työaikana tiimit ratkaisevat itsenäisesti toimintoihin liittyvät ongelmat tai palvelut, on Tämä on aika, jolloin yleensä tapahtuu eniten vikoja, mutta muina aikoina teknistä tukea tarjoavat vapaaehtoiset.

Mitä opimme

Kun käynnistimme virtuaalisen teknisen tukitiimimme, odotimme uusia tehtäviä, kuten ongelmien syiden tutkimista tai kokoontumista yhteen ratkaisemaan yksittäinen käyttökatkon aiheuttanut ongelma. Kehitystiimimme ottivat kuitenkin täyden vastuun epäonnistumisen aiheuttaneista tekijöistä, ja kaikki myöhemmät vastaukset olivat tyypillisesti välittömiä. Meidän piti myös välttää tilanne, jossa tekninen konsultointitehtävä lähetettäisiin takaisin tiimille, josta se tuli, jotta insinöörejä ei pakotettaisi ottamaan yhteyttä työajan jälkeen.

Työajan jälkeisten puheluiden määrä on pudonnut alle kymmeneen kuukaudessa.

Eskalointiprosessiamme käytettiin harvoin muodollisesti. Yleisempi uskomus oli, että insinööriä auttoi epävirallisesti tällä hetkellä verkossa ollut tiimi, erityisesti kaverimme San Franciscon toimistossa. Monet ongelmat poistettiin tai vähennettiin tiimityöskentelyn ja niiden nopean ratkaisemisen avulla.

San Franciscon toimistomme insinöörit liittyivät tiimiin kokopäiväisesti ja ylittivät tavanomaisen teknisen tuen. Meillä oli joitain yleiskustannuksia, mutta tukitiimimme jäsenyyden jakaminen useisiin toimistoihin auttoi meitä, koska se osoittautui hyväksi tapaksi rakentaa suhteita, vahvistaa niitä ja oppia lisää teknologiasta, jonka kanssa työskentelemme.

Intercom-kehittäjien työstä on tullut entistä johdonmukaisempaa tiimeissämme, ja voimme luottavaisin mielin puhua järjestelmäinsinöörin eduista sivustollamme Työpaikat, jossa todetaan, että sinun ei tarvitse olla aina yhteydessä, ellet halua olla.

Tietovarastoidemme vakauttamiseksi ja skaalaamiseksi tehdyn perustavanlaatuisen työn ohella jatkuva keskittyminen ongelmanratkaisuun on johtanut siihen, että tunnin ulkopuolisten puheluiden määrä on laskenut alle kymmeneen kuukaudessa. Olemme erittäin ylpeitä tästä numerosta.

Jatkamme työtä teknisen tukitiimimme ylläpitämiseksi ja parantamiseksi, ja Intercomin kasvaessa saatamme joutua harkitsemaan päätöksiämme uudelleen, koska se, mikä toimii tänään, ei välttämättä toimi seuraavan kerran, kun henkilöstömme kaksinkertaistuu. Tämä kokemus on kuitenkin ollut organisaatiollemme erittäin myönteinen ja parantanut huomattavasti kehitysinsinööriemme elämänlaatua, puheluihin vastaamisemme laatua ja ennen kaikkea asiakkaidemme kokemusta.

Lähde: will.com

Lisää kommentti