Come strutturare un team di sviluppo

Sono il manager di un team di 11 sviluppatori di software che si occupano dei siti Web / delle applicazioni Web della mia azienda, eseguendo fino a 4 progetti simultanei più il supporto quotidiano in qualsiasi momento. All'interno degli 11 sviluppatori c'è un mix di competenze tecniche, titoli di lavoro ed esperienza, anche se la struttura del team è piatta con tutti gli 11 sviluppatori che riportano direttamente a me.

L'intero team che ha un unico manager sta iniziando a dimostrare di non scalare molto bene. Sto iniziando a diffondermi in modo troppo sottile, quindi desidero ridurre il mio numero di rapporti diretti. Tutti i modi in cui posso pensare di fare questo hanno degli svantaggi significativi:

• Chiedi agli sviluppatori junior di riferire a quelli senior. Ciò riduce il tempo dedicato allo sviluppo dai migliori tecnici.
• Dividi il team in base al prodotto software, ad esempio gli sviluppatori 1-6 lavorano su intranet e 7-11 lavorano su siti esterni, con ogni sezione con un nuovo team leader (possibilmente una nuova descrizione del lavoro con più responsabilità di gestione / mentoring / coaching rispetto agli attuali sviluppatori senior ). Ciò aggiunge silos artificiali e potrebbe rendere difficile far funzionare uno "sviluppatore intranet" su un sito Web esterno, se lo desidero.
• Mantieni la struttura piatta e aggiungi il supporto manageriale sotto forma di project manager / amministratori del team solo per ridurre la pressione. Questo non risolve il problema in quanto il team non può continuare a crescere così per sempre.

Esiste un modo standard per risolvere questo problema che mi manca?

In caso contrario, in che modo altri di voi hanno risolto questo problema?

Alcuni pensieri rapidi:

• I sottogruppi sono una buona idea: 11 rapporti diretti senza alcuna struttura sono troppo grandi per un gruppo praticabile (non avrai abbastanza tempo per il coaching diretto e gli incontri di gruppo con così tante persone tenderanno a non essere produttivi).
• Prendi in considerazione la possibilità di separare le operazioni dallo sviluppo: si tratta di un insieme di competenze leggermente diverso e di essere interrotto da problemi operativi tutto il giorno può danneggiare seriamente la produttività di sviluppo dei progetti.
• Come risultato dei primi due punti, penso che dovresti avere forse 3 sottoteam: Intranet, Siti esterni e Operazioni. I ragazzi delle operazioni si occuperanno di tutte le problematiche quotidiane / correzioni di manutenzione ecc. Mentre i due team di sviluppo si concentrano sulla fornitura di nuovi progetti / valore per l'azienda.
• Ciclare le persone tra i team su base regolare. Questo può essere occasionale (ad es. Chiedere alle persone di rivedere il codice in un altro sottogruppo), per un progetto o su base permanente. Ma assicurati che i ruoli del team cambieranno ogni volta che c'è un bisogno aziendale - nessuno "possiede" un ruolo specifico per sempre.
• Non aggiungere più manager / amministratori: questo è un modo infallibile per ridurre l'efficacia / produttività complessiva dei tuoi team. Chiedi alla persona con più esperienza in ogni sottogruppo di svolgere un ruolo guida / allenatore. Assicurati di vedere qui il loro ruolo di coaching e di far funzionare l'intera squadra, e assicurati che siano attrezzati per comportarsi in questo modo piuttosto che agire come un "task manager".
• Il tuo ruolo dovrebbe essere incentrato sulla gestione delle parti interessate esterne, sulla definizione delle priorità delle risorse / attività all'interno del gruppo e sulla funzione di "capo allenatore". Dovrai gestire il problema occasionale intensificato dai sotto-team, ma in generale dovresti incoraggiarli a risolvere i problemi da soli senza venire da te.
• Se sei altamente tecnico tu stesso puoi anche scegliere di ricoprire un ruolo di architetto / progettista. In caso contrario, trova qualcuno che può, all'interno del team o altrove .....

