Welcome

This is the generic homepage (aka Aggregate Blog) for a Subtext community website. It aggregates posts from every blog installed in this server. To modify this page, look for the Aggregate skin folder in the Skins directory.

To learn more about the application, check out the Subtext Project Website.

Powered By:
Powered by Subtext

Blog Stats

  • Blogs - 714
  • Posts - 31405
  • Articles - 310
  • Comments - 95528
  • Trackbacks - 228558

Bloggers (posts, last update)

Latest Posts

Il lavoratore remoto: la flessibilità, diritto e un dovere

Se lavorate da remoto e state facendo 9/18 con 1 ora di pausa pranzo state sbagliando tutto. Il lavoratore remoto è diverso, deve essere diverso e deve giovare dell’essere diverso.

Forse qualcuno avrà notato che ho cambiato la cadenza dei post, non ce ne sono più il venerdì. Perché? Semplice sono in ferie tutti i venerdì fino a fine agosto. Anche quest’anno per ora niente ferie lunghe e consecutive, ma lo stress e la fatica si accumulano comunque, la flessibilità che ho mi permette con tranquillità di prendermi 14 venerdì di ferie.

Allo stresso tempo visto che fa caldo, troppo caldo perché le mie sinapsi producano qualcosa di intelligente, la flessibilità di cui sopra mi permette di cambiare la mia giornata e spaccarla in due in maniera completamente diversa. La mattina inizia presto, 6.30, finisce verso le 11, piscina, piscina, piscina. Il pomeriggio inizia tardi, verso le 15.30 e finisce tardi.

Nel nostro caso specifico ottengo il vantaggio che ho più sovrapposizione con i colleghi australiani e americani, ma è un dettaglio. Il tutto è permesso dal fatto che la struttura organizzativa e i processi sono pensati con la flessibilità come uno dei punti cardine, nel nostro caso perché è un requisito ovviamente, ma nel vostro?

Se siete un lavoratore 100% remoto e siete obbligati al 9/18 con 1 ora di pausa pranzo, fatevi delle domande, probabilmente c’è qualcosa di profondo che non va e quella è la punta dell’iceberg, o l’effetto collaterale. Uno scenario potrebbe essere che l’organizzazione non è strutturata per il lavoro remoto, ma le percepisce solamente come un benefit (se volete leggere contentino fate pure ;-) ) e come tale lo tratta.

posted @ 7/19/2017 11:24 AM by Mauro Servienti

Le persone vanno unite, non divise.

Nota per il lettore:

Questa (mini) serie di post non è una ricetta per trasformare un’organizzazione in un ambiente in cui fallire non sia un problema, mi spiace dirvelo: non esistono ricette o il manuale delle istruzioni. Quello di cui parlo in questi 6 post sono le cose principali che sono emerse nel lungo processo di trasformazione, iniziato ormai 3 anni fa, che hanno portato Particular Software ad essere quello che è oggi.

La vostra ricetta la potete trovare solo voi facendo quello che forse è il primo, e più difficile, passo: chiedendo a voi stessi, ai colleghi e ai dipendenti che cosa non va bene e come lo cambierebbero. Ovviamente dovete ascoltare le risposte, criticarle e poi infine dovete voler cambiare.

Eroi solitari

Ho spesso la sensazione che si tenda a promuovere una cultura in cui l’eroe solitario, che arriva e risolve tutto, sia la cosa da favorire. Certo dal punto di vista dell’eroe è bello pensare di essere la figura indispensabile, senza la quale non funziona nulla. Quello con il numero 11 sulla maglia. Allo stesso tempo l’eroe è il perfetto capro espiatorio, se ha successo verrà osannato, ma se fallisce abbiamo la figura su cui puntare il dito, quello da punire e castigare.

Cui prodest?

