Table des matières du cours
1. Rôle du chef de produit et du cadre
2. Segmentation du marché et analyse concurrentielle
3. Personnages de l'utilisateur
4. Test d'hypothèse
5. Positionnement du
produit 6. Feuille de route du produit <- Vous êtes ici
7. Rédaction des exigences pour le développement
8. Business model et Business- Plan
9. Plan financier et tarification
- à suivre
Avoir une feuille de route est très important pour gérer le développement de produits. Cependant, pour dresser correctement une feuille de route, il est nécessaire d'aborder cette question de manière systématique. Il est très important de ne pas confondre une feuille de route avec une vision, même si avoir une vision est nécessaire pour bien construire une feuille de route.
Devise des Nations Unies: «Pensez globalement, agissez localement . " Fait intéressant, cela fonctionne également lors de la création d'une feuille de route pour un bon logiciel. Pour ce faire, vous devez avoir une vision globale afin que vos aspirations ne s'arrêtent pas ici et maintenant. Dans le cadre de la vision, des objectifs sont fixés - ils sont également assez globaux, et c'est vers ces objectifs que la feuille de route doit conduire. Lorsque vous vous déplacez conformément à la carte préparée, les versions deviennent des jalons et des étapes de ce mouvement - l'incarnation d'étapes spécifiques pour le développement de produits.
Quel horizon devriez-vous balancer avec la planification? Cela peut être différent, mais pour commencer il vaut mieux se limiter à 6 mois. Si vous savez exactement où votre produit va se déplacer, cela peut prendre 3 ou 5 ans. Il n'y a pas de limites. Par exemple, dans son récent discoursLe fondateur d'Amazon, Jeff Bezos, a annoncé le programme spatial Blue Origin avec un horizon de planification de 50 à 100 ans. Autrement dit, une personne crée une entreprise qui fonctionnera la plupart du temps après sa vie. Comment est-ce possible?
C'est juste que dans ce cas, nous parlons d'une vision globale - Blue Origin doit offrir la possibilité de vols spatiaux intenses. Amazon s'appuyait sur une infrastructure de messagerie et de messagerie déjà existante, a déclaré Bezos. S'ils n'existaient pas, Amazon ne serait pas en mesure de travailler ou de réussir. Aujourd'hui, Blue Origin prévoit de créer l'infrastructure pour les futurs voyages spatiaux - fusées, ports spatiaux, satellites, stations orbitales, etc. Les objectifs mondiaux de Blue Origin sont de construire un vaisseau spatial d'ici 2025.
Comprendre vos objectifs globaux aide à élaborer une feuille de route où nous montrons des étapes concrètes, en construisant un plan réaliste pour atteindre les objectifs fixés dans un proche avenir. Et Blue Origin, en tant qu'entreprise aux projets ambitieux, tente de remplir sa mission - organiser un service mondial pour la circulation accessible et pratique des personnes et des marchandises.
Du ciel à la terre ...
Prenons un exemple plus réaliste. Si une entreprise de construction est engagée dans une construction de haute qualité, le concept de son travail peut ressembler à ceci:
● Vision - construire le meilleur quartier résidentiel du nord de Moscou (SAO).
● Objectifs - 5000 appartements, architecture moderne, confort de classe, aménagements pratiques, une cour sans voitures.
● Feuille de route - files d'attente de développement et d'aménagement paysager.
● Libération - bâtiments finis en béton, routes, parcs (la division est possible au stade de l'achèvement).
● Fonctionnalité - un composant de la version. Par exemple, une aire de jeux, des arbres plantés, un parking couvert, une rampe.
Comment créer une feuille de route produit logiciel?
La feuille de route du logiciel comprend des versions, dont chacune doit contenir certaines fonctionnalités. Il est très important de planifier une feuille de route par dates, en tenant compte des capacités et des ressources disponibles (nous en parlerons plus tard). Par exemple, voici à quoi ressemble une feuille de route pour l'une des applications sociales.
Gardez à l'esprit que la feuille de route doit être planifiée pour tous les départements à la fois. Si l'entreprise est grande et que les directeurs commerciaux ont leur propre feuille de route, vous devez la lier à la feuille de route du département de développement. Sinon, lorsque vient le temps, par exemple, de promouvoir un produit sur le marché asiatique, il se peut que vous ne disposiez pas d'une localisation toute faite ... et même d'un support pour la langue chinoise.
Les demandes concernant ce qui devrait être contenu dans un produit proviennent de différents horizons. Nous en avons déjà parlé dans l'un des articles précédents .... Ils doivent être soigneusement organisés et planifiés. Il est important de comprendre qu'il ne sera pas possible de préparer et de publier toutes les fonctionnalités de la version 1.0, car en réalité il n'y a jamais assez de ressources pour mettre en œuvre toutes les idées (si ce n'est pas le cas, alors vous avez peu d'idées et vous devez réfléchir davantage).
Avec la bonne approche, la feuille de route est l'occasion de diviser le processus de développement de produit en étapes et de déployer des fonctionnalités avec une priorité et une importance décroissantes dans les itérations.
Jetons un coup d'œil à un autre cadre de développement de produit logiciel (Software Product Management Framework) qui contrôle le développement logiciel:
La matrice de maturité d'une entreprise qui vit dans un cadre donné est déterminée par le tableau suivant. Et avec l'adhésion formelle au processus de préparation de la feuille de route, l'entreprise atteint immédiatement le deuxième niveau de maturité:
en général, ce cadre est une branche distincte pour tout cours sur le développement de produits. Nous ne nous attarderons pas dessus maintenant. Si quelqu'un souhaite lire un article supplémentaire sur ce sujet, veuillez laisser un commentaire sur ce message.
Ici, pour nous-mêmes, nous n'accepterons qu'en observant certaines procédures formelles de développement logiciel, tout en construisant ces processus, l'entreprise elle-même améliore la culture de la fourniture de meilleurs logiciels. La feuille de route fait partie de cette culture.
Comment collecter et traiter les exigences des produits?
Lorsque nous recevons des demandes de différents côtés, elles doivent être introduites dans une sorte de système. Par exemple, Acronis utilise Jira, qui est un outil assez puissant, mais pour les startups, vous pouvez utiliser des outils plus simples, y compris des outils gratuits, par exemple Redmine ou Asana.
L'essentiel est que toutes les idées soient enregistrées, car il n'y a pas de mauvaises pensées. Si l'idée ne mérite pas encore d'être mise en œuvre, sa priorité restera faible. Par conséquent, il est très important de saisir chaque phrase dans le système - même sans une description détaillée de "comment cela devrait fonctionner". Ce n'est qu'avec cette approche que vous pouvez planifier la mise en œuvre des fonctionnalités demandées, c'est-à-dire créer une véritable feuille de route.
Toutes les idées arrivent dans le soi-disant «backlog entrant», elles peuvent être formalisées ou «brutes», sans évaluation ni compréhension de qui a besoin de ces fonctionnalités. Après avoir traité les demandes et ajouté des détails, certains d'entre eux peuvent passer à la prochaine version. Le reste est envoyé dans le Backlog et je peux y rester longtemps.
Épique
La méthodologie Agile ou Scrum implique un terme comme "Epic". Pour expliquer son essence aussi simplement que possible, nous parlons alors d'une grande fonctionnalité, dont la mise en œuvre nécessite la participation de tous les participants - développeurs, testeurs, concepteurs d'interfaces, rédacteurs techniques, etc.
En règle générale, lors de la création d'une épopée, son importance d'un point de vue commercial est évaluée, les coûts de main-d'œuvre sont calculés et une décision est prise entre l'inclure dans la version actuelle ou l'envoyer dans le backlog.
Vous pouvez attribuer une priorité dans le système aux epics qui ont déjà été évalués. Par exemple, dans le même Jira, vous pouvez définir "high", "medium" ou "low". Mais, par exemple, dans notre backlog Acronis, il y a des centaines, voire des milliers de fonctionnalités. Dans ce cas, des priorités simples sont indispensables.
Calcul du score de fonctionnalité
Une méthodologie de notation plus complexe est appelée Feature Score. L'idée est de regrouper tous les facteurs influençant le développement dans une seule notation. Ensuite, en fonction de l'évaluation normalisée, prenez des décisions concernant l'inclusion de la fonctionnalité dans la version ou l'abandon du développement pour le moment. Ainsi, les métriques positives ajoutent des points à une caractéristique, tandis que les négatives agissent avec une proportion inverse (plus de valeur - moins de points). Certaines des mesures positives comprennent:
1. Urgence.
2. La taille du client qui en a besoin.
3. Augmentation de la part de marché en raison de l'émergence de nouveaux clients.
4. Bénéfice ou perte potentiel du départ des clients actuels.
5. Réalisations stratégiques (objectifs qui nous mènent à l'incarnation de la Vision).
Mesures négatives:
1. Le montant des coûts de main-d'œuvre.
2. Risques potentiels.
Le score de fonctionnalité doit être un nombre. Il ne s'agit pas d'une évaluation qualitative, mais d'une sorte de notation, et la méthode de son calcul doit être unifiée et approuvée dans le cadre du développement d'un produit spécifique.
Les points sont déterminés en fonction des valeurs normalisées, des objectifs de marché de l'entreprise et d'autres paramètres. Le premier paramètre pris en compte dans le Feature Score est le facteur client. Le soi-disant facteur client est défini comme le produit de l'urgence et de la taille du client. Vous pouvez voir un exemple de calcul dans l'image ci-dessous.
Pénétration du marchéest définie comme la probabilité d'attirer de nouveaux clients et dépend de vos projets d'élargissement de votre clientèle. Par exemple, pour les fonctionnalités qui n'attireront pas de nouveaux clients, ce paramètre peut être égal à 0, et pour celles qui peuvent vous apporter, par exemple, 500 clients, le score sera de 20.
La question suivante est la conformité de la stratégie. Pour évaluer la stratégie, vous devez vérifier si la fonctionnalité vous aide à suivre des directions de développement stratégiques. Et plus il couvre de directions, plus le score sera élevé.
Le revenu est le profit potentiel que la mise en œuvre d'une fonctionnalité peut apporter. L'estimation de ce paramètre dépend de la taille de l'entreprise, des caractéristiques du produit et des revenus que vous espérez recevoir. Le tableau présente un exemple de notation pour cet indicateur.
Mais parlons maintenant des facteurs opposés, qui donnent moins de points à une caractéristique, plus ils se manifestent. Par exemple, les coûts de développement peuvent également être fixés pour votre entreprise au niveau de certaines estimations, en fonction de combien vous êtes prêt à dépenser pour le développement de certaines fonctionnalités.
Les risques constituent le deuxième aspect. Plus votre confiance dans les évaluations est faible, plus les risques sont élevés, ce qui signifie que la valeur du critère dans la formule de score de fonctionnalité est faible.
Après avoir pris en compte tous les facteurs mentionnés, la formule du score de fonctionnalité peut ressembler à ceci:
Il est bon que les scores soient objectifs, basés sur des facteurs spécifiques. Mais si vous venez d'entrer sur le marché, faites toujours un score de fonctionnalité. Mieux vaut être subjectif que rien du tout.
Feuille de route sur l'exemple de l'application Taxi
Dans l'un des articles précédents , nous avons déjà parlé de la création d'une application pour appeler un taxi. Supposons que nous ayons besoin de classer les fonctionnalités suivantes pour ce produit:
Un tableau avec des priorités pourrait ressembler à ceci:
Considérez la fonctionnalité "Trier au bon moment". En résumant tous les paramètres, nous obtenons 56. Que signifie ce nombre? Rien! Il s'agit d'une note relative et nous devons calculer les 9 caractéristiques, en respectant les mêmes critères et notes. Le résultat est une liste de priorités. Dans notre application, nous devons évidemment créer une application mobile sur Android. Le deuxième mouvement est le tarif «Enfants».
Une approche systématique permet de ne pas faire ce qui n'est pas si important pour l'entreprise et de ne pas choisir une «caractéristique aléatoire» pour la mise en œuvre. Le rendement des travaux progressifs et échelonnés sera plus élevé. Et ceci est très important, car il y a toujours des facteurs contraignants pour le développement de chaque projet: temps, coût, volume. La combinaison de ce qui vous donne la qualité.
Pas seulement des priorités
La planification des versions tient compte de la capacité de l'équipe de développement. Certains produits ont plusieurs commandes de ce type. Par exemple, pour créer un service de commande de taxi, au moins il devrait y avoir des commandes backend, QA, Android, iOS.
Mais en plus de prioriser, nous devons également estimer le nombre d'heures que les développeurs peuvent allouer pour travailler sur chaque fonctionnalité suivante. Pour ce faire, il faut multiplier le nombre de personnes dans l'équipe par le nombre de jours alloués à sa préparation. Comprendre ce qui peut entrer dans la capacité disponible pour la prochaine version (portée) permet d'éviter de gaspiller des ressources.
La capacité de différentes équipes pour un cycle de publication:
Si vous regardez le tableau ci-dessous, il devient clair que beaucoup de ressources sont nécessaires pour une application mobile pour iOS, non seulement l'équipe de développement iOS, mais aussi les spécialistes du backend et du QA. C'est pourquoi il est logique que la direction prenne la décision de ne pas inclure l'application mobile pour iOS dans la première version, puisque l'équipe n'aura pas le temps de le faire de toute façon, mais d'un autre côté, ils finiront «Commande de taxi au bon moment».
Ainsi, si nous allons dans l'ordre de priorité de toutes les fonctionnalités triées, alors la feuille de route pour le développement de l'application en commandant un taxi ressemblera à ceci:
Chaque version ultérieure inclura les fonctionnalités prioritaires suivantes qui sont placées dans la capacité de l'équipe de développement.
Feuille de route - comme philosophie de développement de produit
N'oubliez pas que la feuille de route n'est pas un engagement, mais plutôt une prédiction. Je vous conseillerais de traiter la feuille de route comme un plan actuel. Il est possible que dans un mois un nouveau client vienne demander une nouvelle fonctionnalité. Et lorsque nous l'ajouterons à l'arriéré, sa priorité sera probablement plus élevée que tout ce qui avait été prévu auparavant. En règle générale, lorsque vous travaillez sur un produit, il est important d'avoir une feuille de route pour chaque instant, mais vous ne devez pas la rendre statique, car aujourd'hui, vous devez vous adapter aux conditions changeantes du marché.
Le travail proposé avec la feuille de route (hiérarchisation des fonctionnalités selon des règles générales) nécessite une culture interne. Toutes les parties prenantes doivent suivre les mêmes principes de notation, la première étape consiste donc à discuter de la formule de calcul, puis à suivre cette règle. Bien sûr, tout peut être changé s'il y a une compréhension de la façon d'améliorer la hiérarchisation, mais il sera alors nécessaire de recalculer les priorités pour l'ensemble de l'arriéré.
Pour les gros produits, il est également conseillé d'allouer une capacité différente des équipes de développement pour des choses qui ne sont pas directement liées au développement de fonctionnalités personnalisées .) dépenser pour maintenir l'écosystème existant sur l'ancienne version ». Pour résoudre de tels problèmes, vous pouvez allouer, par exemple, 25% de la capacité de l'équipe aux fonctionnalités liées à la conquête de nouveaux clients, 45% à la fidélisation des clients actuels, 20% à la dette technique et au refactoring, et 10% à laisser comme tampon afin qu'il y ait de la place pour les fonctionnalités. qui est venu soudainement ou en surcharge pour rendre compte d'activités non directement liées au développement de produits (déploiement d'un nouveau système de construction, mise en œuvre de CI \ CD, etc.).
Conclusion
Pour planifier avec succès le développement et ajuster la feuille de route, vous devez régulièrement revoir votre backlog et recalculer le score des fonctionnalités pour les fonctionnalités que vous prévoyez de développer et que vous souhaitez qu'elles soient dans la portée de la version. Mais si nous avons déjà décidé de la prochaine version, il devient nécessaire d'établir une interaction entre les gestionnaires et les développeurs.
Pour ce faire, dans le prochain article, nous examinerons le mécanisme de création d'exigences pour une fonctionnalité qui doit être présentée au département de développement. Cela est nécessaire pour que la fonctionnalité soit développée, de préférence sous la forme dans laquelle vous souhaitez la voir. Nous parlerons des raisons pour lesquelles les exigences devraient être claires, comment elles devraient être formalisées et quelles pratiques existent pour travailler avec les exigences des développeurs.
→ L'enregistrement vidéo de toutes les conférences du cours est disponible sur YouTube
Conférence sur la feuille de route et les exigences pour le développement: