Cosa fare come sviluppatore quando per anni il loro team è stato privo di innovazione di prodotto, non ha utilizzato le metodologie del progetto mgmt e ha mantenuto cattive pratiche di sviluppo del software? [chiuso]

Sono interessato a sapere come gestire un processo di sviluppo software attuale che non è stato modificato per anni e che alla fine porterà a guasti del prodotto e del team. Sì, probabilmente il modo più semplice per risolvere questo problema è cambiare lavoro, ma con questa economia è più facile a dirsi che a farsi. Tuttavia, se hai esempi specifici e hai visto o sei stato più volte nella stessa situazione e pensi che la soluzione migliore per affrontare questi problemi, è di lasciare l'azienda, ti preghiamo di supportare la tua risposta. Il punto è che questa domanda ha davvero una risposta soprattutto se più esperti in materia finiscono per indicare che il percorso migliore da percorrere è: percorso A.

So che tonnellate di sviluppatori sono stati o si trovano in situazioni simili. Questo è uno dei motivi principali per cui le aziende passano dall'essere il numero 1 nel loro mercato a diventare l'ultimo o addirittura fuori dal mercato. Speriamo che le risposte in questo post possano aiutare altri sviluppatori ad affrontare ostacoli simili. In un team di sviluppo piccolo o grande questo di solito accade:

• Alcuni sviluppatori sembrano non preoccuparsene e decidono di seguire il flusso e preferiscono lasciare il codice con un sacco di odore di codice così com'è e il processo di sviluppo così com'è,
• Altri si stancano di nessun cambiamento e si dimettono e si trasferiscono in un'altra società,
• Altri sembrano aver paura di parlare e preferiscono stare zitti,
• A volte pochissimi sviluppatori o solo uno cercano di parlare per migliorare il prodotto e dicono al team quanto sia importante seguire le migliori pratiche di codifica e i vantaggi di farlo per clienti, utenti e team. Questo tipo di sviluppatori di solito decide di rimanere con il team per motivi come la società offre vantaggi che pochissime aziende di software offrono o il prodotto ha un grande potenziale, ecc.

Il prodotto nel nostro team è solo una piccola parte del fatturato dell'azienda in quanto ha un ombrello di prodotti (questa società non è una società di software / hardware; pertanto, nessuna controversia sui brevetti costante, almeno per ora, che crea lavoro instabilità). Quello che ho imparato finora in questi anni dalle esperienze di altri sviluppatori e la mia esperienza è che per conoscere davvero un team di sviluppo, ci vuole tempo, non giorni, né settimane, ma alcuni mesi. Durante il processo di intervista se la squadra vuole assumerti o ha bisogno di te; fanno suonare tutto alla perfezione e potrebbero dirti cosa vuoi sentire. Tuttavia, la realtà è diversa quando inizi a lavorare in quel team e inizi a scavare all'interno del codice e ti muovi verso il processo SDLC completo. Questo è quando come sviluppatore, inizi a vedere la realtà del lavoro che hai svolto. Questa realtà rende difficile voler passare da una società all'altra perché è difficile sapere se la società in cui ci si sposta sarà migliore o peggiore. Sì, puoi leggere le recensioni su Glassdoor ecc., Ma quante di queste recensioni online sono reali e non da risorse umane?

Quale sarebbe il modo migliore per affrontare i problemi descritti di seguito considerando che il manager fin dall'inizio ha sempre resistito al cambiamento e gli sviluppatori precedenti hanno fatto lo stesso per anni?

