di un ragazzo

Una storia vera, l'ho vista con i miei occhi.

Per alcuni anni, un ragazzo, proprio come voi, ha lavorato come programmatore. Per completezza, lo scriverò così: «programmatore». Perché era un programmatore 1C, con un contratto fisso, in un'azienda industriale.

Prima di questo, ha provato diverse specialità: 4 anni come programmatore in un'agenzia, responsabile di progetti, riuscendo a chiudere fino a 200 ore, guadagnando allo stesso tempo una percentuale sul progetto, per la gestione e occupandosi anche un po' delle vendite. Ha tentato di sviluppare prodotti autonomamente, è stato il capo del dipartimento IT in una grande azienda con 6.000 dipendenti, sperimentando diverse applicazioni della sua professione da programmatore 1C.

Tuttavia, tutte queste posizioni erano piuttosto senza via d'uscita, soprattutto in termini di reddito. All'epoca, tutti noi guadagnavamo all'incirca le stesse somme, lavorando nelle stesse condizioni.

Questo ragazzo ha cominciato a essere curioso su come guadagnare di più senza doversi occupare di vendite né avviare una propria attività.

Si era convinto di essere molto intelligente e decise di trovare una nicchia all'interno dell'azienda in cui lavorava. Questa nicchia doveva essere qualcosa di speciale, non occupata da nessuno. Voleva che l'azienda fosse essa stessa a voler pagare una persona per questa nicchia, senza bisogno di ingannare qualcuno o di forzare la situazione. Doveva essere oggettivo: a una persona in questa posizione dovevano pagare molto. Un tipo strano, insomma.

La ricerca non durò a lungo. Nell'azienda in cui lavorava, c'era una nicchia completamente libera, che si poteva definire "tirocinio nell'ottimizzazione dei processi aziendali". In ogni azienda ci sono un sacco di problemi. Qualcosa non funziona mai, e non c'è nessuno che venga a correggere i processi aziendali. Così, decise di mettersi alla prova come specialista in grado di aiutare il proprietario a risolvere i suoi problemi nei processi aziendali.

All'epoca lavorava in azienda da sei mesi e riceveva uno stipendio medio sul mercato. Non aveva nulla da perdere, soprattutto perché avrebbe potuto trovare un lavoro simile in una settimana. In sostanza, il ragazzo ragionò che non sarebbe successo niente di grave se, per caso, le cose non fossero andate come sperato e fosse stato licenziato.

Ha trovato il coraggio di parlare con il proprietario. Gli ha proposto di migliorare il processo più problematico dell'azienda, che all'epoca era la gestione del magazzino. Oggi, chi lavora in questa azienda si vergogna persino di ricordare quei problemi, ma gli inventari effettuati trimestralmente mostrano discrepanze tra il sistema contabile e le giacenze reali che superavano anche il dieci percento. Questo riguardava sia il valore che la quantità e il numero di articoli. Era un vero disastro. L'azienda aveva giacenze corrette nel sistema contabile solo quattro volte l'anno – il giorno dopo l'inventario. È stato proprio questo processo che il nostro ragazzo ha iniziato a sistemare.

Il ragazzo ha concordato con il proprietario che doveva ridurre gli scostamenti nei risultati dell'inventario della metà. Inoltre, al proprietario non interessava molto, perché prima del nostro eroe vari lavoratori avevano già tentato di risolvere la situazione, e in generale il compito era considerato praticamente irrisolvibile. Tutto ciò accresceva notevolmente l'interesse, perché se tutto fosse andato a buon fine, il tipo sarebbe automaticamente diventato una persona capace di mettere ordine e risolvere problemi apparentemente impossibili.

Così, si trovava di fronte al compito: entro un anno doveva ridurre gli scostamenti nei risultati dell'inventario della metà. All'inizio del progetto non aveva idea di come farlo, ma sapeva che la gestione di magazzino è una cosa semplice, quindi sicuramente sarebbe riuscito a fare qualcosa di utile. Tanto più che ridurre gli scostamenti da decine di percento a una sola decina di percento non sembrava così difficile. Tutti quelli che lavorano nel campo della consulenza o in attività simili sanno che la maggior parte dei problemi del processo possono essere risolti con azioni piuttosto semplici.

