Le dilemme des coups de feu

Question

Voici une citation d'un entretien avec un chef de produit (PM) exprimant sa préoccupation concernant les pratiques UX dans leur entreprise:

une chose qui a toujours échoué est que nous n'avons pas défini qui a le dernier mot, qui peut réellement décider quoi faire et comment.

Un propriétaire de produit (PO) a également exprimé sa préoccupation concernant les pratiques UX:

Ce sont les propriétaires de produits qui travaillent avec les équipes et, en fait, dans une certaine mesure, conçoivent le fonctionnement du système. Les bons de commande sont le client ou le mandataire du client (c'est-à-dire l'acheteur). Ce sont eux qui ont le pouvoir de décision sur la façon dont les choses devraient ressembler ... lorsque les pratiques UX affectent la portée, alors c'est certainement l'OP qui devrait décider.

Cependant, dans la plupart des cas, ces propriétaires ou chefs de produit n'ont pas nécessairement une connaissance suffisante de l'UX, et l'UX n'est pas leur principale préoccupation. Souvent, ce que ces rôles privilégient, c'est la livraison à temps et dans les limites du budget et assurer la satisfaction des `` clients '' (c'est-à-dire des acheteurs) qui, dans le cas d'un logiciel qui n'est PAS axé sur le marché, conduit souvent à négliger dans une large mesure la vision des utilisateurs finaux. Ceci est démontré par un PO disant:

nous avons un composant de table qui a un comportement vraiment mauvais, et nous sommes tous d'accord sur cela, mais nous savons que si nous devons le changer, c'est un énorme travail ... Nous avons fait quelques corrections, afin que vous puissiez vivre avec, ce n'est toujours pas sympa mais vous pouvez travailler avec. Voilà comment cela doit être en ce moment.

Mes questions s'adressent à ceux d'entre vous, experts UX, qui travaillent dans des environnements agiles. Je suis intéressé de savoir:

1. dans les projets agiles auxquels vous avez participé, comment collaborez-vous avec les chefs de produit et (le cas échéant) les chefs de produit? Quels outils et méthodes utilisez-vous?

2. Qui appelle les coups de feu quand il s'agit de décisions qui influencent l'UX du logiciel? par exemple l'apparence, le flux, et même quelles fonctionnalités mettre en œuvre, et quelles fonctionnalités à privilégier à chaque sprint? (n'hésitez pas à ajouter d'autres exemples de décisions qui devraient être prises qui influencent l'UX, aussi si vous utilisez des outils spécifiques pour la priorisation, j'aimerais en entendre parler)

   Je sais que la "collaboration" est la clé! Mais ici, je cherche une réponse plus "tangible", "concrète". J'apprécie donc si vous écrivez sur les outils et les méthodes, les mesures, les preuves, etc. plutôt que sur des concepts abstraits tels que "nous collaborons". Il serait également très utile de partager des "histoires spécifiques" sur vos expériences (comme les citations ci-dessus) et comment vous les avez traitées.

Answer 1

Ceci est une excellente question. J'ai vu des processus de décision échouer dans les grandes entreprises (par exemple, les équipes immobilisées par consensus chez Google) et les petites entreprises (par exemple, les décisions des fondateurs axées sur l'ego dans les startups).

Malheureusement, la plupart des programmes de formation d'entreprise proposés sont conçus pour aider les équipes UX et de développement avec des compétences et des ressources verticales, mais très peu de programmes d'entreprise couvrent comment conduire un travail d'équipe efficace et prendre des décisions d'équipe efficaces .

Les frameworks Agile/Lean ne traitent pas cela directement non plus.

Voici une pile d'actions complémentaires qui peuvent aider à conduire une bonne prise de décision:

1. Établir un leadership décisionnel

La collaboration n'est pas un consensus! Un travail d'équipe efficace ne signifie pas qu'il n'y a pas de leader, ou personne avec un droit de veto.

• Les bons PDG comprennent que le travail en équipe de direction est crucial pour le leadership d'entreprise (aucun PDG ne peut à lui seul diriger une entreprise substantielle), mais ils comprennent également qu'ils peuvent en fin de compte donner le coup d'envoi dans des situations où le consensus est trop difficile, lent ou coûteux à conduire.
• Il en va de même pour les équipes produit: n travail d'équipe serré ne signifie pas qu'il n'y a pas de leader.
• Il est préférable d'avoir un seul chef d'équipe qui a le pouvoir d'appeler, mais qui porte également la responsabilité ultime du produit (avec le pouvoir vient la responsabilité!).
  • Je suis personnellement un fan du chef de produit étant l'autorité de décision ultime au sein d'une équipe de produit (pour conduire le meilleur alignement commercial), avec une escalade supplémentaire en dehors de l'équipe jusqu'au PDG. Mais dans de nombreuses entreprises, il peut être judicieux que d'autres rôles dirigent selon la situation.

