Come modificare le politiche esistenti in un'organizzazione?

Presumo che un'organizzazione che desideri effettuare una trasformazione DevOps abbia alcuni problemi e politiche che è interessata a cambiare. Questo interesse può provenire da top manager, middle manager o persino dal basso verso l'alto. Uno dei maggiori fattori che impediscono questo cambiamento è quello di indurre altre persone a fare il cambiamento.

Ad esempio, in molti casi spingere "nuove" idee come Agile, spesso fallisce. Le persone resistono al cambiamento e sembra un muro che impedisce che accadano cose buone. Eppure c'è un mandato affinché accadano cose buone.

Quali metodi possono essere utilizzati per influenzare i dipendenti di un'organizzazione che iniziano la sua trasformazione DevOps? Tecniche e modi particolarmente specifici che si trovano a funzionare. As-in specifico più ingegneria, meno agitando la mano.

Devi capire che i processi cambiano le persone che li seguono. Man mano che le persone imparano, si interiorizzano e migliorano in un processo, cambia il modo in cui imparano a risolvere un particolare problema. Una serie di processi simili si rafforzano a vicenda in una mentalità che la persona utilizza per risolvere una categoria di problemi e infine formare un insieme di valori che guida le decisioni e le nuove soluzioni a nuovi problemi.

Anche se cambiate il processo, senza cambiare la mentalità e ancor più cruciale per i valori, la persona semplicemente adatterà il nuovo processo per conformarsi agli stessi valori, alla stessa mentalità o persino alla stessa soluzione del processo originale. Ad un certo punto, non è possibile separare questa persona in questa posizione dalla mentalità acquisita o modificare i valori sottostanti.

Per istituire una modifica, hai le seguenti due opzioni:

1. Porta una persona che avrà già i valori e la mentalità giusti e, nel migliore dei casi, capisci il processo che deve essere seguito senza il tuo aiuto.
2. Coinvolgere e responsabilizzare i nuovi dipendenti, assunti di recente, un nuovo assunzione o un trasferimento da un team diverso nell'organizzazione e addestrarlo nel nuovo processo, sperando di instillare la nuova mentalità, sperando che emerga il nuovo insieme di valori.

Se la modifica è locale, potresti preferire un trasferimento interno in quanto tale persona condividerebbe già i valori globali dell'azienda che desideri conservare. In caso di un cambiamento più ampio, è necessario attirare qualcuno dall'esterno per avere una nuova prospettiva e non condividere i valori a livello aziendale che potresti provare a cambiare.

La parte importante è autorizzare la persona, il team o la business unit a seguire i processi e isolarli dal vecchio team, da altri team o dal resto dell'azienda, che potrebbero comunque seguire il vecchio insieme di processi. Poiché è molto difficile isolare tale agente di cambiamento dalla direzione sopra, se il cambiamento deve essere più grande, spesso deve seguire tutta la catena di gestione o arrivare fino in cima.

Nota : è difficile apportare modifiche a qualcosa di più del proprio team senza il supporto della direzione. Anche all'interno della tua squadra è difficile se gli altri sono già disposti a modo loro. Per un nuovo team in una nuova società un evangelista di successo può spesso influenzare le politiche di formazione anche senza il supporto del management semplicemente essendo un leader o creando il percorso di minor resistenza da seguire per gli altri. Ma in società affermata, vedi sopra.

Hack la tua squadra

Realizzare cambiamenti nella tua organizzazione è difficile. Le persone hanno abitudini, resistono al cambiamento e spesso sono a loro agio con lo status quo. Per apportare cambiamenti, in nessun ordine particolare, ecco alcuni strumenti che è possibile utilizzare.

1. Fai sì che gli altri sperimentino il problema che DevOps risolve. Molte volte i vantaggi di DevOps sono compresi solo a livello teorico dal tuo team. La maggior parte dei problemi che si verificano durante l'implementazione sono sperati e raramente riscontrati dal resto del team di sviluppo o della direzione. Per risolvere questo problema, assicurati di parlare dei problemi quando si presentano e menziona come questo problema non si sarebbe verificato se il team stesse usando una soluzione di integrazione continua. Un'altra possibilità è quella di essere sicuri di chiedere agli sviluppatori di risolvere i problemi causati dal loro codice durante la distribuzione invece di risolverlo da soli.

2. Trova i leader . È comune che le persone seguano i leader, siano essi dirigenti o semplicemente la persona più popolare / dominante del gruppo. Ottieni a bordo quei leader con il tuo desiderio di passare a una cultura DevOps e escogita modi pubblici in cui possano essere visti usando o sostenendo le migliori pratiche.

3. Crea fiducia . È più probabile che accettiamo le cose dalle persone dopo che abbiamo già concordato con loro una o due volte prima. Idealmente, puoi trovare piccoli miglioramenti che possono essere fatti senza un cambiamento nella cultura e basarti su quel successo. Tuttavia, se questa non è un'opzione, fai loro semplici domande e offri semplici suggerimenti in modo che abbiano l'abitudine di dire di sì o di essere d'accordo con te.

4. Non vergognarti di ripetere te stesso. La ripetizione funziona e alla fine affonda. Ogni volta che è possibile menziona quanto sarebbe bello se il team stesse usando DevOps. Tuttavia, questo funziona solo se hai prima creato fiducia all'interno del tuo team.

5. Rendilo piacevole . Se ti è permesso costruire una bozza di concetto per la tua situazione DevOps, usa emoticon carine e colori allegri nei rapporti e nelle notifiche. Pubblica gif divertenti quando una build fallisce. Assicurati di non essere fastidioso con i tuoi aggiornamenti.