Scalare il team di sviluppo con ingegneri esterni senza perdere la qualità del codice

Introduzione

Punti chiave

1. Utilizzate ingegneri esterni quando la vostra roadmap è troppo piena per il vostro team principale.
2. Stabilite semplici linee guida di qualità e una pipeline di consegna di base prima che entrino a far parte del team.
3. Accogli gli sviluppatori esterni con una checklist chiara e un referente di riferimento.
4. Applicate un unico insieme di regole, revisioni e metriche per tutti gli ingegneri.
5. Affidatevi a brevi aggiornamenti scritti per mantenere allineato un team misto in crescita.

Perché dovresti ampliare il tuo team di sviluppo con ingegneri esterni?

Dovresti ampliare il tuo team di sviluppo con ingegneri esterni quando la tua roadmap è piena e il tuo personale non riesce a stare al passo in modo sano. Il punto principale è semplice: gli ingegneri esterni dovrebbero aggiungere velocità e competenze senza abbassare il livello di qualità. Se ti aiutano a fornire un lavoro costante che sembra sicuro da mantenere, questa soluzione ha senso. Se aggiungono solo stress e cambiamenti casuali, il momento non è quello giusto.

Molti leader delle aziende di prodotti sentono la stessa pressione. Il lavoro arretrato cresce, le scadenze slittano e assumere ingegneri competenti nella propria città richiede molto tempo. In quel momento si inizia a pensare di ampliare il team di ingegneri con un aiuto esterno. Si può prendere in considerazione un team di sviluppo in outsourcing in un'altra regione o un gruppo più piccolo più vicino al proprio fuso orario. La vera domanda non è se è possibile ricorrere a un aiuto esterno, ma quando questo supporterà la roadmap invece di nascondere problemi più profondi.

Uno dei motivi per invitare ingegneri esterni è l'accesso a competenze che al momento non sono disponibili internamente. Potrebbe essere necessario un supporto a breve termine in aree come i dati, le app mobili o le nuove configurazioni cloud. Potresti non voler creare un team completamente nuovo per ogni nuovo argomento. In tal caso, l'ampliamento del team di sviluppo software può fornirti un livello di supporto flessibile attorno al tuo gruppo principale. Mantenete le conoscenze e la direzione principali all'interno della vostra azienda e utilizzate l'aiuto esterno per parti di lavoro chiare e mirate. Nella vita quotidiana questo sembra più l'aggiunta di un esperto calmo a una squadra impegnata che la creazione di una seconda azienda.

C'è anche un aspetto molto basilare legato al tempo e ai costi. Assumere persone competenti da soli può richiedere molte settimane o addirittura mesi, e durante questo periodo il lavoro arretrato non si ferma. Qui puoi vedere chiaramente i vantaggi dell'ampliamento del personale IT. Puoi assumere personale extra per un periodo di tempo e un ambito definiti, mentre continui a pensare alle assunzioni a lungo termine. Per alcuni team questa opzione attenua i picchi di domanda invece di costringere a un forte aumento del personale fisso. Questo tipo di configurazione ti consente di testare l'effetto della capacità extra sul tuo prodotto prima di cambiare definitivamente l'intera struttura.

Puoi anche scegliere diversi modelli per l'inserimento di queste persone nel tuo mondo. In un modello di aumento del personale, aggiungi ingegneri esterni al tuo team e i tuoi leader guidano il loro lavoro ogni giorno. In una configurazione di team di sviluppo nearshore, le persone si trovano in un fuso orario vicino e possono partecipare alle tue chiamate e chat in orario normale. Molte aziende lavorano con un partner di sviluppo software esperto che sa già come svolgere lo sviluppo software nearshore e integrarsi con i team interni. Più la cultura, il fuso orario e gli strumenti sono simili, più è facile far sentire molte persone come un unico team, anche se i contratti sono diversi. Questa base condivisa è ciò che rende il lavoro esterno naturale invece che fragile.

Come preparare il codice e i processi prima di aggiungere un team di sviluppo esterno?

Ci si prepara per un team di sviluppo esterno stabilendo una base chiara e semplice su come costruire e spedire il proprio prodotto. Sono necessarie regole condivise, strumenti di base e un modo di lavorare visibile prima dell'arrivo di nuove persone. Senza questa base, ogni cambiamento dipende dallo stile personale e dalla memoria, e le nuove persone non hanno modo di indovinare la strada giusta. Con questa base, anche gli occhi nuovi possono muoversi con un ritmo sicuro e costante.

Puoi pensare a questa base come a delle barriere di protezione della qualità per il codice. Queste barriere sono semplici controlli che ogni cambiamento deve superare, indipendentemente da chi lo ha scritto. Possono riguardare il modo in cui dai un nome alle cose, come formatti i file e cosa significa "fatto" per ogni piccolo lavoro. Quando le barriere rimangono le stesse per tutti, il tuo prodotto risulta stabile anche se il team cresce e cambia. Questo rende più facile fidarsi dell'intero flusso, non solo delle persone che già conosci.

