Otto regole per un'efficace produzione di software

Nel corso della mia carriera, ho partecipato a molteplici progetti software reali e ho osservato come vengono fatte le cose a tutti i livelli: processo decisionale, adozione di pratiche, team building, reclutamento, distribuzione delle competenze, ecc. Ovviamente, approcci diversi hanno prodotto risultati diversi . Essendo una persona orientata al miglioramento, ho notato e raccolto le pratiche più efficaci e i migliori trucchi pratici per aiutarmi nel mio lavoro.

Imparare dall'osservazione è un modo difficile e lungo per farlo. Sarei estremamente felice di scegliere questa conoscenza prima dai libri, invece. Purtroppo non ho trovato nessuno sull'argomento. Così ho deciso di condividere la mia esperienza con altri ricercatori di questo tipo di conoscenza. Si spera che risparmierà loro qualche anno di ricerca personale.

In questo articolo imparerai come battere le prestazioni medie del settore producendo prodotti software robusti e affidabili che richiedono una manutenzione 5-10 volte inferiore. Posso affermare senza falsa modestia che negli ultimi 10-15 anni io (personalmente così come i miei team) ho superato ogni aspettativa, lasciando dietro di sé una scia di successi. I gestori non possono essere più felici.

Una volta che il mio team ha portato a termine un progetto importante in un lasso di tempo incredibilmente breve, per il quale ci è stato assegnato un premio "High Performance Team" dal management superiore. Tutto questo senza restare notti e weekend a sfinirci. Solo lavoro normale.

Vedete, la stessa conoscenza della produzione di software efficace è un potere. In effetti, è una sorta di magia nera che non molte persone riescono a cogliere anche quando è spiegata in parole semplici. Lo riceverai gratuitamente. Continua a leggere se vuoi essere percepito come un mago della produzione di software.

Per chi è questo?

Permettetemi di fare qui un importante, importante, importante disclaimer.

Mi rivolgo a coloro che hanno bisogno di un aumento della produttività. Non tutto nella vita riguarda la produttività. Neanche tutti i progetti software. Ci sono casi in cui non vieni giudicato in base alle tue prestazioni. Ovviamente, queste pratiche non sarebbero di aiuto allora.

Queste tecniche saranno molto utili per team leader, architetti e project manager, sebbene anche gli sviluppatori software senior possano trarne vantaggio.

Regola n. 1: Comprendere la mentalità IT

Il settore IT è un mix di scienza, tecnologia, arte e affari. È abbastanza difficile navigare lì senza comprendere questi aspetti a un livello sufficientemente buono. Il problema più grande è che l'industria stessa è piuttosto complessa; pertanto, anche le migliori pratiche sono complesse. Devi imparare molto e verificare le tue conoscenze praticando molto per avere successo.

L'incredibile velocità di aggiornamento della tecnologia lo rende doppiamente difficile. Niente di ciò che hai imparato dieci anni fa è più necessario. Quindi è necessario imparare a un ritmo accelerato.

Riassumendo tutto quanto sopra, possiamo dire che avere successo nel campo IT non si basa su abilità o sentimenti innati ma su duri esempi pratici. Mai e poi mai "seguire l'intestino" o credere esclusivamente sulla base del sentimento, compreso il tuo.

Se sì, vale la pena considerare l'idea. Altrimenti, chiedi una spiegazione molto buona e molto dettagliata su come la scelta di questo percorso renda migliore la vita della tua squadra. Se supera questo test, pianifica un progetto di prova dei concetti leggero che dimostri sperimentalmente che si adatta al tuo ambiente.

La cosa importante da capire qui è che non ci sono soluzioni giuste e sbagliate perché ci sono molti modi per risolvere i problemi del software. Tuttavia, ci sono buone e cattive comprensioni della soluzione.

Se una persona può articolare chiaramente un'idea in dettaglio o tracciare un collegamento dall'adozione di questa soluzione al successo del team per persuadere altri membri del team, allora possiamo fare affidamento sulla visione di questa persona e sperare in un'elevata possibilità di successo.

Regola n. 2: non mischiare la produzione di software e le metodologie di sviluppo del software

La produzione del software si basa sullo sviluppo del software. Tuttavia, questi due hanno obiettivi, mentalità e pratiche completamente diversi. Cercare di risolvere un problema da uno di questi regni con i metodi di un altro produce risultati ridicoli. È importante comprendere la distinzione e utilizzare metodi appropriati per ciascuno di questi mondi.

Lo sviluppo del software è una combinazione di arte e artigianato. La componente artistica sarà sempre presente indipendentemente dagli strumenti di automazione e dalle metodologie di sviluppo software disponibili. Pertanto, la risoluzione delle attività di sviluppo richiede la massima concentrazione e protezione da tutti gli altri segnali di disturbo.