• Mancanza di prodotto Innovazione da anni: il prodotto ha molte potenzialità e porta buoni ricavi all'azienda, ma sembra che sia stato realizzato 20 anni fa. Alcuni utenti si sono lamentati del fatto che il prodotto non è intuitivo né intuitivo, e altri hanno menzionato che vengono utilizzati per app come Gmail e si sentono frustrati quando si utilizza il prodotto a causa della mancanza di funzionalità simili. Il problema principale qui è che quando si tenta come sviluppatore di apportare modifiche al prodotto e si inizia a spostare gli elementi principali del prodotto a solo un paio di pixel di distanza (per renderlo più user friendly o intuitivo), il panico del gestore e ti dice per rimetterlo dove era. Se si tenta di aggiungere una funzionalità a beneficio della produttività per gli utenti, il manager ti chiede di rimuoverla a causa di "gli utenti sono abituati a fare il processo così com'è, ecc." Penso che tu abbia avuto il punto di resistere al cambiamento, al miglioramento e all'innovazione (il manager non è aperto al cambiamento, anche quando tu come sviluppatore fornisci forti argomenti di benefici). L'azienda ha alcuni concorrenti nel settore (i prodotti di alcuni di essi sono molto più competitivi), ma in qualche modo l'azienda ha mantenuto gli attuali clienti per anni.

• Mancanza di coordinamento della gestione del progetto: di conseguenza, alcuni progetti vengono consegnati in ritardo, con bug e alcuni clienti si lamentano (i clienti segnalano anche i bug) o il budget viene utilizzato troppo velocemente prima di consegnare il progetto ecc. Li ho forniti alcuni suggerimenti per il coordinamento dei progetti e le idee vengono ora utilizzati regolarmente per tenere traccia dei progressi dei progetti e delle attività da svolgere.

• Pratiche di sviluppo software errate: l'odore del codice è visibile sulla maggior parte se non su tutti i file, nessuna documentazione, ridondanza del codice, livello front-end e back-end miscelati sullo stesso file, strumenti di sviluppo obsoleti, nessun ambiente di test reale o strumenti di test (basta copiare e incollare file dall'ambiente di sviluppo alla produzione, quindi verifica manualmente che le cose appaiano bene e rilascino). La maggior parte degli strumenti di sviluppo che utilizzo per lo sviluppo e il test sono sconosciuti per team, poiché il team utilizza solo 2 IDE per lo sviluppo del codice e il controllo del codice sorgente è disponibile solo per l'ambiente di sviluppo. Altri sviluppatori hanno tentato di utilizzare i framework più recenti per migliorare i problemi attuali, ma al gestore non piace a causa di "cosa succede se si lascia, quindi chi manterrà quel codice ?, lasciamolo così com'è" Alcuni di questi sviluppatori già lasciato e trasferito in un'altra società.

In sintesi, sono sicuro che situazioni simili si verificano a molti sviluppatori in altre società, ma a causa di circostanze diverse, uno sviluppatore potrebbe preferire rimanere nel team piuttosto che andare in un'altra società per motivi come (convenienza del lavoro, flessibilità del lavoro, benefici per l'azienda o solo perché non è arrivata un'opportunità migliore). Non esiste una compagnia perfetta di cui io sia a conoscenza, ma come faresti tu come sviluppatore a comportarti e ad affrontare tutti questi problemi al fine di mantenere le cose positive e in definitiva promuovere il cambiamento per il miglioramento del prodotto e il miglioramento del processo di sviluppo del software (se ne hai molti anni di esperienza di sviluppo o solo pochi)? So che questo post è lungo, ma ho preferito fornire ulteriori dettagli per aumentare le possibilità di ottenere feedback più utili.

Grazie mille per tutto il tuo feedback e tempo

La citazione di Martin Fowler è rilevante: "Puoi cambiare la tua organizzazione o cambiare la tua organizzazione". Dato che apparentemente hai deciso di cambiare la tua organizzazione (renderla migliore) invece di cambiare la tua organizzazione (lavora per un'altra organizzazione), ecco alcuni suggerimenti.

Innanzitutto, gran parte del tuo modo di agire dipende dai dettagli sulle strutture di potere e sulla politica al lavoro. Esiste un gestore dello sviluppo software o più? Se diversi, ce ne sono alcuni che non sono avversi al cambiamento? Quanti sviluppatori software ci sono? Gli sviluppatori sono interessati a cambiare? In tal caso, è possibile apportare alcune modifiche anche senza l'approvazione della direzione. (Come suggerisce Fowler in Refactoring , potresti non dover nemmeno dirlo alla direzione. Presumibilmente sei assunto per sviluppare software nel miglior modo possibile, quindi se c'è un modo migliore per farlo, allora fallo e basta.)

