Questo è un problema di gestione.

Prima che il codice critico sia distribuito, dovrebbe essere controllato nella sua versione, il codice dovrebbe essere controllato, il codice dovrebbe essere revisionato e almeno l'uso dovrebbe essere documentato. Se si tratta di sicurezza, scegliere i giusti revisori e proteggere il repo e i documenti. Non c'è ragione per cui questo non possa essere avviato immediatamente.

** C'è un problema più grande della sicurezza del lavoro**.

Ognuno di questi sviluppatori potrebbe inserire codice dannoso nell'azienda, per errore o per motivi propri. Nella peggiore delle ipotesi, potrebbe commettere attivamente atti nefasti utilizzando la propria situazione creatasi da sé (estorsione, sabotaggio, spionaggio industriale, ecc.) Nella migliore delle ipotesi, la loro opacità espone tutti a preoccupazioni di sicurezza e lascia sempre un punto interrogativo su eventuali controlli o responsabilità. Se qualcosa va storto, chi può dire che non siano stati in qualche modo coinvolti?

È necessario compilare un rapporto per il management.

Scrivere un breve documento che illustri esattamente il motivo per cui l'approccio attuale sta conducendo l'azienda su una strada pericolosa (essere colpiti da uno scenario di autobus, ad esempio). Illustrare i rischi per la sicurezza, magari citando anche racconti ammonitori del vostro settore, con riferimenti ad articoli, ecc.

Includere anche un elenco di modi in cui l'approccio di questo tipo sta compromettendo il vostro lavoro, così come il lavoro dei vostri collaboratori.

Infine, assicuratevi di elencare le raccomandazioni da implementare immediatamente, come l'aggiunta del codice al controllo di versione per tutti, e l'esecuzione del server su una VM a cui tutti hanno accesso. Illustrare come queste misure non dovrebbero in alcun modo influire sul lavoro di questa persona, e semplicemente aggiungere sicurezza e trasparenza all'intero processo - mettere in chiaro che non ci sono ragionevoli obiezioni a queste misure.**

Magari sedetevi con il vostro capo quando gli consegnate questo rapporto, e riferite verbalmente le esatte paure che avete scritto qui: che questo tizio si sta costruendo un impero nelle infrastrutture dell'azienda, e che, in definitiva, è potenzialmente pericoloso . Se i vostri capi ritengono che questa persona possa diventare irragionevole, allora potreste voler seguire i consigli di @BillLeeper e prendere il controllo della sua macchina in modo che non possa danneggiare la vostra organizzazione. Questo, naturalmente, spetterà a loro decidere.

Purtroppo, non ha detto se qualcuno ha parlato di queste preoccupazioni con il collega o con la direzione. È davvero maligno? O il suo collega è solo cieco? O forse la direzione è cieca?

Io stesso sono stato “quel” ragazzo.

Nel mio precedente lavoro a volte ho avuto vari compiti secondari per “fare questo piccolo strumento” o per fare qualcosa di semplice. A quanto pare, non ci sono mai risorse per il software interno… Di solito andava qualcosa del genere:

– Qualcuno può dare un'occhiata alle soluzioni che ho scelto per capire se è appropriato? – Dai, ci serve solo uno strumento semplice che faccia semplicemente questa semplice operazione, falla e andrà bene.

– Posso creare un server virtuale sul nostro server per questa cosa? – Amico, è solo per uso interno. Basta metterlo insieme ad altre cose su quella scatola fisica rotta. Oppure mettilo su quella scatola che fa - non sappiamo - quali funzioni. O metterlo sulla propria postazione di lavoro.

Naturalmente, non ci sono mai state risorse di tempo per scrivere documenti. A meno che non abbia scelto di farlo nel tempo libero. Naturalmente, tutto quello che potevo dire quando alcuni strumenti avevano problemi era “lavorarci su”.

