Développement produit : Contrôler les délais, arbitrer et communiquer sur les retards.

La gestion du projet de développement produit conditionne beaucoup la survie de votre projet d’innovation. Voici quelques retours d’expérience pour vous aider à arbitrer.

L’exécution, autrement dit la gestion du projet d’entreprise, est critique dans le développement produit de la Startup. Les méthodes “Lean” (Lean Startup, Lean Canvas, etc..) appliquées intelligemment, sont efficaces pour développer son produit car elles permettent de s’appuyer avant tout sur une compréhension fine du besoin des utilisateurs. Il ne faut cependant pas oublier de prendre compte toutes les autres composantes du modèle d’affaires. En effet, si le Lean Startup est optimal pour produire la meilleure solution à un problème donné, la méthode ne permet pas d’avoir un horizon de temps certain🎶.

Le développement produit, la résolution optimale d’un problème.

Dans la constitution de son MVP, il faut aussi faire la différence entre la valeur que produit le service et l’expérience de l’utilisateur. Il est préférable au départ de sortir un produit avec une valeur extraordinaire et une expérience utilisateur moyenne plutôt que l‘inverse. Même si en BtoC il est important d’avoir une interface claire et une ergonomie qui rends simple l’utilisation du produit, il est préférable de privilégier la qualité de la résolution faite du problème.

Quelles sont les arbitrages à réaliser dans l’exécution de son projets ?

Pas de sous-traitance.

Pendant le développement du MVP il vaut mieux faire le développement produit soi même que faire appel à un prestataire. La raison principale est que les objectifs d’un prestataire informatique ne sont pas du tout alignés avec ceux de la Start-up. Cet excellent article de Joel Gascoigne explique en plus détail les 3 principales raisons de ne pas le faire. Si on est pas développeur, on doit trouver le moyen (et il en existe des tas) de “bootstraper” sans produit.

“Done is better than perfect” — MZ

En phase de développement produit l’impératif de la société est toujours la croissance. Elle s’obtient en mettant à disposition le plus régulièrement possible (pour élargir la cible) un produit dont la qualité est croissante (pour améliorer la rétention). Là encore, l’approche de Buffer est assez intéressante : Traiter son produit comme si il était terminé. Dés que le produit en cours de développement devient meilleur que celui en ligne, il faut le passer en production.

Plan, check, do, act.

90% des projets informatiques connaissent des retards de livraisons sur le planning initial. C’est un fait. Cependant comme on l’a dit plus haut, la gestion des délais est cruciale. Pour être sûr de délivrer dans les temps, notre méthode concise à découper les tâches à l’extrême, livrer le plus fréquemment possible, définir le chemin critique (périmètre minimal à atteindre dans le délais incompressible) et à intercaler du développement produit “d’arbitrage” (i.e. des développements qui peuvent être décalés dans le temps). Les délais sont gérés à la semaine (ou toutes les 2 semaines) pour communiquer en permanence sur les retards aux utilisateurs, aux clients, ou aux investisseurs.

Respecter les développeurs.

On a souvent tendance à multiplier les temps de développement par 2 et à ajouter 10%. Ce n’est pas une bonne pratique. En faisant cela, on décrédibilise l’équipe de développement et on l’encourage à ne pas se soucier des délais. Au contraire que les équipes en charge du développement produit doivent être responsables des délais. Et de la même manière que les commerciaux sont objectivés sur leurs ventes, les développeurs devraient être objectivées sur leurs délais de livraison et sur la qualité du code produit (i.e. la couverture en tests unitaires).

📅 Quelles sont les méthodes qu vous utilisez pour développer votre projet, et comment les avez-vous adaptés ?


Originally published at 4venture.

Like what you read? Give 4venture a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.