Python >> Tutoriel Python >  >> Python

Déplacer le développement en interne :comment garantir un processus de transfert de projet logiciel étanche

Il n'y a pas si longtemps, j'ai eu l'occasion d'échanger quelques e-mails avec un CTO inquiet.

Il cherchait à externaliser le développement de logiciels, examinant ses avantages et ses risques.

L'une de ses questions a particulièrement attiré mon attention :

"Lorsque votre coopération avec un client se termine, comment l'aidez-vous à ramener le développement en interne ?"

Une question très valable, en effet !

Quand tout est dit et fait, votre entreprise d'externalisation a conclu, vous ne voulez pas vous demander ce que fait exactement votre code et quoi en faire ensuite. Idéalement, le retour du développement en interne devrait être transparent et vous laisser une idée claire de la marche à suivre.

Grâce à ce qui précède, j'aimerais partager une partie de l'expérience de STX Next en la matière.

Nous ne sommes pas nouveaux dans le jeu de l'externalisation. Nous comprenons que la réduction ou la conclusion d'une coopération avec un éditeur de logiciels externe est une étape naturelle pour certaines entreprises.

Ce n'est pas une rupture émotionnelle. Inutile de verser des larmes.

C'est pourquoi nous avons élaboré un certain nombre de solutions et de pratiques pour un transfert de connaissances optimal. Voici quelques-unes des pratiques que vous pouvez utiliser pour faciliter le processus de transfert et le rendre aussi facile que possible.

Comment savoir quand démarrer le processus de transfert

Il existe deux manières principales de reconnaître quand lancer le processus de transfert :

1. Le travail est fait.

Certains projets sont livrés avec une date de fin établie. Il se peut qu'un projet implique uniquement la création d'un MVP, du début à la fin, et rien d'autre.

2. Le temps est venu.

Parfois, le moment est tout simplement venu de réduire la taille. Cela peut se produire si votre opération de recrutement interne commence à rattraper votre demande de ressources de développement, par exemple, ou si le projet passe d'un développement rapide à une maintenance stable.

Peu importe les circonstances, c'est généralement une réunion ou un chat vidéo qui lance le processus de transfert.

Chaque projet, chaque partenaire et chaque coopération est différent. C'est pourquoi nous utilisons cette première conversation pour établir le plan d'attaque et découvrir les besoins spécifiques pour le transfert particulier.

Selon les besoins exprimés, vous disposez d'une variété d'options et d'outils qui rendront votre prise en charge rapide et indolore.

Vos options pour un transfert sans douleur

Traitez la liste ci-dessous comme vous le feriez pour un délicieux buffet en libre-service. Vous pourriez être tenté d'épuiser toutes les options, mais cela pourrait être un peu exagéré. Au lieu de cela, vous pouvez choisir ce qui convient le mieux à vos besoins.

1. Rencontrez-vous sur place et travaillez côte à côte avec les développeurs internes

Parfois, la meilleure façon de transférer des connaissances est de rassembler les personnes qui possèdent les connaissances.

C'est pourquoi, dans certains cas, nous envoyons un de nos développeurs chez un client afin qu'il puisse y travailler pendant un certain temps, côte à côte avec les développeurs internes. De cette façon, notre développeur est toujours disponible pour le client pour répondre à ses questions et partager toute information nécessaire sur place.

Dans d'autres cas, nous invitons à la place certains des développeurs du client, afin qu'ils puissent apprendre de nos ingénieurs. Le travail peut prendre de nombreuses formes, telles que la programmation en binôme ou la révision du code de l'autre.

Pour des résultats optimaux, il est préférable que les développeurs externes et internes passent au moins une semaine à travailler ensemble.

2. Organisez et enregistrez des sessions de questions-réponses à distance

Pour les situations où les visites en personne ne sont pas viables ou ne sont pas préférées, les sessions de questions-réponses à distance sont la meilleure option suivante.

