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

10

Il mio team di 4 sviluppatori esperti lavora su una grande applicazione Windows modulare (circa 200 KLoC). Mi sono concentrato sul codice base originario dall'inizio del progetto (3 anni fa) e gradualmente sono passato a una posizione di sviluppatore di semi-conduttori, anche se non sono il responsabile della squadra.

La nostra iterazione corrente è un aggiornamento dell'interfaccia utente ad alta priorità richiesto dal management superiore, che comporta circa 15 modifiche alla base di codice principale. Quando ho chiesto al gestore, ho stimato che ciascuna delle 15 modifiche avrebbe richiesto meno di quattro ore per il completamento di , per un totale di meno di 7 giorni lavorativi. Allora mi sono offerto volontario per eseguire il lavoro. Invece, il manager ha deciso di dividere in modo uniforme tutti e 15 i compiti 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 task ciascuno.

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

Mi sono avvicinato al mio manager con la mia preoccupazione per il fatto che eravamo in ritardo e di nuovo ho suggerito di completare le attività rimanenti. La mia richiesta è stata gentilmente respinta, e le ragioni dichiarate per suddividere il carico in modo uniforme erano duplici:

  1. Limita il fattore camion / autobus - aumentando gli altri sviluppatori su queste abilità ora, così che in futuro qualsiasi lavoro possa essere dato a chiunque, non solo a me.
  2. Eliminare un "collo di bottiglia" (io) e portare a termine il lavoro più rapidamente.

Per essere chiari, non ho problemi con: a) investire il tempo nell'insegnamento, b) le persone che toccano il mio codice, o c) la sicurezza del lavoro. In effetti, suggerisco regolarmente al team leader di addestrare altri sviluppatori su alcuni aspetti del corebase 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 più progressi se il carico di lavoro fosse ridistribuito.

In Mythical-Man-Month, Brooks suggerisce un " Team chirurgico " dove ogni squadra è composta da un lead + sub-lead (il manager e me) e alcuni ruoli minori. Mi sento come se cadessimo naturalmente in questa organizzazione, ma il mio manager sta lavorando contro di essa. Sento che il fattore bus è già stato curato (il manager è ben preparato nel codice core) e che il collo di bottiglia non esiste realmente (il coinvolgimento di più sviluppatori non renderà il lavoro più veloce). Penso che a questo proposito, un team chirurgico è una buona cosa.

Questi sono i miei sentimenti, ma non sono un manager esperto, né abbiamo dovuto affrontare il fattore bus (knock on wood). Was Brooks ha ragione? Hai lavorato in un "Team chirurgico" in cui è entrato in gioco il fattore bus? Esistono tecniche migliori per la gestione delle competenze di distribuzione?

Domande simili:

posta Kevin McCormick 13.08.2012 - 21:34
fonte

4 risposte

5

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

Parte del punto di tale modello è che i membri della squadra in basso hanno un ruolo di assistente. Quando la squadra non sta operando al cuore, allora va bene spostarsi più lentamente e dare loro la possibilità di mettere in pratica alcune delle loro abilità o di allenarsi in modo responsabile.

È compito del chirurgo esaminare e gestire la propria squadra cercando i punti deboli e risolvendoli, oltre a essere il principale sviluppatore. Non puoi fare un chirurgo (manager aziendale), perché non capiscono 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 durante il corso del gioco si rivela qualche difetto nella squadra, può affrontarlo prima che diventi un problema. Dì, assumendo un altro sviluppatore.

Oppure, i ragazzi potrebbero commettere un errore. Questo è il momento perfetto per loro di farlo, dal momento che hanno qualcuno che veglia sulle loro spalle. Oscar Wilde ha detto

Experience is simply the name we give our mistakes.

Se questi junior non hanno mai l'opportunità di to commettere errori, allora non miglioreranno mai. Non solo rapinerà il tuo team di sviluppatori esperti con esperienza, ma in un certo senso li derubò di un'opportunità che avrebbero dovuto avere.

    
risposta data 13.08.2012 - 22:45
fonte
7

La nostra azienda lavorava come suggerivi. Avevamo solo due persone che capivano una parte critica del codice. Ogni volta che un compito veniva visualizzato in quella parte del codice, invece di dedicare alcune settimane a velocizzare l'esecuzione di qualcun altro, l'attività veniva assegnata a loro perché potevano completarla in un paio di giorni. Questo ha funzionato abbastanza bene per un po '.

Quello che è successo è che il loro piatto è diventato così pieno che, anche se potrebbero essere in grado di completare un compito in 2 giorni, ci vorrebbero settimane per passare in cima alla loro lista. I dirigenti avrebbero avuto feroci battaglie verbali sul cui compito era più urgente. Le mansioni urgenti dipendenti si troverebbero disfatte.

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 throughput è molto migliore.

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

Sì, è frustrante vedere qualcuno sfidare qualcosa che potresti fare molto più rapidamente e facilmente da solo. Prova a fare i genitori a un bambino di due anni. Lo fai perché aiuta tutto il team a migliorare. È compito del tuo manager preoccuparsi del programma. Se sei preoccupato per i bug incompleti ad alta priorità, sfidati a vedere quanto velocemente puoi correggerli.

    
risposta data 13.08.2012 - 22:46
fonte
6

Ora potresti non essere un collo di bottiglia, ma alla fine lo sarai se continuerai a fare tutto da solo. Il tuo manager si rende conto che è abbastanza importante imparare a delegare a rischio che il tuo progetto sia in ritardo: fidati di lui. Una volta che hai imparato a lasciar andare, i tuoi junior inizieranno ad imparare e produrre molto di più sotto la tua guida.

    
risposta data 13.08.2012 - 22:05
fonte
3

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 dai vincoli di tempo percepiti.

Se tieni il tempo di consegna fuori dalla tua domanda, inizierai rapidamente a chiedervi perché state ponendo la domanda in primo luogo.

Questo non vuol dire che il tempo sia sempre disponibile, e hai affermato che questa è una richiesta di alta priorità da parte del management superiore. Ma non sei al corrente di tutte le conversazioni che il tuo capo ha avuto con loro. Potrebbe aver negoziato per più tempo per farti trascorrere quel tempo allenando gli altri membri della squadra.

E mentre senti che il fattore bus è già stato risolto, il tuo capo potrebbe essere alla ricerca della prossima richiesta di che non si inserisca facilmente in 7 giorni di lavoro da uno dei suoi sviluppatori di stelle. È molto più sicuro addestrare 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 da essere. Nel mio caso, il vicepresidente dell'IT e io abbiamo parlato e abbiamo elaborato un piano per risolvere il problema in modo permanente. Faceva male, ma faceva molto meno male di quanto fossi stato trasportato.

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

    
risposta data 13.08.2012 - 22:43
fonte

Leggi altre domande sui tag