Mantieni la calma e passa a un nuovo team di sviluppo

È normale che un prodotto software passi da un team di sviluppo a un altro durante il suo ciclo di vita. Diverse fasi del prodotto possono richiedere un diverso tipo di team di sviluppo: una consulenza per creare la versione iniziale, uno sviluppatore freelance da solo per mantenerla, un team interno per portarla su scala, o un designer professionista per aggiungere alcuni " pop".

Nonostante la frequenza con cui ciò avvenga, molti fondatori e proprietari di prodotti non tecnici si trovano impreparati e si danno da fare quando arriva il momento di assumere la squadra successiva. Ciò si traduce spesso in un'incapacità per il nuovo team di fare progressi rapidi, perdita di tempo e frustrazione per tutte le persone coinvolte.

Se sembra che potresti essere tu, ora o in futuro, allora dovresti essere un po' preoccupato. Fortunatamente, illustreremo i passaggi che puoi intraprendere per prepararti a questa eventualità e rendere la transizione il più agevole possibile.

Passare il testimone: a bordo di un nuovo team di sviluppo

In questo articolo, ti fornirò una lista di controllo di elementi che ti aiuteranno a prepararti per un tale cambiamento. Conoscerai il tuo prodotto a un livello più intimo e acquisirai un maggiore controllo su tutti i vari servizi e tecnologie che lo compongono, il che ti consentirà di entrare a bordo di un nuovo team con sicurezza e relativa facilità.

Ma cosa succede se non stai sostituendo l'intera squadra? Dovresti preoccuparti di leggere questo?

Anche se alcuni membri del team precedente rimangono a bordo, potrebbero non avere tutte le risposte e le informazioni necessarie per una transizione senza intoppi. Sebbene possano fornire continuità e aiuto nel processo di trasferimento delle conoscenze dal vecchio team al nuovo, fare affidamento sui membri del team in carica non sostituisce il product owner che si fa carico e facilita il trasferimento. Inoltre, la mancata presa in carico potrebbe causare attrito tra vecchi e nuovi membri del team o gravare sui vecchi membri del team con compiti non necessari, costringendoli a perdere troppo tempo a comunicare con i nuovi membri del team e a risolvere vari problemi.

Tuttavia, se alcuni membri del team rimangono a bordo, possono essere una risorsa inestimabile nei tuoi sforzi di transizione. Consultali, tienili aggiornati e prova a sfruttare la loro esperienza senza inondarli di troppe attività legate alla transizione. Non aspettarti che facciano tutto il lavoro pesante! Questo è il tuo lavoro.

Quindi, senza ulteriori indugi, tuffiamoci!

Raccogli documentazione

Agli sviluppatori freelance viene spesso chiesto di entrare in una base di codice esistente che non hanno mai visto prima. Ciò è particolarmente vero per quanto riguarda gli ingegneri del software Toptal. Il nostro obiettivo è sempre quello di aggiornarci il più rapidamente possibile in modo da poter iniziare ad avere un impatto positivo per i nostri clienti.

Avere accesso a una documentazione chiara e completa sul progetto può accelerare notevolmente il processo di onboarding e aiutare gli sviluppatori a evitare insidie ​​che possono impedire il progresso.

Una buona documentazione deve coprire almeno i seguenti argomenti:

• Configurazione di un ambiente di sviluppo - Il primo compito per qualsiasi nuovo arrivato è far funzionare l'applicazione sui propri computer. Il processo per farlo varia tra le tecnologie. In generale, richiede attività come ottenere il codice sorgente, impostare il database, installare dipendenze, configurare l'ambiente con chiavi API e credenziali, importare dati di esempio e così via. Gli sviluppatori hanno una buona idea di tutto ciò che è coinvolto in questo processo all'interno dei rispettivi campi e dovrebbero essere in grado di modificare i dettagli di conseguenza.
• Esecuzione della suite di test automatizzata : vedere il superamento dei test di un'applicazione garantisce che tutto sia stato impostato correttamente e che le modifiche future non interrompano nessuna delle funzionalità esistenti.
• Distribuzione sui server di staging e di produzione : l'aggiornamento dell'applicazione live con le modifiche più recenti è un processo altamente script e l'ordine di tali operazioni deve essere delineato passo dopo passo, nel modo più dettagliato possibile.
• Qualsiasi altra informazione rilevante per uno sviluppatore appena integrato : ogni applicazione ha la sua serie di stranezze. Annotarli consente ai futuri team di risparmiare un sacco di sforzi sprecati per il debug di problemi che il team precedente ha già capito come affrontare.

La documentazione deve essere scritta da uno sviluppatore che abbia esperienza diretta nella configurazione dell'applicazione e nel contributo alla base di codice.

Prima che avvenga qualsiasi transizione, chiedi al team di sviluppo precedente di facilitare il trasferimento di conoscenze creando una risorsa che tocchi gli argomenti sopra!

Se la scrittura non è il loro forte, chiedi loro di registrare uno o più screencast che dimostrano l'impostazione dell'ambiente di sviluppo, la distribuzione, ecc. Oggi ci sono persino strumenti come Vagrant e Docker che consentono di impacchettare e distribuire interi ambienti di sviluppo ad altri. In sostanza, invece di dare a qualcuno indicazioni su come costruire un martello, dagli il martello stesso.

