Di un ragazzo

Una storia reale, ho visto tutto con i miei occhi.

Per diversi anni, un ragazzo, come molti di voi, ha lavorato come programmatore. Siccome è importante, lo dirò così: "programmatore". Perché era un esperto di 1C, su contratto, in una società di produzione.

Prima di questo, ha provato diverse specialità: 4 anni come programmatore in franchising, project manager, era in grado di chiudere 200 ore, ricevendo contemporaneamente una percentuale dal progetto, per la gestione e occupandosi un po' di vendite. Ha provato a sviluppare prodotti autonomamente, è stato il capo del dipartimento IT in una grande azienda con 6.000 dipendenti, ha esplorato diverse varianti dell'applicazione della sua professione quotata – programmatore 1C.

Ma tutte queste posizioni si rivelavano piuttosto senza sbocco, innanzitutto per quanto riguarda il reddito. All'epoca, guadagnavamo più o meno tutti le stesse somme, lavorando nelle stesse condizioni.

Questo ragazzo era curioso di scoprire come guadagnare più soldi, senza occuparsi di vendite e senza creare un proprio business.

Si era convinto di essere un genio e decise di trovare una nicchia nella sua azienda. Questa nicchia doveva essere speciale, non occupata da nessuno. E voleva che l'azienda stessa volesse pagare denaro a una persona in questa nicchia, senza dover ingannare nessuno o architettare qualcosa. Doveva essere oggettivo: una persona in questa posizione doveva guadagnare molto.

Le ricerche non durarono a lungo. Nella società in cui lavorava questo ragazzo, c'era una nicchia completamente libera, che si poteva definire "organizzazione dei processi aziendali". In ogni azienda ci sono tantissimi problemi. C'è sempre qualcosa che non funziona e non c'è nessuno che venga a sistemare i processi aziendali. Così, decise di mettersi alla prova come esperto in grado di aiutare il proprietario a risolvere i suoi problemi.

Al momento lavorava in azienda da sei mesi e riceveva una retribuzione media sul mercato. Non aveva nulla da perdere, soprattutto perché avrebbe potuto trovare lo stesso lavoro in una settimana. In sintesi, questo ragazzo pensò che non sarebbe successo nulla di terribile se per caso tutto fosse andato male e lo avessero licenziato.

Si è fatto coraggio ed è andato dal proprietario. Gli ha proposto di migliorare il processo più problematico che esisteva in azienda. A quel tempo si trattava della gestione del magazzino. Oggi chi lavora in questa azienda prova persino imbarazzo a ricordare quei problemi, ma le inventarizzazioni trimestrali mostrano discrepanze tra il sistema contabile e le giacenze reali di decine di punti percentuali. Sia in valore che in quantità, e in numero di posizioni. Era un disastro. L'azienda aveva correttamente le giacenze nel sistema contabile solo quattro volte all'anno – il giorno dopo l'inventario. Questo processo è quello che il nostro ragazzo ha iniziato a sistemare.

Il ragazzo ha concordato con il proprietario di ridurre le discrepanze nei risultati degli inventari della metà. Inoltre, il proprietario non aveva molto da perdere, perché prima del nostro eroe avevano già tentato di sistemare le cose diversi dipendenti, e in generale il compito era considerato quasi impossibile. Tutto ciò ha acceso molto interesse, perché se tutto fosse andato a buon fine, il tizio sarebbe automaticamente diventato una persona capace di mettere ordine e risolvere compiti irrisolvibili.

Così, si trovò di fronte all'obiettivo: ridurre nel corso dell'anno le discrepanze nei risultati degli inventari di 2 volte. All'inizio del progetto non sapeva come ottenere questo, ma capiva che la gestione del magazzino è una cosa semplice, quindi in qualche modo sarebbe riuscito a fare qualcosa di utile. Tanto più che ridurre le discrepanze da decine di punti percentuali a una decina di punti percentuali non dovrebbe essere così difficile. Tutti coloro che lavorano nel campo della consulenza o attività simili sanno che la maggior parte dei problemi di processo può essere risolta con azioni piuttosto semplici.

