Come impedire a un dipendente di tenere in ostaggio l'azienda?

Cosa posso fare per risolvere questa situazione?

Niente, sei lì solo da pochi mesi, non è il tuo ruolo e non hai il potere di fare nulla se non lamentarti.

I tuoi superiori hanno molte risorse, ma non le usano da 7 anni, quindi a questo punto stai solo ripensando alle loro ragioni e analizzando un collega invece di concentrarti sulle tue responsabilità e sui tuoi compiti.

Assumete due o tre degli sviluppatori più intelligenti che potete trovare. Consegnate loro tutto il codice. Lasciate che verifichino di avere davvero tutto il codice, tutto ciò che serve per far funzionare il software. Fate in modo che imparino cosa fa il codice, lo documentino, lo rifattorizzino, fino a raggiungere il punto in cui possono risolvere i problemi più velocemente del signor A. Tutto questo ovviamente senza alcuna conoscenza di A.

A quel punto vi assicurate di spegnere completamente il signor A da qualsiasi risorsa aziendale, trasferite il lavoro ai vostri nuovi sviluppatori, e informate il signor A. A che il suo lavoro è terminato.

Penserei che con i metodi di sviluppo del signor A, la quantità di lavoro che il suo codice fa è in realtà molto meno di sette anni di sviluppo che normalmente produrrebbe, e che il codice è offuscato, ma in realtà non è difficile, il che rende il lavoro dei nuovi ragazzi molto più facile.

PS. A causa di alcuni commenti, voglio sottolineare ancora una volta questo aspetto: Il problema non sono solo i soldi, il problema è che il software è molto meno sviluppato di quanto potrebbe essere, perché A si concentra sul rendere difficile lo sviluppo, non sul migliorare il software.

Risposta breve: La vostra organizzazione è attualmente in grave pericolo di The Bus Factor .

Ecco perché non lasciate mai che una sola persona detenga tutte le conoscenze. È un rischio enorme. Cosa succederebbe se questa persona decidesse di mollare, o venisse letteralmente investita da un autobus? Se la situazione è come la descrivete voi, allora l'intera azienda non c'è più. Dovete segnalarlo ai vostri manager come un rischio organizzativo, non come un problema di risorse umane.

Iniziate a far passare altre persone attraverso il codice, con o senza il signor A. Preferibilmente senza, perché lo avete già identificato come il problema.

Ricordate, se il signor A non vuole aiutare a mitigare questo rischio per la vostra organizzazione, allora lui stesso è un pericolo per l'organizzazione e deve essere gestito. Toglietegli il suo potere, in modo che se davvero viene investito da un autobus che non tutti finiscono senza via d'uscita.

Le altre risposte sono piuttosto grandiose, ma c'è un'altra cosa che prenderei in considerazione:

Il mio consiglio personale sarebbe di considerare di iniziare a cercare altri posti di lavoro… se la direzione non ha intrapreso alcuna azione in 7 anni, non sono sicuro che questo sia un posto per il quale ti piacerebbe lavorare a lungo termine. Per me, questo è un segnale di avvertimento per altri tipi di problemi in azienda.

e ha ripetuto che prende decisioni sbagliate di proposito per mantenere il prodotto software instabile, difficile da mantenere e risolvere i problemi

Quindi perché il vostro team lascia che queste “decisioni sbagliate” superino la revisione del progetto o la revisione del codice? Se non avete un processo di revisione del codice o anche solo un processo di revisione del design, sostenetelo a lungo termine.

Ma fino ad allora, tutto quello che dovete sapere è nell'articolo del blog di Joel on Software: Getting Things Done When You’re Only a Grunt

E ha un richiamo specifico per trattare con i bozos: FILE BUGS. Per Spolsky:

Come un grugnito, il Suo obiettivo è la minimizzazione dei danni, ovvero il contenimento. A un certo punto, uno di questi geni passerà due settimane a scrivere un po’ di codice che è così incredibilmente cattivo che non potrà mai funzionare. Si è tentati di passare i quindici minuti necessari per riscrivere correttamente la cosa da zero. Resistete alla tentazione. Hai l'occasione perfetta per neutralizzare questo idiota per diversi mesi. Continuate a segnalare i bug contro il loro codice. Non avranno altra scelta se non quella di continuare a rallentare per mesi finché non si troveranno altri bug. Questi sono mesi in cui non possono fare alcun danno da nessun'altra parte.

