Domanda

In un posto in cui lavoravo, la loro tipica risposta a qualsiasi problema era quella di incolpare l'hardware o gli utenti per non aver usato il sistema perfettamente. Avevo adottato la filosofia secondo cui è colpa mia fino a quando non posso dimostrare il contrario prima di quel lavoro (e finora, almeno 99 volte su 100 è corretto).

Uno degli ultimi " irrisolvibile " problemi quando ero c'era un'abbondanza di timeout del database. Dopo mesi di ricerche, avevo ancora solo teorie ma non ne ho potuto provare nessuna. Uno dei miei sviluppatori ha suggerito categoricamente di sostituire la rete (ogni router, switch, punto di accesso) ma non è riuscito a fornire alcuna prova che la causa fosse la rete; era, tuttavia, " ovviamente la causa " secondo il mio manager (nessuna esperienza di sviluppo / IT), quindi ha assunto il problema. Un avvertimento e plug Fog Creek: Non ha potuto spiegare il fatto che la segnalazione degli errori tramite FogBugz ha funzionato perfettamente e con lo stesso SQL Server del resto dei dati.

Un paio di mesi dopo, senza tempo scaduto, il mio manager si vantava di aver corretto i timeout (" Guarda, nessun timeout! "). Ho dovuto trattenermi dall'afferrare una roccia e dire & Quot; Guarda, niente tigri! & Quot; ma gli ho chiesto come sapeva che si sarebbero verificati a cui non ho avuto risposta. I timeout sono tornati (e in numero maggiore) un paio di mesi dopo.

Sono abbastanza contento di come ho gestito la situazione, ma sono curioso di sapere come la folla SO avrebbe risposto a lasciare che un superiore / collega implementasse una soluzione che sai (o sei molto sicuro) sia sbagliata e probabilmente sprecherà migliaia di dollari?

È stato utile?

Soluzione

Lasciali, ma allo stesso tempo continua a cercare la vera causa.

Un paio di migliaia di dollari sono soldi ben spesi se mi impedisce di andare contro quel tipo di pensiero (che è inutile).

Altri suggerimenti

Bene, se il problema riguarda i vertici aziendali, farei come hai fatto tu - presenta il tuo reclamo, quindi segui le istruzioni. Se si scopre che avevano ragione (succede di tanto in tanto) allora sembri un buon impiegato nonostante i tuoi dubbi. Se si scopre che avevi ragione, allora potrebbero essere più disposti ad ascoltarti dato che hai permesso loro il loro turno.

Questo è, ovviamente, ottimista.

Nel caso di un collega, portare il problema a un livello superiore e consultare i superiori per consigli su come affrontare l'argomento. Sii leale sia con la tua prospettiva che con quella del tuo collega, quindi segui i consigli che ti vengono dati.

A volte è meglio lasciare un manager. Se pensi alle sue pressioni e responsabilità doveva essere visto per fare qualcosa, piuttosto che & Quot; niente & Quot ;. Dopo abbastanza tempo & Quot; investigando & Quot; non si risolve in nulla con le parti esterne che devono interrompere i timeout.

Agendo crea un'opportunità per continuare la ricerca. Il trucco è trovare un modo per mettere le tue soluzioni nel suo contesto. Ecco qualcosa che possiamo fare ora, ed ecco cosa possiamo continuare a fare. Ad esempio, & Quot; Possiamo sostituire i dispositivi di rete come passaggio precauzionale, quindi esaminare i log di controllo della versione per escludere tale possibilità. & Quot;

Questo gli dà qualcosa di proattivo in modo che possa apparire produttivo nella sua catena mentre raggiunge la soluzione desiderata che alla fine avrà successo.

A lungo termine dovresti cercare di lavorare per qualcuno che si fida implicitamente delle tue decisioni tecniche, con cui puoi parlare candidamente e che ti aiuta a fargli navigare la politica in modo che entrambi sappiano cosa sta succedendo. Se il tuo manager non è quella persona, spostati.

È un grosso problema? Il tuo compito non è quello di risparmiare dollari della tua azienda oltre a quello che vorresti che la tua azienda rimanesse solvente in modo da essere pagato.

Se è solo un manager, prima o poi verrà eliminato, se l'intera cultura dell'azienda è così, forse sarebbe il momento di andare avanti.

Nel frattempo, vedi se riesci a vedere questo da il tuo prospettiva del gestore.

Considero l'intenzione del tuo manager di essere una buona cosa. Sono le persone che non vogliono disturbare che trovo più difficili. È solo meglio trovare un modo per usare quell'energia per essere utile.

Un problema comune per molte persone (a volte me stesso) è che si agitano quando cercano di diagnosticare un problema. Se stai indovinando selvaggiamente, quindi la particolarità con i computer moderni, hai solo la più sottile possibilità di avere ragione. Affrontare questo tipo di problema con quel tipo di atteggiamento, generalmente significa che non lo risolverai mai.

Il modo migliore per gestire debug complessi è dividere e conquistare. In questo caso, prima pensa a un test, poi lo implementano. Quel test ha funzionato come previsto? A seconda di dove ti trovi con i test, ti stai avvicinando o allontanando il problema. La chiave è che TUTTI i test devono comportare comportamenti concreti (oggettivi). Se i risultati sono ambigui, il test è inutile.

Se ti stai disconnettendo da una parte del sistema, ma qualche altra parte non lo è, allora hai una grande quantità di informazioni preziose (mostra anche che non è la rete). Qual è la differenza tra le parti? Inizia a scendere finché non arrivi da qualche parte ...

Tornando al tuo manager. Ogni volta che incontro quel tipo di problema di personalità, provo a reindirizzare l'energia in qualcosa di più utile. Il desiderio è lì, ha solo bisogno di aiuto per plasmarsi. Se riesci a convincere il tuo manager a verificare che i test siano concreti, se ne fanno abbastanza, produrranno abbastanza informazioni per indovinare correttamente il bug. Certo, un approccio più coerente potrebbe essere più veloce, ma perché rifiutare un po 'di assistenza gratuita. In genere ritengo che ci sia un ruolo utile per chiunque in qualsiasi progetto, si tratta di rendere possibile sfruttare i loro sforzi ....

Paul.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top