Come strutturare un team di sviluppo

Alcuni pensieri rapidi:

• I sottogruppi sono una buona idea: 11 rapporti diretti senza alcuna struttura sono troppo grandi per un gruppo lavorabile (non avrai abbastanza tempo per il coaching diretto, e le riunioni di gruppo con molte persone tenderanno a essere improduttive).
• Considerare la possibilità di separare le operazioni dallo sviluppo - è uno skillset leggermente diverso e essere interrotto da problemi operativi tutto il giorno può seriamente danneggiare la produttività dello sviluppo sui progetti.
• Come risultato dei primi due punti, penso che dovresti avere forse 3 sottogruppi: Intranet, Siti esterni e Operazioni. Le operazioni che i ragazzi affronteranno con tutti i problemi quotidiani / le correzioni di manutenzione ecc. Mentre i due team di sviluppo si concentrano sulla realizzazione di nuovi progetti / valore per il business.
• Pedala tra le squadre su base regolare. Questo può essere occasionale (ad es. Avere persone che riesaminano il codice in un altro sottogruppo), per un progetto o su base permanente. Ma assicurati che sia chiaro che i ruoli dei team cambieranno ogni volta che c'è un bisogno aziendale - nessuno "possiede" un ruolo specifico per sempre.
• Non aggiungere più gestori / amministratori: questo è un modo sicuro per ridurre l'efficacia / la produttività complessiva dei tuoi team. Avere la persona più esperta in ogni sottoteam gioca un ruolo di capocanti / allenatore. Assicurati che vedano il loro ruolo qui come coaching e facendo in modo che tutto il team abbia successo, e assicurati che siano attrezzati per comportarsi in questo modo piuttosto che agire come "task manager".
• Il tuo ruolo dovrebbe essere focalizzato sulla gestione degli stakeholder esterni, sulla prioritizzazione delle risorse / attività all'interno del gruppo e sulla funzione di "head coach". Dovrai gestire l'occasionale problema di escalation dei sottogruppi, ma in generale dovresti incoraggiarli a risolvere autonomamente i problemi senza venire da te.
• Se sei altamente tecnico, puoi anche scegliere di interpretare un ruolo di architetto / design assurance. In caso contrario, trova qualcuno che può, all'interno del team o altrove .....

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

Quella struttura sarà principalmente depend on project specifications

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

Quindi, solo i lead tecnologici faranno rapporto a PM sullo stato di avanzamento del progetto. La struttura descritta presuppone comunque che per problemi non tecnici (ferie, interruzioni temporanee, conflitti, ecc.) Tutti possano avere accesso a PM.

Uno dei team di sviluppo del software relativamente di successo ho preso parte a qualcosa del genere, in base al progetto:

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

• Un project manager, che manteneva gli orari, i requisiti agevolati e la negoziazione di accettazione, e faceva comunicazioni. Anche tutti i punti tratteggiati hanno riferito a questa persona. Una persona di documentazione (che occasionalmente era anche il PM, ma solo quando l'esperienza lo consentiva).
• 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 QA.
• Una persona di infrastruttura (un ruolo spesso adempiuto dal gestore, poiché anche lui aveva una solida competenza SA).

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

Considera di seguire il modello di organizzazione del personale funzionale . Ciò parlerebbe alla tua seconda opzione di dividere il team per prodotto software.

Per citare l'articolo nel tuo contesto:

The greatest strength of a functional organization is that it ties social structures to delivery of business value. In my view software projects succeed as much as they improve the effectiveness of the activity they support - yielding business value. By organizing your teams the same way, you have a team oriented around satisfying their business users.

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

Is there a standard way of solving this problem which I am missing?

Non proprio. Dipenderà dal tuo team, da te, da ciò che devi fare e da quali risorse l'azienda ti metterà a disposizione.

Personalmente, il miglior tipo di passaggio è suddividendo la gestione tecnica dalla gestione amministrativa. È raro che le persone siano brave in entrambi e raramente tendono ad interagire.

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

Il modo in cui questo è suddiviso può andare in diversi modi. Il più comune è avere il responsabile tecnico dal lato amministrativo e un lato tecnico. Sono colleghi e riferiscono a un direttore / vicepresidente.

Un altro lavoro che ho visto è quello di fare in modo che il responsabile tecnico sia la persona amministrativa, e quindi il / i capo / i della squadra agisce come una persona tecnica. Questo è più complicato e richiede che le persone giuste agiscano da pari (per lo più) anche se la segnalazione è gerarchica.

Per il tuo scenario specifico, consiglierei di avere 2-3 team e avere lead tecnici per gli aspetti tecnici e ti concentrerai sull'amministrazione. Sì, riduce il tempo dai lead che scrivono effettivamente 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 vera e propria. E praticamente, è più facile vendere alla gestione che aprire una nuova posizione.