Come dovrebbe essere distribuita l'abilità attraverso i team?

Ci sono alcuni rischi noti con gli A-Teams, ma se le dinamiche sono corrette allora penso di sì, metterei le mie persone più forti sui progetti più importanti insieme agli sviluppatori più giovani con il maggior potenziale. Per i tuoi progetti a priorità più bassa hai bisogno di un buon caposquadra se non riesci a farli andare lontano dai binari. Il debito tecnico sta per accadere, non importa quale. Non tutto il debito tecnico è uguale; il costo / la responsabilità del debito tecnico è in primo luogo proporzionale al valore commerciale del progetto, quindi, mentre i progetti a priorità più bassa potrebbero avere più verruche, il costo di questi è probabilmente ancora molto inferiore rispetto a problemi significativi relativi ai vostri progetti ad alta priorità essere.

Ricordo quando ero all'università uno dei nostri professori che ci raccontava un aneddoto sulle strutture della squadra (ho dato un'occhiata al documento di cui stava parlando solo ora ma non riesco a trovarlo).

Fondamentalmente, la storia è andata come segue:

Un gruppo di programmatori è stato diviso in gruppi in base all'abilità, con i peggiori programmatori x raggruppati, i successivi x raggruppati, ecc. e i migliori raggruppati.

A tutti è stato assegnato lo stesso compito e gli è stato assegnato un intervallo temporale in cui completarlo.

Alla fine del periodo di tempo gli organizzatori hanno esaminato le soluzioni per i compiti e, con loro sorpresa, hanno scoperto che la soluzione migliore proveniva dal team composto da persone medie. Al contrario, il team composto dai programmatori A * ha creato una delle peggiori soluzioni perché ha speso tutto il suo tempo discutendo su quale fosse la soluzione migliore .

Se hai bisogno di una squadra che farà fare un sacco di ragazzi medi e un ragazzo dominante che può guidare, è stata la conclusione dello studio (se ricordo bene), altrimenti i membri più importanti passeranno più tempo combattere piuttosto che fare cose fatte!

La stragrande maggioranza degli sviluppatori inesperti potrebbe non essere in grado di creare da soli modelli robusti ed eleganti, ma possono riconoscerli e comprenderli quando ne vedono uno. Se non ci riescono, in genere non hanno né l'attitudine né la preparazione per essere stati assunti in primo luogo.

Ci sono anche alcuni sviluppatori più esperti che sono in grado di comprendere progetti software molto complessi, ma non hanno la discrezione di sapere quando qualcosa di più semplice sarebbe meglio.

Nella mia esperienza, di solito, i team misti hanno solo problemi permanenti se contengono membri non preparati, membri inutilmente complessi o entrambi. Altrimenti, se la tua squadra ha problemi, di solito possono essere risolti con una comunicazione migliore o l'assegnazione di ruoli appropriati.

Il raggruppamento delle persone migliori in un singolo team può sembrare un'ottima soluzione a breve termine, ma è un fallimento a lungo termine e comporta costi aggiuntivi. Ad esempio, la mia azienda preferisce che le persone imparino dai loro colleghi più esperti invece di pagare per i corsi di formazione. Se separi le persone migliori, non saranno in grado di trasferire conoscenze a persone meno esperte. A breve termine, le migliori squadre possono ottenere buoni risultati, ma a causa della carenza di conoscenze trasferite, il numero di persone qualificate non aumenterà. È molto meglio avere una squadra meno rappresentata all'inizio e aumentare le prestazioni su tutti i team man mano che le persone diventano più abili.

Inoltre cosa succede se persone esperte decidono di andarsene? Chi prenderà i loro progetti?

Un altro punto è che la squadra dovrebbe essere composta da persone con diverse abilità. Avrai sempre compiti facili (e noiosi) che sono troppo costosi per essere eseguiti dagli sviluppatori più anziani.

Quelli che non possono insegnare, fai ...

Penso che ci siano più fattori da considerare.

Otterrai il massimo valore distribuendo quelli che possono insegnare come lead del team. Possono insegnare agli altri membri della squadra e contribuire ad elevare la qualità del loro lavoro.

Non tutti i programmatori esperti faranno buoni progressi. Quella capacità di comunicare informazioni è un'abilità in sé e per sé. Questa abilità non è qualcosa che si sviluppa attraverso l'esperienza di programmazione. Si sviluppa attraverso l'insegnamento e la spiegazione.

L'assegnazione di una squadra "A" ha due problemi significativi. Il primo è la compatibilità. Avere team che vanno d'accordo e lavorare bene insieme è molto più importante della loro "abilità". Ora questo può essere due programmatori di abilità "alti", due programmatori di abilità "bassi" o un mix. Il fatto che possano lavorare bene insieme significa che saranno più produttivi.

La seconda questione riguarda la crescita. Due programmatori di abilità "bassi" non impareranno molto l'uno dall'altro, oltre alle cattive abitudini. Allo stesso modo due programmatori esperti "alti" non impareranno molto l'uno dall'altro. Tuttavia, mescolare livelli di abilità "bassi" e "alti" aiuterà a migliorare le abilità dell'abilità "bassa" e migliorerà anche le abilità degli "esperti". Come? Provare a insegnare un soggetto troverà rapidamente i punti deboli in quel soggetto. Non considero un'abilità "padroneggiata" finché non la puoi insegnare a qualcun altro.

Dall'altro lato della medaglia, penso che abbia senso tenere squadre che possono "tenere il passo" l'una con l'altra. I tuoi programmatori di tipo A non vogliono aspettare i tipi di B-Team per ottenere i loro bit. I tuoi tipi di B-Team potrebbero essere intimati dal flusso di lavoro in stile A-Team.