Tim Lister - coautore di libri
- "Fattore umano. Progetti e team di successo" (il libro originale si intitola "Peopleware")
- "Valzer con gli orsi: gestione del rischio nei progetti software"
- “Impazzito dall’adrenalina e zombificato dagli schemi. Modelli di comportamento dei team di progetto"
Tutti questi libri sono classici nel loro campo e sono stati scritti insieme ai colleghi . In Russia, i suoi colleghi sono più famosi: и , che scrisse anche molte opere famose.
Tim ha 40 anni di esperienza nello sviluppo di software; nel 1975 (nessuno di coloro che hanno scritto questo habrapost è nato quest'anno), Tim era già vicepresidente esecutivo di Yourdon Inc. Ora trascorre il suo tempo consultando, insegnando e scrivendo, con visite occasionali conferenze in tutto il mondo.
Abbiamo fatto un'intervista con Tim Lister appositamente per Habr. Aprirà la conferenza DevOops 2019 e avremo molte domande, sui libri e altro ancora. L'intervista è condotta da Mikhail Druzhinin e Oleg Chirukhin del comitato del programma della conferenza.
Michael: Puoi dire qualche parola su quello che stai facendo adesso?
Tim: Sono il capo della Atlantic Systems Guild. Nella Gilda siamo in sei e ci chiamiamo presidi. Tre negli Stati Uniti e tre in Europa: ecco perché la Gilda si chiama Atlantic. Stiamo insieme da così tanti anni che non puoi contarli. Tutti abbiamo le nostre specialità. Ho lavorato con i clienti negli ultimi dieci anni o più. I miei progetti includono non solo la gestione, ma anche la definizione dei requisiti, la pianificazione del progetto e la valutazione. Sembra che i progetti che iniziano male di solito finiscono male. Pertanto, vale la pena assicurarsi che tutte le attività siano davvero ben pensate e coordinate, che le idee dei creatori siano combinate. Vale la pena pensare a cosa stai facendo e perché. Quali strategie utilizzare per portare a compimento il progetto.
Da molti anni offro consulenza ai clienti in vari modi. Un esempio interessante è un’azienda che produce robot per la chirurgia del ginocchio e dell’anca. Il chirurgo non opera in modo completamente autonomo, ma si avvale di un robot. La sicurezza qui, francamente, è importante. Ma quando provi a discutere i requisiti con persone che si concentrano sulla risoluzione dei problemi... Sembrerà strano, ma negli Stati Uniti c'è (Federal Drug Administration), che concede in licenza prodotti come questi robot. Prima di vendere qualsiasi cosa e usarlo su persone viventi, devi ottenere una licenza. Una delle condizioni è mostrare le tue esigenze, quali sono i test, come li hai testati, quali sono i risultati dei test. Se modifichi i requisiti, dovrai ripetere l'intero enorme processo di test ancora e ancora. I nostri clienti sono riusciti a includere la progettazione visiva delle applicazioni nelle loro esigenze. Avevano screenshot direttamente come parte dei requisiti. Dobbiamo tirarli fuori e spiegare che la maggior parte di questi programmi non sanno nulla di ginocchia e anche, di tutte queste cose con la telecamera, ecc. Dobbiamo riscrivere i documenti relativi ai requisiti in modo che non cambino mai, a meno che non cambino alcune condizioni sottostanti davvero importanti. Se il visual design non rientra nei requisiti, l'aggiornamento del prodotto sarà molto più rapido. Il nostro compito è trovare quegli elementi che riguardano le operazioni al ginocchio, alle anche, alla schiena, estrarli in documenti separati e dire che questi saranno i requisiti fondamentali. Creiamo un gruppo isolato di requisiti relativi alle operazioni al ginocchio. Ciò ci consentirà di creare un insieme di requisiti più stabile. Parleremo dell'intera linea di prodotti e non di robot specifici.
È stato fatto molto lavoro, ma sono comunque arrivati in luoghi dove prima avevano trascorso settimane e mesi di ripetuti test senza significato o necessità, perché i loro requisiti descritti sulla carta non coincidevano con i reali requisiti per i quali i sistemi erano stati costruiti. La FDA glielo diceva ogni volta: le vostre esigenze sono cambiate, ora dovete controllare tutto da zero. Ricontrolli completi dell'intero prodotto stavano uccidendo l'impresa.
Quindi, ci sono compiti meravigliosi quando ti trovi all'inizio di qualcosa di interessante e le primissime azioni stabiliscono le ulteriori regole del gioco. Se ti assicuri che questa prima attività inizi a funzionare bene sia dal punto di vista gestionale che tecnico, c'è la possibilità che ti ritroverai con un grande progetto. Ma se questa parte è andata fuori strada e è andata storta, se non riesci a trovare gli accordi fondamentali... no, non è che il tuo progetto fallirà necessariamente. Ma non potrai più dire: “Abbiamo fatto benissimo, abbiamo fatto tutto in maniera davvero efficace”. Queste sono le cose che faccio quando comunico con i clienti.
Michael: Cioè, lanci progetti, fai una sorta di kickoff e controlli che i binari vadano nella giusta direzione?
Tim: Abbiamo anche idee su come mettere insieme tutti i pezzi del puzzle: quali competenze abbiamo bisogno, quando sono esattamente necessarie, come si presenta il nucleo del team e altre cose fondamentali. Abbiamo bisogno di dipendenti a tempo pieno o possiamo assumere qualcuno part-time? Pianificazione, gestione. Domande come: cosa è più importante per questo particolare progetto? Come raggiungere questo obiettivo? Cosa sappiamo di questo prodotto o progetto, quali sono i rischi e dove si trovano le incognite, come affronteremo tutto questo? Naturalmente, in questo momento qualcuno inizia a gridare “Che ne dici di agile?!” Ok, siete tutti flessibili, ma allora? Come si presenta esattamente il progetto, come lo realizzerai in un modo che si adatti al progetto? Non si può semplicemente dire che “il nostro approccio si estende a qualsiasi cosa, siamo un team Scrum!” Questa è una sciocchezza e una sciocchezza. Dove andrai dopo, perché dovrebbe funzionare, dov’è il punto? Insegno ai miei clienti a pensare a tutte queste domande.
19 anni di agile
Michael: In Agile le persone spesso cercano di non definire nulla in anticipo, ma di prendere decisioni il più tardi possibile, dicendo: siamo troppo grandi, non penserò all’architettura complessiva. Non penserò a un sacco di altre cose; invece, consegnerò qualcosa che funzioni al cliente in questo momento.
Tim: Penso che le metodologie agili, a cominciare da nel 2001, ha aperto gli occhi al settore. Ma d'altra parte, niente è perfetto. Sono favorevole allo sviluppo iterativo. L'iterazione ha molto senso nella maggior parte dei progetti. Ma la domanda a cui devi pensare è: una volta che il prodotto è in uso, quanto dura? È un prodotto che durerà sei mesi prima di essere sostituito da qualcos'altro? Oppure è un prodotto che funzionerà per molti, molti anni? Naturalmente non farò nomi, ma... A New York e nella sua comunità finanziaria, i sistemi fondamentali sono molto vecchi. Questo è sorprendente. Li guardi e pensi, se solo potessi tornare indietro nel tempo, al 1994, e dire agli sviluppatori: "Vengo dal futuro, dal 2019. Sviluppa questo sistema per tutto il tempo necessario. Rendilo espandibile, pensa all'architettura. Verrà poi migliorato per più di venticinque anni. Se ritardi lo sviluppo ancora un po’, nel grande schema delle cose nessuno se ne accorgerà!” Quando fai una stima a lungo termine, devi considerare quanto costerà in totale. A volte vale davvero la pena fare un'architettura ben progettata, a volte no. Dobbiamo guardarci intorno e chiederci: siamo nella situazione giusta per una decisione del genere?
Quindi un'idea del tipo "Siamo a favore dell'agilità, il cliente stesso ci dirà cosa vuole ottenere" è super ingenua. I clienti non sanno nemmeno cosa vogliono e, a maggior ragione, non sanno cosa potrebbero ottenere. Alcune persone inizieranno a citare esempi storici come argomenti, l'ho già visto. Ma le persone tecnicamente avanzate di solito non lo dicono. Dicono: “Siamo nel 2019, queste sono le opportunità che abbiamo e possiamo cambiare completamente il modo in cui guardiamo queste cose!” Invece di imitare le soluzioni esistenti, rendendole un po’ più belle e pettinate, a volte è necessario uscire e dire: “Reinventiamo completamente quello che stiamo cercando di fare qui!”
E non credo che la maggior parte dei clienti possa pensare al problema in questo modo. Vedono solo quello che già hanno, tutto qui. Dopodiché arrivano con richieste del tipo "rendiamo le cose un po' più semplici" o qualunque cosa dicano di solito. Ma non siamo camerieri o cameriere, quindi possiamo prendere un ordine, non importa quanto sia stupido, e poi cuocerlo in cucina. Noi siamo le loro guide. Dobbiamo aprire loro gli occhi e dire: ehi, abbiamo nuove opportunità qui! Ti rendi conto che possiamo davvero cambiare il modo in cui viene svolta questa parte della tua attività? Uno dei problemi dell’Agile è che rimuove la consapevolezza di cosa sia un’opportunità, cosa sia un problema, cosa dobbiamo fare, quali tecnologie disponibili sono più adatte a questa particolare situazione.
Forse sono eccessivamente scettico qui: stanno accadendo molte cose meravigliose nella comunità agile. Ma ho un problema con il fatto che invece di definire un progetto, le persone iniziano ad alzare le mani. Vorrei chiedere qui: cosa stiamo facendo, come lo faremo? E in qualche modo magicamente si scopre sempre che il cliente dovrebbe saperlo meglio di chiunque altro. Ma il cliente sa meglio solo quando sceglie tra cose già costruite da qualcuno. Se voglio comprare un'auto e conosco l'entità del mio budget familiare, selezionerò rapidamente un'auto adatta al mio stile di vita. Qui so tutto meglio di chiunque altro! Ma tieni presente che qualcuno ha già realizzato le auto. Non ho idea di come inventare una nuova macchina, non sono un esperto. Quando creiamo prodotti personalizzati o speciali bisogna tenere conto della voce del cliente, ma questa non è più l'unica voce.
Oleg: Hai menzionato il Manifesto Agile. Dobbiamo in qualche modo aggiornarlo o rivederlo tenendo conto della moderna comprensione del problema?
Tim: Non lo toccherei. Penso che sia un grande documento storico. Voglio dire, lui è quello che è. Compie 19 anni, è vecchio, ma ai suoi tempi ha fatto una rivoluzione. Ciò che ha fatto bene è stato innescare una reazione e la gente ha iniziato a sussurrare su di lui. Molto probabilmente nel 2001 non lavoravi ancora nel settore, ma allora tutti lavoravano secondo i processi. Software Engineering Institute, cinque livelli del modello di completezza del software (CMMI). Non so se queste leggende della profonda antichità ti dicono qualcosa, ma poi è stata una svolta. Inizialmente, le persone credevano che se i processi fossero stati impostati correttamente, i problemi sarebbero scomparsi da soli. E poi arriva il Manifesto e dice: “No, no, no – ci baseremo sulle persone, non sui processi”. Siamo maestri nello sviluppo di software. Comprendiamo che il processo ideale è un miraggio; non accade. C’è troppa idiosincrasia nei progetti, l’idea di un unico processo perfetto per tutti i progetti non ha alcun senso. I problemi sono troppo complessi per affermare che esiste una sola soluzione a tutto (ciao, nirvana).
Non presumo di guardare al futuro, ma dirò che ora le persone hanno iniziato a pensare di più ai progetti. Penso che il Manifesto Agile sia molto bravo a saltare fuori e dire: “Ehi! Sei su una nave e tu stesso guidi questa nave. Dovrai prendere una decisione: non suggeriremo una ricetta universale per tutte le situazioni. Tu sei l'equipaggio della nave e, se sei abbastanza bravo, puoi trovare la strada per raggiungere l'obiettivo. C’erano altre navi prima di te, e ce ne saranno altre dopo di te, ma comunque, in un certo senso, il tuo viaggio è unico”. Qualcosa del genere! È un modo di pensare. Per me non c'è niente di nuovo sotto il sole, le persone hanno già navigato e navigheranno ancora, ma per te questo è il tuo viaggio principale e non ti dirò cosa ti succederà esattamente. Devi avere le capacità del lavoro coordinato in squadra e, se le hai davvero, tutto funzionerà e arriverai dove volevi.
Peopleware: 30 anni dopo
Oleg: Peopleware è stata una rivoluzione così come il Manifesto?
Tim: Peopleware... Tom e io abbiamo scritto questo libro, ma non pensavamo che sarebbe successo così. In qualche modo ha risuonato con le idee di molte persone. Questo è stato il primo libro che affermava: lo sviluppo di software è un'attività ad alta intensità umana. Nonostante la nostra natura tecnica, siamo anche una comunità di persone che costruiscono qualcosa di grande, anche enorme, molto complesso. Nessuno può creare queste cose da solo, giusto? Quindi l’idea di “squadra” è diventata molto importante. E non solo dal punto di vista gestionale, ma anche per i tecnici che si sono riuniti per risolvere problemi profondi e davvero complessi con molte incognite. Per me personalmente, questa è stata una grande prova di intelligenza nel corso della mia carriera. E qui devi essere in grado di dire: sì, questo problema è più di quanto posso gestire da solo, ma insieme possiamo trovare una soluzione elegante di cui possiamo essere orgogliosi. E penso che sia stata questa idea a risuonare di più. L'idea che lavoriamo parte del tempo da soli, parte del tempo come parte di un gruppo, e spesso la decisione viene presa dal gruppo. La risoluzione dei problemi di gruppo è diventata rapidamente una caratteristica importante di progetti complessi.
Nonostante Tim abbia tenuto un numero enorme di discorsi, pochissimi di essi sono pubblicati su YouTube. Puoi guardare il rapporto “The Return of Peopleware” del 2007. La qualità, ovviamente, lascia molto a desiderare.
Michael: È cambiato qualcosa negli ultimi 30 anni dalla pubblicazione del libro?
Tim: Puoi vederlo da molte angolazioni diverse. Sociologicamente parlando... c'era una volta, in tempi più semplici, tu e il tuo team sedevate nello stesso ufficio. Potresti stare vicino ogni giorno, bere un caffè insieme e discutere di lavoro. Ciò che è veramente cambiato è che ora i team possono essere distribuiti geograficamente, in paesi e fusi orari diversi, ma continuano a lavorare sullo stesso problema, e questo aggiunge un livello completamente nuovo di complessità. Può sembrare vecchia scuola, ma non c'è niente come la comunicazione faccia a faccia in cui siete tutti insieme, lavorate insieme, e potete andare da un collega e dire, guarda cosa ho scoperto, ti piace? Le conversazioni faccia a faccia forniscono un modo rapido per passare alla comunicazione informale e penso che dovrebbe piacere anche agli appassionati dell'agilità. E sono anche preoccupato perché in realtà il mondo si è rivelato molto piccolo, e ora è tutto ricoperto di team distribuiti, ed è tutto molto complesso.
Viviamo tutti in DevOps
Michael: Anche dal punto di vista del comitato del programma della conferenza, abbiamo persone in California, a New York, in Europa, in Russia... non c'è ancora nessuno a Singapore. La differenza geografica è piuttosto ampia e le persone stanno iniziando a diffondersi ancora di più. Se parliamo di sviluppo, puoi dirci di più sul devops e sull'abbattimento delle barriere tra i team? C'è il concetto secondo cui tutti sono seduti nei loro bunker, e ora i bunker stanno crollando, cosa ne pensi di questa analogia?
Tim: Mi sembra che alla luce delle recenti scoperte tecnologiche, il devops sia di grande importanza. In precedenza, avevi team di sviluppatori e amministratori, lavoravano, lavoravano, lavoravano e ad un certo punto è apparsa una cosa con cui potevi andare dagli amministratori e lanciarla per la produzione. E qui è iniziata la conversazione sul bunker, perché gli amministratori sono una specie di alleati, non almeno nemici, ma con loro hai parlato solo quando tutto era pronto per andare in produzione. Sei andato da loro con qualcosa e hai detto: guarda che applicazione abbiamo, ma potresti implementarla? E ora l'intero concetto di consegna è cambiato in meglio. Voglio dire, c'era l'idea che si potessero portare avanti i cambiamenti rapidamente. Possiamo aggiornare i prodotti al volo. Sorrido sempre quando Firefox sul mio portatile si apre e dice: ehi, abbiamo aggiornato Firefox in background e, appena hai un minuto, ti dispiacerebbe fare clic qui e ti forniremo l'ultima versione. E io ho pensato: "Oh sì, tesoro!" Mentre dormivo, stavano lavorando per consegnarmi una nuova versione direttamente sul mio computer. Questo è meraviglioso, incredibile.
Ma ecco la difficoltà: hai questa funzionalità con l’aggiornamento del software, ma integrare le persone è molto più difficile. Ciò che voglio esprimere al keynote di DevOops è che ora abbiamo molti più giocatori di quanti ne abbiamo mai avuti. Se pensi solo a tutti coloro che sono coinvolti in una sola squadra…. Lo pensavi come una squadra, ed è molto più di un semplice team di programmatori. Questi sono tester, project manager e un sacco di altre persone. E ognuno ha la propria visione del mondo. I product manager sono completamente diversi dai project manager. Gli amministratori hanno i propri compiti. Diventa un problema piuttosto difficile coordinare tutti i partecipanti in modo da continuare ad essere consapevoli di ciò che sta accadendo e non impazzire. È necessario separare i compiti del gruppo dai compiti che riguardano tutti. Questo è un compito molto difficile. D'altra parte penso che sia tutto molto meglio rispetto a molti anni fa. È proprio questa la strada sulla quale le persone crescono e imparano a comportarsi correttamente. Quando fai l'integrazione, capisci che non dovrebbe esserci sviluppo sotterraneo, in modo che all'ultimo momento il software non esca fuori come un jack-in-the-box: guarda cosa abbiamo fatto qui! L'idea è che sarai in grado di eseguire l'integrazione e lo sviluppo e alla fine il lancio avverrà in modo accurato e iterativo. Tutto questo significa molto per me. Ciò consente di creare più valore per gli utenti del sistema e per il tuo cliente.
Michael: L’idea stessa di devops è quella di fornire sviluppi significativi il prima possibile. Vedo che il mondo ha cominciato ad accelerare sempre di più. Come adattarsi a tali accelerazioni? Dieci anni fa questo non esisteva!
Tim: Naturalmente tutti vogliono sempre più funzionalità. Non c'è bisogno di spostarsi, basta accumularne di più. A volte devi persino rallentare affinché il successivo aggiornamento incrementale porti qualcosa di utile, e questo è del tutto normale.
L'idea che devi correre, correre, correre non è la migliore. È improbabile che qualcuno voglia vivere la propria vita in quel modo. Vorrei che il ritmo delle consegne scandisse il ritmo del progetto. Se produci semplicemente un flusso di cose piccole e relativamente prive di significato, tutto ciò non avrà alcun significato. Invece di cercare sconsideratamente di rilasciare le cose il prima possibile, ciò che vale la pena discutere con gli sviluppatori principali e i responsabili di prodotto e progetto è la strategia. Ha senso anche questo?
Pattern e antipattern
Oleg: Di solito parli di schemi e antischemi, e questa è la differenza tra la vita e la morte dei progetti. E ora il devops irrompe nelle nostre vite. Ha qualcuno dei suoi modelli e anti-modelli che possono uccidere il progetto sul colpo?
Tim: Schemi e anti-schemi si verificano continuamente. Qualcosa di cui parlare. Bene, c'è questa cosa che chiamiamo "cose luccicanti". Alla gente piacciono davvero molto le nuove tecnologie. Sono semplicemente incantati dallo splendore di tutto ciò che sembra bello ed elegante e smettono di fare domande: è davvero necessario? Cosa otterremo? Questa cosa è affidabile, ha senso? Vedo spesso persone, per così dire, all'avanguardia della tecnologia. Sono ipnotizzati da ciò che sta accadendo nel mondo. Ma se dai un'occhiata più da vicino alle cose utili che fanno, spesso semplicemente non c'è nulla di utile!
Stavamo giusto discutendo con i nostri compagni che quest'anno è l'anniversario, cinquant'anni dallo sbarco dell'uomo sulla Luna. Questo accadeva nel 1969. La tecnologia che ha aiutato le persone ad arrivare lì non è nemmeno la tecnologia del 1969, ma piuttosto quella del 1960 o 62, perché la NASA voleva utilizzare solo ciò che aveva buone prove di affidabilità. E così lo guardi e capisci: sì, ed erano vere! Ora, no, no, ma si hanno problemi con la tecnologia semplicemente perché tutto viene spinto troppo oltre, venduto da tutte le parti. La gente grida da ogni parte: "Guarda, che cosa, questa è la cosa più nuova, la cosa più bella del mondo, adatta proprio a tutti!" Ecco, questo è tutto... di solito tutto questo si rivela solo un esca, e poi è tutto da buttare. Forse è tutto perché sono già vecchio e guardo queste cose con molto scetticismo, quando le persone si esauriscono e dicono di aver trovato l'unico modo più corretto per creare le migliori tecnologie. In questo momento dentro di me si risveglia una voce che dice: “Che casino!”
Michael: In effetti, quante volte abbiamo sentito parlare della prossima soluzione miracolosa?
Tim: Esatto, e questo è il solito corso delle cose! Ad esempio... sembra che in giro per il mondo la cosa sia già diventata una barzelletta, ma da noi si parla spesso di tecnologia blockchain. E in realtà hanno senso in certe situazioni! Quando hai davvero bisogno di prove affidabili degli eventi, che il sistema funzioni e che nessuno ci abbia ingannato, quando hai problemi di sicurezza e tutte queste cose mescolate insieme, la blockchain ha senso. Ma quando si dice che la Blockchain ormai spazzerà via il mondo, spazzando via tutto sul suo cammino? Sogna di più! Questa è una tecnologia molto costosa e complessa. Tecnicamente complesso e richiede molto tempo. Anche in modo puramente algoritmico, ogni volta che è necessario ricalcolare i calcoli, con le minime modifiche... e questa è un'ottima idea, ma solo in determinati casi. Tutta la mia vita e la mia carriera riguardano questo: idee interessanti in situazioni molto specifiche. È molto importante capire esattamente qual è la tua situazione.
Michael: Sì, la principale “questione sulla vita, sull’universo e su tutto il resto”: questa tecnologia o approccio è adatto alla tua situazione oppure no?
Tim: Questa questione può già essere discussa con il gruppo tecnologico. Magari coinvolgere anche qualche consulente. Dai un'occhiata al progetto e capisci: ora faremo qualcosa di giusto e utile, meglio di prima? Forse andrà bene, forse no. Ma soprattutto, non prendere una decisione del genere per impostazione predefinita, semplicemente perché qualcuno ha sbottato: “Abbiamo un disperato bisogno di una blockchain! Ho appena letto di lui su una rivista in aereo!” Sul serio? Non è nemmeno divertente.
Il mitico “ingegnere devops”
Oleg: Ora tutti stanno implementando devops. Qualcuno legge dei devops su Internet e domani appare un altro posto vacante sul sito di reclutamento. "ingegnere sviluppatore". Qui vorrei attirare la vostra attenzione: pensate che questo termine “devops engineer” abbia diritto alla vita? C'è un'opinione secondo cui il devops è una cultura, e qui qualcosa non quadra.
Tim: Così così. Diano subito allora qualche spiegazione di questo termine. Qualcosa che lo renda unico. Finché non dimostreranno che esiste una combinazione unica di competenze dietro un posto vacante come questo, non ci crederò! Voglio dire, beh, abbiamo un titolo professionale, "devops engineer", un titolo interessante, sì, e dopo? I titoli di lavoro sono generalmente una cosa molto interessante. Diciamo "sviluppatore": che cos'è comunque? Organizzazioni diverse significano cose completamente diverse. In alcune aziende, programmatori di alta qualità scrivono test che hanno più senso dei test scritti da tester professionisti speciali in altre società. E allora, ora sono programmatori o tester?
Sì, abbiamo titoli di lavoro, ma se fai domande abbastanza a lungo, alla fine si scopre che siamo tutti risolutori di problemi. Siamo alla ricerca di soluzioni e alcuni hanno competenze tecniche e altri ne hanno di diverse. Se vivi in un ambiente in cui è penetrato DevOps, sei impegnato nell'integrazione di sviluppo e amministrazione e questa attività ha uno scopo abbastanza importante. Ma se ti viene chiesto cosa fai esattamente e di cosa sei responsabile, si scopre che le persone fanno tutte queste cose da tempo immemorabile. "Sono responsabile dell'architettura", "Sono responsabile dei database" e così via, qualunque cosa, vedi, tutto questo era prima di "devops".
Quando qualcuno mi dice il suo titolo professionale, non ascolto molto. È meglio lasciare che sia lui a dirvi di cosa è effettivamente responsabile, questo ci permetterà di capire molto meglio la questione. Il mio esempio preferito è quando una persona afferma di essere un “project manager”. Che cosa? Non significa niente, ancora non so cosa fai. Un project manager può essere uno sviluppatore, il leader di un team di quattro persone, che scrive codice, lavora, che è diventato il leader del team, che le persone stesse riconoscono tra loro come leader. Inoltre, un project manager può essere un manager che gestisce seicento persone su un progetto, gestisce altri manager, è responsabile della stesura dei programmi e della pianificazione dei budget, tutto qui. Sono due mondi completamente diversi! Ma il loro titolo professionale sembra lo stesso.
Giriamo la situazione in modo leggermente diverso. In cosa sei veramente bravo, hai molta esperienza, hai talento? Di cosa ti assumerai la responsabilità perché pensi di poter gestire il compito? E qui qualcuno inizierà subito a negare: no, no, no, non ho alcuna voglia di occuparmi delle risorse del progetto, non sono affari miei, sono un tipo tecnico e capisco l'usabilità e le interfacce utente, no Se voglio gestire eserciti di persone, è meglio che mi metta al lavoro.
E comunque, sono un grande sostenitore di un approccio in cui questo tipo di separazione delle competenze funziona bene. Dove i tecnici possono far crescere la propria carriera quanto vogliono. Tuttavia vedo ancora organizzazioni in cui i tecnici si lamentano: dovrò dedicarmi al project management perché in questa azienda è l'unica possibilità. A volte questo porta a risultati terribili. I migliori tecnici non sono affatto buoni manager, e i migliori manager non sono in grado di gestire la tecnologia. Siamo onesti su questo.
Vedo molta richiesta per questo adesso. Se sei un tecnico, la tua azienda può aiutarti, ma a prescindere, devi, devi davvero trovare il tuo percorso di carriera perché la tecnologia continua a cambiare e devi reinventarti insieme ad essa! In soli vent’anni le tecnologie possono cambiare almeno cinque volte. La tecnologia è una cosa strana...
"Esperti di tutto"
Michael: Come possono le persone far fronte a una tale velocità di cambiamento tecnologico? La loro complessità cresce, il loro numero cresce, cresce anche la quantità totale di comunicazione tra le persone e si scopre che non puoi diventare un "esperto in tutto".
Tim: Giusto! Se lavori nel campo della tecnologia, sì, devi assolutamente scegliere qualcosa di specifico e approfondirlo. Alcune tecnologie che la tua organizzazione trova utili (e forse saranno effettivamente utili). E se non ti interessa più - non avrei mai creduto di dirlo - beh, forse dovresti trasferirti in qualche altra organizzazione dove la tecnologia è più interessante o più conveniente da studiare.
Ma in generale sì, hai ragione. Le tecnologie crescono contemporaneamente in tutte le direzioni; nessuno può dire “Sono un tecnologo esperto in tutte le tecnologie esistenti”. D'altra parte, ci sono persone spugna che assorbono letteralmente la conoscenza tecnologica e ne vanno pazzi. Ho visto un paio di persone del genere, lo respirano e lo vivono letteralmente, è utile e interessante parlare con loro. Studiano non solo ciò che sta accadendo all'interno dell'organizzazione, ma in generale ne parlano, sono anche dei tecnologi davvero fantastici, sono molto consapevoli e propositivi. Cercano semplicemente di rimanere sulla cresta dell'onda, indipendentemente da quale sia il loro lavoro principale, perché la loro passione è il movimento della Tecnologia, la promozione della tecnologia. Se all'improvviso incontri una persona del genere, dovresti andare a pranzo con lui e discutere di varie cose interessanti durante il pranzo. Penso che qualsiasi organizzazione abbia bisogno di almeno un paio di queste persone.
Rischi e incertezze
Michael: Ingegneri onorati, sì. Tocchiamo la gestione del rischio mentre abbiamo tempo. Abbiamo iniziato questa intervista con una discussione sul software medico, dove gli errori possono portare a conseguenze disastrose. Poi abbiamo parlato del Programma Lunare, dove il costo di un errore è di milioni di dollari, e forse diverse vite umane. Ma ora vedo il movimento opposto nel settore, le persone non pensano ai rischi, non cercano di prevederli, non li osservano nemmeno.
Oleg: Muoviti velocemente e rompi le cose!
Michael: Sì, muoviti velocemente, rompi le cose, sempre più cose, finché non muori per qualcosa. Dal tuo punto di vista, come dovrebbe avvicinarsi ora lo sviluppatore medio alla gestione del rischio di apprendimento?
Tim: Tracciamo una linea tra due cose: rischi e incertezza. Queste sono cose diverse. L'incertezza si verifica quando non si dispone di dati sufficienti in un dato momento per arrivare a una risposta definitiva. Ad esempio, nella fase iniziale di un progetto, se qualcuno ti chiede “quando finirai il lavoro”, se sei una persona abbastanza onesta, risponderai “Non ne ho idea”. Semplicemente non lo sai e va bene così. Non hai ancora studiato i problemi e non hai familiarità con la squadra, non conosci le loro capacità e così via. Questa è l'incertezza.
I rischi sorgono quando è già possibile identificare potenziali problemi. Questo genere di cose può accadere, la sua probabilità è maggiore di zero, ma inferiore al cento per cento, da qualche parte nel mezzo. A causa di ciò, tutto può succedere, da ritardi e lavoro inutile, ma anche a un esito fatale per il progetto. Il risultato, quando dici ragazzi, chiudiamo gli ombrelloni e lasciamo la spiaggia, non la finiremo mai, è tutto finito, punto. Avevamo dato per scontato che questa cosa avrebbe funzionato, ma non funziona affatto, è ora di smetterla. Queste sono le situazioni.
Spesso i problemi sono più facili da risolvere quando sono già emersi, quando il problema si sta verificando proprio adesso. Ma quando hai un problema davanti a te, non stai facendo gestione del rischio: stai risolvendo problemi, gestisci la crisi. Se sei uno sviluppatore o un manager capo, ti starai chiedendo cosa potrebbe accadere che porterebbe a ritardi, perdite di tempo, costi inutili o al collasso dell'intero progetto? Cosa ci farà fermare e ricominciare da capo? Quando tutte queste cose funzioneranno, cosa ne faremo? C’è una risposta semplice che vale per la maggior parte delle situazioni: non scappare dai rischi, lavorare su di essi. Guarda come puoi risolvere una situazione rischiosa, ridurla a nulla, trasformarla da problema in qualcos'altro. Invece di dire: bene, risolveremo i problemi man mano che si presenteranno.
L’incertezza e il rischio dovrebbero essere in prima linea in tutto ciò con cui hai a che fare. Puoi elaborare un piano di progetto, considerare in anticipo alcuni rischi critici e dire: dobbiamo affrontarlo ora, perché se qualcosa va storto, nient’altro avrà importanza. Non dovresti preoccuparti della bellezza della tovaglia sul tavolo se non è chiaro se puoi cucinare la cena. Per prima cosa devi identificare tutti i rischi legati alla preparazione di una cena deliziosa, affrontarli e solo allora pensare a tutte le altre cose che non rappresentano una vera minaccia.
Ancora una volta, cosa rende unico il tuo progetto? Vediamo cosa può far andare fuori strada il nostro progetto. Cosa possiamo fare per ridurre al minimo la probabilità che ciò accada? Di solito non è possibile neutralizzarli al 100% e dichiarare con la coscienza pulita: “Ecco, questo non è più un problema, il rischio è risolto!” Per me questo è un segno di comportamento adulto. Questa è la differenza tra un bambino e un adulto: i bambini pensano di essere immortali, che nulla può andare storto, andrà tutto bene! Allo stesso tempo, gli adulti guardano come i bambini di tre anni saltano nel parco giochi, seguono i movimenti con gli occhi e dicono a se stessi: "ooh-ooh, ooh-ooh". Sto lì vicino e mi preparo ad afferrare il bambino quando cade.
D’altra parte, il motivo per cui mi piace così tanto questo business è perché è rischioso. Facciamo cose e quelle cose sono rischiose. Richiedono un approccio adulto. L’entusiasmo da solo non risolverà i tuoi problemi!
Pensiero ingegneristico degli adulti
Michael: L'esempio con i bambini è buono. Se sono un ingegnere normale, allora sono felice di essere un bambino. Ma come ci si muove verso un pensiero più adulto?
Tim: Una delle idee che funziona altrettanto bene sia con un principiante che con uno sviluppatore affermato è il concetto di contesto. Cosa stiamo facendo, cosa raggiungeremo. Cosa è veramente importante in questo progetto? Non importa chi sei in questo progetto, che tu sia uno stagista o il capo architetto, tutti hanno bisogno del contesto. Dobbiamo convincere tutti a pensare su una scala più ampia rispetto al proprio lavoro. "Realizzo il mio pezzo e finché funziona, sono felice." No e ancora no. Vale sempre la pena (senza essere scortese!) ricordare alle persone il contesto in cui lavorano. Quello che stiamo cercando di realizzare tutti insieme. Idee che puoi essere un bambino purché tutto vada bene con la tua parte del progetto: per favore, non farlo. Se riusciremo a tagliare il traguardo, lo taglieremo solo insieme. Non sei solo, siamo tutti insieme. Se tutte le persone coinvolte nel progetto, sia vecchie che giovani, iniziassero a parlare di ciò che è esattamente importante per il progetto, del motivo per cui l’azienda sta investendo denaro in ciò che stiamo tutti cercando di ottenere… la maggior parte di loro si sentirebbe molto meglio perché vedrà come il loro lavoro è correlato al lavoro di tutti gli altri. Da un lato capisco il pezzo di cui sono personalmente responsabile. Ma per finire il lavoro abbiamo bisogno anche di tutte le altre persone. E se pensi davvero di aver finito, abbiamo sempre del lavoro da fare nel progetto!
Oleg: Relativamente parlando, se lavori secondo Kanban, quando incontri il collo di bottiglia di alcuni test, puoi abbandonare quello che stavi facendo lì (ad esempio, programmare) e andare ad aiutare i tester.
Tim: Esattamente. Penso che i migliori tecnici, se li guardi da vicino, sono una specie di manager di se stessi. Come posso formulare questo...
Oleg: La tua vita è il tuo progetto, che gestisci.
Tim: Esattamente! Voglio dire, ti assumi la responsabilità, capisci il problema ed entri in contatto con le persone quando vedi che le tue decisioni possono influenzare il loro lavoro, cose del genere. Non si tratta semplicemente di sederti alla scrivania, fare il tuo lavoro e nemmeno realizzare cosa succede intorno a te. No, no, no. A proposito, una delle cose migliori di Agile è che propongono sprint brevi, perché in questo modo lo stato delle cose di tutti i partecipanti è chiaramente osservabile, possono vederlo tutti insieme. Parliamo l'uno dell'altro ogni giorno.
Come entrare nella gestione del rischio
Oleg: Esiste una struttura formale della conoscenza in quest’area? Ad esempio, sono uno sviluppatore Java e desidero comprendere la gestione del rischio senza diventare un vero project manager per istruzione. Probabilmente leggerò prima "Quanto costa un progetto software" di McConnell, e poi? Quali sono i primi passi?
Tim: Il primo è iniziare a comunicare con le persone nel progetto. Ciò garantisce un immediato miglioramento della cultura della comunicazione con i colleghi. Dobbiamo iniziare aprendo tutto per impostazione predefinita, invece di nasconderlo. Di': queste sono le cose che mi danno fastidio, queste sono le cose che mi tengono sveglio la notte, oggi mi sono svegliato di notte e ho pensato: mio Dio, devo pensarci! Gli altri vedono la stessa cosa? Come gruppo, dovremmo rispondere a questi potenziali problemi? È necessario essere in grado di sostenere una discussione su questi argomenti. Non esiste una formula preconfezionata con cui lavoriamo. Non si tratta di fare hamburger, ma di persone. "Preparare un cheeseburger, vendere un cheeseburger" non è affatto il nostro genere, ed è per questo che amo così tanto questo lavoro. Mi piace quando tutto quello che facevano i manager ora diventa proprietà della squadra.
Oleg: Hai parlato in libri e interviste di come le persone si preoccupino più della felicità che dei numeri su un grafico. D'altra parte, quando dici al team: stiamo passando al devops, e ora il programmatore deve comunicare costantemente, questo potrebbe essere molto fuori dalla sua zona di comfort. E in questo momento potrebbe, diciamo, essere profondamente infelice. Cosa fare in questa situazione?
Tim: Non sono sicuro esattamente di cosa fare. Se uno sviluppatore è troppo isolato, non vede il motivo per cui il lavoro viene svolto, guarda solo la sua parte di lavoro e deve entrare in quello che io chiamo "contesto". Ha bisogno di capire come tutto è collegato insieme. E ovviamente non intendo presentazioni formali o cose del genere. Sto parlando del fatto che devi comunicare con i colleghi sul lavoro nel suo insieme e non solo sulla parte di esso di cui sei responsabile. Qui è dove puoi iniziare a discutere idee, accordi comuni per far sì che il tuo lavoro si adatti bene e come affrontare insieme un problema comune.
Per aiutarli ad adattarsi, spesso vogliono mandare i tecnici alla formazione e discutono della formazione. A un mio amico piace dire che l'addestramento è per i cani. C'è formazione per le persone. Una delle cose migliori dell'apprendimento come sviluppatore è l'interazione con i tuoi colleghi. Se qualcuno è davvero bravo in qualcosa, dovresti guardarlo lavorare o parlargli del suo lavoro o qualcosa del genere. Alcuni Kent Beck convenzionali parlavano costantemente di programmazione estrema. È divertente perché XP è un'idea così semplice, ma causa così tanti problemi. Per alcuni, fare XP è come essere costretti a spogliarsi nudi davanti agli amici. Vedranno cosa sto facendo! Sono miei colleghi, non solo vedranno, ma capiranno anche! Terribile! Alcune persone iniziano a diventare seriamente nervose. Ma quando ti rendi conto che questo è il modo migliore per imparare, tutto cambia. Lavori a stretto contatto con le persone e alcune persone comprendono l'argomento molto meglio di te.
Michael: Ma tutto ciò ti costringe a uscire dalla tua zona di comfort. Come ingegnere, devi uscire dalla tua zona di comfort e comunicare. Come risolutore di problemi, devi metterti costantemente in una posizione debole e pensare a cosa potrebbe andare storto. Questo tipo di lavoro è intrinsecamente progettato per essere fastidioso. Ti metti consapevolmente in situazioni stressanti. Di solito le persone scappano da loro, alla gente piace essere bambini felici.
Tim: Cosa si può fare, puoi uscire allo scoperto e dire apertamente: “Va tutto bene, posso gestirlo! Non sono l'unico a sentirsi a disagio. Discutiamo di varie cose scomode, tutti insieme, come una squadra!” Questi sono i nostri problemi comuni, dobbiamo affrontarli, sai? Penso che gli sviluppatori geniali e peculiari siano come i mammut, sono scomparsi. E il loro significato è molto limitato. Se non sai comunicare, non puoi partecipare bene. Pertanto, basta parlare. Sii onesto e aperto. Mi dispiace molto che questo sia spiacevole per qualcuno. Riuscite a immaginare, molti anni fa esisteva uno studio secondo il quale la paura principale negli Stati Uniti non è la morte, ma indovinate un po'? Paura di parlare in pubblico! Ciò significa che da qualche parte ci sono persone che preferirebbero morire piuttosto che dire un complimento ad alta voce. E penso che sia sufficiente che tu abbia alcune competenze di base, a seconda di cosa fai. Capacità di parlare, capacità di scrivere, ma solo quanto è realmente necessario nel tuo lavoro. Se lavori come analista, ma non sai leggere, scrivere o parlare, sfortunatamente non avrai nulla a che fare con i miei progetti!
Il prezzo della comunicazione
Oleg: Assumere questi dipendenti in uscita non è più costoso per vari motivi? Dopotutto, chiacchierano costantemente invece di lavorare!
Tim: Intendevo il nucleo della squadra, e non solo tutti. Se hai qualcuno che è davvero bravo nell'ottimizzazione dei database, ama l'ottimizzazione dei database e continuerà a ottimizzare i tuoi database per il resto della sua vita e basta, bello, continua così. Ma sto parlando di persone che vogliono vivere nel progetto stesso. Il nucleo del team, finalizzato allo sviluppo del progetto. Queste persone hanno davvero bisogno di comunicare costantemente tra loro. E soprattutto all'inizio del progetto, quando si discutono dei rischi, dei modi per raggiungere obiettivi globali e simili.
Michael: Questo vale per tutti coloro che sono coinvolti nel progetto, indipendentemente dalla specializzazione, dalle competenze o dal modo di lavorare. Siete tutti interessati al successo del progetto.
Tim: Sì, ritieni di essere sufficientemente immerso nel progetto, che il tuo compito è aiutare il progetto a realizzarsi. Che tu sia un programmatore, analista, progettista di interfacce, chiunque. Questo è il motivo per cui vengo a lavorare ogni mattina ed è quello che facciamo. Siamo responsabili di tutte queste persone, indipendentemente dalle loro competenze. Questo è un gruppo di persone che hanno conversazioni da adulti.
Oleg: Infatti, parlando di dipendenti loquaci, ho cercato di simulare le obiezioni delle persone, soprattutto dei manager, a cui viene chiesto di passare al devops, a questa visione del mondo completamente nuova. E tu, come consulenti, dovresti essere consapevole di queste obiezioni molto meglio di me, come sviluppatore! Condividi cosa preoccupa di più i manager?
Tim: Manager? Uhm. Molto spesso, i manager sono sotto pressione a causa di problemi, di fronte alla necessità di rilasciare urgentemente qualcosa ed effettuare una consegna, e simili. Osservano come discutiamo e discutiamo costantemente di qualcosa, e la vedono così: conversazioni, conversazioni, conversazioni... Quali altre conversazioni? Torna al lavoro! Perché per loro parlare non sembra un lavoro. Non scrivi codice, non testi software, non sembra che tu faccia nulla: perché non ti mandi a fare qualcosa? Dopotutto, la consegna è già tra un mese!
Michael: Vai a scrivere del codice!
Tim: Mi sembra che non siano preoccupati per il lavoro, ma per la mancanza di visibilità dei progressi. Per far sembrare che ci stiamo avvicinando al successo, hanno bisogno di vederci mentre premiamo i pulsanti sulla tastiera. Tutta la giornata dalla mattina alla sera. Questo è il problema numero uno.
Oleg: Misha, stai pensando a qualcosa.
Michael: Scusate, mi sono perso nei pensieri e ho avuto un flashback. Tutto questo mi ha ricordato un'interessante manifestazione avvenuta ieri... Ci sono state troppe manifestazioni ieri... E tutto suona molto familiare!
Vita senza stipendio
Tim: A proposito, non è affatto necessario organizzare "manifestazioni" per la comunicazione. Voglio dire, le discussioni più utili tra gli sviluppatori avvengono quando parlano tra loro. Entri la mattina con una tazza di caffè e ci sono cinque persone riunite che discutono furiosamente di qualcosa di tecnico. Per me, se sono il manager di questo progetto, è meglio semplicemente sorridere e andare da qualche parte sui miei affari, lasciare che ne discutano. Sono già coinvolti il più possibile. Questo è un buon segno.
Oleg: A proposito, nel tuo libro hai un sacco di note su cosa è buono e cosa è male. Ne usi qualcuno tu stesso? Relativamente parlando, ora hai un'azienda, ed è strutturata in un modo molto poco ortodosso...
Tim: Non ortodosso, ma questo dispositivo ci si adatta perfettamente. Ci conosciamo da molto tempo. Ci fidiamo l'uno dell'altro, ci fidavamo molto l'uno dell'altro prima di diventare partner. E ad esempio, non abbiamo alcuno stipendio. Lavoriamo e basta e, ad esempio, se guadagnavo soldi dai miei clienti, tutti i soldi andavano a me. Successivamente paghiamo le quote associative all'organizzazione e questo è sufficiente per sostenere l'azienda stessa. Inoltre, siamo tutti specializzati in cose diverse. Ad esempio, lavoro con i contabili, compilo le dichiarazioni dei redditi, svolgo ogni sorta di attività amministrativa per l'azienda e nessuno mi paga per questo. James e Tom lavorano sul nostro sito e nessuno li paga neanche loro. Finché pagherai il dovuto, nessuno penserà a dirti cosa devi fare. Ad esempio, Tom ora lavora molto meno di prima. Ora ha altri interessi; fa alcune cose non per la Gilda. Ma finché paga quello che gli spetta, nessuno gli si avvicinerà e gli dirà: “Ehi, Tom, vai a lavorare!” È molto facile trattare con i colleghi quando non ci sono soldi tra di voi. E ora il nostro rapporto è una delle idee fondamentali in relazione alle diverse specialità. Funziona e funziona molto bene.
miglior consiglio
Michael: Tornando al "miglior consiglio", c'è qualcosa che dici ai tuoi clienti più e più volte? C'è un'idea sull'80/20 e alcuni consigli vengono probabilmente ripetuti più spesso.
Tim: Una volta pensavo che se avessi scritto un libro come Waltzing with Bears, avrebbe cambiato il corso della storia e le persone si sarebbero fermate, ma... Beh, guarda, le aziende spesso fingono che per loro vada tutto bene. Non appena succede qualcosa di brutto, per loro è uno shock e una sorpresa. "Senti, abbiamo testato il sistema e non supera alcun test di sistema, e questi sono altri tre mesi di lavoro non programmato, come è potuto succedere? Chi lo sapeva? Cosa potrebbe andare storto? Sul serio, ci credi?
Sto cercando di spiegarti che non dovresti arrabbiarti troppo per la situazione attuale. Dobbiamo discuterne, capire veramente cosa potrebbe essere andato storto e come evitare che tali cose accadano in futuro. Se si presenta un problema, come lo combatteremo, come lo conterremo?
A me tutto questo sembra spaventoso. Le persone affrontano problemi complessi e fastidiosi e continuano a fingere che se incrociano le dita e sperano per il meglio, il “meglio” accadrà davvero. No, non funziona così.
Pratica la gestione del rischio!
Michael: Secondo te, quante organizzazioni si impegnano nella gestione del rischio?
Tim: Ciò che mi fa infuriare è che le persone semplicemente annotano i rischi, guardano l'elenco risultante e si mettono al lavoro. In effetti, identificare i rischi per loro è gestione del rischio. Ma per me questo sembra un motivo per chiedere: ok, c'è una lista, cosa cambierai esattamente? È necessario modificare le sequenze standard di azioni tenendo conto di questi rischi. Se c'è una parte più difficile del lavoro, devi affrontarla e solo dopo passare a qualcosa di più semplice. Nei primi sprint, inizia a risolvere problemi complessi. Sembra già una gestione del rischio. Ma di solito le persone non possono dire cosa hanno cambiato dopo aver compilato un elenco di rischi.
Michael: Eppure, quante di queste aziende sono coinvolte nella gestione del rischio, il XNUMX%?
Tim: Sfortunatamente, odio dirlo, ma questa è una parte davvero insignificante. Ma più di cinque, perché ci sono progetti davvero grandi e semplicemente non possono esistere se non fanno almeno qualcosa. Diciamo solo che sarei molto sorpreso se fosse almeno del 25%. I piccoli progetti di solito rispondono a queste domande in questo modo: se il problema ci riguarda, lo risolveremo. Quindi si mettono con successo nei guai e si impegnano nella gestione dei problemi e nella gestione delle crisi. Quando provi a risolvere un problema e il problema non viene risolto, benvenuto nella gestione delle crisi.
Sì, sento spesso: “risolveremo i problemi non appena si presenteranno”. Sicuramente lo faremo? Decideremo davvero?
Oleg: Puoi farlo ingenuamente e semplicemente scrivere invarianti importanti nella carta del progetto e, se le invarianti si interrompono, riavviare semplicemente il progetto. Risulta molto piembucky.
Michael: Sì, mi è capitato che quando si innescavano dei rischi il progetto veniva semplicemente ridefinito. Bello, bingo, problema risolto, non preoccuparti più!
Tim: Premiamo il pulsante di ripristino! No, non funziona così.
Intervento principale al DevOops 2019
Michael: Veniamo all'ultima domanda di questa intervista. Verrai al prossimo DevOops con un keynote, potresti sollevare il sipario di segretezza su ciò che racconterai?
Tim: In questo momento, sei di loro stanno scrivendo un libro sulla cultura del lavoro, sulle regole non dette delle organizzazioni. La cultura è determinata dai valori fondamentali dell’organizzazione. Di solito le persone non se ne accorgono, ma avendo lavorato per tanti anni nella consulenza, siamo abituati a notarlo. Entri in un'azienda e letteralmente in pochi minuti inizi a sentire cosa sta succedendo. Lo chiamiamo "sapore". A volte questo profumo è davvero buono, a volte è, beh, oops. Le cose sono molto diverse per le diverse organizzazioni.
Michael: Anch'io lavoro nella consulenza da anni e capisco bene di cosa parli.
Tim: In realtà, una delle cose di cui vale la pena parlare al keynote è che non tutto è determinato dall'azienda. Tu e il tuo team, come comunità, avete la vostra cultura di squadra. Potrebbe trattarsi dell'intera azienda o di un reparto separato, di un team separato. Ma prima di dire, ecco cosa crediamo, ecco cosa è importante... Non puoi cambiare una cultura prima che i valori e le convinzioni dietro azioni specifiche siano compresi. Il comportamento è facile da osservare, ma la ricerca delle credenze è difficile. DevOps è solo un ottimo esempio di come le cose stiano diventando sempre più complesse. Le interazioni stanno solo diventando più complesse, non stanno affatto diventando più pulite o più chiare, quindi dovresti pensare a ciò in cui credi e a ciò di cui tutti intorno a te tacciono.
Se vuoi ottenere risultati rapidi, ecco un buon argomento per te: hai visto aziende in cui nessuno dice “non lo so”? Ci sono posti dove torturi letteralmente una persona finché non ammette di non sapere qualcosa. Tutti sanno tutto, tutti sono incredibili eruditi. Ti avvicini a qualsiasi persona e lui deve rispondere immediatamente alla domanda. Invece di dire “Non lo so”. Evviva, hanno assunto un gruppo di eruditi! E in alcune culture è generalmente molto pericoloso dire “non lo so”; può essere percepito come un segno di debolezza. Ci sono anche organizzazioni in cui, al contrario, tutti possono dire “non lo so”. Lì è completamente legale, e se qualcuno inizia a dire sciocchezze in risposta a una domanda, è del tutto normale rispondere: "Non sai di cosa stai parlando, vero?" e trasformare tutto in uno scherzo.
Idealmente, ti piacerebbe avere un lavoro in cui potresti essere costantemente felice. Non sarà facile, non tutti i giorni sono soleggiati e piacevoli, a volte bisogna lavorare sodo, ma quando inizi a fare il punto, salta fuori: wow, questo è davvero un posto meraviglioso, mi sento bene a lavorare qui, sia emotivamente che intellettualmente. E ci sono aziende in cui vai come consulente e ti rendi subito conto che non resisteresti per tre mesi e scapperesti inorridito. Questo è ciò di cui voglio parlare nella relazione.
Tim Lister arriverà con un keynote alla conferenza DevOops 2019, che si svolgerà il 29 e 30 ottobre 2019 a San Pietroburgo. Puoi acquistare i biglietti . Ti aspettiamo al DevOops!
Fonte: habr.com