Il lavoratore remoto: una call è meglio di mille parole e mille parole sono meglio di una call.


Una delle cose su cui sento insistere molto è l’asincronicità del lavoro remoto. Si stressa molto sul rendere tutto asincrono.

Ottimo, peccato che non funzioni sempre

La comunicazione asincrona comporta scrivere molto, anzi moltissimo. Scrivere aiuta moltissimo in certi contesti e crea moltissima frizione in altri. Diventa quindi molto importante capire rapidamente quando la comunicazione ha senso che sia asincrona, e quindi scritta, o sincrona e quindi vis-a-vis con una call.

Diciamo che la nostra regola aurea interna è:

  • discussioni e ricerca del consenso funzionano molto bene in maniera sincrona e molto male in maniera asincrona
  • aggiornamenti di stato, passaggi consegne e brainstorming funzionano molto bene in maniera asincrona e sono molto meno efficaci se sincroni

Scrivere ha un vantaggio enorme: obbliga ad attaccare il cervello. Scrivere ci impone di mettere in fila le idee che abbiamo confuse in testa. La sola attività di scrittura porta ordine nel caos e spesso ci porta a rivalutare quello che abbiamo in mente sotto forma di pensiero.

Attività come le discussioni e la ricerca del consenso sono invece tendenzialmente guidate dall’istinto, e istinto e scrittura sono un ossimoro. Risulta quindi molto facile che una discussione scritta degeneri in una litigata per iscritto. Questo perché, sia una discussione che la ricerca del consenso, tendono ad essere attività guidate anche dalle emozioni e la trascrizione delle emozioni è od oggi troppo rozza (si limita pressoché alle sole “faccine”). Il tono della voce e la mimica diventano quindi parte essenziale della comunicazione. La così detta “comunicazione non verbale”.

Il tutto può solo essere accentuato da differenze culturali e linguistiche.

Quindi?

Alleniamo il nostro sesto senso a capire quando è il momento di spostare la comunicazione usando uno strumento diverso. Ad esempio noi partiamo quasi sempre in maniera asincrona e “saltiamo su una call” non appena ci rendiamo conto che il mezzo, Slack nel nostro caso, sta generando più frizione del necessario. Appena questo succede lo strumento cambia e diventa Zoom.

author: Mauro Servienti | posted @ lunedì 27 marzo 2017 11.47 | Feedback (0)

Il lavoratore remoto e la qualità della connettività.


Sembra una cosa scontata, ma non lo è per nulla. Perché il lavoro da remoto possa anche solo essere preso in considerazione la presenza di connettività è un requisito fondamentale. Direi lapalissiano.
Quello che forse è meno scontato è la frustrazione e lo stress elevatissimo che una qualità scadente della connettività può generare, sia da parte del lavoratore che da parte del datore di lavoro.

Banda, velocità nominale e qualità

La velocità della connessione è un fattore che ha un peso limitato sulla qualità complessiva percepita, e di conseguenza su stress e frustrazione. Paradossalmente è meglio una buona, e mediocremente veloce, ADSL rispetto ad una nominalmente veloce connessione WiMax (o tecnologie simili). Questo perché, nella media della giornata lavorativa, conta di più la stabilità della linea rispetto alla velocità di picco.

Mi è capitato di riuscire a fare, con buoni risultati, conference call su una schifosissima ADSL con 3.0Mbit in download e 0.2Mbit in upload e allo stesso tempo di letteralmente impazzire con una presunta blasonata connessione Eolo da 30/10Mbit con banda minima garantita.

Velocità. Upload delle mie brame.

Certo una bella fibra FTTC, se non migliore, vi garantisco che cambia drasticamente la qualità della vita del lavoratore remoto. La banda in upload è poi, in alcuni momenti, un fattore essenziale oltre che una soddisfazione. Vedere l’upload di circa 200Mb metterci meno di 30 secondi è un piccola goduria.

Si, ma perché?

