A volte, gli ingegneri del supporto tecnico si trovano di fronte a una scelta difficile: adottare il modello di dialogo "Siamo per un alto standard di servizio!" oppure "Clicca sul pulsante e otterrai il risultato"?
…Spezzando un'ala di cotone,
Ci sdraiamo tra le nuvole, come in una tomba.
Noi, poeti, siamo raramente santi,
Noi, poeti, siamo spesso ciechi.
(Oleg Ladyzhensky)
Lavorare nel Supporto Tecnico non riguarda solo le divertenti storie su tempo autoliberante e unicorni GPS, e nemmeno solo enigmi da detective nello stile di Hercule Poirot.
Il Supporto Tecnico è, prima di tutto, comunicazione, e la comunicazione implica persone, e tra i nostri clienti ci sono personaggi molto diversi:
- Un tedesco che lavora in un caffè di fronte al suo ufficio a Berlino, dotato di una pazienza veramente nordica, perfetto equilibrio, una rete attentamente calibrata, un vasto parco server e capacità cognitive per impostare e mantenere tutto questo al livello A+. Le richieste da parte sua spesso suscitano la stessa reazione dell'ultimo raviolo nel piatto in una grande compagnia e della luce spenta in ritardo.
- Un britannico che, negli ultimi 5 anni, ha cambiato due aziende, ma non il suo modo di lavorare con il supporto. I suoi casi fanno fuggire le persone come se fossero affette dalla peste bubbonica, oppure li assumono, prevedendo già tutta la "delizia" di lavorare con questa persona, poiché può, senza preavviso, prendere il controllo durante una sessione remota (per controllare la sua email, a volte personale), fare pressione sugli ingegneri e sulla gestione per le più piccole insignificanze e, infine, chiudere improvvisamente le richieste con il commento "DUPLICATO".
- Un indiano con un cognome complesso e impronunciabile che sfata tutti i miti sull'IT indiano: cortese, calmo, competente, che legge la documentazione, ascolta i consigli degli ingegneri e fa sempre tutto da solo, possessore di un magnifico turbante (sì, lo abbiamo trovato su Facebook) e di una pronuncia perfetta in stile Oxford.
Ogni ingegnere può ricordare circa cinque di questi clienti 'nominativi' senza pensarci troppo. Alcuni spaventano i nostri nuovi arrivati («se ti comporti male in laboratorio, arriverà il babà e!..»), altri li facciamo invidia («io ho già chiuso 5 ticket con N.!»). E spesso ci rendiamo conto che esempi positivi e negativi sono solo la nostra percezione, che deriva dalla comunicazione, quella tra noi e i clienti e quella dei clienti stessi.
E questa comunicazione può essere molto diversa.
Una volta abbiamo già scritto su , e ora voglio mostrare come avviene, con un esempio reale.
Ecco un buon esempio di due anni fa: la reazione di un cliente ai ‘classici’ passi di troubleshooting da parte dell’ingegnere e la risposta dell’ingegnere allo stile comunicativo del cliente.
Caso sulla frammentazione
Quindi, il caso: un cliente molto esperto e tecnicamente competente apre un ticket di supporto e pone una domanda diretta, fornendo molti dettagli per descrivere la situazione.
Ho avuto il coraggio di rielaborare la corrispondenza in un dialogo, mantenendo le peculiarità stilistiche.
Cliente (C): — Buongiorno, signore. Mi chiamo Marco Santino, abbiamo seguito le vostre best practices e installato la tecnologia più recente da voi raccomandata, ma notiamo che le prestazioni del sistema stanno diventando critiche a causa della forte frammentazione. Mi può dire, per favore, se è normale?
Ingegnere (I): — Ciao, Marco! Mi chiamo Ignat e ti aiuterò. Questo si manifesta sempre? Hai provato a deframmentare?
(C): — Gentile Ignat! Sì, si manifesta sempre. Abbiamo provato a deframmentare, ma, ahimè, richiede troppo tempo durante l'interruzione totale del sistema, quindi non è possibile.
(I): — Senti, ma non riesco a trovare queste best practices. Dove le hai trovate? E forse, sarebbe meglio fare la deframmentazione, eh?
(K): — Gentile Ignat! Comprendendo che non prendi sul serio il nostro problema e con grande difficoltà nel trattenere una risposta diretta, invece di una politicamente corretta, tenteremo comunque di risponderti. Non abbiamo la tua esperienza (siamo nel settore IT solo dal 1960) e ti siamo molto grati per il tuo impegno e gli sforzi per la nostra formazione. Le Best Practices ci sono state fornite dai tuoi Product Managers durante una cena a Barcellona, e ti ho inviato il link. Ti chiediamo direttamente, Ivan: questa situazione è normale? Se non sei interessato a parlare con noi, per favore trova qualcuno che possa aiutarci.
(I): — Marco, non riesco a trovare queste best practices. Ho bisogno dei log, e passerò il problema a un altro ingegnere. Ti dico una cosa: se vedi frammentazione e non la defragmente, è sciocco e irresponsabile. E comunque, come hai fatto a confondere il nobile nome “Ignat” e chiamarmi Ivan?
(K): — Basta! Io non sono tuo fratello, Ignat, né tuo parente, quindi ti prego di rivolgerti a me come Signor Santino! Se non riesci a trovare il documento e non riesci a gestire un compito così semplice, allora chiedi al suo autore, che ci ha fornito questo documento, oppure dimettiti dalla compagnia! Per quanto riguarda i log, non possiamo fornirveli senza un'approvazione specifica, poiché lavoriamo con documenti riservati. Il tuo sdegno riguardo al mio errore mostra la tua ignoranza e maleducazione. Mi dispiace molto per te. E infine: se diciamo che abbiamo “provato a deframmentare” e che è “impossibile”, significa che ci abbiamo provato e che è impossibile. Ignat, ti prego, smettila di dire sciocchezze e occupati del tuo lavoro — o dacci una risposta, o trova chi può darcela!
Dopo di ciò, la richiesta è stata inoltrata a un livello superiore, dove è semplicemente morta: il cliente non ha fornito i log, i test completi non hanno dato risultati e il problema non è stato in grado di essere confermato.
Domanda: cosa avrebbe potuto fare l'ingegnere per evitare l'escalation del conflitto?
(Prova a rispondere a questa domanda da solo prima di continuare).
Un distacco tecnico lirico
Per gli appassionati di enigmi e di risposte alla domanda 'chi è l'assassino?': il problema si è rivelato molto più serio: la frammentazione di ReFS non solo influenzava le operazioni su disco, ma in alcuni casi aumentava il consumo di CPU e RAM fino a dieci volte, non solo per i clienti Veeam – anche tutti gli utenti di ReFS potevano soffrirne.
A Microsoft è servuto oltre un anno, con il supporto di molti vendor, per finalmente correggere questo errore (in cui vediamo anche il nostro merito – sono state spezzate molte lance a favore del supporto di questo gigante a tutti i livelli).
Rispondendo alla domanda 'cosa si poteva fare?', voglio porre un'altra, eterna domanda: 'E chi è colpevole?'
Per solidarietà professionale, mi verrebbe voglia di dire: 'Colpevole è il cliente', e iniziare a difendere l'ingegnere. Come dirigente, che valuta continuamente il lavoro dei suoi ingegneri, vedo gli errori fatti da Ignat. Chi ha ragione?
Analizziamo tutto in ordine
Questo caso è molto difficile, ci sono più domande che risposte.
Formalmente, Ignat ha fatto tutto bene:
- seguiva uno dei valori fondamentali di Veeam: Conversazione dal cuore;
- si rivolgeva al cliente per nome;
- chiedeva chiarimenti prima di offrire una soluzione.
Poteva evitare una tale escalation?
Sì: notare come il signor Santino si rivolgeva (solo con 'Lei' e per cognome), evitare le 'domande di routine', mostrare interesse per il problema e promettere di scoprire se questo comportamento fosse normale.
Passi minimi, senza la parte tecnica — e avrebbero già aiutato a 'spegnere' la situazione. Ma anche se questo è stato trascurato — semplicemente 'non fare' avrebbe aiutato un po'.
Sembra ovvio: non prendere un errore come un attacco personale, non offendersi per un cliente sarcastico (anche se tutto indica un ego ipertrofico), non portare la conversazione su un piano personale, non farsi provare… Quante volte, queste 'non', tutte importanti, sono tutte riguardo alla comunicazione.
E il cliente? Le lettere sono scritte 'in uno stile elevato', con continue allusioni a conoscenze ai vertici, insulti velati e offese da un apparente disprezzo? Sì, possiamo leggerlo in questo modo. D'altra parte, ha davvero torto il signor Santino nel suo risentimento?
Eppure, cosa si sarebbe potuto fare da entrambe le parti? La vedo così:
Dal lato dell'ingegnere:
- valutare il grado di formalismo del cliente;
- seguire meno la “isolation di base”;
- (ora sarà soggettivo) leggere le email con maggiore attenzione;
- rispondere alle domande, senza evitarle;
- e, infine, non cadere in provocazioni e non entrare nel personale.
Il cliente dovrebbe:
- definire chiaramente la questione nella prima email, senza nasconderla nei dettagli tecnici (dal dialogo non si evince direttamente, ma credetemi, la dettagliata era straordinaria);
- essere un po' più tollerante nei confronti delle domande — non tutti ragionano allo stesso modo, e a volte è necessario chiedere molto per comprendere il nocciolo del problema;
- forse contenere il desiderio di mostrare la propria importanza e i legami “ai massimi livelli”;
- e, come per Ignat, evitare di entrare nel personale.
Ripeto — questa è solo la mia visione, la mia valutazione, che in nessun modo costituisce raccomandazioni o una guida su “come vivere e lavorare”. Questa è una delle prospettive da cui si può guardare alla situazione, e sarei felice se proponeste le vostre.
Non difendo l'ingegnere: è un Burattino malvagio di per sé. Non accuso il cliente: ha tutto il diritto di comunicare come ritiene opportuno, anche se tale comunicazione si nasconde dietro un delicato pizzo di quasi-complimenti velati (una buona immagine del moderno hidalgo, che non si dedica a mercenariato e guerra, ma a IT — anche se…).
«La scure ha trovato la pietra» — così posso riassumere questa corrispondenza, o per dirla in altri modi, in una verità nella quale credo sinceramente: «in ogni conflitto, di solito, sono colpevoli in due».
Si può dire con le parole del nostro coach aziendale: «la comunicazione efficace è ostacolata dalle esperienze passate, dalle abitudini di comunicazione e dalle diverse visioni del mondo». Possiamo ricordare la regola d'oro della moralità: «Tratta gli altri come vorresti essere trattato».
Si può dire semplicemente che in ogni comunicazione ci sono sempre due persone, e dall'altra parte della cornetta telefonica o dello schermo c'è un essere umano, che prova paura, gioia, tristezza o qualsiasi altra emozione. Sì, si pensa che emozioni e business siano incompatibili, ma come possiamo allontanarci dalle emozioni? Sono sempre state, ci sono e ci saranno, e anche se noi siamo il supporto tecnico e affrontiamo compiti specifici, il nostro lavoro è definito dalla parola 'supporto'.
Il supporto riguarda le persone.
***
Ricordate, ho scritto già due volte che ci sono sempre due colpevoli? In realtà, in questa situazione, sono colpevoli tutti e tre. Perché? Semplicemente perché un ingegnere non è un'entità a sé stante, ma parte del supporto tecnico, e questa è la nostra responsabilità: insegnare ai membri del team a superare situazioni simili. Cerchiamo di imparare dai nostri errori e di aiutare i nostri collaboratori a evitarli.
È sempre possibile evitare tali situazioni? Non sempre. Per quanto bravo possa essere l'ipotetico Ignat, dall'altra parte potrebbe esserci qualcuno che farà di tutto per intensificare la situazione.
Ma la bellezza di lavorare nel Supporto Tecnico di Veeam, uno dei valori di cui siamo orgogliosi, è il lavoro di squadra. È molto importante ricordare: "Non sei solo" — e facciamo tutto il possibile affinché sia così.
È possibile insegnare a vivere e lavorare in situazioni del genere? Certo.
Sappiamo, amiamo e pratichiamo — per questo motivo abbiamo strutturato la nostra formazione interna e continuiamo a migliorarla. Nei due anni e mezzo trascorsi da quella situazione, abbiamo lavorato seriamente sul nostro programma di formazione — e ora utilizziamo attivamente casi reali, modelliamo situazioni, accumuliamo e torniamo sempre sui nostri errori, analizzando le sottigliezze della comunicazione.
Crediamo che ora i nostri ragazzi siano molto più preparati ad affrontare qualsiasi situazione, e se dovesse sorgere qualcosa per cui non sono pronti — noi siamo qui e pronti ad aiutare, aggiungendo nuove situazioni ai nostri corsi.
E questo ripaga. Ecco, ad esempio, il feedback di uno dei nostri clienti sul nostro lavoro:
«Lavoriamo nel settore IT da oltre 20 anni e tutti noi concordiamo che nessun fornitore offre il livello di supporto tecnico che offre Veeam. È un piacere parlare con il personale tecnico di Veeam perché sono competenti e risolvono i problemi rapidamente. Il supporto non dovrebbe mai essere sottovalutato. È un indicatore dell'impegno e del successo di un'azienda. Veeam è il numero 1 per il supporto.»
“Мы работаем в ИТ-индустрии более 20 лет, и мы утверждаем, что ни один другой вендор не предоставляет такой уровень технической поддержки, как Veeam. Очень приятно работать с инженерами Veeam, так как они знают свое дело и могут решать проблемы быстро. Техническая поддержка никогда не должна быть недооценена. Это мерило того, насколько компания ответственна и успешна. У Veeam — лучшая техподдержка.”
***
Qualsiasi comunicazione è un campo di esperimenti e errori, che ci piace o meno. E la mia opinione è che sbagliare è normale, anzi, il mio invito è: sbagliate! Non si tratta di inciampare, ma di aver imparato a mettere il piede fermamente.
A volte è difficile ricordare tutte le istruzioni e i segreti che i "guru" della comunicazione con i clienti o i colleghi esperti condividono generosamente. È molto più semplice a volte ricordare a se stessi: "sto parlando con una Persona".
***
Non pretendo avere la massima conoscenza o uno standard particolare di qualità nella comunicazione con i clienti. Una lista dei miei errori sarebbe sufficiente per un intero manuale.
L'obiettivo che mi ero posto era mostrare come potrebbe essere il supporto tecnico e avviare una discussione su ciò che può essere considerato accettabile in tali casi e ciò che non lo è.
Cosa ne pensate?
Fonte: habr.com