Il modo migliore per motivare uno sviluppatore esperto è presentare loro un compito nella sua pura forma tecnica con tutti i fattori umani esclusi. Tutti i requisiti dovrebbero essere espressi anche in linguaggio tecnico. Dovrebbero essere facilmente verificabili per consentire loro di navigare verso l'obiettivo durante la loro fase di ricerca da solista.

La produzione di software, al contrario, è più nel dominio dell'amministrazione aziendale. Sai di cosa ha bisogno il tuo cliente da un lato e sai quali risorse del team hai a tua disposizione da un altro. Quindi ora provi a dirigere gli sforzi della tua squadra per raggiungere l'obiettivo. Nel frattempo, puoi anche stimare la tua velocità di avanzamento e presentare un piano ben preparato al capo. Le abilità importanti sono la comprensione dei desideri del cliente, la comprensione dei punti di forza del team e la comunicazione di piani e programmi formali.

Detto questo, vorrei sottolineare che molti ruoli nello sviluppo del software stanno lavorando in entrambi questi mondi, nella costruzione di un ponte tra business e tecnologia, come team leader, architetti, analisti e project manager. Le persone in questi ruoli dovrebbero essere in grado di camminare facilmente tra due piani della realtà e capire quando è il momento di parlare di affari e quando è il momento dell'arte.

Regola n. 3: utilizzare l'archiviazione persistente come estensione della memoria umana

La memoria umana, sebbene sorprendente per capacità, ha i suoi limiti. Ricordi le cose con precisione e durata imprevedibili e, quando le dimentichi, non c'è modo di ricordarle a piacimento.

Ecco perché utilizziamo l'archiviazione di memoria persistente per muoverci a una velocità prevedibile. Non si tratta di documentazione formale come i manuali dell'utente che crei molto tempo dopo il fatto e che altre persone possono usare. Si tratta di utilizzare i documenti letteralmente come estensione esterna della tua memoria durante il lavoro che ti aiuta a completare il processo di sviluppo del software.

Ti consiglio di documentare i tuoi pensieri e i tuoi piani lungo il percorso ogni volta che devi affrontare compiti non banali o compiti che coinvolgono più di una persona. Cerca di renderlo il più economico possibile. Non creare documenti formali con il logo dell'azienda. Un buon strumento sarebbe un wiki aziendale con il tuo spazio di progetto al suo interno. Crea pagine dedicate per le attività o problemi (30 secondi). Quindi aggiornalo ogni volta che hai un'idea o stai per discuterne con gli altri.

In una riunione, dì "aspetta, lasciami mettere giù" e dedica 10-30 secondi per esprimerlo per iscritto. La scrittura non dovrebbe essere estesa, ma dovrebbe essere completa e coerente, come se stessi trasferendo l'idea nella sua interezza sulla carta. Più tardi, tu o chiunque altro leggendo il tuo passaggio dovreste capirlo chiaramente come lo capite adesso. Questo trucco consente di risparmiare un sacco di tempo, ma ti consente di documentare al volo.

Questa tecnica ha due scopi.

Innanzitutto, blocca i tuoi progressi sulla strada del successo premendolo con forza nella pietra. Niente più rischi che qualcuno dimentichi qualcosa, ripeta la stessa cosa ancora e ancora o rinegozi la stessa cosa che era già stata negoziata.

Secondo, schiarisci la mente, scaricando il problema che ti assillava. Ora la tua mente ha fame per la prossima sfida. Che aumento di produttività!

Questo vale per qualsiasi dimensione di progetto o attività. Per quelli più grandi, avrai solo spazi più ampi con una gerarchia di pagine che cresce gradualmente man mano che il tuo progetto si evolve. Il concetto importante qui è preparare uno spazio e una struttura di documentazione prima di iniziare con l'attività per stabilire un protocollo di dumping rapido della memoria!

Per le persone che preferiscono le analogie tecnologiche, paragonerei la nostra mente a un processore con un'immensa potenza di elaborazione ma una memoria operativa limitata. In sostanza puoi pensare a una cosa alla volta. In questa analogia, la tua documentazione funge da memoria persistente, mentre la tua mente risolve problemi complessi con un approccio iterativo. Ad un certo punto, decidi di iniziare l'iterazione successiva, leggere la documentazione precedente e caricare lo stato corrente nella tua memoria operativa, riflettendoci per un po' e aggiornando il codice e la documentazione con le tue nuove scoperte. Passo dopo passo fino al completamento.

Detto tutto sopra, non incoraggio le persone a elaborare molte attività contemporaneamente. Al contrario, meno compiti hai, meglio è. Tuttavia, non molte situazioni lavorative sono veramente ottimizzate per l'uomo e potrebbe essere necessario il multitasking e devi gestirlo in qualche modo. Il trucco di cui sopra aiuta a gestirlo meglio.

