Noen ganger står en teknisk støtteingeniør overfor et vanskelig valg: å bruke "Vi er for en høy servicekultur!"-dialogmodellen. eller "Trykk på knappen og du vil få resultatet"?
...Etter å ha brukket vingen laget av bomullsull,
La oss ligge i skyene, som i krypter.
Vi diktere er sjelden helgener,
Vi diktere er ofte blinde.
(Oleg Ladyzhensky)
Å jobbe i teknisk støtte betyr ikke bare morsomme historier om selvhoppingstid og GPS-enhjørninger, og ikke engang bare detektivoppgaver i stil med Hercule Poirot.
Teknisk støtte er først og fremst kommunikasjon, og kommunikasjon betyr mennesker, og blant våre kunder er det svært forskjellige karakterer:
- Tyskeren, som jobber fra en kafé rett overfor kontoret sitt i Berlin, har virkelig nordisk selvkontroll, ideell ro, et nøye kalibrert nettverk, en omfattende serverflåte og den kognitive evnen til å sette opp og vedlikeholde alt dette på A+. Forespørsler fra ham forårsaker vanligvis samme reaksjon som den siste dumplingen på en tallerken i et stort selskap og lyset blir slått av til feil tid.
- En brite som har endret to selskaper i løpet av de siste 5 årene, men ikke hans stil med å jobbe med support. Enten løper de fra sakene hans som byllepesten, eller så tar de dem, og forutsetter på forhånd all «sjarmen» ved å jobbe med denne personen, fordi han uten forvarsel kan ta kontroll over en ekstern økt (for å sjekke e-posten hans, noen ganger personlig), legger press på ingeniører og ledelse over de minste bagateller og til slutt, like plutselig lukke søknader med kommentaren "DUPLICATE".
- En indianer med et flerstavelsesnavn som ikke kan uttales, som tilbakeviser alle mytene om indisk IT: høflig, rolig, kompetent, leser dokumentasjon, lytter til rådene fra en ingeniør og alltid gjør alt selv, eier av en elegant turban (ja, vi fant det på Facebook) og perfekt Oxford-uttale.
Hver ingeniør kan tenke på omtrent fem slike "navn"-klienter, uten engang å tenke for mye på det. Vi skremmer nykommerne våre med noen («hvis du oppfører deg dårlig på laboratoriet, kommer det en kvinne og!..»), med noen skryter vi («og jeg har allerede 5 søknader med N. stengt!»). Og som oftest husker og forstår vi til og med at positive og negative eksempler bare er vår oppfatning, og det følger av kommunikasjon, vår med klienter og klienter med oss.
Og denne kommunikasjonen kan være veldig annerledes.
Vi skrev en gang om , og nå vil jeg vise hvordan dette skjer med et levende eksempel.
Her er et godt eksempel fra to år siden: klientens reaksjon på de "tradisjonelle" trinnene for feilsøking fra ingeniørens og ingeniørens side på klientens kommunikasjonsstil.
Sak om fragmentering
Så her er tilfellet: En svært erfaren og teknisk kunnskapsrik kunde åpner en kundestøttebillett og stiller et direkte spørsmål, og gir mange detaljer for å beskrive situasjonen.
Jeg tok meg friheten til å gjøre korrespondansen til en dialog, og bevare stiltrekkene.
Klient (K): - God ettermiddag, sir. Mitt navn er Marco Santino, vi brukte dine beste praksis og installerte den nyeste teknologien anbefalt av deg, men vi ser at ytelsen til systemet blir kritisk lav på grunn av høy fragmentering. Fortell meg, er dette normalt?
Ingeniør (jeg): - Hei, Marco! Jeg heter Ignat, og jeg skal hjelpe. Skjer dette alltid? Har du prøvd å defragmentere?
(K): – Kjære Ignat! Ja, dette dukker alltid opp. Vi prøvde å defragmentere, men dessverre, det tar for mye tid når systemet er helt inaktivt, og det er derfor ikke mulig.
(I): - Hør her, av en eller annen grunn finner jeg ikke denne beste praksisen. Hvor fant du ham? Og kanskje vi burde gjøre litt defragmentering likevel, ikke sant?
(K): – Kjære Ignat! Med forståelse for at du ikke tar problemet vårt på alvor og har problemer med å holde deg tilbake fra et direkte snarere enn politisk korrekt svar, vil vi likevel prøve å svare deg. Vi har ikke din erfaring (vi har bare vært innen IT siden 1960), og vi er veldig takknemlige for ditt arbeid og innsats for å utdanne oss. Beste praksis ble delt med oss av produktsjefene dine under middagen i Barcelona, og jeg sendte deg en lenke til dem. Vi spør deg direkte, Ivan: er denne situasjonen normal? Hvis du ikke er interessert i å snakke med oss, vennligst finn noen som kan hjelpe oss.
(I): — Marco, av en eller annen grunn fant jeg ikke disse beste praksisene. Jeg trenger loggene og vil eskalere problemet til en annen ingeniør. Jeg skal fortelle deg hva: Hvis du ser fragmentering og ikke defragmenterer, er det dumt og uansvarlig. Og uansett, hvordan klarte du å forvirre det edle navnet "Ignat" og kalle meg Ivan?
(K): – Så, det er nok! Jeg er ikke din bror, Ignat, eller din matchmaker for at du skal kalle meg ved navn, så vær så snill å adressere meg som Gn. Santino! Hvis du ikke finner dokumentet eller ikke kan takle en så enkel oppgave, kan du enten forlate selskapet eller spørre forfatteren, som ga oss dette dokumentet! Når det gjelder loggene, kan vi ikke overføre dem til deg uten spesiell godkjenning, siden vi jobber med hemmelige dokumenter. Din forargelse over min feil viser din uvitenhet og dine dårlige oppførsel. Jeg er veldig lei meg på din vegne. Og til slutt: hvis vi sier at vi "prøvde å defragmentere" og det er "umulig", så prøvde vi og det er umulig. Ignat, jeg ber deg, slutt å lide av tull og tull og gå i gang med arbeidet ditt - enten gi oss svaret, eller finn noen som vil gi oss det!
Etter dette ble applikasjonen overført til et høyere nivå, hvor den døde - klienten ga aldri logger, fullskala testing ga ingenting, og problemet kunne rett og slett ikke bekreftes.
Spørsmål: hva kunne ingeniøren gjøre for å unngå heten av lidenskaper og eskalering av konflikten?
(Prøv å svare på dette spørsmålet selv før du leser videre).
Lyrisk teknisk digresjon
For de som liker å løse gåter og svare på spørsmålet "hvem er morderen?": problemet viste seg å være mye mer alvorlig: ReFS-fragmentering påvirket ikke bare diskoperasjoner, men økte i noen tilfeller CPU- og RAM-forbruket med opptil ti ganger, og ikke bare for Veeam-klienter – alle ReFS-brukere kan lide.
Det tok Microsoft mer enn et år, med støtte fra mange leverandører, for å endelig rette opp denne feilen (som vi ser vår egen fordel for - mange kopier ble ødelagt på grunn av støtten fra denne giganten på alle nivåer).
Jeg, som svarer på spørsmålet "hva kunne ha blitt gjort?", Jeg vil stille et annet, evig spørsmål: "Hvem har skylden?"
Av faglig solidaritet vil jeg virkelig si: «Kunden har skylden» og begynne å skjerme ingeniøren. Som en leder som hele tiden evaluerer arbeidet til ingeniørene sine, ser jeg feilene som Ignat gjorde. Hvem har rett?
La oss ordne alt i rekkefølge
Denne saken er veldig tøff, det er flere spørsmål enn svar.
Formelt gjorde Ignat alt bra:
- fulgt en av Veeams kjerneverdier: Samtale fra hjertet;
- henvendte seg til klienten ved navn;
- avklarte situasjonen før de foreslo en løsning.
Kunne han ha unngått slike intense lidenskaper?
Kunne: legg merke til hvordan Mr. Santino kommuniserer (bare av deg og etternavn), avslå "grunnleggende spørsmål", vis interessen for problemet og lover å finne ut om denne oppførselen er normal.
Minimale skritt, uten den tekniske delen, og de ville allerede ha bidratt til å "slukke" situasjonen. Men selv om dette er savnet, vil det å "ikke gjøre det" også hjelpe litt.
Det høres åpenbart ut: ikke ta en skrivefeil personlig, ikke bli fornærmet av en sarkastisk klient (selv om alt sier om en oppblåst FER), ikke gjør samtalen personlig, ikke gi etter for provokasjoner... Det er så mange av dem, disse «nei», og alle viktige, og alt om kommunikasjon.
Hva med klienten? Er brevene skrevet i "high style", konstante referanser til dine bekjente helt på toppen, tilslørte fornærmelser og harme fra tilsynelatende respektløshet? Ja, vi kan lese det på den måten. På den annen side, er det så Mr. Er Santino faktisk feil på grunn av sinne?
Og likevel, hva kan gjøres på begge sider? Jeg ser det slik:
Fra ingeniørens side:
- vurdere graden av formalisme hos klienten;
- følge mindre "grunnleggende isolasjon";
- (nå blir det subjektivt) les brevene nøyere;
- svar på spørsmål i stedet for å unngå dem;
- og til slutt, ikke gi etter for provokasjoner og ikke bli personlig.
Til klienten:
- oppgi tydelig problemet i det første brevet, uten å skjule det i tekniske detaljer (dette følger ikke direkte av dialogen, men tro meg, detaljene var fantastiske);
- vær litt mer tolerant for spørsmål - ikke alle tenker på samme måte, og noen ganger må du spørre mye for å forstå selve essensen av problemet;
- kanskje begrense ønsket om å vise din betydning og bekjentskaper "på høyeste nivå";
- og, når det gjelder Ignat, unngå å bli for personlig.
Jeg gjentar - dette er bare min visjon, min vurdering, som på ingen måte utgjør anbefalinger eller veiledning om "hvordan leve og jobbe." Dette er en måte å se situasjonen på, og jeg vil være glad hvis du tilbyr din.
Jeg forsvarer ikke ingeniøren - han er sin egen onde Pinocchio. Jeg klandrer ikke klienten - han har rett til å kommunisere som han finner passende, selv om denne kommunikasjonen er mer skjult i den elegante blonden av en nesten raffinert høflig fornærmelse (et godt bilde av en moderne hidalgo som ikke handler med leiesoldater og krig, men i IT - selv om...) .
"Jeg fant en ljå på en stein" - slik kan jeg oppsummere denne korrespondansen, eller til og med si den med andre ord, sannheten som jeg oppriktig tror: "i enhver konflikt er det vanligvis to som har skylden."
Vi kan si med ordene til vår forretningscoach: "Vellykket kommunikasjon er hemmet av tidligere erfaringer, kommunikasjonsvaner og forskjellige bilder av verden." Du kan huske moralens gyldne regel: "Gjør mot andre mennesker som du vil at de skal gjøre mot deg."
Eller du kan ganske enkelt si: i enhver kommunikasjon er det alltid to personer involvert, og på den andre siden av håndsettet eller skjermen fra deg er en levende person som også er redd, glad, trist eller noe annet. Ja, det antas at følelser og Business er uforenlige, men hvor kan vi komme vekk fra følelser? De var, er og vil være, og selv om vi er teknisk støtte og løser veldig spesifikke problemer, er vårt hovedarbeid definert av det andre ordet: "støtte".
Støtte handler om mennesker.
***
Husk at jeg allerede har skrevet to ganger at to har skylden? Så, faktisk, dessuten, i denne spesielle situasjonen, har alle tre skylden. Hvorfor? Rett og slett fordi en ingeniør ikke er en ting i seg selv, men en del av teknisk støtte, og det er vår jobb og vårt ansvar å lære en ansatt å gå gjennom lignende situasjoner. Vi prøver å lære av våre feil og hjelpe våre ansatte å unngå dem.
Er det alltid mulig å unngå slike situasjoner? Ikke alltid. Uansett hvor god ingeniør den hypotetiske Ignat er, "på den andre siden" kan det være en person som vil gjøre alt for å eskalere situasjonen.
Men det fine med å jobbe hos Veeam Technical Support, en av verdiene vi er stolte av, er teamarbeid. Det er veldig viktig å huske: "Du er ikke alene," og vi gjør alt for å gjøre det slik.
Er det mulig å lære å leve og arbeide i slike situasjoner? Kan.
Vi vet hvordan, vi elsker, vi øver - dette er grunnen til at vi bygget vår interne opplæring og fortsetter å feilsøke og polere den. I løpet av de to og et halvt årene som har gått siden den beskrevne situasjonen har vi for alvor jobbet med treningsprogrammet vårt – og nå bruker vi caser aktivt, simulerer situasjoner, sparer penger og går hele tiden tilbake til feilene våre og analyserer forviklingene ved kommunikasjon. .
Vi tror at gutta våre nå drar mye mer forberedt ut i felten for enhver situasjon, og hvis det dukker opp noe de ikke er klare for, er vi i nærheten og klare til å hjelpe, for så å supplere kursene våre med nye eksempler.
Og det lønner seg. Her er for eksempel en anmeldelse fra en av våre kunder om arbeidet vårt:
«Vi har jobbet i IT-bransjen i mer enn 20 år, og vi er alle enige om at ingen leverandør tilbyr det nivået av teknisk støtte som Veeam tilbyr. Det er en glede å snakke med Veeams tekniske stab fordi de er kunnskapsrike og løser problemer raskt. Støtte bør aldri undervurderes. Det er et mål på et selskaps engasjement og suksess. Veeam er nummer 1 for støtte."
«Vi har vært i IT-bransjen i over 20 år, og vi sier at ingen andre leverandører tilbyr det nivået av teknisk støtte som Veeam gjør. Det er en glede å jobbe med Veeam-ingeniører, siden de kan sakene sine og kan løse problemer raskt. Teknisk støtte bør aldri undervurderes. Dette er et mål på hvor ansvarlig og vellykket en bedrift er. Veeam har den beste tekniske støtten."
***
Enhver kommunikasjon er et felt for eksperimenter og feil, enten vi ønsker det eller ikke. Og min mening er at det er greit å gjøre feil; dessuten vil min oppfordring være: gjør feil! Poenget er ikke om du snublet, men om du da lærte å plante foten godt.
Noen ganger er det vanskelig å fange deg selv og huske alle instruksjonene og oppskriftene som "guruer" for kommunikasjon med kunder eller erfarne kolleger sjenerøst deler. Noen ganger er det mye lettere å minne deg selv på: "Jeg snakker med en person."
***
Jeg later ikke til å ha overlegen kunnskap eller en spesiell kvalitetsstandard i å kommunisere med klienter. Listen over mine feil alene ville vært nok for en fullverdig lærebok.
Målet som jeg satte meg: å vise hvordan det kan være i Teknisk støtte og å starte en diskusjon om hva som kan anses som akseptabelt i slike tilfeller og hva som ikke er det.
Hva tror du?
Kilde: www.habr.com