Da gennaio a maggio si è preparato, ha automatizzato un po' di cose, ha riscritto il processo di contabilità di magazzino, ha cambiato i flussi di lavoro di magazzinieri, contabili e ha completamente ristrutturato il sistema, senza mostrare e raccontare nulla a nessuno. A maggio ha distribuito a tutti nuove istruzioni e dopo il primo inventario dell'anno è iniziata una nuova vita – lavoro secondo le sue regole. Per vedere i risultati, in seguito l'azienda ha iniziato a effettuare inventari più frequentemente – ogni due mesi. I primi risultati sono stati positivi e entro la fine dell'anno le deviazioni dei risultati dell'inventario sono scese a frazioni di un percento.

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

Allora ha deciso di ripetere l'esperimento e ha proposto al proprietario di perfezionare un altro processo problematico – l'approvvigionamento. C'erano carenze che non permettevano di spedire i volumi che i nostri clienti volevano. Si sono accordati che entro un anno le carenze si sarebbero ridotte della metà e che il ragazzo avrebbe anche portato a termine 10-15 progetti legati a 1C, ovvero all'automazione di vari processi aziendali e altre sciocchezze.

Nel secondo anno il tutto è stato nuovamente portato a termine con successo, le carenze sono calate di più di 2 volte e tutti i progetti IT sono stati conclusi con successo.

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

Cosa rappresentava? Formalmente, era il direttore IT. Ma capire chi fosse realmente è complicato. Infondo, di cosa si occupa un direttore IT? Di solito amministra l'infrastruttura IT, gestisce gli amministratori di sistema, implementa il sistema ERP e partecipa alle riunioni del consiglio di amministrazione.

E questo tizio aveva come una delle sue principali responsabilità la partecipazione ai processi di cambiamento, e principalmente — la generazione e l'avvio di questi processi, la ricerca e proposta di soluzioni, l'applicazione di nuove metodologie di gestione, la valutazione delle modifiche proposta, l'analisi dell'efficacia di altre funzioni e divisioni, e infine — la partecipazione diretta allo sviluppo strategico dell'azienda, fino alla stesura autonoma del piano strategico dell'intera compagnia.

Gli è stato dato carta bianca. Poteva partecipare a qualsiasi riunione a cui prima non aveva accesso. Si sedeva lì con un taccuino, scriveva qualcosa o semplicemente ascoltava. Parlava raramente. Poi ha cominciato a giocare col telefono — sosteneva che così la memoria associativa funzionava meglio.

In riunione raramente dava qualcosa di utile. Usciva, rifletteva, poi riceveva una lettera — o con critiche, o con opinioni, o con proposte, o con la descrizione di soluzioni che aveva già applicato.

Ma più spesso organizzava lui stesso le riunioni. Trovava un problema, pensava a opzioni di soluzione, identificava le parti interessate e portava tutti in sala riunioni. E lì — come sapeva fare. Convinceva, motivava, dimostrava, litigava, otteneva.

Ufficialmente era considerato la terza persona in azienda, dopo il proprietario e il direttore. Naturalmente, era estremamente fastidioso per tutti i "volti dell'azienda", a partire dal numero 4. Soprattutto per i suoi jeans strappati e le t-shirt colorate, e ancora — per il tempo del proprietario.

Il proprietario gli dedicava 1 ora al giorno. Ogni giorno. Parlavano, discutevano di problemi, soluzioni, nuovi affari, direzioni di sviluppo, indicatori ed efficienza, sviluppo personale, libri, e semplicemente — della vita.

Ma questo ragazzo era strano. Sembrerebbe — siedi e goditi, la vita è andata bene. Ma no. Ha deciso di riflettere.

Gli è venuto in mente: perché a lui è riuscito, mentre agli altri no? Anche il proprietario lo spronava: 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 occupa di cambiamenti sistematici nei propri processi. Nella loro descrizione del lavoro, può darsi che sia scritto che devono accelerare il proprio processo, aumentarne l'efficacia, ma di fatto nessuno se ne occupa. Perché? Anche a quel ragazzo è venuta curiosità, e ha deciso di parlare con tutti quei manager.

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

È andato da un altro vice direttore e ha proposto di introdurre il controllo. Ma anche qui non ha trovato supporto. Poco dopo ha appreso della gestione delle frontiere (boundary management) e ha proposto a tutti i vice direttori di implementare la parte sistematica di questa metodica per migliorare i processi. Ma per quanto ci ha parlato, nessuno sembrava interessato a capire di cosa si trattasse. Forse non era interessante per loro o troppo complicato. In effetti, nessuno ha compreso.