Regola n. 4: smettere di perdere tempo con la stima formale del tempo

Non esistono due progetti uguali. La prossima volta che realizzerai un progetto simile, avrai clienti diversi, obiettivi diversi, un team diverso; forse anche tecnologie diverse. Anche utilizzando strumenti e componenti standard, sarà comunque necessario personalizzarne la configurazione e l'architettura. Quando gestisci progetti software, tieni presente che implicano tra il 50% e il 100% di lavoro personalizzato. Richiedono ricerca, discussioni, pensiero, prove e altre attività altamente imprevedibili. In pratica, potresti sperimentare un'enorme differenza in ciò che in superficie sembra essere lo stesso identico tipo di progetto e ciò che hai fatto prima. Un nuovo tipo di progetto, per estensione, è quasi impossibile da stimare esattamente.

Se è così imprevedibile, come dovrebbero i project manager presentare un programma di progetto e attenersi ad esso?

C'è un metodo formale per farlo descritto in letteratura; vale a dire, per suddividere l'intero progetto in passaggi più piccoli, stimare la durata di ciascun passaggio e quindi calcolare la lunghezza totale del progetto combinando la lunghezza di lavoro dei singoli pezzi. Ci sono tonnellate di teoria dietro questo metodo insegnato nei corsi MBA.

Sfortunatamente, però, nessuna quantità di matematica può salvarlo. Questo metodo è notoriamente impreciso, nella misura in cui è completamente inutilizzabile e poco pratico, per non parlare di quanto sia incredibilmente dispendioso in termini di tempo. Non ho mai visto un project manager che utilizzasse metodi di calcolo formali senza alcun aggiustamento, nemmeno tra fanatici metodologici. Nemmeno quando l'azienda ha imposto rigorosamente l'utilizzo di tale metodo! Infatti, i gestori più performanti utilizzano metodi alternativi completamente diversi, come di seguito descritto:

Un buon project manager prende atto del tipo di progetto, dell'ambiente, delle risorse coinvolte, del tipo di organizzazione e di tutti gli altri aspetti del lavoro che influenzano la durata effettiva del progetto. Naturalmente, nessuno ha bisogno di imparare esclusivamente dai propri errori. Tali osservazioni possono essere fatte sia direttamente che indirettamente; ad esempio, attraverso libri o studiando progetti realizzati da altre persone o anche semplicemente trasmettendo la conoscenza da persona a persona. Tale conoscenza statistica di alto livello migliora la navigazione nella pianificazione del progetto personale.

Vorrei evidenziare due importanti conseguenze del metodo sopra descritto.

In primo luogo, l'accuratezza della stima migliora con l'esperienza. Non è possibile che una persona inesperta, armata di qualunque metodologia forte disponga, possa essere brava in questo. In secondo luogo, anche la migliore stima è ancora buona solo in termini statistici. Cioè, si può dire che un certo progetto può richiedere da quattro a dodici mesi. Supponendo che ciò sia corretto, si dovrebbe capire che c'è una probabilità del 50% che il progetto durerà oltre il suo tempo medio di otto mesi.

Comprendere la previsione statistica ha un effetto così incredibile. Un manager saggio metterebbe semplicemente una stima di dodici mesi su un progetto del genere e poi stupirebbe tutti completandolo in anticipo. In altre parole, nessuno si aspetterebbe che un team segua il programma del progetto fino a un giorno.

Il consiglio generale ai project manager e ai loro capi sarebbe di smettere di perdere tempo con metodologie formali di stima del tempo. Incoraggia invece la raccolta di informazioni statistiche sulla durata del progetto e condividi queste informazioni in tutta l'azienda. Conosco aziende in cui un tale approccio è stato implementato a livello aziendale, ottenendo una precisione predittiva miracolosa.

Regola n. 5: Comprendere il costo del cambio di attività e delle priorità di giocoleria

La mente umana è straordinariamente progettata dalla natura. Anche se è incredibile, ha i suoi limiti. In altre parole, è stato progettato per eccellere in aree particolari e in un particolare tipo di attività.

La mente di uno sviluppatore è sicuramente una grande risorsa nello sviluppo del software. Come project manager, saresti interessato a capirlo meglio e metterlo in una posizione in cui si comporta al meglio?

Mettiamola in termini semplici, evitando troppa teoria. Ricorda, la teoria ti porta solo così lontano prima che tu debba imparare dall'esperienza, dalla tua o dagli altri.

