Recensione: “scadenza. un romanzo sul project management di tom demarco

Forse ci sono ancora manager che credono che la gestione sia riunioni, programmi di formazione e miglioramento del prodotto e vari rapporti. Tuttavia, ai nostri tempi è diventato ovvio che la gestione del progetto è principalmente un lavoro con le persone.

Come scegliere tra una varietà di candidati la persona di cui hai bisogno? Qual è il numero ottimale di persone in un team nelle diverse fasi del progetto? Come puoi ottimizzare il tuo lavoro se hai scadenze ravvicinate? Come identificare e risolvere i conflitti? Come licenziare una persona senza offenderla? Quali qualità deve avere un buon leader? Imparerai tutto questo da questo libro, che peraltro non è un arido lavoro scientifico, ma un emozionante romanzo d'avventura!

Il libro è rivolto ai project manager nel campo della tecnologia dell'informazione.

Prefazione

Negli anni '30, il fisico George Gamow della Colorado State University iniziò a pubblicare una miniserie di storie su un certo signor Tompkins, un impiegato di banca di mezza età. Il signor Tompkins, come mostravano queste storie, era interessato alla scienza moderna. Frequentava regolarmente le lezioni serali del professore universitario locale e, naturalmente, si addormentava sempre nel posto più interessante. E quando si è svegliato, si è ritrovato in un mondo parallelo, dove una delle leggi fondamentali della fisica ha agito in modo diverso rispetto al suo mondo.

In una di queste storie, ad esempio, il signor T si è svegliato in un universo in cui la velocità della luce era di sole quindici miglia.

all'ora e potrebbe osservare gli effetti della relatività mentre pedala. Mentre pedalava più veloce, gli edifici in avvicinamento si rimpicciolirono e le lancette dell'orologio dell'ufficio postale rallentarono. La trama di un'altra storia era che il signor Tompkins viaggiò in un mondo in cui la costante di Planck era uguale a uno e osservò la meccanica quantistica in azione, in piedi davanti a un tavolo da biliardo: le palline non rotolavano dolcemente sulla superficie, come al solito, ma presumevano una posizione imprevedibile, come sfere quantiche particelle.

Sono stato introdotto alle storie di Gamow quando ero un adolescente. Come il signor Tompkins, ero interessato alla scienza moderna, a quel tempo avevo già letto molti libri sulla meccanica quantistica e sulla teoria della relatività. Ma solo dopo che mi sono capitate tra le mani le storie sullo sfortunato impiegato di banca ho finalmente cominciato a capire di cosa si trattava.

Ho sempre ammirato il modo in cui Gamow è riuscito a descrivere complessi postulati scientifici in un modo così interessante e discreto. Mi è sembrato che alcuni principi della gestione del progetto potessero essere descritti nella stessa forma. E ho deciso di raccontarti, caro lettore, la storia di un leader esperto che è finito in un paese immaginario dove sono state apportate modifiche "dall'alto" a varie regole di gestione. Così è nata (mi scuso più sentitamente con George Gamow) l'idea di questo libro, la storia di un manager di nome Tompkins che è finito nell'ex repubblica socialista di Morovia.

Tom De Marco,

Capitolo 1

Le più ampie possibilità

Il signor Tompkins sedeva nell'ultima fila di Baldridge 1, l'auditorium principale della Big Telecommunications Corporation (Penelope, New Jersey). Aveva passato un bel po' di tempo qui nelle ultime settimane a tenere lezioni ai licenziati. Il signor Tompkins e diverse migliaia di altri professionisti e quadri intermedi come lui sono stati semplicemente messi alla porta. Beh, ovviamente, nessuno ha parlato in modo così sgarbato e diretto. Frasi di uso comune erano: "ridimensionamento", oppure "conseguenza del ridimensionamento dell'azienda", oppure "ottimizzazione delle dimensioni dell'azienda", oppure - e questa opzione era la più bella di tutte - "diamo la libertà di scegliere un'altra lavoro." Per quest'ultima frase fu subito inventata una sigla: SVDR. Tompkins era uno di questi SVDR.

Oggi a Baldridge 1 si sarebbe tenuta un'altra conferenza sul tema "Le più ampie opportunità sono proprio di fronte a noi". Come indicato nel programma, questa serie di conferenze consisteva in "più di cento ore di allenamenti, brani, intermezzi musicali e altre attività estremamente entusiasmanti per il nuovo SVDR" - e tutto in cinque settimane. I dipendenti del dipartimento del personale (che non sono stati licenziati da nessuno) erano convinti che diventare un SVDR fosse la più grande felicità, ma per qualche motivo il resto non lo capiva. Certo, loro stessi volevano davvero diventare SVDR. Onestamente. Ma, ahimè, finora nessuna fortuna. No, no, signore, per il momento devono sopportare il loro fardello: ricevere stipendi regolari e promozioni. E ora saliranno sul palco e continueranno con coraggio il loro duro lavoro.

Le ultime file dell'auditorium caddero in ciò che gli ingegneri acustici chiamano "morti". Per qualche misterioso motivo che nessuno è stato ancora in grado di spiegare, il suono del palco praticamente non è penetrato qui, quindi è stato fantastico fare un pisolino qui. Tompkins si è sempre seduto lì.

