Composizione di una squadra di sviluppo

Una squadra è un insieme di persone in cui ognuno può avere il proprio scopo basato sui propri punti di forza e competenze. Non c'è nulla di sbagliato in una squadra in cui tecnici specializzati e persone orientate più alla comunicazione che agli aspetti tecnici lavorano fianco a fianco.

Certamente, richiede una buona organizzazione e un rispetto reciproco . Esiste il rischio che le persone con una vasta esperienza tecnica e una buona conoscenza della base di codice utilizzino la propria conoscenza del codice base e le proprie capacità tecniche per considerarsi superiori, più intelligenti o di qualsiasi tipo e tentare di costringere tutti a concordare con le proprie decisioni.

Alcune situazioni possono aumentare questo rischio. Esempi:

• avere un "guru" in una piccola squadra e trattarlo costantemente come il meglio del meglio. Ad esempio se uno sviluppatore ha un'opinione, e il guru ha un'altra opinione, la cosa sbagliata per la direzione (project manager, direttore, ecc.) È dire: "è un guru, quindi fa quello che dice e sta zitto" ( oppure, in una forma più educata: "Ha abbastanza esperienza e conosce bene il codice base, quindi fidati di lui").

• avere un team separato di specialisti tecnici (è effettivamente il caso nella tua azienda?), per lo stesso motivo: se si isola un gruppo di persone e le si considera come il meglio del meglio, possono inizia a trascurare le opinioni di persone che non fanno parte della squadra.

Per quanto riguarda la tua seconda domanda, devi disporre di un background sufficiente per guidare un team di sviluppatori . Altrimenti, non solo non riuscirai a capire cosa stanno facendo, ma avranno anche la pessima impressione di essere guidati da una persona inesperta, evitando di farti domande.

Detto questo, no, non devi essere uno specialista tecnico . È un vantaggio, ma se devo scegliere tra una persona che ha buone capacità comunicative ma manca di alcuni tecnici, e un guru che non ha alcuna capacità di comunicazione, sceglierò sempre il primo.

Fantastic.

• Il tuo team è enorme ,
• la metodologia sembra piuttosto errata e scelta per il valore della buzzword ,
• i più esperti sono stati praticamente rimossi dal team (anziché dispersi in sub squadre equilibrate in cui possono contribuire e condurre) e inviati una ricerca magica su un'isola profonda del pensiero

Questi tre elementi portano a un'unica conclusione: il tuo manager agisce a caso .

... e ti preoccupi per il cliente? Voglio dire, il cliente è l'ultimo dei tuoi dubbi qui, (e sì, non dovrebbe venire l'ultimo, probabilmente siamo d'accordo), ma quello che vedo qui è: (scusate il mio francese)

• un grande fan,
• un cumulo di letame che cade lentamente su di esso,
• e tu nel mezzo, cercando di gettare il tuo peso fino in fondo nel ventaglio.

Stai lontano dai vecchi e dalle loro opinioni e prendi nota di come loro e quelle opinioni influiscono sul tuo lavoro, sul progetto, su come e quando: arriverà una pesante riorganizzazione , e vorrai avere fatti referenti per supportare la tua posizione e il tuo ruolo nella situazione.

Le responsabilità di guidare un team di sviluppo possono variare molto, dall'assegnazione di compiti, all'approvazione del codice per la produzione, alla progettazione dell'archittettura, alla decisione sulle figure di pianificazione o sui requisiti di formazione ecc., fino a compiti più banali come la concessione di richieste di ferie. Mentre è possibile delegare alcune delle attività ai membri del team, si avrà difficoltà a guidare una squadra del genere se non si ha esperienza in più di alcune categorie. Capire cosa fa il team e come funziona è importante.

Dalla domanda che ho raccolto la tua principale preoccupazione è che il team non ha competenze comunicative, quindi il coordinamento con altri dipartimenti (o clienti) e le esigenze di tracciamento rappresentano un problema. Sembra che la tua squadra trarrebbe beneficio dall'aggiungere un project manager o un manager di collegamento al team. Ciò non implica che un manager di questo tipo debba essere il capo della squadra o un direttore tecnico. Il suo lavoro è forzato a costruire un ponte tra i partner di comunicazione in difficoltà e a tradurre tra loro, non necessariamente a guidarli.