In sintesi, ha raccontato tutto ciò che sapeva e applicava in azienda. Ma nessuno lo ha compreso davvero. E fino ad ora non capiscono perché, ad esempio, sia stato possibile correggere la contabilità di magazzino, cosa c’entri il controllo e la gestione delle frontiere.

Alla fine, è arrivato ai suoi programmatori – il team era composto da 3 persone. Ha parlato di gestione delle frontiere, del controllo, della gestione della qualità, di agile e scrum… E con sorpresa, hanno capito tutto e hanno persino potuto discutere con lui, comprese le complessità tecniche e metodologiche. Hanno capito perché i progetti di magazzino e di approvvigionamento erano riusciti. E lì il ragazzo ha avuto un’illuminazione: in realtà, il mondo sarà salvato dai programmatori.

Ha capito che i programmatori sono gli unici in grado di comprendere a fondo e con i dettagli necessari i processi aziendali.

Perché proprio loro? In realtà, non ha mai trovato una risposta definitiva. Ha solo formulato alcune allusioni tese.

In primo luogo, i programmatori conoscono le aree tematiche del business, e per di più, le conoscono meglio di chiunque altro nella compagnia.

Inoltre, i programmatori capiscono realmente cosa sia un algoritmo di processo. Questo è importante perché i processi aziendali sono algoritmi, e gli elementi al loro interno possono essere semplicemente non allineati. Ad esempio, nel processo di approvvigionamento su cui lavorava il ragazzo, il primo passo è la redazione del piano annuale degli acquisti, mentre il secondo è l'acquisto quotidiano. Questi passaggi sono collegati da un legame diretto, quindi si presume che secondo questo algoritmo le persone debbano lavorare: redigere il piano annuale degli acquisti e immediatamente eseguire l'ordine. Il piano annuale degli acquisti viene redatto una volta all'anno, mentre l'ordine può arrivare fino a 50 volte al giorno. Qui finisce l'algoritmo e bisogna lavorare su di esso. In effetti, ha ragionato, per i programmatori conoscere gli algoritmi è un vantaggio competitivo, poiché chiunque altro che non li conosce semplicemente non comprende come dovrebbe funzionare il processo aziendale e come possa essere rappresentato.

Un altro vantaggio dei programmatori, secondo il ragazzo, è che hanno abbastanza tempo libero. Tutti comprendiamo come un programmatore possa impiegare tre volte il tempo necessario su un compito, e poche persone se ne accorgeranno. Questo, ancora una volta, è un vantaggio competitivo, perché per mettere in ordine un processo aziendale è necessario avere molto tempo libero: pensare, osservare, studiare e provare.

La maggior parte dei manager, secondo il ragazzo, non ha questo tempo libero e ne è fiera. Anche se in realtà significa che una persona non può diventare efficiente, perché non ha tempo per migliorare la propria efficienza: un circolo vizioso. Nella nostra cultura è di moda essere occupati, quindi tutto rimane immobile. E per noi, programmatori, questo è un vantaggio. Possiamo trovare tempo libero e riflettere su tutto.

I programmatori, raccontava, possono cambiare rapidamente un sistema informativo. Non è applicabile a tutte le aziende, ma ovunque abbia lavorato, era possibile apportare qualsiasi modifica si desiderasse. Soprattutto se non riguardava il lavoro di nessun altro. Ad esempio, poteva avviare un sistema che misura segretamente le azioni degli utenti e poi utilizzare queste informazioni per analizzare l'efficacia del lavoro della contabilità e monitorare i costi di gestione della contabilità.

E infine, ciò che ho ricordato dalle sue parole è che i programmatori hanno accesso a un'enorme quantità di informazioni, poiché hanno accesso amministrativo al sistema. Pertanto possono utilizzare queste informazioni nella loro analisi. Nessun altro in una normale fabbrica ha accesso a 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 svolgeva. E la sua posizione stava diventando vacante.

Per alcuni giorni lo abbiamo fatto sedere su una sedia, accendevamo la telecamera e registravamo i suoi monologhi. Gli chiedevamo di parlare di tutti i progetti completati, dei metodi, degli approcci, dei successi e dei fallimenti, delle cause e degli effetti, dei profili dei dirigenti, ecc. Non lo limitavamo troppo, poiché non sapevamo cosa avesse in mente.

