La storia è vera, ho visto tutto con i miei occhi.
Per diversi anni, un ragazzo, come molti di voi, ha lavorato come programmatore. Per ogni evenienza, lo scriverò in questo modo: "programmatore". Perché era 1Snik, una società di produzione fissa.
Prima di ciò, ha provato diverse specialità: 4 anni in Francia come programmatore, project manager, è stato in grado di completare 200 ore, ricevendo allo stesso tempo una percentuale del progetto, per la gestione e facendo alcune vendite. Ho provato a sviluppare prodotti da solo, ero a capo del dipartimento IT di una grande azienda con 6mila persone, ho provato diverse opzioni per utilizzare la mia citata professione: programmatore 1C.
Ma tutte queste posizioni erano in qualche modo senza uscita, soprattutto in termini di reddito. A quel tempo ricevevamo tutti più o meno gli stessi soldi e lavoravamo alle stesse condizioni.
Questo ragazzo si chiedeva come avrebbe potuto guadagnare di più senza vendere o creare una propria attività.
Si considerava un ragazzo intelligente e decise di trovare una nicchia nell'azienda in cui lavorava. Questa nicchia doveva essere qualcosa di speciale, non occupata da nessuno. E volevo che l'azienda stessa volesse pagare soldi a una persona in questa nicchia, in modo che non ci fosse bisogno di ingannare nessuno o imbrogliare nulla. Per raggiungere questo obiettivo: una persona in questa posizione deve essere pagata molto denaro. Un eccentrico, in una parola.
La ricerca fu di breve durata. Nell'azienda in cui lavorava questo ragazzo, c'era una nicchia completamente libera che poteva essere chiamata "mettere le cose in ordine nei processi aziendali". Ogni azienda ha molti problemi. Qualcosa non funziona sempre e non c'è nessuno che venga a sistemare il processo aziendale. Quindi, ha deciso di mettersi alla prova come specialista in grado di aiutare il proprietario a risolvere i suoi problemi nei processi aziendali.
A quel tempo lavorava per l'azienda da sei mesi e riceveva lo stipendio medio del mercato. Non c'era niente da perdere, soprattutto perché avrebbe potuto facilmente trovare lo stesso lavoro nel giro di una settimana. In generale, questo ragazzo ha deciso che non sarebbe successo nulla di brutto se all'improvviso non avesse funzionato nulla e fosse stato licenziato.
Si fece coraggio e andò dal proprietario. Gli ho suggerito di migliorare il processo più problematico dell'azienda. A quel tempo era la contabilità di magazzino. Ora tutti coloro che lavorano in questa azienda si vergognano persino di ricordare quei problemi, ma gli inventari, effettuati trimestralmente, hanno mostrato discrepanze tra il sistema contabile e i saldi effettivi di decine di punti percentuali. E in termini di costi, quantità e numero di posizioni. È stato un disastro. In realtà l'azienda disponeva dei saldi corretti nel sistema contabile solo quattro volte all'anno, il giorno successivo al conteggio dell'inventario. Il nostro ragazzo ha iniziato a mettere in ordine questo processo.
Il ragazzo ha concordato con il proprietario di ridurre della metà le deviazioni dai risultati dell'inventario. Inoltre, il proprietario non aveva niente di speciale da perdere, perché prima del nostro eroe vari operai avevano già tentato di sistemare tutto, e in generale il compito era considerato praticamente irrisolvibile. Tutto ciò ha notevolmente alimentato l'interesse, perché se tutto funzionasse, il ragazzo diventerebbe automaticamente una persona che sa come mettere le cose in ordine e risolvere problemi irrisolvibili.
Quindi, si è trovato di fronte al compito: ridurre le deviazioni in base ai risultati dell'inventario di 2 volte in un anno. All'inizio del progetto non aveva idea di come raggiungere questo obiettivo, ma sapeva che la contabilità di magazzino è una cosa semplice, quindi avrebbe comunque potuto fare qualcosa di utile. Inoltre, ridurre gli scostamenti da decine di punti percentuali a un decimo di punto percentuale non sembra essere così difficile. Chiunque abbia lavorato nella consulenza o in attività simili comprende che la maggior parte dei problemi di processo possono essere risolti con passaggi abbastanza semplici.
Da gennaio a maggio ha preparato, automatizzato un po 'qualcosa, riscritto il processo aziendale di contabilità di magazzino, cambiato i flussi di lavoro dei magazzinieri, dei contabili e in generale ha rifatto l'intero sistema, senza mostrare né dire nulla a nessuno. A maggio ha distribuito nuove istruzioni a tutti e, dopo il primo inventario dell'anno, è iniziata una nuova vita, lavorando secondo le sue regole. Per osservare i risultati, in futuro l'azienda ha iniziato a condurre inventari più spesso, una volta ogni due mesi. Già i primi risultati erano positivi e alla fine dell'anno gli scostamenti dai risultati dell'audit erano scesi a una frazione dell'XNUMX%.
Il successo è stato colossale, ma non si poteva credere nella sua sostenibilità. Il ragazzo stesso dubitava che il risultato sarebbe stato preservato se si fosse fatto da parte e avesse smesso di osservare il processo. Tuttavia, il risultato è stato raggiunto e il ragazzo ha ricevuto tutto ciò che aveva concordato con il proprietario. Quindi, dopo diversi anni, la stabilità del risultato è stata confermata: per diversi anni le deviazioni sono rimaste entro l'1%.
Poi ha deciso di ripetere l'esperimento e ha suggerito al proprietario di migliorare un altro processo problematico: la fornitura. Si sono verificate carenze che non ci hanno permesso di spedire i volumi desiderati dai nostri clienti. Abbiamo concordato che entro un anno i deficit sarebbero stati dimezzati e il ragazzo avrebbe anche completato 10-15 progetti relativi a 1C - per automatizzare vari processi aziendali e altre eresie.
Nel secondo anno, tutto è stato completato di nuovo con successo, i deficit sono diminuiti di oltre 2 volte, tutti i progetti IT sono stati completati con successo.
Poiché lo stipendio soddisfaceva già pienamente tutte le esigenze di quel ragazzo con due anni di anticipo, decise di sistemarsi un po', calmarsi e sedersi in un luogo accogliente e caldo che si era creato.
Com'era? Formalmente era il direttore IT. Ma chi fosse veramente è difficile da capire. Dopo tutto, cosa fa un direttore IT? Di norma amministra l'infrastruttura IT, gestisce gli amministratori di sistema, implementa un sistema ERP e partecipa alle riunioni del consiglio di amministrazione.
E questo ragazzo aveva una delle responsabilità chiave di partecipare ai processi di cambiamento, e principalmente: generazione, avvio di questi processi, ricerca e proposta di soluzioni, applicazione di nuove tecniche di gestione, esame dei cambiamenti proposti, analisi dell'efficacia di altre funzioni e divisioni e, infine, la partecipazione diretta allo sviluppo strategico dell'impresa, fino allo sviluppo autonomo di un piano strategico per l'intera azienda.
Gli è stata data carta bianca. Poteva venire a qualsiasi riunione a cui non aveva avuto accesso in precedenza. Mi sono seduto lì con un blocco note, scrivendo qualcosa o semplicemente ascoltando. Parlava raramente. Poi ha cominciato a giocare al telefono, sostenendo che così la memoria associativa funziona meglio.
Durante l'incontro raramente forniva qualcosa di utile. Se ne andò, pensò, poi arrivò una lettera: o con critiche, o con un'opinione, o con suggerimenti, o con la descrizione delle soluzioni che aveva già applicato.
Ma più spesso convocava lui stesso le riunioni. Ho trovato un problema, ho trovato soluzioni, ho identificato le parti interessate e ho coinvolto tutti nella riunione. E poi, come meglio poteva. Ha convinto, motivato, dimostrato, argomentato, ottenuto.
Ufficiosamente era considerato la terza persona dell'azienda, dopo il proprietario e direttore. Naturalmente ha fatto infuriare terribilmente tutte le “persone dell'azienda”, a cominciare dal numero 4. Soprattutto con i suoi jeans strappati e le magliette sgargianti, ma anche con il suo tempo da proprietario.
Il proprietario gli ha dato 1 ora al giorno. Ogni giorno. Hanno parlato, discusso di problemi, soluzioni, nuovi business, aree di sviluppo, indicatori ed efficienza, sviluppo personale, libri e semplicemente vita.
Ma questo ragazzo era strano. È come, siediti e sii felice, la vita è bella. Ma no. Decise di riflettere.
Si chiese: perché a lui ha funzionato e ad altri no? Anche il proprietario lo ha spinto: ha detto che voleva che anche gli altri potessero ristabilire l'ordine, perché ci sono tanti manager, loro, di regola, sono impegnati nella gestione operativa e nella pianificazione strategica, ma praticamente nessuno è impegnato in cambiamenti sistemici nei loro processi. Potrebbe essere scritto nella descrizione del loro lavoro che dovrebbero accelerare il loro processo e aumentarne l'efficienza, ma in realtà nessuno lo sta facendo. Perché? Anche il ragazzo si è interessato al perché ed è andato a parlare con tutti questi manager.
Si è rivolto al vicedirettore per la qualità e ha suggerito di introdurre le carte di controllo di Shewhart in modo che 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 il controllo statistico dei processi e aveva solo sentito parlare dell'uso del ciclo di Deming nella gestione della qualità. OK…
Si è rivolto a un altro vicedirettore e gli ha suggerito di introdurre il controllo. Ma non ho trovato supporto neanche qui. Poco dopo, ha appreso della gestione dei confini (gestione dei confini) e ha suggerito che tutti i vicedirettori implementino la parte sistemica di questa metodologia al fine di migliorare i processi. Ma non importa quanto il nostro ragazzo parlasse, nessuno voleva davvero approfondire di cosa si trattasse. Forse non erano interessati o era troppo difficile. Ma in realtà nessuno se ne è accorto.
In generale, ha parlato di tutto ciò che sapeva e utilizzava in azienda. Ma nessuno lo capiva. Ancora non capiscono perché, ad esempio, nella contabilità di magazzino è stato corretto tutto e cosa c’entra il controllo e la gestione delle frontiere.
Infine ha raggiunto i suoi programmatori: lo staff era composto da 3 persone. Ha parlato di gestione dei confini, di controllo, di gestione della qualità, di agile e scrum... E sorprendentemente, hanno capito tutto e sono riusciti in qualche modo anche a discutere con lui, comprese le sottigliezze tecniche e metodologiche. Hanno capito perché i progetti di magazzino e fornitura hanno funzionato. E poi il ragazzo ha capito: infatti, i programmatori salveranno il mondo.
I programmatori, si rese conto, sono gli unici in grado di comprendere normalmente i processi aziendali, con il dettaglio necessario.
Perché loro? In realtà non trovò mai una risposta chiara. Ho formulato solo accenni di tesi.
In primo luogo, i programmatori conoscono gli argomenti dell'azienda e li conoscono meglio di tutte le altre persone dell'azienda.
Inoltre, i programmatori capiscono veramente cos'è un algoritmo di processo. Questo è importante perché i processi aziendali sono algoritmi e gli elementi in essi contenuti potrebbero semplicemente non essere coerenti. Ad esempio, nel processo di approvvigionamento su cui stava lavorando il ragazzo, il primo passo era la creazione di un piano di acquisto annuale e il secondo l'acquisto giornaliero. Questi passaggi sono collegati da una connessione diretta, ovvero si presuppone che le persone lavorino secondo questo algoritmo: redigano un piano di approvvigionamento annuale ed eseguano immediatamente la richiesta. Il piano annuale degli appalti viene redatto una volta all'anno e le domande pervengono 50 volte al giorno. Qui è dove finisce l'algoritmo e devi lavorarci sopra. Infatti, secondo lui, per i programmatori la conoscenza degli algoritmi è un vantaggio competitivo, perché chiunque altro che non li conosce semplicemente non capisce come dovrebbe funzionare un processo aziendale e come può essere rappresentato.
Un altro vantaggio dei programmatori, secondo il ragazzo, è che hanno abbastanza tempo libero. Comprendiamo tutti come un programmatore possa dedicare a un'attività tre volte più tempo di quanto effettivamente richiesto, e pochi se ne accorgeranno. Questo, ancora una volta, è un vantaggio competitivo, perché per mettere in ordine alcuni processi aziendali, è 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 è orgoglioso. Anche se in realtà ciò significa che una persona non può diventare efficace perché non ha tempo per migliorare l'efficienza: un circolo vizioso. Nella nostra cultura è di moda essere occupati, quindi tutto rimane uguale. E per noi programmatori questo è un vantaggio. Possiamo trovare il tempo libero e pensare a tutto.
I programmatori, ha detto, possono cambiare rapidamente un sistema informativo. Questo non è applicabile a tutte le imprese, ma ovunque lavorasse poteva apportare tutte le modifiche che desiderava. Soprattutto se non riguardano il lavoro di nessun altro. Ad esempio, potrebbe lanciare un sistema in grado di misurare segretamente le azioni degli utenti e quindi utilizzare queste informazioni per analizzare l'efficienza dello stesso reparto contabilità e tenere traccia dei costi della contabilità.
E l'ultima cosa che ricordo delle sue parole è che i programmatori hanno accesso a una grande quantità di informazioni, perché... avere accesso amministrativo al sistema. Pertanto, possono utilizzare queste informazioni nella loro analisi. Nessun altro in un normale stabilimento dispone di una tale risorsa.
E poi se n'è andato. Durante le due settimane di detenzione richieste, lo abbiamo costretto a condividere la sua esperienza perché volevamo continuare il lavoro che stava portando avanti. Ebbene, il suo posto è diventato vacante.
Per diversi giorni lo fecero sedere su una sedia, accesero la telecamera e registrarono i suoi monologhi. Ci hanno chiesto di raccontarci tutti i progetti completati, i metodi, gli approcci, i successi e i fallimenti, le cause e gli effetti, i ritratti dei manager, ecc. Non c'erano restrizioni speciali, perché Non sapevano cosa stesse succedendo nella sua testa.
I monologhi, ovviamente, erano per lo più tutti senza senso e risate - era di ottimo umore, perché stava lasciando l'entroterra per San Pietroburgo. Dove dovresti andare a lavorare a San Pietroburgo? A Gazprom, ovviamente.
Ma dai suoi monologhi siamo riusciti a ricavare qualcosa di utile. Ti dirò cosa ricordo.
Quindi, i consigli di quel ragazzo. Per chi vuole provare a mettere ordine nei processi aziendali.
Per fare questo tipo di lavoro, innanzitutto, è necessario avere un certo livello di “congelamento”. Non dovresti aver paura di perdere il lavoro, non aver paura di correre rischi, non aver paura dei conflitti con i colleghi. Per lui è stato facile, perché ha iniziato il suo percorso quando lavorava in azienda da soli sei mesi, e non aveva tempo di entrare in contatto con nessuno, né aveva intenzione di farlo. Ha capito che le persone vanno e vengono, ma per lui sono importanti i suoi risultati e la loro valutazione da parte dell'imprenditore. Allora gli importava poco se i suoi colleghi lo trattassero bene o male.
Il secondo punto è che per poter svolgere efficacemente questo lavoro, purtroppo, dovrai studiare. Ma studia non per un MBA, non nei corsi, non negli istituti, ma da solo. Ad esempio, nel suo primo progetto, un progetto di magazzino, ha agito in modo intuitivo, non sapeva nulla di cosa fosse la “gestione della qualità”.
Quando iniziò a leggere la letteratura sui metodi esistenti per aumentare l'efficienza, scoprì le tecnologie che utilizzava. Il ragazzo li ha applicati in modo intuitivo, ma si scopre che questa non era una sua invenzione, tutto era già stato scritto molto tempo fa. Ma ci ha dedicato del tempo, e molto di più che se avesse letto subito il libro giusto. Qui è importante solo capire che quando si studia una tecnica specifica, nessuna di esse, anche la più avanzata, risolverà completamente tutti i problemi di un processo aziendale.
Il secondo trucco è che più tecniche conosci, meglio è. Ad esempio, nell'antico Giappone viveva Miyamoto Musashi, uno dei più famosi spadaccini, autore dello stile a due spade. Ha studiato in una scuola con qualche maestro, poi ha viaggiato in giro per il Giappone, ha combattuto con ragazzi diversi. Se il ragazzo era più forte, il viaggio si fermava per un po 'e Musashi diventava uno studente. Di conseguenza, nel corso di diversi anni ha acquisito le competenze di varie pratiche di diversi maestri e ha formato la propria scuola, aggiungendo qualcosa di suo. Di conseguenza, ha acquisito un'abilità unica. È lo stesso qui.
Ovviamente puoi agire come consulenti aziendali. In generale, sono ragazzi fantastici. Ma, di regola, arrivano a introdurre un qualche tipo di metodologia e implementano la metodologia sbagliata di cui l'azienda ha bisogno. Abbiamo anche avuto situazioni così tristi: nessuno sa come risolvere il problema e nessuno vuole pensare a come risolverlo. Iniziamo a cercare su Internet o chiamiamo un consulente e gli chiediamo cosa può aiutarci. Il consulente pensa e dice che dobbiamo introdurre la teoria dei vincoli. Lo paghiamo per la sua raccomandazione, spendiamo soldi per l'implementazione, ma i risultati sono zero.
Perché succede questo? Perché il consulente ha detto che stiamo introducendo questo o quel sistema e tutti erano d'accordo con lui. Ottimo, ma una metodologia non copre tutti i problemi nemmeno di un processo aziendale, soprattutto se i prerequisiti iniziali - i nostri e quelli richiesti per implementare la metodologia - non coincidono.
Nella pratica consigliata dal ragazzo, devi prendere il meglio e implementare il meglio. Non prendere i metodi interamente, ma prendi le loro caratteristiche, caratteristiche e pratiche principali. E la cosa più importante è capirne l'essenza.
Prendiamo, ha detto, ad esempio, Scrum o Agile. Nei suoi monologhi, il ragazzo ha ripetuto molte volte che non tutti comprendono appieno l'essenza di Scrum. Ha letto anche il libro di Jeff Sutherland, che alcune persone trovano "lettura leggera". Gli è sembrata una lettura approfondita, perché uno dei principi fondamentali di Scrum è la gestione della qualità, questo è scritto direttamente nel libro.
Racconta della Toyota Production, di come Jeff Sutherland ha mostrato Scrum in Giappone, di come ha messo radici lì e di quanto fosse vicino alla loro filosofia. E Sutherland ha parlato dell'importanza del ruolo dello Scrum Master, del ciclo di Deming. Il ruolo dello Scrum Master è quello di accelerare costantemente il processo. Anche tutto il resto presente in Scrum - consegna graduale, soddisfazione del cliente, un chiaro elenco di lavoro per il periodo dello sprint - è importante, ma tutto ciò deve muoversi sempre più velocemente. La velocità del lavoro deve aumentare costantemente nelle unità in cui viene misurata.
Forse è una questione di traduzione, perché il nostro libro è stato tradotto come "Scrum - un metodo rivoluzionario di gestione dei progetti", e se il titolo inglese viene tradotto letteralmente, risulterà: "Scrum - il doppio nella metà del tempo" , cioè, anche nel nome si fa riferimento alla velocità come funzione chiave di Scrum.
Quando questo ragazzo ha implementato Scrum, la velocità è raddoppiata nel primo mese senza alcun cambiamento significativo. Ha trovato spunti di cambiamento e ha modificato lo stesso Scrum per farlo funzionare molto più velocemente. L'unica cosa che scrivono su Internet è che si sono trovati di fronte alla domanda: "Abbiamo raddoppiato la velocità, non resta che capire cosa stiamo facendo a questa velocità?" Ma questa è un'area completamente diversa...
Inoltre ha consigliato personalmente diverse tecniche. Li ha definiti fondamentali e fondamentali.
Il primo è la gestione dei confini.
Lo insegnano a Skolkovo, secondo il ragazzo non ci sono altri libri e materiali. In qualche modo ha avuto la fortuna di assistere a una conferenza di un professore di Harvard che predica la gestione dei confini e di leggere anche diversi articoli sulla Harvard Business Review sul lavoro di Eric Trist.
La gestione dei confini afferma che è necessario essere in grado di vedere i confini e lavorare con i confini. Ci sono molti confini, sono ovunque: tra i dipartimenti, tra i diversi tipi di lavoro, tra le funzioni, tra il lavoro operativo e quello analitico. La conoscenza della gestione dei confini non rivela verità più elevate, ma ci consente di vedere la realtà sotto una luce leggermente diversa, attraverso il prisma dei confini. E, di conseguenza, gestiscili: erigili dove necessario e rimuovili dove sono d'intralcio.
Ma il più delle volte il ragazzo parlava di controllo. Aveva solo una specie di stranezza su questo argomento.
Controllare, in breve, è una gestione basata sui numeri. Qui, ha detto, ogni parte della definizione è importante: sia "gestione" che "basata su" e "numeri".
Noi, ha detto, non siamo bravi con tutte e tre le componenti del controllo. Soprattutto considerando che sono strettamente interconnessi sia tra loro che con altre parti del sistema imprenditoriale.
La prima cosa brutta sono i numeri. Ce ne sono pochi e sono di bassa qualità.
Abbiamo quindi preso una parte significativa dei numeri dal sistema informativo 1C. Quindi, la qualità dei numeri in 1C, come ha affermato, non è buona. Come minimo, a causa della possibilità di modificare i dati retroattivamente.
È chiaro che ciò non è colpa degli sviluppatori 1C: tengono conto solo delle esigenze del mercato e della mentalità della contabilità nazionale. Ma per scopi di controllo, è meglio cambiare i principi del lavoro 1C con i dati in un'azienda specifica.
Inoltre, secondo lui, i numeri di 1C vengono elaborati in modo semimanuale, ad esempio utilizzando Excel. Inoltre, tale elaborazione non aggiunge qualità ai dati, né efficienza.
Alla fine, qualcun altro ricontrolla il rapporto finale per non inviare accidentalmente al manager cifre con errori. 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 numeri di gennaio ti sono arrivati a febbraio, non potrai più gestire le attività di gennaio. Perché gennaio è già finito.
E se le cifre si basano sulla contabilità e la società è la più ordinaria, con presentazione trimestrale dell'IVA, il suo manager riceve cifre relativamente adeguate una volta al trimestre.
Il resto è chiaro. Ricevi i numeri una volta al mese: hai l'opportunità di gestire in base ai numeri (ovvero il controllo) 12 volte all'anno. Se pratichi il reporting trimestrale, lo gestisci 4 volte l'anno. Più un bonus: rendicontazione annuale. Sterza ancora una volta.
Il resto del tempo, il controllo viene solitamente eseguito alla cieca.
Quando (e se) i numeri compaiono, allora entra in gioco il secondo problema: come gestire la situazione in base ai numeri? Non potevo essere d'accordo con questo punto del suo ragionamento.
Il ragazzo ha affermato che se il manager non avesse avuto i numeri prima, il loro aspetto avrebbe causato un effetto wow. Guarderà e stravolgerà i numeri di qua e di là, chiamerà la gente sul tappeto, pretenderà spiegazioni e accertamenti. Dopo aver giocato con i numeri, condotto analisi e promesso minacciosamente a tutti i dipendenti che "ora non mi libererò di te", il manager si calmerà molto rapidamente e rinuncerà a questa questione. Smetti di usare lo strumento. Ma i problemi rimarranno.
Ciò accade, ha detto, a causa di competenze manageriali insufficienti. Nel controllare, innanzitutto. Il manager semplicemente non sa cosa fare con questi numeri. Che cosa сfare - sa cosa fare - no. Fare è quanto scritto sopra (litigare, giocare). Fare è un processo aziendale quotidiano.
Sosteneva che tutto è molto semplice: il digitale deve diventare parte del processo aziendale. Nel processo aziendale dovrebbe essere chiaramente chiaro: chi dovrebbe fare cosa e quando se i numeri si discostano dalla norma (qualsiasi opzione - sopra il confine, sotto il confine, andare oltre il corridoio, presenza di una tendenza, mancato rispetto dei quantile, ecc.)
E così ha delineato il dilemma chiave: il numero esiste, dovrebbe entrare a far parte del sistema aziendale per aumentare l'efficienza gestionale, ma... questo non sta accadendo. Perché?
Perché il leader russo non cederà una parte del suo potere a un concorrente.
I concorrenti del manager russo - un processo aziendale funzionante e di alta qualità, una motivazione reciprocamente vantaggiosa ben ponderata e un'automazione adeguata - ahimè, lasceranno il manager senza lavoro.
Una sciocchezza, non sei d'accordo? Soprattutto sui leader. Ok, te l'ho detto, decidi tu stesso.
Un po' meno, ma comunque troppo, secondo me, ha parlato di Scrum.
Assicurati, ho detto, di leggere e provare Scrum nella pratica. Se, dice, l’hai letto ma non l’hai provato, considerati ignorante. È meglio leggere un libro, ad esempio di Sutherland, piuttosto che articoli e guide di ogni genere (ma che diavolo?) su Internet.
Scrum, ha detto, può essere appreso solo attraverso la pratica e con misurazioni obbligatorie della quantità di lavoro svolto. Prova personalmente i due ruoli più importanti: Product Owner e Scrum Master.
È particolarmente importante, secondo il ragazzo, sperimentare nella pratica il ruolo di Scrum Master, quando è possibile aumentare il volume delle attività completate per sprint senza aumentare le risorse e i costi dello sprint.
Bene, nella sua cima c'era la TOS (teoria delle limitazioni del sistema).
Questi, secondo lui, sono i principi basilari e fondamentali per aumentare l'efficienza che possono essere applicati in quasi ogni ambito, in ogni processo aziendale e sistema aziendale nel suo insieme.
Quando ha scoperto che non conoscevamo TOS, ha smesso di dircelo. Ha solo aggiunto che non ci priverà del piacere di leggere i libri di Eliyahu Goldratt. Ha dato una raccomandazione simile a Scrum: leggilo e provalo. Ad esempio, non importa in quale posizione ti trovi, non importa quale lavoro svolgi, c'è spazio per aumentare l'efficienza utilizzando i metodi TOC.
Poi il suo bagaglio di tecniche apparentemente si è esaurito e ha detto: mescolare i principi per creare soluzioni applicate in una situazione specifica.
Questa, dice, è la raccomandazione principale, la chiave del successo. Comprendere i principi, l'essenza e creare soluzioni applicative uniche: processi aziendali e sistemi aziendali.
Poi ha provato a ricordare qualche citazione e alla fine è dovuto andare online. Si è scoperto che si trattava di una citazione dall'articolo “Standing on the Screws of Giants” di Eliyahu Goldratt:
“C'è una differenza tra le soluzioni applicate (applicazioni) e i concetti fondamentali su cui si basano tali soluzioni. I concetti sono generali; le soluzioni applicate sono l’adattamento dei concetti a un ambiente specifico. Come abbiamo già visto, tale adattamento non è semplice e richiede lo sviluppo di alcuni elementi della soluzione. Dobbiamo ricordare che una soluzione applicativa si basa su presupposti iniziali (a volte nascosti) su un ambiente specifico. Non ci si dovrebbe aspettare che questa soluzione applicativa funzioni in un ambiente per il quale i presupposti non sono corretti”.
Ha affermato che il lavoro di un programmatore e quello di un “miglioratore dei processi aziendali” sono molto simili. E sinistra.
Fonte: habr.com