Se non fosse ovvio il motivo è uno ed uno solo: evitare l’isolamento. Non è detto che abbiate bisogno di connettività costante e costantemente di alta qualità, per lavorare da remoto. Ne avete però bisogno per stare in contatto, quando e come volete con i vostri colleghi. L’aspetto forse più importante del lavoro remoto è evitare l’isolamento sociale.

author: Mauro Servienti | posted @ lunedì 20 marzo 2017 9.18 | Feedback (0)

Il lavoratore remoto


Lavoro, da remoto, come Solution Architect per Particular Software da circa 3 anni. In questi tre anni ho, e abbiamo anche come azienda, sperimentato parecchio in ambito “lavoro da remoto”.

Da un annetto a questa parte parlo pubblicamente di come siamo organizzati. Il talk, “The agony and the ecstasy of working remotely (from cogs to Nirvana)” , è focalizzato sulla struttura organizzativa e sul processo evolutivo che l’azienda ha intrapreso.

La nuova categoria “remote working”, di cui questo è il primo post, nasce invece per raccogliere tutta una serie di suggerimenti e accorgimenti (tips & tricks) per me essenziali per rendere efficace, efficiente ma soprattutto divertente la vita del lavoratore remoto. Sia dal punto di vista del lavoratore che del datore di lavoro.

Il primo consiglio? leggete Remote-First vs. Remote-Friendly di Zach Holman.
Il secondo consiglio? rileggetelo.

author: Mauro Servienti | posted @ venerdì 17 marzo 2017 9.30 | Feedback (1)

La complessità è importante. Accettatela.


Una delle regole non scritte dei sistemi distribuiti, in stile Fight Club, è: non distribuire.

Ci devono essere validissimi motivi per scegliere di costruire un sistema distribuito. Come sappiamo, ma forse troppo facilmente dimentichiamo, la soluzione di tutti i mali non esiste. Un’architettura distribuita risolve un sacco di magagne ma inevitabilmente ne porta con se altre, diventa quindi importante valutare bene queste altre per essere sicuri che il gioco valga la candela.

L’altro ieri parlando di Enel scrivevo:

La cosa che più mi fa imbestialire è che un mondo complesso come quello di Enel è forse il mondo in cui sarebbe più semplice risolvere il problema di cui sopra.

In un sistema inevitabilmente complesso come quello di una grande realtà un’architettura distribuita è paradossalmente molto (più) facile da implementare. Il sistema è distribuito per natura dal giorno zero. La complessità è elevatissima. Tutte le magagne introdotte dal distribuire sono ampiamente annullate dai vantaggi.

Abbiamo sempre detto e accettato per buona la stessa cosa quando si parla di Domain Driven Design.

La cosa importante da comprendere, evidenziata molto bene da Weronika ad Amsterdam, è che la complessità esiste sempre. I business sono (quasi) sempre complessi, noi tecnici siamo stati educati con la forza a cercare di renderli semplici con la tecnologia.

Mai errore fu più nefasto. Fuggire la complessità può solo portare a spostare la stessa in un campo di battaglia più ostico: quello tecnologico.

Così per dire…La mail non è ancora arrivata.

--

With Ginger help.

author: Mauro Servienti | posted @ mercoledì 15 marzo 2017 8.45 | Feedback (2)

Ginger


Da qualche giorno sto usando, con soddisfazione, Ginger come tool di supporto per la scrittura. I ragazzi di Ginger mi hanno offerto una licenza full che abilita tutta una serie di funzionalità interessanti.

Di base Ginger è un “correttore” multilingua che oltre ad avere il classico supporto per grammatica e ortografia vi da anche un discreto supporto per la costruzione logica della frase, molto utile quando si ha a che fare in particolare con una lingua straniera.

La cosa che mi piace di più in questo momento è la varietà di strumenti messi a disposizione. Si integra con il browser (Chrome nel mio caso) in due modi:

  • Direttamente in line mentre si scrive nei vari textbox e taxtarea

image

  • Con una semplice estensione che è possibile usare come applicazione per creare bozze

image

Infine è possibile installare un’applicazione stand alone da usare come vero e proprio editor di testo. Non male.