In secondo luogo, tieni presente che la gestione può avere buone ragioni per quello che sta facendo. Sei uno sviluppatore di software; il tuo compito è sviluppare un buon software e conoscere buone tecniche per farlo. Il compito della direzione è quello di comprendere le problematiche relative alle immagini più grandi e le considerazioni di business che potrebbero essere al di fuori delle tue competenze. Anche se hai ragione e hai torto su ciò che sono le considerazioni aziendali (le tue preoccupazioni sulla mancanza di innovazione, la consegna in ritardo, i reclami dei clienti, ecc.), Capire da dove proviene la gestione ti aiuterà a comunicare nei loro termini, alleviare le loro preoccupazioni e così via.

Terzo (e relativi), assicurati di poter parlare la lingua degli affari. Un'azienda (giustamente) non è direttamente interessata alle buone pratiche di sviluppo del software; un'azienda si occupa di soddisfare le esigenze dei clienti e realizzare profitti. (E molte aziende faranno ovviamente il minimo necessario per soddisfare i profitti possibili per realizzare un profitto.) Sarai più efficace nel promuovere il cambiamento se puoi spiegare come cattive pratiche di sviluppo software e mancanza di innovazione danneggeranno il profitto dell'azienda o nel lungo periodo Salute.

In quarto luogo, è estremamente difficile cambiare la cultura aziendale dalla posizione di lavoratore ordinario. James Shore (un consulente e autorevole agile) ha scritto un diario del cambiamento descrivendo i propri sforzi nel farlo. Consiglio vivamente di leggere tutto. Alcuni punti rilevanti:

• Non provare a cambiare tutto in una volta. Trova i maggiori punti di dolore e inizia da lì. Prendi tutti a bordo aiutandoli a vedere come le tue modifiche affrontano questi punti dolenti.
• Comprendi le prospettive degli altri. Shore parla di come i cambiamenti che stava spingendo dal punto di vista dello sviluppo software sono stati respinti dal project manager perché (Shore) non è riuscito a considerare come i cambiamenti avrebbero influenzato il project manager.
• Alla fine, avrete bisogno di un po 'di sostegno da più in alto, anche se si sta spingendo la maggior parte delle modifiche da soli. Shore parla del suo campione ("qualcuno con cui lavoro che ha più influenza di me e pensa in linea generale con le stesse linee che faccio").

L'ovvia risposta breve è lasciare l'azienda. Altri se ne sono già andati e il tuo manager è un ostacolo attivo al progresso. Se rimani in quella posizione, decadrai lentamente (sia nel morale che nelle abilità). Trovare un nuovo lavoro non è sempre facile, ma in questo caso è necessario.

