Ottimizza il tuo team di programmazione / sviluppatori

Question

Di recente ho lasciato un grande ospedale universitario per un ospedale molto più piccolo a causa dell'aumento della retribuzione e perché era un incentivo alla carriera. Naturalmente queste due cose sarebbero generalmente qualcosa di cui essere entusiasti e un grande risultato (specialmente per qualcuno della mia età) ma mi sono ritrovato a fare il broncio all'interno mentre guido al lavoro ogni mattina, ed ecco perché. Il nuovo t = eam a cui ho aderito è terribilmente indietro nel tempo con pratiche di codifica, tecnologia più recente (sì, usano ancora il classico .ASP) e software - lasciandomi in una distorsione temporale all'indietro dall'uso di VS2008, .NET 3.5 e SQL Server / BIDS 2008 all'utilizzo di antiche reliquie SQL 2000 / VS 6.0.

All'inizio, non così male, ho pensato che non tutte le aziende fossero immediatamente all'avanguardia e stanno solo aspettando quella giusta scintilla per inviarle nella direzione del cambiamento e del miglioramento - no - ho iniziato a suggerire (in modo professionale e in modo non condiscendente) alcuni nuovi strumenti e quali benefici avrebbero avuto per la nostra compagnia sia dalla nostra parte che dalla parte dei clienti ma loro (come nel team di cui faccio parte) mi guardavano come se fossi un alieno e mi davano il semplice, perché dovremmo aver bisogno di quella roba, anche dopo aver fatto il mio caso.

Questo mi ha portato a credere che potrei non farlo nel modo giusto e speravo che alcuni sviluppatori / ingegneri senior condividessero le loro esperienze quando erano più giovani e avevano appena iniziato. So che i tempi sono cambiati, ma ritengo che sarebbe comunque utile e ogni consiglio sarebbe molto apprezzato!

Grazie a tutti!

Answer 1

È inutile adottare nuove tecnologie a meno che non risolvano i problemi reali in modo più semplice ed efficiente delle tecnologie precedenti. (Inclusa la curva di apprendimento.).

È possibile che la tua università abbia una quantità enorme di codice legacy, che si basa su quelle vecchie tecnologie. Passare a quelli successivi può essere un processo estremamente costoso e noioso che è abbastanza difficile da giustificare.

Il modo di introdurre nuove tecnologie potrebbe essere un cambiamento nell'architettura, come l'università nel suo insieme decide di passare a SharePoint o altro, o in un nuovo progetto, in cui è possibile dimostrare i vantaggi delle nuove tecnologie, e lasciare che gli sviluppatori esistenti abbiano il tempo di comprenderli.

Qualcosa da tenere a mente con tutto ciò, è che alla maggior parte delle persone non piace il cambiamento, e cambiando la tecnologia esistente si farà un passo avanti. Ad esempio, gli esperti in particolari sistemi o tecnologie.

Answer 2

Innanzitutto, tieni presente che suggerire cambiamenti importanti quando sei nuovo è quasi sempre una cattiva idea. Prima fai in modo che ti rispettino attraverso le prestazioni, poi suggerisci delle modifiche. Quindi potresti anche capire il costo per l'impresa di apportare tali cambiamenti, motivo per cui non li hanno apportati.

SE ti hanno detto che stavano usando questi strumenti prima che tu andassi lì, dovresti accettare che questo è l'ambiente in cui scegli di vivere e lavorare lì per un po 'prima di sollevare di nuovo l'argomento. Se ti hanno detto che ti volevano perché hai le capacità che mancano per andare avanti, allora la persona con cui devi parlare è il responsabile delle assunzioni, non la squadra. Nota che questo non creerà amici per te nella squadra.

Il mio suggerimento principale per te è che inizi a leggere qualcosa sulla politica dell'ufficio. Crea delle alleanze prima di riprovare. Forse ci sono altre persone che vogliono anche lavorare con cose nuove. Forse alla DBA non piace nemmeno essere bloccato con abilità di dieci anni.

Per quanto riguarda il passaggio da SQL Server 2000 al 2008, è possibile sottolineare che 2000 non sarà più supportato e che quando uscirà SQL Server 2010 non esiste più un percorso di aggiornamento diretto. Questo è ciò che alla fine ci ha permesso di iniziare l'aggiornamento al 2008. Meglio convertire prima che ciò accada. Cerca nel sito Web Microsoft i dettagli esatti di ciò che accade quando.

