Restez calme et faites la transition vers une nouvelle équipe de développement

Il est courant qu'un produit logiciel passe d'une équipe de développement à une autre au cours de sa durée de vie. Différentes étapes du produit peuvent nécessiter un type d'équipe de développement différent : un cabinet de conseil pour construire la version initiale, un développeur indépendant indépendant pour la maintenir, une équipe interne pour la mettre à l'échelle ou un concepteur professionnel pour ajouter quelques " pop".

Malgré la fréquence à laquelle cela se produit, de nombreux fondateurs et propriétaires de produits non techniques se retrouvent mal préparés et se bousculent lorsque vient le temps de faire venir la prochaine équipe. Cela se traduit souvent par une incapacité pour la nouvelle équipe à progresser rapidement, une perte de temps et de la frustration pour toutes les personnes impliquées.

Si cela ressemble à vous, maintenant ou à l'avenir, vous devriez être quelque peu inquiet. Heureusement, nous allons parcourir les étapes que vous pouvez suivre pour vous préparer à cette éventualité et rendre la transition aussi fluide que possible.

Passer le flambeau : intégrer une nouvelle équipe de développement

Dans cet article, je vais vous fournir une liste de contrôle des éléments qui vous aideront à vous préparer à un tel changement. Vous apprendrez à connaître votre produit à un niveau plus intime et vous aurez plus de contrôle sur tous les différents services et technologies qui entrent dans sa fabrication, ce qui vous permettra d'intégrer une nouvelle équipe avec confiance et une relative facilité.

Et si vous ne remplaciez pas toute l'équipe ? Faut-il prendre la peine de lire ceci ?

Même si certains membres de l'équipe précédente restent à bord, ils pourraient ne pas avoir toutes les réponses et informations nécessaires pour une transition en douceur. Bien qu'ils puissent assurer la continuité et faciliter le processus de transfert des connaissances de l'ancienne équipe vers la nouvelle, s'appuyer sur les membres de l'équipe en place ne remplace pas la prise en charge par le propriétaire du produit et la facilitation du transfert. De plus, le fait de ne pas prendre en charge peut entraîner des frictions entre les anciens et les nouveaux membres de l'équipe, ou surcharger les anciens membres de l'équipe avec des tâches inutiles, les obligeant à perdre trop de temps à communiquer avec les nouveaux membres de l'équipe et à résoudre divers problèmes.

Néanmoins, si certains membres de l'équipe restent à bord, ils peuvent être un atout inestimable dans vos efforts de transition. Consultez-les, tenez-les au courant et essayez de tirer parti de leur expérience sans les submerger de trop nombreuses tâches liées à la transition. Ne vous attendez pas à ce qu'ils fassent tout le gros du travail ! C'est votre travail.

Alors sans plus tarder, plongeons-y !

Rassembler la documentation

Les développeurs indépendants sont souvent invités à sauter dans une base de code existante qu'ils n'ont jamais vue auparavant. Cela est particulièrement vrai en ce qui concerne les ingénieurs logiciels de Toptal. Notre objectif est toujours de nous mettre à niveau le plus rapidement possible afin que nous puissions commencer à avoir un impact positif pour nos clients.

Avoir accès à une documentation claire et complète sur le projet peut considérablement accélérer le processus d'intégration et aider les développeurs à éviter les pièges qui peuvent entraver la progression.

Une bonne documentation doit couvrir au moins les sujets suivants :

• Configuration d'un environnement de développement - La première tâche de tout nouveau venu consiste à installer et à exécuter l'application sur son propre ordinateur. Le processus pour le faire varie selon les technologies. En général, cela nécessite des tâches telles que l'obtention du code source, la configuration de la base de données, l'installation de dépendances, la configuration de l'environnement avec des clés d'API et des informations d'identification, l'importation d'exemples de données, etc. Les développeurs ont une bonne idée de tout ce qui est impliqué dans ce processus dans leurs domaines respectifs et devraient être en mesure d'ajuster les détails en conséquence.
• Exécution de la suite de tests automatisés - Le fait de voir les tests d'une application réussir garantit que tout a été correctement configuré et que les modifications futures ne cassent aucune de vos fonctionnalités existantes.
• Déploiement sur les serveurs intermédiaires et de production - La mise à jour de l'application en direct avec les dernières modifications est un processus hautement scripté, et l'ordre de ces opérations doit être décrit étape par étape, aussi détaillé que possible.
• Toute autre information pertinente pour un développeur nouvellement intégré - Chaque application a son propre ensemble de bizarreries. Le fait de les écrire évite aux futures équipes beaucoup de problèmes de débogage d'efforts inutiles que l'équipe précédente a déjà compris comment traiter.

La documentation doit être rédigée par un développeur qui a une expérience directe de la configuration de l'application et de la contribution à la base de code.

Avant toute transition, demandez à l'équipe de développement précédente de faciliter le transfert de connaissances en créant une ressource qui touche aux sujets ci-dessus !