Da gennaio a maggio, si è preparato, ha automatizzato alcune operazioni, ha riscritto il processo di gestione dell'inventario, ha modificato i flussi di lavoro di magazzinieri, contabili e ha completamente ristrutturato il sistema, senza mostrare o raccontare nulla a nessuno. A maggio, ha distribuito a tutti nuove istruzioni e dopo il primo inventario dell'anno, è iniziata una nuova era – il lavoro secondo le sue regole. Per osservare i risultati, l'azienda ha iniziato a condurre inventari più frequentemente – ogni due mesi. Già i primi risultati sono stati positivi e entro la fine dell'anno, le discrepanze nei risultati dell'inventario erano scese a frazioni di un percento.

Il successo è stato enorme, ma non si credeva nella sua sostenibilità. Il ragazzo stesso dubitava che il risultato sarebbe rimasto se si fosse allontanato e avesse smesso di osservare il processo. Tuttavia, il risultato c'era, e il ragazzo ha ottenuto tutto ciò di cui aveva concordato con il proprietario. Poi, dopo alcuni anni, la sostenibilità del risultato si è confermata: le discrepanze sono rimaste entro l'1 % per diversi anni.

Così ha deciso di ripetere l'esperimento e ha proposto al proprietario di migliorare un altro processo problematico: l'approvvigionamento. C'erano penurie che impedivano di spedire i volumi desiderati dai nostri clienti. Si sono accordati che nel corso di un anno le penurie sarebbero diminuite della metà e che lui avrebbe completato 10-15 progetti legati a 1C, riguardanti l'automazione di vari processi aziendali e altre questioni simili.

Nel secondo anno, sono riusciti a concludere tutto con successo, le penurie si sono ridotte di oltre il 50% e tutti i progetti IT sono stati completati con successo.

Poiché lo stipendio soddisfaceva già tutte le richieste di quel ragazzo per almeno due anni, ha deciso di stabilizzarsi un po', di tranquillizzarsi e di godersi un posto accogliente e caldo che aveva creato per se stesso.

Cosa rappresentava? Formalmente, era un IT Director. Ma è difficile comprendere chi fosse realmente. Infatti, cosa fa un IT Director? Di solito amministra l'infrastruttura IT, guida gli amministratori di sistema, implementa sistemi ERP e partecipa a riunioni nel consiglio dei direttori.

Uno dei compiti chiave di quest'uomo era partecipare ai processi di cambiamento, principalmente generando e iniziando tali processi, cercando e proponendo soluzioni, applicando nuove metodologie di gestione, valutando le modifiche proposte, analizzando l'efficacia di altre funzioni e divisioni e, infine, partecipando attivamente allo sviluppo strategico dell'azienda, fino a redigere autonomamente il piano strategico dell'intera società.

Gli è stata data carta bianca. Poteva partecipare a qualsiasi riunione a cui prima non aveva accesso. Stava lì con un blocco note, annotando qualcosa o semplicemente ascoltando. Parlava raramente. Poi iniziava a giocare sul telefono, affermando che questo aiutava la memoria associativa a lavorare meglio.

Nelle riunioni raramente dava contributi utili. Se ne andava, rifletteva e poi arrivava un'email — o con critiche, o con opinioni, o con proposte, o con descrizioni di soluzioni che aveva già applicato.

Ma più spesso era lui a convocare le riunioni. Trovava il problema, inventava soluzioni, identificava le parti interessate e portava tutti nella sala riunioni. E lì, come sapeva fare, convinceva, motivava, dimostrava, discuteva, otteneva risultati.

Ufficiosamente era considerato la terza figura dell'azienda, dopo il proprietario e il direttore. Naturalmente, infastidiva immensamente tutte le "figure aziendali", a partire dal numero 4. Soprattutto con i suoi jeans strappati e le magliette colorate, oltre al tempo del proprietario.