La mia esperienza dice che tutto ciò è figlio di una cultura che premia, o punisce, il risultato. Una cultura focalizzata sul cosa si ottiene e non sul come. In tutto ciò ovviamente il manager, quello nell’accezione negativa, ci sguazza con gioia perché in questo modo detiene potere.

Se al contrario facessimo lavorare, sempre, le persone in team (diciamo in tre)? cosa otterremmo?

  • Diversità di pensiero
  • Lo stimolo a trovare un modo per raggiungere il consenso
  • La nascita, spesso inaspettata, di nuovi leader
  • La scoperta che alcune persone sono dei perfetti avvocati del diavoli
  • Lo stimolo a crescere e alla sfida costante

Forse la cosa più importante è la spersonalizzazione della colpa, se sei solo e fallisci è per forza colpa tua, se sei un team e fallisci è colpa di tutto il team. Ebbene si, magari la colpa è di uno solo del team, ma gli altri lo hanno lasciato fallire portandosi a casa la loro fetta di responsabilità. Un team sano e coeso fa di tutto per auto-correggersi.

Ovvio che siamo in oligarchia, tutto ciò spaventa molto.

Post in questa (mini) serie:

posted @ 7/17/2017 9:23 AM by Mauro Servienti

Le metriche sono il male fatto a misura.

Nota per il lettore:

Questa (mini) serie di post non è una ricetta per trasformare un’organizzazione in un ambiente in cui fallire non sia un problema, mi spiace dirvelo: non esistono ricette o il manuale delle istruzioni. Quello di cui parlo in questi 6 post sono le cose principali che sono emerse nel lungo processo di trasformazione, iniziato ormai 3 anni fa, che hanno portato Particular Software ad essere quello che è oggi.

La vostra ricetta la potete trovare solo voi facendo quello che forse è il primo, e più difficile, passo: chiedendo a voi stessi, ai colleghi e ai dipendenti che cosa non va bene e come lo cambierebbero. Ovviamente dovete ascoltare le risposte, criticarle e poi infine dovete voler cambiare.

L’importanza delle metriche

Misurare è importante, misurare le cose sbagliate è deleterio. Imporre le misurazioni, giuste o sbagliate che siano, è altrettanto problematico. Basare il raggiungimento degli obiettivi sulla base delle metriche, magari sbagliate e imposte, è infine la ricetta per il disastro.

In scenari in cui le metriche scelte sono quelle sbagliate e/o sono imposte dall’alto e non condivise le persone tendono a lavorare principalmente per soddisfare la metrica. Se la metrica premia quanti support case chiudo in una settimana, il mio modello di relazione con il cliente sarà orientato a sbolognarlo nel più breve tempo possibile e non in primis a risolvere con qualità il suo problema.

Non misuravamo nulla

Quando abbiamo deciso di fare tabula rasa della struttura tradizionale dell’organizzazione abbiamo anche eliminato tutte le metriche, non misuravamo nulla. Il passaggio drastico è servito a resettare l’ambiente, a cambiare i parametri del successo e dell’insuccesso. Negli ultimi 6 mesi circa un paio di metriche sono state re-introdotte. Sarebbe meglio dire che sono state inventate dal basso al fine di soddisfare esigenze che le persone coinvolte nelle attività quotidiane hanno.

Quando la metrica emerge dal basso, è condivisa da tutti, è elaborata e costruita da tutti, è naturale vederne il valore intrinseco e non percepirla come un mero strumento di controllo finalizzato alla punizione quando questa non viene soddisfatta.

Concludendo

Come per tutti i processi aziendali, anche le metriche infine devono essere controllate, oliate e aggiustate continuamente, altrimenti diventano il nuovo Gantt scolpito nella pietra, che può solo generare problemi e frustrazioni. Possiamo quindi riassumere dicendo che le metriche:

  • in se non sono il male, ma è come vengono usate;
  • usate per elargire benefit o celebrare successi e punire insuccessi travieranno per forza le persone;
  • devono essere condivise e comprese a fondo da tutti, meglio se vengono dal basso;
  • devono essere costantemente monitorare e aggiustate in base al contesto;

