Il lavoratore remoto è da solo e senza feedback


Nel viaggio attraverso alcune delle caratteristiche del lavoratore remoto abbiamo già toccato il problema solitudine. Il tener traccia delle attività quotidiane è un interessante escamotage al fine di dare valore alla giornata, principalmente se la giornata tende ad essere guidata da mille cose da fare.

L’agendina sul lungo periodo non funziona

In ambienti sani (e non credo di averne incontrati) ci si aspetta che ci sia un processo di feedback consolidato, in cui il manager è colui che veicola il feedback verso il team, con un flusso costante di informazioni. Feedback sia positivo che negativo, sono entrambi fondamentali. In ambienti meno sani in cui non c’è un processo consolidato c’è comunque tutto il mondo non-verbale che emerge in maniera naturale dalla condivisione degli spazi, è ovviamente soggetto a interpretazione ma c’è e non è detto che sia cosa buona e giusta se non accompagnato da un vero processo di feedback.

Il lavoratore quindi è immerso in un ambiente che volente o nolente comunica con lui e porta feedback verso di lui.

Il lavoratore remoto non ha neanche quello

Il lavoratore remoto data la sua innata condizione di solitudine non ha neanche accesso al feedback non-verbale, insinuando nella quotidianità domande che non dovrebbero esistere:

  • sto facendo bene?
  • è quello che si aspettano da me?
  • dovrei fare di più?
  • gli altri fanno cose che io non e da cui sono escluso per qualche motivo?

E via dicendo.

Al fine di evitare la degenerazione inevitabile che domande come quelle di cui sopra portano con se, da quasi un anno, in Particular, stiamo ragionando su definire un processo di feedback consolidato e diffuso al fine di prevenire completamente il formarsi anche del solo dubbio.

Il successo va celebrato

Siamo lontani dall’avere qualcosa di pronto, un secondo pilot sta per partire. Secondo perché il primo è stato un mezzo flop (magari ne parleremo). Quello che abbiamo compreso essere fondamentale è comunque una cosa che per molti magari è scontata ma tanti altri proprio non lo è: celebrare il successo.

L’essere umano è molto bravo ad evidenziare, ma ancor di più a notare e ricordare, i problemi. Ed è comprensibile, i problemi per loro natura impattano molto sulla nostra quotidianità quindi emergono e persistono. Ci sono inoltre persone che partono da presupposto che far funzionare le cose faccia parte del loro lavoro quotidiano, risolvere problemi o essere bravi speaker sia dovuto per il semplice fatto che è il loro ruolo all’interno dell’azienda. Ci si aspetta da un responsabile contabilità che ne sappia di contabilità e che si sappia districare nei meandri della stessa, si tende quindi a dare per scontato che possa anche essere un buon responsabile contabilità.

Non basta

Quando le cose vanno bene è importante dirlo, condividerlo. Quando qualcuno fa qualcosa che ha un impatto su qualcosa o su qualcun altro è importante dirlo. Ma cosa ancora più importante è importante dirlo pubblicamente. La condivisione dei successi e la celebrazione degli stessi è un primo passo verso un processo di feedback sano ed efficace.

author: Mauro Servienti | posted @ Monday, June 26, 2017 7:43 AM | Feedback (0)

Quante pagine sono passate sotto i ponti!


2017-06-22 14.15.10 HDR

Oggi finisce un’agenda e ne inizia un’altra

Ne ho parlato la prima volta circa un’anno fa, la usavo da qualche settimana con lo scopo di organizzare la mia giornata lavorativa e sopperire ai sensi di colpa del lavoratore remoto.

Ad oggi il mio personalissimo flusso è:

  • Scrivere sull’agenda quello che voglio fare nella giornata, tutto dalla colazione alla piscina alle attività lavorative
  • Spuntare le cose mano a mano che le faccio
  • Aggiungere in coda le nuove cose che “spuntano”

Alla fine della giornata:

  • Riportare al giorno successivo le cose che non ho completato oggi

L’esperienza fino ad oggi è stata positiva e quindi continuerà. Mi aiuta a focalizzarmi sulle cose che voglio fare e ad ignorare (nel limite del possibile) le distrazioni. Ma cosa ancora più importante è una fonte di feedback, mi aiuta a capire che anche oggi ho fatto.

Nuova agenda nuovo colore, nuova pratica?

