Gestion des sorties de produits : le retour d’expérience de SoftFluent – 12/12

Les erreurs courantes observées sur le terrain

Cette série de billets vise à partager notre expérience.

Nous avons détaillé notre propre approche et la façon dont nous traitons les différentes dimensions en interne en tant qu’éditeur.

Mais comme nous avons également l’expérience terrain en conseil aux éditeurs de logiciels, nous pensons utiles de répertorier les erreurs communes que nous avons observées sur le terrain et qui peuvent gravement affecter la capacité à maitriser le processus de gestion des produits.

1. Lier une version du produit à un client particulier : sur le terrain, nous voyons beaucoup d’entreprises qui prétendent être des éditeurs de logiciels, mais en fait, lient fortement les versions du produit à un ou quelques clients. Selon notre expérience, il est très difficile de garder une véritable approche orientée produit quand vous avez une connexion à la clientèle trop forte. Cela aboutit souvent à avoir un développement personnalisé qui est trop spécifique pour le contexte client et ne peut se muer en réel produit.
2. Placer de trop grandes attentes pour la version 1 : certains éditeurs de logiciels placent la barre très haut dès le début, ou pour leur nouvelle offre dans le cas du lancement un tout nouveau produit. Essayer de répondre à tous les besoins d’une manière très complète dans une première version est vouée à l’échec la plupart du temps.
3. Démarrer sans une vision minimale du périmètre de vente : a contrario, nous voyons aussi des équipes qui commencent sans avoir une vision réelle du périmètre à atteindre et du produit à vendre. Poussées par les messages axés sur la méthodologie agile, certaines personnes pensent que vous n’avez pas besoin de savoir très bien où vous vous dirigez pour démarrer votre projet. Dans la plupart des cas, cela ne fonctionne pas. De notre point de vue, les méthodologies agiles fonctionnent bien lorsqu’elles sont utilisées comme une méthode de livraison à l’intérieur d’un processus de planification global plus macroscopique.
4. Négliger la documentation: Parce qu’il n’est pas très amusant d’écrire de la documentation, notamment pour les profils développeur, cette zone n’est pas traitée avec le niveau de qualité approprié. En tant qu’éditeur, vous ne devriez jamais développer une fonctionnalité que vous n’êtes pas prêt à documenter. N’est-ce pas évident exprimé de cette façon ?
5. Sous-estimer les tests: cette étape est cruciale pour le succès du logiciel. Elle englobe de nombreuses dimensions (voir notre billet précédent sur les meilleures pratiques de tests logiciels) et chaque éditeur devrait y allouer le bon niveau de ressources et d’attention.
6. Considérer le code comme une production à faible ajoutée : Nous voyons des éditeurs de logiciels qui tentent d’appliquer les recettes de l’industrie avec un schéma simple en disant que toute la valeur réside dans la conception, et que le code peut être confié à des entreprises de services de bas niveau, ces sociétés étant locales, near-shore ou off-shore. C’est peut-être applicable pour certains logiciels de gestion de base qui offrent une large couverture, mais qui restent très simple dans les fonctionnalités et dont celles-ci sont parfaitement définies. Pourtant, la plupart du temps, vous seriez en mesure d’obtenir des résultats beaucoup plus efficaces avec 1/10e de l’investissement avec des ingénieurs logiciels de bon niveau disposant de l’expérience appropriée.
7. Sous-traiter ce qui n’est pas maîtrisé en interne : nous croyons à la spécialisation et à la sous-traitance. Cela peut s’avérer très utile lorsqu’elle est utilisée correctement. Mais il y a une règle d’or apprise au fil du temps : vous ne pouvez sous-traiter que ce que vous comprenez bien. Vous devez avoir la capacité de piloter et de contrôler le travail de vos sous-traitants, et vous ne pouvez pas faire cela si vous perdez les connaissances de base des éléments clés. Ceci s’applique fortement dans toutes les dimensions du logiciel que vous envisagez de sous-traiter.
8. Faire un saut technologique sans en mesurer les impacts méthodologiques : nous connaissons malheureusement de près des dizaines de projets qui sont tombés dans ce piège. Malgré la mise en avant des avantages des plates-formes .NET ou Java qui prônent la simplicité, ce n’est pas simple du tout dans la mise en œuvre, et c’est peu productif. Ces plates-formes donnent de nouvelles possibilités techniques et des capacités de connexion inégalées, mais elles sont plus complexes que jamais. Un éditeur passant d’une approche traditionnelle (comme Progress, PowerBuilder ou NSDK pour n’en nommer que quelques-uns) est plus que susceptible d’échouer dans ses nouveaux projets s’il ne mesure pas l’impact du changement technologique. La méthodologie doit être ajustée dans la mesure où les possibilités de mise en œuvre sont nombreuses dans des plates-formes ouvertes telles que .NET ou Java. Trouver le bon équilibre sur de nombreux sujets est plus que délicat et nécessite une réelle expérience sur ces technologies.

En conclusion, nous espérons que l’expérience que nous avons partagée pourrait vous être utile. Ce ne sont que nos points de vue et nous aurons certainement omis quelques points.

Comme nous sommes toujours désireux d’en apprendre davantage, nous nous réjouissons d’avance de vos commentaires sur ces éléments.

Daniel COHEN-ZARDI

SoftFluent, Président