Il proprietario gli dedicava un'ora al giorno. Ogni giorno. Parlavano, discutevano di problemi, soluzioni, nuovi affari, direzioni di sviluppo, risultati ed efficienza, crescita personale, libri, e semplicemente — vita.

Ma quel ragazzo era strano. Sembrava — siediti e goditi, la vita è bella. Ma no. Decise di riflettere.

Gli è venuto in mente: perché a lui è riuscito, mentre ad altri no? Il proprietario lo incoraggiava: diceva che voleva che anche gli altri riuscissero a mettere ordine, perché ci sono molti manager, che di solito si occupano della gestione operativa e della pianificazione strategica, ma praticamente nessuno si interessa delle modifiche sistemiche ai propri processi. Nella loro descrizione del lavoro, potrebbe anche essere scritto che devono velocizzare il proprio processo, aumentarne l'efficienza, ma di fatto nessuno lo fa. Perché? Anche a questo ragazzo è venuta curiosità e ha cominciato a parlare con tutti questi manager.

È andato dal vice direttore alla qualità e ha proposto di implementare le carte di controllo di Shewhart, affinché i prodotti fossero migliori di quelli giapponesi. Ma si è scoperto che il collega non sapeva cosa fossero le carte di controllo di Shewhart, cosa fosse la gestione statistica dei processi, e aveva sentito solo vagamente parlare dell'uso del ciclo di Deming nella gestione della qualità. Va bene...

Andò da un altro vice direttore e propose di implementare il controllo di gestione. Ma anche lì non trovò supporto. Poco dopo scoprì il boundary management e suggerì a tutti i vice direttori di adottare la parte sistematica di questo approccio per migliorare i processi. Ma per quanto il ragazzo tentasse di spiegare, nessuno sembrava realmente interessato a comprendere di cosa si trattasse. Forse era poco interessante o troppo complicato. Ma, alla fine, nessuno ci capì niente.

In generale, raccontò tutto ciò che sapeva e applicava in azienda. Ma nessuno riuscì a comprenderlo. A tutt'oggi non capiscono perché, ad esempio, siano riusciti a correggere la contabilità di magazzino e quale sia il legame con il controllo di gestione e la gestione dei confini.

Alla fine, arrivò ai suoi programmatori – nel team c'erano 3 persone. Parlò di gestione dei confini, di controllo di gestione, di gestione della qualità, di agile e scrum... E con sua sorpresa, tutti capirono e poterono persino discutere con lui, comprese le specifiche tecniche e metodologiche. Capirono perché i progetti relativi al magazzino e alla fornitura avessero avuto successo. E lì il ragazzo ebbe un'illuminazione: in realtà, il mondo sarà salvato dai programmatori.

I programmatori, ha capito, sono gli unici in grado di comprendere a fondo i processi aziendali con il giusto livello di dettaglio.

Perché proprio loro? In realtà non ha mai trovato una risposta univoca. Ha formulato solo alcune osservazioni per punti.

In primo luogo, i programmatori conoscono le aree tematiche del business e, inoltre, le conoscono meglio di chiunque altro in azienda.

Inoltre, i programmatori comprendono realmente cosa significhi un algoritmo di processo. Questo è importante perché i processi aziendali sono algoritmi e gli elementi al loro interno possono essere semplicemente disallineati. Ad esempio, nel processo di approvvigionamento su cui lavorava, il primo passaggio consisteva nella redazione del piano annuale degli acquisti, e il secondo nell'acquisto quotidiano. Questi passaggi sono collegati da un legame diretto, cioè si presume che secondo questo algoritmo le persone debbano lavorare: redigere il piano annuale degli acquisti e subito dopo eseguire la richiesta. Il piano annuale degli acquisti viene redatto una volta all'anno, mentre la richiesta arriva 50 volte al giorno. Questo è dove l'algoritmo finisce, e bisogna lavorare su di esso. In effetti, ragionò, per i programmatori conoscere gli algoritmi è un vantaggio competitivo, poiché chiunque altro, che non ne è familiare, semplicemente non comprende come dovrebbe funzionare un processo aziendale e come possa essere rappresentato.

