Recentemente, per pura coincidenza e grazie a una brava persona, è nato l'idea di allegare un riassunto a ogni articolo. Non un'annotazione, non una pubblicità, ma proprio un riassunto. Un riassunto che permetta di non leggere affatto l'articolo.
Ho provato, e mi è piaciuto moltissimo. Ma questo è secondario: la cosa importante è che è piaciuto ai lettori. Sono tornati quelli che da tempo avevano smesso di leggere, considerandomi un grafomane. Un'altra brava persona ha suggerito di scrivere un riassunto per ogni vecchio articolo. Ho accettato e ora, nel frattempo, scrivo questi brevi riassunti. Li chiamo short.
Vi propongo alcuni di questi short, relativi a diverse pubblicazioni. Chissà che non troviate qualcosa di utile per voi.
Il gatto è morto, la coda spellata.
Le riunioni molto spesso si svolgono senza risultati. Ci si riunisce, si chiacchiera, e si va via.
I risultati, o i prodotti di una riunione, sono le decisioni. Ecco, di solito non ci sono. E se ci sono, non sempre sono di buona qualità.
Se la riunione è limitata nel tempo e si deve prendere necessariamente una decisione, quella decisione può risultare di bassa qualità.
Se la riunione non è limitata nel tempo e dura fino a una decisione, viene accettata qualsiasi decisione, purché la riunione si concluda.
Se la decisione viene formulata durante la riunione, verrà accettata semplicemente perché la mente valorizza ciò che è stato pensato.
La comprensione della bassa 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 trovare risposte.
In secondo luogo, non c'è la pressione di dover prendere una decisione.
Dopo la conclusione della riunione, si può riflettere tranquillamente e prendere una decisione. Sarà di migliore qualità.
Fondamentale: durante la riunione, rimanere in silenzio e ascoltare. Per tranquillizzare gli altri, dire che si tratta di una posizione consapevole.
→
Parassiti latenti
Ci sono due approcci fondamentali nella definizione degli incarichi e nel controllo dell'esecuzione: parassitario e simbiotico.
L'approccio simbiotico implica far sì che il compito venga risolto.
L'approccio parassitario implica far sì che il compito NON venga risolto.
L'approccio simbiotico è diretto e semplice, ma difficile da realizzare. Perciò si incontra raramente.
L'obiettivo è formulato in modo che tutto sia chiaro: obiettivi, risorse e vincoli.
Il controllo viene effettuato affinché l'obiettivo venga raggiunto con certezza.
L'approccio simbiotico implica lasciare parte della responsabilità (e di più) nella definizione dell'obiettivo a chi lo propone.
L'approccio parassitario è complesso e ingegnoso, ma semplice da attuare. Per questo motivo è comune.
L'obiettivo è formulato in modo che non sia chiaro niente. Meno è chiaro, meglio è.
È preferibile non effettuare alcun controllo.
Non c'è alcuna responsabilità per chi propone l'obiettivo; tutta la 'scimmia' viene trasferita sulle spalle di chi esegue.
L'obiettivo dell'approccio parassitario: manipolazione, narcisismo, affermazione di sé. Per questo è frequente nel lavoro dei mentor con i nuovi dipendenti.
Naturalmente, è preferibile un approccio simbiotico.
→
Misurazioni vs Illusioni
Se valuti il processo e i risultati delle tue attività senza misurazioni, commetterai errori continuamente.
La valutazione senza numeri dipende dall'umore. Un cattivo umore ti farà sembrare che stai lavorando male. Un buon umore, al contrario.
Si può passare una settimana a lavorare male e poi alla fine della settimana presentare un buon risultato, dando l'impressione che l'intera settimana sia stata produttiva.
Fondamentalmente, ci sono due tipi di metriche: quantitative e alternative (più conosciute dai programmatori come Boolean).
«Compito completato in tempo» è un indicatore Boolean. È lo stesso di «Parte valida» (un criterio di qualità alternativo quando non è possibile misurare in numeri).
«Lavoriamo bene», «Raggiungiamo i nostri obiettivi», «Io sono bravo» sono anch'essi indicatori Boolean.
È difficile basare la gestione su valutazioni di tipo Boolean. Si consiglia di passare il prima possibile a metriche quantitative.
Il sistema Boolean genera burocrazia e formalismo. Ad esempio, per rispettare le scadenze, si possono allungare i termini, inventare compiti o applicare l'IBD.
Per gestire in base agli indicatori Boolean, è necessario investire molto tempo — in riunioni, analisi, ecc. Perché le informazioni sono troppo scarse.
Si consiglia di misurare sia il processo che il risultato. Allora il quadro sarà il più completo possibile.
Per i programmatori, si raccomanda il metodo del «Planning Poker» del Scrum.
→
Questa è Sparta
Immagina di essere uno sviluppatore e ti viene assegnato un compito difficile. E tu pensi che non valga la pena affrontarlo: è stupido e dannoso.
Il comportamento tipico in questa situazione è di portare il compito in campo pubblico. Inviare per approvazione al capo, avviare un progetto interno, registrarlo nel sistema, ecc.
A questo punto, tutto si rompe. La persona che ha portato il compito non vuole essere considerata un idiota. E una volta portato in pubblico, si difenderà.
È importante per la persona non perdere la faccia, in senso politico. La cosa principale in politica è non ammettere mai i propri errori. Puoi non fare nulla, ma la cosa fondamentale è non avere errori riconosciuti.
La persona farà di tutto per dimostrare che lo sviluppatore è il cattivo, un idiota, un oppositore del cambiamento. E lo sviluppatore dovrà comunque affrontare il compito.
In alcuni casi, la persona cercherà di fare in modo che lo sviluppatore non risolva affatto il compito. Allora la persona sarà "bianca", mentre lo sviluppatore sarà assolutamente "nero" (sia per la resistenza, sia per il fatto che alla fine non ce l'ha fatta).
Ci sono diverse soluzioni.
Il primo passo è diventare un programmatore aziendale, approfondire le aree correlate e decidere autonomamente cosa e come automatizzare.
Il secondo passo è diventare il responsabile delle modifiche. Ad esempio, il direttore dello sviluppo.
Il terzo passo è non opporsi e semplicemente fare ciò che viene detto.
Il quarto passo è il percorso di Sparta, una rapida selezione delle soluzioni. Più conosciuto come fail fast, fail cheap.
L'importante è non rendere pubblica la questione. Dire a una persona: 'non perdiamo tempo, facciamo un prototipo e vediamo se la soluzione è fattibile oppure no.'
Ci vorrà poco tempo per il prototipo. In caso di successo, entrambi otterranno ciò che desiderano: una buona soluzione e punti politici.
In caso di insuccesso, nessuno subirà conseguenze. Inoltre, la persona avrà una migliore opinione del programmatore.
→
Surrogati
Il mondo degli affari non ama 1C e i suoi prodotti, gli sviluppatori web, i sistemi di gestione della qualità, la contabilità, gli economisti, i progetti di sviluppo, Scrum, TOC, il controllo di gestione, i KPI e i sistemi di incentivazione.
Le aziende amano aumentare la 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 tramite i numeri, previsioni sulla situazione aziendale, un'effettiva migliore efficienza, l'accelerazione dell'esecuzione dei progetti da 2 a 4 volte, un incremento esponenziale dei profitti e una riduzione delle scorte, un sistema di gestione preciso, un sistema chiaro e comprensibile per valutare la situazione aziendale e un sistema di valutazione del lavoro che permette di licenziare la metà dei manager.
Le aziende amano raggiungere gli obiettivi aziendali. Le aziende non amano i surrogati.
Un surrogato è quando si richiede di raggiungere un obiettivo aziendale, ma si ottiene un progetto di automazione, un sito web, un mucchio di documenti, un personale incomprensibile o report illeggibili.
Un surrogato è quando lungo il cammino si sostituisce l'obiettivo con il mezzo per raggiungerlo. E tutti dimenticano l'obiettivo.
La produzione di surrogati si basa su tre fondamenti: formalismo, gradualità e collusione.
Il formalismo è il trasferimento degli obiettivi su carta con una decomposizione. In sostanza, si tratta di spostare l'attenzione dal grande obiettivo ai piccoli dettagli. Nessuno ricorda più l'obiettivo: tutti discutono dei dettagli.
Gradualità significa una bassa velocità di transizione dagli obiettivi ai mezzi. All'inizio si discute ancora occasionalmente l'obiettivo. Ma gradualmente, passo dopo passo, se ne parla sempre meno. Fino a quando il cliente non se ne dimentica, immerso nei dettagli.
Responsabilità collettiva — è il fatto che tutti i fornitori agiscono in modo simile. Non esiste un automatizzatore che aumenti realmente il profitto. Pertanto, il cliente non ha molte opzioni.
Cosa fare?
Evitare i surrogati e il primo passo verso la loro creazione: il formalismo. Anche nei progetti interni. Stabilite un obiettivo e parlate costantemente con l'esecutore di esso. Anche delle scale, delle risorse, dei piani, ecc. — lo stesso. Ma la cosa principale è l'obiettivo.
Altrimenti, l'attenzione si sposterà inevitabilmente, e otterrete un altro surrogato.
→
Vitali Klitschko
C'è un pugile — Vladimir Klitschko. Ha una particolarità — l'uso costante del jab. Cioè, più costante rispetto ad altri pugili.
Il jab mantiene 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 ma utili, se ripetute nel tempo, possano portare a grandi benefici.
Ho deciso di provare anch'io. Ho creato un semplice sistema di monitoraggio per tenere traccia delle attività che ho svolto oggi.
Il lavoro era in fabbrica. Eseguivo le attività durante la pausa pranzo (non pranzo), ovvero un'ora al giorno. Facevo ciò che gli altri non facevano (si dice che questo porti al successo).
Configuravo controlli per un sistema auto-apprendente, ideavo proposte di sviluppo, implementavo idee di altri, configuravo compiti automatici, rifattorizzavo e ottimizzavo il codice.
Ogni giorno, qualsiasi compito da questa lista. Completata una attività, bravi. Se ne possono fare anche diverse.
Ho raccolto osservazioni per 3 mesi. In questo periodo ho effettuato 30 controlli, inventato 200 idee, realizzato 80 idee di altri, costruito processi automatizzati in due reparti e fatto tre ottimizzazioni rilevanti.
Fantastico, eh? Questo è un lavoro "nel frattempo". Lo consiglio a tutti.
→
Surrogato flessibile
Con il termine «Scrum» si indicano almeno due entità: filosofia e framework.
La filosofia, o approccio al lavoro, è descritta nel libro di Jeff Sutherland.
Il framework, ovvero l'algoritmo di azioni, è descritto nel documento intitolato Scrum Guide.
La filosofia è diventata un framework perché gli autori della filosofia volevano guadagnare soldi con essa (secondo le loro stesse parole).
Il framework è molto semplificato rispetto alla filosofia. La cosa principale è che è semplificato, o meglio, è stata eliminata, la sua finalità.
L'obiettivo della filosofia: accelerare il raggiungimento del risultato. E in modo significativo. Nel libro ci sono esempi di accelerazione fino a 8 volte.
L'obiettivo del framework: avere Scrum. È precisamente scritto: se segui l'istruzione, hai Scrum; se violi l'istruzione, non hai Scrum.
Il framework non prevede accelerazioni nel raggiungimento del risultato, per nulla.
Le persone che insegnano o implementano Scrum lavorano con il framework. Raccontano e introducono algoritmi che non portano a risultati, se non a 'ora abbiamo Scrum'.
Il concetto è chiaro. Vendere filosofia è molto difficile. Un framework è più semplice.
Il framework è un prodotto. Come dovrebbe essere, ha seguito un ‘packaging’. È semplice, chiaro, c'è supporto e molti specialisti. Non ti ricorda nulla?
Tutto va bene, tranne il risultato — non c'è.
Se il cliente non è a conoscenza della filosofia Scrum, l'implementazione del framework lo soddisferà pienamente.
Se il cliente è familiare con la filosofia Scrum, l'implementazione del framework porterà delusione: non ci sarà alcun acceleramento nel raggiungere i risultati.
Sarà divertente, alla moda, moderno, ma nessun obiettivo commerciale sarà raggiunto (a parte l'assorbimento del budget per 'qualcosa di nuovo').
Cosa fare? Studiare la filosofia di Scrum. Essa si basa sulla filosofia giapponese della gestione della qualità, la cui essenza è: misurazioni e miglioramenti continui.
Sfortunatamente, richiede di pensare molto, sperimentare, osservare e, ahimè, lavorare. Se tutto ciò non fa per voi, prendete il framework.
→
Fonte: habr.com
