Réduire le délai de mise sur le marché d'un nouveau site web d'entreprise

Les sites web d'entreprise sont vraiment complexes. Ils nécessitent beaucoup de temps et d'efforts chaque fois qu'ils doivent être reconstruits. Parfois, on a l'impression que le site web, dès qu'il est terminé, pourrait être reconstruit à nouveau. Voyons pourquoi cela se produit et que faire à ce sujet.

Les projets de sites web d'entreprise prennent trop de temps

Les reconstructions de sites web d'entreprise sont complexes. Il y a beaucoup de choses à prendre en compte, de nombreuses parties prenantes à impliquer, des attentes élevées qui doivent être satisfaites. Si nous ajoutons à cela un grand nombre d'exigences, de contenus et de fonctionnalités, nous nous retrouvons avec une entreprise colossale. Et les projets d'envergure prennent du temps.

Mais les projets de sites web de longue durée créent toutes sortes de risques et de coûts supplémentaires que nous pourrions éviter s'ils étaient plus courts. Regardons cela de plus près.

Coûts supplémentaires de la gestion des changements

Si votre site web d'entreprise nécessite 18 mois pour être livré, il est presque certain qu'il y aura des changements au sein de l'entreprise pendant cette période. Les plans de marketing et de vente seront mis à jour ou modifiés. Les produits et les stratégies de marché peuvent également être modifiés. En général, tous ces changements nécessitent des modifications du site web. Parfois, ils peuvent n'être que des ajustements cosmétiques, mais ils peuvent aussi bien être substantiels.

Si votre projet de refonte de site web avait été plus court, vous auriez juste pu attendre qu’il se termine pour introduire les changements par la suite. Cependant, s'il doit durer encore 10 mois, vous ne pouvez pas attendre - Vous mettriez votre entreprise en danger de subir des pertes à cause d'un site web obsolète. Vous devrez ajuster le projet.

Il y a bien sûr un processus pour introduire des changements dans un projet en cours. Surtout si le projet est mené en méthodologie agile. Cependant, la plupart des changements augmenteront les coûts et prolongeront davantage le projet. Ils sont également difficiles à introduire pendant que le projet est en cours.

Coûts supplémentaires de la double maintenance

Pendant que le nouveau site web est en cours de construction, l'ancien assure toujours tout le travail pour l'entreprise. Si vous devez introduire des modifications, vous devrez probablement les appliquer au nouveau site web mais aussi à l'actuel. Et nous savons que vous devrez le faire si votre nouveau site web est encore loin. Cela génère des coûts supplémentaires de maintenance de 2 sites web en même temps. Une décision très difficile à prendre par tout cadre, surtout lorsqu'il sait qu'un des sites sera abandonné en moins d'un an.

Coût de ne pas mettre à jour le site web actuel

“Désolé, nous avons la nouvelle offre mais elle n'est pas sur le site web. Nous construisons le nouveau site web maintenant. Laissez-moi vous envoyer un PDF.”

      - dit un représentant commercial dans une entreprise qui a décidé de ne pas supporter le coût de la double maintenance.

Bien sûr, le coût est toujours là. C'est juste dans les opportunités perdues.

Laisser l'ancien site web tel quel jusqu'à ce que le nouveau soit prêt est probablement le pire choix, car vous perdrez du business et vous ne saurez même pas combien vous perdez. Vos départements marketing et ventes seront bloqués pendant longtemps, incapables de rivaliser.

Alors comment réduire le temps de mise sur le marché ?

Il y a plusieurs façons de réduire le temps de mise sur le marché des sites web. La meilleure façon est de prendre un peu de chacune pour minimiser le temps du projet.

1. Simplifier

Lorsque nous planifions, nous laissons notre imagination s'épanouir. Nous choisissons les meilleures solutions disponibles, examinons ce que font les autres et comment, et nous essayons de reproduire et de construire sur toutes les meilleures pratiques. Bien que cela soit formidable, c'est souvent complexe et coûteux. Une fois que vous avez établi une liste d'exigences, vous devez l'inspecter en détail à la recherche de choses qui peuvent être simplifiées sans compromettre les résultats souhaités. Par exemple :

