À propos de l'auteur
Ida Aalen est chef de produit et co-fondateur de la startup de vidéoconférence Confrere . Elle a 10 ans d'expérience avec UX et stratégie de contenu. Elle est …
Plus d'informations sur Ida …
La participation précoce d'autres personnes – en particulier celles d'autres disciplines – peut faire peur. En s'inspirant des revues de code, nous pouvons améliorer la collaboration aussi bien dans nos propres domaines que dans d'autres disciplines, que ce soit la conception, l'expérience utilisateur, le contenu ou le développement.
La collaboration entre développeurs et concepteurs est une chose à laquelle tout le monde aspire, mais est notoirement difficile . Mais avec le Web avancé d'aujourd'hui, il est difficile – voire impossible – de créer un produit vraiment génial sans collaborer à travers les disciplines. En raison de la gamme de technologies requises pour construire un produit, le produit ne peut vraiment réussir que lorsque toutes les disciplines – développeurs et concepteurs, créateurs de contenu et stratèges de l'expérience utilisateur – sont fortement impliqués dès les premières étapes du projet . Quand cela arrive, toutes les finalités de ce qui est nécessaire pour construire un produit sont naturellement réunies en un tout unifié, et donc un très bon produit.
Pour cette raison, personne ne fait plus la promotion des processus de cascade [19459]. Néanmoins, impliquer d'autres personnes au début, en particulier les personnes d'autres disciplines, peut faire peur. Dans le pire des cas, cela conduit à " design by committee ."
De plus, les concepteurs et les stratèges de contenu ont souvent des antécédents dans des domaines où un seul génie créatif reste l'idéal. Avoir quelqu'un d'autre pour prouver son travail peut être une menace pour votre créativité.
Alors, comment pouvez-vous impliquer les gens dès le début afin d'éviter la cascade, mais aussi vous assurer que vous ne vous préparez pas à la création? Comité? J'ai trouvé ma réponse en apprenant des critiques de code.
The Aha! Moment
En Juillet 2017, j'ai fondé Confrere avec deux développeurs, et Nous avons rapidement embauché notre premier ingénieur (je ne suis pas moi-même un développeur, je suis plutôt un UX ou un concepteur de contenu). Notre collaboration se déroulait étonnamment bien, à tel point que lors de nos rétrospectives le thème récurrent était que nous sentions tous que nous «faisions bien».
Je me suis assis avec mes collègues pour essayer de déterminer exactement ce que nous faisions «bien» afin que nous puissions essayer de préserver ce sentiment alors même que notre entreprise grandissait et que notre équipe prenait de l'expansion. Nous avons réalisé que nous apprécions tous que toute l'équipe ait été impliquée dès le début et que nous ayons été honnêtes et clairs dans nos commentaires. Notre directeur technique Dag-Inge a ajouté: «Cela fonctionne parce que nous le faisons en tant que pairs. Vous n'êtes pas réprimandé et vous obtenez juste une liste de fautes. "
Le mot" pair "est ce qui m'a donné le moment aha. Je me suis rendu compte que ceux d'entre nous travaillant sur UX, conception et contenu avaient beaucoup à apprendre des développeurs en matière de collaboration.
L'examen par les pairs sous forme de révisions de code est essentiel à la construction des logiciels. Pour moi, les revues de code sont une source d'inspiration pour améliorer la collaboration dans nos propres domaines, mais aussi un modèle de collaboration entre domaines et disciplines.
Si vous connaissez déjà les révisions de code, n'hésitez pas à passer à la section suivante. Qu'est-ce qu'une révision de code?
Une révision de code peut être effectuée de différentes manières. Aujourd'hui, la forme la plus courante de révision de code se produit sous la forme de prétendues demandes de pull (utilisant une technologie appelée git ). Comme illustré ci-dessous, les demandes d'extraction permettent aux autres membres de l'équipe de savoir qu'un développeur a terminé le code qu'il souhaite fusionner avec la base de code principale. Cela permet aussi à l'équipe de réviser le code: ils donnent des commentaires sur le code avant qu'il ne soit fusionné, au cas où il aurait besoin d'amélioration.
Les requêtes pull ont des rôles clairement définis: il y a un auteur et un relecteur. ] Ingvild et Dag-Inge se posent l'un à côté de l'autre et sourient. Une flèche indique qu'Inngvild a envoyé du code à Dag-Inge « />
À titre d'exemple, disons que notre ingénieur Ingvild a modifié le flux d'inscription de Confrere. Avant qu'elle ne soit fusionnée dans la base de code principale et qu'elle soit expédiée, elle (l'auteur) crée une demande d'extraction pour demander une révision à notre CTO Dag-Inge (le réviseur). Il n'apportera aucun changement à son code, seulement ajouter ses commentaires.
C'est à Ingvild de décider comment elle veut réagir aux commentaires qu'elle a reçus dans la revue. Elle mettra à jour sa demande de traction avec les changements qu'elle juge appropriés.
Lorsque le ou les réviseurs approuvent la demande de tirage, Ingvild peut alors fusionner ses modifications avec la base de code principale.
Pourquoi ne pas faire une révision de code?
Si vous n'avez jamais fait de révision de code, le processus ci-dessus peut sembler bureaucratique. Si vous avez des doutes, voici un tonne de blog messages et recherche universitaire sur les avantages de la révision de code.
pour toute l'entreprise, tout ce que nous faisons devrait être ouvert à l'examen des autres, et qu'un tel examen devrait être une partie bienvenue de votre flux de travail plutôt que considéré comme menaçant.
La revue de code réduit le risque. Avoir quelqu'un preuve de votre travail, et aussi sachant quelqu'un va prouver votre travail, aide à éliminer les erreurs et améliore la qualité. En outre, il assure la cohérence et aide chaque membre de l'équipe à se familiariser avec une plus grande partie de la base de code.
Une fois correctement effectuée, la révision de code crée également une culture de collaboration et d'ouverture. Essayer de comprendre et de critiquer le travail d'autrui est une excellente façon d'apprendre, et donc d'avoir une rétroaction honnête sur votre travail.
Toujours avoir au moins deux personnes à regarder le code réduit aussi les idées de "mon" code et "votre" code. C'est notre code
Considérant ces avantages, une révision ne devrait pas être juste pour le code
Principes de revue pour toutes les disciplines, pas seulement le code
Avec les critiques, il y a toujours un auteur et un ou plusieurs réviseurs. Cela signifie que vous pouvez impliquer les gens dès le début sans tomber dans la conception par le comité.
Tout d'abord, je dois mentionner deux facteurs importants qui affecteront la capacité de votre équipe à faire des examens bénéfiques. Vous n'avez pas forcément besoin de les maîtriser, mais vous devriez au moins aspirer à ce qui suit:
- Vous et vos collègues vous respectez les uns les autres et les disciplines de l'autre.
- suffisamment sûr de soi dans votre propre rôle pour que vous ayez l'impression que vous pouvez à la fois donner et recevoir des critiques (ceci est également lié à la sécurité psychologique de l'équipe.)
Même si nous n'examinons pas le code, Il y a beaucoup à apprendre des meilleures pratiques existantes pour les revues de code
Au sein de notre équipe, nous essayons d'adhérer aux principes suivants lors des revues:
- Critique le travail, pas l'auteur. 19659047] Soyez critique, mais restez affable et curieux.
- Faites la distinction entre a) Suggestions b) Exigences, c) Points qui nécessitent une discussion ou une clarification.
- Déplacez les discussions du texte vers le face-à-face. ( La vidéo compte )
- N'oubliez pas de faire l'éloge des bonnes parties! Qu'est-ce qui est intelligent, créatif, solide, original, drôle, gentil, etc.?
Ces principes n'ont pas été écrits avant après nous avons discuté pourquoi notre collaboration fonctionnait ainsi bien. Nous avions tous le sentiment qu'on nous permettait de poser des questions et de suggérer des améliorations, et que nos motivations étaient toujours de construire quelque chose de bien ensemble, et non de critiquer quelqu'un d'autre
. donnaient, et se souvenaient aussi de faire l'éloge du bon travail de chacun, faire des critiques était une force positive plutôt que démotivante.
Un exemple
Pour vous donner une idée de la façon dont notre équipe utilise l'examen à travers les disciplines , regardons comment les différents membres de notre équipe ont basculé entre les rôles d'auteur et de critique quand nous avons créé notre flux d'inscription.
Étape 1: Collecte des exigences
Auteur: Ida (UX) [19659005] Évaluateurs: Svein (stratégie), Dag-Inge (ingénierie), Ingvild (ingénierie).
Les sessions de tableau blanc peuvent être épuisantes s'il n'y a pas de structure. Pour maintenir la productivité et la créativité, nous utilisons la structure auteur / critique, même pour quelque chose d'aussi basique que le brainstorming sur un tableau blanc. Dans ce cas, dans lequel nous devions établir les conditions de notre flux d'inscription, je devais en être l'auteur, et le reste de l'équipe a donné son avis et a agi en tant que réviseur. Parce qu'ils savaient aussi qu'ils seraient en mesure de revoir ce que j'ai trouvé à l'étape 2 (beaucoup plus de possibilités d'ajustements, de suggestions et d'améliorations), nous avons travaillé rapidement et nous sommes parvenus à un accord en moins de 2 heures. ] Étape 2: Maquette avec microcopie
Auteur: Ida (UX)
Évaluateurs: Ingvild (ingénierie), Eivind (design), Svein (stratégie).
En tant qu'auteur, j'ai créé une maquette du flux d'inscription avec microcopie. Le flux d'inscription a-t-il un sens, tant du point de vue de l'utilisateur que de l'ingénierie? Et comment pourrions-nous améliorer le flux d'un point de vue design et frontal? À ce stade, il était essentiel de travailler dans un format dans lequel il serait facile pour toutes les disciplines de donner leur avis (nous avons opté pour Google Docs, mais cela aurait aussi pu être fait avec un outil comme InvisionApp). : Mise en œuvre du flux d'inscription
Auteur: Ingvild (ingénierie)
Relecteur: Ida (UX) et Dag-Inge (ingénierie).
Nous nous étions mis d'accord sur flux, les champs d'entrée, et la microcopie, et il appartenait à Ingvild de l'implémenter. Grâce à Surge nous pouvons automatiquement créer des URL de prévisualisation des modifications afin que les personnes qui ne peuvent pas lire le code puissent aussi donner leur avis à ce stade.
Étape 4: Test utilisateur
Auteur: Ida (UX)
Testeur: Les utilisateurs.
Oui, nous considérons que l'utilisateur teste une forme de révision. Nous avons mis en ligne notre flux d'inscription nouvellement créé avec les utilisateurs actuels. Cette étape nous a donné une tonne de perspicacité, et les changements les plus significatifs dans notre flux d'inscription sont venus en conséquence.
Étape 5: Conception
Auteur: Eivind (design)
Relecteurs: Ingvild (ingénierie) et Ida (UX).
Lorsque le design apparaît soudainement à l'étape 5, cela ressemble beaucoup à un processus en cascade. Cependant, notre concepteur Eivind était déjà intervenu en tant qu'examen depuis la deuxième étape. Il a donné beaucoup de commentaires utiles à ce stade et a également commencé à réfléchir à la façon dont nous pourrions améliorer la conception du flux d'inscription au-delà des modules existants dans notre système de conception. À cette étape, Eivind pourrait également aider à résoudre certains des problèmes que nous avons identifiés dans le test de l'utilisateur.
Étape 6: Implémentation
Auteur: Ingvild (ingénierie)
Relecteur: ] Eivind (conception), Ida (UX) et Dag-Inge (ingénierie).
Et puis nous sommes de retour à l'implémentation
Pourquoi réviser les travaux
En résumé, il y a toujours un seul auteur, évitant ainsi conception par comité. En faisant participer tout un éventail de disciplines en tant qu'examinateurs, nous évitons d'avoir un processus de chute d'eau.
Les gens peuvent signaler leurs préoccupations rapidement et commencer à réfléchir à la façon dont ils peuvent contribuer plus tard. Les rôles clairement définis gardent le processus sur la bonne voie.
Procédures pas à pas de revue régulière
En s'inspirant de procédures pas à pas, nous effectuons régulièrement des revues de différents foyers guidés par les principes suivants:
- ]
- Une personne est chargée de l'examen et de la documentation
- L'idée est de d'identifier les problèmes pas nécessairement de les résoudre.
- Choisissez un format qui donne le plus de contexte possible, de sorte qu'il soit facile d'agir sur les résultats plus tard (par exemple, InvisionApp pour les avis visuels, Google Docs pour le texte, etc.)
fait passer en revue les soluces pour des choses telles que les audits d'accessibilité, l'examen des demandes de fonctionnalités, l'audit de l'implémentation de la conception et les évaluations d'utilisabilité heuristique.
Lorsque nous effectuons nos revues trimestrielles de l'accessibilité, Joakim erface et documents et hiérarchise les problèmes qu'il a trouvés dans une feuille Google partagée. Joakim nous explique ensuite les questions les plus importantes qu'il a identifiées.
Rencontrer les problèmes en face-à-face (ou au moins en vidéo) aide à créer un environnement propice à l'apprentissage plutôt qu'un sentiment de supervision ou de microgestion. 19659103] Trois personnes dans un canapé réunis autour d'un ordinateur portable. Ils discutent et sourient. « />
Si vous vous retrouvez toujours coincé avec quelque chose qui doit être libéré, ou si vous corrigez ce qui se trouve en haut de votre boîte de réception, les critiques peuvent vous aider à y remédier. Si vous réservez des demi-journées régulières pour réviser le travail que vous avez déjà effectué, vous pouvez identifier les problèmes avant qu'ils ne deviennent urgents. Cela peut aussi vous aider à vous recentrer et à vous assurer que vos priorités vont dans le bon sens. Votre équipe ne devrait peut-être pas commencer à créer cette nouvelle fonctionnalité avant d'être certaine que les fonctionnalités existantes sont conformes à vos normes.
Les tests utilisateur sont une forme de révision
Une motivation importante pour les révisions de code est de réduire les risques. En faisant cela chaque fois que vous introduisez un changement ou que vous ajoutez quelque chose de nouveau à votre produit, et pas seulement lorsque vous soupçonnez que quelque chose n'est peut-être pas à la hauteur, vous diminuez les chances d'expédier des bugs ou des sous-fonctionnalités. Je crois que nous devrions regarder les tests d'utilisateurs dans la même perspective.
Vous voyez, si vous voulez réduire le risque d'expédition avec des problèmes d'utilisabilité majeurs, les tests utilisateurs doivent faire partie de votre processus. Le simple fait que vos concepteurs UX examinent l'interface ne suffit pas. Plusieurs études ont constaté que même les experts de l'utilisabilité échouent à identifier tous les problèmes d'utilisabilité réels. En moyenne, 1 problème sur 3 identifié par les experts était de fausses alarmes – ce n'était pas un problème pour les utilisateurs dans la pratique. Mais, pire, 1 des 2 questions que les utilisateurs ont effectivement eu, ont été ignorées par les experts.
Sauter les tests utilisateur est un risque tout aussi important que de passer en revue le code
Les personnes qui travaillent dans le domaine du design, de l'expérience utilisateur et du contenu ont souvent des formations dans des écoles d'art ou peut-être dans la littérature, dans lesquelles l'unique créateur ou génie artistique créatif est considéré comme l'idéal. Si vous revenez dans l'histoire, c'était aussi le cas pour les développeurs. Au fil du temps, cela a changé par nécessité lorsque le développement web est devenu plus complexe.
Si vous vous cramponnez à l'idée de créativité venant de quelque part au plus profond de vous-même, l'idée de révision peut paraître menaçante ou effrayante. Quelqu'un s'immisce dans votre travail à moitié fini? Aie. Mais si vous pensez à la créativité comme quelque chose qui peut provenir de nombreuses sources, y compris le dialogue, la collaboration ou toute forme d'inspiration (que ce soit de l'extérieur ou d'un endroit en vous), une revue n'est qu'un atout et une opportunité. Tant que nous construisons quelque chose pour le web, il n'y a aucun moyen de collaborer avec d'autres personnes, que ce soit dans notre propre domaine ou d'autres. Et une bonne idée survivra à la révision.
Créons quelque chose de génial ensemble.
Source link