Au cours d'une telle session, nos développeurs discutent des fonctionnalités de ce qu'ils ont construit, module par module. La présentation est suivie d'une séance de questions-réponses, où le client peut obtenir des réponses à d'éventuelles questions supplémentaires.

Pour faire du Q&A un point de référence durable, nous nous assurons de l'enregistrer et partager l'enregistrement avec le client.

Pour chaque session, nous n'invitons que les experts concernés par le sujet traité. Cela signifie en pratique que les sessions sur le développement backend n'incluront que les développeurs backend, tandis que les développeurs frontend assisteront aux sessions liées au frontend, par exemple. Cependant, le Product Owner est présent à chaque session pour fournir le contexte nécessaire.

Une autre variante des sessions de questions-réponses consiste à enregistrer une conversation vidéo dans laquelle un développeur explique le code à un autre. Encore une fois, cela peut être une série de réunions virtuelles qui examinent la base de code module par module.

Le principal avantage des sessions de questions-réponses à distance est qu'elles peuvent être facilement organisées en ligne, éliminant ainsi le besoin de déplacer quiconque hors de son lieu de travail habituel. C'est particulièrement pratique si les deux parties se trouvent à l'autre bout du monde, par exemple.

3. Créer la documentation du projet

La documentation n'est pas toujours cruciale lorsqu'un projet est en cours. La connaissance du fonctionnement du programme est encore fraîche dans l'esprit des personnes impliquées, à la fois en interne et au sein de l'équipe à distance.

Cependant, lorsque vous vous séparez d'un éditeur de logiciels, il peut être judicieux de leur demander de préparer la documentation du projet pour votre application. Pour cela, on peut demander à l'un des développeurs de passer sa dernière semaine de travail à rédiger la documentation par exemple. Heureusement, le texte peut être généré automatiquement dans une certaine mesure, ce qui réduit le temps nécessaire pour présenter les connaissances nécessaires.

Le résultat pratique de ce processus est généralement un wiki auquel le client peut accéder à sa convenance pour référence future.

La documentation du projet peut être particulièrement utile pour expliquer l'intégration entre l'application et les différentes API utilisées dans le projet. Dans certains cas, des liens vers la documentation des API seront également fournis.

Heureusement, certaines solutions comme le framework Django REST sont déjà bien documentées, de sorte que le processus de production de documentation ne prend pas autant de temps qu'il n'y paraît.

4. Réduisez, puis remettez

Couper le cordon d'un seul coup n'est pas toujours l'option optimale.

Lorsque vous vous séparez d'un éditeur de logiciels, il peut être préférable de terminer progressivement la coopération en réduisant d'abord 1 à 2 personnes et en leur faisant effectuer la maintenance, ainsi que le transfert de connaissances.

Par exemple, si vous démarrez un projet avec ~6 personnes, vous pouvez réduire à 2 personnes pour la maintenance au cours du dernier mois, puis réduire à 0 pour terminer la coopération.

5. Soutien à temps partiel

Dans certaines situations, une assistance à temps plein pendant le transfert peut être excessive. Nous avons eu des cas où le besoin était faible et 20 heures d'assistance par mois étaient suffisantes. Les détails d'un tel arrangement, y compris le nombre exact d'heures d'assistance, peuvent être définis au cas par cas.

Profitez du délai de résiliation

Votre contrat de développement logiciel inclut une période de résiliation pour une raison. Nous faisons de la place pour un transfert en douceur chaque fois que nous signons un nouveau contrat, prévoyant généralement une période de résiliation de 2 mois.

Cela signifie que nous ne mettons jamais fin à la coopération de manière abrupte et que nous ne demandons jamais à un client de se débrouiller tout seul. Aucun éditeur de logiciels digne de ce nom ne devrait ignorer le transfert s'il se soucie ne serait-ce que légèrement de sa réputation. Imaginez simplement les critiques de Clutch que nous obtiendrions si nous essayions de faire disparaître un acte comme celui-là.

