Bonjour, Habr!
Aujourd'hui, nous voulons parler de la façon dont notre équipe produit aborde la préparation des exigences fonctionnelles pour les développeurs lors de la création de nouveaux produits et fonctionnalités.
Au stade du développement, de nombreuses surprises peuvent survenir, surtout si la tâche n'est pas clairement décrite. Différents membres de l'équipe peuvent comprendre le développement et le fonctionnement de la même fonctionnalité de différentes manières, les chefs de produit sont donc responsables de la création d'un produit depuis le développement du concept jusqu'à la version finale. Et une partie importante de ce processus est la préparation des exigences fonctionnelles.
La question de la description des tâches pour les développeurs que nous avons déjà abordée dans l'article
Comment les gestionnaires apprennent à définir des tâches pour les développeurs , mais nous y parlons plus de problèmes administratifs et aujourd'hui nous parlerons plus de problèmes techniques. Il s'agit d'un élément extrêmement important de toute entreprise dont les ventes se font via Internet. Chaque entreprise qui se développe activement dans l'environnement Internet se transforme en fait en une entreprise de logiciels. Mais malgré cela, les compétences dans le domaine de la gestion des exigences ont tendance à croître très lentement.
En conséquence, nous voyons souvent la même image: les tâches de différents départements tombent constamment dans le département de développement, les exigences de ces tâches sont décrites vaguement, et dès que quelque chose est mis en œuvre, il revient immédiatement pour révision (parce que le directeur n'a pas décrit complètement ce que je voulais, et le développeur a fait ce qu'il voulait). Le résultat est évident: des délais imprévisibles pour des tâches qui peuvent prendre des mois, une équipe démotivée, des tensions au sein de l'équipe, des clients insatisfaits, à la traîne des concurrents, etc.
Avec cet article, nous voulons donner une recette simple qui jettera les bases de la résolution de ces problèmes. Il peut être recommandé en toute sécurité pour l'étude (en outre, pour l'action) à tous ceux qui fixent des tâches.
Différentes entreprises ont différentes approches pour rédiger les exigences fonctionnelles, mais chez
Retail Rocket, nous avons opté pour cette option et nous n'avons jusqu'à présent aucun regret.
Exigences fonctionnelles: qu'est-ce que c'est et pourquoi sont-elles nécessaires
Voyons d'abord quelles sont les exigences fonctionnelles.
Exigences fonctionnelles - c'est la déclaration du problème au développeur. Tout ce qui n'est pas indiqué dans les exigences est fait à la discrétion du développeur, qui s'écarte souvent de la présentation du chef de produit sur le résultat attendu. Par conséquent, les exigences doivent contenir des réponses à toutes les questions possibles sur la tâche.
Les exigences fonctionnelles consistent généralement en:
- User story - montre ce que vous attendez de l'équipe de développement
- Cas d'utilisation - afficher les scénarios d'utilisation
- Wireframes - un outil de visualisation pour votre idée
Aujourd'hui, nous nous concentrerons sur la user story et les cas d'utilisation.
Histoire d'utilisateur
L'histoire de l'utilisateur décrit ce que l'utilisateur fait un certain rôle pour atteindre le résultat et ce que le développeur doit faire pour donner vie à cette tâche.
En règle générale, un modèle est utilisé:
En tant que / an <Nom du rôle>, je veux <But, Action>, de sorte que <Résultat attendu>, faire <Ce que le développeur doit faire>Il existe différents exemples d'application de cette méthodologie. Par exemple, voici comment cela
fonctionne dans Trello:
Dans Retail Rocket, nous créons des user stories dans Google Docs à l'aide de tableaux. Cela permet de simplifier le processus de communication entre les différentes équipes, car tout le monde peut laisser des commentaires et donner son avis.
Par exemple, voici à quoi ressemble la tâche de suivi NPS pour une boutique en ligne:
Grâce à une telle visualisation de l'interaction, la tâche de l'utilisateur passe en douceur et logiquement à la tâche des développeurs. Vient ensuite le tour des cas d'utilisation.
Cas d'utilisation
Les cas d'utilisation décrivent le comportement de l'utilisateur étape par étape lors de l'interaction avec un produit développé.
La tâche de l'utilisateur est ce que l'utilisateur fait pour atteindre des objectifs à court terme.
Si l'utilisateur résout le problème sur la page développée de plusieurs manières, chaque solution doit avoir son propre cas d'utilisation écrit. Par exemple, si l'accès aux fonctionnalités concernées se trouve sur plusieurs pages, vous devez écrire un cas d'utilisation distinct pour chaque manière dont l'utilisateur passe à la fonctionnalité.
Regardons un exemple de notre fonctionnalité récemment publiée -
Galerie d'images et de polices pour les envois de masse.
Le but de l' utilisateur est de stocker des images sur notre plateforme et de les utiliser pour créer des campagnes email.
Tâches utilisateur:
- Téléchargez des images
- Intégrer des images dans un modèle de lettre
- Supprimer des images
Pour chaque tâche, vous devez rédiger votre propre cas d'utilisation - une description de la façon dont l'utilisateur interagit avec l'interface.
Exemples de cas d'utilisation:Téléchargement d'image:
- Email Marketer se connecte à votre compte Rocket Retail personnel
- Email Marketer ouvre une section galerie
- Le marketing par e-mail télécharge des images par glisser-déposer ou en cliquant sur le bouton «Sélectionner les fichiers»
- Les images sont téléchargées
- L'utilisateur voit une notification de téléchargement réussi d'images
Supprimer des images:
- L'utilisateur clique sur l'image
- L'image se démarque
- La sélection peut être supprimée en cliquant sur la zone en dehors de l'image sélectionnée.
- L'utilisateur clique sur l'icône des trois points
- Un menu contextuel apparaît.
- L'utilisateur y sélectionne le lien "Supprimer le fichier". Si plusieurs images ont été sélectionnées, toutes seront supprimées.
- L'image est supprimée
Tous les scénarios d'utilisation sont peints de la même manière, ce qui permet au développement de comprendre clairement à quoi ressemble l'interaction de l'utilisateur avec le produit ou les fonctionnalités, et ce qui doit être fait pour cela.
Pourquoi les exigences fonctionnelles sont si importantes
En utilisant ce format d'exigences fonctionnelles, vous fournissez à l'équipe de développement des instructions claires. De plus, vous pouvez montrer à quoi ressemble l'interface du côté client et comment elle résout ses tâches. Cette approche permet de présenter votre idée et d'éviter les malentendus au sein de l'équipe.
En règle générale, la formulation du problème aux développeurs leur pose de nombreuses questions, dont les réponses dépendent de la complexité et du calendrier de mise en œuvre. Pour clarifier les détails, ils doivent consacrer du temps à la communication plutôt qu'à leur travail direct - créer des fonctionnalités intéressantes et améliorer le produit. Et même dans le processus de communication, toutes les subtilités ne sont pas toujours clarifiées si le directeur de tâche ne répond qu'aux questions qui se posent, mais l'utilisateur ne suit pas le chemin lui-même.
Prenons l'exemple de notre galerie. Si le chef de produit venait à l'idée de créer une galerie, sur un point concernant la suppression de fichiers, les développeurs devraient clarifier:
- Dois-je supprimer le fichier?
- Sera-ce une suppression manuelle ou les fichiers les plus anciens seront-ils automatiquement supprimés lorsque de nouveaux seront téléchargés, si la limite de stockage est dépassée?
- est la suppression de la liste des fichiers ou devez-vous ouvrir le fichier?
- le fichier est-il définitivement supprimé ou existe-t-il un panier pour les fichiers où ils sont stockés pendant un certain temps? si vous avez besoin d'un panier, combien de fichiers y sont stockés?
- Doit-il y avoir suppression de fichiers batch ou ne peut-on en supprimer qu'un seul?
- le fichier est supprimé à l'aide d'une icône distincte (à quoi ressemble cette icône?) ou via un élément de menu (comment s'appellera-t-il? où se trouve-t-il dans la liste d'actions?)
- etc.
Et après tout, ce n'est là qu'un des points de la tâche, et il y a déjà tellement de questions. Et découvrir chacun requiert du temps et des efforts des deux côtés.
Les exigences fonctionnelles aident le chef de produit à réfléchir et à formuler clairement tous les scénarios d'interaction utilisateur à partir des interfaces au sein de la tâche.
Plus la tâche est posée avec précision et plus les développeurs ont de détails avant de commencer le travail, plus le travail est efficace. Pas de temps perdu sur une communication longue et parfois dénuée de sens. Dans ce cas, toutes les parties en profitent: les développeurs comprennent clairement quoi et comment faire, et le fournisseur de tâches effectue le travail exactement sous la forme dans laquelle il l'a imaginé.
Et comment abordez-vous la formulation des tâches pour les développeurs?
Directeur de produit Gulfiya Kurmangaleeva