Post in questa (mini) serie:

  • Il manager non serve, trovate: leader, mentor e coach.
  • Le metriche sono il male fatto a misura.
  • Le persone vanno unite, non divise.
  • Fiducia, fiducia e ancora fiducia.
  • Processi (tanti), non risultati.
  • Basta! basta! basta! pensare alla soluzione non serve se non si è compreso il problema.

posted @ 7/12/2017 11:10 AM by Mauro Servienti

GeoCoordinate

per ottenere la distanza in metri fra due punti geografici (lat,lng) in c#

var sCoord = new GeoCoordinate(sLatitude, sLongitude); 
var eCoord = new GeoCoordinate(eLatitude, eLongitude);
double dist = sCoord.GetDistanceTo(eCoord);

posted @ 7/11/2017 2:22 PM by Alessandro Gervasoni

Il manager non serve, trovate: leader, mentor e coach.

Nota per il lettore:

Questa (mini) serie di post non è una ricetta per trasformare un’organizzazione in un ambiente in cui fallire non sia un problema, mi spiace dirvelo: non esistono ricette o il manuale delle istruzioni. Quello di cui parlo in questi 6 post sono le cose principali che sono emerse nel lungo processo di trasformazione, iniziato ormai 3 anni fa, che hanno portato Particular Software ad essere quello che è oggi.

La vostra ricetta la potete trovare solo voi facendo quello che forse è il primo, e più difficile, passo: chiedendo a voi stessi, a colleghi e dipendenti che cosa non va bene e come lo cambierebbero. Ovviamente dovete ascoltare le risposte, criticarle e agire. Infine dovete voler cambiare.

Da Wikipedia:

A manager is a person who manages or is in charge of something. Managers can control departments in companies, or guide the people who work for them. Managers must often make decisions about things.

Abbiamo completamente eliminato i manager, le persone operative sono direttamente responsabili delle loro azioni, le persone sul campo sono quelle che prendono decisioni, tutte le persone coinvolte in un processo si assicurano che il processo sia ben oliato e funzionante, controllando che tutto funzioni come si deve.

Non ci serve un manager con il frustino che stia su un piedistallo a controllare che le risorse (perché così lui le chiamerebbe) stiano incollate davanti al computer almeno 8 ore, ne tantomeno ci serve qualcuno che ti faccia notare che insomma per oggi hai fatto solo mezza giornata, mentre i tuoi colleghi faranno anche 11 ore.

Quello che ci serve sono leader, che spronino le persone a fare scelte audaci e a mettersi in gioco, leader che allo stesso tempo sappiano insegnare alle persone trasferendo conoscenze ed esperienza. Infine siamo costantemente alla ricerca di punti di riferimento, di persone con cui confrontarci in merito alla quotidianità e perché no anche ai problemi lavorativi e non che ci attanagliano.

Come siamo soliti dire:

Non esistono persone sbagliate, ma solo persone giuste al posto sbagliato.

Un manager farebbe di tutto per liberarsene; leader, coach a mentor fanno di tutto per esplorarne il potenziale e trovare il posto giusto per massimizzarlo.

Post in questa (mini) serie:

  • Il manager non serve, trovate: leader, mentor e coach.
  • Le metriche sono il male fatto a misura.
  • Le persone vanno unite, non divise.
  • Fiducia, fiducia e ancora fiducia.
  • Processi (tanti), non risultati.
  • Basta! basta! basta! pensare alla soluzione non serve se non si è compreso il problema.

posted @ 7/10/2017 10:28 AM by Mauro Servienti

La coesione cambia, l’accoppiamento resta. Take 2

Quando abbiamo detto che la coesione cambia e l’accoppiamento resta abbiamo usato un esempio:

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.

La macchina a stati

