Come lavorare in remoto ed essere ancora il migliore

La cintura degli attrezzi del telelavoratore

Iniziare un nuovo lavoro da remoto o da casa, che si tratti di un contratto o di un lavoro a tempo pieno, può essere un po' intimidatorio se sei abituato ad andare in ufficio giorno dopo giorno.

Ma questo stile di lavoro sta diventando sempre più popolare, con alcune aziende molto importanti che gli hanno prestato la loro approvazione.

Ho lavorato con successo da remoto utilizzando questi strumenti ormai da anni su progetti di varie scale e durate. Con questo post, spero di enumerare alcune delle migliori pratiche che ho raccolto per lavorare in una varietà di situazioni. La guida a distanza e lavoro da casa qui va da consigli specifici per software e hardware, a suggerimenti per rispettare le scadenze del tuo team.

L'impostazione del telecomando o dell'ufficio domestico

Non posso sottolineare abbastanza l'importanza di avere la giusta configurazione dell'ufficio. Ti renderà più produttivo e sembrerà più professionale. Ad esempio, un auricolare è fondamentale per evitare l'eco durante le chiamate online; piccole cose come questa fanno molto quando si lavora come telecomando.

Ecco alcuni strumenti per lavorare in remoto che ritengo essenziali all'interno del mio ufficio di casa:

