Communiquer efficacement avec son équipe de développement

Hello les entrepreneurs !

J’ai un souci assez récurrent et je recherche des idées pour résoudre.

Souvent, j’ai une idée que je veux faire développer sur un site (nouvelle fonction ou site complet peu importe) et personnellement je me fais une certaine idée de la manière dont cela doit fonctionner.

Mon équipe de développement elle interprète mon idée sur la base d’un mockup et de documents de spécifications, mais bien souvent le résultat qui m’est présenté peut être assez éloigné de l’idée que je m’en était faite (nous sommes pourtant en méthodes Agiles, itérations courtes mais cela n’aide pas sur ce problème).

Résultat: perte de temps pour tout le monde le temps de procéder aux ajustements.

Avez-vous des solutions concrètes pour aider à résoudre ce problème ?

Hello,

C’est étonnant de ne pas avoir de bon résultats en suivant les méthodes agiles. Est-ce que vous poussez les choses jusqu’au bout ? quelle méthode agile suivez vous, scrum ? Le fait de dire « je leur donne les specs » ne me fait pas penser à de l’agilité, surtout pour des projets comme des sites internet.

Bonjour,
quand tu dis "sur la base d’un mockup et de spécifications. Qui rédige ces deux documents? impliques-tu un webdesigner et un développeur dans la mise au point de ces document? Peut-être une démarche plus proche du design thinking te serait utile.

Bonjour @toopixel,

Je m’y connait pas côté « technique » mais je pense qu’il y a un problème de « diapason-fil directeur ».

Quand tu « te fais une certaine idée de la manière dont cela doit fonctionner », le retranscris-tu pour le communiquer à ton équipe ?

Organises-tu des réunions « synergiques »? Ou réfléchis tu seul ?
Ton équipe ne réfléchis pas comme toi, et toi tu ne réfléchis pas comme ton équipe, non ? A mon avis, tu réfléchis trop, et trop vite pour eux…

Pour être en « phase », tu peux faire un document écrit de chaque parcelle de ta réflexion (et pour chaque opération) et en parler pausément (si, si, j’insiste!).

Avoir une feuille de route ::

  • préparée et réfléchie pour toi (pour qu’aucun détail ne manque à l’appel),
  • clairement édifiée et « conservable » pour ton équipe
    peut contrecarrer de possibles interprétations/malentendus. En essayant de se limiter à ce qui a été dit et réfléchi, car revenir « 100 fois » sur qq chose, remet en cause qq chose !..

« Plus d’excuses possibles … En avant, marche ! » :wink:

1 « J'aime »

Utiliser les users stories ça aide dans e cas là

c’est simple et sans ambiguïtés, tu couvres TOUS les aspects de ta fonctionnalité:

En tant que
Je veux
Pour

ex:
En tant que Client
Je veux être notifié par mail
pour avoir un suivi de commande

Tu prends le temps avec tes dev d’aller partout dans ta fonctionnalité, éventuellement tu crées des personas, ou profil, des utilisateurs imaginaires qui représente les différents types et tu les met en scène.
Si tous les cas de figure sont passés au crible, il n’y a plus de place pour l’interprétation.

Si par contre ton soucis, c’est que dans ta tête tu as une liste déroulante, et que tes dev mettent une barre avec des onglets, le soucis vient d’ailleurs, et tu dois te positionner autrement par rapport à eux.

3 « J'aime »

J’aime bien la réponse de @NicolasKaizen , c’est également ce que j’entendais par Design Thinking. Bref quand je fais un brief, je pars de deux principes de base: 1) mes presta sont pas dans ma tête donc j’explique tout
2) mes presta sont des spécialistes et je dois leur laisser de la place pour exprimer leurs compétences et expertise donc je demande des fonctions, des arrangements mais je laisse une marge clairement définie.

Tu n’es plus intervenu @toopixel , ça serait bien d’avoir ton retour sur toutes nos participations.

2 « J'aime »

Voilà ce que j’essaye :

Narrative:

  • As a [role]
  • I want [feature]
  • So that [benefit]

Acceptance Criteria:

Scenario 1: Title (only what differs)

  • Given [context]
    • And [some more context]…
  • When [event]
  • Then
    • [outcome]
    • And [another outcome]

Scenario 2: …

1 « J'aime »

Alors quand je parlais de specs, effectivement je me suis mal exprimé j’aurais plutôt du dire brief car nous sommes bien en méthodes agiles (Kanban pour nous).

