Dedicato ai project manager (e a chi sogna di diventare capo).
Scrivere tonnellate di codice è difficile, ma gestire le persone è ancora più difficile! Quindi hai solo bisogno di questo libro per imparare a fare entrambe le cose.
È possibile combinare storie divertenti e lezioni serie? Michael Lopp (noto anche in ambienti ristretti come Rands) ci riuscì. Troverai storie di fantasia su persone immaginarie con esperienze incredibilmente gratificanti (anche se immaginarie). È così che Rands condivide le sue esperienze varie, a volte strane, maturate negli anni di lavoro in grandi aziende IT: Apple, Pinterest, Palantir, Netscape, Symantec, ecc.
Sei un project manager? O vuoi capire cosa fa tutto il giorno il tuo dannato capo? Rands ti insegnerà come sopravvivere nel mondo tossico dei tacchini gonfiati e prosperare nella follia generale di persone disfunzionalmente appariscenti. In questa strana comunità di cervelli maniacali ci sono creature ancora più strane: manager che, attraverso un mistico rituale organizzativo, hanno acquisito potere sui piani, sui pensieri e sui conti bancari di molte persone.
Questo libro è diverso da qualsiasi manoscritto di gestione o leadership. Michael Lopp non nasconde nulla, racconta semplicemente le cose come stanno (forse non tutte le storie dovrebbero essere rese pubbliche :P). Ma solo così capirai come sopravvivere con un boss del genere, come gestire geek e nerd, e come portare “quel maledetto progetto” a lieto fine!
Estratto. Mentalità ingegneristica
Pensieri su: dovresti continuare a scrivere codice?
Il libro di Rands sulle regole per i manager contiene un breve elenco di "cose da fare" manageriali moderne. Il laconicismo di questo elenco deriva dal fatto che il concetto di “must” è una sorta di assoluto e quando si tratta di persone ci sono pochissimi concetti assoluti. Un metodo di gestione di successo per un dipendente sarà un vero disastro per un altro. Questo pensiero è il primo elemento nell’elenco delle “cose da fare” del manager:
Rimani flessibile!
Pensare di sapere già tutto è una pessima idea. In una situazione in cui l’unica costante è che il mondo cambia continuamente, la flessibilità diventa l’unica posizione corretta.
Paradossalmente, il secondo punto della lista è sorprendentemente inflessibile. Tuttavia, questo punto è il mio preferito perché credo che aiuti a creare le basi per la crescita manageriale. Questo paragrafo recita:
Smettila di scrivere codice!
In teoria, se vuoi fare il manager, devi imparare a fidarti di chi lavora per te e affidare interamente a loro la programmazione. Questo consiglio è solitamente difficile da digerire, soprattutto per i manager appena coniati. Probabilmente uno dei motivi per cui sono diventati manager è la loro produttività nello sviluppo e, quando le cose vanno male, la loro prima reazione è ricorrere alle competenze in cui hanno piena fiducia, ovvero la capacità di scrivere codice.
Quando vedo che un manager appena coniato “sprofonda” nella scrittura di codice, gli dico: “Sappiamo che sai scrivere codice. La domanda è: puoi guidare? Non sei più responsabile solo di te stesso, sei responsabile dell'intero team; e voglio assicurarmi che tu possa convincere il tuo team a risolvere i problemi da solo, senza che tu debba scrivere tu stesso il codice. Il tuo compito è capire come ridimensionarti. Non voglio che tu sia uno solo, voglio che ce ne siano tanti come te”.
Un buon consiglio, vero? Scala. Gestione. Responsabilità. Parole d'ordine così comuni. È un peccato che il consiglio sia sbagliato.
Sbagliato?
Sì. Il consiglio è sbagliato! Non del tutto sbagliato, ma abbastanza sbagliato da dover chiamare alcuni ex colleghi e scusarmi: “Ricordate quella mia affermazione preferita su come dovreste smettere di scrivere codice? È sbagliato! Sì... Ricomincia la programmazione. Inizia con Python e Ruby. Si sono serio! La tua carriera dipende da questo!”
Quando ho iniziato la mia carriera come sviluppatore di software presso Borland, ho lavorato nel team Paradox Windows, che era un team enorme. C'erano solo 13 sviluppatori di applicazioni. Se aggiungi persone di altri team che lavoravano costantemente sulle tecnologie chiave per questo progetto, come il motore del database principale e i servizi applicativi principali, ottieni 50 ingegneri direttamente coinvolti nello sviluppo di questo prodotto.
Nessun altro team per cui ho lavorato si avvicina a queste dimensioni. Infatti, ogni anno che passa, il numero di persone nel team in cui lavoro diminuisce gradualmente. Cosa sta succedendo? Noi sviluppatori stiamo diventando collettivamente sempre più intelligenti? No, stiamo solo condividendo il carico.
Cosa hanno fatto gli sviluppatori negli ultimi 20 anni? Durante questo periodo abbiamo scritto un sacco di codice. Mare di codice! Abbiamo scritto così tanto codice che abbiamo deciso che sarebbe stata una buona idea semplificare tutto e diventare open source.
Fortunatamente, grazie a Internet, questo processo è diventato il più semplice possibile. Se sei uno sviluppatore di software, puoi verificarlo subito! Cerca il tuo nome su Google o Github e vedrai un codice che hai dimenticato da tempo, ma che chiunque può trovare. Spaventoso, vero? Non sapevi che il codice vive per sempre? Sì, vive per sempre.
Il codice vive per sempre. E il buon codice non solo vive per sempre, ma cresce perché coloro che lo apprezzano si assicurano costantemente che rimanga aggiornato. Questa pila di codice di alta qualità e ben gestito aiuta a ridurre la dimensione media del team di ingegneri perché ci consente di concentrarci sul codice esistente anziché scriverne nuovo e di portare a termine il lavoro con meno persone e in un arco di tempo più breve.
Questa linea di ragionamento sembra deprimente, ma l’idea è che siamo tutti solo un mucchio di automi di integrazione che usano nastro adesivo per collegare insieme diversi pezzi di cose esistenti per creare una versione leggermente diversa della stessa cosa. Questa è una linea di pensiero classica tra i dirigenti senior che amano l’outsourcing. "Chiunque sappia usare Google e abbia del nastro adesivo può farlo! Allora perché stiamo pagando un sacco di soldi per le nostre macchine?
Paghiamo davvero un sacco di soldi a questi ragazzi della gestione, ma pensano queste sciocchezze. Ancora una volta, il mio punto chiave è che ci sono molti sviluppatori brillanti e molto laboriosi sul nostro pianeta; sono veramente brillanti e diligenti, nonostante non abbiano trascorso un solo minuto seduti in università accreditate. Oh sì, ora ce ne sono sempre di più!
Non ti suggerisco di iniziare a preoccuparti del tuo posto solo perché alcuni compagni brillanti lo stanno cercando. Ti suggerisco di iniziare a preoccuparti perché l’evoluzione dello sviluppo del software si sta probabilmente muovendo più velocemente di te. Lavori da dieci anni, di cui cinque come manager, e pensi: “So già come si sviluppano i software”. Si lo sai. Ciao…
Smettila di scrivere codice, ma...
Se segui il mio consiglio originale e smetti di scrivere codice, smetterai volontariamente anche di partecipare al processo di creazione. È per questo motivo che non utilizzo attivamente l'outsourcing. Gli automi non creano, producono. Processi ben progettati fanno risparmiare molti soldi, ma non portano nulla di nuovo nel nostro mondo.
Se hai un piccolo team che fa molto con pochi soldi, allora l’idea di smettere di scrivere codice mi sembra una pessima decisione professionale. Anche nelle aziende mostruose con le loro infinite normative, processi e politiche, non hai il diritto di dimenticare come sviluppare software da solo. E lo sviluppo del software è in continua evoluzione. Sta cambiando proprio adesso. Sotto i tuoi piedi! Proprio in questo istante!
Hai obiezioni. Capire. Ascoltiamo.
“Rands, sto andando alla sedia del regista! Se continuo a scrivere codice, nessuno crederà che posso crescere”.
Voglio chiederti questo: da quando sei seduto sulla tua sedia “Sto per diventare CEO!”, hai notato che il panorama dello sviluppo software sta cambiando, anche all'interno della tua azienda? Se la tua risposta è sì, allora ti farò un’altra domanda: come sta cambiando esattamente e cosa farai riguardo a questi cambiamenti? Se hai risposto “no” alla mia prima domanda, allora devi spostarti su un’altra sedia, perché (scommetto!) il campo dello sviluppo software sta cambiando proprio in questo momento. Come potrai crescere se lentamente ma inesorabilmente dimentichi come sviluppare software?
Il mio consiglio è di non impegnarti a implementare tantissime funzionalità per il tuo prossimo prodotto. È necessario adottare costantemente misure per rimanere al passo con il modo in cui il tuo team crea software. Puoi farlo sia come direttore che come vicepresidente. Qualcos'altro?
“Uffa, Rand! Ma qualcuno deve essere l'arbitro! Qualcuno deve vedere il quadro generale. Se scrivo codice, perderò la prospettiva."
Devi ancora essere l'arbitro, devi ancora trasmettere le decisioni, e devi ancora fare il giro dell'edificio quattro volte ogni lunedì mattina con uno dei tuoi ingegneri per ascoltare il suo sfogo settimanale "Siamo tutti condannati" per 30 anni. minuti. ! Ma oltre a tutto ciò, devi mantenere una mentalità ingegneristica e non devi essere un programmatore a tempo pieno per farlo.
I miei consigli per mantenere una mentalità ingegneristica:
- Utilizzare l'ambiente di sviluppo. Ciò significa che dovresti avere familiarità con gli strumenti del tuo team, incluso il sistema di creazione del codice, il controllo della versione e il linguaggio di programmazione. Di conseguenza, imparerai fluentemente la lingua utilizzata dal tuo team quando parla di sviluppo del prodotto. Ciò ti consentirà anche di continuare a utilizzare il tuo editor di testo preferito, che funziona perfettamente.
- Devi essere in grado di disegnare uno schema architettonico dettagliato che descriva il tuo prodotto su qualsiasi superficie in qualsiasi momento. Ora non intendo la versione semplificata con tre celle e due frecce. È necessario conoscere lo schema dettagliato del prodotto. Quello più difficile. Non un diagramma carino qualsiasi, ma un diagramma difficile da spiegare. Dovrebbe essere una mappa adatta per una comprensione completa del prodotto. È in costante cambiamento e dovresti sempre sapere perché si sono verificati determinati cambiamenti.
- Assumere l'implementazione di una delle funzioni. Sto letteralmente sussultando mentre scrivo questo perché questo punto contiene molti pericoli nascosti, ma non sono davvero sicuro che tu possa realizzare i punti n. 1 e n. 2 senza impegnarti a implementare almeno una funzionalità. Implementando tu stesso una delle funzionalità, non solo sarai coinvolto attivamente nel processo di sviluppo, ma ti permetterà anche di passare periodicamente dal ruolo di “Manager responsabile di tutto” al ruolo di “Uomo incaricato di implementarne una”. delle funzioni." Questo atteggiamento umile e senza pretese ti ricorderà l’importanza delle piccole decisioni.
- Sto ancora tremando dappertutto. Sembra che qualcuno mi stia già urlando: "Il manager che si è fatto carico dell'implementazione della funzione?!" (E sono d'accordo con lui!) Sì, sei ancora il manager, il che significa che dovrebbe essere qualche piccola funzione, ok? Sì, hai ancora molto da fare. Se proprio non riesci ad affrontare l’implementazione della funzione, allora ho qualche consiglio in più per te: correggi alcuni bug. In questo caso, non sentirai la gioia della creazione, ma capirai come viene creato il prodotto, il che significa che non rimarrai mai senza lavoro.
- Scrivere test unitari. Lo faccio ancora in una fase avanzata del ciclo di produzione, quando la gente inizia a impazzire. Considerala come una lista di controllo sanitario per il tuo prodotto. Fallo spesso.
Ancora obiezione?
“Rands, se scrivo codice, confonderò la mia squadra. Non sapranno chi sono: un manager o uno sviluppatore”.
Bene.
Sì, ho detto: "Va bene!" Sono felice che tu pensi di poter confondere la tua squadra semplicemente nuotando nello stagno degli sviluppatori. È semplice: i confini tra i diversi ruoli nello sviluppo del software sono attualmente molto sfumati. I ragazzi dell'interfaccia utente fanno quella che a grandi linee può essere chiamata programmazione JavaScript e CSS. Gli sviluppatori stanno imparando sempre di più sulla progettazione dell'esperienza utente. Le persone comunicano tra loro e vengono a conoscenza dei bug, del furto del codice altrui e anche del fatto che non esiste una buona ragione per cui un manager non partecipi a questo baccanale informativo massiccio, globale e impollinante.
Inoltre, vuoi far parte di una squadra composta da componenti facilmente sostituibili? Ciò non solo renderà il tuo team più agile, ma darà a ciascun membro del team l'opportunità di vedere il prodotto e l'azienda da una varietà di prospettive. Come puoi arrivare a rispettare Frank, il ragazzo calmo responsabile delle build, non più di quanto lo sia dopo aver visto la semplice eleganza dei suoi script di build?
Non voglio che la tua squadra diventi confusa e caotica. Al contrario, voglio che il tuo team comunichi in modo più efficace. Credo che se sei coinvolto nella creazione del prodotto e nel lavoro sulle funzionalità, sarai più vicino al tuo team. E, cosa ancora più importante, sarai più vicino ai continui cambiamenti nel processo di sviluppo del software all'interno della tua organizzazione.
Non smettere di svilupparti
Una mia collega alla Borland una volta mi ha attaccato verbalmente per averla definita una "programmatrice".
“Rands, il programmatore è una macchina senza cervello! Scimmia! Il programmatore non fa nulla di importante se non scrivere noiose righe di codice inutile. Non sono un programmatore, sono uno sviluppatore di software!”
Aveva ragione, avrebbe odiato il mio consiglio iniziale ai nuovi amministratori delegati: “Smettetela di scrivere codice!” Non perché sto suggerendo che siano programmatori, ma più perché sto suggerendo in modo proattivo che inizino a ignorare una delle parti più importanti del loro lavoro: lo sviluppo di software.
Quindi ho aggiornato il mio consiglio. Se vuoi essere un buon leader, puoi smettere di scrivere codice, ma...
Sii flessibile. Ricorda cosa significa essere un ingegnere e non smettere di sviluppare software.
Chi l'Autore
Michael Lopp è uno sviluppatore di software veterano che non ha ancora lasciato la Silicon Valley. Negli ultimi 20 anni, Michael ha lavorato per una varietà di aziende innovative, tra cui Apple, Netscape, Symantec, Borland, Palantir, Pinterest, e ha anche partecipato a una startup che lentamente è finita nell'oblio.
Al di fuori del lavoro, Michael gestisce un popolare blog su tecnologia e management sotto lo pseudonimo di Rands, dove discute con i lettori idee nel campo del management, esprime preoccupazione per la costante necessità di tenere il passo con il polso e spiega che, nonostante il generose ricompense per la creazione di un prodotto, il tuo successo è possibile solo grazie al tuo team. Il blog può essere trovato qui .
Michael vive con la sua famiglia a Redwood, in California. Trova sempre il tempo per andare in mountain bike, giocare a hockey e bere vino rosso, perché essere sani è più importante che essere occupati.
» Per ulteriori informazioni sul libro, visitare il sito
»
»
Per Khabrozhiteli sconto del 20% sul coupon - Gestire gli esseri umani
A seguito del pagamento della versione cartacea del libro, verrà inviata via e-mail la versione elettronica del libro.
PS: il 7% del prezzo del libro andrà alla traduzione di nuovi libri di informatica, un elenco di libri consegnato alla tipografia .
Fonte: habr.com