E poi ho deciso di smettere. Quello è stato il primo momento in cui qualcuno intorno a me ha capito che i “piccoli strumenti interni” erano in realtà importanti e le cose “semplici” non sono così semplici. Ho passato un paio di weekend a scrivere documenti per fregare meno i miei colleghi. È passato quasi un anno e ricevo ancora diverse telefonate al mese su come fare qualcosa con i miei strumenti interni.

Modifica

Alcuni commenti mi hanno fatto notare che non dovrei aiutarli gratuitamente. Questo è generalmente corretto. Volevo chiarire che non sto dedicando ore del mio tempo a risolvere i loro problemi, sto solo dedicando un minuto per rispondere a una domanda. Tecnicamente è ancora vero che sto così abilitando e incoraggiando le pratiche esistenti Per il modo in cui l'azienda mi ha offerto una posizione part-time o a pagamento a ore per risolvere i problemi come ho fatto prima e l'ho rifiutato.

Il fatto è che non sono disposto a costringere i miei ex-colleghi a “ricercare meglio” invece di chiedermi semplicemente “Su quale macchina sta funzionando il Veeam?” se posso semplicemente dire il nome o l'indirizzo IP senza pensare o dire “Dovrebbe essere scritto in […]”. Oltre a 2 minuti di telefonata con l'ex-collega è di solito una distrazione positiva e rilassante come visitare lo stackexchange.

Modifica fine

Cosa posso suggerire? Il tuo collega sembra abbastanza capace, vero? Discutetene con la direzione. Non dite “sta diventando insostituibile”. Chiediglielo e basta - e se se se ne va? E se si ammala per un periodo di tempo prolungato? Convinceteli che il problema è reale. Dovrebbero discuterne loro stessi con quel tizio per trovare delle soluzioni. Forse gli mancano solo le risorse? Forse ha bisogno di un'altra persona nel team del “software interno” per rendere il tutto piacevole e carino?

La maggior parte di queste risposte sono WAY OVERBOARD su assumendo un intento maligno da parte dello sviluppatore in questione.

Prima di fare un'immagine surrettizia del server e poi di perquisire il tizio fuori dall'ufficio, perché non fare un bel respiro e cercare di capire cosa sta succedendo?

Potrebbe benissimo essere che la persona in questione sia sovraccaricata di lavoro, non abbia abbastanza risorse e sia più che disposta a condividere le conoscenze. O forse lo fa da molto tempo e non ha mai ricevuto un'indicazione che indichi che debba fare altrimenti. Come minimo, soprattutto se le sue cose funzionano, merita la possibilità di risolvere i problemi e di collaborare con i colleghi.

Non vedo alcuna prova che sia stato tentato di fare qualcosa di simile nella domanda dell'OP. Prima di considerare le opzioni draconiane, provate prima la comunicazione. Se la persona non aveva intenzione di fare del male, potete aspettarvi la sua collaborazione.

C'è qualcosa che non ho ancora visto nelle altre risposte:

Inizia casualmente a cercare un nuovo lavoro

Naturalmente, questo si basa sul presupposto che tu ne abbia già parlato con il tuo manager. Altre risposte hanno fornito le ragioni per cui questo non è un problema vostro ma del vostro manager e hanno anche dato indicazioni su come affrontare questa conversazione con il vostro manager.

Ora, sto guardando la situazione in cui avete parlato di questo con il vostro manager e poi, dopo un ragionevole lasso di tempo, non è successo niente di tutto questo. Avete la sensazione che il vostro manager non lo consideri un problema come sapete.

È qui che potreste voler iniziare a cercare un nuovo lavoro. Non importa che il vostro manager non lo consideri un problema o che semplicemente non lo capisca abbastanza bene da capire il problema, qui c'è qualcosa che non va. (E non sto parlando del codice “privato”, ma del problema del manager che non fa qualcosa a riguardo)

Un tale problema è qualcosa che non si può cambiare dalla posizione di sviluppatore. Tuttavia, ci sono altre aziende e non hanno gli stessi problemi, quindi potresti voler cercare un altro datore di lavoro.