Answer 3

Sei sfortunato, francamente. Se non vedono alcun bisogno di imparare, non lo faranno mai da soli. Dovrai lavorare per ottenere le nuove cose in ufficio e probabilmente trovare un modo per pagare un po 'di formazione per loro. O convincere i loro capi a licenziarli.

In molti ambienti non tecnologici, le persone si sistemano nella loro routine e continuano a utilizzare gli stessi strumenti, anche se non aggiornati. Visto cento volte.

Answer 4

Ci sono molte variabili sconosciute qui, così tante che è difficile dare consigli. Mi piacerebbe sapere:

1. Stai gestendo questa squadra o solo un programmatore?
2. Il tuo responsabile delle assunzioni ti ha portato con una missione specifica per aggiornare il team alle nuove tecnologie?
3. Qual è l'atteggiamento dell'alta direzione per quanto riguarda l'aggiornamento delle tecnologie utilizzate?

Se sei responsabile di questa squadra, spetta a te stabilire l'ordine del giorno, eccitare tutti per la nuova direzione e, possibilmente, licenziare qualcuno per mostrare agli altri che intendi affari (preferibilmente quello che geme il più rumoroso o trascina i piedi ovviamente).

Se sei solo una scimmia di codice, o se il management superiore sta bene nel modo in cui le cose stanno funzionando ora, quindi inizia a inviare il tuo curriculum, perché non sei in grado di cambiare nulla. E la prossima volta che prendi un lavoro, chiedi informazioni specifiche sulle tecnologie che stanno utilizzando.

Answer 5

Questo succede sempre.

Avresti dovuto chiedere quali strumenti usano e come funzionano prima di accettare di unirti a loro. Vorrei anche segnalare qualcosa come " Se scopro che hai inventato solo per farmi iscrivere, non rimarrò a lungo. & Quot ;.

Answer 6

Scoprirai che le persone resistono al cambiamento fortemente e dovresti conoscere i motivi per cui le persone usano per rifiutare il cambiamento per provare a cambiarlo.

In primo luogo le persone in generale evitano il rischio (con alcune eccezioni "adozione anticipata"). Cioè, le persone evitano il rischio e ogni cambiamento è un rischio.

In secondo luogo, nella tua situazione, le persone tendono ad avere paura di DOVE il cambiamento le metterà. Guardalo in questo modo: uno sviluppatore del tuo team penserà "se passiamo alla tecnologia xxx, che effetto avrà sulla mia carriera? In che modo influenzerà le mie possibilità di ottenere una promozione o addirittura essere licenziato? Non conoscono la nuova tecnologia, non vogliono diventare obsoleti o perdere la loro posizione di esperti o qualunque cosa nei "vecchi modi".

Finalmente tutto ciò che è nuovo è difficile da imparare e capire, specialmente quando lavori nella vecchia cosa da molto tempo. Ci vuole tempo e ti fa sentire come se fossi un idiota. Nei team più anziani (e intendo letteralmente in termini di persone anziane) aumenta anche la paura di essere sostituiti per qualcuno più giovane che già conosce la tecnologia.

Se hai intenzione di superare la resistenza dovrai affrontare tutte le cose.

In primo luogo la cosa dovrà essere graduale. Un passo alla volta, un prodotto alla volta. Non tentare di modificare l'intero processo per l'intera azienda. Invece proponi di prendere un progetto minore e applicare la nuova tecnologia ad esso. Il presente è un'opportunità e un test. Se non è utile, non lo useremo più, ma proviamo, il rischio sarà minimo.

Quindi rassicurare le persone. Assicurati che tutti si sentano apprezzati e che tu o la compagnia confida più nei lunghi anni di esperienza nel campo che in ogni data tecnologia utilizzata. Ascolta le persone, rispetta le loro opinioni e fai sentire loro che ti importa di quello che pensano. Ovviamente questo non dovrebbe essere un atto, dovresti davvero sentirti in quel modo. Le grandi squadre si fidano l'una dell'altra.

