Il "team chirurgico" di Fred Brooks gestisce efficacemente il fattore bus?

Il mio team di 4 sviluppatori esperti lavora su un'applicazione Windows modulare di grandi dimensioni (circa 200 KLoC). Mi sono concentrato sul codebase di base dall'inizio del progetto (3 anni fa) e sono gradualmente passato a una posizione di sviluppo semi-lead, anche se non sono il team manager.

La nostra attuale iterazione è un aggiornamento dell'interfaccia utente ad alta priorità richiesto dalla direzione superiore, che comporta circa 15 modifiche alla base di codice principale. Quando mi è stato chiesto dal direttore, ho stimato che per completare ciascuna delle 15 modifiche ci sarebbero volute meno di quattro ore, per un totale di meno di 7 giorni lavorativi. Mi sono quindi offerto volontario per eseguire il lavoro. Invece, il manager ha deciso di dividere equamente tutte e 15 le attività per tutti e quattro gli sviluppatori.

Nei tre giorni da quando abbiamo iniziato a lavorare, ho osservato due cose:

1. Gli altri membri del team inesperti hanno completato circa 1 o meno attività ciascuno.

2. Legge di Brook in azione: ho trascorso circa la metà del mio tempo a fornire assistenza (tentando di istruirli sull'uso dei componenti). Di conseguenza, ho terminato solo 2 compiti da solo, anziché i 5 o 6 previsti.

Mi sono avvicinato al mio manager con la preoccupazione che eravamo in ritardo e ho suggerito di nuovo di completare le attività rimanenti. La mia richiesta è stata gentilmente rifiutata e i motivi dichiarati per dividere il carico in modo uniforme erano duplici:

1. Limita il fattore camion / autobus - intensificando gli altri sviluppatori su queste abilità ora, in modo che in futuro qualsiasi lavoro possa essere dato a chiunque, non solo a me.
2. Per eliminare un "collo di bottiglia" (me) e svolgere il lavoro più velocemente.

Per essere chiari, non ho problemi con: a) investendo tempo nell'insegnamento, b) persone che toccano il mio codice, o c) sicurezza del lavoro. In effetti, suggerisco regolarmente al team leader di addestrare altri sviluppatori su alcuni aspetti della base di codice principale per ridurre il rischio.

In questa iterazione abbiamo anche una vasta raccolta di correzioni di bug ad alta priorità mirate, quindi sembrerebbe che si potrebbero fare ulteriori progressi se il carico di lavoro fosse ridistribuito.

In Mythical-Man-Month, Brooks 'suggerisce un " Team chirurgico " in cui ogni team è composto da un lead + sub-lead (il manager e io) e alcuni ruoli minori. Sento che stiamo naturalmente cadendo in questa organizzazione, ma il mio manager sta lavorando contro di essa. Sento che il fattore bus è già curato (il manager è ben versato nel codice di base) e che il collo di bottiglia in realtà non esiste (coinvolgere più sviluppatori non renderà il lavoro più veloce). Penso che a questo proposito, un team chirurgico sia una buona cosa.

Questi sono i miei sentimenti, ma non sono un manager esperto, né abbiamo dovuto fare i conti con il fattore bus (knock on wood). Brooks aveva ragione? Hai lavorato in un "team chirurgico" in cui è entrato in gioco il fattore bus? Esistono tecniche migliori per gestire le competenze distributive?

Domande simili:

• Come aumentare il fattore bus e specializzarsi allo stesso tempo?
• /software/103718/always-keeping-2-people-expert-on-any-one-chunk-of-code

In realtà, direi che stai seguendo il modello del "team chirurgico". Fortunato!

Parte del punto di detto modello è che i membri del team inferiore hanno un ruolo di assistente. Quando il team non sta eseguendo un intervento chirurgico al cuore, allora va bene muoversi più lentamente e dare loro la possibilità di esercitare alcune delle loro abilità o di allenarsi in modo incrociato nelle responsabilità.

È compito del chirurgo esaminare e gestire il proprio team alla ricerca di punti deboli e risolverli, oltre ad essere il miglior sviluppatore. Non puoi far fare questo a un non chirurgo (direttore aziendale), perché non comprendono le competenze richieste, un po 'come un apprendista di un maestro artigiano.

Quindi, il manager sta approfittando di questa opportunità per lavorare su uno dei suoi altri obiettivi. Se nel corso di esso, viene rivelato un difetto nella squadra, può affrontarlo prima che diventi un problema. Ad esempio, assumendo un altro sviluppatore.