Guardando la cosa dal lato positivo, però, non c'è troppa pressione su di te in questo momento. Avete un lavoro e non vi aspettate di perderlo. Non dovrete scendere a compromessi per poter continuare a pagare l'affitto, il mutuo e i costi della vita. Puoi iniziare a guardarti intorno con disinvoltura e non lasciare il tuo attuale lavoro fino a quando non trovi quel lavoro che ti piace davvero.

Sembra che ci siano alcuni buoni rimedi per evitare che ciò accada in futuro, ma non cosa fare adesso.

1. 1. Mettere in sicurezza il computer. O si fa controllare dal management e da un esperto IT quando è sbloccato e non sorvegliato, oppure si va a chiedere di sbloccare la macchina e di concederne l'accesso. Poi togliete questo mostro dalla rete. Fate un'immagine immediata dell'HD nel caso in cui abbia uno switch morto.
2. 1. Licenziare immediatamente questo individuo. 3. Accompagnatelo fuori dalla porta. Non preoccupatevi della causa, ci saranno un sacco di prove su quel suo computer. Se l'azienda è preoccupata, faccia fare la sua magia al suo avvocato, che è quello per cui viene pagato.

3. Licenziare immediatamente questo individuo. 3. Raduna la squadra. Spiegate cosa è successo. Questo individuo ha agito in modo sconsiderato e poco professionale. Ha messo a rischio la società ed è stato licenziato per questo. Ci vorranno tutte le risorse di cui disponiamo per risolvere questo casino.

4. Spiegare il motivo per cui è stato licenziato. 4. Utilizzare il team per ricostruire e ri-impiegare questo lavoro in modo adeguato su macchine sicure, ecc. Il team dovrà passare da un'applicazione all'altra e gestire la situazione. Non preoccupatevi subito di riscrivere, assicuratevi solo che non ci siano porte sul retro, ecc., e poi fate funzionare i servizi su hardware fresco e controllato.

5. Fate entrare un esperto di sicurezza. Questo tizio probabilmente non se ne andrà in silenzio e cercherà di ‘hackerare’ il sistema per sabotarlo o per ottenere l'accesso al suo sistema. Potrebbe anche avere password globali di sistemi con cui ha interagito o ha ottenuto password individuali nel corso del tempo. L'IT dovrebbe attivare un reset forzato della password su tutti gli utenti e bloccare qualsiasi accesso esterno per un certo tempo (come VPN).

Tutte le risposte attuali e la maggior parte dei commenti attuali si limitano ad indicare la situazione attuale o a fornire suggerimenti per compiere passi estremi.

Solo per riassumere: Ci sono due possibili situazioni: I colleghi lo fanno intenzionalmente, in questo caso sono malintenzionati in un modo o nell'altro, e quindi è necessaria un'estrema cautela. Oppure i colleghi non vedono i problemi e i pericoli potenziali e reali, che stanno causando, quindi sono “amichevoli”, ma dovrebbero essere educati a fare di meglio. Quindi, la seguente tabella di marcia cerca di fare due cose allo stesso tempo: 1) cercare di ridurre al minimo i danni potenziali, che i colleghi possono fare, se sono malintenzionati, e 2) cercare di tenerli in compagnia (in modo che in futuro possano diventare collaboratori cooperativi) se sono amichevoli:

(btw: Lo so, non sei tu il capo, ma con le informazioni che altri hanno fornito, immagino che avrai tutto in mano per convincere il tuo capo, per prendere questo filo molto seriamente, quindi questa tabella di marcia affronta quello che il tuo capo potrebbe fare, non quello che faresti tu. L'unica cosa che puoi fare è attirare l'attenzione sul tuo capo. btw2: Se il tuo capo ancora non ti ascolta, cerca un nuovo lavoro e licenziati non appena ne hai trovato uno nuovo. Perché quei colleghi sono delle bombe a orologeria, indipendentemente dal fatto che siano amichevoli o malvagi - non importa affatto).