Si l'écriture n'est pas leur point fort, demandez-leur d'enregistrer un ou plusieurs screencasts démontrant la configuration, le déploiement, etc. de l'environnement de développement. Aujourd'hui, il existe même des outils tels que Vagrant et Docker qui permettent de regrouper et de distribuer des environnements de développement entiers. Essentiellement, au lieu de donner à quelqu'un des instructions sur la façon de construire un marteau, donnez-lui le marteau lui-même.

Le test décisif pour l'exhaustivité et l'efficacité de la documentation d'un projet est la rapidité avec laquelle un nouveau développeur peut configurer son environnement de développement et exécuter votre application.

Comprendre votre produit

Avoir une excellente documentation ne vous dispense pas d'avoir besoin de connaître les bases de la technologie de votre propre produit. En tant que propriétaire d'un produit logiciel, il est de votre responsabilité de comprendre au mieux votre application, même si vous n'êtes pas très technique.

Les questions suivantes sont courantes et vous devriez être censé connaître les réponses sans avoir à les rechercher :

• Quelle pile technologique votre application utilise-t-elle ? - Il existe de nombreux frameworks d'application communs pour le back-end et le front-end, et toute nouvelle équipe de développement doit connaître ceux que votre application utilise. Quelques exemples de technologies Web back-end sont Ruby on Rails, Node.js et Django. Quelques exemples de technologies Web frontales sont React.js, Angular.js et Ember.js.
• Où est-il hébergé ? - Différents hébergeurs Web ont des processus de déploiement différents, qui nécessitent différents niveaux d'expérience. Ces dernières années, les technologies cloud ont créé un certain nombre de nouvelles options d'hébergement, et vous devrez identifier celle que vous utilisez et décrire pourquoi elle a été choisie parmi les autres.
• Quel est le processus de développement ? - Votre équipe utilise-t-elle un outil de gestion du contrôle des sources particulier tel que Git ? Si oui, quel est le processus par lequel une nouvelle fonctionnalité est développée, testée, approuvée et déployée ? Le processus doit être standardisé, correctement documenté et facile à reproduire par les nouveaux arrivants.
• Quels services tiers votre application utilise-t-elle ? - Certaines applications sont construites sur des services tiers tels que Shopify. Veuillez garder à l'esprit que le recours aux services tiers augmente progressivement, et même si vous n'utilisez actuellement aucun service supplémentaire, votre projet peut décider d'employer un service tiers plus tard.
• Sur quelles plateformes votre application peut-elle fonctionner ? - Votre application est-elle une application de bureau, une application Web, un site Web mobile réactif, une application iOS native, une application Android native ou autre chose ? Fonctionne-t-il sur plusieurs plates-formes différentes ? Quelle plateforme est votre priorité à un moment donné ? Sur quelle plate-forme votre produit est-il le plus fort et le plus faible ? Assurez-vous de connaître tous les détails des plates-formes actuelles de votre application, et même celles vers lesquelles elle peut être étendue.

Prendre possession

Le processus de développement de logiciels d'aujourd'hui utilise une pléthore de services et d'outils tiers. Que vous le sachiez ou non, votre application ne fait pas exception.

Au cours du développement, votre équipe précédente peut s'être inscrite en votre nom ou même avoir utilisé ses propres comptes pour accéder aux services nécessaires. La transition vers une nouvelle équipe signifie que vous devez vous approprier et contrôler chacun des services et outils sur lesquels votre application s'appuie afin que vous puissiez accorder l'accès à votre nouvelle équipe sans avoir à passer par un intermédiaire ou à chasser le développeurs originaux.

Voici une liste des différents outils ou services externes que votre application peut utiliser :