Un esempio minimalista potrebbe essere il seguente:

  1. Scelgo dal catalogo
  2. Aggiungo al carrello
  3. Inizio il checkout
  4. Imputo l’indirizzo di spedizione
  5. Scelgo il tipo di spedizione
  6. Imputo l’indirizzo di fatturazione
  7. Pago
  8. La merce viene reperita
  9. Il corriere espresso viene contattato
  10. La merce viene spedita
  11. L’ordine è evaso

Diciamo che dal punto 3 in poi è una tipica gestione ordini. Abbiamo vari servizi (logici) coinvolti, come Shipping, Finance, e Warehouse.

Un tentativo accoppiato

Un modo per modellare il processo di cui sopra potrebbe essere:

Il carrello manda un comando al gestore ordini per iniziare il checkout. Il checkout manda un comando a Shipping per far si che i dettagli della spedizione vengano definiti, Shipping quindi manda un comando a Finance per gestire il pagamento, Finance una volta gestito il pagamento manda un comando a Warehouse per iniziare la comporre l’ordine e infine Warehouse manda un comando nuovamente a Shipping per iniziare la spedizione, al termine della quale Shipping dice al gestore dell’ordine che l’ordine è completato e quindi evaso.

Se rileggete quello che abbiamo appena scritto e sostituite tutti i “manda un comando” con “invoca” avete un bel flusso procedurale, accoppiatissimo e monolitico. Flusso in cui magari i service boundary sono chiari e definiti ma monolitico resta, se ci mettete una coda e dei messaggi ottenete due cose:

  • più complessità
  • il solo vantaggio che la coda vi fa off-loading del carico quindi se il passaggio X è particolarmente lento gli altri non ne risentono

L’orchestratore

A questo punto tipicamente il passaggio che si fa è: ma se l’ordine è a tutti gli effetti una macchina a stati, allora un orchestrator, o un process manager, o una saga sono il modello ideale. Del resto prima in un paio di punti sono stato obbligato ad usare il termine “gestore ordini”.

La trasformazione che quindi si applica potrebbe essere ad esempio:

Il carrello manda un comando al gestore ordini per iniziare il checkout. Il gestore ordini manda un comando a Shipping per far si che i dettagli della spedizione vengano definiti, Shipping quindi manda un messaggio al gestore ordini per informare che i dettagli della spedizione sono definiti, il gestore ordini quindi dice a Finance che può gestire il pagamento, Finance una volta gestito il pagamento manda un messaggio al gestore ordini per aggiornarlo sulla situazione. A questo punto il gestore ordini può mandare un comando a Warehouse per iniziare la comporre l’ordine e, dopo aver ricevuto conferma da Warehouse, infine mandare un comando nuovamente a Shipping per iniziare la spedizione, al termine della quale Shipping dice al gestore dell’ordine che l’ordine è completato e quindi evaso.

È cambiato qualcosa?

Secondo me è peggiorato, lo si evince anche solo leggendo:

  • Abbiamo sempre una sorta di comportamento procedurale, questa volta nelle mani di qualcuno di specifico: il gestore ordini
  • è ancora più complesso perché adesso abbiamo un nuovo attore: il gestore ordini
  • è molto verboso, o “chatty” come direbbero i miei colleghi

Perché quindi?

Spesso si finisce comunque per disegnare una soluzione come la seconda con la convinzione che risolva due problemi:

  • non è monolitica, ma è distribuita, scala ed è disaccoppiata (solo perché c’è una coda nel mezzo)
  • abbiamo un posto solo dove la UI può andare a leggere per riportare al lettore lo stato dell’ordine

Tada: “Riportare al lettore lo stato dell’ordine”

Questo è quello che ci sta fregando, questa necessità ci sta dicendo che una porzione del sistema, quella in cui facciamo reportistica all’utente, ha bisogno di informazioni aggregate sull’ordine. Il processo che gestisce l’ordine assolutamente no. I singoli servizi hanno bisogno delle loro informazioni interne per poter fare il loro lavoro. Shipping non ha bisogno di sapere quanto ho pagato o come ho pagato, ha solo bisogno di sapere che ho pagato.