En fait ce qui pose problème c’est exactement ce que @NicolasKaizen, à savoir que moi j’imagine une liste déroulante et que mon développeur me sort des checkboxes (malgré la petite story qui décrit ce que l’utilisateur peut faire). Donc sur 1-2 fonctions c’est ok on fait une itération et c’est réglé, sur l’ensemble du projet cela commence à peser lourd en temps et pour exemple on devait lancer un projet le 1er juillet et ca ne sera jamais prêt avec le 1er aout.

Je suis donc très intéressé par vos conseils, et notamment vous avez tous raison, je vais impliquer plus les codeurs avec le designer, à l’inverse le designer s’impliquera davantage lors du développement, et on va clairement adopter le Design Thinking que j’avais vu passer sans m’y attarder mais après 2 projets ou le problème se répète cette fois je vais prendre la méthode plus au sérieux.

Donc merci à tous vraiment vous m’avez aidé là :sunny:

@Will désolé pour le manque de réactivité mais je vit à 300 km/h en ce moment donc pas trop le temps pour répondre la journée :frowning:

1 « J'aime »

@toopixel : Pour moi, c’est simple : je fais des Powerpoint montrant exactement ce que j’attends. Ça peut sembler rustique/amateur, mais c’est un très bon support de travail. Avec un peu d’habitude, n’importe qui peut faire un rendu rapide et fidèle à son idée. C’est très facile à modifier, très souple. Et quand on s’est mis d’accord dessus, ça devient une sorte de « cahier des charges » visuel.

1 « J'aime »

Etant développeur, je vois bien le problème:

Tu n’a pas fait un mockup. Un mockup comme ça:

Ps: normalement il ya les commentaires mais ils ne sont pas visibles dans cette version

Tu veux une liste déroulante, tu fais un mockup avec une liste déroulante.
Tu veux une liste déroulante à droite d’un texte bleue, tu fais un mockup avec une liste déroulante à droite d’un texte bleue.
Là ya pas d’embrouille. Ya pas d’interprétation. Ya un mockup complet.

Si tu me dis: à coté du texte j’veux une liste pour le choix.
Tu auras un texte quelque part et dans ses environs proches un choix multiple.

Pour le rendu, il faut des documents explicites qui indiquent exactement ce qui doit être visible et où.

Ps: j’ai fait ce mockup avec Balsamiq

3 « J'aime »

@Steph bon il y a quand même mieux que du PPT pour le web, un tool de mockup me semble plus approprié, ceci dit c’est un choix perso de ses outils ensuite, si ca marche pour toi :smiley:

@sgendrot si bien sûr, nous on utilise Mockflow, mais bon sur une grosse app dans mon cas par exemple on a une 30aines de mockups, malgré tout on ne pas pas tout anticiper et pas mal de fonctions arrivent durant le développement, il y a aussi le choix du développeur lui même face à un mockup qui n’est pas à mon sens la référence obligatoire à suivre si lui estime que c’est mieux ainsi.

Bon on a pris l’exemple de drop down, mais ceci dit les problèmes que je rencontre sont quand même un peu plus profonds que ca, dans mon cas pour donner un exemple concret, on a dans le backlog une story qui n’était pas assez détaillé concernant une boite login, moi j’avais imaginé au design qu’elle viendrait comme une modal box, le développeur lui a imaginé d’après le mockup que ca sera une page à part, résultat: 2 heures de perdu pour rien. Quand tu accumule les petites incompréhensions sur un dev de 6 mois ca pèse en fin de projet et on se ramasse 1 mois de retard, c’est ca que j’essaye de résoudre.

1 « J'aime »
  • Si le développeur front est calé en UX, il choisira le plus adapté à la fonction concernée. (d’où l’intérêt de la méthode agile, décentraliser les décisions.)
  • Si l’auteur du brief sait exactement ce qu’il veut, il doit être explicite.
  • Si le choix dépend d’une logique transversale propre au produit en cours de développement, il faut fournir un guide au développeur. (même principe qu’une charte graphique)

Un client (interne ou externe) n’a aucune légitimité à attendre qu’on lise dans ses pensées ! C’est « déloyal » vis à vis du travailleur en face.

En théorie ce n’est pas une perte de temps car le retour apporte des informations utiles et la deuxième version va plus vite.
Ce n’est une perte de temps que si on savait quoi faire avant (comment ?). Le problème serait alors un manque de spec (voir ci-dessus).