Sul sedile di fronte, ha disposto il set di regali di oggi dell'azienda: due grossi taccuini e altre piccole cose erano confezionati in una bellissima borsa di stoffa con il logo dell'azienda e la scritta: "La nostra azienda sta perdendo peso, quindi tutti gli altri può ingrassare". In cima alla borsa c'era un cappellino da baseball con ricamo: "Sono SVDR e ne sono orgoglioso!" Tompkins si stiracchiò, si tirò il berretto da baseball sugli occhi e nel giro di un minuto si addormentò profondamente.

In questo momento, il coro delle risorse umane ha cantato ad alta voce sul palco: “Le più ampie opportunità: apriamo loro la porta! apriamolo!" Secondo il piano degli artisti, il pubblico doveva battere le mani e cantare insieme: "Apriamolo!" A sinistra del palco c'era un uomo con un altoparlante e acclamava il pubblico con grida di "Più forte, più forte!" Diverse persone hanno applaudito svogliatamente, ma nessuno voleva cantare insieme. Tuttavia, tutto questo rumore ha cominciato a farsi strada anche nella "zona morta" dove dormiva il signor Tompkins, e alla fine lo ha svegliato.

Libro in scadenza. Un romanzo sulla gestione dei progetti descrive i principi della gestione dei progetti in modo interessante e discreto: la forma di un romanzo d'affari.

Tom DeMarco - Informazioni sull'autore

Tom De Marco - Conduce un'attività didattica attiva, scrive articoli e libri.

Assiste anche in contenziosi relativi al software. Membro dell'Association for Computing Machinery e dell'Institute of Electrical and Electronics Engineers.

scadenza. Un romanzo sulla gestione dei progetti - Riassunto del libro

Il protagonista del libro - il manager Webster Tompkins - si ritrova misteriosamente nell'ex repubblica socialista di Morovia con un regime totalitario, dove è stato nominato capo di diversi progetti software.

Trova le persone giuste. Quindi, qualunque cosa tu faccia, qualunque errore tu commetta, le persone ti tireranno fuori dai guai. Questo è il lavoro di un leader.

Quattro regole fondamentali di gestione

