Le dilemme du singe codant
Ceci est une citation d'un entretien avec un praticien ayant une formation technique et un rôle:
Les développeurs sont tous des gens intelligents; ils n'aiment pas leur travail si quelqu'un leur dit que c'est ce que vous devez faire et que vous allez le faire. Personne ne veut se sentir comme un singe codeur.
J'appelle cela "le dilemme du singe codeur". Je suis sûr que beaucoup d'entre vous qui travaillent avec UX ont connu des situations similaires dans lesquelles le rôle d'une personne UX, d'un concepteur d'interaction ou similaire est quelque peu considéré comme une `` menace '' pour la satisfaction professionnelle des développeurs. Je suis d'accord que l'introduction de nouvelles compétences telles que l'expérience utilisateur signifie une répartition des responsabilités et une perte de pouvoir dans certains domaines pour d'autres rôles.
Ma question est quelles approches (processus, outils, méthodes, etc.) utilisez-vous dans votre travail en tant qu'expert UX, concepteur d'interaction ou similaire pour surmonter le `` dilemme du singe de codage ''?
J'aimerais également en savoir plus à ce sujet si vous connaissez des références.
Utilisez le dialogue, pas la direction,
Utilisez des conversations, pas de coercition
Les singes de code sont un symptôme d'un processus de conception et de développement moche qui met l'accent sur la direction/gestion par rapport au dialogue/collaboration.
Il existe de nombreux noms pour ce type de processus (cascade, linéaire, directive, etc.) mais au cœur de celui-ci, le syndrome du singe de code sort d'un modèle de conception/développement où les développeurs sont considérés comme ressources à diriger plutôt que partenaires dans un processus :
L'approche directive est faible pour de nombreuses raisons bien documentées.
- Les développeurs se sentent impuissants, non impliqués et sous-estimés dans le processus.
- Le processus étouffe la rétroaction vers le haut ou la ralentit.
- Le manque de rétroaction et de mécanismes itératifs le rend lent et inefficace ... et bien plus encore
Développement collaboratif
Transformer des singes de code en collaborateurs 
Les modèles de développement collaboratif utilisent généralement des concepts de propriété partagée, de conversations et de développement itératif pour atteindre plusieurs objectifs:
- Évitez le syndrome du singe code en donnant aux développeurs (et aux autres parties prenantes) la propriété et un rôle actif dans la prise de décision.
- Améliorez la communication bidirectionnelle en brisant les murs/silos/barrières fonctionnelles qui peuvent ralentir la coopération ouverte.
- Accélérez le développement en fournissant un processus expérimental/de prototypage/itératif plutôt que linéaire, résultant en une détection plus rapide des pannes/erreurs et une évolution plus rapide du produit. ... et autres avantages
Dans un modèle de développement collaboratif, le professionnel UX devient un facilitateur, pas un directeur de l'activité produit.
- En favorisant le processus de conception collaborative, l'idéation guidée, les conversations facilitées et la propriété partagée du processus de développement de produit, le professionnel UX maximise la contribution des participants de l'équipe au lieu de diriger les ressources de l'équipe pour faire un travail.
Il existe de nombreux outils et cadres de référence ici pour faciliter le développement collaboratif:
Les cadres tels que Agile, Spiral, Lean et autres fournissent une structure globale et des conseils pour le développement collaboratif de produits.
Modèles comportementaux tels que Flow , Hyperfocus , Hiérarchie des besoins , N-Ach et d'autres aident à fournir des modèles psychologiques pour motiver les développeurs et les concepteurs dans un environnement d'équipe.
Les méthodes de processus d'équipe telles que les entretiens de conception, le scénarimage, l'idéation structurée et d'autres fournissent des directives de collaboration pour accomplir des tâches spécifiques dans le flux de production.
Espérons que ces termes/concepts fourniront un point de départ pour vos recherches futures.
La plupart des développeurs avec lesquels j'ai travaillé ont des opinions sur l'UX, et souvent ils peuvent être valides. La plupart du temps, ils causent plus de maux de tête que souhaité, mais cela est principalement dû à un manque de communication au sein de l'équipe. La communication est l'antidote dans ce cas. Je vais parler de quelques bonnes pratiques et de scénarios idéaux qui devraient aider à illustrer certaines stratégies pour faire face à ce dilemme:
Bons développeurs
Un bon développeur s'en remettra à l'équipe UX lorsqu'un problème survient qui pourrait affecter l'utilisateur - non pas parce que ce sont des singes qui ne savent pas quoi faire, mais parce qu'ils respectent que c'est votre rôle d'enquêter et de résoudre le problème. S'ils ont des opinions sur ce que pourrait être la solution, ils devraient la partager, mais en tant qu'UXer, vous devriez leur demander s'ils ont des idées sur la façon dont le problème pourrait être résolu. Cela ne signifie pas que vous devez courir avec, mais c'est peut-être la meilleure idée de tous les temps! On ne sait jamais.
Bons designers
De même, dans les bonnes équipes, les concepteurs UX incluront des développeurs dans leur processus. Pas tout le temps et pas tous les jours nécessairement, mais certainement à des moments clés. Les développeurs sont naturellement des résolveurs de problèmes curieux - s'ils obtiennent simplement des réponses mais ne voient pas la pensée derrière eux, ils sont tenus de remettre en question vos motivations et votre fonctionnement. À long terme, ils nourriraient des ressentiments s'ils ne se sentaient pas libres de remettre en question l'UX.
En pratique
Un exemple de ce que j'ai fait précédemment au cours d'un cycle UX pour enquêter sur une fonctionnalité particulière (bien que raisonnablement importante) serait d'inviter un ou deux développeurs aux premières réunions de lancement et à certains ateliers suivants. De cette façon, ils auront un bon aperçu de ce que vous essayez de réaliser et pourquoi, et auront la possibilité de fournir des commentaires et des commentaires. Cela leur donne un sentiment d'appropriation du résultat, ce qui est inestimable pour maintenir le moral de l'équipe. Après cela, au fur et à mesure que les conceptions évoluent et que les PO sont recherchés, etc., je demanderais de temps en temps aux développeurs de reprendre leur point de vue sur les itérations de conception. Ce n'est pas toujours idéal, mais si vous sautez cette partie, il vous serait au moins conseillé d'organiser une réunion pendant que vous transférez le projet de la conception au développement. De cette façon, toutes les parties peuvent exprimer leurs préoccupations et se rappeler mutuellement leurs rôles respectifs dans le processus. (J'espère qu'une réunion de transfert va sans dire ... mais vous seriez étonné!)
De plus: tout au long du voyage, il y aura diverses sessions de test utilisateur et les retours des parties impliquées et il est important de documenter tout cela dans un endroit accessible à tous. Beaucoup de développeurs avec qui j'ai travaillé aiment fouiller dans la documentation UX et comprendre ce qui s'est passé.
Lectures complémentaires
Un très bon livre sur UX qui a une section sur les relations entre UXers et l'équipe en général est Under Cover User Experience Design par Cennydd Bowles et James Box http://undercoverux.com/ . C'est un peu daté à certains égards, mais il regorge de bonnes idées et de conseils intemporels.
Il s'agit de la structure organisationnelle et de la mentalité de silo classique.
Perdez les silos.
Les silos mettent l'accent sur les objectifs personnels plutôt que sur les objectifs de l'organisation. Les stratégies deviennent fragmentées et intériorisées plutôt que de faire partie d'une image plus large au profit des utilisateurs finaux.
Faire passer des morceaux de travail d'un groupe à un autre n'est pas la bonne façon de bien faire le travail. Impliquez autant de personnes que possible tout au long du processus.
Travailler en équipe avec des objectifs communs (ceux de l'utilisateur), avec une communication ouverte et un partage des connaissances. Connaissez les points forts des autres membres de l'équipe et assurez-vous qu'ils connaissent vos points forts.
Matériel de lecture:
Smashing Mag:Briser les silos, Partie 1: Les conséquences du travail en isolation
Leisa Reichelt:Tout le monde fait de la stratégie en ce moment et La stratégie ne vit pas dans un silo (ou, il n'y a rien de tel que la stratégie UX)
FoolProof:Briser les silos organisationnels
Qu'il s'agisse d'un dilemme de "singe codeur" ou de "singe pixel" (pour les concepteurs graphiques/visuels), le problème reste le même. Il y a essentiellement deux aspects de tout rôle qui a un certain degré de spécialisation. Dans le premier cas, il s'agit de pouvoir résoudre des problèmes dans votre domaine, et dans le second cas, il s'agit d'implémenter la solution.
Le dilemme du singe de codage concerne la mise en œuvre d'une solution que vous n'avez pas trouvée et, par conséquent, vous n'avez aucun intérêt personnel dans le résultat ou vous n'êtes pas d'accord avec le fait que c'est la bonne solution au problème.
Le `` gorille codeur '' est la personne qui (vraisemblablement parce qu'il occupe une position plus élevée ou plus expérimentée) se bat la poitrine à propos de ces problèmes mais peut ou non affecter les changements.
La solution est vraiment de définir les attentes pour votre rôle/position afin qu'il réponde à vos besoins. Si vous êtes heureux de trouver une solution sans la mettre en œuvre, alors peut-être que le travail de codage ne convient pas. Si vous êtes heureux d'implémenter la solution de quelqu'un sans le remettre en question, le travail de codage de singe est tout à fait approprié.
P.S. Je pense que la personne UX pourrait tomber dans la description d'un singe `` magique '', car beaucoup de gens considèrent les aspects apparemment très logiques du travail de recherche et de test que les praticiens UX effectuent comme une sorte de magie `` noire/noire ''.
Il y a déjà d'excellentes réponses ici.
Je voudrais apporter une perspective légèrement différente sur le sujet, qui est davantage basé sur les processus.
Développement piloté par les tests
Parmi les différentes stratégies de développement logiciel, le Test Driven Development (TDD) est l'une des plus populaires de nos jours.
Il affirme que vous devez écrire des tests avant écrire n'importe quel code. Mais le paradigme va bien plus loin, car beaucoup considèrent les tests comme l'élément central de la documentation, des exigences et des spécifications d'un système.
Les tests doivent saisir:
- Cas d'utilisation, y compris les chemins alternatifs.
- Rétroaction attendue pour diverses actions de l'utilisateur.
- La logique métier.
- etc.
Une grande partie de cela est définie par le travail de l'UXer.
Les tests peuvent être écrits dans un langage assez naturel (voir Concombre ), ou en utilisant un langage de programmation dans (espérons-le) un format compris par les non-programmeurs; quelque chose comme ça:
describe( "distance converter", function () {
it("converts inches to centimeters", function () {
expect(Convert(12, "in").to("cm")).toEqual(30.48);
});
it("converts centimeters to yards", function () {
expect(Convert(2000, "cm").to("yards")).toEqual(21.87);
});
});
TDD centré sur l'homme
La combinaison de la conception centrée sur l'humain (ce qui signifie que l'UX pilote la conception du système et donc également sa mise en œuvre) avec TDD est de plus en plus répandue.
Le processus ressemble à peu près à ceci (beaucoup a été omis par souci de clarté et de se concentrer sur le message clé):
Il est important de noter que les tests servent de pont entre la conception et la mise en œuvre. L'argument tourne souvent autour de qui devrait passer le test, les options étant:
- Le concepteur UX - nous devons de toute façon documenter une grande partie de ce que les tests couvrent, donc plutôt que d'écrire quelque chose en un seul endroit qui est ensuite converti en test, cela vaut la peine de l'écrire seulement deux fois dans une syntaxe qui peut être facilement convertie en test.
- La personne QA
- Le développeur - les développeurs doivent souvent écrire des tests supplémentaires pour les unités de code internes, et sont les plus compétents avec la syntaxe.
Mon argument est que si l'on considère l'ingénierie aller-retour, les UXers devraient être ceux qui écrivent les tests qui capturent une grande partie de leur travail.
Qu'est-ce que cela signifie pour les développeurs?
- Premièrement, de bons tests fournissent des spécifications bien définies .
- Les tests font gagner beaucoup de temps aux développeurs car le code est testé automatiquement plutôt que le développeur ne doit tester tous les comportements précédents à chaque changement (pour donner un exemple, un champ de saisie de date structuré que j'ai conçu a impliqué 64 tests, la plupart représentent des cas d'utilisation atomiques comme "si l'utilisateur est partiel le jour et appuie sur TAB, la sélection doit passer au mois partiel"; si le développeur devait tester manuellement chaque utilisation cas après l'avoir implémenté avec tous les cas d'utilisation précédents, il y aurait 2080 tests à exécuter)
- Les tests réduisent les bugs .
- Les tests permettent aux développeurs d'écrire un meilleur code car ils peuvent améliorer le code sans craindre de le casser.
OK, donc pour que tout cela se passe, qu'est-ce qui est nécessaire? Les développeurs doivent écrire du code par rapport à des exigences bien spécifiées sous forme de tests.
Est-ce à dire "qu'on lui dise quoi faire?". Eh bien, en quelque sorte oui. Mais considérez les alternatives - en donnant simplement une courte phrase d'une fonctionnalité requise et en espérant que le développeur fera un travail de conception approprié et écrivez les tests?
Je dirais que les développeurs seront plus heureux de faire partie d'un processus HCID/TTD, que toute stratégie qui omet l'un ou les deux de ces composants.
Bien sûr, cela ne signifie toujours pas que nous ne les impliquerons pas dans le processus de conception, mais vous devez vous rappeler que leur personnalité et leur perspective sur le système sont naturellement différentes de celles des utilisateurs ou des concepteurs UX.
Impliquer les développeurs dans UX
Les développeurs sont intelligents et veulent généralement comprendre pourquoi et "parce que c'est dans la spécification" crée juste une autre question raisonnable pourquoi est-ce dans la spécification? Expliquer, défendre et gagner le respect de toute l'aide, mais voici des activités spécifiques que j'ai trouvées pour créer un effet de levier:
Laissez le développeur voir et ressentir les problèmes des utilisateurs
Dans tests utilisateurs , interviews , les rapports de bogues et show and tell sont autant d’occasions pour les développeurs non seulement de comprendre mais aussi de ressentir l’importance de leur travailler sur l'utilisateur. Non seulement ils valorisent l'UX plus haut, mais ils sont plus motivés à faire un meilleur travail.
Co-conception
Un atelier de conception bien organisé rassemble non seulement une gamme d'idées, mais communique également clairement. Un élément clé du dialogue bidirectionnel est que les "gotacha cachés" qui peuvent plus tard apparaître et que les conceptions polluantes sont révélées tôt. De cette façon, le concepteur n'est pas considéré comme "superficiel", mais plutôt comme faisant partie de l'équipe qui s'occupe des choses sérieuses.
Permettre aux développeurs de gagner quelques opinions
Un environnement Agile avec un cycle de rétroaction robuste permet à certaines décisions serrées d'aller dans les deux sens. Plus tard, si une correction de cap est nécessaire, elle peut être effectuée et vous obtenez toujours un excellent résultat utilisateur. Autoriser la conception préférée des développeurs a deux résultats possibles (a) il mesure fortement avec les utilisateurs et vous apprenez quelque chose de peut-être nouveau (b) il mesure mal avec les utilisateurs, et les développeurs apprennent à mieux piloter l'UX. L'UX a besoin d'un pouvoir de "veto", mais il est crucial de l'exercer au bon endroit et au bon moment.
Conception pour l'implémentation
Cela peut être controversé, mais sans compromettre sur le travail de qualité globale avec les développeurs sur les options UX qui sont adaptées à leurs pressions internes (outillage, timing et ensemble de compétences). À l'occasion, cette interface utilisateur optimisée pour la livraison peut offrir des avantages en termes de cohérence, de simplicité et de précision de mise en œuvre
Éducation
Le plus susceptible de susciter la réflexion des développeurs est probablement Les détenus dirigent l'asile: pourquoi les produits de haute technologie nous rendent fous et comment restaurer la santé mentale par Alan Cooper
Commencer également par une prise non technique peut être intéressant The Design of Everyday Things par Donald Norman
Ajuster le niveau d'engagement en fonction de l'intérêt du développeur
Dans une équipe de développement, vous trouverez normalement un mélange d'intérêt pour l'UX. Certains veulent être étroitement impliqués dans l'UX et certains veulent simplement travailler sur des spécifications fixes. Quoi qu'il en soit c'est la clé lorsque toutes les requêtes sont résolues par la communication - pas une action indépendante.
Certaines des périodes les plus déprimantes que j'ai eues dans ma vie, c'est quand j'ai dû mettre en œuvre quelque chose que quelqu'un d'autre a conçu, et ils l'ont mal conçu. Mettre beaucoup d'énergie et de temps dans quelque chose que vous savez être complètement inutile (ou pire) est aussi écrasant que notre travail peut l'être. Plus je me rapprochais du début du projet, où toutes ces décisions de conception sont généralement prises, plus j'étais heureux.
Donc ma solution serait de pratiquer la co-conception. Un développeur est partie prenante du projet. Votre travail en tant que professionnel UI/UX n'est pas de développer des spécifications à mettre en œuvre, c'est de guider un processus. Mettez votre patron, votre client, l'avocat, l'utilisateur et le développeur autour de la table et formez leur discussion. Mettez-les tous sur la même page et assurez-vous qu'ils travaillent vers le même objectif, chacun selon leur propre perspective.
Tous les outils dont nous disposons, les user stories, les wireframes, les personas, sont tous conçus pour vous y aider: pour permettre aux non-concepteurs de contribuer au processus de conception et pour transformer les divergences d'opinion en choix de conception élégants et créatifs (au lieu d'un argument qui est réglé lorsque le patron choisit l'option la moins chère).
Si vous créez ce genre de rencontre et si vous laissez les gens revenir de temps en temps aux fondamentaux, je suis sûr que vous obtenez des développeurs heureux, qui sont vraiment motivés, car ils comprennent pourquoi le produit est conçu tel qu'il est, et comment ils peuvent aider à atteindre l'objectif commun.
Je pense que la clé ici est de faire la distinction entre dire au développeur ce qui doit être fait et dire au développeur comment le faire.
Le concepteur UX est spécialisé dans la détermination de l'expérience utilisateur qui sera la plus positive. Cela implique entre autres la facilité d'apprentissage et la facilité d'utilisation. Si le développeur respecte le concepteur UX, le développeur respectera généralement (pas toujours) l'opinion de l'UX sur ce à quoi le système devrait ressembler, face à l'utilisateur. Et l'UX devrait exprimer cette opinion.
Si le concepteur UX respecte le développeur, le concepteur UX s'abstiendra de dire au développeur comment le faire. Le développement consiste à savoir comment faire ce qui doit être fait. Concentrez-vous sur l'interface et laissez l'implémentation au développeur.
La clé est le respect mutuel. Sans cela, même la bonne structure organisationnelle va tomber à plat. Avec respect mutuel, les choses vont marcher, même si une partie marche de temps en temps sur la pelouse de l'autre.
Ma question est de savoir quelles approches (processus, outils et méthodes, etc.) utilisez-vous dans votre travail en tant qu'expert UX, concepteur d'interaction ou similaire pour surmonter le "dilemme du singe codant"?
Je mets à jour mon CV et trouve un nouvel emploi.
Malheureusement, pour les codeurs et les utilisateurs UX, ce qui fait de votre rôle un rôle de "singe codeur" est la culture organisationnelle. Les plus gros drapeaux rouges que j'ai trouvés sont a) L'organisation est énorme et b) l'organisation est coincée avec des méthodologies en cascade.
Avec Waterfall, j'ai trouvé que l'UX devient de plus en plus un rôle de preneur de notes hautement rémunéré. (Eh bien, espérons-le, très bien payé). Notre seul travail consiste à dessiner des images pour la gestion.
Passer à Agile aide. Ce n'est pas une panacée, mais cela apporte plus de collaboration - à la fois pour les équipes UX et les équipes de développement.
Mon défi actuel est que j'essaie de faire en sorte qu'une équipe de développeurs soit soumise à un lavage de cerveau pour coder des singes depuis des années. Ils ne savent plus quoi faire quand nous leur demandons "alors, devs, qu'en pensez-vous?" :)
PS (C'est une excellente question!)
Éducation et communication. Cela se produit dans toutes les relations de service - dire à l'avocat quoi faire ou au plombier quoi faire peut être valable parfois, et peut ne pas l'être à d'autres moments.
Lorsque votre client demande un mauvais travail, l'expert a le devoir de communiquer clairement que ce qu'il demande n'est pas approprié et pourquoi - et ensuite, s'il persiste, demandez-lui de formaliser la demande par écrit, en reconnaissant qu'il demandent à l'expert d'aller à l'encontre de son expertise - puis de faire le travail et de passer à autre chose.
Vous leur communiquez ce que vous attendez d'eux dans la relation, ce qu'ils devraient attendre de vous, et s'ils commencent à pousser pendant le travail que vous communiquez, vous éduquez, puis vous avancez dans la direction que vous avez définie avec votre client. Cela peut en fait être de rompre la relation. Cela peut être un compromis.
La clé, cependant, est la fondation initiale que vous avez créée avec eux sur laquelle votre relation est construite. S'ils ne vous font pas confiance en tant qu'expert, ou que vous ne leur faites pas confiance en tant que client pour savoir ce qu'ils demandent, alors vous allez rencontrer ces problèmes fréquemment.
Ensuite, vous développez de nouvelles relations et mettez fin à des relations qui ne fonctionnent pas pour vous au besoin.
Conception collaborative et non collective
Il est important de distinguer clairement entre le design collectif et le design collaboratif car ils pourraient conduire à deux résultats complètement distincts!
Collaboratif implique la contribution de différents rôles: (personnes + expérience + Connaissances + perspective etc. pour atteindre une cible ou un objectif partagé. Le résultat est un solution forte et viable à un problème. =
Collectif implique, tout le monde est impliqué mais pas pour atteindre un objectif commun, plutôt pour avoir son mot à dire. Il en résulte ne solution diluée, compromise et médiocre car elle a essayé de répondre à l'opinion de beaucoup.
UX concerne les méthodes et les processus et moins l'opinion
Il existe des moyens de résoudre le dilemme du singe de codage! La clé ici est d'avoir une méthodologie et un processus en place qui garantissent qu'aucun membre de l'équipe ne se sente aliéné tout en offrant de meilleures solutions:
- Avoir un modèle de développement collaboratif clair (l'agile fonctionne mieux) avec des entrées et sorties claires et standardisées.
- Validation adéquate des solutions proposées: Trajets d'utilisateurs, personnalités, tests, recherches, revues heuristiques, etc. Toujours fournir et partager des justifications clairement structurées et encourager les autres membres à les lire (pas facile :)
- Impliquez toutes les personnes concernées dans votre équipe dans les premières sessions de raffinement et externalisez le travail UX autant que possible: Naturellement, personne n'aime être dans une position où il réagit toujours au travail de quelqu'un d'autre! Les gens aiment avoir le sentiment de contrôler ce qu'ils font, d'être consultés plutôt qu'informés.
- N'entrez pas dans un dialogue de sourds prenez plutôt toutes les opinions en compte et convertissez-les en hypothèses à tester. Après tout, si nous travaillons tous au profit de l'utilisateur, les résultats des tests devraient être un argument très convaincant contre toute réserve mal placée.
- Obtenez un accord sur certains principes de conception et créez une bibliothèque de modèles qui documente les différents cas d'utilisation. (Quick Gain)
La liste n'est pas exhaustive mais devrait en principe garantir que tout le monde a contribué positivement au processus de développement depuis les premiers stades jusqu'à la version finale.
Tout comme dans la lutte contre le racisme réel, il est préférable de lutter contre le racisme en réunissant les gens. Travaillez ensemble, dans la même équipe.
Je devrais probablement dire que je n'ai pas l'intention de banaliser le racisme, et si par magie on m'autorisait à m'en débarrasser, le réel irait très certainement en premier.
Commencez par ne pas faire partie du problème. Ne croyez pas, ne vous associez pas ou ne propagez pas le stéréotype (et il est auto-réalisateur). Si vous avez déjà assisté à une conférence ux, il est probable qu'au moins un orateur se soit moqué d'un ingénieur ou d'un développeur en agissant comme un singe ou un homme des cavernes. Ce n'est généralement pas fait avec la malveillance voulue, peut-être l'ironie voulue. Ça fait bien rire. Ne participe pas.
D'autres réponses contiennent d'excellentes suggestions de méthodologies favorisant la collaboration.
Il est probable dans une organisation que vous ne serez pas en mesure de changer la structure entière. Je pense que vous pouvez faire une grande différence pour la macro en affectant le micro. Demandez à participer à la planification/stand up. Lorsque vous travaillez sur un problème, les wireframes peuvent prendre votre ordinateur portable et s'asseoir avec un développeur et collaborer pendant une demi-heure environ. Invitez les développeurs à faire des critiques.
Il est possible que vous ayez parfois l'air d'un imbécile, mais peu importe. Il est également probable que vous marchiez sur les orteils des gens, alors soyez prudent et humble (mais continuez à le faire). Lorsque les petites pratiques deviennent la norme, il est parfois possible de commencer à suggérer les plus grandes.