Vorrei evolvere, ma sono indeciso sul da farsi. Ho due suggerimenti e so che ne posso scegliere uno solo, applicarli entrambi sarebbe uno stravolgimento della quotidianità poco produttivo.

  • Evolvere aggiungendo una sorta di diario della giornata, in stile retrospettiva. Poche righe, o semplici commenti alle attività e alla giornata nel suo complesso al fine di consolidare e per certi versi celebrare i successi (cosa che noi essere umani siamo pessimi a fare)
  • Introdurre più metodo e quindi ad esempio ordinare la lista per priorità, che quindi vanno decise e valutate, ma soprattutto rispettate

Voi cosa fareste? Avete altre idee?

author: Mauro Servienti | posted @ Friday, June 23, 2017 7:25 AM | Feedback (3)

Quando il software scritto male ti fa perdere clienti: Vitaminstore


Faccio sport, faccio uso di integratori vari e siccome sono allergico ad un paio di cose comperarli online non è mai semplice perché ad esempio su Amazon il dettaglio degli ingredienti è spesso assente. E per un allergico questo è un problema non da poco.

Vitaminstore dal canto suo invece ha un buon modello di ricerca che vi permette di filtrare, ad esempio, per tipologia di alimentazione. Nel mio caso scegliendo la categoria per vegani sono certo di eliminare tutti gli allergeni problematici per me.

Quindi?

Armato di pazienza, perché il sito Vitaminstore è tutto tranne che un fulmine, faccio la mia bella ricerca, aggiungo al carrello, faccio il checkout, pago, e poi attendo fiducioso. Mi arriva la mail di conferma d’ordine e poi il silenzio più assoluto. Dalla mail di conferma d’ordine mi ero quasi dimenticato della cosa, partivo dal presupposto “arriverà”. Oggi mi sono ricordato che l'ordine non si era ancora visto, torno quindi sul sito Vitaminstore per scoprire quanto segue:

image

Il mio ordine quindi non è andato da nessuna parte, quel “tentativo di pagamento” non ho idea di cosa significhi. Sta di fatto che secondo PayPal la transazione è andata a buon fine:

image

Quindi il problema sembra essere lato Vitaminstore.

Ora, mi chiedo io… è possibile che dopo una settimana dall’inoltro di un ordine nessuno del supporto Vitaminstore si sia accorto che quell’ordine è incastrato in qualche modo? Lungi da me il pensare che sia voluta, piuttosto sono quasi convinto che il software usato sia talmente scritto con i piedi che non contempli uno scenario del genere e quindi non si ponga il problema di notificare che un ordine è “stale” da una settimana.

Concludendo

La conseguenza di tutto ciò è che se mai userò ancora Vitaminstore sarà solo ed esclusivamente per la ricerca, poi prendo il prodotto che mi interessa e lo compero su Amazon.

Quanto ci vuole perché questi sedicenti imprenditori capiscano che il software è una componente importante del loro business e non solo una rogna da gestire?

Certo, se scegli schifezze aspettati rogne.

author: Mauro Servienti | posted @ Wednesday, June 21, 2017 2:22 PM | Feedback (0)

La coesione cambia, l’accoppiamento resta


Abbiamo parlato di coesione e accoppiamento e della distinzione tra processi e servizi, ma soprattutto di quando l’accoppiamento sia problematico. Una cosa importante da sottolineare quando si affronta il discorso coesione e processi è che la coesione cambia mentre il processo evolve.

Una macchina a stati

Se pensiamo ad un processo come ad una macchina a stati, in ogni stato del processo ci possono essere coinvolti uno o più servizi, coesi tra loro da quello specifico stato, ma non necessariamente nello stato successivo. Se non stiamo attenti e scivoliamo da coesione verso accoppiamento a questo punto ci ritroviamo che i servizi coinvolti in un processo sono per forza anche inutilmente coesi, proprio perché accoppiati, a prescindere dallo stato del processo stesso.

Siccome l’accoppiamento è per sempre è bene lavorare per ridurlo al minimo indispensabile, ricordandoci che accoppiamento zero è impossibile. La strategia per ridurre all’osso l’accoppiamento tra le parti è identificare i service boundary seguendo la coesione che è una buona linea guida.

author: Mauro Servienti | posted @ Monday, June 19, 2017 10:44 AM | Feedback (0)

Stand up worker: balance pad


Ho avuto più di una occasione per menzionare che sono uno stand-up worker, tutti i giorni, tutto il giorno.

Mai scelta fu più felice

Una delle cose che hanno contribuito a rendere la giornata migliore è un dettaglio che spesso quando siamo costretti a stare in piedi tralasciamo: il modo in cui stiamo in piedi. Stare in piedi fermi per 8 ore è semplicemente deleterio, se poi lo facciamo a piedi nudi è un disastro su tutti i fronti, perché non siamo più fatti per stare a piedi nudi.