Qu'est-ce qui détermine la durée du processus de transfert ?

Lorsque vous créez un logiciel, vous êtes toujours désireux de progresser. "Combien de temps cela prendra-t-il?" est une question naturelle à poser, et le processus de transfert ne fait pas exception à cette règle.

Pour vous donner une réponse courte, le processus de transfert dure généralement un mois ou moins.

La réponse longue est, comme toujours, "Cela dépend". Plus le système est complexe, plus le transfert est long.

S'il s'agit d'un projet de plusieurs années avec une architecture logicielle complexe, la réduction progressive et le transfert peuvent prendre jusqu'à 6 mois.

Mais pour un petit MVP dont la construction a pris 3 mois, enregistrer quelques sessions de questions-réponses peut s'avérer parfaitement adéquat. Alternativement, des sessions de questions-réponses plus un développeur de logiciels qui reste pendant un mois pour soutenir le projet devraient être plus que suffisants.

L'impact de la portée du projet sur la durée du processus de transfert s'applique à la fois à un transfert complet et à une réduction. Passer de 3 équipes à 1 équipe avec l'une de nos entreprises clientes a pris 4 mois, par exemple.

Honnêtement, si votre éditeur de logiciels a une approche agile, il vous aidera à élaborer un processus de transfert personnalisé adapté à vos besoins et à la portée de votre projet.

Python et les normes de codage facilitent tout cela

Lorsque votre projet logiciel est basé sur Python, vous constaterez que le processus de transfert peut être plus rapide que pour certains autres langages.

La principale raison en est la syntaxe claire de Python, qui est facile à lire et à comprendre, en particulier lorsque le code change de mains.

En outre, un éditeur de logiciels compétent aura élaboré des normes de codage qui améliorent encore la clarté. Avec des normes concrètes et uniformes en place, vous devriez être en mesure d'examiner le code fourni par plusieurs équipes de développement et de trouver des éléments communs qui le rendent facile à comprendre.

Réflexions finales

Travailler avec une maison de logiciels, il est sage de commencer par la fin à l'esprit. C'est pourquoi je suis heureux que vous ayez pris le temps de réfléchir à deux étapes à l'avance et d'explorer vos options pour un transfert de projet logiciel réussi.

Pour résumer vos options, rappelez-vous que vous pouvez toujours demander à votre éditeur de logiciels :

  • envoyer un de leurs développeurs pour transférer les connaissances
  • invitez l'un de vos développeurs à travailler avec l'éditeur de logiciels pendant un certain temps pour comprendre le code ;
  • organisez et enregistrez des sessions explicatives qui détaillent le fonctionnement de chaque module, avec une section de questions-réponses ;
  • créer une documentation de projet (telle qu'un wiki) à laquelle vous pouvez vous référer lorsque vous développez le code par vous-même avec votre équipe interne ;
  • réduire d'abord avant le transfert complet ;
  • fournir une assistance à distance à temps partiel si nécessaire.

Comme je l'ai déjà dit, vous n'aurez probablement pas à épuiser toutes les options énumérées ci-dessus pour transférer les connaissances souhaitées. Mais maintenant que vous connaissez les étapes possibles du processus, vous pouvez identifier celles qui correspondent le mieux à vos besoins pour assurer une transition en douceur.


Merci d'avoir lu ! C'était formidable de pouvoir répondre à cette préoccupation sur notre blog. Et dire que tout a commencé par quelques courts mails échangés avec un CTO dans le besoin…

Un merci spécial à Michał Kwiatkowski pour avoir travaillé avec moi sur cet article en tant qu'expert en la matière.

Si vous avez d'autres questions liées aux projets logiciels auxquelles nous pourrions répondre sur le blog, n'hésitez pas à laisser un commentaire ci-dessous ou à nous contacter directement !

Alternativement, nous vous encourageons à apprendre tous les tenants et aboutissants de l'externalisation du développement logiciel ou à vous familiariser avec le développement logiciel nearshoring.