Nei monologhi, c'era ovviamente soprattutto spazzatura e risate — era di ottimo umore, poiché stava lasciando un paesino per San Pietroburgo. E dove andare a lavorare a San Pietroburgo? In Gazprom, ovviamente.

Ma ci sono state alcune informazioni utili che siamo riusciti a estrarre dai suoi monologhi. Vi racconterò ciò che ricordo.

Quindi, i consigli di quel ragazzo. A chi vorrà provare a sistemare le cose nei processi aziendali.

Per fare un lavoro del genere, prima di tutto, è necessario avere un certo livello di 'indifferenza'. Non bisogna avere paura di perdere il lavoro, non aver paura di rischiare, non aver paura dei conflitti con i colleghi. Lui ci riusciva facilmente, perché ha iniziato il suo percorso dopo aver lavorato in azienda solo sei mesi e non ha avuto il tempo di entrare in contatto con nessuno, né intendeva farlo. Comprendeva che le persone vengono e vanno, e per lui erano importanti i propri risultati e la loro valutazione da parte del proprietario dell'azienda. Se i colleghi lo trattavano bene o male, a lui importava poco in quel momento.

Il secondo punto è che, per svolgere efficacemente questo lavoro, purtroppo, bisogna imparare. Ma non imparare attraverso un MBA, corsi o istituti, bensì in modo autonomo. Ad esempio, nel suo primo progetto sul magazzino, ha agito istintivamente, non sapeva nulla, solo che cosa fosse la "gestione della qualità".

Quando ha iniziato a leggere la letteratura riguardo ai metodi di aumento dell'efficienza, ha scoperto le tecnologie che applicava. Il ragazzo le applicava in modo istintivo, ma si è reso conto che non erano una sua invenzione, era tutto già stato scritto da tempo. Tuttavia, ha perso tempo, molto di più rispetto a se avesse letto subito il libro giusto. Qui è importante capire che quando si studia una metodologia specifica, nessuna di esse, nemmeno la più avanzata, risolverà completamente tutti i problemi del processo aziendale.

Il secondo punto è che più metodologie si conoscono, meglio è. Ad esempio, nell'antico Giappone viveva Miyamoto Musashi, uno dei più noti schermidori, autore dello stile delle due spade. Ha studiato in qualche scuola con un maestro, poi ha viaggiato per il Giappone, combattendo contro vari avversari. Se un avversario era più forte, il viaggio si interrompeva per un po' e Musashi diventava allievo. Così, in pochi anni, acquisiva competenze in varie pratiche di diversi maestri e formava la propria scuola, aggiungendo qualcosa di suo. Alla fine, ha raggiunto una maestria unica. Qui è lo stesso.

Certo, si può agire come consulenti aziendali. In generale, sono ottimi ragazzi. Ma, di solito, arrivano per implementare qualche metodologia, e non quella necessaria per l'azienda. Anche noi abbiamo avuto situazioni tristi: nessuno sa come risolvere il problema e nessuno vuole pensare a come farlo. Iniziamo a cercare in internet oppure chiamiamo un consulente, e gli chiediamo cosa possa aiutarci. Il consulente riflette e dice che bisogna implementare la teoria dei vincoli. Gli paghiamo per la raccomandazione, spendiamo per l'implementazione, ma il risultato è zero.

Perché succede così? Perché il consulente ha detto di implementare un certo sistema, e tutti hanno acconsentito. Benissimo, ma una metodologia non risolve tutti i problemi nemmeno di un singolo processo aziendale, specialmente se non coincidono le condizioni di partenza — le nostre e quelle richieste per l'implementazione della metodologia.

Nella pratica che il ragazzo consiglia, bisogna prendere il meglio e implementare il meglio. Non prendere i metodi nella loro interezza, ma cogliere le loro caratteristiche chiave, peculiarità e pratiche. E la cosa più importante è capire l'essenza.

Prendiamo, diceva lui, ad esempio Scrum o Agile. Nelle sue dissertazioni, il ragazzo ha ripetuto molte volte che non tutti comprendono appieno l'essenza di Scrum. Anche lui ha letto il libro di Jeff Sutherland, che ad alcuni sembra una 'lettura leggera'. A lui è sembrato una lettura profonda, perché uno dei principi fondamentali di Scrum è la gestione della qualità, di cui si parla esplicitamente nel libro.