La cartina di tornasole di quanto sia completa ed efficace la documentazione di un progetto è la rapidità con cui un nuovo sviluppatore può configurare il proprio ambiente di sviluppo ed eseguire l'applicazione.

Comprendi il tuo prodotto

Avere un'ottima documentazione non ti esonera dal dover conoscere le basi della tecnologia del tuo prodotto. In qualità di proprietario di un prodotto software, è tua responsabilità comprendere la tua applicazione nel miglior modo possibile, anche se non sei molto tecnico.

Le seguenti domande sono comuni e dovresti aspettarti di conoscere le risposte senza doverle cercare:

• Quale stack tecnologico utilizza la tua applicazione? - Esistono molti framework applicativi comuni per il back-end e il front-end e qualsiasi nuovo team di sviluppo dovrebbe avere familiarità con quelli utilizzati dall'applicazione. Alcuni esempi di tecnologie web di back-end sono Ruby on Rails, Node.js e Django. Alcuni esempi di tecnologie web front-end sono React.js, Angular.js ed Ember.js.
• Dove è ospitato? - Diversi host web hanno diversi processi di distribuzione, che richiedono diversi livelli di esperienza. Negli ultimi anni, le tecnologie cloud hanno creato una serie di nuove opzioni di hosting e dovrai identificare quale in particolare stai utilizzando e descrivere perché è stata scelta rispetto alle altre.
• Qual è il processo di sviluppo? - Il tuo team utilizza un particolare strumento di gestione del controllo del codice sorgente come Git? In tal caso, qual è il processo mediante il quale una nuova funzionalità viene sviluppata, testata, approvata e distribuita? Il processo deve essere standardizzato, adeguatamente documentato e facile da replicare da parte dei nuovi arrivati.
• Quali servizi di terze parti utilizza la tua applicazione? - Alcune applicazioni sono basate su servizi di terze parti come Shopify. Tieni presente che la dipendenza da servizi di terze parti è in graduale aumento e, anche se al momento non utilizzi alcun servizio aggiuntivo, il tuo progetto potrebbe decidere di utilizzare un servizio di terze parti in un secondo momento.
• Su quali piattaforme può essere eseguita la tua applicazione? - La tua app è un'applicazione desktop, un'app Web, un sito Web mobile reattivo, un'applicazione iOS nativa, un'applicazione Android nativa o qualsiasi altra cosa? Funziona su diverse piattaforme? Quale piattaforma è la tua priorità in un dato momento? Su quale piattaforma è il tuo prodotto più forte e più debole? Assicurati di conoscere tutti i dettagli delle piattaforme attuali della tua applicazione e anche in quali può essere espansa.

Assumere la proprietà

Il processo di sviluppo del software odierno utilizza una pletora di servizi e strumenti di terze parti. Che tu lo sappia o no, la tua applicazione non fa eccezione.

Durante il corso dello sviluppo, il tuo team precedente potrebbe essersi registrato per tuo conto o persino utilizzato i propri account per ottenere l'accesso ai servizi necessari. Il passaggio a un nuovo team significa che devi assumere la proprietà e avere il controllo di ogni singolo servizio e strumento su cui si basa la tua applicazione in modo da poter concedere l'accesso al tuo nuovo team senza dover passare attraverso un intermediario o inseguire il sviluppatori originali.

Di seguito è riportato un elenco dei vari strumenti o servizi esterni che l'applicazione potrebbe utilizzare:

• Gestione del controllo del codice sorgente - GitHub, Bitbucket, Gitlab
• Hosting Web : Heroku, EngineYard, Digital Ocean, Bluehost, Amazon Web Services
• Hosting di file - Amazon Web Services (S3)
• Provider DNS - GoDaddy, DNSimple, Hover
• Servizi di sviluppo : NewRelic, FileStack, Segment, Bugsnag (e innumerevoli altri)
• Servizi di pagamento : Stripe, Braintree, PayPal
• Servizi di blog - WordPress, Tumblr, Ghost
• Soluzioni di e-commerce - Shopify, Squarespace
• Analisi/Tracciamento - Google Analytics, Mixpanel, Kissmetrics
• Email Marketing: MailChimp, Contatto Costante

Chiedi al tuo team di sviluppo uscente quali sono applicabili. Per tutti i servizi di proprietà del team di sviluppo, chiedi loro di trasferirti la proprietà. Se ciò non è possibile, chiedi loro di aiutarti a creare un nuovo account e assicurati che l'applicazione utilizzi il tuo account anziché il loro. Ciò non dovrebbe richiedere nient'altro che la modifica di alcune impostazioni di configurazione per la tua applicazione.

Inutile dire che assicurati che ogni contratto di sviluppo protegga i tuoi interessi fin dal primo giorno e assicuri una transizione graduale, qualunque cosa accada.

Concedere l'accesso

