Nogle gange står en teknisk supportingeniør over for et vanskeligt valg: at anvende dialogmodellen "Vi er for en høj servicekultur!" eller "Tryk på knappen og du får resultatet"?
...Efter at have brækket vingen lavet af vat,
Lad os ligge i skyerne, som i krypter.
Vi digtere er sjældent helgener,
Vi digtere er ofte blinde.
(Oleg Ladyzhensky)
At arbejde i teknisk support betyder ikke kun sjove historier om selvspringende tid og GPS-enhjørninger, og ikke engang bare detektiv-puslespil i stil med Hercule Poirot.
Teknisk support er først og fremmest kommunikation, og kommunikation betyder mennesker, og blandt vores kunder er der meget forskellige karakterer:
- Tyskeren, der arbejder fra en cafe overfor sit kontor i Berlin, har ægte nordisk selvkontrol, ideel ro, et nøje kalibreret netværk, en omfattende serverflåde og den kognitive evne til at sætte op og vedligeholde alt dette hos A+. Forespørgsler fra ham forårsager normalt samme reaktion som den sidste dumpling på en tallerken i et stort firma, og lyset bliver slukket på det forkerte tidspunkt.
- En brite, der har skiftet to virksomheder i løbet af de sidste 5 år, men ikke hans stil med at arbejde med support. De løber enten væk fra hans sager som byllepesten, eller også tager de dem og forudser på forhånd al den "charme" ved at arbejde med denne person, fordi han uden varsel kan tage kontrol over en fjernsession (for at tjekke sin e-mail, nogle gange personlige), lægge pres på ingeniører og ledelse over de mindste bagateller og endelig lige så pludselig lukke ansøgninger med kommentaren "DUPLICATE".
- En indianer med et polysyllabisk og ikke-udtaleligt efternavn, som afkræfter alle myterne om indisk IT: høflig, rolig, kompetent, læser dokumentation, lytter til rådene fra en ingeniør og gør altid alt selv, ejer af en smart turban (ja, vi fandt det på Facebook) og perfekt Oxford-udtale.
Enhver ingeniør kan tænke på omkring fem sådanne "navne"-klienter, uden selv at tænke for meget over det. Vi skræmmer vores tilflyttere med nogle (“hvis du opfører dig dårligt i laboratoriet, kommer der en kvinde og!..”), med nogle praler vi (“og jeg har allerede 5 ansøgninger med N. lukket!”). Og oftest husker og forstår vi endda, at positive og negative eksempler blot er vores opfattelse, og det følger af kommunikation, vores med kunder og kunder hos os.
Og denne kommunikation kan være meget anderledes.
Vi skrev engang om , og nu vil jeg vise, hvordan det sker med et levende eksempel.
Her er et godt eksempel fra to år siden: klientens reaktion på de "traditionelle" trin i fejlfinding fra ingeniørens og ingeniørens side på klientens kommunikationsstil.
Sag om fragmentering
Så her er sagen: En meget erfaren og teknologikyndig kunde åbner en supportbillet og stiller et direkte spørgsmål, hvilket giver en masse detaljer til at beskrive situationen.
Jeg tog mig den frihed at forvandle korrespondancen til en dialog og bevare de stilistiske træk.
Klient (K): - God eftermiddag, sir. Mit navn er Marco Santino, vi brugte din bedste praksis og installerede den nyeste teknologi anbefalet af dig, men vi ser, at systemets ydeevne er ved at blive kritisk lav på grund af høj fragmentering. Fortæl mig venligst, er det normalt?
Ingeniør (jeg): - Hej, Marco! Mit navn er Ignat, og jeg vil hjælpe. Sker dette altid? Har du prøvet at defragmentere?
(K): - Kære Ignat! Ja, det dukker altid op. Vi forsøgte at defragmentere, men desværre tager det for meget tid, når systemet er fuldstændig inaktivt, og det er derfor ikke muligt.
(I): - Hør her, af en eller anden grund kan jeg ikke finde denne bedste praksis. Hvor fandt du ham? Og måske skulle vi alligevel lave noget defragmentering, hva?
(K): - Kære Ignat! Forstår vi, at du ikke tager vores problem seriøst og har svært ved at holde dig tilbage fra et direkte snarere end politisk korrekt svar, vil vi stadig forsøge at svare dig. Vi har ikke din erfaring (vi har kun været i IT siden 1960), og vi er dig meget taknemmelige for dit arbejde og indsats for at uddanne os. Bedste praksis blev delt med os af dine produktchefer under middagen i Barcelona, og jeg sendte dig et link til dem. Vi spørger dig direkte, Ivan: Er denne situation normal? Hvis du ikke er interesseret i at tale med os, så find en, der kan hjælpe os.
(I): - Marco, af en eller anden grund fandt jeg ikke disse bedste praksisser. Jeg har brug for logfilerne og vil eskalere problemet til en anden ingeniør. Jeg skal fortælle dig hvad: Hvis du ser fragmentering og ikke defragmenterer, er det dumt og uansvarligt. Og alligevel, hvordan lykkedes det dig at forveksle det ædle navn "Ignat" og kalde mig Ivan?
(K): - Så det er nok! Jeg er ikke din bror, Ignat, eller din matchmaker for at du skal kalde mig ved navn, så tiltal mig venligst som Gn. Santino! Hvis du ikke kan finde dokumentet eller ikke kan klare sådan en simpel opgave, så forlad enten virksomheden eller spørg dets forfatter, hvem gav os dette dokument! Hvad angår logfilerne, kan vi ikke overføre dem til dig uden særlig godkendelse, da vi arbejder med hemmelige dokumenter. Din forargelse over min fejl viser din uvidenhed og dine dårlige manerer. Jeg er meget ked af det på din vegne. Og til sidst: Hvis vi siger, at vi "prøvede at defragmentere", og det er "umuligt", så prøvede vi, og det er umuligt. Ignat, jeg beder dig, lad være med at lide af sludder og gå i gang med dit arbejde - enten giv os svaret, eller find en, der vil give os det!
Herefter blev applikationen overført til et højere niveau, hvor den døde - klienten leverede aldrig logs, fuldskala test gav ikke noget, og problemet kunne simpelthen ikke bekræftes.
Spørgsmål: hvad kunne ingeniøren gøre for at undgå hede lidenskaber og eskalering af konflikten?
(Prøv selv at besvare dette spørgsmål, før du læser videre).
Lyrisk teknisk digression
For dem, der kan lide at løse gåder og besvare spørgsmålet "hvem er morderen?": problemet viste sig at være meget mere alvorligt: ReFS-fragmentering påvirkede ikke kun diskoperationer, men i nogle tilfælde øgede CPU- og RAM-forbruget med op til ti gange, og ikke kun for Veeam-klienter – alle ReFS-brugere kan lide.
Det tog Microsoft mere end et år, med støtte fra mange leverandører, til endelig at rette denne fejl (hvilket vi ser vores egen fordel - mange kopier blev ødelagt på grund af støtten fra denne gigant på alle niveauer).
Jeg, som besvarer spørgsmålet "hvad kunne have været gjort?", vil jeg stille et andet, evigt spørgsmål: "Hvem har skylden?"
Af faglig solidaritet vil jeg virkelig sige: "Kunden har skylden," og begynde at skærme ingeniøren. Som leder, der konstant evaluerer sine ingeniørers arbejde, ser jeg de fejl, Ignat begik. Hvem har ret?
Lad os ordne det hele i rækkefølge
Denne sag er meget hård, der er flere spørgsmål end svar.
Formelt gjorde Ignat alt godt:
- fulgt en af Veeams kerneværdier: Samtale fra hjertet;
- henvendte sig til klienten ved navn;
- afklarede situationen, inden der blev foreslået en løsning.
Kunne han have undgået sådanne intense lidenskaber?
Kunne: læg mærke til, hvordan Hr. Santino kommunikerer (kun af dig og med efternavn), afviser "grundlæggende spørgsmål", viser sin interesse for problemet og lover at finde ud af, om denne adfærd er normal.
Minimale skridt, uden den tekniske del, og de ville allerede have hjulpet med at "slukke" situationen. Men selvom dette er savnet, ville blot "ikke at gøre det" også hjælpe lidt.
Det lyder indlysende: tag ikke en tastefejl personligt, bliv ikke stødt af en sarkastisk klient (selvom alt siger om en oppustet FER), gør ikke samtalen personlig, giv ikke efter for provokationer... Der er så mange af dem, disse "nej" og alle vigtige, og alle om kommunikation.
Hvad med klienten? Er brevene skrevet i "high style", konstante referencer til dine bekendte helt i top, tilslørede fornærmelser og harme fra tilsyneladende respektløshed? Ja, sådan kan vi læse det. På den anden side er det så hr. Er Santino faktisk forkert på grund af sin vrede?
Og alligevel, hvad kunne der gøres på begge sider? Jeg ser det sådan her:
Fra ingeniørens side:
- vurdere graden af formalisme hos klienten;
- følge mindre "grundlæggende isolation";
- (nu bliver det subjektivt) læs brevene mere omhyggeligt;
- besvare spørgsmål i stedet for at undgå dem;
- og endelig ikke bukke under for provokationer og ikke blive personlig.
Til klienten:
- angiv klart spørgsmålet i det første brev uden at skjule det i tekniske detaljer (dette følger ikke direkte af dialogen, men tro mig, detaljen var fantastisk);
- være lidt mere tolerant over for spørgsmål – ikke alle tænker på samme måde, og nogle gange skal man spørge meget for at forstå selve essensen af problemet;
- måske begrænse ønsket om at vise din betydning og bekendtskaber "på højeste niveau";
- og, hvad angår Ignat, undgå at blive for personlig.
Jeg gentager - dette er blot min vision, min vurdering, som på ingen måde udgør anbefalinger eller vejledning om "hvordan man bor og arbejder." Dette er en måde at se situationen på, og jeg vil blive glad, hvis du tilbyder din.
Jeg forsvarer ikke ingeniøren - han er sin egen onde Pinocchio. Jeg bebrejder ikke klienten - han har ret til at kommunikere, som han finder det passende, selvom denne kommunikation er mere skjult i den elegante knipling af en næsten raffineret høflig fornærmelse (et godt billede af en moderne hidalgo, der ikke handler med lejesoldater og krig, men i IT - skønt...) .
"Jeg fandt en le på en sten" - sådan kan jeg opsummere denne korrespondance, eller endda sige det med andre ord, hvis sandhed jeg oprigtigt tror på: "i enhver konflikt er to normalt skyldig."
Vi kan sige med vores forretningscoachs ord: "succesfuld kommunikation er hæmmet af tidligere erfaringer, kommunikationsvaner og forskellige billeder af verden." Du kan huske moralens gyldne regel: "Gør mod andre mennesker, som du vil have, at de skal gøre mod dig."
Eller du kan simpelthen sige: i enhver kommunikation er der altid to personer involveret, og på den anden side af håndsættet eller skærmen fra dig er en levende person, der også er bange, glad, trist eller noget andet. Ja, det menes, at følelser og Business er uforenelige, men hvor kan vi komme væk fra følelser? De var, er og vil være, og selvom vi er teknisk support og løser meget specifikke problemer, er vores hovedarbejde defineret af det andet ord: "support".
Support handler om mennesker.
***
Husk, jeg skrev allerede to gange, at to er skylden? Så faktisk er det desuden i denne særlige situation, at alle tre har skylden. Hvorfor? Simpelthen fordi en ingeniør ikke er en ting i sig selv, men en del af teknisk support, og det er vores opgave og vores ansvar at lære en medarbejder at gå igennem lignende situationer. Vi forsøger at lære af vores fejl og hjælper vores medarbejdere med at undgå dem.
Er det altid muligt at undgå sådanne situationer? Ikke altid. Uanset hvor god en ingeniør den hypotetiske Ignat er, kan der "på den anden side" være en person, der vil gøre alt for at eskalere situationen.
Men det smukke ved at arbejde hos Veeam Technical Support, en af de værdier, vi er stolte af, er teamwork. Det er meget vigtigt at huske: "Du er ikke alene," og vi gør alt for at gøre det.
Er det muligt at lære at leve og arbejde i sådanne situationer? Kan.
Vi ved, hvordan, vi elsker, vi øver os - det er derfor, vi har bygget vores interne træning og fortsætter med at fejlsøge og polere den. I de to et halvt år, der er gået siden den beskrevne situation, har vi for alvor arbejdet på vores træningsprogram – og nu bruger vi aktivt cases, simulerer situationer, sparer penge og vender hele tiden tilbage til vores fejl og analyserer kommunikationens forviklinger. .
Vi tror på, at vores fyre nu går meget mere forberedte i marken til enhver situation, og hvis der dukker noget op, som de ikke er klar til, er vi i nærheden og klar til at hjælpe, og så supplere vores kurser med nye eksempler.
Og det betaler sig. Her er for eksempel en anmeldelse fra en af vores kunder om vores arbejde:
"Vi har arbejdet i it-branchen i mere end 20 år, og vi er alle enige om, at ingen leverandør tilbyder det niveau af teknisk support, som Veeam tilbyder. Det er en fornøjelse at tale med Veeams tekniske personale, fordi de er vidende og løser problemer hurtigt. Support bør aldrig undervurderes. Det er et mål for en virksomheds engagement og succes. Veeam er #1 for support."
"Vi har været i IT-branchen i over 20 år, og vi siger, at ingen anden leverandør yder det niveau af teknisk support, som Veeam gør. Det er en fornøjelse at arbejde med Veeam-ingeniører, da de kan deres kram og kan løse problemer hurtigt. Teknisk support bør aldrig undervurderes. Dette er et mål for, hvor ansvarlig og succesfuld en virksomhed er. Veeam har den bedste tekniske support."
***
Enhver kommunikation er et felt for eksperimenter og fejltagelser, uanset om vi vil det eller ej. Og min mening er, at det er okay at begå fejl; desuden vil min opfordring være: lav fejl! Pointen er ikke, om du snublede, men om du så lærte at plante din fod fast.
Nogle gange er det svært at fange dig selv og huske alle de instruktioner og opskrifter, som "guruer" af kommunikation med kunder eller erfarne kolleger generøst deler. Det er meget nemmere nogle gange at minde dig selv om: "Jeg taler med en person."
***
Jeg foregiver ikke at have overlegen viden eller en særlig kvalitetsstandard i kommunikationen med kunder. Listen over mine fejl alene ville være nok til en fuldgyldig lærebog.
Målet, som jeg satte mig: at vise, hvordan det kan være i Teknisk Support og at starte en diskussion om, hvad der kan anses for acceptabelt i sådanne tilfælde, og hvad der ikke er.
Hvad synes du?
Kilde: www.habr.com