Une voie à explorer : être encore plus agile = raccourcir encore les itérations, livrer encore plus souvent.

« D’expérience, quelques heures de code suffisent à produire un lot viable qu’il vaut la peine de valider et déployer. »
Eric Ries

2 « J'aime »

Exemple de critères pour une story très petite avec le format proposé plus haut :

  • Soit un visiteur non connecté sur la page d’accueil
  • Quand il clique sur le BOUTON « Log In »
  • Alors
  1. un formulaire s’ouvre dans une modale
  2. Et le visiteur peut saisir ses données d’identification

Il faut un deuxième scénario pour le log proprement dit.

Qu’en pensent les experts par ici ?

Vaut il mieux :

  • une story plus grosse et moins précisé « se logger » + un mockup directif ?
  • une story « se logger » avec une « longue » liste de critères, dont la modale
  • une story « voir le formulaire de login dans une modale » ci dessus + une story s’identifier ?

@funkybranding explique très bien le problème:

Tout techos est confronté à cette blague durant tout sa vie.

Si les specs sont une option, moi je fais ce que je veux.

Toi pas lui.

Les méthodes agiles c’est pas un truc magique.

Si tes specs sont incomplètes ou facultatives, tu perdras du temps après à corriger ce qui a été fait.
Si tes specs sont complètes et obligatoires, tu perdras du temps avant à rédiger tes specs.

1 « J'aime »

j’ai l’impression, le sentiment que ton problème ne vient pas de la méthode mais de ton positionnement dans l’équipe.

Si tu imagines l’UX, es-tu UX designer ? Dans l’équipe j’entends, pas dans les compétences.

Es-tu product owner au sens agile ?

Soit tu fais confiance à tes dev, et ils font ce qui leur parait ok, soit tu as un ux avec qui tu décides l’UX et qui le porte ensuite aux équipe de dev, ou dans la même réunion, mais que le designer fasse le design, même si toi avant (ou pendant) tu diriges.

J’ai l’impression que ton positionnement n’est pas bien définis, et que la latitude de tes équipes non plus.

Vos méthodes ont l’air ok, alors pourquoi ça coince ? :smile:

1 « J'aime »

@toopixel
J’ai jamais eu l’occasion d’essayer un tool de mockup, quels sont les avantages par rapport à un ppt ?
Et tu me conseillerais quoi ? Balsamiq, comme @sgendrot ?

Merci pour toutes ces réponses constructives @plarcher et à tous les autres, je vais me pencher sur tout ca et remettre en question une partie de nos processus actuels.

Les avantages sont d’abord collaboratifs à mon sens. Ensuite c’est un tool dédié à de l’application web ou mobile, donc tu dispose de tous les sets d’outils dédiés à cela. Cela permet aussi de faire rapidement du prototyping exporté en HTML clickable et interactif pour montrer à un client ou une personne comment ca va fonctionner.

Nous on a choisi MockFlow, j’avais testé Balsamiq mais n’ai pas trop aimé, ensuite des tools de mockup il y en a vraiment beaucoup, des très chers, des moins chers, au final nous on a accroché sur MockFlow, je pense que ca relève plus du choix personnel.

1 « J'aime »

Si si je te rassure c’est parfaitement défini, simplement quand le résultat ne me conviens pas en tant que product owner, ou que lors de tests utilisateurs on se rend compte que quelque chose coince bien que j’ai fait confiance à l’équipe qui a fait un autre choix que celui que j’avais moi en tête alors ca nous amène a des corrections donc des pertes de temps.

Ce qui ressort pour moi de toutes ces discussions de toutes façons c’est plutôt l’implication des devs directement dans la conceptualisation du projet, et aussi de manière plus rapprochée avec le designer. Donc pour moi la conclusion que j’en tire ici c’est que nous allons améliorer ce point, et adopter le Design Thinking comme philosophie de fond :sunny:

Merci tous en tout cas, cela m’a beaucoup aidé !

Soit l’expérience montre que tu avais raison 90% du temps et en effet il faut soit être plus directif, soit transformer en process (design thinking ?) tes intuitions qui font mouches à 90%.

Soit c’est 50/50 et alors il ne s’agit pas de perte de temps mais d’un process normal hypothèse>test>action !
Si les corrections sont trop lourdes, c’est que les lots sont peut-être trop gros ?

Et c’est surement un mix des deux…

1 « J'aime »