Mi sembra anche di poter dire, in maniera molto empirica e poco scientifica, che è decisamente poco esoso in termini di risorse.

author: Mauro Servienti | posted @ martedì 14 marzo 2017 9.57 | Feedback (0)

Tutto è una macchina a stati: la tecnologia al servizio dell’utente.


In questi ultimi giorni ho, volente o nolente, parecchio a che fare con Enel. L’esperienza utente con i sistemi Enel spazia dal piuttosto pietoso al disastroso.

Lasciatemi usare l’ultima cosa che mi è appena successa come spunto per una riflessione:

  • alle 17.50 mi arriva un SMS che mi informa di controllare la mail
  • secondo loro dovrei cliccare sul link presente nella mail per completare la procedura di attivazione della bolletta online
  • alle 18.43 la mail non è ancora arrivata

E uno si chiede: come credi si possa sentire un non informatico in questa situazione? Come minimo brancola nel buio. Tra un’oretta comincia a chiedersi dove ha sbagliato; infine domani mattina chiamerà il servizio clienti.

Ovvio che è sbagliato

Lo sottolineo giusto così per precauzione, un approccio come il seguente è sbagliato, ripetete con me sba | glià | to.

using( var tx = new TransactionScope() )
{
   UpdateCustomerStatus(123, true);
   SendMail(MailType.OnlinePaymentActivation);
   SendSMS(SMSType.OnlinePaymentActivation);
}

La cosa che più mi fa imbestialire è che un mondo complesso come quello di Enel è forse il mondo in cui sarebbe più semplice risolvere il problema di cui sopra.

Un errore terribile

In sistemi complessi le parti sono tante, le applicazioni ancora di più i servizi di appoggio non si smette mai di censirli. In sistemi complessi la comunicazione non può essere sincrona e lo snippet usato come esempio nasconde un errore terribile.

Nasconde la convinzione che farsi un bus fatto in casa ricada sotto il vecchio adagio: ma si, che ci vuole.

Quel codice esprime un intento che dovrebbe essere:

using( var tx = new TransactionScope() )
{
   UpdateCustomerStatus(123, true);
   QueueSendMail(MailType.OnlinePaymentActivation);
   QueueSendSMS(SMSType.OnlinePaymentActivation);
}

Nel qual caso diventerebbe ovvio che accodare l’invio dell’SMS è pericoloso perché se il servizio di invio mail è giù generiamo immediatamente il pastrocchio di cui sopra.

Tutta la nostra vita è una macchina a stati

Quindi perché fare tutti questi sforzi per negarlo? Non sarebbe molto più semplice prendere atto della cosa e progettare il software con questa innegabile verità come linea guida?

  1. Aggiorno lo stato del cliente
  2. Pubblico un evento significativo
  3. Reagisco all’evento e invio la mail relativa
    1. Attendo conferma che la mail sia sul server di posta del destinatario*
  4. Pubblico un evento significativo
  5. invio l’SMS

Sono le 19.11 e della mail ancora nessuna traccia.

* che è quello che fa Amazon, non è al 100% affidabile ma abbatte il numero di casistiche di inconsistenza, e di conseguenza il numero di chiamate al servizio clienti.

author: Mauro Servienti | posted @ lunedì 13 marzo 2017 19.12 | Feedback (0)

Make an impact.


Rendete straordinaria la vostra vita

https://youtu.be/L7maQfH0lMs

author: Mauro Servienti | posted @ venerdì 10 marzo 2017 17.33 | Feedback (0)

Commit o no delle dipendenze?


Quando ci siamo chiesti a chi conviene/interessa seguire SemVer abbiamo usato questo screenshot:

image

E abbiamo anche detto:

Nel caso specifico Alessandro si riferisce ad un problema leggermente diverso legato alla gestione delle dipendenze, lo affronteremo.

Gli sviluppatori .NET sono abituati a Nuget e a non committare le dipendenze, il motivo è abbastanza semplice: il comportamento del package restore è predicibile. Se nel mio packages.config locale c’è una versione della dipendenza il package restore ripristinerà quella versione anche se ne esiste una superiore.