Quindi abbiamo due informazioni importanti adesso:

  • La UI sta generano coesione, alcuni servizi devono in alcuni momenti essere in grado di riportare al lettore informazioni
  • Gli stati dei singoli servizi coinvolti nella gestione dell’ordine sono coesi al fine di risolvere il problema della gestione dell’ordine, ergo tutti prima o poi devono partecipare in qualche modo facendo la loro parte

Perché la coesione può cambiare?

Nel processo di cui sopra il carrello è coeso con la gestione dell’ordine? Solo al primo passaggio, quando iniziamo il processo di checkout, se lo iniziamo dal carrello, se lo iniziassimo da un ordine telefonico no non sarebbe coeso.

Allo stesso modo la coesione evolve o cambia con l’evolvere o l’avanzamento del processo di gestione dell’ordine, c’è un momento, ma solo quello, in cui Shipping probabilmente ha bisogno di Warehouse per capire dimensione e valore dei beni da spedire per organizzare la spedizione e capire se deve assicurarli.

Infine nuovi requisiti potrebbero cambiare gli attuali rapporti di coesione ma sarebbero un terremoto se ci fosse accoppiamento, uno su tutti: arriva uno stakeholder e vi informa che il business vuole vendere anche musica in formato digitale. Tutta la parte di spedizione scompare in un batter d’occhio. Se c’è accoppiamento sono dolori. Se c’è solo coesione c’è solo da introdurre il nuovo processo.

Ricordiamoci che:

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.

posted @ 7/8/2017 11:21 AM by Mauro Servienti

Your First TypeScript Angular 2 App

posted @ 7/7/2017 11:34 AM by Alessandro Gervasoni

CI/CD Hello world

posted @ 7/5/2017 10:38 AM by Alessandro Gervasoni

“Embrace failure”: come crei un ambiente in cui fallire non sia un problema?

Alessio fa quella che probabilmente è la Domanda, con la D maiuscola: Come crei un ambiente che consenta di alzare la mano e dire: “non sono produttivo”?

image

Diciamo che probabilmente possiamo generalizzare la domanda in: come crei un ambiente in cui fallire non sia un problema?

42, è la risposta

Un ambiente in cui fallire non è un problema non è il punto di partenza, piuttosto è la destinazione a cui dovremmo tendere. Se il fallimento non è più visto come un problema si sbloccano tutta una serie di comportamenti che non possono far altro che migliorare drasticamente l’ambiente in cui viviamo e lavoriamo.

Fallimento = male

Il problema di fondo è che la cultura in cui viviamo ci ha insegnato che fallire, o anche semplicemente sbagliare è male, il male peggiore. Si viene marchiati a vita, con la lettera scarlatta, come dei falliti. La cosa molto curiosa è che questo processo mentale si instaura in tarda età. Il bambino appena nato fallisce costantemente e ad ogni piè sospinto, per il semplice fatto che sta facendo esperienza ed ogni cosa è nuova, e l’unico modo per imparare è sperimentando e apprendendo dagli errori, quindi fallendo. Questa cosa è accettata fino ad una certa età dalla nostra società dopodiché ci si aspetta che l’esperienza accumulata sia sufficiente per non sbagliare più.

Mai cazzata fu più colossale

Questo ovviamente, alza il velo del disonore e con il disonore i freni. Quindi? come ristabiliamo l’equilibrio nella forza? Nel nostro piccolo ci abbiamo messo quasi tre anni, minchia tre anni (cit.), ma ci siamo riusciti. Non abbiate fretta.