Nel caso in cui tu abbia scelto di non lasciare la compagnia (la prima riga della tua domanda l'ha dato via):

Il tuo manager ha un capo? In tal caso, in che modo il capo visualizza il prodotto? Puoi (oserei persino dirlo?) Andare oltre la testa del tuo manager e avvicinarti al suo capo? Non dargli fastidio con i dettagli tecnici, esprimi solo interesse ed entusiasmo per crescere all'interno dell'azienda. Presentare idee tangibili per miglioramenti che influenzerebbero in modo misurabile la linea di fondo. Potresti essere promosso da sotto l'ostacolo.

Attenzione però: mentre alcune ruote cigolano vengono unte, altre vengono sostituite. Farai in modo che il tuo manager non ti piaccia. Egli sarà interessare questo, ed egli sarà dire cose poco gentili su di te al suo capo. Percorri attentamente, ma ricorda: nessun rischio, nessuna ricompensa.

Il peggio che può succedere è che stai cercando un nuovo lavoro, che dovresti comunque fare.

Sembra che sia tempo per te di conoscere le vacche in contanti. Vai qui e qui . E dai un'occhiata alla matrice della quota di crescita . Il GSM fornisce alcune informazioni aggiuntive sul perché la vacca da mungere sia in buone condizioni.

Investopedia (secondo collegamento) ha probabilmente la migliore citazione in questo caso.

1. Una vacca in contanti richiede poco capitale di investimento e fornisce perennemente flussi di cassa positivi, che possono essere assegnati ad altre divisioni all'interno della società. Questi generatori di cassa possono anche utilizzare i loro soldi per riacquistare azioni sul mercato o pagare dividendi agli azionisti.

Come hai notato, ci sono alcuni aspetti positivi di essere su un progetto di vacca da mungere.

• È stabile
• È garantito un modesto grado di nuovo sviluppo
• C'è sempre un lavoro di correzione di bug da affrontare.

E come hai anche notato, ci sono alcuni aspetti negativi di questi progetti.

• È stabile e la base di codice non gira molto
• Le nuove tecnologie sono generalmente ignorate (troppo costose per essere imbullonate)
• E le cose diventano ... stantie.

Una volta ho lavorato a un progetto in cui avevo molte lamentele simili a quelle che hai sollevato. Ricordo distintamente di aver condiviso le mie preoccupazioni sulla base di codici con il mio capo in quel momento. La sua intuizione non era particolarmente illuminante, quindi non la condividerò. Ma ho eliminato il progetto e, a dire il vero, è stato uno dei progetti migliori che abbia mai visto. No, non era appariscente. Sì, abbiamo perso le scadenze. Sì, ho raccolto alcune marce mortali da lì. No, la tecnologia del codice non era poi così innovativa, ma abbiamo generato alcune soluzioni sorprendenti.

Il problema sono stato io. Non avevo abbastanza prospettive per capire cosa richiedesse veramente una base di codice per sopravvivere. Non ho avuto l'esperienza di vedere dove stava realmente avvenendo l'innovazione. Non capivo i fondamenti del mercato che dettavano quale fosse il livello adeguato di finanziamento per quel progetto di vacca da mungere.

Ti incoraggio a considerare questo come un'opportunità di apprendimento per capire meglio come funziona il business e come puoi migliorare le tue abilità nell'adattare un prodotto alle esigenze del business. Sebbene il lavoro possa non essere appariscente, il potenziale di apprendimento è elevato e queste abilità ti porteranno bene più avanti nella tua carriera. La maggior parte dello sviluppo a livello aziendale ruota attorno a tutti i vincoli che hai appena citato. Il codice puzza; le cose venivano schiaffeggiate sul posto per contenere le scadenze che erano già sfuggite; molti sviluppatori sono resistenti ai cambiamenti.

Ad un certo punto, passerai comunque dal progetto. Le lezioni che puoi portare con te possono essere vere e proprie lezioni di carriera.

Il tuo manager probabilmente è resistente ai cambiamenti perché vede che nessun valore (aziendale) sta cambiando le pratiche. Il business non vede alcun problema reale perché qualsiasi cosa viene richiesta dal team di sviluppo alla fine viene fatta e i reclami dei clienti non arrivano alle persone che si prendono cura e / o possono fare qualcosa per garantire un risultato migliore. Quello o il business è arrivato ad accettare lo stato attuale delle cose come inevitabili.

Se hai intenzione di cambiare le pratiche di sviluppo, devi mostrare loro che lo stato attuale delle cose non è inevitabile. E l'unico modo per essere ascoltato è costruire un caso aziendale che mostri come lo stato attuale delle cose stia aumentando il costo del prodotto e trattenendo il potenziale di entrate dato un altro stato di cose.

Per creare questo business case devi parlare con il product manager di questo software. Il product manager è la persona che decide in merito alla priorità degli articoli da sviluppare in base al valore aziendale che rappresentano. Il product manager è (dovrebbe essere) quello che può vedere i vantaggi e il valore aziendale di poter costruire software migliore più rapidamente. (E spero che non sia lo stesso responsabile del team di sviluppo.)

Il business case deve affrontare quali sono gli effetti sulle entrate aziendali di:

• Funzionalità che non sono (ancora) implementate per generare più clienti o trattenere più clienti se fossero state implementate.
• Funzionalità inadeguate che generano insoddisfazione dei clienti e portano ad attriti nei clienti.

Il business case deve anche mostrare in che modo le attuali pratiche di sviluppo stanno influenzando la velocità e il costo dello sviluppo delle funzionalità necessarie:

• Quanto tempo ci vuole per apportare anche le modifiche più semplici.
• Quanti bug sono stati introdotti a seguito dello sviluppo di nuove funzionalità, sia nella nuova funzionalità che nei danni collaterali in altre funzionalità.
• Quanto tempo impiega a correggere questi bug che non possono essere spesi per implementare nuove funzionalità.
• Quante chiamate di supporto vengono generate a causa di questi bug e quanto il personale di supporto deve spendere per queste chiamate.

E ovviamente deve mostrare come l'adozione di migliori pratiche di sviluppo influenzerà queste cifre.

Probabilmente stai affrontando la necessità di una (maggiore) riscrittura di (maggiori) parti del software. Anche se non lo fai, allora Come sopravvivere a una riscrittura radicale senza perdere la sanità mentale è un must leggere su come affrontare questo tipo di progetti.

Nota finale: se il product manager non è interessato a tutto ciò, ti perdi: salta la nave.

Penso che questo sia un problema davvero difficile senza soluzione diretta. Ecco alcune idee su cosa potresti provare a fare:

Paura del cambiamento Per quanto riguarda il cambiamento delle cose in meglio, capisco perché i timori del management cambiano. Le persone sono abituate alle cose in un certo modo e se le cambi, gli utenti si ribelleranno (forse). Il cambiamento è una cosa spaventosa e di solito richiede molto pensiero e studio prima di essere fatto. Ciò di cui hai bisogno sono i dati per dimostrare che questo è meglio e che gli utenti lo desiderano. A proposito di Gmail, potresti provare a fare qualcosa come "Google Labs", in cui puoi abilitare / disabilitare nuove funzionalità in modo che gli utenti possano provare. Quindi agganciare una raccolta di dati attorno a questo per aiutare a eseguire il backup delle modifiche.

Cambiare il processo di sviluppo software Ancora una volta il cambiamento è difficile, le persone non cambiano solo perché dici che esiste un modo migliore. Penso che in questo scenario la mia migliore raccomandazione sia quella di dare l'esempio. Fai le cose nel modo in cui desideri che vengano fatte e mostra alle persone quanto è meglio. Inoltre, e questa è la chiave, devi trovare gli altri che condividono i tuoi pensieri. Se riesci a trovare alcune persone a bordo, ciò sarà di grande aiuto per la tua causa. Una volta che puoi mostrare alcuni risultati, puoi avvicinarti al management per rendere più ampi questi cambiamenti. Trovo che uno sforzo dall'alto verso il basso e uno di base aiuta davvero a fare cambiamenti.

Anche dal punto di vista degli strumenti le aziende temono di aggiornarle / modificarle perché costano denaro e i risultati di nuovi strumenti non sono sempre misurabili. La mia raccomandazione qui è di creare i tuoi strumenti. Se fai il tuo, ti risparmierai tempo e farai un lavoro migliore. Speriamo che le persone inizino a notare e poi vogliono usarli anche loro.

Cambiare la gestione Questo è difficile e non sono sicuro di come farlo oltre a essere qualcuno che produce risultati e ha una sua opinione valutata. Una volta valutata la tua opinione, le persone potrebbero iniziare ad ascoltare o potrebbero non esserlo.

Infine, ricorda che il cambiamento è difficile e richiede tempo. Resisti e inizia in piccolo e costruisci.