La predicibilità è fondamentale, altrimenti rischiate che su due macchine due package restore distinti producano due risultati diversi. Cosa inaccettabile.

Cosa che si verifica tranquillamente con i package manager per Javascript in cui potete specificare che le versioni delle vostre dipendenze sono fluttuanti. In questo caso avete due scelte:

  1. Come dice Alessandro non lo fate, ma semplicemente mettete una versione fissa. Fine dei giuochi.
  2. Fate commit delle dipendenze e quindi il package manager trovandosele già in locale quelle usa.

1 tutta la vita :-) Ovviamente non sottolineo il dettaglio che in ogni caso package restore ha bisogno di connettività. Cosa in alcune zone del mondo rara e preziosa.

In questa breve, e conclusa, serie:

author: Mauro Servienti | posted @ mercoledì 8 marzo 2017 8.15 | Feedback (0)

Una chiacchierata introduttiva a GraphQL @CodemotionIT


Siete curiosi di scoprire cosa sia GraphQL e perché sia Facebook che GitHub sembra non ne possano più fare a meno?

Venerdì 10 marzo, alle 14, sarò ospite di un webinar gratuito, organizzato da Codemotion, durante il quale faremo una chiacchierata introduttiva a GraphQL, ponendo l’accento sulla interessante relazione che ci può essere con un’architettura SOA.

GraphQL and Microservice Architecture

Come possiamo progettare la comunicazione tra UI e back-end quando quest'ultimo è composto da decine (se non di più) di Microservices? Abbiamo la giusta separazione e autonomia lato back-end, ma tutto alla fine deve tornare insieme lato front-end. Come evitiamo che si trasformi nel solito caos di spaghetti code? Come evitiamo che operazioni semplici si trasformino in un tornado di web request? Durante questo webinar introdurremo i concetti base di GraphQL e vedremo come si sposa con la Services UI Composition al fine di comprendere come progettare e implementare con successo una UI per i nostri Microservices.

Maggiori informazioni e iscrizioni: https://attendee.gotowebinar.com/register/155986996187235841

author: Mauro Servienti | posted @ lunedì 6 marzo 2017 7.26 | Feedback (0)

Le sessioni, i titoli e gli abstract.


So che questo appello potrebbe cadere nel vuoto ma sia da partecipante che da speaker mi sento in dovere di farlo.
Mettiamola così: andate al cinema a vedere “Trainspotting”, comprate il vostro biglietto e tutti eccitati vi sedete nella sala giusta in pole position. Inizia il film e vi fanno vedere “50 sfumature di grigio”.

Per chiunque sarebbe inconcepibile.

Il pubblico

È la stessa esperienza che un partecipante ad una conferenza, o evento in generale, fa quando i titoli o gli abstract, se ci sono, non coincidono con quello che poi succede durante la sessione.

Si, perché non solo capita che i titoli, o gli abstract, non abbiano nulla a che spartire con l’argomento poi trattato, ma succede anche che gli abstract siano un laconico e deprimente “TBD…”.

A casa mia è una pura e semplice questione di rispetto.

Lo speaker

Preparare una sessione, un titolo, e un abstract, è uno sforzo non indifferente, specialmente se lo dovete fare in una lingua diversa da quella nativa. Non farlo, oltre a essere irrispettoso nei confronti della nostra ragione di esistere, il pubblico, ci priva anche di un’interessante opportunità.

Ci sono due importanti componenti, oltre alla storia, in un talk:

  • Thesis
  • Call to Action

Riuscire a costruire un abstract, che allo stesso modo di un pitch, racchiuda in poche righe entrambe le cose è difficile. Quando ci riuscite diventa un perfetto faro che vi guida nella creazione dei contenuti del talk stesso. Vi permette di capire cosa è in tema e cosa no. Vi aiuta a garantire che da spettatore non vi sentiate davanti al film sbagliato.

È giusto che sia molto faticoso.

author: Mauro Servienti | posted @ venerdì 3 marzo 2017 12.13 | Feedback (1)