Un altro vantaggio dei programmatori, secondo quel ragazzo, è che hanno abbastanza tempo libero. Tutti capiamo come un programmatore possa impiegare tre volte più tempo per completare un compito rispetto a quanto realmente richiesto, e pochi se ne accorgono. Questo, di nuovo, è un vantaggio competitivo, perché per sistemare un processo aziendale è necessario avere molto tempo libero per riflettere, osservare, studiare e sperimentare.

La maggior parte dei manager, secondo il ragazzo, non ha questo tempo libero e ne è orgogliosa. Anche se in realtà ciò significa che una persona non può diventare efficace, poiché non ha tempo per migliorare la propria efficienza - un circolo vizioso. Nella nostra cultura è di moda essere occupati, quindi tutto resta stagnante. E per noi programmatori, questo è un vantaggio. Possiamo trovare del tempo libero e pensare a tutto.

I programmatori, ha raccontato, possono cambiare rapidamente il sistema informativo. Questo non è applicabile a tutti gli stabilimenti, ma in tutti quelli in cui ha lavorato, era possibile apportare qualsiasi modifica ritenuta necessaria. Soprattutto se non riguardava il lavoro di nessun altro. Ad esempio, poteva avviare un sistema che misurava segretamente le azioni degli utenti e utilizzare poi queste informazioni per analizzare l'efficacia del lavoro della contabilità e monitorare i costi della gestione contabile.

E l'ultima cosa che ricordo dalle sue parole è che i programmatori hanno accesso a una grande quantità di informazioni, poiché sono dotati di accesso amministrativo al sistema. Pertanto, possono utilizzare queste informazioni nella loro analisi. Nessun altro in un normale stabilimento ha tale risorsa.

E poi se ne andò. Durante il periodo di preavviso di due settimane, lo abbiamo costretto a condividere la sua esperienza, perché volevamo continuare il lavoro che stava svolgendo. Inoltre, la sua posizione stava diventando vacante.

Per alcuni giorni lo abbiamo fatto sedere su una sedia, accendere la telecamera e registrare i suoi monologhi. Gli abbiamo chiesto di parlare di tutti i progetti completati, dei metodi, degli approcci, dei successi e degli insuccessi, delle cause e degli effetti, dei ritratti dei dirigenti, ecc. Non abbiamo posto troppi limiti, poiché non sapevamo cosa avesse in mente.

Nei monologhi, ovviamente, c'era soprattutto una certa sciocchezza e divertimento — era di ottimo umore, poiché stava lasciando un luogo sperduto per San Pietroburgo. E dove andare a lavorare a San Pietroburgo? In Gazprom, naturalmente.

Ma siamo riusciti a ricavare alcune informazioni utili dai suoi monologhi. Racconterò ciò che ricordo.

Quindi, ecco i consigli di quel ragazzo. A chi volesse provare a mettere ordine nei processi aziendali.

Per intraprendere un lavoro del genere, prima di tutto, bisogna avere un certo livello di 'follia'. Non bisogna temere di perdere il lavoro, di correre rischi o di affrontare conflitti con i colleghi. Lui riusciva a farlo facilmente, perché ha iniziato il suo percorso dopo solo sei mesi di lavoro in azienda, ed era ancora lontano da qualsiasi contatto, e non aveva nemmeno intenzione di instaurarne. Comprendeva che le persone vanno e vengono, e ciò che contava per lui erano i suoi risultati e la loro valutazione da parte del proprietario dell'azienda. Se i colleghi lo giudicavano bene o male, a lui interessava poco in quel momento.

Un secondo punto è che, per svolgere efficacemente questo lavoro, purtroppo, bisognerebbe studiare. Ma non studiare in MBA, né in corsi, né all'università, ma autonomamente. Ad esempio, nel suo primo progetto, relativo al magazzino, agiva d'istinto, non sapeva nulla, solo cosa fosse la 'gestione della qualità'.