• Gestion du contrôle des sources - GitHub, Bitbucket, Gitlab
• Hébergement Web - Heroku, EngineYard, Digital Ocean, Bluehost, Amazon Web Services
• Hébergement de fichiers - Amazon Web Services (S3)
• Fournisseur DNS - GoDaddy, DNSimple, Hover
• Services de développement - NewRelic, FileStack, Segment, Bugsnag (et d'innombrables autres)
• Services de paiement - Stripe, Braintree, PayPal
• Services de blogs - WordPress, Tumblr, Ghost
• Solutions de commerce électronique - Shopify, Squarespace
• Analytique / Suivi - Google Analytics, Mixpanel, Kissmetrics
• Marketing par e-mail : MailChimp, Contact constant

Demandez à votre équipe de développement sortante lesquelles sont applicables. Pour tous les services appartenant à l'équipe de développement, demandez-leur de vous en transférer la propriété. Si ce n'est pas possible, demandez-leur de vous aider à créer votre propre compte et assurez-vous que l'application utilise votre compte au lieu du leur. Cela ne devrait nécessiter rien de plus que de modifier certains paramètres de configuration de votre application.

Inutile de dire que chaque contrat de développement protège vos intérêts dès le premier jour et assure une transition en douceur, quoi qu'il arrive.

Accorder l'accès

Avec une solide compréhension de l'écosystème de votre application et la propriété de tous les différents outils et services utilisés par votre application, vous êtes désormais en mesure de fournir un accès complet à l'équipe ou à l'individu entrant.

La plupart des services vous permettront d'ajouter un collaborateur à votre compte et de lui accorder un niveau d'accès particulier. C'est bien d'être conservateur ici . de nombreux fondateurs, en particulier les entrepreneurs individuels, préfèrent donner à leurs développeurs un accès administrateur complet à leurs services et les laisser gérer tout. Cela a pour effet secondaire négatif de vous tenir à l'écart, ce qui, comme nous l'avons appris, peut rendre plus difficile la transition à l'avenir.

Devez-vous accorder à vos développeurs des privilèges d'administrateur complets ? C'est votre choix, et la plupart des gens n'ont pas de problème avec cette approche. Cependant, vous devez toujours planifier à l'avance et vous assurer que votre décision n'affecte pas négativement une nouvelle équipe de développement. Ne pas le faire dans les premières étapes du projet peut avoir des conséquences fâcheuses à l'avenir.

Gestion du transfert

Maintenant que vous avez couvert toutes vos bases, vous devrez gérer le transfert d'une équipe à l'autre. Voici quelques conseils de base pour gérer à la fois l'équipe entrante et l'équipe sortante.

Équipe entrante

• Définissez des attentes - La nouvelle équipe doit savoir quels sont vos objectifs les plus importants afin de pouvoir se concentrer dans la bonne direction. Gérer vos propres attentes sur ce que la nouvelle équipe peut accomplir immédiatement est tout aussi important.
• Enregistrez-vous souvent - Ne laissez pas la nouvelle équipe couler ou nager. Vous voulez vous enregistrer souvent pour vous assurer qu'ils ont tout ce dont ils ont besoin et qu'ils n'ont pas l'impression qu'ils doivent se débrouiller seuls. Essayez de le faire sans microgestion. Assurez-vous qu'ils savent que vous êtes là pour les soutenir et les aider s'ils en ont besoin, mais ne leur mettez pas de pression inutile.
• Soyez patient - Il faut du temps aux développeurs pour s'acclimater à une nouvelle base de code. Comprenez qu'il y aura un certain temps d'apprentissage avant que la nouvelle équipe puisse suivre le rythme de la précédente.

Équipe sortante

• Collectez tout le code en attente - Assurez-vous que tout le code source est archivé dans le référentiel principal et que vous connaissez l'état de ce qui a ou n'a pas été déployé. La nouvelle équipe devra savoir exactement où ramasser et commencer à travailler. J'ai moi-même vécu une situation où j'ai pris le relais d'une équipe qui avait déployé du code sans le mettre dans le référentiel principal. Cela a entraîné des bogues, du travail en double et des maux de tête qui auraient pu être facilement évités si l'équipe sortante avait laissé le code source dans un état cohérent.
• Mettez à jour leur niveau d'accès - Si vous vous êtes séparés en bons termes, vous voudrez peut-être leur laisser l'accès à votre code et/ou à votre déploiement. De nombreuses équipes sont heureuses d'aider pendant la phase de transition jusqu'à ce que la nouvelle équipe puisse pleinement prendre le relais. Si ce n'est pas le cas, envisagez de rétrograder ou de révoquer l'accès pour éviter tout problème ou conflit accidentel avec la nouvelle équipe.
• Remerciez-les pour leur travail - Les transitions peuvent être mouvementées. Pendant que vous êtes occupé à traiter avec la nouvelle équipe, n'oubliez pas de remercier votre équipe sortante pour sa contribution à votre projet.

Conclusion

Toute transition dans la vie peut être effrayante, entraînant l'incertitude quant à savoir si cela fonctionnera ou non, la peur de l'inconnu, etc. La transition vers une nouvelle équipe de développement n'est pas différente, mais vous pouvez et devez prendre des mesures pour la rendre plus facile. Dans la plupart des cas, cela nécessite juste un peu de planification à long terme.

Avoir une meilleure compréhension technique et non technique de votre produit logiciel, du processus de développement et de tout ce qui est entré dans le processus aidera à rendre toute transition d'une équipe à l'autre aussi transparente et indolore que possible.

Mieux encore, votre nouvelle équipe vous respectera et vous remerciera d'être au top de votre forme ! Vous leur ferez probablement gagner du temps et des efforts, ce qui signifie également que vous économiserez de l'argent. De plus, plus tôt la nouvelle équipe réalisera qu'elle insiste sur des normes professionnelles élevées, mieux ce sera. Il y a de fortes chances qu'ils continuent à mettre en œuvre ces pratiques une fois qu'ils auront repris le projet, ce qui facilitera également la prochaine transition.

Passons donc en revue les points clés qui doivent précéder tout transfert de propriété de votre produit logiciel :

• Rassemblez ou créez autant de documentation que possible sur votre application, l'environnement de développement et le processus de déploiement.
• Connaissez votre produit de fond en comble.
• Gardez le contrôle de tous les services tiers et dépendances de votre application, et disposez des noms d'utilisateur et des mots de passe pour tout.
• Soyez prêt à donner à votre nouvelle équipe l'accès à tout ce dont elle a besoin pour être opérationnelle.
• Soyez proactif et ne laissez rien au hasard, ni à l'équipe de développement sortante.