Lì si parla della Toyota Production, di come Jeff Sutherland ha presentato Scrum in Giappone, di quanto si sia radicato lì e di quanto fosse vicino alla loro filosofia. E Sutherland ha parlato dell'importanza del ruolo del Scrum Master, del ciclo di Deming. Il ruolo dello Scrum Master è quello di accelerare costantemente il processo. Tutto il resto che c'è in Scrum — consegne per fasi, soddisfazione del cliente, un elenco chiaro delle attività per il periodo dello sprint — è importante, ma tutto deve procedere sempre più velocemente. La velocità del lavoro deve aumentare continuamente nelle unità in cui viene misurata.

Forse, qui il problema è nella traduzione, perché da noi il libro è stato tradotto come 'Scrum - un metodo rivoluzionario di gestione dei progetti', ma se traduciamo letteralmente il titolo inglese, diventa: 'Scrum - il doppio in metà tempo', quindi anche nel titolo c'è un riferimento alla velocità, come funzione chiave di Scrum.

Quando questo ragazzo ha implementato Scrum, nella prima settimana la velocità è raddoppiata senza particolari cambiamenti. Ha trovato punti per modificare, ha adattato Scrum a sé stesso, in modo che funzionasse molto più velocemente. L'unica cosa, come si legge su Internet, è che si sono trovati di fronte alla questione: 'Abbiamo raddoppiato la velocità, rimane da capire cosa fare con tale velocità?'. Tuttavia, questa è un'altra area completamente diversa...

Inoltre, ha personalmente consigliato diverse metodologie. Le ha definite fondamentali e fondamentali.

La prima è il boundary management.

Viene insegnato a "Skolkovo", altre pubblicazioni e materiali, secondo quanto afferma il ragazzo, non ci sono. È riuscito a partecipare a una lezione di un professore di Harvard, che predica il boundary management, e ha anche letto alcuni articoli del Harvard Business Review sui lavori di Eric Trist.

Il boundary management tratta di come saper vedere e lavorare con i confini. I confini sono ovunque: tra dipartimenti, tra diversi tipi di lavoro, tra funzioni, tra lavoro operativo e analitico. La conoscenza del boundary management non rivela verità più elevate, ma permette di vedere la realtà sotto una luce diversa, attraverso la lente dei confini. E, di conseguenza, di gestirli: stabilendoli dove necessario e rimuovendoli dove ostacolano.

Ma più spesso il ragazzo ha parlato di controlling. Aveva davvero una fissa per questo argomento.

Il controlling, in breve, è la gestione basata sui numeri. Qui, ha detto, è importante ogni parte della definizione: sia "gestione", sia "basata su", sia "numeri".

Da noi, ha affermato, siamo messi male con tutti e tre gli elementi del controlling. Specialmente considerando che sono strettamente interconnessi tra di 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 la traevamo allora dal sistema informativo 1C. Ebbene, la qualità dei numeri in 1C, come sosteneva, è inaccettabile. Almeno per via della possibilità di modificare i dati retroattivamente.

È chiaro che non è colpa degli sviluppatori di 1C, che tengono conto solo delle esigenze del mercato e della mentalità della contabilità domestica. Ma per gli scopi del controlling, i principi di lavoro di 1C con i dati dovrebbero essere modificati, a livello dell'impresa specifica.

In seguito, i numeri provenienti da 1C, secondo le sue parole, subiscono un'elaborazione semiautomatica, utilizzando Excel, ad esempio. Tale lavorazione non aggiunge qualità ai dati, né tempestività.

Alla fine, un qualche responsabile rivede il report finale, per evitare di inviare al dirigente numeri errati. Di conseguenza, i numeri arrivano al destinatario in modo bello, controllato, ma molto in ritardo. Di solito — dopo la fine del periodo (mese, settimana, ecc.).

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

E se i numeri si basano sulla contabilità e l'azienda è una comune, con dichiarazioni IVA trimestrali, allora il suo dirigente riceve numeri relativamente adeguati una volta al trimestre.

Dopo è chiaro. Ricevete i numeri una volta al mese: avete la possibilità di gestire in base ai numeri (cioè mettere in atto il controllo) 12 volte all'anno. Praticate la rendicontazione trimestrale: gestite 4 volte all'anno. Inoltre, un bonus: rendicontazione annuale. Possibilità di gestire ancora una volta.

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

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

