Come essere un buon membro del team e spingere il team verso nuovi paradigmi e tecnologie allo stesso tempo.

Devi spiegare due cose in ordine per una nuova tecnologia / paradigma / linguaggio / metodologia / qualsiasi cosa per avere qualche possibilità di successo in una squadra. Innanzitutto, è necessario spiegare cosa non funziona con l'approccio attuale. Devi quindi spiegare in che modo la tua tecnologia proposta risolverà questi problemi, senza introdurre problemi più grandi (che tu prevedi, almeno).

Se la soluzione attuale del team funziona bene per il team, non vedono alcun motivo per cambiarlo, quindi l'indifferenza. Se non hai spiegato il motivo per cui la tua soluzione sarebbe adatta per questa squadra in questa situazione , la ignoreranno come parole d'ordine, specialmente se dici "Dovremmo usare DevOps per questo", senza altra spiegazione, perché a quel punto è solo una parola d'ordine.

Fai la tua ricerca e assicurati di non buttare fuori parole alla moda. Trova i numeri sui vantaggi della programmazione della coppia (conteggi ridotti degli errori, fattore bus più alto, ecc.), Scopri perché Kubernetes è una buona soluzione per le tue app e scopri cosa ne sarà del DevOps a vantaggio del tuo team.

Alcune cose come DevOps sono davvero solo parole d'ordine, e anche i gruppi che non fanno "DevOps", in realtà ne fanno davvero grandi pezzi.

Ad esempio:

• hai un repository di codice?
• Esegui i test unitari prima di promuovere il codice?
• Le tue distribuzioni sono automatizzate?

Ce ne sono molti altri. Molto di questo accadeva già prima che DevOps desse semplicemente un nome ad esso. Quindi posso vedere come dire alla tua squadra che "abbiamo bisogno di fare DevOps" potrebbe essere incontrato con "è solo una parola d'ordine".

Forse sarebbe utile consigliare solo parti specifiche di DevOps senza menzionare in realtà DevOps. Ad esempio, se si dispone di un repository di codice e di unit test, ma la distribuzione non è automatizzata come potrebbe essere, si potrebbe consigliare un modo specifico per migliorare tale automazione. O magari mostrare come uno sniffer di codice può migliorare la coerenza del codice e come può essere automatizzato in modo che la gente possa monitorare la qualità del proprio codice senza dover fare altro che controllarlo nel repository.

Gli sviluppatori sono persone impegnate e raramente vogliono occuparsi di parlare di marketing. Ma se riesci a mostrare loro un modo per essere più produttivi con meno sforzo, è una vittoria e se non devono spendere cicli preziosi per imparare nuove procedure, ancora meglio.

Suppongo che ci siano una serie di argomenti che puoi usare internamente per spingere nuove tecnologie o metodologie.

1. Pitch to Managers: i nuovi progetti di introduzione alla tecnologia possono essere una facile conquista per i nuovi manager. "Che cosa hai fatto nella tua ultima posizione? Ho introdotto il prodotto X e salvato la società $$$."

2. Pitch to Devs: l'uso della nuova tecnologia sembra buono sui CV degli sviluppatori. consentendo loro di candidarsi per posti di lavoro più numerosi e più remunerativi. 'CV Driven Development'

3. Pitch to Admins: l'automazione dei processi manuali riduce il carico di lavoro delle persone.

Il pericolo di provare a introdurre nuove cose è che ti stai liberando di cose vecchie. Cose vecchie a cui forse la gente ha attribuito la reputazione.

es. Se avessi introdotto Scrum l'anno scorso e avessi ottenuto un aumento, non posso permetterti di cambiarlo in KANBAN quest'anno.

Trova le cose che a nessuno piace sostituire o trovare cose che puoi aggiungere senza sostituire nulla.

Capisci chi ha introdotto cosa e quando prima di suggerire qualcosa.