2. Établir des rôles de spécialistes clairs

• Un développeur est beaucoup plus susceptible de prendre une bonne décision sur les problèmes liés au code qu'un graphiste. Un professionnel UX est beaucoup plus susceptible de prendre une bonne décision d'utilisation qu'un chef de produit. Un bon travail d'équipe doit donc reconnaître et intégrer la spécialisation dans la prise de décision.
• Les équipes SEAL ont une structure de peloton qui a un bureau en charge (OCI) global mais aussi des spécialistes (tireur d'élite, pirate, communicateur, etc.) qui ont beaucoup plus d'expertise dans leur domaine professionnel. La prise de décision repose en fin de compte sur l'OCI, mais doit intégrer l'expertise professionnelle de spécialistes ayant le poids approprié.
  • Par exemple, ce serait une idiotie pour un OIC d'ignorer les conseils d'un spécialiste des intrus lors de la planification d'une mission de violation. Le OIC pourrait prendre la décision d'incorporer l'avis du contrevenant, ou peut déléguer complètement la décision au contrevenant.

3. Utiliser les données

• tilisation précoce, cohérente et habituelle des données aide les équipes à prendre les bonnes décisions en toute connaissance de cause. Cela contribue également à favoriser une culture de l'objectivité et de la méritocratie dans le travail d'équipe, car les décisions ne sont pas prises en fonction de l'ancienneté, du favoritisme ou du caprice du leadership, mais plutôt sur des faits concrets ou statistiques lorsqu'ils sont disponibles.

• L'utilisation des données signifie également établir la pratique de la collecte, de l'analyse et de la présentation des données dans le cadre de la prise de décision en équipe.

• Utiliser les données signifie également engager des parties appropriées ou des ressources informationnelles en dehors de l'équipe (voix du client, PDG, consultants, universitaires, etc.) comme nécessaire.

4. Établir une culture et des principes clairs et cohérents pour le travail d'équipe

• Des principes clairs tels que l'analyse basée sur les données, des domaines de spécialisation clairs, un pouvoir décisionnel, un débat/dialectique rationnel collaboratif, etc. clarifient les rôles et les processus de décision.

• Une culture cohérente et axée sur les principes contribue à fournir un environnement stable et fiable pour le travail d'équipe, ce qui réduit les frictions dans l'exécution et la prise de décision.

• Il est important que les principes du travail d'équipe soient également reconnus par l'organisation en dehors de l'équipe . Par exemple, si une équipe a un leader, ce leader doit en fait être autorisé à tirer au coup par le reste de l'organisation, sinon le travail d'équipe peut s'effondrer une fois que l'équipe se rend compte qu'un leader n'est pas habilité.

Answer 2

Il s'agit d'une question très large, pour laquelle cette longue réponse n'est que la pointe de l'iceberg.

Diviser et conquérir

une chose qui a toujours échoué est que nous n'avons pas défini qui a le dernier mot, qui peut réellement décider quoi faire et comment.

La réponse agile à cela est que tout le monde décide ensemble. Mais cela échoue souvent misérablement pour les raisons suivantes:

Il y a trop de tout le monde et de tout. En d'autres termes, le processus de décision implique trop de personnes, avec des enjeux et des souhaits très divers, avec trop de choses de nature très diverse pour se décider.

Pour donner un exemple, vous vous asseyez dans une réunion de chef d'équipe et devez choisir l'un des deux: une amélioration UX demandée par de nombreux utilisateurs depuis 6 mois maintenant, par rapport à une nouvelle fonctionnalité que le PDG veut développer car elle peut ajouter revenu. Qui a la priorité? Eh bien, c'est comme comparer des pommes à des bananes. La première est centrée sur le client , la seconde est la croissance .

C'est un problème parfois appelé priorisation croisée - lorsque vous essayez de décider de la priorité entre deux choses qui sont clairement peu liées.

Considérons maintenant la question suivante: Est-il préférable pour un pays d'avoir 1 500 lits supplémentaires dans les hôpitaux, ou que l'armée dispose 2 autres drones ? Demandez au Premier ministre et il vous dira: je ne perds pas mon temps à faire de telles comparaisons, nous définissons le budget de la santé et de la défense et chaque ministère fait ce qu'il juge approprié.

Je suppose que la solution devient claire dans le dernier exemple - en utilisant l'approche diviser pour mieux régner , les décisions sont plus faciles et la haute direction doit principalement se préoccuper de la façon dont pour couper le gâteau.

Voici un exemple pratique du monde réel:

• Le mauvais - Dans une certaine structure organisationnelle, j'étais une fois assis dans des réunions de gestion de produits et je devais me battre pour que tout problème UX soit réglé, mais à peine tout a été fait à cause de nombreuses autres forces qui pensaient qu'il y avait de meilleures choses à faire.
• Le bon - Ensuite, nous avons changé le système pour que UX soit un projet agile à part entière - moi-même en tant que concepteur et deux autres développeurs. Cette petite équipe (avec le bon de commande, quand il pouvait le faire) décidait ensemble de ce qui était le plus important. Le résultat? L'UX s'est améliorée beaucoup plus rapidement, les utilisateurs étaient satisfaits, même le PDG était satisfait des commentaires positifs.

De plus, le PO devait maintenant nous guider uniquement sur les problèmes UX, donc il n'était pas partagé entre UX, les nouvelles fonctionnalités, les corrections de bugs, etc.

Agile comme un prêteur

Souvent, ce que ces rôles privilégient est la livraison à temps et dans les limites du budget

L'agilité est une excellente méthode, mais la réalité est que de nombreuses organisations (sinon la plupart) ne suivent que les bits qu'elles aiment à ce sujet et éliminent les bits qu'elles ne préfèrent pas. L'expérience personnelle et la recherche le démontrent. En fait, je n'ai personnellement rencontré qu'une seule équipe qui suit agile par Word et maximise son potentiel et c'est Google's Angular team .

Les autres l'utilisent de manière trop souvent `` achetez maintenant payez plus tard '' - compromettant la recherche, la conception (UX et logiciels), les tests, l'assurance qualité, la qualité du code uniquement pour des raisons de temps de mise sur le marché.

Heureusement, je crois que la prise de conscience de cet échec systématique se développe - trop de startups se retrouvent 4 ans plus tard à courir après les bogues et avec des temps de développement non compétitifs. La Parole se propage, de bas en haut.

Les propriétaires de produits sont bons pour vous

Ce sont les propriétaires de produits qui travaillent avec les équipes et, en fait, dans une certaine mesure, conçoivent le fonctionnement du système. Les bons de commande sont le client ou le mandataire du client (c'est-à-dire l'acheteur). Ce sont eux qui ont le pouvoir de décision sur la façon dont les choses devraient ressembler ... lorsque les pratiques UX affectent la portée, alors c'est certainement l'OP qui devrait décider.

Je suis totalement d'accord sur ce qu'il faut faire ensuite. Mon expérience avec les PO a toujours été positive - en fin de compte, ils connaissent et souhaitent le meilleur pour les vrais utilisateurs. En fait, ma vie a été beaucoup plus facile car il y avait ce véritable utilisateur avec une vaste connaissance du domaine et d'autres utilisateurs qui pouvaient nous guider là où la valeur est au lieu de nous le supposer.

Attitudes défaitistes et coût du retard

nous avons un composant de table qui a un comportement vraiment mauvais, et nous sommes tous d'accord sur cela, mais nous savons que si nous devons le changer, c'est un énorme travail ... Nous avons fait quelques corrections, afin que vous puissiez vivre avec, ce n'est toujours pas sympa mais vous pouvez travailler avec. Voilà comment cela doit être en ce moment.

Eh bien, cela pourrait bien être un argument valable. Si le coût de développement est élevé par rapport à la valeur ajoutée, il est parfaitement normal que l'OP choisisse une autre tâche avec un meilleur ratio.

Mais je soupçonne que cette déclaration sent que la dette technique est derrière, auquel cas c'est comme si vous veniez chez le médecin pour vous plaindre de divers symptômes étranges et le médecin dit: "Vous mangez malsain, vous ne faites pas d'exercice, vous buvez de l'alcool tous les jour, vous fumez 40 cigarettes par jour, votre taux de cholestérol est élevé, votre sucre est élevé, vous devriez vraiment changer votre alimentation et votre style de vie! " et vous allez "Nah ... trop d'effort".

Un autre concept qui peut me venir à l'esprit ici est le coût du retard comme le soutient en détail Reinertsen (Un livre, vous pouvez souhaiter lire, mais ne pas être considéré comme biblique). En termes simples, beaucoup prennent des décisions en fonction des coûts de développement par rapport à une valeur client rationnelle. Mais d'abord, les clients ne sont pas rationnels (en particulier avec UX où les émotions sont difficiles à quantifier); plus important encore - il s'agit de ce que vous perdez pendant la durée de vie du produit que vous devez comparer au coût de développement. Donc, si vous n'allez pas le réparer dans les 5 prochaines années, le coût d'avoir un mauvais composant de table serait-il toujours inférieur au coût de développement pour l'améliorer?

Skunkworks

Les entreprises ont du mal à changer les processus internes et les vieilles habitudes.

Une solution consiste à introduire un rôle, ou une équipe, dont la seule responsabilité est d'assurer la qualité et d'améliorer les choses. Par définition, cette entité est autonome et complètement inconsciente de toute contrainte de temps/budget. Cette pratique s'est avérée extrêmement bénéfique pour certaines entreprises.

Le concept clé ici est l'autonomie . Maintenant, alors qu'un tel concept peut sembler un peu extrême (en particulier dans les petites entreprises), une variante de celui-ci est au lieu d'avoir une entité autonome, que les individus ou les équipes obtiennent un degré d'autonomie. Selon la rumeur, Google permet aux employés de consacrer 10% de leur temps à tout ce qu'ils souhaitent, tant que le travail est en quelque sorte lié à ses produits. Le concept de cellules de travail qui bénéficient d'une certaine autonomie est également assez courant.

Donc, par rapport à votre question - parfois, des individus ou de petites équipes ayant le droit d'appeler les tirs de manière autonome sont très bénéfiques.

Answer 3

Il y a 2 excellentes réponses de @tohster et @Izhaki.

Je suis dans une situation similaire, dans une équipe embarquant avec SCRUM avec un produit SaSS où les personnes qui ont acheté le logiciel ne sont pas les principaux utilisateurs. Je veux donc simplement ajouter mes expériences sur les choses que j'ai trouvées qui ont fonctionné.

Relier l'UX aux dollars

Dans le domaine SaSS (Software as A Service), le taux de désabonnement des clients est un sujet brûlant. L'un des entretiens de cette année Pulse Conference suggère que la principale cause de désabonnement des clients est la convivialité du produit. Et votre équipe d'assistance ou de rétention ne peut rien faire pour garder les clients si le produit fait défaut. Cela peut être quelque chose que vous pouvez exploiter pour accéder à plus de ressources pour UX. Combien de revenus sont perdus en raison du taux de désabonnement des clients. Combien d'argent récupérerez-vous si vous réduisez le taux de désabonnement de seulement 1%? Combien de revenus futurs gagnerez-vous si le client renouvelle son abonnement année après année?

C'est "mauvais" ... mais à quel point est-ce "mauvais"?

Sur le sujet de l'expérience utilisateur, la gestion et parfois les bons de commande n'ont aucune idée de la gravité d'un problème, car ils n'ont pas interagi directement avec les utilisateurs réels. Ils peuvent dire, oui, ce n'est pas idéal, mais c'est toujours utilisable alors qu'en réalité ce n'est pas le cas. Pas lorsque l'utilisateur passe la majeure partie de sa journée dans cette partie de l'application qui passe par le flux non pas une fois, mais à plusieurs reprises plus de 30 fois par jour.

Alors, apportez-leur cette perspective. Ce sera agréable s'ils peuvent s'asseoir sur une session de convivialité. Sinon, vous pouvez leur montrer des enregistrements de sessions. Du coup, ce n'est plus un problème abstrait. Ce sont les gens qui sont touchés. J'ai trouvé que le PO de mon équipe est devenu beaucoup plus réactif aux préoccupations UX après avoir fait quelques observations d'utilisateurs et assisté à des sessions d'utilisation.

La dette produit et technique tuera lentement le produit

Le bon de commande a été présenté au livre de Marty Cagan " Inspiré: comment créer des produits que les clients adorent " et a ensuite participé à un atelier sur le sujet. Cagan est un énorme partisan de la répartition du temps pour la dette technique et de produit/UX. À l'époque, il était chef de produit pour Netscape et a directement attribué la mort du navigateur Netscape à Tech Debt. Lorsque vous empilez de nouvelles fonctionnalités après une autre, le code et le flux de travail deviennent incohérents ... au point où vous ne pouvez littéralement pas ajouter de nouvelles fonctionnalités ou le système est si compliqué que l'utilisateur ne pourrait pas trouver la fonctionnalité, laissez utilisez-le.

Alors maintenant, le PO comprend cela et notre équipe consacre 1 sprint sur 5 pour la dette Tech & UX. Je pense que cela aide beaucoup les OP d'entendre des histoires d'anciens combattants qui sont liées à la jonglerie des gains à court et à long terme. Les concepts collent bien mieux quand ils l'entendent de la part de personnes dans leur domaine, contrairement à ce qu'ils viennent de l'UX ou du Dev qui peuvent leur sembler trop axés sur l'UX ou le Dev.

Négociation au sein d'équipes interfonctionnelles

Dans Scrum, le PO agit comme le seul cou pouvant être essoré. Et donc oui, techniquement, le bon de commande est celui qui a le dernier mot sur ce qui entre dans le backlog de produit et la priorité des articles.

Cependant, il y a beaucoup de négociations impliquées pour déterminer ce qui va dans l'arriéré. Pour notre équipe, lors de la séance de toilettage, UX s'assoit avec PO, Dev Lead et QA pour discuter des travaux potentiels à venir. Nous passons en revue les exigences et l'interface utilisateur et faisons un pointage approximatif. Parfois, je ferai apparaître des éléments UX à examiner et le responsable du développement fera de même avec les éléments techniques.

Souvent, le temps pour ces sessions, je passe un peu plus d'efforts pour trouver diverses options pour l'amélioration de l'expérience utilisateur: le meilleur scénario, le démantèlement et le scénario "acceptable". De cette façon, cela devient un "travaillons ensemble pour choisir la meilleure option compte tenu de nos contraintes de temps et de ressources" au lieu d'une chose "tout ou rien". C'est un peu une astuce psychologique où les gens sont plus susceptibles de choisir un terrain apparemment intermédiaire, mais vous avez mis en place des options pour biaiser les choses en votre faveur.

Est-ce un produit qui tue?

Cela a été évoqué par un orateur lors de la conférence Lean UX NYC de cette année. Comment savez-vous quoi corriger en premier. Demandez combien de personnes ce problème d'utilisation affecte, quel est l'impact sur ces utilisateurs et ce qui se passera si rien n'est fait à ce sujet. Semble être un bon moyen de proposer des statistiques à l'appui des améliorations. Le fait d'avoir le contexte complet montrera également le bon de commande que vous avez fait vos recherches et peut les aider à hiérarchiser cela par rapport à tout ce qui devrait aller dans l'arriéré.

Answer 4

dans les projets agiles auxquels vous avez participé, comment collaborez-vous avec les chefs de produit et (le cas échéant) les chefs de produit? Quels outils et méthodes utilisez-vous?

Les outils et méthodes que j'ai utilisés sont les suivants:

• parlant
• esquisse
• bâtiment
• montrant

En d'autres termes, ils font partie de l'équipe Agile. Ainsi, comme tout le monde dans l'équipe Agile, ils font simplement partie du processus entier et sont prêts pour le trajet.

Qui appelle les coups de feu quand il s'agit de décisions qui influencent l'UX du logiciel?

Toutes les personnes. Voilà l'esprit d'Agile. Il n'est pas "détenu" par une seule entité. Il n'y a pas de processus unique de "signature". L'équipe travaille ensemble. Et peut-être que la mauvaise chose sort par la porte. Cela fait également partie du processus. Apprenez ce qui ne va pas, corrigez-le dans le prochain sprint.

Dans Agile (et même en dehors d'Agile, mais surtout dans Agile), l'équipe UX n'est pas celle qui appelle les coups. Ce sont eux qui facilitent la conception. Ils contribuent à la conception, bien sûr, mais leur travail consiste principalement à amener tout le monde à contribuer au processus de conception.

Si une organisation est aux prises avec "qui a le dernier mot", alors c'est une organisation qui est encore vraiment aux prises avec Agile. Ils s'accrochent à un vieux modèle "Cover-yer-ass" de cascade. Les signatures sont un goulot d'étranglement en Agile en général.

S'il y a un fort besoin d'approbations dans l'organisation, c'est généralement le signe d'une priorité de la politique d'entreprise sur le produit lui-même. Ce n'est certainement pas rare. Mais frustrant, c'est sûr.