La mente umana ha un forte potenziale per la risoluzione dei problemi e la generazione di idee. Sfortunatamente, non è sempre possibile sfruttare questo potenziale, principalmente perché per supportare la generazione di idee, è necessario tenere insieme tutti i pezzi del problema nella memoria attiva allo stesso tempo. Ecco perché la risoluzione di problemi complessi passa attraverso una fase di semplificazione quando un compito viene generalizzato o riformulato per ritagliare pezzi non importanti e diminuire il numero di elementi mantenuti in memoria contemporaneamente. In altre parole, possiamo risolvere un problema complesso molto ristretto o più problemi semplici.

Il rapporto non è lineare, però. Aumentare il numero di cose che fai contemporaneamente compromette drasticamente le tue capacità di risoluzione dei problemi. Ecco perché l'umanità ha sempre impiegato e impiegherà la separazione dei ruoli come ottimizzazione della vita. Due persone che lavorano separatamente su due attività faranno un passo avanti più velocemente che se lavorassero entrambe su entrambe le attività contemporaneamente.

Un'altra caratteristica importante della mente umana è la sua incapacità di passare immediatamente da un'attività all'altra come fanno i computer. In effetti, non puoi semplicemente smettere di pensare a qualcosa a tuo piacimento. Non puoi nemmeno iniziare subito a pensare a un nuovo concetto a tutta velocità. Questo tipo di inerzia mentale è perfettamente illustrato dagli operatori del controllo del traffico aereo. Anche se stanno guardando il radar e vedendo l'intera immagine, devono comunque caricarlo nella loro memoria per funzionare rapidamente. Occorrono dieci minuti prima che un nuovo operatore guardi lo schermo prima di poter sostituire quello vecchio a un cambio di turno.

Ciò che rende le cose peggiori è che non possiamo dimenticare le cose a piacimento. Tutto ciò che abbiamo imparato rimane con noi e svanisce gradualmente con il tempo, occupando uno spazio che potremmo utilizzare per nuove conoscenze. E, peggio ancora, questo effetto è a volte aggravato da una sensazione di "affare in sospeso". È molto più facile dimenticare qualcosa che è stato completato e di cui non avrai mai bisogno in futuro. Mentre quando metti da parte le cose per finire più tardi, il tuo cervello si aggrappa naturalmente alle informazioni contrassegnate come "per riferimenti futuri", non volendo lasciare che nuove conoscenze prendano il suo posto.

Bene. Ora che abbiamo delineato l'idea di cambiare attività, vediamo come funziona in un esperimento mentale nella vita reale (per così dire).

Immagina di avere i tuoi dieci sviluppatori regolari che lavorano su dieci attività regolari, un'attività per persona. Supponendo di poterli racchiudere in un ambiente perfetto e privo di distrazioni, ogni compito può essere risolto in un certo lasso di tempo da un'unica mente. L'intera operazione richiederà tutto il tempo necessario per completare l'attività singola più lunga.

Ora, ripetiamo lo stesso esperimento mentale. Questa volta, cambieremo costantemente le assegnazioni delle attività tra gli sviluppatori senza motivo (importante). Ogni giorno, ogni sviluppatore riceve una nuova attività su cui lavorare. Ancora meglio, accendiamolo ogni ora. Quando finiranno, secondo te? Forse mai.

Il project manager nel primo scenario è stato in grado di eseguire il progetto in modo efficace. I secondi sono riusciti a “eseguirlo”, questo è certo… nel senso che ne hanno facilitato la morte. Congratulazioni. Questa tecnica di eliminazione del progetto è estremamente efficace perché, oltre alla semplice perdita di tempo, abbassa anche il morale dei dipendenti a zero.

La maggior parte delle persone sarebbe d'accordo con l'esempio sopra quando viene loro presentato in un modo puramente accademico come quello. Tuttavia, nella vita reale improvvisamente dimenticano tutto sotto la minima pressione. Il grande capo richiede un rapporto sullo stato di avanzamento o il cliente chiede una certa data di implementazione delle funzionalità: quasi qualsiasi evento esterno può far precipitare un project manager dal team ed esprimere la propria preoccupazione, seguito da una raffica di riassegnazioni di attività e giocoleria di priorità in un tentare di guadagnare un po' di tempo qua e là, risultando alla fine nient'altro che buttare il progetto fuori pista ancora di più.

Questo è uno scenario di vita reale che si verifica abbastanza spesso, sfortunatamente.

Un buon manager si alza e protegge la squadra da tali disturbi minori assorbendo l'onda d'urto emotiva e convertendola in argomenti di discussione futuri produttivi. È sicuramente difficile emotivamente, ma è l'unico modo per mantenere la squadra in un buon ritmo di lavoro e per fargliela raggiungere.

Regola n. 6: utilizzare le revisioni dell'architettura come un modo per migliorare la progettazione del sistema