• les mécanismes complexes pourraient être remplacés par quelque chose de plus simple (une API pourrait être remplacée par un outil d'import/export, une opération système complexe pourrait être échangée par un import/export depuis Excel, où vous pouvez effectuer des opérations
• les fonctionnalités personnalisées pourraient être remplacées par des solutions disponibles sur le marché ou SAAS (par exemple suivi & analyse, personnalisation de contenu, solutions d'e-mailing, sauvegardes, boutique en ligne personnalisée avec Shopify ou similaire)
• certaines options de configuration peuvent être omises. Cela nécessitera que l'équipe de développement modifie ces options par la suite, mais nous planifions souvent trop d'options au départ et beaucoup ne sont jamais utilisées.

2. Fractionner le développement

Après avoir recueilli toutes les spécifications pour le site web et effectué tous les wireframes, vous vous retrouverez généralement avec un périmètre très important. Le moyen le plus simple de le réduire est de fragmenter le développement.

Pour la première phase, ne choisissez que les parties les plus importantes. Les parties critiques qui doivent absolument être là et celles qui sont les plus cruciales sur votre site web (par exemple sections produits, formulaires de contact, etc.). Planifiez la publication de celles-ci dans la ‘Phase 1’. Tout le reste sera livré dans la ‘Phase 2...3’.

Il y a beaucoup d'avantages à une approche par étapes. En particulier :

1. Les éléments qui ont le plus d'impact sont livrés rapidement. Ils ne sont pas retardés par les sections “à propos de nous” et autres. Vous pouvez profiter des principaux avantages même avant que le site web complet ne soit achevé.
2. Vous pouvez vous concentrer mieux sur les fonctionnalités essentielles sans être perturbé par des sections moins importantes.
3. Il est beaucoup plus facile de vendre un développement par étapes aux parties prenantes par rapport à une réduction totale des moins importants. Et l'expérience montre qu'après le lancement de la phase 1, il y a souvent un nouvel espace pour réévaluer ce qui devrait entrer dans la phase 2, phase 3, etc. Vous comprenez.
4. La publication rapide de la première phase vous permet de tester vos hypothèses plus rapidement et de vous ajuster plus vite et moins cher.
5. Après la publication de la première phase, vous apprenez beaucoup et les phases suivantes sont meilleures qu'elles ne le seraient si tout était livré d'un coup.

Et comment aborder les éléments restants, moins importants, mais toujours requis qui ne sont pas programmés pour la phase 1 ? Il y a 2 façons :

1. Les simuler - créer des solutions temporaires simples pour ces sections (par exemple en copiant le HTML de l'ancien site web). Cette solution pourrait être bonne pour le “à propos de nous” et d'autres sections assez statiques.
2. Utiliser un proxy pour rediriger le trafic entre l'ancien et le nouveau site web selon que l'utilisateur souhaite visiter quelque chose qui est déjà sur le nouveau site ou encore sur l'ancien. Cela nécessite quelques ajustements de conception pour s'assurer que les utilisateurs ne soient pas déconcertés par des changements soudains d'apparence (entre vieux et nouveau) mais c'est dans l'ensemble une méthode très efficace de migration progressive.

L'approche en plusieurs phases n'a probablement pas de sens si tout le projet durera moins de 4-6 mois. Dans tous les autres cas, je vous recommande de la considérer.

3. Réduire la portée

Si vous avez suivi une phase complète de planification, discuté avec toutes les parties prenantes et capturé toutes les exigences, vous aurez beaucoup à livrer. Un bon moyen de réduire cette portée est de prioriser les éléments. Marquez tout selon l'ordre :

• 1 - Critique - cela doit être là quoi qu'il arrive. Nous ne pouvons pas lancer sans cela. (par ex. page d'accueil, SEO, formulaires de contact, produits)
• 2 - Important - vraiment important pour l'entreprise, nous pourrions nous en passer mais peut-être seulement pendant quelques semaines (analyses avancées, nouveau blog contre ancien, boutons de partage social, chargement paresseux des images sur mobile)
• 3 - Agréable à avoir - cela nous aiderait beaucoup mais nous pouvons nous en passer pendant une période prolongée (nouvelles intégrations, fonctionnalités éditoriales nous aidant à publier plus rapidement, API REST pour un service externe, etc.)
• 4 - Utile mais non requis

Lorsque vous créez un tel ordre, il est vraiment facile de décider ce qui doit être livré et ce qui peut être omis (ou programmé pour les “phases suivantes”) pour rendre votre projet plus court.

4. Augmenter l'équipe

Augmenter l'équipe est une méthode assez évidente si l'on veut augmenter la production dans un temps fixe. Je le mets cependant en quatrième place, car ce n'est pas une panacée pour tous les problèmes.

Tout d'abord, il est logique de livrer des projets en phases et de réfléchir à ce qui est vraiment important et ce qui ne l'est pas.

Cependant, ce qui est particulièrement important, c'est la loi des rendements décroissants. Plus l'équipe est grande, plus la productivité d'une personne est faible. Les petites équipes sont agiles, rapides, connectées et informées. Les grandes équipes doivent passer beaucoup de temps à se mettre d'accord, à planifier, à revoir et à s'informer sur l'état actuel. Il est difficile de gérer une grande équipe et cela coûte beaucoup plus cher globalement.

Par exemple, si vous souhaitez utiliser les méthodologies agiles, votre équipe ne devrait pas vraiment dépasser 8 personnes. Si vous avez besoin d'une équipe beaucoup plus grande, c'est toujours possible mais vous devriez la diviser en plusieurs équipes sprint petites, chacune travaillant sur un sous-ensemble de votre système. De plus, vous devez avoir une vue d'ensemble de ce que chaque équipe livre et comment cela s'intègre dans l'ensemble.

Pour résumer - augmenter une équipe peut fonctionner, mais après environ 8 personnes, il devient subitement beaucoup plus difficile de gérer et devient à la fois exponentiellement plus coûteux.

NE pas compromettre la qualité et les processus

En référence à notre expérience de consulting Drupal, plus le projet est grand et les exigences complexes, plus il est important d'avoir des processus, des flux de travail et des tests. Les grands projets peuvent vraiment trébucher sous une énorme quantité d'erreurs et de problèmes s'il n'y a pas de processus pour les aborder.

Introduire l'automatisation (par exemple l'intégration continue) et les tests automatisés à votre projet peut sembler être un coût inutile, mais ce n'est pas le cas. Vous économiserez une énorme quantité de temps, que vous auriez autrement passé à corriger des bugs et à tester manuellement. Le temps d'itération de vos équipes sera considérablement réduit et le nombre d'erreurs de régression sera beaucoup plus faible si vos processus QA sont en place et automatisés.