Il lavoratore remoto: la diversa-socializzazione


group of monkeys

Il lavoratore remoto, a differenza di quello colocato, non socializza, o fa molta più fatica a socializzare, proprio perché non c’è un “posto” di lavoro che ne favorisca il processo. È quindi facile diventare l’orango di turno che, come in natura, vive la sua vita in solitaria. Solo che il buon orango ha uno scopo ben preciso nello star da solo, mentre sappiamo che l’essere umano molto rapidamente si trasforma in uno strano mostro alienato dalla società.

Il lavoratore remoto deve quindi fare qualcosa di proattivo per stimolare socializzazione dato che non è immerso in un contesto che la favorisce.

Approfittiamone

Tempo fa abbiamo parlato di diversity e della sua importanza in funzione della diversità di pensiero. Il lavoratore remoto ha un’occasione d’oro per cominciare un processo che lo porta ad ampliare le sue vedute. La necessità di cercare socialità principalmente al di fuori del nostro ambiente lavorativo ci può spingere a fare nuove conoscenze, ad andare a più conferenze, ad cercare uno user group vicino a noi (o magari non troppo vicino), e perché no dopo un po’ a cercare stimoli anche in quella che non è la nostra comfort zone.

Insomma non chiudetevi in casa. Non fa bene a noi, ma non fa bene neanche ai nostri colleghi.

author: Mauro Servienti | posted @ Monday, October 16, 2017 7:21 AM | Feedback (0)

Il lavoratore remoto: demo, tutorial, e tanto tanto materiale scritto.


typewriter-1462564916ktC

Se da un lato scrivere è attività da ponderare, dall’altro per il lavoratore remoto è attività fondamentale. Ogni volta che dovete condividere qualcosa con i colleghi in un modello colocato sareste portati ad indire una riunione. Quando lavorate da remoto è molto facile transitare da una riunione ad una conference call, peccato che questa invada lo spazio e l’autonomia di tutti gli invitati come farebbe un lock pessimistico in uno database con alto traffico.

Un disastro insomma. Non che in uno scenario colocato non lo sia, anzi.

La soluzione alla condivisione di materiale è, ad esempio, preparare demo, tutorial e documentazione, con tutti i vantaggi del caso. Ci sono dei casi in cui, sempre di più ultimamente, in cui ad esempio registriamo delle demo e poi le condividiamo internamente attraverso Slack. In soldoni facciamo la conference call con noi stessi, da soli, la registriamo e la rendiamo disponibile ai colleghi da consumarsi in maniera asincrona. Allo stesso modo l’eventuale Q&A può avvenire in maniera asincrona.

Come per la documentazione, il dover preparare una presentazione, una demo, o un tutorial che possa essere consumato da altri in maniera asincrona ne aumenta inevitabilmente la qualità. Perché è molto più semplice, e immensamente meno efficace, parlare a casaccio in maniera sincrona con dei colleghi di qualcosa, invece che organizzarsi perché il contenuto non abbia bisogno di chi l’ha prodotto perché possa essere consumato. Oltre al dettaglio che mantiene il suo valore nel tempo.

author: Mauro Servienti | posted @ Wednesday, October 11, 2017 10:03 AM | Feedback (0)

Il lavoratore remoto: Arrabbiato? non scrivere


cat-1865546_1920

È probabilmente un consiglio che vale sempre, ma ancor di più per il lavoratore remoto: quando sono le emozioni a guidare non usate comunicazione scritta.

WhatsApp è causa della rottura di una quantità abominevole di rapporti, lo so è triste e anche un po’ deprimente. Ho assistito personalmente ad amicizie di lunghissima data andate in frantumi per un’interpretazione sbagliata di un messaggio scritto. E attenzione, non c’è faccina che tenga, se poi ci mettiamo che c’è gente che si è nascosta molto bene quando hanno cercato di insegnarli grammatica, ortografia e l’uso dei famigerati puntini di sospensione…siamo a posto.

Polemiche a parte: Scrivere è difficile, comunicare emozioni scrivendo lo è ancora di più, essere diplomatici mentre si è guidati dalle emozioni e nello stesso tempo si sta scrivendo è compito assai arduo.

Gli strumenti di comunicazione del lavoratore remoto sono nella maggioranza dei casi basati sulla scrittura, vuoi che sia una mail, la chat aziendale o un artefatto di qualsivoglia genere. Ci sono tanti momenti nella quotidianità lavorativa in cui vi girano, non è mica un peccato, o momenti che sono comunque guidati dalle emozioni. Ecco, se dovete esternare qualcosa in questi momenti fate il possibile per non farlo per iscritto, vis-a-vis è nettamente meglio.

