Come trattare con un collega che mi ha incolpato per il bug che è stata colpa sua

Alcune persone hanno la tendenza a dare la colpa ad altri in modo aggressivo per distogliere l'attenzione da se stessi. Dato che anche lei è relativamente nuovo, deve essere stato molto conveniente per lui fare quello che ha fatto.

Ecco il mio consiglio. Scrivi una mail, descrivi qual è stato il problema, come hai raggiunto la causa alla radice, qual è stata l'eventuale soluzione e come può essere evitata in futuro. Includete tutti gli interessati in questa mail.

Alla fine di questa mail, scrivete qualcosa su queste righe,

XYZ,

Potete aggiungere questi passaggi nella documentazione appropriata o nel documento Standard-Operating-Procedure per questo pezzo di codice?

In questo modo non gli state “puntando il dito” contro, ma state esplicitamente affermando che è il proprietario di questo pezzo di codice e quindi responsabile di esso. Chiamare fuori è importante perché non tutti (specialmente i dirigenti superiori) apriranno qualsiasi link del codice per vedere di chi era il commit.

Un po’ duro, ma se lo merita.

Ho costruito la mia carriera non giocando al gioco delle colpe, ma la verità è che gli esseri umani ascoltano la voce più forte. Tuttavia, se ti impegni a difenderti, ti farà scendere al suo livello e ti batterà con l'esperienza.

Se riesci a trovarne uno, hai bisogno di un campione. Idealmente, questo dovrebbe essere il tuo manager, ma a volte è un altro sviluppatore molto rispettato. Andranno alla battuta per farti mettere a tacere quello rumoroso. Tutto quello che dovete fare è avere una discussione privata con loro sui fatti (non sulla colpa) di ciò che avete fatto per risolvere il problema e su come vorrebbero che procedeste in modo che, la prossima volta che qualcosa non va con il servizio, il problema possa essere trovato e risolto più velocemente. Ciò può comportare la scrittura di una piccola utilità di test che testi il servizio direttamente (senza usare il codice degli altri sviluppatori), o qualche registrazione o qualcosa del genere, in modo che il problema “noi contro loro” possa essere determinato molto rapidamente. Se sanno chi è il vero colpevole, possono ripulire il tuo nome senza che tu entri in conflitto diretto con quello rumoroso.

Mi sono sempre fatto in quattro per evitare di mettere altri sviluppatori in difesa. Ho detto cose del tipo: “Ho problemi a duplicare il problema, puoi farmi sapere quali chiamate stai facendo al servizio e cosa ricevi in cambio, così posso testare il servizio correttamente”? Se lo sviluppatore si preoccupa di darvi le tracce di registro delle chiamate e delle risposte effettive, chiedete cosa si aspettava di ricevere in cambio. Tuttavia, la maggior parte delle volte, lo sviluppatore vi mostrerà solo il loro codice. In questo caso, a volte è possibile individuare il problema. Anche se lo fai, non chiamarli. Devono trovare il problema da soli. Fate loro passare il codice attraverso un debugger e chiedete loro, in modo innocente, cosa contiene una certa variabile in una certa linea di codice. Potrei continuare, ma l'idea è chiara.