Il settore IT opera con nozioni di sovra -e sotto -ingegneria. Quando viene fuori in un'intervista, tutti dicono che l'eccesso di ingegneria è male. È facile rispondere perché la domanda stessa trasmette una connotazione negativa di "sopra" che significa "troppo". Il vero know-how pratico sarebbe riconoscere quando la tua architettura diventa eccessivamente ingegnerizzata ed evitarlo nelle fasi iniziali.

Lascia che ti dia alcuni dei miei suggerimenti collaudati su questo.

Prima di tutto, la soluzione può essere considerata troppo ingegnerizzata se esiste un'altra soluzione più semplice che offre tutte le funzionalità richieste. Ciò significa che se non conosci una soluzione più semplice, qualunque soluzione tu possa offrire è la migliore ai tuoi occhi a meno che qualcuno non dimostri che hai torto.

Se il nostro architetto immaginario cerca veramente la perfezione della soluzione, la consueta revisione dell'architettura garantisce che sia sufficientemente ottimale. Sfortunatamente, la revisione dell'architettura richiede almeno alcuni altri architetti qualificati. In molti casi corre il pericolo di non essere disponibile o poco pratico. In assenza di revisione tra pari, gli architetti sono inclini a errori comuni. Esaminiamoli uno per uno e discutiamo i possibili rimedi per ciascuno.

Uno degli errori più comuni è la progettazione senza un obiettivo aziendale in mente. Appare ovvio che qualsiasi attività lavorativa debba essere legata alla soddisfazione del consumatore finale o al successo aziendale o ad un'analoga esigenza aziendale. Eppure spesso è possibile vedere l'architettura progettata in tutto o in parte senza tale scopo in mente. Il ragionamento o è assente o si riduce all'uso del maggior numero possibile di campane e fischietti moderni.

L'architetto in questo caso non fa ciò per cui il consumatore ha pagato. Piuttosto, giocano con fantastici giocattoli per il loro divertimento e piacere. Questo non è in alcun modo accettabile nell'industria formale. Eppure, sembra che accada abbastanza spesso comunque.

A volte, il problema sta nella personalità dell'architetto e nella sua ossessione per determinate tecnologie o strumenti. A loro piace semplicemente usarli e non sono in grado di spiegare in modo coerente quale esigenza aziendale stanno cercando di risolvere. Vicino a questo c'è un altro caso in cui le persone non sanno altro che costruire qualcosa da piccoli pezzi. Sicuramente, qualsiasi evento esterno fa scattare la loro voglia di tuffarsi nel mondo del design e non tornare mai più da un vero cliente. Anche se l'innesco iniziale può essere un valido input aziendale, il loro prolungato distacco dalla realtà diminuisce l'utilità delle loro opere d'arte.

La cura per questo è molto semplice, ma richiede autodisciplina. Un buon architetto non dovrebbe mai toccare carta e penna fino a quando non può rispondere in modo chiaro e onesto perché è necessario. Tale bisogno potrebbe assumere forme diverse. Potrebbe essere un requisito formale, un'esigenza implicita di miglioramento del prodotto o l'emergere di nuove tecnologie che rendono meno efficace il design precedente. In ogni caso, non dovrebbe essere un fattore scatenante formale fintanto che gli architetti stessi ne comprendono la forza trainante. Quindi possono usare questa forza come verifica finale della loro qualità progettuale.

Un altro problema più difficile da rilevare è legato al pensiero dell'architettura a blocchi. Le persone con una tale mentalità credono che esista una soluzione per tutto e tale soluzione è sempre implementata come un elemento costitutivo. In altre parole, traducono la funzionalità in componenti direttamente senza valutare l'architettura nel suo insieme. Possono semplicemente collegare un componente che fornisce la funzionalità desiderata al sistema quando si presenta la necessità di tale funzionalità. Il più delle volte, ciò soddisfa i requisiti formali ma lascia il sistema in uno stato incoerente. Il nuovo blocco non è stato selezionato sulla base della compatibilità del sistema esistente per lo sviluppo, il supporto o persino il modello di licenza dell'azienda. Pertanto, il team tenta di modificare la configurazione esistente o di implementare questa funzionalità tramite la capacità del sistema esistente. Di conseguenza, il supporto e la manutenzione del sistema si trasformano gradualmente in un incubo contorto seguito da vicino da un degrado delle prestazioni.

Non esiste una soluzione semplice per questo problema, poiché la progettazione del sistema è un'arte e non è mai possibile prevedere se un nuovo componente deve essere aggiunto o può essere evitato. La pratica migliore sarebbe probabilmente quella di mantenere un backlog di manutenzione e problemi architetturali che si accumulano nel tempo, seguito da revisioni periodiche dell'architettura generale del sistema. Questa revisione periodica può anche prendere in considerazione le tecnologie emerse. Quindi lo scopo generale delle revisioni dell'architettura non dovrebbe essere quello di risolvere i problemi, ma di valutare la potenziale fattibilità dei miglioramenti desiderati e del sistema nel suo insieme contro l'inevitabilità incombente dell'obsolescenza.