Altrimenti, come nuovo assunto del team, il vostro obiettivo dovrebbe essere quello di sviluppare la vostra reputazione di eccellenza.

Solo per dirlo più chiaramente delle risposte attuali…

Il tuo problema :

nessuno sapeva come risolverlo.

La tua soluzione :

• Impara a risolverlo da solo.

Ecco, ora l'azienda non ha più bisogno dell'altro.

Affiggete questo sul muro: (Dovrete cambiare alcuni nomi e luoghi).

Alcuni anni fa ho passato una settimana a tenere un corso interno di progettazione di programmi presso un'azienda manifatturiera nel mid-west degli Stati Uniti. Il venerdì pomeriggio di venerdì era tutto finito. Il DP Manager, che aveva organizzato il corso e lo stava pagando con il suo budget, mi chiese di entrare nel suo ufficio. “Cosa ne pensi?” mi chiese. Mi chiese di raccontargli le mie impressioni sulla sua operazione e sul suo staff. “Abbastanza buone”, gli dissi. “Ci sono delle brave persone lì”. I corsi di progettazione del programma sono un lavoro duro; ero molto stanco e la consulenza per la valutazione del personale è a pagamento. Comunque, sapevo che voleva davvero dirmi le sue idee.

“Cosa ne pensi di Fred? Tutti noi pensiamo che Fred sia brillante”. “È molto intelligente”, ho detto. “Non è molto entusiasta dei metodi, ma sa molto sulla programmazione”. “Sì”, ha detto il direttore del DP. Si è girato sulla sua sedia per affrontare un enorme diagramma di flusso incollato al muro: circa cinque grandi fogli di carta per la stampa di linee, forse duecento simboli, centinaia di linee di collegamento. “Fred lo fece. È l'accumulo dello stipendio lordo per il nostro libro paga settimanale. Nessun altro, a parte Fred, lo capisce”. La sua voce si è abbassata a un riverente silenzio. “Fred mi dice che non è sicuro di capirlo lui stesso”

“Fantastico”, ho borbottato rispettosamente. Ho capito chiaramente il quadro. Fred nel ruolo di Frankenstein, Fred il geniale creatore dell'incontrollabile mostro diagramma di flusso. “Ma che dire di Jane?” Ho detto. “Pensavo che Jane fosse molto brava. Ha raccolto le idee di progettazione del programma molto velocemente”

“Sì”, ha detto il DP Manager. “Jane è venuta da noi con una grande reputazione. Pensavamo che sarebbe stata brillante come Fred. Ma non ha ancora dato prova di sé. Le abbiamo dato alcuni problemi che pensavamo sarebbero stati davvero difficili, ma quando ha finito si è scoperto che non erano affatto difficili. La maggior parte di essi si sono rivelati piuttosto semplici. Non ha ancora dato prova di sé — se capisci cosa intendo?”

“Ho visto cosa intendeva”.

• Estratto dal libro Requisiti e specifiche del software - Michel Jackson (Vale la pena di leggerlo).

La risposta è semplice: licenziatelo. Potresti dover pagare una somma di denaro non banale a breve termine per sistemare il casino che ha fatto, ma il signor A non è più intelligente di chiunque altro al mondo - qualcun altro sarà in grado di mantenere il software a breve termine e di migliorarlo a lungo termine.

C'è una prospettiva da considerare.

L'azienda ama così. Se non l'hanno fatto 7 anni è un tempo lungo per lasciarlo persistere.

Tendiamo a dimenticare, come sviluppatori, che non è nostro compito scrivere codice buono o intelligente. Il nostro lavoro è quello di far nascere un prodotto. Scrivere del buon codice rende solo migliore questo processo, ma è possibile un prodotto totalmente fantastico con un codice totalmente merdoso.