1. Trova le persone giuste.
2. Dai loro il lavoro per il quale sono più adatti.
3. Non dimenticare la motivazione.
4. Riunire la squadra e mantenerla in uno stato di coesione. (Tutto il resto è un'assurdità amministrativa.)

Dal taccuino del signor Tompkins

Sicurezza e cambiamento

1. Una persona resiste al cambiamento se non si sente al sicuro.
2. I cambiamenti sono necessari affinché un leader funzioni con successo (sicuramente sono necessari in qualsiasi altra attività).
3. L'incertezza fa sì che una persona eviti il ​​rischio.
4. Evitando il rischio, una persona perde nuove opportunità e benefici che potrebbero portarlo al cambiamento.
5. È facile intimidire una persona con minacce dirette, ma puoi anche fargli sapere che, a volte, può essere trattata in modo sgarbato e crudele. L'effetto sarà lo stesso.

Motivazione negativa

6. Le minacce sono il tipo di motivazione più inappropriato se ci tieni alle prestazioni dei dipendenti.
7. Non importa quanto minacci, l'attività non sarà comunque completata se hai impiegato troppo poco tempo per completarla dall'inizio.
8. Se le persone non portano a termine il lavoro, dovrai mettere in atto le tue minacce.

Parti del corpo necessarie per la gestione dei progetti

9. La leadership richiede cuore, istinto, anima e profumo.
10. Quindi:
è necessario condurre con il cuore;
sentire interiormente;
investire nel team e nell'anima del progetto;
avere fiuto per distinguere l'utile dall'insensato.
Il comandante in capo sul campo di battaglia come metafora del project management. All'inizio della battaglia, il lavoro del comandante in capo era già stato completato.

Colloquio di lavoro e assunzione

11. Per assumere una persona per un lavoro, un manager ha bisogno di tutte le sue capacità: cuore, anima, profumo e capacità di sentire interiormente (soprattutto - quest'ultima).
12. Non cercare di assumere persone da sole: è molto meglio utilizzare l'intuizione di due manager in questo processo.
13. Assegna ai nuovi assunti lavori che hanno svolto bene in passato e lascia che la loro crescita e le loro ambizioni aspettino fino al prossimo progetto.
14. Chiedi un vantaggio: la persona che hai assunto nella tua squadra può probabilmente dirti chi altro assumere.
15. Ascolta di più, parla di meno. Aumento della produttività
16. Non ci sono misure a breve termine che aumenterebbero rapidamente la produttività dei robot.
17. Il miglioramento della produttività è il risultato di uno sforzo a lungo termine.
18. Qualsiasi potenziamento delle prestazioni che promette risultati immediati è una truffa.

Gestione dei rischi

19. Per gestire un progetto è sufficiente gestirne i rischi.
20. Creare un elenco di rischi per ogni progetto.
21. Tieni traccia dei rischi che causano il fallimento del progetto, non solo dei rischi finali.
22. Valutare la probabilità e il costo di ciascun rischio.
23. Per ogni rischio, determina un indicatore, un sintomo in base al quale puoi determinare che il rischio si sta trasformando in un problema.
24. Nomina una persona dedicata per gestire il rischio e non usare motti ottimistici come "Possiamo fare qualsiasi cosa!".
25. Creare canali accessibili (possibilmente anonimi) per fornire cattive notizie al management.

Gioco di difesa

26. Tagliare le perdite.
Il comandante in capo sul campo di battaglia come metafora del project management. All'inizio della battaglia, il lavoro del comandante in capo era già stato completato.

27. Il successo del progetto può essere assicurato riducendo gli sforzi inutili piuttosto che lottando per nuove vittorie.
28. Prima interrompi il lavoro non necessario, meglio si rifletterà sul progetto nel suo insieme.
29. Non creare inutilmente nuovi team: è meglio attirare quelli esistenti per lavorare.
30. Incoraggiare i membri del team a lavorare insieme dopo la fine del progetto (se lo desiderano) per evitare inutili problemi con la formazione di nuovi team.
31. Considera che un team i cui membri sono pronti a continuare a lavorare insieme è uno degli obiettivi principali di qualsiasi progetto.
32. Un giorno perso all'inizio di un progetto significa tanto quanto un giorno perso alla fine.
33. Ci sono mille modi per sprecare un giorno e nessuno per riavere quel giorno indietro.

34. Modella le tue ipotesi e ipotesi su come andrà il processo di lavoro.
Ci sono mille modi per sprecare un giorno e nessuno per riavere indietro quel giorno.

35. Discutere questi modelli con i partner per comprendere meglio il processo di lavoro e apportare le correzioni necessarie.
36. Prevedi i risultati del lavoro con un modello.
37. Confronta i risultati ottenuti nel processo di simulazione con quelli reali.
Molti anni fa, il signor Tompkins ha imparato una regola utile: rispettare qualsiasi, anche il più dannoso dei suoi subordinati.

Politica perversa

38. In qualsiasi momento, devi essere pronto a rifiutare il lavoro e chiedere un calcolo ...
39. ...tuttavia, ciò non significa che in questo modo potrai evitare le conseguenze di una politica perversa.
Molti anni fa, il signor Tompkins ha imparato una regola utile: rispettare qualsiasi, anche il più dannoso dei suoi subordinati.

40. La politica perversa ti porterà ovunque, anche nell'organizzazione più sana e avanzata.
41. Il segno principale di una politica perversa è che gli obiettivi e l'influenza personali sono messi in primo piano, e non gli interessi generali dell'azienda.
42. Inoltre, gli obiettivi personali possono contraddire direttamente gli obiettivi dell'organizzazione.
43. Uno degli effetti collaterali di una politica perversa è che diventa poco sicuro avere un team dotato di personale ottimale.

Raccolta di dati metrici

44. Definire i parametri di ogni progetto.
45. Non essere troppo zelante all'inizio con la scelta di un'unità di misura: se in seguito dovrai lavorare con dati reali, le unità astratte andranno bene per cominciare.
46. ​​​​Costruisci metriche complesse basate su metriche semplici che sono facili da calcolare in qualsiasi prodotto software.
47. Raccogli dati storici per calcolare la produttività dei progetti già completati.
48. Lavorare su formule per il calcolo di metriche sintetiche complesse fino a quando i risultati ottenuti riflettono nel modo più accurato il rapporto tra unità astratte e la quantità di lavoro indicata nei dati di archivio.
49. Traccia una linea di tendenza attraverso l'intero database dell'archivio, che mostrerà la quantità di lavoro prevista come rapporto di metriche sintetiche complesse.
50. Ora, per ogni nuovo progetto, sarà sufficiente calcolare il valore della metrica sintetica e utilizzarlo per determinare la quantità di lavoro prevista.
Il segno distintivo della politica perversa: gli obiettivi personali e l'influenza sono messi in primo piano, non gli interessi generali dell'azienda

51. Non dimenticare il "livello di rumore" sulla linea delle prestazioni: usalo come indicatore per determinare quanto puoi deviare dalla traiettoria complessiva.

Processo di sviluppo e suo miglioramento

52. Un processo di sviluppo efficiente e il suo miglioramento continuo sono obiettivi molto meritevoli.
53. Ma ci sono anche traguardi e obiettivi lavorativi: un buon dipendente si concentrerà su di essi, anche se non glielo hai chiesto.
54. I programmi formali per migliorare il processo di sviluppo esistente costeranno caro al team, sia in termini di tempo che di denaro. Anche gli sforzi individuali per migliorare il processo possono far arretrare il team. Per quanto riguarda il possibile aumento della produttività, anche se lo fosse, è improbabile che i benefici di questo aumento coprano i costi.

Le persone non penseranno più velocemente perché la direzione inizia a fare pressione su di loro.

55. Si può sperare di ottenere un risultato positivo da qualsiasi miglioramento equilibrato e scelto con cura nei metodi di lavoro. In questo caso, può ripagarsi da solo.
56. Il tentativo di introdurre più di un miglioramento nella metodologia è una causa persa. I programmi volti a migliorare molte tecniche e competenze (ad esempio, il passaggio al livello successivo di CMM) rischiano solo di ritardare il processo di completamento del lavoro.
57. Il pericolo di un processo di sviluppo standardizzato è che le persone non vedono l'opportunità di risparmiare tempo e fatica dedicati allo sviluppo del progetto dietro le operazioni di routine.
58. Per i team che sono troppo grandi, verrà rigorosamente rispettato un processo standardizzato, purché consenta a tutti i partecipanti di sentirsi coinvolti (che sia vantaggioso per il progetto o meno).

Lavora in modo diverso

59. C'è solo un modo per ridurre il tempo di sviluppo, quando è già breve, ed è quello di ridurre il tempo di debug del programma.
60. I progetti ad alte prestazioni richiedono molto meno tempo per eseguire il debug e correggere i bug.
61. I progetti ad alta produttività richiedono molto più tempo di progettazione.
La rabbia e la mancanza di rispetto sono contagiose. Quando l'alta dirigenza dimostra rabbia e mancanza di rispetto per i subordinati, i quadri intermedi iniziano a copiare tale comportamento.

62. Non puoi costringere le persone a fare qualcosa di diverso senza mostrare loro la cura e l'interesse adeguati. Per cambiarli, devi capire (e apprezzare) cosa fanno e per cosa si battono.

Effetto pressione dall'alto

63. Le persone non penseranno più velocemente perché la leadership inizia a fare pressione su di loro.
64. Maggiore è il lavoro straordinario, minore è la produttività.
65. Un po' di pressione e straordinari possono aiutare a concentrarsi sul problema, capirne e sentirne l'importanza, ma una pressione prolungata dà sempre un risultato negativo.
66. Forse il management ama così tanto fare pressione perché semplicemente non sa come influenzare la situazione in altro modo, o perché le soluzioni alternative sembrano troppo complicate.
Un progetto che coinvolge più parti non eviterà un conflitto di interessi

67. Ipotesi terribile: la pressione e i tempi supplementari mantengono solo una buona faccia in una brutta partita. Ne più ne meno.

Capo terribile

68. La rabbia e la mancanza di rispetto sono contagiose. Quando l'alta dirigenza dimostra rabbia e mancanza di rispetto per i subordinati, i quadri intermedi iniziano a copiare tale comportamento. Allo stesso modo, i bambini che sono stati puniti da bambini spesso diventano genitori violenti in seguito.
69. La mancanza di rispetto e la malizia, secondo alcuni leader, dovrebbero far lavorare meglio i subordinati. Questa è una tipica politica del "bastone e carota". Ma una tale "frusta" non incoraggia mai le persone a lavorare meglio.
70. Se il capo mostra mancanza di rispetto per i subordinati, questo è un segno che non può più mantenere la sua posizione (e per niente che ha cattivi subordinati).

Specifiche nebbiose per lo sviluppo

71. La vaghezza della presentazione del materiale indica che ci sono conflitti irrisolti tra i partecipanti al progetto.
72. Una specificazione che non elenca i tipi di informazioni in entrata e in uscita non dovrebbe nemmeno essere presa in considerazione. Ciò significa che semplicemente non specifica nulla.
Il conflitto merita comprensione e rispetto. Il conflitto non ha nulla a che fare con un comportamento non professionale.

73. Nessuno ti dirà mai che la specifica è cattiva. È più probabile che le persone sospettino se stesse di non essere in grado di comprendere ciò che è scritto piuttosto che accusare gli autori della specificazione del fallimento.

Conflitto

74. Un progetto che coinvolge più parti non eviterà i conflitti di interesse.
75. Il processo di creazione e distribuzione di sistemi software è un focolaio di ogni tipo di conflitto.
76. Nella maggior parte delle aziende in cui viene creato il software, nessuno si occupa specificamente della questione della risoluzione dei conflitti.
77. Il conflitto merita comprensione e rispetto. Il conflitto non ha nulla a che fare con un comportamento non professionale.
78. Comunica a tutti che considererai gli interessi di tutti i partecipanti e mantieni la tua promessa.
79. È difficile negoziare. È molto più facile mediare.
Pensiamo che la cosa peggiore sia l'ignoranza. Ma molto peggio è la falsa conoscenza

80. Annunciare in anticipo che se gli interessi delle parti in conflitto sono completamente o parzialmente opposti, la ricerca di una soluzione sarà spostata su un mediatore.
81. Non dimenticare: tutti i partecipanti alla situazione sono dalla stessa parte delle barricate. Dall'altra parte c'è il problema stesso.

Catalizzatore di progetto

82. Ci sono persone catalizzatori. Aiutano a creare una squadra sana, rapporti di fiducia, spirito combattivo. Anche se non hanno fatto nient'altro (e di solito fanno molto di più), il loro ruolo nel progetto rimane uno dei più importanti.
83. La mediazione è un altro settore in cui i catalizzatori umani sono indispensabili. Tuttavia, la mediazione può essere appresa, non è molto difficile.
84. Il primo passo nella mediazione dovrebbe essere una piccola cerimonia. Ad esempio, puoi pronunciare la frase "Posso provare a giudicare la tua controversia?".

Gli esseri umani tendono a commettere errori

85. Ci sembra che la cosa peggiore sia l'ignoranza. Ma la falsa conoscenza è molto peggio.
Presupposto orribile: sembra che quei team a cui non vengono date scadenze ravvicinate finiscano il lavoro più velocemente di quelli che sono fortemente limitati nel tempo!

A proposito di personale

86. Se all'inizio il progetto viene svolto da un team numeroso, ciò riduce l'efficacia della parte più critica del lavoro: determinare l'architettura del sistema (perché tutti gli sviluppatori devono svolgere rapidamente del lavoro).
87. Se il lavoro viene distribuito a persone e gruppi prima che la fase di progettazione del prodotto sia completata, non sarà possibile creare modelli semplici ed efficaci di interazione tra dipendenti e gruppi di lavoro.
88. Ciò comporterà una perdita di indipendenza, un aumento del numero di riunioni e conferenze e un malcontento generale.
89. Idealmente, sarebbe bene reclutare prima un piccolo team che crei un'architettura di sistema ben ponderata, e solo allora, per l'ultimo sesto del tempo di sviluppo, si potrebbe aggiungere nuovo personale a questo team (chi lavorare direttamente sulla codifica).
90. Presupposto terribile: sembra che quei team a cui non vengono date scadenze ravvicinate finiscano il lavoro più velocemente di quelli che hanno un tempo molto limitato!

Problemi di sociologia

91. Le riunioni non dovrebbero essere affollate. È necessario garantire la presenza all'incontro solo di quelle persone per le quali i temi discussi sono veramente importanti o interessanti. Il modo più semplice è pubblicare un ordine del giorno in anticipo e attenersi rigorosamente ad esso in ogni momento.
92. Ogni progetto ha bisogno di una sorta di cerimonia o rituale.
93. Con l'aiuto delle cerimonie, puoi focalizzare l'attenzione dei riuniti sui principali scopi e obiettivi dell'incontro: ridurre la composizione del gruppo di lavoro, migliorare la qualità del codice del programma, ecc.
94. Proteggi le persone dalla pressione e dagli abusi dei grandi capi.
Le riunioni non dovrebbero essere affollate. È necessario garantire la presenza all'incontro solo di quelle persone per le quali i temi discussi sono veramente importanti o interessanti. Il modo più semplice è pubblicare l'ordine del giorno in anticipo e rispettarlo sempre rigorosamente.

95. Ricorda: nel lavoro, paura = rabbia. I manager che urlano costantemente ai loro subordinati e li umiliano e li insultano in ogni modo possibile, in realtà hanno solo molta paura di qualcosa.
96. Osservazione: se la manifestazione di maleducazione e rabbia nei confronti dei subordinati diceva sempre agli altri che il capo aveva semplicemente paura, allora nessuno dei leader si comporterebbe in questo modo semplicemente per paura che la sua paura diventasse evidente! (Questo, ovviamente, non risolve i problemi di un tale leader, ma almeno protegge i suoi subordinati.)
Se ti capita di lavorare sotto un malvagio idiota, spera in un miracolo.

Sulla politica perversa (ancora una volta)

I manager che urlano costantemente ai loro subordinati e li umiliano e li insultano in ogni modo possibile, in realtà hanno solo molta paura di qualcosa.

97. Questa patologia non può essere curata dal basso.
98. Non vale la pena perdere tempo o mettersi in pericolo per verificare sulla propria esperienza il postulato precedente.
99. A volte l'unico modo per uscire da una situazione è aspettare. Cerca di aspettare finché il problema non si risolve da solo o finché non trovi un modo per evitarlo.
100. I miracoli, ovviamente, accadono, ma è meglio non contarci.

Malizia e avarizia

101. Malizia più avarizia: questa è la formula che coloro che sono responsabili dei fallimenti aziendali iniziano ad applicare nelle cattive compagnie.
102. La rabbia e l'avarizia sono esattamente l'opposto dei veri valori di qualsiasi buona azienda: essere generosi e premurosi nei confronti dei propri dipendenti.
A volte l'unica via d'uscita è aspettare. Cerca di aspettare finché il problema non si risolve da solo o finché non trovi un modo per evitarlo.

103. Se noti manifestazioni di malizia e avarizia in un'azienda, sappi che la loro vera ragione è la paura del fallimento.
Il taccuino del signor Tompkins, testimone e custode di tutte le sue straordinarie avventure, scoperte e conoscenze, giaceva in esigente attesa sul tavolo davanti a lui, aperto alla centoduesima pagina. Voleva che l'ultimo disco fosse qualcosa di speciale, che riassumesse tutta la sua nuova esperienza e conoscenza. Tuttavia, le conclusioni finali non potevano ancora prendere forma nella sua testa. Forse il suo intero taccuino era una voce così definitiva? Tornò indietro di una pagina. C'era scritto qualcosa che aveva capito da tempo, ma che ancora non si preoccupava di esprimere su carta.

Fondamenti di buon senso

104. Il progetto dovrebbe avere due scadenze: pianificata e desiderata.
105. Queste tempistiche non devono sovrapporsi.

Tutti i principi di una buona gestione sono descritti qui in una forma interessante e discreta di un romanzo d'affari. L'autore - Tom Demarco - ha già scritto 13 libri, ma Deadline lo considera il suo libro più potente. È sicuro che leggerlo ti aggiungerà due interi anni di eccellente esperienza manageriale, e una trama entusiasmante ed esempi illustrativi saranno più utili di qualsiasi libro di testo.

Non è un caso che questo libro sia diventato un libro di riferimento per centinaia di migliaia di manager in tutto il mondo. È incluso nell'elenco delle letture richieste per il corso di Project Management in molte business school in tutto il mondo. Presidente del consiglio di amministrazione
I direttori di Sberbank lo hanno notato come uno dei migliori libri di affari e lo hanno aggiunto alla biblioteca di Sberbank.

Se vuoi leggere solo un libro sulla gestione dei progetti, leggi questo.

Perché abbiamo deciso di pubblicare questo libro

Questa è solo una manna dal cielo per un manager stanco di leggere manuali ossessivi e storie di successo, e le parabole zen sul management non gli sono vicine nello spirito.

Per chi è questo libro?

Per tutti coloro che gestiscono progetti (soprattutto in ambito IT).

E per chi partecipa ai progetti.

Dall'autore

Gli occhi del signor Tompkins si illuminarono.

— Un esperimento... Una squadra lavora sotto stretto controllo, un'altra sotto controllo debole, la terza è praticamente libera e tutte e tre stanno lavorando allo stesso compito. Vedremo quale finisce più velocemente. Per tutta la vita ho sognato di fare qualcosa del genere. Puoi avere troppe persone in una squadra, troppo poche in un'altra, così tante quante penso te ne servano in una terza...

- In una squadra, recluta solo specialisti esperti, nell'altra - esperti e principianti, - ha continuato Laxa.

Ma lo stesso signor Tompkins era già intriso dell'idea e non si sarebbe fermato.

- In una recluta persone che hanno già lavorato insieme e vedi come competeranno con una squadra in cui nessuno si conosceva prima. Laxa, se lo facciamo, possiamo svelare uno dei più grandi misteri del management. Potremmo capire perché alcuni progetti hanno successo e altri no.

È tutto nelle tue mani, Webster. Puoi sperimentare con tutta la Morovia,” Laxa indicò Silicon Glade. — Eccolo, il primo Laboratorio di Project Management al mondo.

Il pluripremiato Tom DeMarco dirige Atlantic Systems Guild, un centro di consulenza con uffici negli Stati Uniti, in Germania e nel Regno Unito. Ingegnere del software e Bachelor of Electrical Engineering, destinatario del Jean-Dominique Warnier Lifetime Contribution to Information Science Award, DeMarco ha dimostrato di essere uno scrittore di talento, autore di nove libri su gestione, progettazione organizzativa e ingegneria dei sistemi, oltre a quattro opere di finzione.

Konstantin Smygin, fondatore del servizio di riepilogo della letteratura aziendale MakeRight.ru, ha condiviso con i lettori del sito web le idee chiave del romanzo d'affari di culto The Deadline, che racconta l'arte della gestione dei progetti.

Di cosa parla questo libro

In breve, Deadline è un libro sulla gestione dei progetti e delle persone.

All'inizio, il libro è percepito come un thriller, e solo dopo un po 'il lettore si rende conto di avere consigli abbastanza chiari e consigli pratici sulla gestione del progetto in un brillante guscio artistico.

Il guscio si presenta così. L'esperto project manager, il signor Tompkins, sta per essere licenziato. All'improvviso, viene rapito da una bellissima sconosciuta di nome Laxa, trasportata nel paese post-comunista di Morovia, governato dal tiranno VVN (Grande Leader dei Popoli).

Al signor Tompkins viene offerto di guidare molti progetti contemporaneamente, dietro un'enorme ricompensa, dando completa libertà di azione. Il tiranno VVN, a un esame più attento, risulta essere un giovane uomo d'affari bonario, con il quale Tompkins trova subito un linguaggio comune. Ma VVN e Laxa sono in servizio per affari, e il tipo pericoloso di Bellock, che incarna le peggiori caratteristiche di un leader, sostituisce il "tiranno". Stabilisce obiettivi irraggiungibili per Tompkins e la squadra, fissa scadenze irrealistiche e, in caso di mancato rispetto degli ordini, è pronto per l'eliminazione fisica. Ma Tompkins e il team, grazie alle complessità della gestione, riescono a districarsi con successo dai guai.

Idea n. 1. La chiave del successo di qualsiasi progetto non è nel capitale o nella tecnologia, ma nelle persone

L'idea è semplice fino alla banalità. Tuttavia, sono le cose semplici che più spesso vengono dimenticate quando si gestiscono progetti complessi. In Morovia (quasi come in) c'è di tutto: opportunità, idee, risorse umane e materiali praticamente illimitate. Mancano solo un paio di piccole cose: la giusta selezione del personale e un responsabile che, insieme agli assistenti, faccia funzionare il progetto.

Secondo DeMarco, tutta la gestione del personale si riduce a pochi semplici passaggi: primo, trovare le persone giuste e fornire loro il lavoro giusto; in secondo luogo, trovare la giusta motivazione che li unisca in una squadra ben coordinata.

Per Tompkins lavorare per Morovia è anche un esperimento per capire perché alcune squadre hanno successo e altre no, e hanno lo stesso compito.

Idea n. 2. Il giusto reclutamento si basa non tanto sulla scelta di un curriculum impressionante, ma sull'intuizione del responsabile delle risorse umane

Selezionando una squadra per lavorare su diversi progetti, Tompkins chiede un assistente e ottiene una strana donna Belinda Blinda, un'ex responsabile delle risorse umane che una volta si è esaurita al lavoro ed è diventata una vagabonda.

Belinda accetta il lavoro, chiedendo come compenso un carrello del supermercato.

Invece di leggere curriculum, Belinda incontra personalmente i candidati idonei e seleziona quelli giusti quasi all'istante, facendo riferimento alla sua intuizione. Tompkins, inizialmente scioccato, in seguito ammette che lui stesso avrebbe scelto queste persone.

Perché gli piacciono e sente che gli piacciono.

Questa scelta della squadra è simile alla scelta degli amici. Le persone seguono il leader perché lo amano e lo rispettano, e questa è l'unica ragione. Le relazioni affettuose all'interno del team sono molto importanti e quindi il leader deve avere un grande cuore. Oltre al cuore, il leader deve avere “dentro” (quella stessa intuizione) per identificare la persona giusta e sentire la situazione nel suo insieme, “l'anima” per infonderla nel progetto e nel team, e il “profumo ” per scartare le sciocchezze.

Idea numero 3. La motivazione del personale non dovrebbe essere negativa. Le minacce e la pressione uccidono l'iniziativa, non accelerano il lavoro

La motivazione ideale per lavorare in squadra è fondersi con essa, accettarne le idee, lo stesso “spirito di squadra”. Anche la componente monetaria e di carriera, la crescita professionale sono abbastanza appropriate. Ma se vengono utilizzate minacce e pungoli, ovvero motivazioni negative, ciò rallenta solo la produttività del lavoro, sebbene molti dirigenti siano di opinione diversa.

Inoltre, se le minacce non sono seguite dalla punizione, ciò mina l'autorità del leader. Dovrai soddisfarli, provocando un'ondata di licenziamenti e malcontento, oppure dimenticartene, esponendoti come una persona frivola.

Un'illustrazione ironica di questa idea è la storia di VVN, che decise di diventare un tiranno perché tutte le sue idee furono respinte. Si è lamentato del fatto che mentre raccontava in dettaglio allo staff cosa avrebbe voluto, c'erano sempre degli scettici che spiegavano perché era impossibile. Ciò è andato avanti fino a quando ha iniziato a ricorrere a minacce spettacolari come la decapitazione o l'impiccagione a un gancio. Non ha mai più sentito la parola "no". Nessuno si è opposto a lui, ma i subordinati non hanno comunque rispettato la scadenza.

Idea n. 4. In qualsiasi organizzazione, la "politica perversa" può sorgere improvvisamente quando i leader a qualsiasi livello dimenticano gli interessi comuni e si preoccupano solo degli obiettivi personali, anche se sono direttamente opposti a quelli generali.

Di solito la politica perversa è combinata con minacce e motivazioni negative, sebbene possa assumere forme più eleganti. Le conseguenze possono essere qualsiasi, quindi se non riesci in qualche modo a fermarlo, devi essere pronto a smettere in qualsiasi momento.

Un lato della politica perversa è il "capo arrabbiato". Secondo DeMarco, alcuni leader sono come genitori severi che credono che "la cintura non sia mai abbastanza". Sono loro a cui piace fissare scadenze irrealistiche e punirli per il mancato rispetto, sebbene essi stessi siano ben consapevoli dell'impraticabilità delle loro istruzioni. Il cattivo Mr. Bellock (un tipico "politico pervertito") è un sostenitore di continui strappi e esercitazioni. Il dipendente, a suo avviso, dovrebbe essere colpito nel naso ogni giorno alla scadenza del progetto e ricordargli che non sta affrontando i suoi doveri.

Ma proprio come i bambini che vengono costantemente puniti prima o poi impareranno a imbrogliare e ingannare i genitori severi, così i subordinati impareranno a imbrogliare ea non essere veloci. Puoi costringere una persona a fare gli straordinari, ma la sua produttività non aumenterà da questo: non penserà più velocemente. I programmatori sanno come ingannare le autorità - dopotutto, nelle parole di uno degli eroi, sono "cinici nati".

La rabbia e la mancanza di rispetto vengono trasmesse lungo la catena dai top manager ai quadri intermedi. Nel frattempo, secondo De Marco, se il capo si abbatte costantemente sui suoi subordinati, significa che è ora di rimuoverlo dal suo incarico, poiché dietro la rabbia c'è sempre la paura.

Altre forme di politica perversa sono la malizia e l'avarizia, che si basano sempre sulla paura del fallimento.

Idea n. 5: i team software hanno inevitabilmente conflitti di interesse che devono essere gestiti da un intermediario catalizzatore.

Notando che ci sono conflitti nei team, Tompkins convoca una riunione per discutere il problema. Innanzitutto, durante la discussione, nascono pensieri su seminari di formazione, invitando un esperto di conflitti internazionali, studiando la letteratura pertinente. Infine, uno degli assistenti di Tompkins, il generale Markov, propone la candidatura dell'ex maestra d'asilo, il maestro Dianyar, che non sembra fare niente di speciale, ma i conflitti in sua presenza si attenuano da soli, e non capisce nemmeno come questo accade. Queste persone DeMarco le chiama "l'uomo catalizzatore".

Il team di Tompkins riesce comunque a procurarsi un esperto professionista per una sera, e anche a lui viene in mente l'idea di un intermediario terzo che aiuti a trovare una soluzione accettabile per tutti. Alle parti in conflitto deve essere spiegato che in realtà sono persone che la pensano allo stesso modo e il vero nemico è il loro problema comune.

L'uomo catalizzatore, il Maestro Dianyar, accettato nella squadra in conflitto, non ha fatto nulla di speciale: ha solo raccontato storie adatte all'occasione. All'inizio, questo ha infastidito molti, poi le persone hanno tirato fuori idee e morale da ciascuna di queste storie, e gradualmente i conflitti sono svaniti.

Le persone-catalizzatori, secondo DeMarco, aiutano a unire la squadra, a sentire un obiettivo comune, anche se esteriormente non sembrano fare niente di speciale. Il loro ruolo è particolarmente importante per la risoluzione dei conflitti.

Idea n. 6. La gestione del progetto è la gestione del rischio

Prima di procedere con la realizzazione del progetto, occorre individuarne i punti deboli e valutarne le conseguenze. Crea un elenco di tali punti deboli, stima il loro costo e trova un indicatore che indichi che il rischio è diventato un problema.

Molte organizzazioni non comunicano i rischi ai superiori. Impara tutto per ultimo, quando non è più possibile nascondere il problema. Dobbiamo trovare un modo per farlo in tempo, attraverso fonti anonime o attraverso una persona specifica che gestisce i rischi.

Idea n. 7. Il processo di sviluppo dei programmi e gestione dei progetti è opportunamente modellato utilizzando i disegni.

Per calcolare i rischi e comprendere i principi del progetto, secondo DeMarco, è possibile costruire modelli che rappresentino chiaramente tutte le ipotesi. I personaggi del libro disegnano costantemente diagrammi per supportare le loro teorie, discutendole con i colleghi e correggendole nel corso della discussione.

Al termine del progetto sarà interessante confrontare il risultato reale con il modello mostrato, verificando così se le ipotesi erano corrette.

Idea n. 8. Uno degli obiettivi principali di qualsiasi progetto di sviluppo software è un team ben coordinato, pronto a lavorare insieme e oltre.

I progetti, come i leader, vanno e vengono, ma le persone restano. Hanno imparato a lavorare insieme, il che non è facile quando si costruisce un prodotto. Non è necessario aggiungere nuovi arrivati ​​al loro team ben coordinato e inevitabilmente dedicare del tempo alla loro formazione. Non sono scossi dai conflitti, si capiscono perfettamente. Se nel corso del lavoro è stato possibile creare almeno una di queste squadre di persone che la pensano allo stesso modo che lavorano come un unico organismo, allora nessuna scadenza è terribile per lei. Sanno come gestire correttamente il loro tempo.

Questo libro è utile?

Il libro spiega in modo semplice e chiaro le basi della teoria del management, i principi del lavoro con il personale, poiché, secondo l'autore, non ci sono progetti senza persone, che i manager non sempre comprendono. Insegna come affrontare i conflitti e rispettare le scadenze. Allo stesso tempo, aiuta a riconoscere in tempo i segni di una "politica perversa" e la posizione precaria dell'organizzazione, quando è molto più ragionevole lasciare i suoi ranghi che combattere l'assurdità e l'incompetenza della leadership.

In generale, il libro sarà utile sia al leader che al dipendente ordinario. E, naturalmente, il libro è stato a lungo una lettura obbligatoria per coloro che creano prodotti software.

Quali sono i vantaggi del libro

I punti di forza del libro includono la sua sincerità e il calore con cui DeMarco parla del lavoro con le persone. Ci sono molte sottigliezze in questo lavoro che non sono state toccate dagli autori di altri romanzi d'affari. L'autore ha un grande senso dell'umorismo, un buon linguaggio, talento come scrittore (non per niente è passato di recente alla narrativa, meritando il plauso della critica). A volte nel libro compaiono caratteristiche di satira sociale, a volte - un romanzo utopico, che distrae leggermente dalla linea principale, ma non la rovina.

Ci sono difetti nel libro?

Gli svantaggi includono un numero enorme di personaggi secondari. Alcuni personaggi appaiono solo per dire poche parole e scompaiono per sempre. Forse l'autore aveva le sue idee (come l'avversario di qualsiasi riduzione del personale), ma non sono molto chiare al lettore.

Inoltre, dovrebbe essere tenuto conto del tempo di pubblicazione del romanzo - 1997. Da allora sono apparsi nuovi approcci alla gestione dei progetti basati sulla flessibilità (""), quindi il lettore non troverà nel libro informazioni complete e aggiornate sulla gestione dei progetti.

Tuttavia, i meriti del libro di DeMarco compensano ampiamente i suoi difetti, e persino i critici del libro e l'abilità letteraria di Tom DeMarco generalmente riconoscono che il libro contiene molte idee utili sulla gestione dei progetti.