1.) Fate in silenzio i backup di tutto ciò a cui potete accedere. Non spegnere i sistemi nel processo, spegnere i sistemi potrebbe potenzialmente innescare alcuni tipi di trappole esplosive.

2.) 3. Costruire un motivo per cui le stazioni di lavoro devono essere spente. Se avete bisogno di un'idea, contattatemi in privato.

3.) Estrarre i dischi rigidi, fare un'immagine completa, rimetterli dentro. Fatelo nel corso di un fine settimana circa

4.) Se i sistemi hanno roba di rilevamento delle intrusioni a livello di BIOS, e non si possono aggirare, costruite un'altra ragione per cui quei sistemi di rilevamento delle intrusioni hanno sparato.

Questi colleghi stanno creando strumenti per la roba interna, giusto? Quindi non hanno bisogno di accedere ai sistemi dei clienti e simili?

5.) Se hanno accesso ai sistemi, non hanno bisogno, cambiano le password, si assicurano che non ci sia una sorta di login a chiave pubblica, controllano le porte per i processi che permettono il login non standard. 6. Controllare cron/at jobs, controllare inetd, controllare tutto ciò che è in esecuzione al momento. Per ogni singolo pid, dovete essere in grado di rispondere, perché quel processo è in esecuzione.

6.) 7. Ottenere qualche nuovo dipendente (davvero nuovo, completamente sconosciuto. Deve essere davvero un buon esperto, perché deve essere in grado, se necessario, di prendere in mano il loro lavoro da solo per qualche mese. Non puoi prendere qualche studente laureato a caso (nemmeno uno con il massimo dei voti), hai bisogno di alcuni di quei ragazzi, che non hanno mai visitato un'università, ma che sanno ancora tutto) e inserirlo in quel team per sostenerli. Tanto più che stanno causando dei blocchi agli altri lavoratori, può essere facilmente giustificato. Il suo compito ufficiale è quello di sostenerli, il suo vero compito è quello di imparare come funzionano.

Step 6 è particolarmente importante, perché in questo modo si ha la possibilità di capire se quei colleghi sono malintenzionati.

Se il nuovo arrivato si integra bene nella squadra, allora si può supporre che sia amichevole, quel nuovo arrivato dovrebbe essere in grado di attuare i cambiamenti necessari senza bisogno di dire a quei ragazzi, che ci sono stati dei sospetti contro di loro.

Se il nuovo arrivato lo capisce, sono malintenzionati, ma lo integrano, allora il suo compito è quello di stare al gioco. Imparare tutto, trovare figo quello che fanno, e così via. Pagatelo il doppio dei soldi, perché deve lavorare due volte, perché una volta tornato a casa, deve scrivere tutto quello che ha imparato e inviarlo a una squadra appena formata che dovrebbe prendere in mano il lavoro non appena le conoscenze sono state trasferite.

Se i malintenzionati non lo integrano, allora la vostra unica possibilità è sperare, avete abbastanza dati di backup (solo per il caso) e licenziare quella squadra. Allora potreste aver bisogno di due o più esperti tra i super esperti di cui parlavo prima, per far entrare molto velocemente un nuovo team in quel codice.

Spero che questa tabella di marcia vi aiuti - almeno come fonte di ispirazione su come gestire la situazione. Forse, in tua compagnia, hai delle opzioni, che non posso considerare, forse, ci sono delle differenze culturali, quindi devi ancora pensarci su e magari aggiustare il piano.

Il programmatore in questione non deve ricevere alcun nuovo lavoro fino a quando la situazione non sarà risolta in un modo o nell'altro. Tutti i nuovi requisiti devono andare ad un altro sviluppatore/team che deve seguire le corrette procedure di controllo delle fonti e di revisione tra pari (nuove assunzioni se necessario). Il programmatore in questione può essere tenuto occupato a correggere i difetti o a “combattere gli incendi” della sua eredità esistente. Le risorse devono essere allocate per il reverse engineering dell'eredità esistente e la sua reimplementazione attraverso processi appropriati. Il costo di questa operazione deve essere giustificato dal rischio esistente - quanto costerà all'azienda se tutto ciò che questo programmatore ha fatto va improvvisamente perso? O peggio, quali dati proprietari (aziendali) sono vulnerabili alla perdita per la concorrenza?

Potrebbe valere la pena di chiedere a questo dipendente: “cosa ci succede se venite investiti da un autobus o decidete di fare una crociera di un mese intorno al mondo?” e valutare la risposta per decidere se rinuncerà volontariamente al suo codice. Se collabora, non c'è bisogno che la situazione diventi conflittuale; se non c'è alcun segno di preoccupazione per l'azienda da parte sua, il tempo di darsi da fare per mettere al sicuro tutto ciò che ha toccato.

Come affrontare il management di questo?

Diciamo che la migliore pratica è quella di non permetterlo, per molte ragioni.

I programmatori professionisti dovrebbero sapere che questo non è il modo di gestire un'azienda; e se i manager non sanno nient'altro dovrebbero almeno saperlo (i programmatori dovrebbero dirlo ai manager e/o i manager dovrebbero dirlo ai programmatori).

Le ragioni sono, si spera, così ben note che non ho bisogno di dirvele. Esse includono il “backup”, cioè sei nei guai se perdi il programmatore (o se viene riassegnato a qualcos'altro), o se il programmatore perde la sua macchina.

Almeno tu have “controllo di versione aziendale”, quindi non hai bisogno di combattere questa battaglia; fai solo in modo che sia un requisito di lavoro/processo che sia effettivamente usato.

Probabilmente non dovresti far girare il software di produzione sulla macchina dello sviluppatore. Un primo passo potrebbe essere quello di insistere sul fatto che:

• Gli utenti non fanno connessioni di rete alla macchina dello sviluppatore
• Il software gira su/da un server di produzione
• Il software girato sul server di produzione deve poter essere costruito da qualcun altro (o da una macchina di compilazione), dal controllo dei sorgenti

Implementazione che richiede il codice sorgente da controllare, le istruzioni di compilazione pubblicate. Vi suggerirei di farlo come semi-emergenza. Permettere allo sviluppatore di non accedere in scrittura al server di produzione o alla macchina di compilazione (per verificare che il codice di produzione sia compilabile dal controllo di versione).

Dopo averlo fatto (dopo aver saputo che il codice sorgente è nel controllo di versione e che le istruzioni di compilazione sono pubblicate), allora altri sviluppatori possono pensare di ispezionare il codice sorgente e di aiutare a mantenerlo.

Si noti che * Get Riding Of Indispensable Programmer As Quickly As Quickly As Possible ** è stato pubblicato da Gerald Weinberg nel 1971 (quindi, in realtà, tutti dovrebbero saperlo ormai). IIRC la citazione originale è,

“Se un programmatore è indispensabile, sbarazzatevi di lui il più rapidamente possibile”.

Questo non è un tuo problema, è la responsabilità e il ruolo dei manager, sei solo un collega e possibilmente non hai tutte le informazioni necessarie. Mi preoccuperei di più dei miei compiti piuttosto che volermi occupare dei miei colleghi. Non riesco a capire come qualcosa di positivo possa scatenare un polverone sul tuo collega.

Ti farai un nemico, ti farai vedere dal tuo manager per essere incompetente e darai l'impressione di avere così poco lavoro da avere il tempo di avviare indagini interne senza che ti venga chiesto o che tu abbia l'autorità per farlo.

La domanda è: quanto vuoi uscire da questo circolo vizioso? Perché non facciamo i furbi su questo, costerà allo studio.

1. 1. Lo studio dovrà spendere soldi per assumere qualcuno che scriva il codice che lo studio controlla. 2. Lo studio dovrà richiedere il codice al codificatore e, se necessario, sostenere tale richiesta con l'aiuto di un legale. Farò notare che il codice è stato commissionato dallo studio, che il codificatore ha ricevuto una busta paga dall'azienda mentre scriveva il codice, quindi il codice è quello dello studio. La mancata produzione del codice da parte del codificatore sarebbe nel peggiore dei casi considerata un furto, il che sarebbe un reato penale.

La libertà non è gratuita. Se lo studio non è disposto a spendere risorse per essere libero da questo individuo, allora non si fa altro che sbattere le gengive. Dovrete tutti affrontare la situazione, perché se il codificatore si allontana o viene investito da un camion, lo studio è SOL.

Considerate il motivo per cui lo stanno facendo. E’ del tutto possibile che gli angoli vengano tagliati per soddisfare i vincoli di tempo, gli obiettivi di performance e le richieste sempre maggiori. Questo spesso porta a debiti tecnici e a un codificatore molto stressato che non ha altra scelta se non quella di risolvere ogni problema fuori dagli schemi.

Questa persona può benissimo scrivere le cose in un modo che solo lui può risolvere perché non ha il tempo di documentare, modificare e mantenere il codice in modo tempestivo. Credetemi quando vi dico che questo ha un effetto del tutto negativo su chiunque si trovi in questa posizione. Non è un ruolo comodo dove qualcuno può sedersi e rilassarsi.

Se, come suggerisce il tuo titolo, non stanno risolvendo i problemi, non ci sarebbe alcun problema. Butteresti semplicemente via il codificatore, con tutto il loro codice, perché è inutile.

Prevenire situazioni come questa è un compito di gestione estremamente elementare. Ne consegue che la direzione che è consapevole del problema non è competente, e la direzione che è competente non è consapevole.

Purtroppo, districarsi in situazioni come questa è un compito di gestione difficile. Quindi, dato che i manager responsabili di questo sviluppatore non sono stati in grado di prevenire la situazione, non contate su di loro per risolvere la situazione.

*L'unico modo per risolvere questo problema è quello di passare ad un livello di gestione più elevato. * Se sono interessati e in grado di risolvere la situazione, non devi nemmeno spiegare più di quanto ci hai spiegato - basta che la rendi meno personale concentrandoti sui programmi, e sui problemi con loro, invece che sul programmatore.

Dovresti sapere che questa è un'opzione ad alto rischio - bassa ricompensa**. Se lo fai, anche se funziona, lo sviluppatore e il suo manager (che probabilmente è anche il tuo manager) ne soffriranno, e sapranno che sei tu il responsabile. L'unico vantaggio che si ottiene facendo questo è che si sta (probabilmente) seguendo il proprio codice etico e di onore, ma si potrebbe perdere il lavoro per questo. Ecco perché alcune delle altre risposte raccomandano di lasciar perdere o di cercare un lavoro migliore, che è la cosa più intelligente da fare.

* L'altro modo per risolvere la situazione è diventare manager in prima persona, e risolvere il problema, ma ci sono diverse insidie.

Dopo la sua autovalutazione ha deciso sia che non ha la possibilità di essere promosso, sia che l'unica ragione per cui l'azienda dovrebbe tenerlo è che gli sta nascondendo il codice.

Non so se siete d'accordo con questo, ma se lo siete, il codice potrebbe probabilmente essere fatto da qualcuno migliore. O se non si spiega il motivo per cui questo comportamento assicura che non potrà mai essere promosso.

Penso che si tratti di capire se vale la pena di risolvere questa situazione, ma anche di come risolverla.

Questo è un compito di gestione. La prima gestione dovrebbe cercare di scoprire se questo è intenzionale. In caso affermativo, si dovrebbe fare un piano per licenziare le persone che hanno commesso il reato. Se non è intenzionale, si dovrebbe fare un piano per addestrare le persone che hanno commesso il reato.

Progettano i loro programmi … in modo che siano gradualmente più difficili da sostituire.

*Non se fossi il capo! *

Ci sono due problemi qui:

1. 1. Cattivo programmatore.
2. 1. Gestione incompetente.

Questo, naturalmente, supponendo che tu rappresenti la situazione correttamente.

Non puoi risolvere il problema #1. C'è una piccola possibilità che possiate risolvere il problema n. 2. Questa piccola possibilità si ha se il capo, per alcuni motivi, semplicemente non è a conoscenza di ciò che sta succedendo. Andate dal capo e ditegli quali sono i problemi che vedete e perché sono negativi per l'azienda. Questo probabilmente fallirà perché il capo è già a conoscenza del problema e non è competente ad affrontarlo, o sa così poco di software e di gestione del software che non è nemmeno competente a capire il problema.

L'unica vera soluzione è iniziare a risolvere il problema #2, in cui si può al massimo giocare un ruolo minore. Il manager incompetente deve essere sostituito.

Il nuovo manager ha poi un incontro con questo programmatore, gli fa spiegare l'architettura e gli dice di interrompere qualsiasi nuovo sviluppo e di documentare tutti i protocolli. Nel frattempo, fa entrare un nuovo ingegnere che è lì per “aiutare” il primo ingegnere a documentare i protocolli, a mettere il software nel controllo dei sorgenti e ad assicurarsi che il codice stesso sia ben documentato. Questo nuovo ingegnere fa ogni nuovo sviluppo, e si spera che corregga i bug e i piccoli miglioramenti del software esistente.

Questo non piacerà al primo ingegnere. Potrebbe mollare, fare i capricci, fare i capricci, creare un oggetto rumoroso, o peggio, sabotare le cose. Ecco perché fare un backup è il primo ordine del giorno. Sarebbe bello avere una transizione fluida dal primo al secondo ingegnere, ma non aspettatevi che questo accada. Il piano è quello di licenziare alla fine il primo ingegnere, se non si arrende o si trasforma (ancora di più) in un distruttore contro l'azienda.

Non si può semplicemente lasciare che questa sciocchezza vada avanti. Più a lungo lo si fa, più è doloroso risolvere il problema alla fine. Non aggiustarla perché sarà già dolorosa è assolutamente il modo sbagliato di pensarla.

In questo caso stavo usando il “tu” retorico. Per rispondere alla domanda su cosa potete fare personalmente, cominciate a portare le vostre preoccupazioni al capo, come ho detto prima. Anche in questo caso, è improbabile che questo si traduca in qualcosa di utile.

Il prossimo passo dipende da cose che non ci hai detto. Può essere molto pericoloso scavalcare il capo. Se è così, allora c'è poco altro da fare se non valutare se si vuole davvero continuare a lavorare lì. Se si tratta di un'azienda abbastanza piccola dove si può tranquillamente parlare con i dirigenti superiori, allora andate avanti. È possibile che la direzione superiore abbia già la sensazione che il software manager di basso livello sia incompetente, ma ovviamente non ve lo diranno. Questa potrebbe essere l'informazione aggiuntiva per loro per intraprendere un'azione più decisiva.

Un'altra possibilità lontana, se il vostro obiettivo primario è quello di risolvere questo pasticcio e vi vedete come un longevo in questo posto, è quello di offrirvi di occuparvi voi stessi dello sviluppo di alcuni strumenti interni. Questo dovrebbe darvi un motivo legittimo per parlare con il primo ingegnere, capire come funzionano le cose, dove vive il codice, ecc. Alla fine, sarai tu il ragazzo degli strumenti e il management potrà sbarazzarsi del primo ingegnere. Poi puoi chiedere loro di assumere qualcuno per quel ruolo, in modo da poter tornare a fare quello che vuoi fare. Anche in questo caso, non è una cosa che suggerisco seriamente, ma è un'alternativa se lo si vuole davvero e se si è disposti a farlo.