Oppure, i giovani potrebbero commettere un errore. Questo è il momento perfetto per loro, dal momento che hanno qualcuno che li guarda da sopra le spalle. Disse Oscar Wilde

L'esperienza è semplicemente il nome che diamo ai nostri errori.

Se questi junior non hanno mai l'opportunità di commettere errori, non miglioreranno mai. Non solo deruberà il tuo team di futuri sviluppatori esperti, ma in un certo senso li deruba di un'opportunità che avrebbero dovuto avere.

La nostra azienda lavorava come da te suggerito. Avevamo solo due persone che comprendevano una parte critica del codice. Ogni volta che veniva posta un'attività in quella parte del codice, piuttosto che passare qualche settimana a velocizzare qualcun altro, l'attività veniva assegnata a loro perché potevano completarla in un paio di giorni. Questo in realtà ha funzionato abbastanza bene per un po '.

Quello che è successo è che alla fine il loro piatto è diventato così pieno che, anche se potrebbero essere in grado di finire un compito in 2 giorni, ci vorrebbero settimane per spostarsi in cima alla loro lista. I dirigenti avrebbero avuto feroci battaglie verbali per i quali il compito era più urgente. Compiti urgenti dipendenti sarebbero stati annullati.

Alla fine i manager si sono stancati di aspettare e hanno iniziato a formare le proprie squadre. Sì, è stato molto più lento per un po ', ma ora il nostro rendimento è molto migliore.

Ora potresti essere in quella prima fase in cui puoi gestire il lavoro, ma non hai modo di prevedere quando ti sposterai nella seconda fase. Ecco un suggerimento: succede sempre nel momento più scomodo possibile. Il tuo manager ha ragione a prendere il colpo quando hai ancora un po 'di respiro.

Sì, è frustrante vedere qualcuno che lotta con qualcosa che potresti fare molto più rapidamente e facilmente da solo. Prova a diventare genitore un bambino di due anni prima o poi. Lo fai perché aiuta l'intero team a migliorare. È compito del tuo manager preoccuparsi del programma. Se sei preoccupato per i bug annullati ad alta priorità, mettiti alla prova per vedere quanto velocemente puoi risolverli.

Ora potresti non essere un collo di bottiglia, ma alla fine lo sarai se continui a fare tutto il lavoro da solo. Il tuo manager si rende conto che è abbastanza importante per te imparare a delegare per rischiare che il tuo progetto sia in ritardo - fidati di lui. Una volta che impari a lasciarti andare, i tuoi ragazzi inizieranno a imparare e produrre molto di più sotto la tua guida.

Stai applicando un vincolo che potrebbe non essere presente o significativo nella misura in cui pensi che sia. In particolare, sei preoccupato per il tempo fino al completamento. Il tuo manager, d'altra parte, non sembra preoccupato per i vincoli temporali percepiti.

Se prendi i tempi di consegna fuori dalla tua domanda, inizierai presto a chiederti perché stai ponendo la domanda in primo luogo.

Questo non vuol dire che il tempo è sempre disponibile e hai dichiarato che si tratta di una richiesta prioritaria da parte dell'alta direzione. Ma non sei a conoscenza di tutte le conversazioni che il tuo capo ha avuto con loro. Potrebbe aver negoziato per più tempo per farti passare quel tempo ad addestrare gli altri membri del team.

E mentre ritieni che il fattore bus sia già stato affrontato, il tuo capo potrebbe essere alla ricerca della prossima richiesta in arrivo che non si inserirà facilmente in 7 giorni di lavoro da uno dei suoi sviluppatori principali. È molto più sicuro formare la squadra su una iterazione più piccola in cui l'entità obiettiva del rischio è molto più piccola.

Sono stato un collo di bottiglia critico prima; e onestamente, non è un posto piacevole dove stare. Nel mio caso, il vicepresidente dell'IT e io abbiamo parlato e abbiamo elaborato un piano per risolvere definitivamente il problema. Faceva male, ma faceva molto meno male di quanto fossi stato trasportato su camion.

È facile entrare nella mentalità di tutto ciò che deve essere eliminato il più rapidamente possibile. Un buon manager individua le rare opportunità in cui un piccolo ritardo (per cross-training / istruzione) può pagare dividendi significativi in ​​un secondo momento.