Questo richiede un po 'di altre risposte, ma sembra che tu abbia un team di sviluppo che non è focalizzato sul cliente come dovrebbe essere, e un manager che non lo ha capito e che non ha focalizzato il focus sul tuo gruppo di lavoro. I detenuti stanno gestendo il manicomio. Sembra che quello di cui hai bisogno sia il responsabile e il contatto con il cliente. Il manager crea l'elenco delle cose che il cliente desidera e gli sviluppatori devono farlo. In altre parole, devi entrare in modalità hamburger ("fammi un cheeseburger, no non mi interessa il tuo pattern di senape, nemmeno il cliente, basta fare l'hamburger in modo da poter iniziare con le patatine") fino a torni in pista Questo non significa che il manager debba essere duro, solo che sembra che tu abbia bisogno di una strong leadership reale (da qualcuno al di fuori del team di sviluppo).

In termini di domande:

1: Sì, ma l'accordo è lavoro con il cliente per scoprire cosa vogliono (di frequente) e quindi dire agli sviluppatori cosa costruire. La persona che lavora con il cliente aiuta il cliente a capire cosa vuole, gli sviluppatori non si limitano a sprecare denaro creando piccoli progetti per animali domestici che nessuno in realtà vuole o pagherà. Non vuoi che gli sviluppatori si occupino di questo perché 15 vs 1 (o 2) è fonte di confusione per il cliente, con chi stanno veramente trattando?

2: No, non devi essere uno specialista, ma devi sapere abbastanza per rilevare le falsità o BS. Ho visto un team di sviluppo andare per sempre (overbudget e tardi) perché il "lead" era completamente non tecnico e doveva fare affidamento su uno sviluppatore del team. Certo, aveva una sua agenda e stava solo seguendo il suo volo e la sua fantasia. Povero "piombo" non aveva la minima idea di essere stato licenziato. Sorridi e annuisci, sorridi e annuisci. Tornando alla tua domanda, a volte un esperto tecnico è una brutta cosa come protagonista, perché spesso lui o lei andrà a fare (o rifare) qualcosa di grosso, eccessivamente architettato e eccessivamente complicato. In breve: Un buon lead ha un solido supporto tecnico e una altrettanto solida o migliore comprensione di come il team e il progetto si inseriscono negli obiettivi aziendali.

Non sudare la cosa agile, il tuo manager ha sentito la parola da qualche parte. Basta fare ciò che funziona e ottenere il cliente lì in anticipo e spesso, e dimostrarlo presto e spesso.

Sembra che tu abbia bisogno di stabilire un ruolo di supporto al cliente. Questo è un termine di squadra agile per la persona che rappresenta gli interessi dei clienti per il team. Si siedono a tutte le riunioni di progettazione e si assicurano che gli ingegneri costruiscano i requisiti che il cliente ha predisposto. Assicurati inoltre di essere lì per rispondere alle domande che potrebbero avere sui requisiti. Offri di porre domande anche al cliente, se necessario.

Una cosa su cui puoi applicare le tue abilità di cliente è quella di agire in questo ruolo. Scrivi i requisiti dettagliati (sotto forma di storie utente se vuoi essere agile a riguardo) per dettagliare ciò che il cliente desidera. Questo è molto importante se il cliente è vago in quello che vuole. Niente porta a sistemi di buggy eccessivamente gonfiati più che a esigenze vaghe.

Dovresti essere un team che rivede tutto il codice fatto per uno sprint (un altro termine agile che sta fornendo codice testabile edificabile ogni 1 o 2 settimane). Se hai bisogno di approfondire questa idea, quello che ho fatto con il mio team è stato semplicemente avere la riunione di revisione in corso in cui abbiamo introdotto la gestione (era una piccola azienda) e i sostenitori dei clienti e demo tutte le nuove funzionalità di quella settimana (o 2 settimane di lavoro). Gli sviluppatori hanno bisogno di partecipare a questo incontro. Lo odieranno, si lamenteranno che è una perdita di tempo, ecc., Ma sentiranno direttamente dal cliente cosa gli piace e cosa non piace di quello che stanno facendo.

Siate pronti a tenere le cose in ordine. Se una caratteristica inizia a essere discussa che non è nei requisiti, dica così. Se riesci a ottenere l'autorità dalla gestione, fai in modo che anche gli sviluppatori testino l'inferno su ogni funzione. Niente ferma una caratteristica inutile come dover passare 2 giorni a scrivere test dall'inferno per questo.