Recentemente, completamente per caso, grazie a una persona molto gentile, è nata l'idea di allegare un riassunto a ogni articolo. Non un'annotazione, né un'attrazione, ma proprio un riassunto. Uno che permetta di non leggere affatto l'articolo.
Ho provato e mi è piaciuto moltissimo. Ma questo è secondario — l'importante è che sia piaciuto ai lettori. Sono tornate le persone che avevano smesso di leggere, etichettandomi come grafomane. E un'altra persona gentile mi ha consigliato di scrivere un riassunto per ciascun vecchio articolo. Ho accettato e ora, nel frattempo, scrivo questi brevi riassunti. Li ho chiamati 'short'.
Vi propongo alcuni di questi 'short', relativi a diverse pubblicazioni. Magari troverete qualcosa di utile per voi.
Il gatto è morto, la coda è pelata
Le riunioni spesso si svolgono senza risultati. Ci si riunisce, si chiacchiera, poi ci si disperde.
I risultati, o i prodotti della riunione, sono le decisioni. Di solito, queste mancano. E quando ci sono, non sempre sono di buona qualità.
Se la riunione è limitata nel tempo e si deve necessariamente prendere una decisione, allora la decisione è spesso di bassa qualità.
Se la riunione non ha limiti di tempo e dura fino a quando non si prende una decisione, allora si prende qualsiasi decisione, pur di concludere la riunione.
Se la decisione è stata concepita in riunione, questa verrà presa — semplicemente perché la mente apprezza ciò che ha creato.
La comprensione della scarsa qualità della decisione arriverà dopo, ma sarà già troppo tardi.
Per prendere una decisione efficace, è meglio non partecipare alla discussione, ma osservare in silenzio.
In primo luogo, la mente non sarà occupata a inventare risposte.
In secondo luogo, non c'è la pressione di dover prendere una decisione.
Dopo la fine della riunione, si può riflettere tranquillamente e prendere una decisione. Sarà di qualità migliore.
Il punto chiave: rimanere in silenzio e ascoltare durante la riunione. Per rassicurare gli altri, dire che è una posizione consapevole.
→
Parassiti latenti
Esistono fondamentalmente due approcci alla definizione dei compiti e al controllo della loro esecuzione: parassitario e simbiotico.
L'approccio simbiotico consiste nel garantire che il compito venga risolto.
L'approccio parassitario consiste nel garantire che il compito NON venga risolto.
L'approccio simbiotico è diretto e semplice, ma difficile da realizzare. Per questo motivo è raro.
Il compito deve essere formulato in modo tale che tutto sia chiaro: obiettivi, risorse e vincoli.
Il controllo viene effettuato in modo da garantire che il compito venga risolto con precisione.
L'approccio simbiotico consiste nel lasciare parte della responsabilità (in particolare, la maggiore) per la risoluzione del compito al proponente.
L'approccio parassitario è complesso e ingegnoso, ma facile da attuare. Ecco perché è molto comune.
Il compito viene formulato in modo che nulla sia chiaro. Meno è comprensibile, meglio è.
Idealmente, è meglio non effettuare alcun controllo.
Non c'è responsabilità per il proponente del compito, tutta la "scimmia" viene trasferita sulla spalla dell'esecutore.
L'obiettivo dell'approccio parassitario: manipolazione, ego, affermazione di sé. Ecco perché è spesso utilizzato nel lavoro dei mentor con i dipendenti principianti.
Naturalmente, è preferibile l'approccio simbiotico.
→
Misurazioni vs Illusioni
Se si valuta il processo e i risultati del proprio lavoro senza misurazioni, si commetteranno errori tutto il tempo.
La valutazione senza numeri dipende dall'umore. Un cattivo umore porterà a pensare che si stia lavorando male. Un buon umore, al contrario.
Così si può passare una settimana a lavorare male e, il venerdì, presentare un risultato che farà sembrare che l'intera settimana sia andata bene.
Fondamentalmente, ci sono due tipi di metriche: quantitative e alternative (più conosciute dai programmatori come Boolean).
"Il compito è stato completato in tempo" è un dato Booleano. È lo stesso che dire "Il componente è idoneo" (un criterio alternativo di qualità quando non possono essere misurati in numeri).
"Lavoriamo bene", "Rispettiamo il piano", "Sono bravo" sono anch'essi dati Booleani.
È difficile costruire un processo di gestione basato su valutazioni di tipo Booleano. È consigliabile passare il prima possibile a metriche quantitative.
Il Booleano genera burocrazia e formalismo. Ad esempio, per rispettare i termini, si possono allungare i tempi, inventare compiti per se stessi o attuare lavoro superficiale.
Per gestire sulla base di indicatori Booleani, è necessario spendere molto tempo — in riunioni, analisi, ecc. Perché ci sono poche informazioni.
Si raccomanda di misurare sia il processo che il risultato. Allora il quadro sarà il più completo possibile.
Per i programmatori si raccomanda il metodo "Planning Poker" dallo Scrum.
→
Questa è Sparta
Supponiamo che tu sia un programmatore e ti venga presentato un compito serio. E ritieni che non sia necessario affrontare il compito — è stupido, dannoso.
Comportamento tipico in questa situazione: portare il compito in pubblico. Inviare per approvazione al capo, avviare un progetto interno, registrarlo nel sistema, ecc.
In questo punto tutto si rompe. La persona che ha portato il compito non vuole essere considerata un idiota. E poiché è stato portato in pubblico, si difenderà.
È importante per una persona non perdere la faccia, in senso politico. In politica, la cosa principale è non ammettere mai i propri errori. Si può non fare nulla, ma l'importante è non avere errori riconosciuti.
La persona farà di tutto per dimostrare che il programmatore è un cattivo, un idiota, un avversario del cambiamento. E il programmatore dovrà comunque risolvere il problema.
In alcuni casi, la persona organizzerà tutto in modo che il programmatore non risolva affatto il problema. In quel caso, la persona sarà 'bianca', e il programmatore sarà completamente 'nero' (sia si è opposto, sia non è riuscito in fin dei conti).
Ci sono diverse soluzioni.
La prima è diventare un programmatore di business, capire le aree correlate e determinare autonomamente cosa e come automatizzare.
La seconda è diventare il Responsabile dei cambiamenti. Ad esempio, il direttore dello sviluppo.
La terza è non opporsi, e semplicemente fare ciò che viene detto.
La quarta è il Percorso di Sparta, un rapido scarto delle soluzioni. Meglio conosciuto come fail fast, fail cheap (fallisci in fretta, fallisci a basso costo).
L'importante è non rendere le cose pubbliche. Dire alla persona: non perdiamo troppo tempo, facciamo un prototipo e vediamo se la soluzione è sostenibile o no.
Ci vorrà poco tempo per il prototipo. In caso di successo entrambi otterranno il loro — e la soluzione sarà adeguata, e saranno guadagnati punti politici.
In caso di insuccesso, nessuno subirà conseguenze. E la persona avrà un'opinione migliore del programmatore.
→
Surrogati
Il settore non ama 1C e i suoi prodotti, sviluppatori web, GRC, contabilità, economisti, progetti di sviluppo, Scrum, TOC, controllo, KPI e sistemi di incentivazione.
Il business ama l'aumento della redditività attraverso l'automazione, la crescita del fatturato grazie alla promozione online, il miglioramento della qualità del prodotto, una visione chiara e comprensibile del business nei numeri, previsioni sulle condizioni dell'azienda, un reale miglioramento dell'efficienza, l'accelerazione dell'esecuzione dei progetti da 2 a 4 volte, un incremento moltiplicato dei profitti e una riduzione delle scorte, un sistema di gestione accurato, un sistema di valutazione chiaro e comprensibile della situazione aziendale, un sistema di valutazione del lavoro che consenta di licenziare metà dei manager.
Il business ama il raggiungimento degli obiettivi aziendali. Il business non ama i surrogati.
Un surrogato è quando ti chiedono di raggiungere un obiettivo aziendale, ma ricevi un progetto di automazione, un sito, un mucchio di carta, un team di dipendenti poco chiari o relazioni incomprensibili.
Un surrogato è quando l'obiettivo viene sostituito lungo il cammino con il mezzo per raggiungerlo. E dell'obiettivo ci si dimentica tutti insieme.
La produzione di surrogati poggia su tre colonne fondamentali: formalismo, gradualità e protezionismo reciproco.
Il formalismo è il trasferimento degli obiettivi su carta con decomposizione. In sostanza, si sposta l'attenzione dal grande obiettivo su piccoli dettagli. Di obiettivo ormai nessuno si ricorda — tutti discutono di dettagli.
La gradualità è la bassa velocità di transizione dagli obiettivi ai mezzi. Inizialmente l'obiettivo viene ancora discusso di tanto in tanto. Ma gradualmente, passo dopo passo, si nomina sempre meno. Fino a quando il committente non lo dimentica totalmente, affondando nei dettagli.
Il protezionismo reciproco si manifesta nel fatto che tutti i contraenti agiscono in maniera simile. Non esiste un automatizzatore che aumenti realmente i profitti. Pertanto, il committente non ha granché scelta.
Cosa fare?
Evitare i surrogati e il primo passo verso la loro creazione: il formalismo. Almeno nei progetti interni. Fissa un obiettivo e parla costantemente con l'esecutore di esso. Anche delle scale, risorse, piani, ecc. — bisogna farlo. Ma soprattutto — riguardo all'obiettivo.
Altrimenti l'attenzione si sposterà sicuramente e otterrai l'ennesimo surrogato.
→
Vladimir Klitschko
C'è un pugile, Vladimir Klitschko. Ha una caratteristica — l'uso costante del jab. Cioè, un uso più costante rispetto ad altri pugili.
Il jab tiene costantemente l'avversario sotto pressione, lo esaurisce.
Le caratteristiche chiave del jab di Klitschko: semplicità di esecuzione (relativa, ovviamente) e costanza.
Molti autori parlano del fatto che azioni semplici, utili ma costanti possano portare molti benefici.
Ho deciso di provare anch'io. Ho creato un semplice sistema di monitoraggio: quali jab ho fatto oggi.
La cosa è accaduta in fabbrica. Facevo jab durante la pausa pranzo (non prendo pausa) cioè 1 ora al giorno. Facevo ciò che gli altri non facevano (si dice che questo porti al successo).
Configuravo i controlli di un sistema auto-apprendente, inventavo idee per lo sviluppo, realizzavo idee di altri per lo sviluppo, impostavo attività automatiche, rifattorizzavo e ottimizzavo il codice.
Ogni giorno — qualsiasi compito da questa lista. Fatta una attività — sei un campione. Puoi farne anche più di una.
Ho osservato per 3 mesi. In questo periodo ho effettuato 30 controlli, inventato 200 idee, realizzato 80 idee altrui, costruito processi automatizzati per due dipartimenti, fatto tre ottimizzazioni fantastiche.
È fantastico, vero? È proprio 'tra un compito e l'altro'. Lo consiglio a tutti.
→
Sostituto flessibile
Con il termine 'Scrum' si identificano, almeno, due entità: filosofia e framework.
La filosofia, o approccio al lavoro, è descritta nel libro di Jeff Sutherland.
Il framework, cioè l'algoritmo delle azioni, è descritto nel documento intitolato Scrum Guide.
La filosofia si è trasformata in un framework perché gli autori della filosofia volevano guadagnare soldi con essa (secondo le loro stesse parole).
Il framework è molto semplificato rispetto alla filosofia. Il punto principale è che è semplificato, o meglio, l'obiettivo è stato eliminato.
L'obiettivo della filosofia: accelerare il raggiungimento del risultato. E con un margine notevole. Nel libro ci sono esempi di accelerazione fino a 8 volte.
L'obiettivo del framework: che tu abbia Scrum. È scritto così: segui le istruzioni — hai Scrum, violi l'istruzione — non hai Scrum.
Il framework non prevede l'accelerazione del raggiungimento dei risultati, affatto.
Le persone che insegnano o implementano Scrum lavorano con il framework. Raccontano e implementano un algoritmo che non porta a nessun risultato, a parte il fatto che 'ora abbiamo Scrum'.
Il concetto è chiaro. Vendere la filosofia è molto difficile. Il framework — è più semplice.
Il framework è un prodotto. Ha, come si deve, passato attraverso una 'confezione'. È semplice, comprensibile, c'è supporto e tanti specialisti. Ti ricorda niente?
Tutto bene, tranne il risultato — che non c'è.
Se il cliente non è familiare con la filosofia Scrum, allora l'implementazione del framework sarà sicuramente soddisfacente per lui.
Se il cliente è a conoscenza della filosofia Scrum, si aspetta di essere deluso dall'implementazione del framework: non ci sarà alcun acceleramento nel raggiungere il risultato.
Sarà interessante, alla moda, moderno, ma non saranno raggiunti obiettivi aziendali (a parte il consumo del budget per "qualcosa di nuovo").
Cosa fare? Studiare la filosofia Scrum. Essa si basa sulla filosofia giapponese della gestione della qualità, il cui fulcro è: misurazione e miglioramenti continui.
Sfortunatamente, è necessario pensare molto, sperimentare, osservare e, ahimè, lavorare. Se questo non vi si addice, prendete il framework.
→
Fonte: habr.com