D'altra parte, gestire la modifica. Le pietre miliari devono essere più ampie, devi tenere conto del cambiamento. Devi far sentire al team che capisci che il cambiamento è difficile e che è un processo lungo. Che nessuno sarà giudicato se la cosa nuova richiede più tempo di quella precedente e che ci si aspetta un fallimento e nessuno verrà licenziato a causa sua.

Alla fine, se vuoi un cambiamento, devi rassicurare le persone e far loro capire che il cambiamento è solo un test, se funziona bene per tutti, se non funziona, allora va bene. Naturalmente anche l'azienda deve capire questo. Per i manager questo significa presentare loro un rapporto rischi / benefici chiaro, affermare la verità e dire PERCHÉ il cambiamento deve essere fatto.

Quando parli con il management, ricorda anche di ricordarli che la concorrenza è sempre là fuori. Devi evolvere o, più correttamente, essere sempre in evoluzione. Anche se il prodotto è lo stesso in termini di funzionalità e più triste di quanto possa sembrare, dal punto di vista del marketing, dire che usi l'ultima tecnologia xxx con la tecnica di sviluppo tardiva yyy è un ottimo gancio. I clienti non sono stupidi, ma non sono nemmeno esperti di computer, quindi sono facilmente impressionati dalle parole fuzz, quindi la concorrenza può rubarli senza davvero avere un prodotto migliore, solo un "nuovo". uno.

Ancora un'altra cosa: forse ti sarà utile parlargli del " Chi mi hai spostato il formaggio? storia " che ruota attorno al cambiamento e al modo in cui il mercato si evolve attorno al cambiamento.

Il cambiamento è una cosa fondamentale nella vita di tutti, sia personale che professionale e dovrebbe essere sempre preso in considerazione. Ogni volta che qualcuno dice "cambiare ora è troppo rischioso" o " non possiamo permetterci il cambiamento " devi davvero pensarci bene ... la foto è vista a lungo termine o tutti stiamo parlando di uno scenario a breve termine? Perché se è quest'ultimo, allora andremo bene per sapere, ma a lungo termine ... qualcosa come dare sempre un prestito a tutti per comprare una casa perché le case aumentano SEMPRE il loro valore ... o lo fanno? ..

Answer 7

Sono solo gli strumenti obsoleti? O è il codice che stanno producendo sottoparte? Se è il codice, la soluzione migliore è la revisione del codice di gruppo. Se si tratta solo di strumenti, è sufficiente produrre articoli e / o documenti in cui sono elencate le caratteristiche che mancano e in che modo potrebbero essere utili al gruppo.

Answer 8

Se la squadra è bloccata in passato, potrebbe non esserci molto da fare al riguardo. Alcuni sviluppatori o non vedono i vantaggi della tecnologia / dei metodi più recenti (e in alcuni casi potrebbero avere ragione) o hanno paura del cambiamento. Direi che impari cosa puoi da loro: ci sono molte abilità interpersonali, di project management, politiche e di altro tipo che puoi imparare. Trascorri il tuo tempo al passo con la tecnologia attuale e tieni gli occhi aperti per avere la possibilità di passare a qualcos'altro. Per ora, impara cosa puoi. Molti sviluppatori si concentrano sulla tecnologia e perdono le competenze importanti di cui avranno davvero bisogno in seguito nelle loro carriere.

Answer 9

Tutti noi abbiamo i nostri pregiudizi sulla piattaforma e sulla tecnologia e quando una nuova persona si unisce a una squadra e vuole cambiare tutto nel loro modo di fare le cose è dirompente e la squadra spesso cercherà di rifiutare il cambiamento, anche se le motivazioni sono bene.

Purtroppo il " Stai usando Java ?? Ick! Dobbiamo trasferire immediatamente tutto questo su C #! & Quot; i tipi hanno reso le persone giustamente scettiche nei confronti del nuovo ragazzo, suggerendo molte cose nuove.

Un suggerimento che potrei offrire quando suggerisco un nuovo processo o tecnologia è quello di inquadrarlo in termini di un problema reale che stanno incontrando e a cui possono essere collegati. La tecnologia non è la soluzione, è la risposta. Trova il problema e magari proponiti di insegnare una borsa marrone sulla tecnologia sottolineando gli aspetti che risuoneranno con il team alla luce dei loro punti deboli. Dimostrare il valore e lasciarli emergere da soli piuttosto che adottare l'approccio del passo di vendita.