Quando ha iniziato a leggere sulla letteratura, sui metodi per migliorare l'efficienza, ha scoperto le tecnologie che già applicava. Il ragazzo le applicava intuitivamente, ma si è reso conto che non era una sua invenzione, tutto era già stato scritto da tempo. Tuttavia, ha sprecato tempo, molto di più di quanto avrebbe fatto se avesse letto subito il libro giusto. È importante comprendere che quando si studia una metodologia specifica, nessuna di essa, neanche la più avanzata, risolverà completamente i problemi del processo aziendale.

Il secondo aspetto è che più metodologie conoscete, meglio è. Per esempio, nell'antico Giappone viveva Miyamoto Musashi, uno dei più famosi spadaccini, autore dello stile delle due spade. Ha studiato in una scuola con un maestro, poi ha viaggiato per il Giappone, combattendo con vari avversari. Se un avversario era più forte, il viaggio si interrompeva per un po' e Musashi si dedicava all'apprendistato. Di conseguenza, in pochi anni ha acquisito competenze in diverse pratiche di vari maestri e ha fondato la sua scuola, aggiungendo elementi personali. Alla fine, ha sviluppato un'abilità unica. Anche qui è la stessa cosa.

Certo, si può agire come consulenti aziendali. In effetti, sono ottime persone. Ma, di norma, arrivano per implementare un qualche metodo, e applicano metodologie che non sono quelle necessarie per l'azienda. Anche noi abbiamo avuto situazioni del genere: nessuno sa come risolvere il problema e nessuno vuole pensare a come risolverlo. Cominciamo a cercare su Internet o a contattare un consulente, chiedendo cosa può aiutarci. Il consulente riflette e dice che dobbiamo implementare la teoria delle restrizioni. Lo paghiamo per il consiglio, spendiamo per l'implementazione, ma il risultato è zero.

Perché succede questo? Perché il consulente ha detto di implementare tale sistema e tutti sono stati d'accordo. Ottimo, ma un singolo metodo non risolve tutti i problemi anche di un solo processo aziendale, soprattutto se le premesse di partenza non coincidono — le nostre e quelle necessarie per l'implementazione del metodo.

Nella pratica, ciò che il ragazzo consiglia è di prendere il meglio e implementare il meglio. Non prendere i metodi nella loro interezza, ma cogliere le loro caratteristiche chiave, punti di forza, pratiche. E la cosa più importante è comprendere l'essenza.

Prendiamo, diceva, per esempio, scrum o agile. Nei suoi monologhi, il ragazzo ha ripetuto più volte che non tutti comprendono fino in fondo il significato dello scrum. Anche lui ha letto il libro di Jeff Sutherland, che alcuni considerano una lettura 'leggera'. A lui è sembrato un lavoro profondo, perché una delle fondamenta dello scrum è la gestione della qualità, e di questo si parla esplicitamente nel libro.

Nel libro si parla della Toyota Production, di come Jeff Sutherland ha presentato lo scrum in Giappone, di quanto si sia radicato lì e di quanto fosse vicino alla loro filosofia. Sutherland ha anche parlato dell'importanza del ruolo dello scrum master, del ciclo di Deming. Il ruolo dello scrum master è quello di accelerare continuamente il processo. Tutto ciò che riguarda lo scrum, come le consegne per fasi, la soddisfazione del cliente e un elenco chiaro di attività per il periodo dello sprint, è importante, ma tutto deve procedere sempre più rapidamente. La velocità del lavoro deve aumentare costantemente nelle unità in cui viene misurata.

Forse qui c'è un problema di traduzione, perché il nostro libro è stato tradotto come "Scrum - un metodo rivoluzionario per la gestione dei progetti", mentre se si traduce letteralmente il titolo originale in inglese, si ottiene: "Scrum - il doppio in metà tempo", il che significa che anche nel titolo c'è un riferimento alla velocità, come funzione chiave dello scrum.

Quando questo ragazzo ha implementato lo scrum, nella prima settimana la velocità è raddopiata senza particolari cambiamenti. Ha trovato opportunità di cambiamento, ha modificato lo scrum per adattarlo a sé stesso, in modo che funzionasse molto più velocemente. L'unica cosa, come scrivono su internet, è che si sono trovati di fronte al problema: "Abbiamo raddoppiato la velocità, rimane da capire cosa fare con questa velocità?". Tuttavia, questa è già un'altra questione...

