Riesci a gestire con successo quando sei costretto a tornare in sviluppo?

Conosci il detto "non riesci a vedere la foresta per gli alberi". Quando stai gestendo, il tuo lavoro è tendere la foresta. Quando scrivi il codice, il tuo compito è far crescere un albero. Ho scoperto che quando togli le mani dal codice, sono un manager migliore. Sono in grado di interagire con la mia squadra e mantenere il polso del progetto. Il secondo che scrivo per scrivere codice, quella vista di alto livello deve andare via o non sarò un programmatore efficace.

Non conosco un modo per aggirare questo, non puoi gestire una squadra e scrivere codice allo stesso tempo. Di conseguenza, una o l'altra di queste attività ne risentirà.

Ho avuto un problema molto simile. Un lavoro di gestione che non era al 100%, ma se avessi provato a lavorare sullo sviluppo con il resto del mio tempo, sono diventato un collo di bottiglia, soprattutto perché non potevo concentrarmi su un singolo compito di sviluppo per più di un paio di ore alla volta.

Il mio consiglio è di smettere di farlo e iniziare a dedicare quel tempo libero a chiarire la strada agli altri sviluppatori. Guarda tutto ciò che costa il tempo di sviluppo e chiedi cosa puoi fare al riguardo. Leggi la Consegna continua e scopri cosa puoi fare per migliorare il processo di generazione e rilascio. Dai un'occhiata alla copertura della tua unità e del test di integrazione.

Evita semplicemente di lavorare su attività che fanno parte dell'iterazione, a meno che tu non sia sicuro di poterle completare facilmente senza diventare un collo di bottiglia. Finché puoi puntare a un miglioramento della quantità di lavoro svolto, a nessuno interesseranno i dettagli di come hai trascorso il tuo tempo.

In base alla mia esperienza no, non sono riuscito a gestire bene lo sviluppo, ma allo stesso tempo non sono riuscito a fare molto con uno sviluppo sostanziale durante la gestione.

Ho anche assistito (in una vita precedente) al mio "capo" che ha lo stesso problema ...

Fondamentalmente questa è una variazione del problema descritto nell'eccellente articolo Calendario dei Makers, Programma del Gestore - quando sei sviluppando non vuoi fare nient'altro fino a quando non ti blocchi o hai finito a che punto vuoi andare dal tuo manager per aiuto / direzione. Allo stesso modo se sei il manager, sei il punto di contatto per le interruzioni esterne (e in effetti dovresti lavorare sodo per evitare che qualcuno interrompa gli sviluppatori e li faccia uscire dal loro groove). Ciò che equivale a questo è che se stai gestendo sei, almeno potenzialmente, in uno stato di costante interruzione da sopra e da sotto - e ciò vale per la tua capacità di codificare a qualsiasi livello sostenuto in quanto non puoi mai cancellare i mazzi. Se vai dall'altra parte, non riesci a gestire bene la tua squadra (concedi loro troppo margine di manovra e accadranno cose interessanti, e non sarà quello che vuoi ...)

Alla fine sono riuscito a trovare una posizione comoda in cui avrei potuto gestire bug e piccoli frammenti di roba da brividi, in cui avrei potuto confrontarmi con le cose a livello architettonico, dove ero felice di discutere i dettagli dell'implementazione (a vari livelli a seconda del programmatore) e potrebbe dirigere i miei sviluppatori mentre, per la maggior parte, non li interrompe. Le interruzioni esterne sono venute da me, quindi il resto degli sviluppatori ha dovuto fare cose. Mi sono preoccupato per il quadro generale, hanno fatto i grandi lavori.

Un ulteriore pensiero - mi sembra che le metodologie di stile agili con team sostanzialmente auto-organizzanti e concetti simili potrebbero andare a una certa distanza per renderlo più possibile rimuovendo parte del sovraccarico necessario, cioè rendendo più possibile fidarsi del tuo squadra di fare la cosa giusta da soli il più delle volte. Questo comunque non si occupa di fattori esterni.

No, a meno che tu non abbia intenzione di eseguire lo sviluppo al di fuori dell'orario di lavoro, non puoi fare tutto.

Condividete l'uno con l'altro su cosa state lavorando ogni giorno e sui progressi, in questo modo potrete cambiare tutte le priorità in base alle esigenze fino ad aumentare il numero di sviluppatori.

Assolutamente puoi indossare entrambi i cappelli allo stesso tempo, quanto efficacemente puoi farlo è in gran parte una questione di gestione del tempo.

La gestione è sia una serie di competenze che una descrizione del lavoro. Da ciò comprende varie attività che esegui. Quando gestivo un team di 10 persone, ero il responsabile delle risorse umane e il loro team tecnico. Ho assegnato il lavoro (sì, non agile ...) affrontato con piccole questioni di bilancio, noleggio di risorse umane generali / incendio / revisione / vacanze / ecc. roba e cose simili.

Alcuni di questi lavori aumentano il numero di persone gestite e alcuni sono riparati in base a sì / no. Il numero di dipendenti che hai non incide in modo significativo sulla durata del budget, ma influisce sul tempo necessario per eseguire le revisioni a metà anno e documentarle sulla soddisfazione delle risorse umane.

Con un team di 10 persone, ho principalmente supervisionato, recensito il codice ed ero la persona a rimbalzare idee. Con un team di soli 5, tuttavia, c'era molto più tempo per la vera codifica.

Per usare una formula grezza elaborata come un'analogia, la mia esperienza personale sarebbe qualcosa di simile

Dev-Time-As-Percent = 100 - Fixed-Managerial-Overhead - (Staff-Count * 5)

Qui presumo che ogni individuo rappresenti il 5% del mio tempo di lavoro - mediamente esaurito. Alcuni hanno bisogno di più in alcuni giorni, ecc. La parte fissa è quella che ho menzionato come budget, che tende ad essere invariata - o devo farne uno o non farlo. Il conteggio dello staff è anche un input per i numeri nel budget, ma il conteggio dello staff non cambia lo sforzo di creare molto il budget.

Che cosa tu fai con quel tempo residuo dipende da te e dal tuo capo! Nel mio caso, ho risolto il problema principalmente per tenere le mani sporche nel codice, e poiché il mio tempo era effettivamente variabile, non ero quindi un collo di bottiglia per funzioni più grandi.

Qualsiasi lavoro, come i bit su un disco rigido o mobili in una casa, può espandersi per riempire lo spazio (tempo) disponibile. Quindi tutto torna a gestione del tempo . Hai le cose di gestione fatto-fatto e puoi quindi fare altre cose? Oppure le cose di gestione prendono il 100% del tuo tempo indipendentemente dalle dimensioni del team?

Questo può funzionare bene se la "squadra" si riduce a una piccola dimensione, ad es. solo tu e un altro (esperto) sviluppatore, quindi non c'è più da gestire oltre a quello di uno sviluppatore autogestito. Certo, devi ancora pianificare caratteristiche, iterazioni, scadenze, ecc. Ma questo non è un conflitto eccessivo - se non del tutto - con il tuo ruolo di sviluppatore.

Ma se il numero di sviluppatori è ancora troppo grande per essere eseguito senza una corretta gestione, il piccolo output che è possibile produrre sul lato difficilmente compenserà il calo della loro produttività.