Answer 10

Come hai fatto il tuo caso? Professionale e non condiscendente è buono, ma è solo l'inizio.

Quando stai cercando di persuadere qualcuno a cambiare, dai risalto a cosa c'è dentro. Scopri cosa vogliono e mostra loro come può aiutare la nuova tecnologia.

La direzione vuole più lavoro fatto e denaro risparmiato. I manager non si preoccuperanno di desiderare cose nuove e migliori. Prova a trovare casi e studi che dimostrino che andare alle ultime cose ha risparmiato l'X% in denaro e lavoro. Trova o crea buone stime di ciò che costerà (non solo in strumenti, ma in formazione, doppie tracce di sviluppo e simili). Ricorda che le vecchie cose rimarranno in circolazione e devi avere un piano per renderlo conto.

I tuoi collaboratori devono essere informati di come questo è positivo per loro e che non ne soffriranno. Hanno investito molto in questo. Sanno cosa stanno facendo e conoscono la base di codice. Passa a un sistema più recente e non sapranno cosa stanno facendo, non conosceranno la base di codice, all'inizio saranno incompetenti e potrebbero aver paura di diventare sacrificabili. Questo è molto da chiedere alla persona media e potrebbe essere troppo da chiedere ad alcune persone (come il ragazzo che ha tre anni dalla pensione).

Scopri cosa non gli piace del sistema attuale e mostra loro come può aiutare il nuovo software. Discutere della formazione ed essere almeno in anticipo su quanto sarà facile convertire. Se riesci a mostrare loro come fare ciò che fanno di solito nel nuovo sistema, senza preoccuparti di sfruttare le nuove funzionalità, ciò sarà di grande aiuto. Sottolinea che la loro conoscenza non è solo della base di codice, ma dell'azienda e dei suoi requisiti.

E non aspettarti di scaricare le cose legacy. Sarai in grado di introdurre nuovi strumenti solo all'avvio di un progetto e, se è incompatibile con i sistemi legacy, semplicemente non funzionerà.

Questo è difficile, ovviamente, e potresti stare meglio qualche anno e trasferirti in un negozio più moderno.

Answer 11

Come accennato prima, dimentica i progetti legacy se stanno funzionando bene e non riuscirai a convincere nessuno a riscriverli. Un modo migliore potrebbe essere quello di attendere l'arrivo di un nuovo progetto e, a quel punto, suggerire di utilizzare nuovi strumenti. Discuti su come questi strumenti più recenti miglioreranno l'efficienza o altro, ma non dire che dovresti usarli solo perché sono nuovi. Potrebbe essere più semplice farlo con un piccolo progetto che la direzione considererà meno importante.

Dopo aver avviato un progetto, hai vinto metà della battaglia e puoi usarlo come esempio dei vantaggi della nuova tecnologia per la gestione.

Buona fortuna comunque.

Answer 12

Quando il nuovo ragazzo entra e inizia a predicare - anche in modo totalmente legittimo, positivo e utile - sui nuovi strumenti, spesso può impostare un "tu contro di loro". atmosfera.

Non dovrebbe essere così, ma ammettendo che questi nuovi incredibili strumenti risparmieranno loro molto lavoro, è un po 'un'ammissione implicita che hanno perso molto tempo. Anche se sono d'accordo con questo a livello personale (a parte i vincoli esterni, la maggior parte delle persone vuole solo fare un buon lavoro!) Saranno diffidenti su come potrebbe apparire ai loro superiori se "il nuovo ragazzo" ne sa molto di più.

Idea: falli andare ad alcuni eventi degli sviluppatori locali con te. Quindi è più come scoprire nuove interessanti cose insieme e meno come un "i miei strumenti sono migliori dei tuoi" cosa.

Soprattutto, è necessario aggiungere un po 'di grasso al gomito e inchiodare alcuni progetti in modo da accumulare credito nel nuovo posto di lavoro.

Inoltre, ho sempre pensato che SQL Server 2000 sia fantastico. SQL 2K5 e 2K8 sono buoni aggiornamenti, ma 2000 è roba davvero solida; non è come se fossero in esecuzione su Access.