L'azienda ha sostenuto le sue decisioni, e lo ha persino riassunto. A loro “piace” lui e il suo modo di fare. Non è probabile che questo cambi, anche se in qualche modo siete riusciti a farlo licenziare. Quello che è probabile che succeda è che scelgano una nuova persona per essere “l'uomo” e il processo ricomincia da capo.

Non è compito tuo dirigere l'azienda. L'azienda ha fatto la sua scelta. Tu devi fare la tua. Imparare dal ragazzo (ha mantenuto lo stesso lavoro per 7 anni e deve fare qualcosa di giusto) o andare avanti.

Nel bene e nel male, né nulla né nessuno è insostituibile. (alcuni possono essere più di altri, ma comunque) Se la gente conosce la soluzione, può iniziare a invertirla.

Sono stato nei tuoi panni più di un paio di volte in passato. Nella situazione più simile alla vostra, “Mr. A” era sparito da tempo, tuttavia, avevo una soluzione monolitica che lavorava per il back end di un'azienda di cavi dove non avevo codice sorgente per le librerie sviluppate localmente, e per finire ero un novellino in quel settore.

ho praticamente attaccato con un approccio modulare, dando un'occhiata al codice esistente, il reverse engineering dove mancava e scrivendo moduli che sostituivano a turno con migliori funzionalità e velocizzare i compiti principali. Ho perfezionato ogni modulo prima di passare al successivo. In pochi mesi avevo ucciso la precedente applicazione.

Essere insostituibile è sopravvalutato.

Affrontare anche le cose ereditate non è un compito facile, forse il tuo collega lo fa per inerzia o perché non sa fare di meglio.

Dal punto di vista del business, ci sono fondamentalmente due soluzioni:

1. 1. Transizione incrementale, in altre parole, prendere un piccolo pezzo della funzionalità, reimplementarlo ad un alto standard, e metterlo in produzione, e continuare a fare questo pezzo per pezzo fino a quando il vecchio sistema può essere completamente dismesso.
2. 2. Costruire completamente un nuovo sistema, e poi passare ad esso, tutto in una volta o gradualmente, ad esempio iniziando nuovi clienti su di esso e spostando gradualmente i vecchi clienti su di esso. Il nuovo sistema non deve essere per forza così funzionale come quello vecchio inizialmente; il suo punto di forza può essere un prezzo più basso, un supporto più rapido, ecc.

I vantaggi dell'opzione 1 sono che non ha bisogno di un grande investimento iniziale, il nuovo codice viene testato sul campo gradualmente invece che tutto in una volta, e si cominciano a vedere i benefici in anticipo (perché l'azienda spende meno tempo e denaro per mantenere le parti del vecchio sistema che non sono più attive).

Tuttavia, gli svantaggi sono che la struttura del nuovo sistema può essere fortemente influenzata dalla struttura del vecchio sistema, e in alcuni casi è davvero difficile sostituire parti di un sistema molto disordinato. A volte è necessaria un po’ di creatività - se tutto il resto fallisce, il nuovo codice può simulare la pressione dei tasti e i clic sul vecchio sistema! Ma l'interfacciamento con il vecchio sistema può generare così tanto lavoro che è meglio andare con l'opzione 2.

In ogni caso, c'è è qualcosa che si può fare. La domanda è: quanto costerà e quanto risparmierà? Cercare di stimare che per ciascuna delle opzioni sopra citate aiuterà a determinare quale opzione scegliere (se esiste). Dipenderà dai requisiti funzionali, dalla struttura del sistema esistente e dalla disponibilità dell'azienda a spendere soldi/utilizzare il credito in anticipo per i risparmi futuri.

Come membro del team del software il vostro lavoro non è quello di gestire l'azienda e i suoi dipendenti.

Il vostro lavoro è scrivere un buon software. Quindi preoccupatevi del software e non delle persone.

Vedete i problemi del software e dalla vostra domanda sembra che abbiate qualche idea per risolvere i problemi. Porta queste idee al tuo manager e combatti per averle.