• Auricolare . Mi piacciono molto le cuffie cablate in particolare perché non esauriscono la batteria nei momenti critici. Lo indosserai molto, quindi assicurati di avere qualcosa di comodo. Ho due cuffie iMicro: una per la mia scrivania e una che ripongo nella borsa del laptop. Come auricolare per borsa per laptop, ha due grandi qualità: poiché è alimentato tramite USB, non devo preoccuparmi di mantenere le batterie cariche ed è molto economico sostituirlo se si rompe nella mia borsa. In realtà, trovo questo particolare auricolare un po' scomodo per lunghe chiamate in conferenza; se ne stai facendo molti, ti consiglio il Corsair Vengeance 2000: un comodo auricolare wireless con capacità di batteria, che ti consente di lavorare tutto il giorno. (A proposito: nessuno di questi sono link di riferimento.)
• Posto tranquillo per pensare , con una porta che si chiude, soprattutto se vivi con altre persone e soprattutto se hai una famiglia.
• Connessione Internet stabile o buona connessione di backup. Ad esempio, ho una DSL e ho impostato il tethering sul mio telefono se la DSL si interrompe. Se hai costantemente problemi con Skype o interrompi le chiamate, stai diventando meno affidabile e meno professionale agli occhi degli altri che potrebbero provare a gestire diversi dipendenti remoti.
• Skype . Questo è utile per chiamate in conferenza ad hoc, messaggistica istantanea con i clienti o persino per la creazione di chat room a bassa cerimonia.
• SkypeOut , che ti consente di ricevere ed effettuare chiamate dal tuo telefono ai contatti Skype. Questo è fantastico, specialmente per i momenti in cui sei lontano dal tuo computer e (hai calcolato male un orario, il cliente ha un'emergenza, ecc.).
• Bollitore elettrico . A volte voglio un caffè caldo ma non voglio disturbare il mio flusso per prenderne un po'.
• Brocca d'acqua da galloni . Per il bollitore o per bere. Per lunghe sessioni di codifica o lunghe chiamate in conferenza.

Alcuni di questi sembrano ovvi, ma saresti sorpreso dal numero di telecomandi che non colpiscono tutti i segni qui. Come sviluppatori, abbiamo bisogno di uno spazio tranquillo per pensare, senza interruzioni. E come lavoratori remoti, abbiamo bisogno di un luogo tranquillo per ospitare chiamate in conferenza, riunioni, sessioni di programmazione di coppia, ecc., senza interruzioni. Il solo lavoro sul divano probabilmente non è una buona soluzione di lavoro a distanza a lungo termine.

Strumenti software

Ci sono un sacco di buoni strumenti software là fuori per integrare il tuo tipico ambiente di sviluppo e aiutarti a superare le sfide associate al lavoro a distanza. Eccone alcuni che mi piacciono molto:

• AwayFind , utile per le e-mail urgenti, in particolare i messaggi dell'ultimo minuto da parte di un partecipante a una riunione, poiché ti inoltra i messaggi tramite SMS.
• Time Zone Converter , per lavorare con clienti e colleghi in tutto il mondo. Mi piacciono l'orologio dell'ora mondiale di Time And Date, Every Time Zone, World Time Buddy o The Time Now per una versione più accessibile per i non vedenti.
• Stanze chat/IRC per tutti i membri del team. Questo potrebbe essere formale (ad esempio, una stanza del fuoco) o semplicemente una chat room di Skype (in Keep It Simple, Silly).
• Bug tracker : questo merita una sezione a parte, quindi vedi sotto.

Qualche anno fa facevo parte di un team Rails di dimensioni decenti. Diversi membri del team hanno lavorato in remoto per almeno una parte del tempo e la cultura del team prevedeva che molto lavoro sarebbe stato svolto la sera. Ho proposto di creare una chat room tramite il team leader ufficiale dell'epoca, indicando Campfire o qualche altro servizio di chat a pagamento. Sono trascorse diverse settimane senza alcuna azione e ho deciso di creare una chat room Skype solo con gli sviluppatori, per testare la mia teoria secondo cui una chat room sarebbe stata una risorsa per il team. Questo esperimento ha avuto molto successo, così tanto che abbiamo continuato a utilizzare la chat di Skype invece di un'altra soluzione. Questa chat room di Skype era ancora in uso quando ho lasciato il progetto quasi un anno dopo. A volte, semplice può essere l'opzione migliore.

Successivamente, durante una scadenza critica per lo stesso progetto, abbiamo creato una chat room su Skype che includeva gli sviluppatori, gli analisti aziendali, i project manager e il cliente, in modo che le domande potessero essere affrontate rapidamente dal gruppo generale. Sebbene non sia attivo come la chat room per soli sviluppatori, ha comunque funzionato molto bene. Le chat di Skype possono essere moderate e controllate da alcuni comandi di chat di gruppo, impostando i ruoli della chat e impostando le autorizzazioni di accesso, il che ti consente di personalizzare davvero la chat in base al tuo caso d'uso. Anche una configurazione di tale semplicità può migliorare la produttività remota.

Best practice per il lavoro a distanza: monitoraggio dei bug

Mi piace sapere tre cose da un bug tracker che sto usando:

• A cosa sto lavorando in questo momento?
• Cosa c'è nel mio piatto per la prossima versione di questo software?
• Quali sono i risultati finali dell'intero team per questa versione del software?

Ognuno di questi ha uno scopo.

Primo, "A cosa sto lavorando in questo momento?": Quando lavori in un ufficio tradizionale, hai chiacchiere in background: questo ti dà un'idea generale di cosa stanno facendo tutti gli altri. Un indicatore esplicito nel sistema di localizzazione dei bug che afferma: "Sì, ci sto lavorando attivamente in questo momento", può introdurre uno schema e una sensazione simili al lavoro a distanza.

In secondo luogo, "Cosa c'è nel mio piatto per la prossima versione?" significa "Di quali bug sono responsabile" o "Di quali bug sto gestendo". C'è sicuramente un po' di avanti e indietro in ogni team, ma è anche bene sapere a chi chiedere se vuoi prendere un bug o hai bisogno di aiuto per finalizzare i tuoi bug per il rilascio.

È anche possibile che il tuo team non funzioni affatto in questo modo: ad esempio, il tuo flusso di lavoro potrebbe essere in cui a ogni sviluppatore viene assegnato un solo bug con cui iniziare e preleva la pila non assegnata quando il loro bug è terminato. Anche questo può essere produttivo.

La "prossima versione del software" non deve essere nulla di importante: ho fatto parte di team in cui la "prossima versione" significava "tra 3 giorni, rilasceremo una nuova build alpha per il client ”. Ma è comunque positivo per tutti sapere cosa accadrà in questa nuova versione. Soprattutto se ritiri i biglietti non assegnati quando il tuo attuale biglietto è completo.

Ho incluso alcuni consigli per specifici bug tracker in fondo al post.

Best practice per il lavoro a distanza: comunicazione di gruppo

Per alcuni, la comunicazione di gruppo è la parte più intimidatoria del lavoro da remoto o da casa. Ma questo sarà un problema solo se lo lasci fare .

In un ufficio, mentre passeggi accanto a tutti sulla strada per il tuo posto, c'è un po' di battute, la gente dice "Ciao". I tuoi colleghi sanno che sei al lavoro perché ti vedono, laggiù, alla tua scrivania, al lavoro.

I telelavoratori devono essere leggermente più espliciti : nessuno sa che stai lavorando a meno che tu non glielo dica . Ma se stabilisci le giuste pratiche di comunicazione, i tuoi colleghi saranno disponibili premendo un pulsante, piuttosto che una passeggiata attraverso l'ufficio, giù per l'ascensore, ecc.

Questi suggerimenti si applicano maggiormente a un dipendente gestito in remoto come parte di un team più grande, ma possono essere utili se sei solo tu come unico sviluppatore.

Far sentire la tua presenza: non diventare invisibile

Ho raccolto molte di queste idee dall'episodio 48 del podcast di Wide Teams.

All'inizio della giornata, vai su IRC (o qualsiasi strumento utilizzato dal tuo team) e dì "Ciao" , parla di come stanno andando le giornate delle persone, ecc., ecc. Anche se ciò significa salire su IRC e chiedere di bambini, fine settimana, squadre sportive o hacking nel fine settimana. Quando le persone sanno che al momento lavori a casa, non diventi invisibile. Costruisci una relazione e fai sapere alle persone che ci sei .

Chatta con le persone in chat e assicurati di rimanere coinvolto con i tuoi colleghi. Questo è diverso rispetto a quando incontri persone nella sala caffè, ecc. Ecc. Devi contattare esplicitamente e rimanere in contatto in modo che quando esegui il commit del codice o hai bisogno di assistenza, le persone siano pronte.

Messaggi "Giorno di inizio", "Ora di pranzo" e "Torna".

Oltre a far sentire la tua presenza, dovresti anche far sapere ai tuoi compagni di squadra remoti quando non lavori. Proprio come in un ufficio tradizionale, non vuoi sparire per il resto della giornata e lasciare i tuoi colleghi in sospeso.

Se fai parte di un team con un certo numero di altri sviluppatori o gestisci dipendenti remoti, ha senso effettuare il check-in quando inizi la tua giornata lavorativa. Un semplice “Buongiorno a tutti” per far sapere alle persone che sei alla tua scrivania pronto per iniziare a lavorare al progetto, e non più a casa oa letto.

Anche l'invio di messaggi "Torna tra 1 ora" per il pranzo o le pause di lavoro durante il giorno è bello. Il lavoro a distanza è ottimo per molte cose, ma uno scenario preoccupante è che tu faccia una domanda al tuo collega e non ricevi risposta. Non rispondono perché sono via per 30 minuti? O perché sono nel profondo della zona e non ascoltano la chat? Forse in una riunione? I messaggi "Torna dentro..." possono alleviare queste preoccupazioni e snellire il flusso di lavoro.

Quando hai finito per il pomeriggio, fai sapere alle persone quando tornerai. Forse è "Ci vediamo domattina" o "Torna più tardi questa sera per finire [x]". Ma come i messaggi "Torna tra 1 ora", stabiliscono una certa aspettativa a cui la tua squadra può adattarsi.

C'è un'interessante startup chiamata Sqwiggle che potrebbe risolvere alcuni di questi problemi (anche se non l'ho ancora provato da solo). Oltre a scattare una foto di te ogni pochi secondi, consente anche ai membri del team di fare clic sulla tua foto per avviare la chat video/audio, oltre a fornire un componente di chat di testo. L'idea alla base dell'immagine è di vedere, a colpo d'occhio, se sei davanti al tuo computer o meno. (Non c'è niente di peggio che provare a chattare con qualcuno online e non rispondere rapidamente. Sono stati raggiunti da qualcos'altro? Nelle profondità della zona? Non vedi la notifica della chat? In bagno proprio ora?). Ho sentito parlare di Sqwiggle nell'episodio 83 del podcast di Wide Teams.

Sui progetti in cui è possibile impostare le migliori pratiche

I concerti di freelance a distanza sono sempre diversi. (Questo fa parte dell'appello!) A volte vieni coinvolto in un team esistente di sviluppatori puramente come potenziamento del personale. Forse questa squadra sta insieme da tempo e, in quel caso, ha già stabilito pratiche di comunicazione.

D'altra parte, a volte sei l'unico sviluppatore del progetto, a lavorare con un cliente non tecnico. Puoi impostare le tue migliori pratiche di sviluppo software e avere un certo controllo su come eseguire l'operazione. Di seguito sono riportate alcune best practice della mia decennale esperienza di lavoro a distanza. Per lo più, questi sono destinati a programmi di mezza settimana (20 ore/settimana) o di una settimana intera (40 ore/settimana).

Riunioni in piedi

C'è qualcosa da dire sullo svolgimento di riunioni in piedi per parlare dello stato del progetto. Questi sono molto comuni negli uffici tradizionali, ma non c'è motivo per cui non possano essere produttivi per il team remoto: sono solo un altro modo per rafforzare la comunicazione tra le due parti: cliente e sviluppatore.

Un tradizionale incontro in piedi chiede a cosa stavi lavorando ieri, su cosa lavorerai oggi e se ci sono ostacoli sulla tua strada. Questo formato può funzionare o meno date le dimensioni del tuo team: se si tratta di un progetto di un singolo sviluppatore, queste domande non hanno senso.

La frequenza con cui dovresti tenere una riunione in piedi dipende in realtà dalle dimensioni e dalla cultura del team. Comunque ecco i miei consigli:

• 1-3 sviluppatori: 2 riunioni in stile standup a settimana
• 4+ sviluppatori: riunioni quotidiane in piedi

Con 1-3 sviluppatori, queste domande sono per lo più ovvie: sai cosa sta facendo ogni sviluppatore perché è facile tenere traccia del proprio lavoro individuale mentre esaminano i ticket: tutti sanno cosa stanno facendo tutti, perché non ci sono molte persone che fanno lavoro.

Con team remoti più grandi, ci sono più parti in movimento: vuoi assicurarti che nessuno calpesti i piedi virtuali di nessuno replicando il lavoro o apportando modifiche incompatibili.

I team remoti avanzati possono disporre di altri metodi per mantenere tutte le parti interessate sulla stessa pagina senza programmare una riunione effettiva mentre lavorano da casa. Mi piace ancora parlare al telefono/Skype/Hangout con qualcuno e avere una riunione in quel modo.

Per i piccoli team, due riunioni stand-up alla settimana funzionano molto bene: le correzioni del corso vengono apportate rapidamente, ma gli sviluppatori hanno ancora qualcosa di sostanziale da segnalare durante ogni riunione.

Consegnare la prossima versione da remoto

A seconda delle dimensioni del progetto, mi piacciono i deliverable inviati al cliente settimanalmente per progetti piccoli (1-2 sviluppatori) e bisettimanali per progetti più grandi (3+ sviluppatori). Questo ritmo offre agli sviluppatori abbastanza tempo per completare porzioni di lavoro considerevoli, inclusa un'interfaccia (o un'esperienza utente migliorata) che il client può vedere.

È importante che gli sviluppatori ricordino, specialmente con client non tecnici, che i progressi che puoi visualizzare con un'interfaccia utente sono spesso l'unica cosa che conta per il client. Ai clienti non tecnici non importa che tu abbia distribuito 500 righe di codice questa settimana o che tu abbia avuto difficoltà a interagire con qualche servizio web; l'unico parametro in base al quale possono misurare i progressi è quello che possono vedere sullo schermo . Questo non vuol dire che fare un buon lavoro sul back-end sia irrilevante, ma piuttosto che devi rendere tutto questo buon lavoro tangibile agli occhi del cliente.

Ecco perché mi piacciono i risultati settimanali o bisettimanali. Qualsiasi cosa più breve di quella spesso mette in difficoltà lo sviluppatore: forse rimangono bloccati a fare il lavoro di back-end per due giorni e non hanno il tempo di finire l'interfaccia, quindi non hanno nulla da mostrare al client.

A seconda del tipo di progetto software, non tutte queste versioni client verranno rilasciate al pubblico. Ad esempio, se stai lavorando a un progetto Rails, potresti voler distribuire immediatamente le modifiche approvate; d'altra parte, con un'app mobile, puoi chiamare una versione "1.3a10", ma la versione corrente è solo una parte del set di funzionalità più ampio di una nuova versione 1.3 del software che verrà implementata in seguito.

È qui che entrano in gioco le migliori pratiche del tracker di bug remoto. Con il monitoraggio dei bug, il cliente sa:

1. Cosa c'è nel piatto della squadra per questo risultato
2. Se è stato completato
3. Se il lavoro è stato approvato dal cliente.

Il cliente sa cosa aspettarsi da questa versione e gli sviluppatori sanno quale lavoro li attende.

Se il tuo team remoto è abbastanza maturo per utilizzare la distribuzione continua e/o Kanban, allora va bene. Tuttavia, queste sono entrambe tecniche molto avanzate che sono più adatte alle organizzazioni con una forte cultura basata sugli sviluppatori. La maggior parte delle organizzazioni, in cui lo sviluppo di software personalizzato è considerato necessario ma costoso, probabilmente non è pronta per nessuna di queste tecniche. Perché? Due cose che ho visto sono che il client non riesce a tenere il passo con il numero di modifiche che gli sviluppatori vogliono che esaminino , o le priorità cambiano troppo rapidamente perché lo sviluppo possa fare qualsiasi cosa .

Raccomandazioni

Se ti capita di entrare in un team in cui stabilirai le migliori pratiche, ho elencato di seguito alcuni strumenti per la gestione del tuo lavoro a distanza. Tieni presente che questi sono solo i miei consigli: di certo, questa guida non è per tutti; e se non ti piacciono questi strumenti, probabilmente c'è uno strumento che si adatta meglio alle tue esigenze.

• Planscope.io , in modalità settimanale. Questo è uno strumento di monitoraggio del tempo + bug tracker + stima del progetto che invia quotidianamente ai clienti e-mail quando si lavora al loro progetto e consente loro di vedere come stanno andando le cose in termini di avanzamento e budget. Questo è ottimo per progetti di dimensioni da 1 a 4 sviluppatori/mesi.
• App Trajectory è un bug tracker per piccoli team con particolare attenzione alla stima e alla suddivisione del progetto in blocchi da una a due settimane (iterazioni). App Trajectory può dirti quanto lavoro stai completando in un'iterazione e quante iterazioni fino al completamento di tutto il lavoro noto. Questo è ottimo per progetti di dimensioni da 2 a 12 sviluppatori/mesi.
• Pivotal Tracker è uno strumento di monitoraggio dei bug per i clienti con particolare attenzione alle metodologie Agile. Questo è ottimo se stai eseguendo iterazioni Agile formali o hai una dimensione del progetto misurata in sviluppatore/anni.
• FlowDock per la chat. Flowdock offre alcuni vantaggi rispetto alla semplice chat IRC o Skype: oltre all'integrazione con i servizi più diffusi, ti consente anche di taggare le conversazioni per un rapido riferimento in seguito. FlowDock mantiene anche un elenco di attività di stato (check-in del codice, ecc.) Che sono separate dalle chat generali. (Ad esempio, nell'interfaccia web, gli aggiornamenti automatici dello stato sono a sinistra, mentre le chat sono a destra.)
• Ancora una volta, Campfire è ottimo anche per la chat.

Conclusione

Iniziare con il lavoro a distanza o da casa può essere un bel cambiamento, sia per te che per il cliente. L'ho fatto andare molto bene e molto male. Ma, quando va bene, può essere un ottimo modo per i clienti o i datori di lavoro di risolvere il problema del "talent crunch" e creare una gamma più ampia di opportunità per gli sviluppatori che vivono al di fuori dei principali centri tecnologici o hub di "startup". C'è un intero mondo di efficienza da guadagnare dagli sviluppatori che lavorano insieme in remoto con le giuste best practice in atto.