Il ragazzo sosteneva che se prima il dirigente non aveva numeri, la loro apparizione provocherà un effetto wow. Guarderà e girerà i numeri in tutti i modi, chiamerà le persone e chiederà spiegazioni e indagini. Giocando con i numeri, facendo delle analisi e promettendo minacciosamente a tutti i dipendenti che 'adesso non vi lascerò in pace', il dirigente si calmerà rapidamente e lascerà perdere. Non utilizzerà più lo strumento. E i problemi rimarranno.

Questo accade, diceva, a causa della mancanza di competenze del dirigente. Soprattutto nel controllo. Il dirigente semplicemente non sa cosa fare con questi numeri. Cosa confare - sa, cosa fare - no. Fare - è ciò di cui si è scritto sopra (litigare, giocare). Fare - è un processo aziendale quotidiano.

Sosteneva che tutto era molto semplice: il numero deve diventare parte del processo aziendale. Nel processo aziendale deve essere chiaro: chi, cosa e quando deve fare in caso di deviazione del numero dalla norma (qualsiasi variante - sopra i confini, sotto i confini, uscita dal corridoio, presenza di tendenze, mancato rispetto del quantile, ecc.)

Ecco che ha delineato il dilemma cruciale: il numero c'è, deve diventare parte del sistema aziendale per migliorare l'efficacia della gestione, ma... questo non accade. Perché?

Perché il dirigente russo non cederà un pezzo del suo potere al concorrente.

I concorrenti del dirigente russo - un processo aziendale di qualità e funzionante, una motivazione reciproca ben ponderata e una corretta automazione - purtroppo, lasceranno il dirigente senza lavoro.

Qualcosa di assurdo, ammettetelo? Soprattutto riguardo ai leader. Va bene, vi ho raccontato, decidete voi.

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

Assolutamente, ha detto di leggere e provare Scrum nella pratica. Se, dice, avete letto ma non provato, considerate di non sapere. È meglio leggere un libro, ad esempio di Sutherland, piuttosto che articoli e vari guide (che stronzate?) su Internet.

Scrum, ha detto, si comprende solo attraverso la pratica, e con misurazioni obbligatorie del volume di lavoro svolto. Provate personalmente i due ruoli più importanti: il Product Owner e il Scrum Master.

È particolarmente importante, secondo il ragazzo, vivere nella pratica il ruolo di Scrum Master, quando sarete in grado di aumentare il numero di task completati in uno sprint, senza aumentare risorse e costi dello sprint.

E in cima alla sua lista c'era il TOC (Teoria dei Vincoli).

Questi, secondo il ragazzo, sono principi fondamentali per aumentare l'efficienza, applicabili praticamente in qualsiasi area, in qualsiasi processo aziendale e sistema aziendale nel suo complesso.

Quando ha scoperto che non conoscevamo il TOC, ha smesso di raccontare. Ha solo aggiunto che non ci avrebbe privati del piacere di leggere i libri di Eliyahu Goldratt. Ha dato una raccomandazione simile a quella di Scrum: leggete e provate. Tipo, a qualunque posizione vi troviate, qualunque lavoro svolgiate, troverete spazio per migliorare l'efficienza con i metodi del TOC.

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

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

Poi si sforzava di ricordare una citazione, alla fine ha dovuto cercare su Internet. Si è scoperto che la citazione era tratta dall'articolo "Standing on the Shoulders of Giants" di Eliyahu Goldratt:

«C'è una differenza tra soluzioni applicative (applicazioni) e concetti fondamentali su cui si basano queste soluzioni. I concetti sono generali, le soluzioni applicative sono un'adattamento dei concetti a un ambiente specifico. Come abbiamo già visto, tale adattamento non è semplice e rende necessaria la sviluppazione di determinati elementi della soluzione. Dobbiamo ricordare che una soluzione applicativa è basata su ipotesi di partenza (a volte nascoste) relative a un ambiente specifico. Non dobbiamo aspettarci che questa soluzione applicativa funzioni in un ambiente per il quale le ipotesi di partenza non sono valide».

Ha detto che il lavoro di un programmatore e quello di un «miglioratore di processi aziendali» sono molto simili. E se ne è andato.

Fonte: habr.com