Con una solida comprensione dell'ecosistema della tua applicazione e la proprietà di tutti i vari strumenti e servizi utilizzati dalla tua applicazione, ora sei in grado di fornire l'accesso completo al team o al singolo in entrata.

La maggior parte dei servizi ti consentirà di aggiungere un collaboratore al tuo account e garantire loro un particolare livello di accesso. Va bene essere conservatori qui . molti fondatori, in particolare imprenditori individuali, preferiscono dare ai loro sviluppatori l'accesso completo ai loro servizi e fargli gestire tutto. Questo ha l'effetto collaterale negativo di tenerti fuori dal giro, che, come abbiamo imparato, può rendere più difficile la transizione in futuro.

Dovresti concedere ai tuoi sviluppatori i privilegi di amministratore completi? È la tua chiamata e la maggior parte delle persone non ha problemi con questo approccio. Tuttavia, devi sempre pianificare in anticipo e assicurarti che la tua decisione non influisca negativamente su un nuovo team di sviluppo. Non farlo nelle prime fasi del progetto può avere conseguenze fastidiose in futuro.

Gestire l'Handoff

Ora che hai coperto tutte le tue basi, dovrai gestire il passaggio da una squadra all'altra. Ecco alcuni suggerimenti di base per affrontare sia il team in entrata che quello in uscita.

Squadra in arrivo

• Stabilisci le aspettative - Il nuovo team dovrebbe sapere quali sono i tuoi obiettivi più importanti in modo da potersi concentrare nella giusta direzione. Gestire le proprie aspettative su ciò che il nuovo team può realizzare subito è altrettanto importante.
• Fai spesso il check-in - Non lasciare che la nuova squadra affondi o nuoti. Vuoi fare il check-in spesso per assicurarti che abbiano tutto ciò di cui hanno bisogno e non si sentano come se dovessero cavarsela da soli. Prova a farlo senza microgestione. Assicurati che sappia che sei lì per supportare e aiutare se necessario, ma non esercitare pressioni inutili su di loro.
• Sii paziente : gli sviluppatori richiedono tempo per abituarsi a una nuova base di codice. Comprendi che ci sarà del tempo di apprendimento prima che la nuova squadra possa eguagliare il ritmo della precedente.

Squadra uscente

• Raccogli tutto il codice in sospeso : assicurati che tutto il codice sorgente sia archiviato nel repository principale e di conoscere lo stato di ciò che è stato o non è stato distribuito. Il nuovo team dovrà sapere esattamente dove ritirare e iniziare a lavorare. Io stesso ho sperimentato una situazione in cui ho preso il posto di un team che aveva distribuito il codice senza inserirlo nel repository principale. Ciò ha portato a bug, lavoro duplicato e mal di testa che avrebbero potuto essere facilmente evitati se il team in uscita avesse lasciato il codice sorgente in uno stato coerente.
• Aggiorna il loro livello di accesso - Se ti sei separato in buoni rapporti, potresti voler lasciare loro l'accesso al tuo codice e/o distribuzione. Molte squadre sono felici di dare una mano durante la fase di transizione fino a quando la nuova squadra non potrà subentrare completamente. In caso contrario, valuta la possibilità di eseguire il downgrade o la revoca dell'accesso per evitare problemi o conflitti accidentali con il nuovo team.
• Ringraziali per il loro lavoro : le transizioni possono essere frenetiche. Mentre sei impegnato a trattare con il nuovo team, non dimenticare di ringraziare il tuo team uscente per il contributo al tuo progetto.

Conclusione

Qualsiasi transizione nella vita può essere spaventosa, portando l'incertezza se funzionerà o meno, paura dell'ignoto e così via. Il passaggio a un nuovo team di sviluppo non è diverso, ma puoi e dovresti adottare misure per renderlo più semplice. Nella maggior parte dei casi, richiede solo un po' di pianificazione a lungo termine.

Avere una maggiore comprensione tecnica e non tecnica del prodotto software, del processo di sviluppo e di tutte le cose che sono state introdotte nel processo contribuirà a rendere qualsiasi transizione da un team all'altro il più semplice e indolore possibile.

Soprattutto, la tua nuova squadra ti rispetterà e ti ringrazierà per essere al top del tuo gioco! È probabile che risparmierai tempo e fatica, il che significa anche che risparmierai denaro. Inoltre, prima il nuovo team si rende conto di insistere su standard professionali elevati, meglio è. È probabile che continueranno a implementare queste pratiche una volta che avranno rilevato il progetto, rendendo agevole anche la transizione successiva.

Esaminiamo quindi i punti chiave che dovrebbero precedere qualsiasi trasferimento di proprietà del tuo prodotto software:

• Raccogli o crea quanta più documentazione possibile sulla tua applicazione, sull'ambiente di sviluppo e sul processo di distribuzione.
• Conosci il tuo prodotto dentro e fuori.
• Mantieni il controllo di tutti i servizi e le dipendenze di terze parti della tua applicazione e disponi di nomi utente e password per tutto.
• Preparati a dare al tuo nuovo team l'accesso a tutto ciò di cui ha bisogno per essere operativo.
• Sii proattivo e non lasciare nulla al caso o al team di sviluppo uscente.