“Manger, questo software non è testato e la sua attuale implementazione non è verificabile. Suggerisco di lavorare sulla reimplementazione in un linguaggio che sia più testabile, usando modelli di progettazione che permettano di testare più facilmente”

Ora, è molto probabile che:

A. Questa è una grande impresa in cui l'azienda non è disposta a investire, perché non vede la necessità

B. Il signor A si opporrà a questa roba e sarà ascoltato perché è più anziano

Se questo accade allora avete cercato di fare bene il vostro lavoro e siete stati soffocati. È tempo di cercare un nuovo lavoro.

Se questo si rivela e ti ascoltano, ti sei iscritto a una tonnellata di lavoro.

Non si può dare per scontato che ci sia l'intenzione dietro la situazione.

Tenerlo lontano dai moderni framework di sviluppo software

Potrebbe essere più a suo agio con ciò che conosce meglio?

Ho lavorato in grandi aziende la cui pipeline era un patchwork di codice antico e nuovissimo e dove certi pezzi di codice “funzionavano appena” e non sono mai stati toccati. Soprattutto i programmatori che l'hanno scritto non c'erano più e nessuno ha capito veramente come funzionavano, così hanno aggiunto nuove funzioni per adattarsi alle mutate esigenze. La loro pipeline era sempre in funzione, quindi qualsiasi lancio importante poteva avere conseguenze disastrose (cioè un lavoro molto costoso e l'interruzione delle consegne), quindi si sono astenuti dal toccarla troppo.

È una cattiva abitudine e rende l'infrastruttura non ottimizzata, ma in realtà ha i suoi meriti.

Cosa si potrebbe fare, soprattutto se si deve lavorare su molto o su tutto il codice: Se non c'è una documentazione adeguata, proponete di crearne una (se sapete di essere qualificati e avete il tempo) o chiedete se dovrebbe essercene una per velocizzare il lavoro.

Dovreste (come già fate) parlare (come già fate) di adattare nuove tecnologie o miglioramenti con il vostro manager, ma aspettatevi che non ne venga fuori nulla, anche se lui è d'accordo con voi.

Le probabilità sono che nessuno più in alto vede il beneficio di spendere risorse per questo e il vostro tentativo potrebbe essere visto come ah, il sangue nuovo pensa che può cambiare il mondo e ci insegna l'errore dei nostri modi.

Purtroppo le strutture aziendali resistono ai cambiamenti improvvisi e le modernizzazioni sono una questione di logorare gradualmente la resistenza o di implementarla poco a poco a meno che non si possa dimostrare che i vostri “cambiamenti rivoluzionari porteranno ad un'età dell'oro del profitto finanziario senza rischi”.

Anche se lo sta facendo maliziosamente per mantenere il suo lavoro, non vedo la responsabilità di far saltare il coperchio, soprattutto se il suo diretto superiore ne è informato.

Cosa farebbe? Parlerebbe con il suo superiore o senza di lui con il suo superiore o con il collega in questione?

Visto che il vostro superiore ha deciso di non portare avanti la questione, probabilmente non vorrà parlare con i suoi superiori con o senza di voi, oppure l'ha già fatto e ha incontrato un blocco.

Se parlate con i suoi superiori senza di lui rischiate di alienarvelo.

Parlare con il collega sarà sicuramente un pessimo ambiente di lavoro in seguito e sicuramente negherà qualsiasi accusa.

L'unico modo per risolvere il problema è togliere il controllo Mr. A.

Prima ottenere l'approvazione della direzione.

Fare un git nuovo di zecca.

1. Importare un bene, concordato sul punto di partenza.

2. Importare un bene, concordato sul punto di partenza. 2. Partire da lì e portare avanti il codice.

3. 1. Non date al signor A accesso a tutti (non ditegli nemmeno che esiste)
4. 1. Lasciate che il signor A. faccia tutto quello che vuole al suo repo, perché non lo userete. 6. Effettuate modifiche al codice falso per farlo sembrare attivo, se necessario, per nascondergli il vostro nuovo repo.

5. Alla fine il codice diverrà abbastanza distante da diventare automaticamente obsoleto.

6. Dovete prendere una decisione critica per mantenere o abbandonare la strategia dei moduli. I moduli non sono necessariamente un male per loro, è necessario mantenerli sincronizzati e in ordine.

Questo sarà un sacco di lavoro in quanto si deve riscrivere molto codice esistente.

Un ulteriore vantaggio, è che il codice alla fine diverrà abbastanza lontano da non poter più rivendicare il suo codice. Gli sarà completamente estraneo.

Siate consapevoli che, in qualità di non manager, questo non DEVE essere il vostro problema da risolvere (a parte seguire le istruzioni per fare cose che sono state decise come parte di una soluzione).

Inoltre, mai interpretare ciecamente “Vogliamo che il problema XY sia risolto” in una dichiarazione “…a causa del problema XY”.

Inoltre, siate consapevoli che una volta che si guida qualsiasi iniziativa, anche con l'approvazione, per cambiare la situazione, si sta coinvolgendo nella politica aziendale. Nella politica aziendale, non esiste una cosa come “un innocente innovatore senza un'agenda personale, che non possiamo ritenere responsabile di conseguenze indesiderate”.

Se lo fate, fatelo con un'agenda personale, e possedete le conseguenze in entrambi i casi.

@MightyPizza - Stai sprecando il tuo tempo. Vai a lavorare per un'altra azienda che ha un futuro migliore e più luminoso. Dovreste spendere così tante energie per risolvere questo problema solo se questa azienda è la vostra ultima tappa.

Questa è la risposta migliore in assoluto che otterrete. Preparati per il salto.

“Voglio rendere il software moderno, manutenibile e stabile”.

Il modo migliore per farlo è il primo giorno, prima riga di codice, non con il mucchio di spazzatura calda di qualcun altro.

Il fatto che sia rimasto nella posizione per così tanto tempo dimostra che l'azienda sta applicando consapevolmente o inconsciamente Hanlon’s razor :

Mai attribuire alla malizia ciò che è adeguatamente spiegato dalla stupidità.

Sembra che sia molto difficile trovare casi reali di malizia, solo cose che non hanno funzionato così bene nel tempo. Infatti, sembra che il signor A abbia lasciato che le persone cercassero di cambiare le cose e poi le abbiano eroicamente sistemate quando sono andate male.

Si dovrebbe anche considerare che il signor A potrebbe soffrire dell'effetto Dunning-Kruger , in quanto non è in grado di vedere che quello che sta facendo è sbagliato.

Potrebbe essere che una volta era bravo, ma ha smesso di imparare e ha smesso di provare. Chi lo sa. Quello che si deve prendere come primo principio, è che non importa quanto sia esasperante, si deve trattare con lui come se non fosse un agente malvagio.

La sua domanda sembra prendere l'ipotesi che sia appena dopo la sicurezza del lavoro e si rifiuta di aggiornare le cose per incorporare questo. Forse hai ragione, ma non puoi trattare con lui su questa base.

Sono sicuro che alcune delle tue idee brillanti hanno la resistenza di “l'abbiamo provato una volta e non ha funzionato a causa di X”. Dal punto di vista del business questo ha senso, hanno rischiato che qualcosa non funzionasse, quindi perché dovrebbero riprovarci?

Lei afferma come obiettivo.

Voglio rendere il software moderno, manutenibile e stabile.

Ripartiamolo in base alle esigenze del business

1. Moderno

Non c'è un valore commerciale implicito nel moderno. È discutibile in ogni caso. Lei dice Java 8, altri direbbero che Rust o Golag sono moderni. Finché un sistema è supportato non c'è un grande valore nell'aggiornarlo.

2. Mantenibile

Anche questo potrebbe essere difficile da argomentare. Il signor A sosterrà che è manutenibile, in quanto lo mantiene. Dovrebbe sostenere che i costi di manutenzione scenderebbero drasticamente per giustificare un cambiamento radicale del quadro di riferimento.

3. Stabile

Lei dice che vuole rendere il sistema HA, ma dice anche che

il software monitora gli eventi, fa alcune elaborazioni su di essi e poi intraprende le azioni appropriate.

Che non sembra che abbia bisogno di HA.

** Allora cosa fare?

Il vostro sistema suona come una grande palla di fango definita da

Una grande palla di fango è una giungla di codici di spaghetti, strutturata in modo disordinato, tentacolare, sciatta, con un filo a nastro adesivo e un filo di gomma. Questi sistemi mostrano segni inequivocabili di crescita non regolamentata, e di riparazioni ripetute e convenienti.

Affrontare questa testa, con uno sviluppatore non collaborativo che gestisce tutto questo sarà molto frustrante, e probabilmente infruttuoso. Sembra che molti altri abbiano tentato e fallito.

Quello che si può fare è iniziare ad aggirarlo:

• Se non si può fare l'HA del sistema, allora usare un sistema di bus di messaggi o simili per catturare i messaggi in questo modo se il sistema va giù non si perdono i dati.
• Se non si possono scrivere test unitari, scrivere test di sistema. Questi non sono così ordinati, ma permetteranno di eseguire i test sul sistema
• La prossima volta che sarà necessaria qualche azione, iniziate a costruirla in un sottosistema indipendente che possa ascoltare il bus di messaggi ed eseguire la propria azione.
• Se si può iniziare ad influire su alcuni effetti a valle (per esempio incapsulare le azioni che vengono intraprese) allora inserirli in un sottosistema.

C'è qualche argomento a sostegno del majectic monolith su microservices , ma si presuppone che il monolite sia ben ingegnerizzato. Nel vostro caso, il sistema può andare bene come monolite ben ingegnerizzato, ma se non è ben ingegnerizzato bisogna dividere le cose. Questo sembra un buon articolo per iniziare:

Un approccio più comune è quello di iniziare con un monolite e gradualmente staccare i microservizi ai bordi. Un tale approccio può lasciare un monolite sostanziale al cuore dell'architettura dei microservizi, ma con la maggior parte dei nuovi sviluppi che si verificano nei microservizi mentre il monolite è relativamente quiescente.

Tuttavia è importante stare al gioco con il signor A, non dirgli che stai sostituendo il sistema, ma che stai “migliorando l'affidabilità” o aggiungendo ridondanza. Se attaccate quello che ha fatto lui, vi renderà più difficile raggiungere i vostri obiettivi.

Potreste avere l'impressione che state rendendo il sistema più complesso. È vero, ma è necessario se si vuole andare avanti a lungo termine.

Perché tutti vogliono licenziare Mr. A così tanto? Penso che non abbia fatto nulla di male qui. Lo sviluppo di software non riguarda la realizzazione di cose nuove utilizzando strumenti interessanti o un framework. Si tratta di creare una cosa stabile che “funziona”. La vostra azienda ama Mr. A ed è soddisfatta del suo lavoro.

Tenetelo lontano dai moderni framework di sviluppo software

Il vostro sistema è attuale in condizioni stabili, quindi perché il team ha bisogno di utilizzare framework di sviluppo software moderni come Scrum o agile?

Logica di core business scritta in linguaggi che non possono essere testati

C'è un requisito che la logica di core business deve essere testata automaticamente?

Componenti software ri-architettati in 30 moduli per aggiungere complessità e problemi di certificazione delle versioni

Quanto è costata alla vostra azienda questa implementazione?

Progettata in modo non scalabile, assicurando che non ci siano capacità HA (alta disponibilità)

Sempre la stessa domanda: quanto è costata alla vostra azienda questa implementazione?

Secondo me, tutto quello che scrivete qui è solo il vostro reclamo contro di lui. Se avesse fatto molte cose “terribili” il sistema stesso si sarebbe fuso nel primo anno, e non sarebbe potuto rimanere così a lungo nella vostra azienda.

Semplice, l'azienda deve offrirgli un generoso aumento per documentare lo stato attuale del software e tutte le conoscenze che non vengono documentate e poi lo licenziano. Oppure, in alternativa, assumono una società di consulenza tecnica per documentare tutto e lui vedrà la scritta sul muro e alla fine se ne andrà.