Comunicazione di squadra (conta più dei tuoi strumenti)

Da quando ho assunto un paio di appaltatori, una domanda che gli altri si pongono è:

oCom’è passare dal lavorare sui progetti da solo al lavorare sui progetti con un team?

O, più semplicemente, com’è avere degli appaltatori? La risposta breve è che lo scavo perché offre alcuni vantaggi:

• dobbiamo avere una netta divisione del lavoro,
• l’azienda può assumere più progetti,
• siamo in grado di collaborare alle cose (che è qualcosa che mi manca del volo da solo),
• e altro ancora.

L’altro lato di questo, però, è che sento di dover imparare com’è ricominciare da capo un’impresa.

Come iniziare con una lavagna vuota.

Questo, in nessun modo, è una brutta cosa. È il contrario. Ma quando passi dal lavorare sui progetti da solo allo sviluppo della tua configurazione, si verifica un periodo di adattamento.

Lo sto ancora sperimentando e ci sto lavorando. Richiede sia conversazioni con il tuo team che un po’ di introspezione per determinare se quello che stai facendo è ancora giusto per il tuo modo di lavorare o se dovresti adattarlo.

Comunicazione di squadra

Ovviamente, questo particolare argomento è ampio e io, insieme a molti di voi, potrei parlare di una varietà di cose relative alla gestione di un’impresa.

Ma, per oggi, l’unica cosa di cui voglio parlare è il ruolo in cui la comunicazione del team, non i tuoi strumenti di sviluppo software, gioca nel fornire soluzioni agli altri.

I tuoi strumenti contano (ma non così tanto)

Ad esempio, ho lavorato in un posto dove ti portano una macchina con un particolare set di strumenti e dicono "Questo è ciò che usiamo per costruire i nostri progetti".

Certo, richiede che tu lo impari, ma a una parte di me è piaciuto perché rimuove il mal di testa che deriva dal capire cosa usare. Mi ha anche impedito di dover prendere quelle decisioni da solo.

D’altra parte, ha anche reso più difficile l’introduzione di un nuovo strumento perché avrebbe interrotto il flusso di lavoro di un intero reparto. Quando sei una piccola squadra, però, è un po’ più facile adattarsi.

Visual Studio Code è diventato il mio IDE preferito.

Innanzitutto, quando lavori per te stesso, probabilmente hai il tuo preferito:

• VA
• sistema di controllo del codice sorgente,
• costruire strumenti,
• strumenti di distribuzione,
• ambiente di accoglienza,
• e così via.

Quando metti gli altri nel mix, però, stai portando le stesse cose esatte tranne che è alle loro condizioni. Ora hai il compito di determinare se dovresti rimanere con ciò che hai, valutare ciò che hanno, fargli adottare i tuoi strumenti, adottare i loro strumenti, combinare i due o ricominciare da capo.

Questo non è un modo banale soprattutto quando si lavora insieme per risolvere una soluzione per un cliente. Potrei scrivere molto di più su questo. E non fraintendetemi: penso che sia un argomento che dovrebbe essere discusso ed è qualcosa che ritengo importante.

Ma c’è qualcosa che sta al di sopra di tutto questo che non dovrebbe mai essere sottovalutato, ed è il processo di comunicazione del team.

La comunicazione è importante (e di più)

Non sto parlando di assicurarmi di controllare gli stati d’animo delle persone ogni giorno (anche se questo è importante), e non sto parlando di chattare in SMS o Slack o IRC solo per il gusto di farlo in modo che tu ti senta produttivo.

La comunicazione di squadra è più di Slack.

Sto parlando di requisiti di comunicazione completa.

Caso in questione: supponiamo che sto parlando con un cliente, accetto un contratto e poi sono pronto per andare avanti. So cosa vogliono, i progetti esistenti e come dovrebbe funzionare qualcosa. Poi porto un compagno di squadra e dico "Ehi, iniziamo".

Il problema qui è chiaro, giusto? Non ha idea di cosa stiamo cercando.

E non importa quanto descrivi i passaggi nel tuo strumento di gestione dei progetti o parli di come dovrebbe funzionare qualcosa.

Inoltre, puoi avere la configurazione degli strumenti più elegante ed efficiente possibile, ma se il tuo team non è chiaro sui requisiti del progetto, non importa.

Quando decidi di assumere qualcuno che ti aiuti con i progetti e quando decidi di iniziare a collaborare alla soluzione, organizza la discussione sugli strumenti e sui requisiti della prima discussione.

Questo non può essere sottovalutato.

Se conosci i requisiti e il tuo compagno di squadra no, o se i requisiti non sono chiaramente comunicati per un motivo o per l’altro, la soluzione adeguata non verrà fornita. E questo è ovviamente costoso.

Inoltre, se finisci per pensare di avere le stesse idee in mente e finisci per implementare qualcosa di completamente diverso, allora hai un’altra serie di problemi con cui affrontare.

Per quanto riguarda la mia attività, mi occupo principalmente di sviluppare relazioni con le persone con cui lavoro sia nel mio team che con le quali ci assume.

Ma se le discussioni interne sulle soluzioni su cui stiamo lavorando non sono sulla stessa pagina, nient’altro conta: non i tuoi strumenti, non ciò che spedisci, non la velocità con cui lo spedisci e non se viene semplicemente fatto.

E c’è dell’altro

Quindi, in un prossimo post, condividerò alcune idee dalle esperienze personali finora – sia errori che vittorie – nella speranza che tu sia in grado di evitare qualunque cosa potresti dover affrontare quando scegli di far crescere la tua squadra.

Non fraintendetemi: è una cosa fantastica da fare (e mi piace), ma richiede aggiustamenti su livelli con cui non ero completamente preparato.

Nel frattempo, se hai qualcosa da contribuire a questo post, sentiti libero di farlo nei commenti. Sono sempre ansioso di sapere come i liberi professionisti e coloro che sono anche lavoratori autonomi o che gestiscono team gestiscono questo particolare argomento.