Ha anche raccomandato personalmente alcune metodologie. Le ha definite fondamentali e fondamentali.

La prima è il boundary management (gestione dei confini).

Viene insegnato a «Skolkovo», e secondo quanto afferma il ragazzo, non ci sono altri libri o materiali. Ha avuto la fortuna di assistere a una lezione di un professore di Harvard, che parla di boundary management, e di leggere diversi articoli nella Harvard Business Review sul lavoro di Erik Tristen.

Il boundary management riguarda la capacità di riconoscere i confini e di lavorare con essi. I confini sono ovunque: tra i dipartimenti, tra i diversi tipi di lavoro, tra le funzioni, tra il lavoro operativo e analitico. La conoscenza del boundary management non svela verità superiori, ma permette di vedere la realtà sotto una luce diversa — attraverso la lente dei confini. Di conseguenza, consente di gestirli — creando confini dove necessario e rimuovendoli dove sono un ostacolo.

Ma più spesso il ragazzo parlava di controlling. Sembrava avere una sorta di fissazione su questo argomento.

Il controlling, in breve, è la gestione basata sui numeri. Qui, diceva, ogni parte della definizione è importante — sia «gestione», sia «basata su», sia «numeri».

Da noi, ha detto, ci sono problemi con tutti e tre gli elementi del controllo. Soprattutto considerando che sono strettamente interconnessi tra loro e con altre parti del sistema aziendale.

La prima cosa che non va sono i numeri. Ce ne sono pochi e sono di bassa qualità.

Una parte significativa dei numeri proveniva allora dal sistema informativo 1C. Ebbene, la qualità dei numeri in 1C, come affermava, è inaccettabile. Almeno, a causa della possibilità di modificare i dati retroattivamente.

È chiaro che la colpa non è degli sviluppatori di 1C — essi si limitano a soddisfare le esigenze del mercato e la mentalità della contabilità domestica. Ma per scopi di controllo, sarebbe meglio cambiare i principi di lavoro di 1C con i dati, all'interno dell'azienda specifica.

Successivamente, i numeri da 1C, secondo lui, subiscono un elaborazione semi-artigianale, utilizzando Excel, ad esempio. Tale elaborazione non aggiunge né qualità né rapidità ai dati.

Alla fine, il report finale viene ancora verificato da qualcun altro, per non presentare accidentalmente al dirigente numeri errati. Di conseguenza, i numeri arrivano al destinatario belli, verificati, ma molto tardi. Di solito — dopo la fine del periodo (mese, settimana, ecc.).

E qui, ha detto, tutto è molto semplice. Se i dati di gennaio ti arrivano a febbraio, non puoi più gestire le attività di gennaio. Perché gennaio è già finito.

E se i numeri sono basati sulla contabilità, e l'azienda è una normale, con la dichiarazione IVA trimestrale, il suo dirigente riceve dati abbastanza coerenti una volta al trimestre.

Poi è chiaro. Ricevi i dati una volta al mese - hai la possibilità di gestire in base ai dati (cioè effettuare il controllo) 12 volte l'anno. Se pratichi la rendicontazione trimestrale - gestisci 4 volte all'anno. Inoltre, come bonus, la rendicontazione annuale. Un'altra occasione di gestione.

Il resto del tempo, la gestione, di norma, avviene alla cieca.

Quando (e se) i dati compaiono, entra in gioco il secondo problema: come gestire in base ai dati? Su questo punto delle sue riflessioni non sono riuscito a concordare.

Il ragazzo sosteneva che se un manager non aveva mai avuto numeri prima, la loro comparsa genererebbe un effetto wow. Inizierà a guardare e a manipulare i dati in vari modi, convocando le persone per chiedere spiegazioni e avviare indagini. Dopo aver giocato con i numeri e fatto analisi, promettendo minacciosamente a tutti i dipendenti che "ora non vi lascerò più", il manager si calmerà rapidamente e abbandonerà il tutto. Smollerà di usare lo strumento. Ma i problemi rimarranno invariati.

