Rassemblement des exigences minimales de faible friction [fermé]

Question

Comment notre équipe peut-elle collecter les exigences de notre " Product Owner " avec le moins de frottement possible, tout en restant utilisable?

Maintenant, voici les directives - Aucun message ne peut être écrit ou que l'entreprise doit prendre une décision qui la soucie de la qualité, yada yada. Le produit pour lequel je travaille est un petit groupe qui réussit depuis des années. Je veux juste les aider à progresser d'un cran.

En gros, je fais partie d’une équipe de 6 ou 7 personnes avec un seul responsable de produit. Elle fait un excellent travail, mais jongle avec quelques rôles différents (comme je le crois commun aux très petites équipes). Habituellement, les besoins sont définis à des moments sporadiques (convos par courrier électronique, discussions en face à face, réunions, etc.). Elles ne sont jamais entrées dans un système, ce qui entraîne parfois l’absence de publication d’une version ou l’obtention de la publication, car tout le monde a oublié la fonctionnalité nécessaire.

Si vous êtes dans une situation similaire mais que vous avez trouvé un moyen de surmonter cela, j'aimerais l'entendre. Je suis heureux d’écrire du code pour aider à atténuer cette situation, mais il ne peut s'agir d'un site Web auquel le responsable du produit doit se rendre pour pouvoir effectuer quoi que ce soit. Elle est extrêmement occupée et nous avons besoin d’un moyen de travailler en équipe afin de répondre à ces besoins.

Je pense actuellement à quelque chose comme ceci: les développeurs et les membres de l'équipe rassemblent les exigences discutées lors de réunions en face à face et écrivent quelques notes rapides sur les fonctionnalités présentées sur une page de wiki. Le propriétaire du produit est averti chaque fois que ces pages sont mises à jour et il incombe alors à elle d’assurer l’exactitude.

Avantages: nous aurons une trace des fonctionnalités. Inconvénients: Les développeurs assument la responsabilité de quelque chose qu'ils ne feraient normalement pas. Je suis d'accord avec ça ici. Je pense que dans cette situation, c'est un travail d'équipe.

Bien sûr, une fois que nous aurons fait cela, nous verrons que le propriétaire du produit n’a probablement pas le temps de garantir la précision des fonctionnalités. En fin de compte, elle est surchargée et je pense que cela contribuera à illustrer ce fait, mais je dois juste être en mesure d’attirer l’attention sur ce fait en premier lieu.

Donc, des suggestions?

P.S. Comme son temps est extrêmement limité, il est jugé déraisonnable de s’attendre à ce qu’elle ait besoin de saisir les exigences après la discussion. Elle n'a que le temps d'en discuter une fois et de passer à autre chose.

Answer 1

Bien que le concept de "propriétaire du produit" C’est un peu ambigu pour moi, je pense que je travaille dans des circonstances très similaires: le client est extrêmement dynamique et constitue toujours un goulot d’étranglement dans le développement des exigences.

En apparence, ce que nous essayons de faire dans cette situation est assez évident et apparemment simple: nous essayons de faire en sorte que le client participe au processus "lecture seule / conversation seulement". mode. Pas d'écriture. Lecture minimum. Parlons surtout.

Le diable, bien sûr, est dans les détails. Alors, voici quelques détails sur notre processus (sans ordre particulier):

• Nous partons souvent de l'enregistrement des déclarations de problèmes , qui constituent la source ultime des exigences. En fait, il arrive parfois que tout ce que nous enregistrons au départ ne contienne qu'un énoncé de problème, histoire de ne pas nous perdre.

  NB: Il est important de distinguer les énoncés de problèmes des exigences. Bien qu'un énoncé de problème implique parfois clairement certaines exigences, en général, un seul énoncé de problème peut engendrer toute une série d'exigences (chacune ayant sa propre gravité et priorité); de plus, parfois, une exigence donnée peut définir une solution (généralement partielle) à plusieurs problèmes.

  L’une des principales raisons d’enregistrer des énoncés de problèmes (, ce qui est tout à fait pertinent pour votre question! ) est que, sémantiquement, elles sont un peu "plus proches de la peau du client". et plus stable que les exigences qui en découlent. Je pense que ces énoncés de problèmes permettent de placer le client dans le contexte approprié plus facilement et plus rapidement chaque fois qu'il a le temps de faire part de ses commentaires à l'équipe de développement.

• Nous enregistrons toutes les exigences (et les suivons dans les déclarations de problèmes) , quel que soit le moment où nous les mettrons en œuvre. Les priorités déterminent l'ordre dans lequel les exigences sont mises en œuvre. Bien entendu, ils régissent également l'ordre dans lequel les clients passent en revue les exigences non terminées.

  Remarque: Un seul et même document contenant toutes les exigences est un no no non absolu! Toutes les exigences sont placées dans la "base de données de suivi des problèmes", avec les rapports de bogues. . (Un bug n’est qu’un cas particulier dans notre livre.)