Le cose che abbiamo fatto e che continuiamo a fare sono tantissime, ma quelle che ritengo essere le più importanti sono:

  1. Il manager non serve, trovate: leader, mentor e coach.
  2. Le metriche sono il male fatto a misura.
  3. Le persone vanno unite, non divise.
  4. Fiducia, fiducia e ancora fiducia.
  5. Processi (tanti), non risultati.
  6. Basta! basta! basta! pensare alla soluzione non serve se non si è compreso il problema.

Alcuni degli argomenti li abbiamo già trattati in maniera sparsa qua e la in questi ultimi due anni. Abbiamo 6 post da scrivere, alla prossima. Post che sono la base del talk “from cogs to nirvana” che ogni tanto mi capita di portare in giro per conferenze e user group, se siete interessati fate un fischio.

posted @ 7/5/2017 8:44 AM by Mauro Servienti

Il lavoratore remoto: il confronto con i colleghi

L’organizzazione della propria giornata lavorativa, in particolare se si è da soli nel proprio ufficio, è particolarmente complessa e rischia di essere il nostro tallone d’Achille. Una giornata mal organizzata può solo portare a:

  • Sensazione o effettiva poca produttività.
  • Poca soddisfazione.
  • Frustrazione

Giorno dopo giorno, mano a mano che si accumulano le settimane la cosa può solo finire male.

Prevenire è meglio che curare

Non ci sono ricette magiche, una delle cose che ho compreso essere molto importante è il costante confronto con i colleghi, ove confronto significa:

  • farsi spiegare come organizzano loro la loro giornata
  • ascoltare quali problemi hanno
  • esporre come organizziamo noi la nostra giornata
  • dire molto apertamente quali problemi abbiamo
  • condividere quindi successi e insuccessi anche nelle piccole cose di tutti i giorni

Quello che in apparenza sembra ovvio implica che lavoriate in un ambiente in cui potete alzare la mano e dire: “non sono produttivo”.

posted @ 7/3/2017 10:19 AM by Mauro Servienti

Services Composition: ViewModel Composition - Take 3

Ci siamo lasciati a questo punto, con una overview ancora architetturale di come funzionano le cose:

image

Il commento di Raffaele mi da lo spunto per entrare un minimo nel tecnico:

image

Back-end

Facciamo un esempio con il mero scopo di capire come potrebbero funzionare nella realtà le cose.

Marketing è un nostro sistema interno scritto in .NET che espone un’API tramite WebAPI. Sales è un’istanza di SalesForce che paghiamo profumatamente. Shipping sono i servizi del/i corriere/i espresso/i che ci forniscono servizi e li possiamo interrogare sempre tramite un’API basata su HTTP. Warehouse è sempre un nostro sistema interno scritto in Node.js. Infine Publishing, che abbiamo detto essere, dal punto di vista logico, un processo di Marketing è un mero Key/Value store in cui dato un ID di prodotto possiamo sapere se è disponibile on-line o meno: quindi Key = ID prodotto, Value = true/false.

IT/Ops Composition Engine

Il Composition Engine altro non è che un reverse proxy che ha lo scopo di implementare un API Gateway, implementato nell’esempio disponibile online con ASP.NET Core. Data la tecnologia del gateway, ogni team dei servizi di cui sopra produrrà un assembly con delle classi che implementano interfacce definite dal Gateway stesso. Questi assembly saranno deployati insieme al Gateway il quale li caricherà via IoC.

/products/123

Abbiamo bisogno di visualizzare un prodotto, la cui chiave è “123”. Per il client il web server a cui rivolgersi è il reverse proxy, quindi la richiesta HTTP “/products/123” viene gestita dal nostro fidato API Gateway. Il quale Gateway ovviamente non sa che fare, se non:

  • Iterare su tutte le classi che implementano IRouteInterceptor (uso la terminologia dell’esempio) e chiedere se sono interessate a gestire la rotta “/products/123” (istanze che potrebbero essere ovviamente cachate per URL).
  • Creare in memoria un ViewModel vuoto, ad esempio un dictionary o un oggetto dymanic.
  • Invocare tutti i route interceptor interessati a gestire la richiesta corrente passando ad ognuno il ViewModel di cui sopra.
    • Ogni route interceptor, data la rotta corrente, è pensato per interagire con il suo backend e quindi recuperare le informazioni necessarie a soddisfare la porzione di richiesta che spetta a lui
  • Aspettare che tutti abbiano finito :-).
  • Ritornare il ViewModel come risposta HTTP.

