Article original : How to make your launch process a walk in the park
Par David Yu
Il était 2h du matin. Mon téléphone vibrait encore avec des conversations de développeurs sur la façon de gérer les pages 404. Ce n'était que le début…
Moins trois jours avant le lancement. Nous courions comme des poules sans tête. ?
Je devais réfléchir à la manière dont nous pourrions éviter ce sentiment d'apocalypse à l'approche de la date de lancement officielle.
Comme le dit la loi de Murphy :
Tout ce qui peut mal tourner tournera mal.
Comment lancer un produit et s'assurer que quelque chose NE VA PAS mal tourner (dans la mesure du possible) ?
Voici la version bêta de ma stratégie pour le prochain lancement.
Avoir du contenu pour la première semaine
Lorsque vous dites à un client que la date de lancement est dans un mois, la liste des données et des actifs nécessaires pour le lancement sont enterrés dans leur boîte de réception et réapparaissent seulement une semaine avant le lancement. ?
En fin de compte, nous nous précipitons pour des détails à cause des changements soudains d'images et de texte — les « petites choses ».
Oh attendez, le ratio de taille de l'image n'est pas bon, vérifions avec le client s'il y a une autre image…
Un temps précieux est perdu pendant ces allers-retours de communication.
Comment inciter le client à fournir les informations dont vous avez besoin sans être impoli
- Expliquez comment le contenu est l'âme du produit. Sans lui, le produit n'est qu'un squelette de logique sophistiquée.
- Soyez plus proactif dans la compréhension de leurs obstacles pour obtenir ces actifs.
- Écrivez des spécifications détaillées pour les images et les textes : ratio de taille des images, type de fichier préféré, longueur des mots, famille de polices préférée, etc.
- Identifiez la personne responsable de la tâche. Offrez de l'aide et de l'assistance. Les ajustements sont plus faciles à faire dans les premières étapes.
Que faire si le client dit : « Détends-toi… mec, on s'en occupe. » Et qu'aucune action claire n'est entreprise ?
Vous pourriez expliquer pourquoi vous êtes pressé, afin qu'ils comprennent le contexte de tout ce que vous devez faire.
C'est comme construire une maison en briques. Lorsque nous n'avons posé qu'une ou deux briques sur le sol, nous pouvons facilement dire : « Bof, je n'aime pas la brique. Utilisons du bambou. »
Mais il faudra un miracle pour remplacer les briques par du bambou lorsque la maison en briques est presque terminée. Nous construirons une maison (produit) fragile au mieux, ou notre date de lancement sera retardée.
Soyez ferme sur le gel des fonctionnalités
Le gel des fonctionnalités est un concept pratique, plus facile à dire qu'à faire.
En ingénierie logicielle, un gel est un point dans le temps du processus de développement après lequel les règles de modification du code source ou des ressources associées deviennent plus strictes, ou la période pendant laquelle ces règles sont appliquées - Wikipedia
En plus de fixer un gel des fonctionnalités une semaine avant la date de lancement, nous devons également être clairs sur ce qu'est une fonctionnalité.
Un élément discret de fonctionnalité souhaité par les parties prenantes - Oliver Dolan
Si vous avez un site web avec une carte interactive, serait-ce une nouvelle fonctionnalité de construire une carte de « secours » avec un autre fournisseur de cartes ?
Notre processus de réflexion aurait pu être que, puisque nous sommes en Chine, il n'y a aucune garantie que notre premier choix de fournisseur de cartes ne soit pas bloqué.
Nous pourrions donc l'intégrer à notre emploi du temps comme une fonctionnalité.
Mais comment décider si cette fonctionnalité vaut notre temps ?
Voici les questions à poser à votre équipe et à votre client pour chaque fonctionnalité que vous prévoyez d'implémenter
- Que se passe-t-il si nous ne l'implémentons pas ?
- Quel est le niveau de priorité de cela ?
- Avons-nous la capacité de prendre ce travail sans retarder la date de lancement ?
Soyez plus affirmatif avec vos opinions
Le syndrome de l'imposteur nous affecte à tous les stades de notre carrière. Lorsqu'un développeur senior avec 20 ans d'expérience dit : « Faisons comme ça », et que vous n'êtes pas sûr à 100 % d'un contre-argument, vous murmurez sous votre souffle : « Oh… d'accord. »
C'est ce que je fais lorsque je ne peux pas trouver une meilleure solution sur le moment.
Alors, comment se préparer à des situations comme celle-ci ?
- Comprenez exactement comment nous sommes arrivés à cette conclusion en premier lieu
- Formulez votre solution sous forme de question
- Notez ce qui vous dérange et réfléchissez à une meilleure façon de le faire plus tard
- Améliorez vos compétences en communication
Si au début l'idée n'est pas absurde, alors il n'y a aucun espoir pour elle. - Albert Einstein
Prendre soin de DevOps en premier
Nous avons compliqué notre configuration initiale pour le développement, la préproduction et la production. Nous avons passé une quantité énorme de temps à travailler sur un problème et à trouver une solution.
Attendre vingt minutes pour voir mes changements en ligne à cause de pipelines de code sophistiqués et de problèmes de connexion a failli me faire détester le codage. ?
Alors, comment aurions-nous pu faire différemment ?
- L'environnement de développement doit pouvoir changer rapidement.
- Si l'automatisation ne fait pas gagner de temps, ce n'est pas de l'automatisation.
- Utilisez un fournisseur de cloud qui répond à vos besoins
- Assurez-vous que le processus de déploiement est fluide dès la première semaine
Avoir une checklist pour les tests
Pour éviter de perdre du temps à corriger les mêmes choses, voici quelques points à garder à l'esprit lors de la rédaction de la liste.
Et je ne parle pas d'écrire du code pour tester votre code. À quelle fréquence corrigeons-nous quelque chose et quelque chose d'autre se casse ?
Pour éviter d'avoir à corriger la même chose encore et encore, voici quelques points à garder à l'esprit lors de la rédaction de la liste.
- Rédigez la checklist du point de vue de l'utilisateur
- Faites évoluer la liste avec les retours de chaque itération
- Faites relire la liste par un regard neuf
- Aidez les autres développeurs de l'équipe à vérifier la liste
Pratiquer l'empathie
Peu importe la position que vous occupez. Un peu d'empathie fait un long chemin.
Par exemple : si vous avez construit une API utilisée par une application web et que vous êtes sur le point de modifier des noms de clés de données.
Vous comprenez que les noms de clés de données particuliers peuvent avoir été inclus partout par un autre développeur dans une application web. Informez proactivement les autres développeurs avant que les choses ne commencent à mal tourner.
En informant toutes les équipes qui pourraient être affectées par un changement, nous pouvons réduire la probabilité de problèmes lors de la démonstration en direct ou même en production.
Chaque rôle dans une équipe fait face à ses propres obstacles. La capacité à se mettre à la place des autres vous transformera d'un simple développeur qui écrit du code en un leader qui produit un code stable de haute qualité.
Merci d'avoir lu
Si vous avez apprécié cet article, vous pouvez applaudir ? pour que plus de personnes puissent en bénéficier.