Le parole saranno supportate da tutta la comunicazione non verbale e le reazioni del vostro interlocutore vi aiuteranno, spesso inconsciamente, a gestire la situazione.

Questo è ancor più importante se la comunicazione è pubblica, come ad esempio nel nostro caso dove moltissimi degli scambi di opinioni avvengono in commenti su GitHub in repository pubblici, dove molti degli osservatori sono anche totalmente a digiuno del contesto.

author: Mauro Servienti | posted @ Monday, October 9, 2017 7:51 AM | Feedback (1)

Il lavoratore remoto: Nessuno lo sa se non lo dici


2017-05-23-16-13-10

Le dinamiche del lavoro colocato non si possono applicare al lavoro remoto, questo credo sia ormai chiaro. Ne stiamo parlando da un po’ e con i ragazzi di dotNetPodcast stiamo anche registrando una serie di puntate sul tema.

In un ambiente colocato l’ambiente vi osserva, i vostri colleghi vi osservano, il vostro capo vi osserva. In un ambiente in cui c’è contatto fisico con le persone il linguaggio non verbale è una componente importantissima. Questo significa che la comunicazione può essere in qualche modo passiva, non siamo noi a dover per forza iniziare una comunicazione, ma possono essere gli altri sulla base dell’osservazione a decidere che è il caso di iniziarla.

Questa dinamica è totalmente inesistente per il lavoratore remoto, diventa quindi fondamentale essere proattivi, molto proattivi, nella comunicazione con i colleghi.

Non aspettate che la gente venga da voi, andate voi da loro.

Questo vale per qualsiasi cosa: dubbi, problemi, comenti, critiche, stato avanzamento lavori e anche sfoghi e frustrazioni. Non c’è nessuno che ci osserva e che percepisce i nostri sbuffi o malumori non verbali, diventa quindi importante, anche se tutto tranne che facile, essere proattivi.

La considerazione ovvia, leggendo quanto sopra, è che una realtà in cui alzarsi e parlare non è ben visto non è di certo un ambiente che stimola la proattività. Ne consegue che probabilmente non sarà un ambiente adatto al lavoratore remoto.

author: Mauro Servienti | posted @ Friday, October 6, 2017 9:15 AM | Feedback (0)

RFC: Request for Comments


consent-2052051_960_720

Un po’ di tempo fa ci siamo lasciati dicendo che il consenso non funziona. Mettere d’accordo le persone è impresa ardua e complessa, metterne d’accordo tante è molto faticoso, metterle d’accordo tutte è impossibile.

Il nostro processo decisionale è basato su alcuni principi cardine:

  • Sbagliare è umano, e non è un problema
  • Prendere decisioni in solitaria è molto più rischioso che se condivise con un gruppo
  • Prima di prendere una decisione è fondamentale:
    • capire quale sia il problema (o oggetto del contendere)
    • essere certi che il toro che stiamo prendendo per le corna non sia troppo grosso, nel qual caso spezzettare il toro in sotto-problemi, e ricominciare, è cosa buona e giusta

Fatte queste premesse quando dobbiamo affrontare un nuovo compito quello che succede in soldoni è:

  • Un gruppo di persone (task force, TF), diciamo da tre a cinque, si compone al fine di gestire/risolvere il compito in oggetto (il toro)
  • La TF comincia una prima fase di analisi del problema e conferma di avere tutti gli skill necessari alla soluzione/gestione. Nel caso in cui così non fosse ha due opzioni:
    • rinunciare, e smantellarsi
    • contattare degli specialisti al fine di “comperare” (come se fossero consulenti esterni, ma in realtà possono essere anche colleghi) consulenza, conoscenza ed esperienza
  • Ogni volta che la TF è in procinto di prendere una decisione viene iniziate una fase, la cui durata è a discrezione della TF, chiamata RFC:
    • La TF annuncia l’RFC
    • l’RFC, è un documento, dettaglia il contesto, le soluzioni prese in considerazione, pro e contro, e l’attuale proposta o direzione che la TF vorrebbe prendere
  • Chiunque ha la possibilità di commentare
  • Al termine della finestra di RFC la TF può valutare i commenti/suggerimenti/critiche. Non è obbligata a prenderli in considerazione
  • La TF è pronta per procedere e se necessario in uno stadio successivo fare un’altra RFC.

Chiunque, con buone e solide motivazioni può bloccare tutto in qualsiasi momento (stop the line) se ritiene che le scelte che la TF sta facendo siano sbagliate. Con buone e solide motivazioni.

author: Mauro Servienti | posted @ Wednesday, October 4, 2017 7:32 PM | Feedback (0)

12 minuti ben spesi: Why good leaders make you feel safe


image

Parafrasando:

