Spegnere gli incendi VS fare strategie

Musica:

https://ziklibrenbib.bandcamp.com/track/in-my-labyrinth-mind

https://ziklibrenbib.bandcamp.com/track/feeling-good

Puntata:

Articolo tradotto da https://www.codesimplicity.com, parla a degli informatici, ma ci sono spunti molto interessanti, per esempio questa cosa calza molto bene in questo momento e mi trova d’accordo:

Se costruissi tutte le politiche e i modelli di lavoro della tua azienda basati solo sulle decisioni prese durante i periodi di estrema emergenza, alla fine sembrerebbe una società totalmente pazza e probabilmente fallirebbe.

Dove per società, intenderei la Società civile 😛

Buona lettura dall’inizio:

C’è un punto che ho recentemente sottolineato agli ingegneri che ho capito che sarebbe stato prezioso se fosse stato condiviso più ampiamente.

Quando lavori in ingegneria, ci sono diversi tipi di attività che ti vengono affidate. Alcuni compiti sono emergenze o lavoro a breve termine. A volte lo chiamiamo “spegnere gli incendi”, specialmente quando il lavoro riguarda la gestione di qualcosa che viene urgentemente rotto o qualcosa immediatamente necessario senza indugio.

Altri compiti sono di natura strategica. Hai raccolto informazioni su ciò che è necessario e / o desiderato dai tuoi utenti, hai progettato una soluzione e stai lavorando su di essa metodicamente e in modo intelligente.

È importante capire quando stai facendo quale tipo di lavhttps://ziklibrenbib.bandcamp.com/track/feeling-goodoro e pensarci in modo diverso.

incendi


Quando spegni il fuoco, l’obiettivo è spegnere il fuoco. Fondamentalmente vuoi fare qualunque cosa sia il minimo lavoro per spegnere il fuoco in modo da poter tornare al tuo lavoro strategico a lungo termine. Non vuoi essere coinvolto nella costruzione di sistemi enormi e complessi che vivranno per sempre, solo per spegnere un incendio. Le emergenze sono il momento in cui vuoi fare un lavoro “veloce e sporco”. Non significa che dovresti fare un cattivo lavoro. Ma non dovresti creare un sistema a lungo termine ad alta manutenzione per spegnere un incendio.

Esistono diversi tipi di incendi. A volte un dirigente o un altro team viene da te con una richiesta immediata, qualcosa che deve essere fatto nelle prossime settimane o giù di lì. Quello che vuoi fare è capire come portare a termine quel compito e toglierlo di mezzo in modo da poter tornare al tuo lavoro strategico a lungo termine.

Altre volte, hai una sorta di emergenza reale, come un’interruzione. È più chiaro in quel caso che dovresti semplicemente risolvere l’interruzione e non correre in giro a fare un sacco di altre cose. Un’interruzione non è il momento in cui vuoi dire: “Bene, aspettiamo di scrivere un documento di progettazione e rivederlo la prossima settimana con i nostri inAgegneri senior”. Lo stesso vale per qualsiasi incendio: un incendio non è il momento di applicare i metodi e i sistemi di progettazione software a lungo termine.

Esempio


Facciamo un esempio più concreto per mostrare di cosa sto parlando. Diciamo che un dirigente viene da te e dice: “Abbiamo un cliente che vuole darci un milione di dollari la settimana prossima, ma prima che lo facciano, dobbiamo produrre un grafico che mostri come i nostri server resistono ad alto carico. ” Diciamo, non hai nemmeno alcun sistema per registrare il carico sui tuoi server.

Se ci pensassi in un modo strategico a lungo termine, potresti dire: “Ah, beh, dovremmo avere un sistema che tenga traccia del carico sui nostri server. Dobbiamo capire in dettaglio come funzionerebbe lo storage, come possiamo essere sicuri che sia accurato, come lo monitoriamo e come lo testiamo. Quindi dovremmo lavorare con un progettista dell’esperienza utente per assicurarci che i grafici che produce possano essere ben compresi dai suoi utenti, conducendo ricerche utente standard e elaborando una progettazione dell’interfaccia utente per questo. ”

Non sarà fatto entro una settimana. Inoltre, è una perdita di tempo. In realtà non hai idea se questo “incendio” accadrà di nuovo o no. Solo perché qualcuno è venuto da te con una richiesta urgente una volta non significa che questo sarà un bisogno a lungo termine. Potrebbe sembrare che lo sarà, e potresti immaginare che lo sarà, ma perché indovinare i progetti strategici a lungo termine? Non è necessario indovinare il lavoro a lungo termine: quando svolgi un lavoro a lungo termine, hai il lusso di fare ricerca per scoprire quali sono le esigenze e i requisiti degli utenti reali. Quindi fallo e costruisci cose basate su quello, non sulla base delle tue ipotesi.

Invece, ciò che dovresti dire è qualcosa del tipo: “Ok, elaborerò un test di carico molto semplice che posso eseguire manualmente da uno script sulla mia macchina, domani. Distribuirò una nuova versione del server che scrive solo le informazioni sul suo carico in un file di registro, quindi creerò manualmente un grafico basato sull’analisi di quel registro. ” Tutto ciò era fondamentalmente il lavoro minimo richiesto per risolvere il problema.