Regola n. 7: Valuta i giocatori della squadra

Alla maggior parte dei professionisti del settore IT è stato chiesto in un'intervista se sono bravi giocatori di squadra o se lavorano bene in una squadra. Eppure, probabilmente nessuno ne ha mai visto una definizione chiara in letteratura. Ovviamente, una tale persona contribuirebbe al successo della squadra in generale, ma poche persone possono effettivamente definire qualità personali distintive che assicurino tale successo.

Ho osservato molte persone che lavorano a diversi livelli e ho visto come le loro qualità personali hanno influenzato l'avanzamento del progetto. Vorrei presentare i seguenti suggerimenti sulle qualità personali che sono più utili nel lavoro di squadra.

Comunicare

La prima e più importante qualità, ovviamente, è la capacità di comunicare.

Immagina una persona con zero capacità comunicative. Sicuramente non ricevere feedback dai membri del team li rende completamente inutili. Questo è così ovvio che nessuno sta effettivamente misurando questa abilità durante l'intervista, il che implica che l'abilità è a un livello sufficientemente buono fintanto che la persona può parlare bene.

La comunicazione non è un'abilità binaria sì/no; è più una finestra di trasferimento di informazioni. Più è ampio, più veloce e chiaro sarà lo scambio di informazioni.

Poiché l'intervallo di apertura di quella finestra varia notevolmente tra la popolazione, la misura della larghezza di tale finestra è una caratteristica importante di un giocatore di squadra. Tieni presente che stiamo parlando di trasmettere informazioni in questo contesto, ma non di parlare senza intoppi o incoraggiare le persone o motivarle o organizzarle attraverso conversazioni e comunicazioni.

Anche lo stile di comunicazione è irrilevante. Le informazioni possono essere fornite oralmente, testualmente, per immagini o in modo misto. La persona può parlare velocemente o lentamente. Possono essere amichevoli, come guardarti negli occhi e sorridere continuamente, oppure possono distogliere lo sguardo e parlare con voce monotona. Lo stile può influenzare la tua percezione personale del tuo collega, ma finché capisci chiaramente cosa significano, qualsiasi stile è sufficiente.

Passiamo ai casi pratici sul rilevamento e la misurazione delle capacità comunicative.

Ci sono due aspetti principali delle capacità di comunicazione in generale. Il primo è la volontà di condividere le informazioni. Alcune persone sono desiderose di condividere, ma altre cercano di nascondere le informazioni. Quell'inclinazione è più o meno naturale, ma può essere cambiata lentamente con l'automotivazione e l'allenamento. È lecito ritenere che la persona che mostra un tipo di volontà di condivisione delle informazioni lo dimostrerà anche in futuro. Ecco perché questa caratteristica è utile per prevedere il successo futuro di un candidato in una squadra.

Nella vita reale, le persone che cercano di nascondere le informazioni sono facilmente visibili. Di solito cercano di fornire informazioni intenzionalmente inutili invece di qualsiasi cosa effettivamente necessaria. Oppure fanno domande preliminari per indirizzare il flusso di informazioni verso l'interno e ridurre al minimo le loro risposte a un'occorrenza di "necessità di sapere". Qualunque sia la loro tattica, alla fine sentirai di non aver ottenuto le informazioni desiderate da loro, o che ottenere le informazioni richiedeva uno sforzo extra.

È importante capire l'intento, poiché alcuni tipi di persone aperte potrebbero farti domande preliminari per comprendere meglio la tua domanda e quindi fornirti la risposta nel modo più conveniente. La persona che intende nascondere le informazioni farà domande aggiuntive solo per allontanare la conversazione e non risponderà mai alla tua domanda iniziale.

Un'altra parte dell'abilità di comunicazione è la capacità di sintonizzarsi con l'ascoltatore.

Persone diverse hanno un diverso livello di comprensione degli argomenti, un diverso stile di comunicazione e forse anche un diverso interesse per i dettagli specifici. Alcune persone intelligenti comunicative varierebbero il loro flusso di conversazione a seconda della capacità dell'ascoltatore di capirlo e di preparare la loro risposta per fornire informazioni specifiche. In tale preparazione, possono essere poste alcune domande preliminari per restringere l'interesse dell'ascoltatore. La capacità di “elaborare” le differenze comunicative è davvero una grande abilità, in quanto ci permette di raggiungere la comprensione in quasi tutti i casi. I parlanti flessibili, d'altra parte, a volte possono semplicemente essere bloccati in vicoli ciechi irrisolvibili di incomprensioni.

Capire i punti di forza e di debolezza