• Nous essayons toujours de faire de notre mieux pour minimiser le nombre d'itérations nécessaires à la "finalisation". chaque exigence (ou un groupe d'exigences connexes). Idéalement, un client devrait avoir à examiner une exigence une seule fois.

  Chaque fois que la première révision s'avère insuffisante (cela arrive tout le temps) et que l'exigence en question est suffisamment complexe pour nécessiter beaucoup de texte et / ou d'illustrations, nous veillons à ce que le client ne dispose pas pour tout relire de zéro . Tous les changements / ajouts / suppressions importants depuis la version précédente ont été mis en évidence.

  Bien qu'un problème ou une exigence ne soit pas encore terminé, tous les problèmes en suspens (principalement des questions posées au client) sont incorporés dans le document et mis en surbrillance . Par conséquent, chaque fois que le client a le temps d'examiner les exigences, il n'est pas obligé de convoquer une réunion et de solliciter des questions de la part de l'équipe. Au lieu de cela, le client peut ouvrir tout document inachevé en premier, voir ce qu’on attend exactement de lui, puis décider du meilleur moyen et du meilleur moment (pour lui) pour résoudre les problèmes en suspens. Parfois, le client choisit d'écrire un courrier électronique ou d'ajouter un commentaire directement au document qui pose problème.

• Nous faisons de notre mieux pour établir et maintenir le vocabulaire de domaine officiel (même s'il est éparpillé dans la documentation). Plus important encore, nous obligeons pratiquement le client à s'en tenir à ce vocabulaire.

  NB: Il s’agit d’un des aspects les plus difficiles du processus. Le client essaie de "se rebeller". de temps en temps. Cependant, à la fin de la journée, tout le monde convient que c'est le seul moyen de rendre les réunions avec le client les plus précieuses aussi efficaces que possible. Si vous avez déjà assisté à des réunions d’une heure durant lesquelles 30 minutes ont été consacrées à mettre tout le monde sur la même page (encore), je suis sûr que vous apprécieriez disposer d’un vocabulaire.

  NB: Chaque fois que cela est possible, les modifications apportées au vocabulaire officiel sont reflétées dans la toute prochaine version du logiciel.

• Parfois, un problème donné peut être résolu de plusieurs manières, et le bon choix n'est pas évident sans consulter le client. Cela signifie qu'il y aura un " menu d'exigences " pour que le client choisisse . Nous documentons ces "menus", pas seulement l'exigence finalement choisie.

  Cela peut sembler controversé et ressembler à une surcharge inutile. Cependant, cette approche permet de gagner beaucoup de temps chaque fois que le client (généralement quelques semaines ou quelques mois plus tard) se lance soudainement avec une question du type "pourquoi diable l'avons-nous fait de cette façon et non de cette façon?" En outre, il n’est pas si difficile de cacher les "branches rejetées". en utilisant une organisation / un formatage approprié de la documentation des exigences. Ennuyeux mais faisable. : -)

  NB: lors de la préparation de "menus d'exigences", il est très important de ne pas en faire trop. Trop de choix ou de niveaux d'imbrication - et la prochaine révision peut nécessiter beaucoup plus de temps que nécessaire. Inutile de dire que le temps consacré aux branches élaborées peut être totalement perdu. Oui, il est difficile de trouver un équilibre ici (cela dépend énormément de la capacité du client toujours pressé de penser à deux étapes ou plus et de le faire rapidement). Mais que puis-je dire? Si vous voulez vraiment bien faire votre travail, je suis sûr qu'après un certain temps, vous trouverez le bon équilibre. : -)

• Notre client est un très " visuel " gars. Par conséquent, chaque fois que nous abordons des éléments d'interface utilisateur importants, les maquettes d'écran (ou même des prototypes légers) sont souvent extrêmement utiles. Économies de temps réel parfois!

  NB: Nous filtrons les maquettes exclusivement pour le client, uniquement dans le but de faciliter les discussions. Ils peuvent également être utilisés par les développeurs, mais ils ne se substituent en aucun cas aux spécifications de l'interface utilisateur! Plus souvent qu'autrement, certains détails très importants de l'interface utilisateur sont spécifiés par écrit (maintenant - principalement pour les développeurs).

• Nous avons la chance d'avoir un client ayant une formation très technique. Nous n'hésitons donc pas à utiliser les diagrammes UML comme aide à la discussion . Toutes sortes de diagrammes UML, dans la mesure où ils aident le client à entrer rapidement dans le contexte approprié et à y rester.

  Je parle bien sûr des diagrammes UML au niveau des exigences. Pas à propos des implémentations. Je crois que même des personnes peu techniques peuvent commencer à creuser tôt ou tard des diagrammes UML au niveau des exigences; vous devez juste être patient et savoir quoi mettre sur un diagramme.