È inoltre necessaria una pipeline di integrazione e consegna continua di base. Questa lunga frase descrive un'idea semplice. Ogni volta che qualcuno modifica il codice, il sistema esegue dei controlli e aiuta a trasferire tale modifica agli utenti con piccoli passi sicuri. Questa pipeline può risiedere su piattaforme comuni e può essere eseguita ad ogni push sul vostro archivio di codice principale. Una pipeline funzionante trasforma molte piccole modifiche in una linea di progresso pulita invece che in un mucchio di release grandi e spaventose. I nuovi arrivati possono imparare questo percorso una volta sola e poi seguirlo senza ulteriori congetture.

I test sono una parte fondamentale di questo percorso. I test automatizzati in CI/CD significano che i test vengono eseguiti automaticamente ogni volta che qualcuno condivide un nuovo codice. È possibile iniziare con semplici controlli che coprono i percorsi più utilizzati nel prodotto. Nel corso del tempo è possibile aggiungere altri test man mano che si individuano i punti in cui tendono a verificarsi i bug. Anche una piccola serie di test stabili offre maggiore sicurezza rispetto a un lungo elenco di controlli manuali che nessuno esegue in tempo. Questo approccio mantiene le cose reali e supporta sia gli ingegneri interni che quelli esterni.

Aiuta anche a esaminare le parti più vecchie del sistema prima di chiedere ad altri di modificarle. È qui che entra in gioco la gestione di base del debito tecnico. Il debito tecnico è un modo per descrivere il codice che funziona ma è difficile da modificare senza rischi. È possibile contrassegnare le zone sicure per i nuovi arrivati e quelle che richiedono ancora l'attenzione del personale più esperto. Una volta individuate le parti rischiose, è possibile guidare il team di sviluppo esterno verso le aree più sicure. Ciò protegge il prodotto e tiene i nuovi arrivati lontani dalle trappole nascoste.

L'ultima parte della base è la semplice sicurezza e l'accesso. Un ciclo di vita dello sviluppo software sicuro può sembrare complesso, ma si basa su passaggi chiari. Si concede alle persone solo l'accesso di cui hanno bisogno, si mantengono al sicuro i dati reali degli utenti e si trattano con cura le chiavi segrete. Si scrive anche cosa fare quando qualcosa va storto, anche su piccola scala. Quando la sicurezza fa parte del lavoro normale, gli ingegneri esterni possono unirsi al processo senza suscitare nuovi timori. Anche i team legali e di sicurezza vedono che questa crescita segue un piano, non una soluzione rapida.

Come si presenta un piano di inserimento sicuro per gli sviluppatori esterni?

Un piano di inserimento sicuro per gli sviluppatori esterni fornisce loro il contesto, gli strumenti e i primi passi chiari senza precipitarli in acque profonde. Dovrebbe sembrare un percorso guidato in cui ogni giorno ha uno scopo semplice e reale. Quando il piano è chiaro, i nuovi arrivati possono aggiungere valore in poche settimane, non in mesi, e il tuo team non si sente svuotato da domande costanti.

L'onboarding degli sviluppatori esterni inizia con una visione condivisa di ciò che devono imparare per primo. Ciò include il vostro prodotto, i vostri utenti e il vostro normale modo di lavorare. Una checklist di inserimento per gli sviluppatori può contenere tutti questi elementi in un unico posto. Può essere un semplice documento che entrambe le parti possono aprire e modificare. Una checklist visibile trasforma il "Penso che glielo abbiamo già detto" in "sappiamo esattamente cosa è stato fatto e cosa c'è da fare". Questo piccolo cambiamento elimina molto stress silenzioso per tutti.

Ecco un semplice elenco che spesso funziona bene come base per una checklist di questo tipo:

1. Accesso al codice, al tracker di lavoro e alle principali chat room.
2. Passaggi per eseguire il prodotto su un laptop o un server di prova.
3. Una breve guida per gli utenti, i flussi principali e le regole aziendali fondamentali.
4. Nomi delle persone a cui rivolgersi per domande su prodotto, codice e strumenti.
5. Due o tre piccoli compiti chiari pronti per un primo cambiamento reale.

È utile anche nominare una persona di riferimento chiara. Un responsabile tecnico o un ingegnere senior può fungere da compagno di inserimento per le prime settimane. Questa persona può esaminare tutte le modifiche iniziali, rispondere alle domande e spiegare perché le scelte passate sono state fatte in un certo modo. Brevi controlli quotidiani, anche solo cinque minuti in chat, possono mantenere le cose in carreggiata. Un compagno calmo e punti di contatto costanti contribuiscono maggiormente a un inserimento sicuro rispetto a un grande discorso il primo giorno. Nel corso del tempo è possibile trasferire più aggiornamenti nella comunicazione asincrona per i team di sviluppo, come brevi note scritte.