Concentriamoci su un'altra qualità personale essenziale per un giocatore di squadra.

La maggior parte delle persone sarebbe d'accordo sul fatto che un ambiente di squadra dovrebbe essere più amichevole rispetto alla media del mondo circostante per favorire la collaborazione e aumentare la produttività. Pertanto, è importante che un team comprenda le aree di forza e di debolezza di ciascun membro per distribuire correttamente i compiti e coprire i punti deboli con i punti di forza. Il primo passo in questo percorso è che tutti i membri misurino onestamente le proprie abilità l'una contro l'altra. Psicologicamente, questo può essere difficile poiché tendiamo naturalmente a nascondere i nostri punti deboli agli altri, proteggendoci.

È qui che l'atmosfera amichevole della squadra viene in aiuto.

Quindi il nuovo membro dovrebbe giocare secondo le regole della squadra. Sfortunatamente, alcune persone non possono abbassare la guardia nemmeno in un ambiente amichevole. Si comportano come lupi solitari per tutta la loro vita. Questo è più forte di loro. Purtroppo, tale atteggiamento non contribuisce agli sforzi di squadra.

C'è una tecnica facile per riconoscere tali lupi solitari nell'intervista. Non ammettono mai di non sapere qualcosa. Naturalmente, alle persone piace mostrare il meglio di sé, mostrando tutte le proprie capacità e cercando di risolvere ogni singolo problema difficile. Tuttavia, c'è un limite di conoscenza per tutti. I nostri limiti modellano le nostre capacità. Non ammettere limiti significa che i candidati si presentano come un tuttofare, ugualmente bravo in tutto e in niente.

Quando assumi uno specialista, probabilmente vorresti evitare queste persone. Inoltre, quell'atteggiamento arrogante è spesso accompagnato da un altro tratto distintivo: la riluttanza a chiedere aiuto. La capacità di chiedere aiuto è assolutamente essenziale per il lavoro di squadra. Senza di essa, non possiamo progredire e svilupparci così rapidamente. Una persona così testarda brucerebbe risorse e tempo dell'azienda, combattendo indefinitamente compiti difficili ma senza mai chiedere aiuto ai compagni di squadra. C'è un trucco facile per rilevare tali candidati al colloquio. Fai loro una domanda che non ha senso o menziona qualche termine senza senso. Una persona normale, idealmente curiosa, direbbe semplicemente che non lo sa e chiederebbe di cosa si tratta. Una persona difensiva non lo farebbe mai, anche se si sottolinea che non esiste una risposta giusta o sbagliata e che “non lo so” non la squalifica.

Regola n. 8: Focus sull'organizzazione del lavoro di squadra

Ci sono poche informazioni sull'organizzazione del lavoro di squadra come su qualsiasi argomento precedente sopra. Tutti sanno che il lavoro di squadra è migliore, ma come costruire e mantenere una squadra rimane un mistero. Tuttavia, anche se è impossibile coprire tutti gli aspetti del team building, possiamo almeno esplorare alcune tecniche chiave di team building qui.

Competenza edilizia

Ogni progetto IT è unico. Per avere successo in esso, è necessario imparare e padroneggiare le specifiche del progetto. Possono includere conoscenze sia tecniche che non tecniche. Un esempio di conoscenza non tecnica potrebbe essere una rete personale per la gestione, i clienti, i team di supporto tecnico, ecc. Le conoscenze tecniche speciali sono dettagli aggiuntivi oltre alle competenze informatiche generali.

Ad esempio, potresti aver bisogno di conoscere Maven per costruire un progetto. Tuttavia, l'esatta struttura di costruzione, la posizione delle proprietà e il filtro varieranno comunque in base al progetto. Come con qualsiasi tipo di conoscenza, padroneggiare tali dettagli richiede tempo; più tempo ci si investe, migliori saranno le prestazioni. Il tempo è la risorsa più preziosa che hai. Vuoi mantenere il tuo membro del team concentrato sulla stessa area funzionale il più a lungo possibile per capitalizzare le loro competenze e svilupparle ancora di più, migliorando così costantemente le prestazioni del team.

Sfortunatamente, non è possibile farlo a tempo indeterminato. Da un lato, le persone potrebbero semplicemente annoiarsi. Dall'altro lato, corri il rischio di perdere la loro esperienza, mettendo inaspettatamente a rischio il tuo progetto.

Vediamo se ci sono modi per affrontare i lati negativi senza ostacolare molto le prestazioni della squadra.

Distribuisci le aree di interesse tra i membri del team e consenti loro di sviluppare la loro esperienza al riguardo. Ad un certo punto, raggiungono un livello sufficientemente alto che ha senso nell'ambito di questo progetto. Lo sforzo di apprendimento extra non lo migliorerà in modo significativo a questo punto. Senza motivazione e sfida, le persone intelligenti si annoiano e iniziano a odiare il proprio lavoro.