Su consiglio dell’osteopata il primo approccio è stato usare un gradino, usavo la scaletta IKEA, su cui alternare le gambe. L’operazione se lavorate in piedi è totalmente naturale e dopo un po’ la fate senza minimamente pensarci. Il risultato è che non siete mai fermi con la conseguenza che schiena e articolazioni delle gambe ne traggono solo benefici.

Una volta compreso che quello era un approccio funzionante, su consiglio del mio collega Daniel, mi sono comperato una cosa che è pensata anche per “impedirci” di stare fermi: un balance pad.

37488f1eb4e8b5c85600d3e406e20fef

È una sorta di materassino in un materiale tipo Memory che assorbe molto bene il peso, non “rimbalza” come farebbe ad esempio la gommapiuma, ma allo stesso tempo impedisce di stare fermi forzando dei costanti micro-movimenti. Costoso, ma perfetto.

Per approfondire

author: Mauro Servienti | posted @ Wednesday, June 14, 2017 1:21 PM | Feedback (0)

Services Composition: ViewModel Composition - Take 2


Dopo aver introdotto ViewModel Composition e prima di parlare di UI Composition, lasciatemi approfondire un attimo la parte di composizione perché è propedeutica a quando inizieremo a parlare di scritture. La volta precedente ci siamo lasciati qui:

image

Dicendo che ViewModel Composition è il risultato del lavoro prodotto da IT/Ops nell’orchestrare il dialogo tra client e servizi.

OK, ma come?

Quello che succede può schematizzato nel seguente modo

image

Tutto inizia con il client interessato ad una risorsa che possiamo identificare con un URL, come ad esempio “/orders/1” dove 1 nel diagramma di cui sopra potrebbe essere visto come la PK (potrebbe perché è un discorso molto ampio che esula da questa serie di post).

L’URL in questione non viene gestito direttamente da uno, o più, dei servizi di backend ma viene preso in carico dal IT/Ops Composition Engine, che nel diagramma opera in modalità reverse proxy (o API Gateway).

Il Composition Engine ospita, come si evince dal digramma i componenti deployati da ogni servizio di backend, immaginiamoci classi che implementano un’interfaccia “IRequestHandler” che il Composition Engine carica via Inversion of Control.

Ogni Request Handler può fare due cose:

  • esprimere interesse o meno per una determinata richiesta
  • intercettare, se interessato, una richiesta

Il Composition Engine a questo punto itera su tutti i Request Handler interessati ad una specifica richiesta (li può anche cachare) e li invoca passando loro un ViewModel (ad esempio dynamic) da poter riempire.

I Request Handler possono a questo punto dato l’URL di partenza invocare i loro rispettivi servizi di backend e comporre il vie model che verrà poi ritornato al client.

Come dicevo un esempio di tutto il giro completo è disponibile qui: https://github.com/mauroservienti/ddd-sw-2017

Post in questa serie:

author: Mauro Servienti | posted @ Monday, June 12, 2017 12:01 PM | Feedback (1)

Altro interessantissimo evento con i ragazzi di @klabcommunity a Fiorenzuola d’Arda


Ieri sera ho avuto il piacere di partecipare all’ennesimo K-Lab organizzato dai ragazzi di K-Lab Community. Come al solito l’evento è stato ottimo, non che ne avessi dubbi. Stavolta c’era anche il bresciano, Alessandro Melchiori. Insieme ad Andrea Ceroni hanno parlato di Actor Model e di AKKA.Net. Ho imparato qualcosa di nuovo anche stavolta, quindi meglio non poteva andare.

Se ricordo bene il prossimo appuntamento sarà a Luglio con un Lean Coffee, o qualcosa di simile in stile unconference. Ci sarò.

author: Mauro Servienti | posted @ Friday, June 9, 2017 4:12 PM | Feedback (1)

Coesione e accoppiamento: Servizi e Processi


Quando cerchiamo di districarci nei meandri della coesione e dell’accoppiamento una delle cose che rischiano di fregarci è un’analisi frettolosa e superficiale di alcuni problemi che sembrano noti e facili a priori. Uno di questi è il non porre attenzione alla distinzione tra servizi e processi. Usiamo un esempio per meglio comprendere.

Shipping è un servizio?

Probabilmente no, molto probabilmente Shipping è un processo all’interno di un servizio, o contesto, più ampio, che è quello del magazzino. Ovvio anche che lo scenario è fondamentale, il mondo della logistica modella in maniera radicalmente diversa da quello degli alimentari, eppure entrambi spediscono.