Questo accade, diceva, a causa delle competenze insufficienti del manager. In particolare, nel controllo. Il manager semplicemente non sa come gestire questi numeri. Cosa confare — lo sa, ma non sa come farlo. Fare — è ciò di cui si è parlato sopra (litigare, giocare). Lavorare — è un processo aziendale quotidiano.

Sosteneva che tutto fosse molto semplice: il numero deve diventare parte del processo aziendale. Nel processo aziendale deve essere chiaro: chi, cosa e quando deve agire in caso di deviazione del numero dalla norma (qualsiasi opzione — sopra il limite, sotto il limite, uscita dal corridoio, presenza di tendenze, non raggiungimento del quartile, ecc.)

Ecco, ha evidenziato una dilemma cruciale: i dati ci sono, devono diventare parte del sistema aziendale per migliorare l'efficienza della gestione, ma... questo non accade. Perché?

Perché il leader russo non cederà un pezzo del proprio potere al concorrente.

I concorrenti del leader russo sono un processo aziendale di qualità e funzionante, una motivazione ben congegnata e la corretta automatizzazione, che purtroppo lasceranno il leader senza lavoro.

È una follia, non credete? Soprattutto riguardo ai leader. Va bene, ho raccontato, decidete voi.

Un po' meno, ma comunque troppo, secondo me, ha parlato dello Scrum.

Assolutamente, ha detto, leggete e provate a mettere in pratica lo Scrum. Se, dice, avete letto ma non provato - considerate di non sapere. È meglio leggere un libro, ad esempio quello di Sutherland, piuttosto che articoli e vari guide (che cavolo sono?) su Internet.

Lo Scrum, ha detto, si apprende solo con la pratica e con misurazioni obbligatorie del lavoro svolto. Provate personalmente i due ruoli più importanti: quello del Product Owner e dello Scrum Master.

È particolarmente importante, secondo il ragazzo, esperire praticamente il ruolo di scrum master, quando si riesce ad aumentare il numero di compiti completati in uno sprint, senza aumentare le risorse e il costo dello sprint.

Un'altra raccomandazione nel suo elenco era la TOC (Teoria dei Vincoli).

Questi, secondo il ragazzo, sono principi basilari e fondamentali per migliorare l'efficienza, applicabili praticamente a qualsiasi ambito, in ogni processo e sistema aziendale in generale.

Quando ha scoperto che non conoscevamo la TOC, ha smesso di parlarne. Ha solo aggiunto che non ci priverebbe del piacere di leggere i libri di Eliyahu Goldratt. Ha dato una raccomandazione simile a quella dello scrum: leggete e provate. Insomma, qualunque sia il vostro ruolo, qualunque lavoro stiate svolgendo, troverete un'opportunità per migliorare l'efficienza attraverso i metodi della TOC.

Poi, sembra che il suo bagaglio di metodologie si sia esaurito, e ha detto: mescolate i principi per creare soluzioni applicative in situazioni specifiche.

Questa, afferma, è la raccomandazione principale, la chiave del successo. Comprendete i principi, l'essenza, e create soluzioni applicative uniche: processi e sistemi aziendali.

Poi cercò di ricordare una citazione, e alla fine dovette andare su Internet. Si scoprì che la citazione era tratta dall'articolo "In piedi sulle spalle di giganti" di Eliyahu Goldratt:

"C'è una differenza tra soluzioni applicative e concetti fondamentali su cui si basano queste soluzioni. I concetti sono generali, le soluzioni applicative sono un'adattamento dei concetti a un contesto specifico. Come abbiamo già visto, tale adattamento non è semplice e richiede lo sviluppo di determinati elementi di soluzione. Dobbiamo ricordare che una soluzione applicativa si basa su presupposti iniziali (a volte nascosti) riguardanti un contesto specifico. Non bisogna aspettarsi che questa soluzione applicativa funzioni in un contesto per il quale i presupposti iniziali non sono validi."

Disse che il lavoro di un programmatore e quello di un "miglioratore dei processi aziendali" sono molto simili. E se ne andò.

Fonte: habr.com