Concludendo

A questo punto ci aspettiamo che il ViewModel sia riempito con dati pertinenti, ma non è così semplice come sembra. Se osserviamo i servizi/processi da cui siamo partiti c’è una cosa che probabilmente ci salta all’occhio ed è che Publishing comanda, se nel Key/Value Store il valore per “123” è false significa che il prodotto non deve essere visualizzato e che quindi tutti gli altri non devono fare nulla. L’ordine di esecuzione è una rogna, perché implica accoppiamento per certi versi, è una rogna che quindi vorremmo evitare.

Al prossimo giro, però :-)

posted @ 6/30/2017 6:13 PM by Mauro Servienti

Agenda: perché cartacea e non digitale

La domanda di Roberto e la risposta di Michael sono interessanti:

image

Diciamo che sono allineato al 100% con quello che dice Michael, oltre al fatto che la carta:

  • Mi piace
  • Le batterie non si scaricano
  • Non crasha, sbomba, corrompe lo storage, etc..

Battute a parte le motivazioni sono le seguenti:

  • Il fatto di dover riportare costantemente, tutte le sere, al giorno successivo mi aiuta a ragionare sul perché non ho fatto
  • La frizione derivante dal “riportare” a mano mi aiuta a pianificare meglio, perché riportare è noioso

La giornata di oggi si è rivelata un disastro, e guardando l’agenda è evidente perché: ieri si sono accumulate una quantità notevole di cose da fare. Di solito ho un massimo di 8 task, mentre in questo momento siamo così:

2017-06-28 12.52.40 HDR

e dopo la foto è pure peggiorata…sarà una lunga settimana :-)

posted @ 6/28/2017 3:37 PM by Mauro Servienti

Summer reading list

Summer is here.

Time for a break, to re-energise, and explore.

Here a summer reading list, books, for the (to be) reformed manager. It's from my company blog:
- http://www.smharter.com/blog/2017/06/28/summer-reading-list-for-the-to-be-reformed-manager/

And here a selection of posts from this blog of mine:
- http://blogs.ugidotnet.org/luKa/archive/2012/06/25/summer-posts-selection-again.aspx

Have a nice summer !

posted @ 6/28/2017 12:48 PM by Luca Minudel

A day without Javascript

posted @ 6/27/2017 10:10 AM by Alessandro Gervasoni

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.

posted @ 6/26/2017 7:43 AM by Mauro Servienti

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?

posted @ 6/23/2017 7:25 AM by Mauro Servienti

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.

posted @ 6/21/2017 2:22 PM by Mauro Servienti

Alcune risorse sul public speaking

Durante i corsi e le sessioni li cito spesso, ho deciso di raccogliere un po’ di link a futura memoria!

Ogni tanto aggiornerò questo post e lo riposterò sui social… stay tuned!

posted @ 6/20/2017 2:24 PM by Lorenzo Barbieri

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.

posted @ 6/19/2017 10:44 AM by Mauro Servienti

FaunaDb

https://fauna.com

Adaptive operational database from the team that scaled Twitter

posted @ 6/15/2017 4:57 PM by Alessandro Gervasoni

Latest Images

From miscellaneous
From miscellaneous
From miscellaneous
From Immagini
From Immagini
From Immagini
From Immagini
From Immagini
From Immagini
From Immagini
From Immagini
From Immagini
From Immagini
From Immagini
From Immagini
From Immagini
From Immagini
From Immagini
From Immagini
From Immagini