È una tradizione molto bella nel settore IT (e in alcuni altri, come l'aviazione) che quando qualcuno trova un problema, tutti lavorano insieme per trovare una soluzione, e idealmente per trovare la causa alla radice in modo che i processi possano essere migliorati, ma nessuno si prende la colpa personalmente o subisce sanzioni per aver commesso l'errore. Il risultato è che le persone sono aperte e oneste sui loro errori, piuttosto che cercare di coprirli, il che va a vantaggio di tutti.

Sembra che ci siano persone nel vostro negozio che non hanno comprato in questa cultura, e questo è qualcosa che richiede attenzione da parte del management.

Credo che dovreste parlare con il vostro manager su come vengono gestiti i problemi, in particolare le questioni prioritarie che hanno un impatto sull'esperienza dell'utente.

In questo caso avete 2 sistemi che comunicano tra loro e improvvisamente la comunicazione smette di funzionare. Quando la comunicazione non riesce, è importante che entrambe le parti guardino entrambi i sistemi. Ognuno mette l'accento sul vostro servizio, portandoli a non indagare sulle cose dal loro punto di vista. La più grande perdita di tempo nella risoluzione di un problema è cercare di scoprire cosa c'è di sbagliato in una parte di esso ** che in realtà funziona come dovrebbe**.

Queste sono, tuttavia, esperienze di apprendimento. Scommetto che ora sapete perfettamente come risolvere i problemi. Provate a impostare un piano di risoluzione dei problemi sulla base della vostra esperienza, e fate uno dei primi passi per essere sicuri che sia effettivamente il vostro servizio che sta fallendo (“Il servizio funziona se viene chiamato da un'altra pagina?”, “Il servizio sta fallendo parzialmente o completamente?”). Tu sei IL ragazzo del servizio web, puoi avere un po’ di fiducia nel tuo lavoro.

Cerca di lasciar perdere il fatto che in realtà è stato il suo codice a fallire. Cercare di farglielo notare è un po’ meschino. Non avrebbe dovuto concentrarsi tanto su di te fin dall'inizio. Consideratelo come un problema generale all'interno dell'azienda con la risoluzione di un problema e gestitelo come tale con il vostro manager. Non sai nemmeno se era effettivamente il suo codice, avrebbe anche potuto copiarlo da un'altra sezione scritta da un collega.

Penso che il suggerimento di parlare con il suo manager sia un buon suggerimento. Il vostro manager deve sapere che siete stati accusati ingiustamente.

Ma oltre a questo, siete messi alla prova. Il tuo istinto iniziale è giusto; devi rispondere, o le cose peggioreranno. Gli manderei un'e-mail direttamente e gli farei sapere che il problema era nel suo codice, e che per questa volta non l'hai detto a nessuno se non al tuo manager, a cui hai dovuto dirlo per proteggerti. E infine gli facevo sapere che se lo fa di nuovo, lo renderà pubblico.

Sono un po’ in ritardo con la domanda, ma oltre al consiglio molto valido della risposta di Edgar, c'è una seconda parte.

Se inviate una comunicazione che avete trovato il problema e annotate dove è stato risolto, allora gli altri sviluppatori probabilmente sapranno dove si trova il problema (questo è un bene), ma il management probabilmente no.

Fare così significa che avete fatto un favore a questo tizio - vi ha chiamato pubblicamente, avete trovato il problema, l'avete risolto e non l'avete fatto cadere con il management. Costruire un rapporto di fiducia come questo con i vostri colleghi vi garantirà un buon rapporto di fiducia a lungo termine.

Lieve nota a margine - questo ovviamente dipende leggermente dalla natura del difetto che trovate nel loro lavoro. Se quello che trovate è talmente sbagliato da indicare un'incompetenza da parte loro, potreste volerla tranquillamente aumentare al vostro manager - loro vorranno saperlo e anche voi state costruendo un rapporto di fiducia con loro.

Vi suggerisco di dormirci sopra prima di rispondere agli aspetti personali della situazione. Se avete risolto il problema e avete rimesso in moto le cose, allora siete ancora “l'uomo”. Dopo aver riposato un po’ sarà più facile essere gentili.

Mentre la questione principale era già stata affrontata a lungo in altre awswers - l'altro tizio che ti molestava - vorrei sottolineare un'altra prospettiva.

La correzione è stata fatta nel codice che l'altro tizio possedeva, ma il più delle volte il servizio avrebbe potuto evitare un problema più grande essendo più conservatore nel gestire le richieste dei clienti. Convalida gli input? Segnala eventuali errori di runtime? C'è un ambiente di test (questo vale anche per i consumatori)? A volte un problema nel servizio era solo in attesa di emergere, quindi direi che solo perché una correzione è stata fatta in un posto non significa che questa sia l'intera storia. Inoltre, per problemi come questo, non c'è solo il codice. C'è anche il processo.