Domanda:
Avviso scritto dal datore di lavoro per aver seguito le istruzioni del manager per implementare la correzione dei bug direttamente in produzione
Nathan
2016-09-16 18:40:02 UTC
view on stackexchange narkive permalink

Mi chiedo se voi meravigliose persone qui presenti potreste offrirmi qualche consiglio su come gestire un avvertimento scritto che ho ricevuto oggi.

Background

Ho lavorato per una società di software negli ultimi 8 anni che si occupa di posta elettronica broadcast. I clienti utilizzano il nostro servizio per caricare i loro elenchi di clienti e inviare loro e-mail promozionali, tenere traccia delle risposte e-mail ecc. Alcune di queste e-mail possono essere inviate a centinaia di migliaia di persone contemporaneamente.

Si è verificato un problema con una delle applicazioni coinvolte nell'invio dell'email. Mi è stato assegnato il compito di esaminare il problema dal mio diretto superiore. Non avevo mai visto prima questa parte dell'applicazione, quindi il suo processo era completamente nuovo per me; Ho dovuto imparare mentre andavo.

Dopo alcune indagini ho trovato il problema e l'ho segnalato. Il mio manager mi ha quindi chiesto di apportare una modifica per correggere il bug. Tuttavia, mi è stato chiesto di apportare questa modifica nella versione live dell'applicazione, non nella versione di sviluppo. Per gli sviluppatori non software là fuori, questa non è una best practice ed è potenzialmente pericolosa .

Non ho fatto domande al mio manager perché pensavo (erroneamente) che se fosse disposto per permettermi di apportare una modifica come questa all'applicazione live, non potrebbe essere davvero così catastrofico se qualcosa fosse andato storto, quindi ho apportato la modifica. Ho chiesto come avremmo potuto testarlo e lui ha risposto:

"Il client X ha programmato che un'email venga inviata a 5k client in 10 minuti; sarà un buon test".

Poi è andato a pranzo, e così ho fatto io. Al ritorno, sono stato informato dal personale di supporto che il processo non era riuscito, il che significa che era stata inviata un'e-mail errata all'intero database anziché un sottoinsieme dei loro clienti.

Il fallout

Questa mattina, il nostro amministratore delegato è arrivato in ufficio ed era estremamente arrabbiato per quello che è successo. Ha portato me e il mio manager immediatamente a una riunione e ha chiesto cosa fosse successo. Il mio manager è rimasto per lo più in silenzio durante l'intera riunione, lasciandomi a parlare. A quel tempo, non volevo gettare il mio manager sotto l'autobus perché volevo permettergli di ammettere il suo errore nell'insegnarmi a svolgere il lavoro su un sistema live. Tuttavia, questa volta non è arrivata. L'amministratore delegato quindi mi ha interrotto di parlare e ha inviato a entrambi un avviso disciplinare scritto poiché esiste la possibilità di perdere questo cliente che vale circa £ 200.000 all'anno.

La mia domanda

Mi è stato concesso il diritto di presentare ricorso contro la notifica scritta, tuttavia devo farlo entro 7 giorni. Mi sento come se questa comunicazione scritta che mi è stata inviata sia ingiusta poiché agivo solo sotto istruzioni dirette del mio manager. Ne ho parlato con la mia collega oggi e lei mi ha detto di aver ascoltato l'intera conversazione tra me e il mio manager sui test sui dati in tempo reale e pensa che la mia notifica sia ingiusta.

Pensi che io abbia un punto per appellarsi a questa decisione? e se sì, come mi avvicinerei? Siamo una piccola azienda (10 dipendenti) e non voglio davvero rendere le cose imbarazzanti tra me e il mio manager in ufficio.