Inoltre, vale sempre la pena andare e (ri) leggere il Manifesto Agile , e in particolare i dodici principi .

Questa struttura sarà principalmente depend on project specifications

Idealmente, ci dovrebbero essere 3 junior per sviluppatore senior in una squadra. Di conseguenza, ci sono 2-3 sviluppatori senior per un lead di insegnamento.

Pertanto, solo i lead tecnici riferiranno al PM sullo stato di avanzamento del progetto. La struttura descritta presuppone ancora che per problemi non tecnici (ferie, ferie, conflitti, ecc.) Tutti possano avere accesso a PM.

Uno dei team di sviluppo software relativamente riusciti a cui facevo parte è andato in questo modo, per progetto:

Un responsabile dello sviluppo software / sviluppatore senior / mentore, a cui tutti gli altri hanno riferito direttamente.

• Un project manager, che ha tenuto gli orari, facilitato i requisiti e la negoziazione di accettazione e ha fatto comunicazioni. Anche tutti i punti tratteggiati hanno riferito a questa persona. Una persona di documentazione (che occasionalmente era anche il PM, ma solo quando le competenze lo consentivano).
• Un mix di 1-3 sviluppatori o sviluppatori senior, a seconda delle esigenze del progetto.
• Uno sviluppatore junior quando disponibile.
• Qualcuno assegnato da un pool di QA.
• Una persona di infrastruttura (un ruolo spesso ricoperto dal gestore, dal momento che aveva anche una solida competenza SA).

Ha funzionato perfettamente e ho adorato quell'organizzazione. D'altra parte, ero il responsabile dello sviluppo del software e la struttura organizzativa del team si stava evolvendo.

Considerare di seguire il modello di organizzazione del personale funzionale . Ciò parlerebbe della tua seconda opzione di divisione del team per prodotto software.

Per citare l'articolo nel tuo contesto:

Il più grande punto di forza di un'organizzazione funzionale è che lega le strutture sociali alla consegna del valore aziendale. Dal mio punto di vista, i progetti software riescono tanto quanto migliorano l'efficacia dell'attività che supportano, dando valore al business. Organizzando i tuoi team allo stesso modo, hai un team orientato a soddisfare i loro utenti aziendali.

L'attuale struttura di gestione / risorse umane è irrilevante oltre a ciò.

Esiste un modo standard per risolvere questo problema che mi manca?

Non proprio. Dipenderà dal tuo team, da te, da cosa devi fare e da quali risorse la società ti metterà a disposizione.

Personalmente, il miglior tipo di switch è quello di dividere la gestione tecnica dalla gestione amministrativa. È raro che le persone siano brave in entrambi e raramente tendono a interagire.

Una persona gestisce gli aspetti tecnici. Cosa bisogna fare, chi lo farà, come devono essere allineate le cose. L'altro gestisce gli aspetti amministrativi. Recensioni, riunioni di bilancio, pianificazione del prodotto, ecc. Lavorano quindi insieme per comunicare approfondimenti da una parte all'altra e fornire un fronte unito.

Il modo in cui questo viene suddiviso può andare in diversi modi. Il più comune è che il responsabile tecnico sia il lato amministrativo e un architetto sia il lato tecnico. Sono colleghi e riferiscono a un regista / vicepresidente.

Un altro lavoro che ho visto è far sì che il responsabile tecnico sia la persona amministrativa, e quindi il capo / i team agisca come persona tecnica. Questo è più complicato e richiede che le persone giuste agiscano come (principalmente) coetanei anche se il reporting è gerarchico.

Per il tuo scenario specifico, consiglierei di avere 2-3 team e di avere lead tecnici che fanno gli aspetti tecnici e ti concentri sull'amministrazione. Sì, riduce il tempo dai lead che scrivono il codice, ma dovrebbero (se stanno facendo un buon lavoro) recuperare quel tempo rendendo gli sviluppatori più giovani più efficienti / produttivi. Fornisce loro più motivazione e un senso di realizzazione anche con la promozione effettiva. E praticamente, è una vendita più facile per il management rispetto all'apertura di una nuova posizione.