Un buon leader si sacrifica per salvare gli altri, non sacrifica gli altri per salvare se stesso.

Manager con i macchinoni, i bonus e le posizioni acquisite: meditate.

Versione integrale: https://www.ted.com/talks/simon_sinek_why_good_leaders_make_you_feel_safe

author: Mauro Servienti | posted @ Monday, October 2, 2017 6:23 AM | Feedback (0)

Lo strano concetto di sicurezza di ATM


Ci risiamo :-) La sfortuna vuole che mi sono dimenticato la password per accedere al sito ATM, lo uso per poter acquistare i biglietti dei mezzi di Milano direttamente dall’app.

image

Mi sembra normale che siccome puoi usare l’app per spendere del denaro:

  • la password te la mandano per e-mail, che sappiamo essere sicurissima
  • la password non deve essere cambiata al primo accesso…WAT?
  • non vi è nessuna possibilità di avere una sorta di, o una vera che sarebbe meglio, 2 Factor Authentication

Grrrr…

author: Mauro Servienti | posted @ Friday, September 29, 2017 11:01 AM | Feedback (5)

Quando la UX toppa alla grande


Qualcosa di diverso oggi. Ho aggiornato l’iPad ad IOS 11, mi piace, funziona bene nonostante l’iPad in questione abbia ormai quasi 3 anni, ma una cosa mi ha sorpreso (o deluso se volete) parecchio.

Domanda: quante applicazioni ho in esecuzione in questo momento?

2017-09-25 21.19.46

La risposta è 5, perché la UX corretta di quella schermata sarebbe dovuta essere la seguente:

2017-09-25 21.19.54

Che fa capire al volo che quello che vedo non è tutto, la UX attuale obbliga a tentare di scrollare verso sinistra sempre perché non si ha idea se vi sia qualcosa.

E dire che “altri” ci avevano pensato qualche anno fa…A buon intenditore poche parole.

author: Mauro Servienti | posted @ Wednesday, September 27, 2017 10:19 AM | Feedback (0)

Sempre per quella storia della documentazione


image

Giulio su LinkedIn commenta:

Nella mia esperienza, la documentazione con maggior valore è scritta prima del codice, quella in cui spieghi il contesto di riferimento, l'ambito di applicazione del sistema, l'architettura generale e il Quick start manual. È l'equivalente del TDD, anzi dell'ATDD, ma a livello dell'intero sistema è con la prospettiva di ciascun ruolo: semplice utente, amministratore, manutentore del codice, incluso il marketing. Non deve essere un ritratto, ma uno schizzo che coglie i lineamenti essenziali, che andrà rifinita ad ogni iterazione. Gran parte del suo valore è prospettico: è un esercizio di analisi e comprensione che spesso svela elementi critici del sistema. Se ricordo bene The mythical man month aveva già colto tutto questo diecine di anni fa (purtroppo non posso andare a verificarlo adesso).

Avevo cercato di dire la stessa cosa in precedenza, evidentemente senza lo stesso impatto:

Allo stesso modo trovo molto valore nella documentazione, vi dirò di più trovo molto valore nello scrivere la documentazione. È una forma di testing, spesso ci ritroviamo a scrivere documentazione prima dell’implementazione stessa. L’operazione di scrittura, comprensiva di esempi completi e snippet di codice, impone di mettersi nei panni dall’utilizzatore finale provando in prima persona l’ergonomia di quello che si sta per produrre.

Che va a braccetto con quello che scrive Giulio nel commento:

Nella mia esperienza, la documentazione con maggior valore è scritta prima del codice […] È l'equivalente del TDD […] ma a livello dell'intero sistema è con la prospettiva di ciascun ruolo

Questo per (riba)dire che nella mia esperienza la documentazione serve prima a noi che all’utente finale.

author: Mauro Servienti | posted @ Monday, September 25, 2017 9:20 AM | Feedback (2)

Che l’autunno abbia inizio: #KLab 2017 05 - @klabcommunity


Ebbene si il 22 e non il 21 quest’anno. Per l’ennesima volta ho il piacere e l’onore di partecipare come speaker ad un KLab. Altro trimestre, altro KLab e altra culaccia* ;-)

A questo giro si parlerà di .NET Standard e .NET Core, il sottoscritto si preoccuperà di introdurvi nel mondo magico di .NET Standard, mentre Michael si occuperà del corposo argomento .NET Core (quindi ha diritto a magiare di più).

Maggiori informazioni: http://milestone.topics.it/events/klab-2017-05.html

Iscrizioni: https://www.eventbrite.com/e/klab-5-2017-tickets-37936481036

[*] Sento il profumo solo a scriverlo…

author: Mauro Servienti | posted @ Friday, September 22, 2017 8:55 AM | Feedback (0)