Anche quella soluzione comporta un rischio, però: hai modificato il server per registrare qualcosa relativo al carico. È possibile che in seguito qualcuno arrivi e pensi di aver pensato che si trattasse di un meccanismo supportato a lungo termine per tracciare il carico del sistema e fare affidamento sul fatto che sia ben progettato e ben congegnato quando non lo è. Ciò evidenzia un punto molto importante:

Non prendere mai decisioni a lungo termine o implementare soluzioni a lungo termine durante un incendio.

In effetti, potresti persino voler annullare intenzionalmente tutto il lavoro svolto durante l’incendio, come rimuovere quella linea di script, solo così nessun altro pensa che tu abbia preso una decisione a lungo termine.

Questa regola non si applica solo ai dettagli tecnici di implementazione, ma anche ai cambiamenti organizzativi o a qualsiasi decisione. Ad esempio, supponiamo che sia in corso un’interruzione. Durante l’interruzione non è il momento di parlare di come impedirai che accada in futuro o di come dovresti cambiare i tuoi normali processi quotidiani.

L’unica volta in cui è sicuro prendere decisioni a lungo termine basate su un incendio è quando si sta facendo un “post mortem” – una revisione razionale della situazione dopo che l’incendio è stato “spento”. Quindi puoi sederti e dire: “Okay, che tipo di lavoro strategico vogliamo fare per evitare che si ripetano incendi come questo?” o “Che cosa abbiamo imparato da questo che potremmo usare per cambiare il modo in cui lavoriamo?

Questa regola è estremamente importante. La violazione crea follie che possono distruggere i gruppi. Se costruissi tutte le politiche e i modelli di lavoro della tua azienda basati solo sulle decisioni prese durante i periodi di estrema emergenza, alla fine sembrerebbe una società totalmente pazza e probabilmente fallirebbe.

Lavoro strategico


L’altra estremità dello spettro (ed è uno spettro, non è in bianco e nero) da “spegnere gli incendi” è: fare un lavoro strategico. Fondamentalmente, hai un obiettivo noto e stai lavorando per raggiungerlo, applicando tutti i principi di base della progettazione del software, assicurandoti di pensare a lungo termine e collaborando in modo intelligente con il tuo gruppo per creare qualcosa di sostenibile.

Allo stesso modo, se applichi i metodi e i sistemi di “spegnimento degli incendi” al lavoro strategico, causerai un disastro. Se tratti ogni singolo progetto come se fosse un’emergenza e lo fai semplicemente “veloce e sporco” perché “deve essere fatto domani” (anche se in realtà non lo è), finirai con un casino. Quello che accadrà effettivamente è che creerai incendi! Il tuo sistema sarà progettato in modo così scadente che cadrà, causerà problemi, sarà difficile da mantenere e alla fine ti consumerà completamente nello spegnere “incendi” attorno a questo pasticcio mal progettato.

Quando applichi i principi di Emergenza al lavoro strategico, non realizzi mai il tuo lavoro strategico. Se vedi un’organizzazione ingegneristica che sembra non riuscire a fare le cose a lungo termine, questo è molto spesso il motivo per cui hanno trattato tutto come se il mondo fosse in fiamme e quindi non possono mai andare avanti.

Il lavoro strategico richiede molto di dire: “Ok, capiamo le tue esigenze. Grazie per averci detto quali sono i tuoi problemi. Stiamo costruendo una soluzione per te, la stiamo facendo nel modo giusto e ci vorrà un po ‘di tempo. Non per sempre, ma ci vorrà del tempo per farlo.

Penso che a volte i dirigenti si preoccupino che se dicono agli ingegneri di “prendere abbastanza tempo”, che gli ingegneri diventeranno pigri e non completeranno mai il lavoro. Questa potrebbe essere una preoccupazione legittima in alcune aziende, e sicuramente i dirigenti hanno interesse a far andare avanti le cose in modo che l’azienda possa consegnare i suoi prodotti! Ma deve esserci un equilibrio tra l’incoraggiamento delle persone a consegnare in tempo e la garanzia che seguano i processi e le procedure di sviluppo del software a lungo termine. In generale, è meglio, quando si fa un lavoro strategico, sbagliare sul lato di fare un po ‘troppo design, un po’ troppa recensione, ecc. Non sto dicendo di esagerare e smettere di costruire cose, o sottoporre tutti a revisioni non necessarie solo perché qualcosa “potrebbe averne bisogno”. Sto solo dicendo che se non sei sicur*, quella non è la direzione in cui dovresti andare, pensaci.

 

Fare entrambi

Fintanto che applichi i principi generali di cui sopra, è possibile che una squadra (o una persona) gestisca contemporaneamente il lavoro strategico e gli incendi (almeno nella stessa settimana o mese). Il trucco sta nel fare un lavoro minimo sugli incendi, per assicurarsi che le emergenze vengano gestite e i commerciali continuino a ridacchiare, e quindi concentrarsi nuovamente sul lavoro strategico una volta spento l’incendio.

Dopotutto, se lo stai facendo nel modo giusto, il lavoro strategico dovrebbe essere l’elemento più importante per il business: le cose che hai studiato e che sai avranno il massimo impatto se le consegnerai, a lungo termine. Quindi spegni gli incendi e torna a fare ciò che sarà effettivamente importante a lungo termine.

-Max

Fonte https://www.codesimplicity.com/post/fires-vs-strategy/

Autore