Previeni ciò aprendo loro possibilità di apprendimento altrove. Tienili informati sui progetti e sullo stack tecnologico dell'azienda e apri nuove sfide. Se il loro interesse rientra nell'ambito del progetto, ottieni la doppia ricompensa di mettere alla prova il tuo team e allo stesso tempo estendere le competenze del team utili. However, any self development is good to avoid boredom, even if it doesn't intersect with immediate project needs. As long as the team expert brains are engaged, they keep supporting already-learned project areas in the back of their minds.

When leaving the company, team experts take a big portion of expertise with them. One of the countermeasures you can use is to widely disseminate documentation that can be updated on the fly. Think of the “persistent memory storage” mentioned earlier.

Still, a project manager would love to duplicate knowledge in team member heads if possible. Having two of every expert would be a simple solution for that, albeit twice as expensive. But there is a leaner way to do it. The trick is to let most of your developers develop expertise in multiple areas, so that each project aspect is covered by at least one deep expert. At the same time, chose a few senior members to grow the breadth along with the depth of their expertise. Usually, this role is best played by a team development lead or an architect. The team lead interacts with all team members and participates in all task implementations. They can tap into each and every aspect of the project, understanding all of its internals. This way, even if you lose one of the experts, the leader can take over and keep on the project progressing until you can hire and train the replacement.

Another flavor of same idea is to cross-train developers in adjacent areas, letting them to observe, learn, and occasionally try their peers' work. Keep in mind that this cross-training needn't be extensive, so it doesn't disrupt focus on developers' primary tasks and doesn't impede productivity. Developing expertise across leadership and cross-training developers builds you a cushion of protection against unforeseen life culprits and allow you some time to maneuver with project resources.

Minimizing Distraction

Software development is a chain of complex and creative problem solving. Even though, with industry development, these complex problems get more and more automated, the work doesn't become easier. It still involves a large amount of art and individual insight, which is very hard to predict and sometimes even harder to wrangle.

Developers are the edge of the weapon. Their concentration is equivalent to the hardness of the weapon's tip. Increase their focus and you'll cut through problems like a hot knife through butter. Distract them and you'll end up clumsily poking at the butter with a blunted stick.

This cannot be over emphasized: Non-problem-solving work can be intensified with motivation or extra effort. For problem solving work, you need maximum detachment from the mundane world. It is difficult to leave all everyday problems behind, and a good project manager should build a quiet development environment in both the physical and mental senses. A developer's workplace should be analogous to a sensory deprivation tank.

Physically, this is implemented as a closed work space. Every team member should have a cube at least where they can dive into solitude. It is preferable to avoid loud noises and aisle conversations. Quick interpersonal communications should be maintained by emails and chats. Large groups should use closed rooms for their meetings to not distract others. This is a pretty standard picture for office life as it used to be.

Unfortunately, the open space paradigm is being adopted more and more widely even in large offices. I would warn against his fad. Even worse, together with open spaces, top management encourages in-place team conversations. That is, in essence, shouting to a person in another row over an uninvolved team member's head. A developer that is interrupted by loud conversation twenty times a day won't have a shred of concentration left. Certainly a major performance killer.

Allowing for a Learning Curve

Knowledge itself is power. This is especially true for such a complex industry as IT. Every task here has its regular cycle: learn, research, implement. The learning phase in particular is invaluable. Not only does better understanding allow better and faster implementation, there are certain knowledge thresholds that must be passed in order to achieve something at all. Of course, there is no point in over-learning either. Each skill should match the production need and not much above it.

However, often, developers are pressured in the opposite direction; to stop learning and to do nothing but produce. Learning is perceived as wasted effort, as it doesn't move the task progress bar. This seems like a really easy problem to solve, sitting at home and reading this article. Yet in the real life, the slightest work pressure turns every manager into that demanding idiot who insists that everybody “stop learning and start doing something already.” I swear, I have heard those exact words so many times throughout my career… A good manager and team leader should understand that learning is an important part of the process even if it doesn't directly increment the progress bar.

Building a Competitive Development Workshop

The tips and tricks presented above are a subset of effective software production expertise. By understanding and applying them in real life, you'll improve your production effectiveness little by little. If you think they are largely unconnected and lacking a theoretical base, you are absolutely right.

I would like to highlight that building a competitive development workshop is not a single-discipline task. It requires knowledge and expertise in multiple adjacent areas. Building such expertise is a hard work. There is no single theoretical base or idea that would solve all your problems at once. Believing in such a silver bullet just serves to distract you from the real goal.

Try out these tips at work to see if they are worth adopting permanently. If you find them useful (or not), leave a comment below and share your experience!