Da quanto ho potuto osservare, il rischio maggiore durante l'inserimento è una silenziosa confusione. I nuovi arrivati temono di chiedere troppo, mentre i membri del team più anziani sperano che le cose "funzionino" da sole. Un piano chiaro per l'inserimento degli sviluppatori esterni e un unico responsabile di tale piano cambiano questo quadro. Quando una sola persona è responsabile del percorso, è possibile individuare gli schemi, correggere i punti deboli e rendere più agevole ogni successivo ciclo di inserimento. In pochi mesi il piano diventa una risorsa ripetibile invece che una nuova sfida ogni volta che si aggiunge qualcuno.

Come si mantiene la qualità del codice in un team di sviluppo misto quando si gestiscono sviluppatori esterni?

Si mantiene la qualità del codice in un team di sviluppo misto utilizzando le stesse semplici regole, controlli e numeri per tutti. I vostri standard devono applicarsi a tutti gli ingegneri se volete che il prodotto sia percepito come un sistema pulito e sicuro. Una volta suddivise le regole in base al tipo di contratto, si suddividono anche la fiducia e la chiarezza nel vostro team.

Un team di sviluppo misto è un gruppo in cui ingegneri interni ed esterni lavorano allo stesso prodotto. Possono trovarsi in luoghi diversi, ma condividono un unico backlog e un unico archivio di codice. Questo mix può essere molto forte perché combina una profonda conoscenza del settore con punti di vista nuovi. Può anche essere fragile se ogni gruppo segue le proprie abitudini. Senza una guida chiara, questo mix si trasforma in cluster di codice che sembrano diversi e tra i quali è difficile spostarsi. È in quel momento che la qualità e la velocità iniziano a diminuire.

In questo caso sono utili alcune semplici best practice per la revisione del codice. Ogni modifica dovrebbe essere sottoposta alla revisione di almeno un'altra persona, indipendentemente da chi l'ha apportata. Le revisioni dovrebbero valutare la chiarezza, la sicurezza e l'adeguatezza al resto del sistema, non solo lo stile. È possibile supportare questo processo con strumenti leggeri che analizzano il codice alla ricerca di problemi comuni. Queste routine mantengono la qualità del codice degli sviluppatori esterni in linea con il resto del team in modo tranquillo e ripetibile. Le persone imparano le une dalle altre e costruiscono un senso condiviso di ciò che è "buono".

È anche possibile monitorare una piccola serie di metriche del team di sviluppo software. Queste possono mostrare quanto tempo occorre per completare un lavoro, quanti problemi raggiungono gli utenti e con quale frequenza si effettuano le consegne. Non servono decine di numeri. Bastano pochi dati che si possano leggere e discutere con facilità. Quando queste metriche rimangono stabili o migliorano mentre gestite gli sviluppatori esterni e fate crescere il team, sapete che la vostra configurazione supporta la qualità. Se scendono, avete un segnale precoce per rivedere le vostre regole, l'ambito o la combinazione di attività.

I modelli di comunicazione sono importanti tanto quanto le regole e i numeri. Molti team di sviluppo misti sono anche team agili distribuiti, perché le persone lavorano da diversi luoghi o fusi orari. Hanno bisogno di una comunicazione asincrona per i team di sviluppo, in modo che i progressi non dipendano da lunghe chiamate. Brevi aggiornamenti scritti, note chiare sulle attività e semplici tag per lo stato sono di grande aiuto. Buoni aggiornamenti scritti rendono più facile per tutti gli ingegneri partecipare, seguire e migliorare il prodotto nel tempo. Le discussioni dal vivo sono ancora importanti, ma non sono più l'unico luogo in cui vengono prese le decisioni.

Anche il modo in cui si coinvolgono le persone esterne influisce sulla qualità. Se le si tratta come un flusso separato con obiettivi poco chiari, non si sentiranno pienamente responsabili del prodotto. Se le si aggiunge alle squadre esistenti con un unico insieme di regole, potranno agire come qualsiasi altro membro del team. Alcune aziende utilizzano a questo scopo una struttura di potenziamento del team, in cui uniscono persone interne ed esterne sotto un unico responsabile. Obiettivi condivisi, strumenti condivisi e revisioni condivise contribuiscono alla qualità del codice nello sviluppo del software più di qualsiasi documento di controllo rigoroso. Nel tempo è possibile modificare la composizione del team e il lavoro, ma la struttura condivisa rimane la stessa.