Évidemment, le coût d’un tel processus dépend en grande partie des capacités d’analyse et de rédaction de l’équipe et, bien entendu, des outils à votre disposition. Et je dois admettre que dans notre cas, ce processus semble être assez coûteux et lent. Mais, compte tenu du très faible taux de bugs et du faible taux de "caractéristiques de la vapeur" ... je pense qu'à long terme, nous obtiendrons un très bon retour sur investissement.

FWIW: Selon la belle classification des produits logiciels de Joel , ce projet est un " interne " un. Nous pouvons donc nous permettre d’être aussi agiles que notre client peut les gérer. : -)

Answer 2

"Les développeurs et les membres de l'équipe rassemblent les exigences discutées lors de réunions en face à face et rédigent quelques notes rapides"

.

Commencez avec ça. Si vous ne prenez pas de notes, apportez une petite modification. Prendre des notes. Plus tard, vous pourrez les poster sur un wiki ou créer un backlog de fonctionnalités ou commencer à utiliser Scrum ou bugzilla ou quelque chose du genre.

D'abord, cependant, faites de petits changements. Notez que cela ressemble à quelque chose que vous ne faites pas, alors faites-le et voyez ce qui s’améliore et ce que vous pouvez faire ensuite. Soyez agile. Travailler progressivement.

Answer 3

Vous voudrez peut-être faire attention au HiPPO dans la pièce. L’avis de la personne la mieux payée n’est pas toujours bon. Nous avons tendance à nous concentrer davantage sur la fourniture d'outils et d'un support de qualité aux développeurs. Ces choses, faites correctement, simplifient énormément le développement, pour que cela devienne plus rapide et plus amusant. Les développeurs sont alors plus flexibles en termes de charge de travail et plus enclins aux changements de dernière minute.

Les tests et le déploiement en un clic sont deux bons exemples pour commencer; Assurez-vous que chaque développeur peut utiliser sa propre pile de logiciels en quelques secondes et essayer directement des idées. Les développeurs sont ensuite en mesure de faire des révisions rapidement ou de parcourir des chemins qu'ils jugent intéressants, et ces chemins sont souvent les plus réussis. Et par succès, je veux dire un succès mesuré basé sur des indicateurs réels rassemblés directement dans le système et mis à la disposition de toutes les personnes concernées. Le propriétaire est ensuite en mesure de définir les métriques, dont il se préoccupe probablement, plutôt que les exigences dont il ne se soucie pas ou qui n’ont aucune expérience de la définition.

Bien sûr, cela dépend du propriétaire et de votre situation particulière, mais nous avons constaté que les métriques sont plus faciles à discuter que les exigences, et que les développeurs sont également très bons pour les interpréter. Un problème typique pourrait être que les clients semblent passer beaucoup de temps à remplir leurs paniers mais ne passent pas à la caisse.

1) Une exigence marketing peut être de rendre le bouton de commande plus gros et plus rouge. 2) L’exigence du PDG peut être d’emmener le client directement à la caisse, car le PDG n’achète jamais qu’un article à la fois. 3) L'exigence du concepteur d'interface utilisateur peut être de placer un deuxième bouton de paiement en haut du panier, ainsi que le bouton existant en bas. 4) Le développeur peut avoir besoin d’un widget Web 2.0 AJAX qui suit le pointeur de la souris sur l’écran. Qui a raison?

Peu importe ... le client a probablement vu le coût ridicule de la livraison et s’est enfui. Mais redéfinissez le problème en tant que métrique, au lieu d'exigence, et soudain le développeur s'intéresse. Le développeur n'a pas à faire 10 tours avec l'OCM sur quelle nuance de rouge le bouton devrait être. Il peut jouer avec son truc Web 2.0 toute la semaine, puis abandonner les 3 autres solutions lundi matin. Chacune est déployée en direct pendant 48 heures et le taux de panier au départ est mesuré et signalé instantanément. Cela ne fait aucune différence, mais le développeur doit faire son travail et l'entreprise se concentre désormais sur les produits médiocres qu'ils vendent et sur le prix qu'ils évaluent à la livraison.

Bien, d'accord, l'exemple est artificiel. Il y a beaucoup de travail à faire pour s'assurer que le projet est petit, que l'équipe est expérimentée, que le déploiement à chaud est simple, que la restauration instantanée est fournie et que tout le monde est de la partie. Ce que nous voulions atteindre, c’est un état dans lequel le potentiel du développeur n’est pas gaspillé. C’est pourquoi ils sont impliqués non seulement au début, mais aussi au succès. Commencez par un problème comme le nombre de clics lors de l'enregistrement est trop élevé, passez-le par un comité de conception et nous avons constaté que le nombre de clics avait en fait augmenté dans les spécifications de conception. C'était notre expérience quand même. Mais laissez au développeur une certaine liberté pour réduire le nombre de clics et vous pourriez vous retrouver avec une solution brevetée, comme nous l'avons fait. Ce n’est pas que le développeur se soucie des brevets, mais c’était un mérite - et pas de clics!