Sebbene mi renda conto che il senno di poi è 20/20 e quello che è stato fatto è fatto, mi aspetto che uno sviluppatore con 8 anni di esperienza sappia meglio che apportare modifiche a un ambiente di produzione, * specialmente * quando si tratta di un sistema CRM rivolto al pubblico e * * soprattutto ** in un'applicazione di trasmissione. Questo è il genere di cose che rovinano le carriere ...
"Il cliente X ha programmato una mail da inviare a 5k clienti in 10 minuti, sarà un buon test". Poi è andato a pranzo, e anche io. "Davvero? *Veramente*? Lavori nel software da 8 anni e questo non ha fatto scattare un campanello d'allarme? Faccio eco al sentimento che siete entrambi fortunati ad avere ancora un lavoro.
I commenti non sono per discussioni estese; questa conversazione è stata [spostata in chat] (http://chat.stackexchange.com/rooms/45530/discussion-on-question-by-nathan-written-warning-from-employer-for-following-man).
A posteriori, avresti dovuto chiedere al manager se era assolutamente sicuro che fosse una buona idea, assicurarti che fosse consapevole dei pericoli (o almeno sapere che potevano essercene alcuni) e gettarlo sotto l'autobus al seguito- incontro se continuava a insistere. Allo stato attuale, non credo che tu abbia altra scelta migliore che accettare l'avviso e continuare con l'azienda, oppure trovare un altro lavoro altrove. Buona fortuna con qualunque cosa tu decida; Temo che questa non sia una bella situazione.
"Ho pensato" Ora sai di non dare per scontato le cose quando la posta in gioco è così alta. "sarà un buon test" Ti sei chiesto cosa potrebbe accadere se il test fallisse? (cosa che a quanto pare ha fatto). Quindi sei partito per pranzo, lasciando un hotfix da testare in produzione da un ignaro cliente, su un prodotto di cui hai poca conoscenza? Non credo che tu abbia molti motivi per fare appello. L'unica luce di speranza che vedo è che apparentemente hai i diritti per distribuire il codice live in modo arbitrario, il che è un segno che la società ha forse una minima idea di ciò che avrebbe dovuto essere effettivamente fatto.
di quanti livelli di gestione hai bisogno in un'azienda di 10 persone?
Tutta questa cosa sembra un po 'folle. Come avresti potuto spiegare in buona fede cosa è successo al tuo datore di lavoro e in qualche modo lasciargli comunque l'impressione che non si trattasse di un ordine diretto del tuo supervisore? Detto questo, sono molto sorpreso della quantità di tempo e impegno che le persone stanno facendo prendendo per rimproverarti per aver apportato modifiche direttamente a un sistema di produzione. Certamente non best practice, no, ma dovrebbe essere sempre considerato uno strumento in qualsiasi ambiente con una buona comunicazione e forti processi aziendali. La mancanza di questi è il vero problema qui.
@njzk2 idealmente 9. La regola pratica è di avere "n-1" livelli di manager in una compagnia di "n" persone.
Non è * necessariamente * contrario alle best practice distribuire una correzione per la produzione live. L'ho fatto. Le chiavi sono: (1) è assolutamente necessario? Ho corretto un bug in produzione che impediva a uno studente di completare un test accademico richiesto. Non avrebbe voluto aspettare. (2) sei assolutamente supportato dalla direzione? nel mio caso era assolutamente chiaro che volevano che accadesse. (3) puoi esercitarti su un server di staging? (4) puoi registrare lo schermo? Documenta tutto.
Cerca un avvocato e spiega questa situazione. Dovrebbero essere in grado di dirti rapidamente qual è la tua migliore linea d'azione e il mal di testa associato alle azioni disponibili.
Le lezioni più grandi da imparare da tutto questo: copriti il ​​culo (CYA) e * non * fidarti mai che le persone "facciano la cosa giusta", specialmente una persona in una posizione elevata rispetto a te con la capacità di licenziarti. Se fossi stato in questa situazione, mi sarei rifiutato di spingere il codice a prodursi a meno che non fosse diretto da qualcuno molto più in alto, possibilmente con un titolo che inizia con V, P o C. si sono rifiutati di correggere il codice di produzione, perché anche se mi licenziano, nessun responsabile delle assunzioni ragionevole nei colloqui futuri si farà beffe della mia decisione.
Dodici risposte:
nvoigt
2016-09-16 18:51:23 UTC
view on stackexchange narkive permalink

Poiché non conosco la tua giurisdizione, questa è la mia opinione personale fortemente basata sulle influenze europee:

  • Hai fatto ciò che ti era stato ordinato di fare.
  • Tu sapevi che era potenzialmente pericoloso.
  • Sia tu che il tuo capo siete stati avvertiti per questo.

Quindi sì, hai agito su un ordine diretto. Tuttavia, il tuo dovere in quanto bravo dipendente è di avvertire il tuo supervisore se fa qualcosa di sbagliato. Quindi ai miei occhi, quello che devi dimostrare è che l'hai fatto. Che non solo ti sei affidato al tuo supervisore per avere ragione, ma hai presentato le tue conoscenze e il tuo supervisore ti ha annullato .

Quindi, se hai una mail in cui dici al tuo supervisore non vuoi farlo perché è pericoloso e una risposta del tuo supervisore in cui ti dice di continuare nonostante le tue obiezioni, poi tu ha sicuramente un caso in cui è solo colpa sua.

Se non hai niente di tutto questo, forse perché pensavi che il tuo capo avrebbe saputo quello che sai, allora immagino che tu entrambi meritano l'avvertimento. Il tuo supervisore per aver preso una decisione stupida e tu per non averlo chiamato in causa.

Anche se meriti l'avvertimento, sarà importante informare il senior management che stavi agendo su ordini diretti. Potrebbero ancora decidere che ti meriti parte della responsabilità, ma l'alta dirigenza merita di conoscere i fatti.
@DJClayworth La mia opinione è che lo sappiano già. Dopo tutto hanno dato al suo manager lo stesso avvertimento.
@DJClayworth Il senior management non sa che stavo ancora agendo su ordini diretti. Come ho detto, volevo dare al mio manager la possibilità di riconoscere direttamente che mi aveva ordinato di svolgere il lavoro su un sistema live.
@Nathan Probabilmente no. Il mio consiglio è di informare rapidamente, e intendo rapidamente, l'alta dirigenza che stavate agendo su ordini diretti e che entrambi avete capito che era potenzialmente pericoloso. Ma sembra che lo sappiano già, ma ti consigliamo di assicurarti che sia scritto con le risorse umane che stavi agendo su ordini diretti nonostante questa conoscenza.
Concordato! Una cosa che ho imparato molto tempo fa da una certificazione di qualità (acronim) è stata quella di ** produrre prove **. Inoltre mi chiedo perché ti è stato affidato il compito di cercare in un pezzo del sistema di cui non hai alcuna conoscenza, può farmi avere un brutto abbattimento sin dall'inizio.
Una cosa che dovresti stabilire è "cosa pensa che avrei dovuto fare l'azienda?". Avresti dovuto disobbedire al tuo manager e rifiutarti di fare il cambiamento? Avresti dovuto controllare con una direzione superiore? Hai il diritto di sapere qual è secondo loro l'azione corretta.
@Nathan Il tuo manager probabilmente non è molto tecnico e, in quanto tale, probabilmente non ha pensato ai potenziali effetti collaterali del portare modifiche non testate direttamente nella produzione. Il tuo lavoro è assicurarti che sia fatto bene. Avresti dovuto testarlo e poi distribuirlo se era buono, anche se il tuo manager ha detto "portalo in produzione il prima possibile" o simili.
Se stiamo parlando di una corretta pratica di sviluppo software, forse l'amministratore delegato dovrebbe emettere * se stesso * un avvertimento disciplinare scritto per presiedere un sistema in cui uno sviluppatore ha i diritti di accesso per cambiare il server live, nonostante il protocollo sia che un manager dovrebbe fallo ("È qualcosa che non faccio mai! Dove lavoro, se un bug è urgente, la direzione apporterà modifiche al sistema live"). Solo da quel punto di vista sono d'accordo che l'alta dirigenza dovrebbe ottenere i dettagli quando le cose vanno FUBAR.
@SteveJessop "allora forse l'amministratore delegato dovrebbe emettere un avvertimento disciplinare scritto" Come potrebbe funzionare?
@SteveJessop è un'azienda di 10 persone, ovviamente tutti gli sviluppatori hanno accesso. Altrimenti, dipenderai da un ragazzo per fare una distribuzione.
@ThatGuy: ma secondo l'interrogante questa è la prima volta in assoluto che ha effettuato una distribuzione senza test in questo modo, e lo ha fatto su istruzione diretta della persona che normalmente ce l'avrebbe fatta, ed è stato un disastro. Quindi non sembra esserci alcun vantaggio procedurale nel fatto che lo sviluppatore lo abbia fatto (potrebbe essercene uno per il manager che ha diffuso la colpa). In una compagnia di 10 persone potrebbe esserci una via di mezzo tra la dicotomia "tutti gli sviluppatori hanno accesso" e "solo una persona ha accesso". Ma non sappiamo quanti di questi 10 siano completamente estranei allo sviluppo. Potrebbe essere 2, potrebbe essere 8.
Comunque il punto è che * o * gli sviluppatori non dovrebbero avere accesso per farlo, * o * la gestione non dovrebbe essere gli unici a farlo. Dare poteri alle persone, ma nessuna opportunità di sperimentarli, porta esattamente a questo tipo di errore.
@SteveJessop il tuo ultimo punto è buono e lo ammetto.
@Steve Sta cercando di risolvere un problema sociale con mezzi tecnici. Anche se questo può funzionare - e in questo caso ovviamente potrebbe funzionare (è per questo che ci sono le autorizzazioni!) - È costoso da implementare e può essere facilmente aggirato (chi non ha sentito parlare di account / password condivisi in aziende più grandi con regole rigide?) . Insegnare alle persone i rischi e la procedura corretta d'altra parte è assolutamente la mossa giusta in ogni caso.
Anche se l'OP agiva sotto espliciti ordini del manager, non avrebbe dovuto farlo. Era chiaramente sconsiderato.
@ThatGuy non necessariamente un ragazzo, ma solo i ragazzi che di solito lavorano sul prodotto. E in questa domanda, dati i livelli di gerarchia e procedure, ci sono buone probabilità che l'azienda contenga più di 10 persone
@njzk2 "Siamo una piccola azienda (10 dipendenti)" ~ OP
(-1) Non credo che questa risposta affronti effettivamente la domanda. Capisco che la lunga introduzione alla domanda sia piena di retorica a discarico e che sia utile contrastarla e spiegare perché l'avvertimento potrebbe essere considerato meritato e / o legalmente valido. Ma questo significa che un appello è inutile o controproducente? Qual è la migliore linea d'azione per evitare ulteriori conseguenze negative? Non sembri affrontarlo esplicitamente. Altre risposte sono molto migliori sotto questo aspetto.
@ThatGuy come potrei perdere quella parte!
Julia Hayward
2016-09-16 19:02:53 UTC
view on stackexchange narkive permalink

Se stavi seguendo le istruzioni esplicite di un superiore, allora hai ragione a fare appello. Tuttavia, a seconda del tuo stato e della tua esperienza ci sarebbe stata qualche aspettativa da parte tua di anticipare e avvisare il tuo capo delle sue istruzioni potenzialmente rischiose. Era ragionevole aspettarsi che tu conoscessi le probabili conseguenze di un errore? Se lo avessi avvertito e lui avesse insistito per procedere, potresti essere ragionevolmente considerato irreprensibile; questo non è il caso qui e dovresti essere preparato ad alcune delle colpe. Se c'è una lezione da trarre, è che dovresti sempre seguire il tuo istinto nel controllare cosa ti viene chiesto di fare se hai dei dubbi sinceri.

All'epoca, non l'ho fatto ' Non voglio gettare il mio manager sotto l'autobus perché volevo permettergli di ammettere il suo errore nell'insegnarmi a fare il lavoro su un sistema live. Tuttavia, questa volta non è arrivata.

Complimenti per aver conquistato un alto livello morale. Tuttavia, è chiaro che il tuo capo non è disposto a buttare te sotto l'autobus. E qui sta il valore maggiore di un appello: se l'alta dirigenza ha l'impressione che tu abbia avuto un ruolo di primo piano in questo, e accetti semplicemente l'avvertimento mentre fa appello con forza, è probabile che tu ne prenda tutto il peso. / p>

* è chiaro che il tuo capo non è al di sopra di gettarti sotto l'autobus. * - Non vedo dove l'hai preso. Il manager si rese conto che nulla di ciò che aveva detto avrebbe influenzato l'esito di quell'incontro. Ha fatto la cosa intelligente e non ha detto niente. In una riunione del genere la cosa intelligente da fare è ascoltare e fare volontariato solo il minimo assoluto. Il suo capo non voleva sentire cosa era successo, doveva fare la domanda, come sarebbe finita la riunione era predeterminato a meno che qualcuno non dicesse qualcosa per peggiorare le cose.
@Chad Nonsense. Il manager ha preso attivamente la decisione di intraprendere questa linea di azione ed è sua responsabilità assumersi la responsabilità di tale decisione. Questo è il lavoro di un manager. Se il nostro OP di sviluppo si prenderà la briga di prendere decisioni che non erano sue, allora 1) OP dovrebbe essere il manager e 2) OP dovrebbe prendere le decisioni. Tu prendi la decisione, prendi il caldo. È così che funziona. Uscire di nascosto è un comportamento terribile e non esiterei a rimuovere immediatamente un manager da una posizione di responsabilità per aver cercato di nascondere i propri errori in questo modo.
@J ... - Non è uscito di nascosto. Si è seduto lì e ha preso il rimprovero che meritava e ha accettato la punizione per quell'azione.
Ma non ha detto "Ho detto a Nathan di farlo", che sarebbe stata la linea di condotta onesta. Rimanendo in silenzio, spera che il senior tragga una conclusione diversa, che può essere solo meno favorevole all'OP.
@Chad Si è seduto lì e ha guardato il suo subordinato essere disciplinato per una decisione * che * ha preso senza alzarsi in piedi per assumersi completamente la responsabilità. È codardo, poco gentile e sconveniente per un manager - punto.
@JuliaHayward - Capisco che te lo aspetti. Ho il sospetto che il regista lo sapesse già prima di entrare. È sciocco andare a una riunione del genere senza conoscere i fatti in anticipo. Quello che avrebbe dovuto fare era contattare lo sviluppatore in anticipo e fargli sapere cosa probabilmente succederà. Entrambi hanno sbagliato, entrambi devono pagare il prezzo.
HopelessN00b
2016-09-17 01:07:51 UTC
view on stackexchange narkive permalink