Tornando al nostro esempio, se Shipping è un processo all’interno di un servizio le “leggi” che regolano l’accoppiamento e la coesione cambiano perché è lecito aspettarsi che i cambiamenti impattino tutto il contesto del magazzino, e di conseguenza anche le spedizioni.

Il processo di scoperta dei service boundaries è lungo, tortuoso e complesso, ma fondamentale. Se non fatto, o fatto male, porta inevitabilmente ad un risultato zoppo, a prescindere dalla qualità del codice che possiamo scrivere.

author: Mauro Servienti | posted @ Wednesday, June 7, 2017 10:09 AM | Feedback (0)

Services Composition: ViewModel Composition


Fino a questo momento non abbiamo fatto distinzioni tra ViewModel Composition e UI Composition, diciamo che in maniera generica abbiamo trattato di Services Composition.

Abbiamo sempre usato un diagramma tipo il seguente senza mai addentrarci nei meandri di cosa succede nel client, a livello di UI.

image

Diventa abbastanza ovvio che ci addentriamo nei meandri dello stack tecnologico, cosa che sappiamo non mi interessa, e che quindi per ora non farò. I concetti però sono la prima cosa che dobbiamo digerire.

IT/Ops

Nel mondo servizi/SOA si tende a etichettare con IT/Ops tutto ciò che è infrastruttura a supporto del business ove un vero e proprio servizio che ne sia proprietario non si riesce ad identificare, spesso perché proprio non c’è. IT/Ops è la parte che si occupa fisicamente del recupero delle informazioni dai vari servizi e della composizione. Il risultato del processo gestito da IT/Ops è la composizione del ViewModel, quindi il diagramma precedente diventa il seguente:

image

Fino a questo punto stiamo facendo ViewModel Composition, il client quindi consuma un ViewModel composto da più servizi che sono totalmente trasparenti al client stesso. Una delle tecniche di composizione di cui abbiamo parlato è quella del proxy, e sul mio account GitHub è disponibile un esempio di Composition Reverse Proxy scritto per .NET Core.

Branding

Nulla vieta a questo punto che la UI sia monolitica, su un device avrebbe molto senso ad esempio. In generale ci sono tante realtà in cui la componente User eXperience è fondamentale, in realtà di questo genere il controllo sulla UI è maniacale. Vengono ad esempio fatti fior di studi sul posizionamento degli elementi e sull’effetto che questo ha sugli utenti. In scenari di questo genere la UI è di proprietà di un servizio, servizio che in gergo si chiama Branding. Branding si occupa di dare il via all’implementazione dei requisiti di business attraverso tutto il processo di Information Architecture e gli studi di User eXperience. In scenari di questo genere la UI è a sua volta monolitica e consuma un ViewModel composto a runtime.

Quando la UI non è monolitica si comincia a parlare di UI Composition, argomento di un prossimo post.

Post in questa serie:

author: Mauro Servienti | posted @ Monday, June 5, 2017 1:01 PM | Feedback (0)

La fretta genera l’errore in ogni cosa (Erodoto)


Il cambiamento richiede tempo e pazienza.

Felice in L’ossimoro implicito dell’ortodossia innaturale nel cambiamento stagnante, interessante articolo sul cambiamento (anche se dal titolo un po’ “antani, prematurata” :P ) sottolinea una cosa molto importante. Un’organizzazione non può pensare di cambiare nello spazio di un week-end. È semplicemente un fallimento garantito, uno spreco di energie e un forte fattore demotivante.

Sembra un’ovvietà, ma come tutte le ovvietà viene ignorata e mi ritrovo a vedere organizzazioni che provano a cambiare alla carlona, senza la benché minima idea di quello che stanno per affrontare e di che impatto avrà. Mi sono reso conto di quanto il cambiamento sia lungo e tortuoso quando settimana scorsa a SoCraTes Italy parlando di tutto il processo che stiamo facendo in Particular, mi è stato fatto notare che noi ci abbiamo messo quasi 3 anni (minchia 3 anni <cit.>) per arrivare dove siamo ora. Se inoltre consideriamo che “ora” è una situazione abbastanza stabile ma che sappiamo essere comunque in costante evoluzione da il metro di misura su cosa voglia dire cambiare un’organizzazione.

State lontani dalla fretta, cattiva consigliera.

author: Mauro Servienti | posted @ Friday, June 2, 2017 8:01 AM | Feedback (0)