Questo è ciò che viene spesso definito "mossa limitante la carriera" (o CLM). Indipendentemente da qualsiasi altra cosa, sei il ragazzo che quasi costava all'azienda un cliente di 200.000 sterline all'anno. (O il tizio che effettivamente l'ha fatto, se il cliente dovesse portare i suoi affari altrove).

Hai fatto due errori che posso vedere.

Il primo è stato implementazione in produzione senza una direttiva scritta del tuo capo: avresti dovuto inviare un'e-mail che delinea i rischi, sconsigliarlo e richiedere la conferma scritta della sua decisione di farlo comunque. Questo è il modo in cui ti proteggi quando una decisione come questa si ritorce contro.

L'altro errore è stato quello di aspettarti che il tuo capo si limitasse a dichiarare volontariamente che era una sua decisione quando hai incontrato l'alta dirigenza. Si spera che poco altro debba essere detto su questa nota. Aspettarsi che le persone si prendano volontariamente la colpa per te è ... poco saggio, per non dire altro.

Puoi appellarti alla decisione, ma entrambi questi errori renderanno una decisione favorevole molto più difficile ora. E anche se ne prendi uno, e allora? L'alta dirigenza sa / crede che tu sia una delle due persone responsabili di questo disastro, che tu abbia un rimprovero ufficiale o meno.

Entrambi questi errori sono esperienze di apprendimento per il tuo futuro, ma lo consiglierei a prescindere , hai limitato il tuo futuro in questa azienda. Possono decidere o meno di sbarazzarsi di te (e / o del tuo capo), ma anche se non lo fanno, le tue opportunità di avanzamento saranno molto limitate. Pertanto, nella tua posizione, ti consiglierei di provare a trovare un altro lavoro in un'altra azienda, dove non hai un segno nero contro di te.

Probabilmente ti sbagli sul primo punto. Il manager diretto ha diretto un test utilizzando 5K client live. Dato il lasso di tempo di 10 minuti, ciò preclude i test in preprod. Quindi il percorso CYA è a posto. Per quanto riguarda le "opportunità di avanzamento", beh, è ​​un'azienda di 10 persone.
@MSalters Advancement può essere qualcosa di più che salire di livello. Sollevamenti, progetti interessanti e altri vantaggi possono rientrare tutti in questo termine.
L'unico avvertimento minore è la cultura aziendale. Alcuni considerano gli errori come il costo della formazione.
@MSalters Il punto che stai sottolineando è la stessa logica difettosa che ha portato a questa situazione, una situazione in cui il risultato del pensare che potrebbe esserci un test "limitato" in produzione è stato smentito dato che c'era un bug che eludeva il previsto scopo del test. _Questo_ è il motivo per cui non testiamo in Produzione: _qualcosa_ può andare storto, incluso molto peggio (cioè legge di conseguenze non intenzionali) dato che questa sembra essere un'applicazione condivisa / SaaS in cui il codice è condiviso da tutti i clienti.
@srutzky: Non c'è bisogno che mi dica che è stata una cattiva idea. Il vero punto che stavo facendo è che c'è una traccia scritta, nonostante l'affermazione in questa risposta ("La prima era la distribuzione alla produzione senza una direttiva scritta").
@MSalters Ok, ma non è mai stato affermato che la "direttiva" per fare il test fosse scritta e parlata. E un lasso di tempo di 10 minuti _non_ preclude un corretto test non di produzione (a meno che non si tratti di una situazione di vita o di morte, cosa che non era); ciò che preclude è la capacità di inviare qualsiasi correzione alla produzione nel periodo di tempo ideale del cliente, nel qual caso è necessario dire al cliente di trattenere l'invio dell'e-mail fino a quando non sarà possibile eseguire il test appropriato.
Achilles
2016-09-17 13:17:21 UTC
view on stackexchange narkive permalink

Ci sono numerosi commenti e risposte che criticano le pratiche standard che non vengono seguite, ecc., Ma so per esperienza personale che tali incidenti non sono troppo rari nelle piccole aziende non tecnologiche. Di solito non c'è gestione del cambiamento, nessuna standardizzazione, ambienti di test / staging inadeguati, nessun controllo di versione ... e tutti (a volte anche i ragazzi non IT) hanno accesso amministrativo ai database / server di produzione. In tali aziende, la maggior parte delle modifiche abbastanza piccole va direttamente ai sistemi di produzione / live perché gli sviluppatori esistenti conoscono i sistemi alla perfezione (anche questi sistemi non sono troppo complessi). Ma quando qualcuno di nuovo si unisce, è molto probabile che commetta un tale errore inizialmente se non adeguatamente supervisionato.

Quello che è successo è chiaramente che il tuo manager si è preso la tua parola quando hai detto di averlo risolto, ma come si è scoperto, non l'hai riparato. Non è nemmeno colpa tua perché eri nuovo nel sistema e il tuo manager avrebbe dovuto saperlo meglio.

Detto questo, penso che questa potrebbe effettivamente essere una grande opportunità per te per essere promosso o ottenere sufficiente rispetto agli occhi del tuo amministratore delegato per la prossima valutazione. Di seguito è riportato cosa ti consiglierei di fare:

  1. Organizza un incontro con il tuo MD (e chiunque altro più in alto tranne il tuo diretto manager) e spiega loro cosa è successo. Non incolpare il tuo manager e non prenderti la colpa su te stesso, ma spiega i fatti del caso. Non dimenticare di mettere in chiaro che non era una tua idea pasticciare con il sistema di produzione e che stavi seguendo le istruzioni del tuo manager per tutto il tempo (ma ancora una volta senza incolparlo direttamente, una conversazione complicata). Se non puoi fare questa conversazione senza far sembrare che stai pugnalando alle spalle il tuo manager, non farlo.

  2. Quindi enfatizza il fatto che il vero problema qui è la mancanza di best practice del settore come la gestione del cambiamento, la gestione dei rilasci, il TDD, l'integrazione continua ecc. in azienda. Spiega come sono stati seguiti nelle tue organizzazioni precedenti e che tali problemi non esistevano. Digli con sicurezza che sei esperto in queste pratiche e, se gli piace, puoi implementarle anche qui. Questo passaggio sta per lanciare la tua carriera in questa azienda perché questo ti cambierà dal-nuovo-ragazzo-che-ha-incasinato-al-nuovo-ragazzo-che-farà-nostro -problemi-go-away. Assicurati di comprendere a fondo le migliori pratiche prima di questo incontro in modo da sapere di cosa stai parlando, le persone in posizioni di alto livello sono solitamente abbastanza intelligenti da vedere attraverso le bugie.

Ricorda che la chiave è usare tutto il tatto a tua disposizione per spostare l'attenzione da chi l'ha fatto a qual è il vero problema e come stai andando implementare le migliori pratiche del settore per eliminare tali problemi per sempre (e farlo dando l'impressione di essere completamente onesti e sinceri, credere in te stesso e nella tua capacità di farlo).

I passaggi precedenti elimineranno molto probabilmente la necessità di preoccuparsi dell'avvertimento scritto e del resto e ti saresti messo in una posizione molto favorevole con il tuo MD. Inoltre, avrai l'opportunità di implementare le migliori pratiche che non solo ti aiuteranno a rafforzare la tua posizione, ma anche a migliorare le cose nella tua azienda su tutta la linea. È un piccolo negozio da 10 persone, se sei bravo con il tuo MD, puoi restarci per sempre.

Buona fortuna.

Mi piace molto questa risposta. Proprio come disse John F. Kennedy: “I cinesi usano due pennellate per scrivere la parola 'crisi'. Una pennellata rappresenta il pericolo; l'altro per opportunità. ** In una crisi, sii consapevole del pericolo, ma riconosci l'opportunità **. "
Inoltre: "1. Se non puoi fare questa [conversazione privata con MD] senza far sembrare che stai pugnalando alle spalle il tuo manager, allora non farlo". Consiglio terribile. Deve farlo. Avrebbe dovuto farlo la prima volta. Al medico potrebbe non interessare ora, anche se la prima volta non gli è importato.
Personalmente, non ho idea se questa sia una buona idea o abbia qualche possibilità di successo ma +1 ma un altro suggerimento e per affrontare effettivamente la questione di come affrontare la situazione piuttosto che soffermarmi all'infinito sull'opportunità o meno di incolpare l'OP per le sue azioni.
@smci Sareste sorpresi di come funzionano le cose in così tante piccole aziende non tecnologiche. Il reparto IT è più un ripensamento per queste aziende perché è visto più come un costo che come il business effettivo. Conosco almeno 3 diverse aziende in cui i BA hanno accesso completo a prod db / webserver. L'azienda di OP chiaramente manca di alcune buone pratiche. Andare dal senior management e dire "Farò andare via tutti questi problemi, dammi solo una possibilità" o semplicemente offrirti di colmare le lacune mostrerà iniziativa e aiuterà a mitigare il problema. ** Ed è per questo che è un'opportunità ** imho.
@smci La ragione per cui sarebbe una cattiva idea è che il manager non sarebbe in giro per difendersi. Organizzare un incontro privato con l'MD e dare l'impressione che il programma sia pugnalare alle spalle il suo capo per salvare il suo lavoro distruggerà la credibilità di OP. Questo è il motivo per cui deve essere fatto con tatto o per niente.
OP non è certo un "nuovo ragazzo", dopo 8 anni di lavoro lì.
Nuovo per quel processo / applicazione ...
Kilisi
2016-09-16 19:39:55 UTC
view on stackexchange narkive permalink

Faccio appello e inizio tranquillamente a cercare un nuovo lavoro. In nessun modo vorrei un ammonimento scritto accettato sul mio record, non importa nient'altro. E in ogni caso può essere un preludio alla cessazione come capro espiatorio autoammesso.

La regola generale è di non ammettere nulla formalmente senza valutare molto attentamente le possibili ripercussioni. Non hai un'idea "reale" della loro agenda, ma puoi praticamente scommettere sul fatto che non ti è favorevole.

Certamente non vorrei continuare a lavorare per un manager che * apparentemente * mi ha buttato sotto l'autobus.
@Raystafarian se fossi un manager non vorrei certamente lavorare con un ingegnere che non segue le migliori pratiche e non può informarmi e avvisarmi al riguardo. Come datore di lavoro non vorrei pagare per un ragazzo di 8 anni di esperienza che segue ciecamente gli ordini senza pensare alle conseguenze
@Raystafarian Il manager non ha gettato il suo dipendente sotto l'autobus, il dipendente gli è saltato davanti lui stesso. Ammetto che non sia esattamente cavalleresco o nobile lasciare che il dipendente subisca il colpo ... ma nemmeno mettere il manager in una posizione in cui deve sacrificarsi per un dipendente.
Punto controverso ragazzi, il danno è già stato fatto, ora è il momento di mitigare il miglior vantaggio dell'OP, può puntare il dito tutto il giorno.
O più specificamente, l'autobus stava arrivando, il manager, che non stava prestando attenzione alla strada, ha detto al dipendente di attraversare la strada, il dipendente ha visto l'autobus ma non ha fatto domande e è stato colpito.
Vorrei appellarmi e il contenuto principale del mio appello sarebbe sulla falsariga di "Sono nuovo e non ci sono documenti per chi ha l'autorità di apportare modifiche alla produzione. Dovresti scrivere il regolamento in modo che non si ripresenti come questo."
Salvador Dali
2016-09-17 02:24:30 UTC
view on stackexchange narkive permalink

Come sviluppatore, credo che tu abbia gestito la situazione davvero male e ora stai cercando di trovare un supporto per cui non devi essere incolpato. Secondo me dovresti ammettere il tuo errore e cercare di migliorare la tua reputazione o cercare un altro lavoro.

Ecco le mie giustificazioni per questa convinzione:


Mi è stato chiesto di apportare questa modifica nella versione live dell'applicazione, non nella versione di sviluppo. Non ho fatto domande al mio manager perché pensavo che se fosse disposto a permettermi di apportare una modifica come questa all'applicazione live, non sarebbe potuto essere così catastrofico se qualcosa fosse andato storto, quindi ho apportato la modifica

Sei uno sviluppatore con 8 anni di esperienza e hai semplicemente pensato che fosse giusto fare cose su prod-service che possono potenzialmente influenzare un enorme numero di utenti. Se pensavi che fosse sbagliato, è tua responsabilità come professionista avvertire una persona che ti ha assegnato un compito e spiegarne tutte le conseguenze . Non sembra che tu l'abbia fatto, ma invece hai semplicemente assunto che tutti gli altri tranne te saranno responsabili e tutti gli altri sono d'accordo con questo.

Aggiungerei che questo

Non avevo mai visto prima questa parte dell'applicazione, quindi il suo processo era completamente nuovo per me, ho dovuto imparare man mano che procedevo.

non è una scusa valida, perché in ogni sistema ragionevolmente grande ci sono molte parti dell'applicazione che non si sono mai viste prima e anche ci sono alcune parti che nessuno nell'organizzazione ha mai visto prima.


Un'altra parte:

Ho chiesto come avremmo potuto testarlo e lui ha risposto: "Il cliente X ha programmato un'e-mail da inviare a 5k client in 10 minuti, sarà un buon test"

e ancora dopo 8 anni di esperienza accetti che testare applicazioni potenzialmente pericolose che hai ammesso di non aver mai visto prima dovrebbe essere fatto su persone reali. Veramente? Dov'è il tuo manager, che diavolo è questo? Non dovremmo mai farlo e questa è una delle cose peggiori che puoi suggerirmi. Ecco cosa penso che dovremmo fare: xxx . E poi se pensa davvero che questo è ciò che dovresti fare, lascia che lo dica in forma scritta.


ok, e infine

Poi è andato via per il suo pranzo, e anch'io. Al ritorno, sono stato informato dal personale di supporto che il processo era fallito

quindi hai fatto due errori molto pericolosi e invece di sederti ed essere pronto a sistemare tutto il secondo dopo il collasso, hai deciso di andartene (o ti aspettavi che tutto andasse liscio?)


Quindi in base a questo credo che la colpa sia ancora di più ecco che il tuo manager .

Alla fine immagina questa situazione: vieni con uno dei tuoi parenti (che è molto malato) in ospedale. Stai pagando il dottore, quindi sei una specie di capo. Il medico inizia a curare il tuo parente e tu inizi a dargli suggerimenti su cosa fare. Il dottore segue ciecamente tutto ciò che gli hai detto di fare ignorando il fatto che ha 8 anni di esperienza e ciò che suggerisci non ha senso e poi entrambi andate a mangiare felicemente.

È successo qualcosa di terribilmente brutto a un paziente e il dottore dice: "sai una cosa - ho seguito solo quello che mi ha detto il mio capo".

Questa è una situazione molto esagerata, ma il punto principale è: tu sei un professionista, dovresti conoscere i potenziali problemi con le cose pericolose che fai. È tua responsabilità spiegarli alla direzione. E fallo solo se hanno ascoltato le tue lamentele e ti hanno chiesto di fare altrimenti in forma scritta.

L'unico commento che posso fare per mitigare il comportamento dell'OP è che nel tipo di azienda che descrive, è molto probabile che il suo manager sia anche uno sviluppatore professionista che avrebbe dovuto conoscere i rischi di intraprendere questa azione esattamente come l'OP. Oltre a questo, +1.
(-1) Spiegazione: proprio come la risposta più votata (vedi anche il mio commento lì), questo suona più come un commento elaborato nella sezione "Background" che come una risposta reale alla domanda posta.
@Relaxed per niente. La sua domanda è: "Pensi che abbia ragione per fare appello a questa decisione?". La mia risposta è `no, non lo fai. Sei fortunato a non essere stato licenziato. Ammetti il ​​tuo errore e vai avanti ». Con le giustificazioni (basate sullo sfondo fornito) perché penso che non ci sia motivo di appellarsi alla decisione.
Dan
2016-09-16 20:43:03 UTC
view on stackexchange narkive permalink

Onestamente sono sorpreso che non siate stati licenziati entrambi per questo. Questa è una violazione piuttosto grave della fiducia dei clienti nell'azienda. Nel settore dello sviluppo del software, come sapete, giocare con i dati in tempo reale non è mai una buona idea, soprattutto se tale manipolazione interesserà un'ampia gamma di clienti. I clienti interessati possono arrabbiarsi e esprimere la loro rabbia nei confronti dell'azienda. Se i superiori vengono a sapere di questo, inseguiranno tutti i responsabili, indipendentemente da chi ha detto cosa. Pensa allo scandalo Wells Fargo in corso in questo momento. 5800 persone sono state licenziate. Quanti pensi che stessero semplicemente seguendo ciò che i loro superiori hanno detto loro?

Tuttavia, sono d'accordo sul fatto che sia molto difficile segnalare una tale violazione in corso quando non ci sono canali per farlo. Anche se lo segnali, è molto facile per il tuo manager ribaltarlo su di te.

Quindi sono d'accordo con te che questa è una cosa piuttosto difficile da bloccare. Per i casi futuri credo che tu possa deviare questo problema dicendo prima che pensi di aver identificato il problema, ma devi testarlo dopo aver impostato un ambiente di sviluppo. Assicurati di ricevere chiaramente ogni e-mail e assicurati che se ti viene chiesto di manipolare i dati in tempo reale, ripeti con una domanda: "Voglio un chiarimento che vuoi che modifichi i dati in tempo reale con qualcosa che non ho testato? "

Potrebbe non essere sufficiente per proteggere il tuo lavoro, ma sarebbe sufficiente se fossi stato licenziato per errore che potresti avere prove del contrario.

Un sacco di buoni consigli, ma non sono sicuro di capire come questo affronti la domanda in questione, ovvero come affrontare un possibile appello. Farlo o no? Immagino che tendi a non farlo (perché non essere licenziato è già un buon risultato) ma è questo che intendi?
Xavier J
2016-09-17 00:46:30 UTC
view on stackexchange narkive permalink

Pensi che abbia ragione di fare appello a questa decisione? e se sì, come mi avvicinerei? Siamo una piccola azienda (10 dipendenti) e non voglio davvero rendere le cose imbarazzanti tra me e il mio manager in ufficio.

Il tuo comportamento nel cercare di evitare sentimenti di disagio sta arrivando a un prezzo elevato. Sei stato chiamato sul tappeto e pensavi che il tuo manager sarebbe stato il virtuoso cavaliere in armatura scintillante e ti avrebbe salvato, ma non ha funzionato. Il tuo manager probabilmente sapeva meglio che modificare il codice di produzione, ma ha scelto una scorciatoia. Con ciò, c'era già una bandiera rossa per quanto riguarda l'integrità. Quindi forse ti aspettavi troppo durante la riunione.

Ora sei ancora preoccupato che ci sarà qualche disagio, anche se in realtà non hai fatto nulla di sbagliato, se dici la verità. Apparentemente il tuo manager ha una posizione migliore di te nell'affrontare le emozioni negative. Stai anteponendo i suoi sentimenti alla tua capacità di portare a casa uno stipendio . Per salvare la tua coda, dovrai diventare saggio, emotivamente.

Ecco dove può andare, se le cose si fanno male: nessun lavoro, avvisi in ritardo nella tua casella di posta e un frigorifero vuoto. Parla per te stesso.

Solo un promemoria per i nostri rispondenti e commentatori della nostra politica [Be Nice] (http://workplace.stackexchange.com/help/be-nice). Si prega di mantenere tutte le interazioni professionali ed educate.
@JaneS non è chiaro per me in che modo questo viola la politica di "be nice"? Per quanto ho capito essere gentile non significa confermare la convinzione di OP e spiegargli che ha ragione e che la colpa è di tutti gli altri.
@SalvadorDali è fantastico. Ti sei perso un commento off-color sulla mia risposta, che è stato cancellato. Grazie.
Questa versione è sia più efficace che più utile. Grazie.
"anche se in realtà non hai fatto nulla di sbagliato". Sì ha fatto. Ha inserito codice non testato in un ambiente di produzione. I professionisti dicono di no quando gli viene chiesto di fare qualcosa di non etico. E questo era un comportamento non etico.
"Non etico" - non proprio. Ci sono ambienti (sfortunatamente, ci lavoro adesso) in cui il management non ha capito i vantaggi di avere molta più disciplina su ciò che può essere fatto in un ambiente di produzione. Non ha mentito, imbrogliato, intrufolato, infranto la legge o rubato - QUELLI non sono etici. Ha seguito le istruzioni. Non è stato saggio? Diavolo sì! Vale la pena salire sopra la testa del suo capo? Dipende da chi è al di sopra del capo! Ma se non ci fossero tali conseguenze negative, questo non sarebbe nemmeno un problema.
Old_Lamplighter
2016-09-17 01:53:07 UTC
view on stackexchange narkive permalink

Fai ricorso. Potresti non vincere, ma almeno puoi tirare fuori la tua storia.

Fallo umilmente, spiega che ti è stato detto di fare quello che hai fatto e chiedi cosa avresti dovuto fare diversamente. Di 'loro che lo prendi molto sul serio e che vuoi assicurarti che non accada di nuovo, indipendentemente dal fatto che ci sia o meno un avviso nel tuo record.

Nel frattempo, e per sempre dopo questo punto, documenta tutto. Se un manager ti prende da parte e ti dice "fallo". La prima cosa che dovresti fare quando torni alla tua scrivania è scrivere un'e-mail che dice:

"Come da nostra conversazione di oggi, mi hai chiesto di fare l'ABC. Se qualcun altro viene informato prima di me iniziare a lavorare su questo e ci sono dubbi / dipendenze / autorizzazioni necessarie che dovrei ottenere prima di iniziare a lavorare?

Voglio solo assicurarmi che tutti siano sulla stessa pagina. Grazie in anticipo per i tuoi chiarimenti "

In questo modo puoi documentare anche le conversazioni secondarie e assicurarti che sia chiaro in anticipo che non sei una mina vagante.

Come dicevo ai miei rapporti "Qualunque cosa prima che accada qualcosa (scadenza, errore, eccetera) è esprimere una preoccupazione, qualsiasi cosa dopo è una scusa che nessuno ascolterà. Sii pieno di preoccupazioni e documentale.

user57597
2016-09-17 02:38:47 UTC
view on stackexchange narkive permalink

Non vuoi assumerti la colpa principale in modo retroattivo e altri ne hanno discusso. Tuttavia, devi essere consapevole che la maggior parte certamente è una cosa di cui tu e nessun altro dovete incolpare: avete installato una modifica importante su un sistema live che sta per fare una grande transazione e poi, come il responsabile dell'esecuzione tecnica, è andato a pranzo quando lo ha fatto il tuo manager e ha lasciato che la merda colpisse il ventilatore in tua assenza.

E quello dopo questo è stato chiamato "caso di prova" e quindi non c'era aspettativa di successo.

È come un maestro della demolizione che imposta il timer sugli esplosivi per un grattacielo e poi parte per il pranzo, aspettandosi che torni in un edificio raso al suolo.

Quella parte dell'incidente sta davvero completando l'inconsapevolezza dell'intero evento e appartiene giustamente al tuo record e non è qualcosa che puoi ragionevolmente aspettarti di essere chiarito. Quindi la domanda è quanto speri di migliorare la tua situazione correggendo altre cose.

Destra; questo è il vero problema proprio qui. Non riuscire a avvisare il manager in termini abbastanza forti che questa era una cattiva idea è un problema, ma * non essere in loco per il tempo programmato in anticipo per un evento in cui avresti dovuto sapere che c'era una non banale possibilità di fallimento * è, IMO, imperdonabile.
(-1) Spiegazione: proprio come la risposta più votata (vedi anche il mio commento lì), questo suona più come un commento elaborato nella sezione "Background" che come una risposta reale alla domanda posta.
Rob Moir
2016-09-19 13:29:41 UTC
view on stackexchange narkive permalink

Sono fermamente convinto che tu e il tuo capo meritate entrambi gli avvertimenti che avete ricevuto per aver implementato un hotfix in produzione e poi andate a pranzo .

Il fatto che ti sia stato ordinato di distribuire l'hotfix dal vivo è un errore del tuo capo (e forse tuo per non aver respinto con forza - ci sono volte in cui i miei capi potrebbero chiedermi di fare qualcosa che so essere pericoloso e Ci si aspetta che rifiuti e indichi perché in qualità di esperto in materia per quell'area). Ma va bene, lo daremo al tuo capo, è qui che si è guadagnato il suo avvertimento.

Il fatto che poi sei andato a pranzo quando sapevi che stava per svolgersi una corsa dal vivo con il cliente i dati sono assolutamente sbalorditivi. Mi dispiace, ma questo è il momento in cui il tuo ammonimento scritto è stato veramente guadagnato e non vedo quanto possa essere utile. Dovevi essere in giro per assumerti la responsabilità e la proprietà di eventuali problemi che si sono verificati con questa correzione e sei caduto su questo problema andando a pranzo nel momento sbagliato.

Mr Me
2016-09-19 17:44:58 UTC
view on stackexchange narkive permalink

Il compito del tuo manager è determinare cosa è necessario fare; stabilire le priorità, prendere decisioni difficili e simili.

Il tuo compito è sapere come fare ciò che deve essere fatto, tenere a mente le migliori pratiche, calcolare i compromessi ... e comunicarlo conoscenza alla tua direzione e aiutarli a prendere le decisioni giuste.

Non sei riuscito a riconoscere una situazione pericolosa.

Non l'hai comunicato a il tuo manager.

Hai detto che non sapevi molto di questa parte del sistema.

Tuttavia lavori da 8 anni in un'azienda di 10 persone .

Se fossi il tuo manager non mi aspetterei che NON sapessi cosa stai facendo.

  • Se non menzionassi il tuo manager la tua mancanza di conoscenza questa parte del tuo sistema,
  • e se non hai menzionato i potenziali rischi di apportare modifiche dal vivo e non in fase di sviluppo per testarle

Allora, sono scusa, è colpa tua.



Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 3.0 con cui è distribuito.
Loading...