Frank Taillandier

La hype statique ne fait que commencer

2018-11-20T16:33:00+01:00

Le Web évolue sans cesse et depuis quelques années, on assiste à la convergence de plusieurs tendances : le versionnement systématique des projets, la génération de contenus en amont, le déploiement continu, l’hébergement de fichiers sur des réseaux de CDN performants, l’omniprésence de JavaScript côté client grâce notamment à des frameworks qui proposent une gestion d’état de composants, de plus en plus d’APIs de services accessibles dans divers domaines, le lancement de fonctions depuis le cloud, etc.

Ce qu’on résume encore trop souvent à l’appellation “site statique” cache en fait l’adoption d’un nouveau paradigme : le séparation du back et du front et le passage d’architectures monolithiques à des architectures plus modulaires, plus performantes, plus sécurisées et redimensionnables par défaut.

Aujourd’hui JavaScript est en train de remplacer HTML côté client (et aussi de se faire une place côté serveur avec NodeJS). On est passé d’architectures centralisées et monolithiques à des architectures décentralisées et modulaires. Les coûts de développement sont moindres, même chose pour l’hébergement, qui est même la plupart du temps devenu gratuit quand il se contente de servir des fichiers statiques.

Tout cela permet de se recentrer sur le métier, sur sa valeur ajoutée, et de ne pas avoir à maintenir de trop gros systèmes complexes qui ne feront que se dégrader avec le temps.

Si les premiers générateurs ne produisaient que des sites purement statiques, aujourd’hui, avec la multiplication de services, la mise à disposition d’APIs et l’omniprésence de composants JavaScript côté client, on obtient des pages statiques qui intègrent des composants dynamiques, le tout hébergé dans le Cloud sur des réseaux performants situés au plus proche de l’utilisateur final.

La performance fait partie des facteurs différenciants, et elle est devenue un atout majeur pour les entreprises qui ont compris qu’à l’ère du web mobile, si vous n’êtes pas suffisamment rapides, votre taux d’abandon sera plus élevé et la rétention et la fidélisation seront plus faibles.

Lors d’une conférence improvisée au Capitole du Libre, j’ai tenté d’expliquer en 45 minutes comment tout cela était apparu petit à petit en proposant une chronologie rapide et subjective des diverses évolutions qu’à connu le Web de ses débuts à nos jours avec un focus particulier sur :

l’apparition de différents formats textes facilement lisibles par les humains et les machines pour représenter des contenus et des données : d’abord HTML puis plus tard YAML, JSON, Markdown, et maintenant JSX ou Portable Text.
la mise à disposition de nombreux services spécialisés par des startups innovantes et la prolifération d’APIs permettant aux développeurs et aux machines d’interagir à distance avec ces services.
l’évolution des requêtes HTTP avec REST et maintenant GraphQL qui permettent d’interagir avec les services web,
l’automatisation de la validation et de la publication de modifications, notamment grâce à la gestion de version avec Git et aux plates-formes de déploiement continu,
la démocratisation de l’accès au stockage dans le Cloud, grâce à une baisse des prix et une concurrence acharnée des différents acteurs (Amazon, Google, Microsoft, Cloudflare, etc.)

Le logiciel libre a joué un rôle central dans la modernisation des manières de travailler. Aujourd’hui beaucoup d’outils cités, même s’ils sont initiés par des acteurs majeurs comme Facebook, Google, Microsoft ou Amazon, sont développés sous licence libre. Même chose pour les générateurs de site statique Jekyll, Hugo, Gatsby et leurs poursuivants. Le modèle a fait ses preuves, l’open source encourage la collaboration, l’innovation et l’excellence technique. Et la réutilisation. C’est important de le préciser car elle va permettre d’améliorer la productivité des équipes et la fiabilité de l’application.

Dans un monde de services, on trouve davantage de modèle d’affaire freemium : les projets modestes de petite taille avec peu d’intervenants ne paieront pas grand-chose, voire rien du tout, tandis que les plus grosses structures et les gros volumes devront financer le développement et la pérennité du service. Ainsi on facilite l’adoption dans un premier temps des développeurs qui travaillent sur des projets de taille modeste, en espérant que s’ils sont satisfaits du service, ils l’utiliseront aussi sur des projets plus importants au sein de leur entreprise.

C’est donc accessible sur le papier à tout le monde, même si le passage aux dernières technologies est toujours moins simple pour les petites structures, qui ne dédient pas forcément du temps à ce qu’on a longtemps appelé de la recherche et du développement. Ici il serait plus juste d’appeler ça de la formation continue et de la veille technologique, afin de rester à jour dans son domaine.

C’est une aubaine pour les entreprises dont le cœur de métier n’est pas forcément le numérique et qui ont accumulé de la dette technique. Elles peuvent en profiter pour rattraper leur retard en se reposant au moins en partie sur des services tiers (contenus, authentification, paiement, recherche, etc.) et ainsi en rembourser une partie tout en minimisant le coût de fonctionnement et de maintenance de leur propre infrastructure. Pour ces structures, il serait à minima intéressant de procéder à un état des lieux et de comparer les solutions. C’est en réalisant des tests que Smashing Magazine a pu constater les gains et a décidé de migrer.

Ce dont la société Netlify fait la promotion sous l’acronyme JAMstack, à savoir des architectures découplées et décentralisées, peut profiter également aux petites structures, qui n’auront quasi rien à débourser en maintenance et en hébergement, tout en améliorant leur qualité de service. Elles pourront ainsi investir davantage dans une conception centrée utilisateur — la vraie, celle qui va se confronter au réel, pas celle qui se résume à adopter le même look-and-feel que le voisin.

Dans un paysage en constant mouvement, il est parfois difficile de s’y retrouver, la multiplication des technologies, l’abondance de l’offre, la diversité de niveaux d’expériences dans la profession, la difficulté de se projeter ne serait-ce qu’à moyen terme, autant de facteurs qui font que l’on va souvent préférer attendre une adoption et une maturité suffisante avant de songer à franchir à son tour le pas.

Le fait que les entreprises innovantes soient les premières à adopter ces technologies est somme toute logique, toutefois cela devrait mettre la puce à l’oreille des développeurs web et de leurs clients : les choses bougent, et en 2018 avec tout ce qui s’est passé depuis 5 ans, on peut affirmer avec certitude qu’il n’y a pas que WordPress, Joomla ou Drupal qui permettent de développer des sites web. Mieux, les alternatives présentent de sacrés avantages.

Vu les performances affichées et ses impacts positifs, la concurrence va faire qu’il va falloir considérer tous les leviers disponibles pour améliorer la qualité de ses services numériques.

Les architectures découplées en font clairement partie, et devraient continuer à voir leur adoption progresser dans les années qui viennent.

Concevoir dans le navigateur

2018-09-06T00:00:00+02:00

Le retour d’expérience de Mark Dalgleish et son équipe sur la mise en place d’un outillage qui facilite la collaboration des développeurs et des designers sur un style guide, géré d’un côté en React et de l’autre avec Sketch. C’est déjà un énorme progrès mais les outils utilisés par les designers ne permettent toujours pas de travailler directement sur le medium cible.

Demandez à n’importe quelle équipe qui travaille avec un design system et vous comprendrez que les bénéfices sont nombreux — les designers et les développeurs sont plus productifs, les produits sont plus consistants, la communication est plus claire entre les disciplines.

Toutefois, la majorité des design system souffrent toujours d’un gros problème. Les designers et les développeurs continuent de travailler sur des médiums totalement différents. Du coup sans effort permanent de synchronisation manuelle, notre code et nos éléments de design diffèrent de plus en plus les uns des autres.

Pour les boîtes qui bossent avec des design systems, il semblerait que notre industrie soit condamnée à travailler avec des outils de conception qui ne soient pas pensés pour le bon medium — incapables d’incorporer notre travail de développement dans la prochaine itération de design.

Fort heureusement, tout cela est sur le point de changer.

Page d’accueil de la charte de Seek

L’odyssée de notre design system

Chez SEEK, nous travaillons sur notre living style guide depuis plus d’un an maintenant, avec de plus en plus de composants React. Vous imaginez bien que cela nous a amené à revoir totalement notre manière de penser le design visuel.

Nous avions tout d’un coup une seule source de référence, dans le code, facile à installer, qui définit la manière dont notre marque est affichée sur des douzaines de projets différents.

Bien entendu, notre travail sur le design system n’a pas commencé dans le navigateur. Nous avons passé beaucoup de temps en amont pour tenter de formaliser nos règles de conception dans un format plus statique — bien avant que notre living style guide existe.

Ce qui a commencé sous la forme d’un fichier PDF statique, a ensuite évolué en un kit de démarrage Sketch. On pouvait facilement se baser sur les symboles standardisés, les couleurs et les styles typographiques pour démarrer tout nouveau travail de conception.

Notre premier fichier de démarrage Sketch

Nous avons par la suite testé Craft, un ensemble de plugins Sketch d’InVision, le plus notable d’entre eux étant le plugin de bibliothèque.

Cela nous a permis de partager les symboles Sketch à la fois entre les documents et les différentes équipes, mais aussi de bâtir une bibliothèque de symboles partagée avec l’ensemble de l’entreprise.

Plugin de bibliothèque Craft

Nous nous sommes rapidement aperçu de la quantité de travail absurde demandée pour maintenir cette bibliothèque à jour, surtout quand les éléments existants et les nouveaux n’arrêtent pas d’évoluer dans l’ensemble de nos produits.

Les développeurs, souvent en binôme avec les designers, procédaient à des changements dans le code qui pouvaient avoir un impact spectaculaire sur le design visuel, mais notre bibliothèque statique elle restait intacte — sauf si quelqu’un se rappelait de la mettre à jour manuellement, ce qui était rarement le cas.

Et pendant ce temps les mêmes problèmes de consistance se posaient de l’autre côté de la barrière, avec des développeurs à qui une source unique de référence sur le design manquait pour leur code.

De React à react-sketchapp

C’est à ce moment que nous avons commencé à travailler sur notre premier projet React — avec du rendu côté serveur, assemblé avec webpack et des modules CSS que nous avons aidés à co-créer en cours de route — pour finalement aboutir à la création de notre living style guide.

Le fait que React se focalise essentiellement sur les composants a rendu cette transition inévitable. Ce n’est pas étonnant si depuis sa publication, nous avons vu que c’était la même histoire pour d’innombrables entreprises un peu partout dans le monde.

Une fois que nous avons eu développé une collection assez importante de composants, les autres équipes qui travaillaient sur de nouveaux projets ont pu rapidement bénéficier de notre travail — mais comme notre style guide était constitué de composants React et de fichiers Less, il n’était que peu d’utilité pour nos designers. Toutefois, ce problème ne nous a pas sauté immédiatement aux yeux. Cette déconnexion technique entre les designers et les développeurs ne date pas d’hier — comme elle a toujours existé dans notre secteur d’activité, nous nous sommes habitués à ne pas en tenir compte.

Ça c’était bien entendu avant qu’on découvre react-sketchapp.

React-sketchapp

“Dans Sketch, nous utilisons des symboles et des surcharges, dans React des composants et des propriétés. Ces concepts sont si semblables qu’il serait bête de ne pas les unifier.

Jon Gold, Airbnb

C’était trop beau pour être vrai. Du vrai code React, rendu directement dans Sketch. On dirait bien que les développeurs et les designers allaient enfin pouvoir s’appuyer sur un design system comme unique source de référence.

En centralisant nos règles de conception dans le code, non seulement nous pouvions les diffuser sur nos applications en production, mais nous étions également capables de répercuter notre travail dans les outils que nos designers utilisaient déjà. Au fur et à mesure que nos conventions de conception continuaient d’évoluer, nous étions capables de rester synchrone avec nos designers, sans avoir à intervenir manuellement dans Sketch.

Bien sûr, après avoir creusé un peu, nous avons découvert que react-sketchapp imposait quelques contraintes :

Les composants doivent (évidemment) être développés avec React. Heureusement pour nous nous utilisions déjà React, ce n’était donc pas un problème.
Les styles doivent être définis en JavaScript. Dans notre cas, vu que notre design system était développé avec des modules CSS, c’était déjà un premier obstacle. Même si nous sommes de grands fans de CSS-in-JS nous n’allions pas corriger l’ensemble des styles de notre écosystème — du moins pas dans l’urgence.
Les composants doivent utiliser des primitives génériques (View, Text, StyleSheet) plutôt que les primitives du navigateur, à l’aide par exemple de react-primitives. En gros, react-sketchapp était plus proche de React Native que de pur React. Encore une fois, c’est une migration que nous aurions pu envisager, mais qui aurait demandé beaucoup de travail et quelques arrangements au passage.

Donc bien que react-sketchapp soit un projet extraordinaire, que nous vous recommandons chaudement, ses pré-requis techniques faisaient que nous n’aurions pas pu l’utiliser à court ou moyen terme.

Même si vous avions décidé de migrer notre bibliothèque de composants, nous aurions eu besoin d’une autre solution entre temps.

Versionner les fichiers de conception

Comme vous le savez peut-être déjà, il existe des outils qui vous permettent de versionner vos fichiers dans vos outils de conception —— mais c’est le monde à l’envers.

Nous avons besoin que nos outils de conception soient compatibles avec le contrôle de version, et non l’inverse. Nous avons besoin que les fichiers produits par les designers figurent aux côtés de ceux produits par l’ensemble de l’équipe — et non dans un silo réservé aux designers, hébergé dans un jardin privé.

Nous avons donc essayé de faire autrement.

Nous avons expérimenté l’enregistrement de fichiers Sketch dans le dépôt de notre style guide à l’aide de Kactus et de quelques scripts Node maison.

Kactus, montrant les différences d’un fichier Sketch enregistré avec Git

Même si nous avons pu réaliser cette prouesse technique, nous étions déçus de nous apercevoir que le flux de travail ne fonctionnait pas comme nous le souhaitions — en tout cas, pour ce qui nous concerne. Le fait de devoir synchroniser deux formats de fichiers radicalement différents s’est avéré fastidieux, sujet à des erreurs, et difficile à passer en revue.

Garder le code et les fichiers Sketch dans un même emplacement a pu aider à clarifier le problème, mais ça n’aidait pas vraiment à le résoudre. Pire, cela a provoqué de nouvelles frictions pour les contributeurs au style guide, pour un gain minime. Les fichiers Sketch ont rapidement été laissés de côté. Cette expérience fut pour nous un échec.

Mais au moment où nous commencions à perdre espoir de faire travailler ensemble les développeurs et les designers sur un même projet html-sketchapp a débarqué et a changé toute la donne.

L’émergence d’html-sketchapp

En définitive, nous n’étions pas les seuls à avoir des difficultés à intégrer react-sketchapp dans notre stack technique existante.

“Nous étions incapables de simplement passer outre ces limitations, nous avons donc créé html-sketchapp”

Konrad Dzwinel, Brainly

Ils ont pris une approche radicalement différente avec html-sketchapp.

Comme son nom l’indique, html-sketchapp permet de générer des fichiers Sketch à partir de fichiers HTML normaux, mais contrairement à react-sketchapp, vous restez libre des choix techniques pour votre application.

Vous pourriez développer votre application avec Preact, Vue, Angular, Backbone, jQuery — ou même Ruby ou PHP.

Vous pouvez bien entendu utiliser React et cette fois vous pouvez gérer les styles comme bon vous semble, et utiliser les primitives qui font sens pour votre projet.

Le contrat était incroyablement limpide — du moment que vous pouvez générer du HTML, vous pouvez l’importer dans Sketch.

Génération des fichiers Sketch

À première vue, c’était trop beau pour être vrai, mais après avoir jeté un œil sous le capot, nous nous sommes rendu compte que ce n’était pas si compliqué.

Pour comprendre le fonctionnement de html-sketchapp, il faut connaître le format de fichier de Sketch. Étonnamment, les fichiers Sketch sont juste des fichiers zippés.

Une fois dézippés, on s’aperçoit que les fichiers Sketch sont principalement constitués de fichiers JSON qui peuvent être ouverts dans n’importe quel éditeur de texte.

Si vous regardez attentivement le contenu de ces fichiers, vous verrez que c’est un format relativement simple, constitué en grande partie d’une petite poignée de classes imbriquées.

À bas-niveau, html-sketchapp permet de générer à l’aide d’un programme des instances de ces classes et de les convertir en JSON — mais ça ne s’arrête pas là.

La fonctionnalité la plus puissante dans html-sketchapp c’est nodeToSketchLayers, qui vous donne la possibilité de convertir un élément unique du navigateur en un tableau de calques Sketch. C’est là où toute la magie opère, puisque la fonction possède toute la logique pour extraire les styles du navigateur et les convertir en leurs équivalents dans Sketch.

C’est la classe SymbolMaster qui lie vraiment le tout, elle permet de générer dynamiquement des symboles Sketch. Puisque les symboles sont la base de toute bibliothèque Sketch, cela nous a permis d’exposer un ensemble de composants à nos designers, à partir du code sous-jacent.

Malheureusement, certaines limitations dans le format actuel de Sketch liées à l’encodage des styles de texte font que les fichiers générés se sont pas vraiment des fichiers Sketch valides — html-sketchapp les désigne comme des fichiers à peu près Sketch ou asketch pour faire court. Du coup il faut les importer manuellement avec le plugin html-sketchapp pour Sketch. Ça va, c’est pas trop compliqué.

Assembler le tout peut paraître un peu perturbant au début, heureusement un exemple de projet sur GitHub montre comment convertir un style guide existant en document Sketch.

Dès que nous avons vu ça, nous nous sommes rapidement mis à le tester et il ne nous a pas fallu beaucoup de temps avant de pouvoir constater des résultats vraiment surprenants.

Test de html-sketchapp

Pour avoir un premier aperçu des possibilités, nous avons commencé par le faire pointer sur la page d’accueil de notre style guide.

Taking html-sketchapp for a spin—really impressive!

Without having to touch our code, it rendered our style guide documentation home page pretty well—only struggling with the SVGs!

cc @kdzwinel pic.twitter.com/OZ8NFI8X2v
— Mark Dalgleish (@markdalgleish) 23 novembre 2017

Nous avons ensuite généré nos premiers symboles à partir de notre composant Button et de ses différentes variantes de rendu.

Wow—I'm getting pretty far pretty quickly with html-sketchapp 😱 pic.twitter.com/JdbzPHf3AO
— Mark Dalgleish (@markdalgleish) 23 novembre 2017

Pour parvenir à cela, nous avons décidé d’ajouter un fichier JavaScript à l’intérieur de chaque dossier de composant (par exemple Button.sketch.js), qui indique les symboles que nous souhaitons exporter.

Chaque fichier exporte un objet qui définit les noms des symboles et les éléments React correspondants.

import React from "react";
import Button from "./Button";

export const symbols = {
  "Button/Pink": <Button color="pink">Button</Button>,
  "Button/Blue": <Button color="blue">Button</Button>,
  "Button/Transparent": <Button color="transparent">Button</Button>
};

Nous avons ensuite créé une route masquée spécifique pour le site de notre style guide qui importe tous les fichiers de type .sketch.js et qui effectue le rendu des éléments React fournis à l’écran. De cette manière, nous avons pu simplifier le processus de conversion et exposer tous les contenus pour Sketch sur une seule et même page.

Chaque instance de symbole est encapsulée dans un élément div et son nom est défini dans un attribut data, ce qui nous permet de sélectionner et de nommer facilement tous les symboles présents sur la page.

<div data-sketch-symbol="Button/Pink">
  ...
</div>

Ce patron s’est montré tellement efficace, que nous l’avons ensuite appliqué de sorte à inclure aussi les styles typographiques et les couleurs du document.

More progress with html-sketchapp! Text styles in Sketch, defined in code as React components 😱🎉

This is incredible. pic.twitter.com/1CC7GLIw0M
— Mark Dalgleish (@markdalgleish) November 24, 2017

Even more progress with html-sketchapp! Colours defined as Less variables, bulk imported into React components, exported to Sketch as document colours 😱🎉 pic.twitter.com/A5qnbBU8af
— Mark Dalgleish (@markdalgleish) November 24, 2017

Comme notre charte est responsive, nous avons ensuite dû automatiser le redimensionnement du navigateur pour capturer les symboles dans différentes tailles d’écran.

More amazing progress with html-sketchapp! Automatically rendering *every* symbol and text style for an array of named viewport sizes 😱🙌 pic.twitter.com/ZbyvIUfbE7
— Mark Dalgleish (@markdalgleish) November 27, 2017

Nous pouvions désormais ajouter, supprimer et renommer différentes tailles de viewport depuis un seul endroit, et chaque symbole était ensuite régénéré pour prendre en compte ces nouvelles valeurs. Tout d’un coup, on aurait dit que nous venions de résoudre une des problématiques les plus fastidieuses liées à la maintenance d’une bibliothèque responsive Sketch.

Si tout se passait étonnamment pour le mieux, nous avons quand même dû faire quelques adaptations spécifiques pour le support de Sketch — de la même manière que vous devez parfois supporter quelques implémentations erronées d’un navigateur — que nous avons pu rassembler dans un seul fichier.

Du test à la production

Ce qui avait démarré comme une expérimentation à petite échelle s’est rapidement transformé quelque chose qui ressemblait à un mini-framework. À ce niveau, il ne restait plus grand-chose à faire pour l’intégrer proprement à notre style guide, pour l’inclure dans notre processus standard de déploiement.

It's happening! Just opened the PR that automatically converts our style guide components into a Sketch library with html-sketchapp! 😱🎉 https://t.co/764TMHz9Mz
— Mark Dalgleish (@markdalgleish) December 1, 2017

Cependant si vous regardez bien la pull request, vous verrez qu’il nous a fallu ajouter pas mal de code et de dépendances pour relier le tout, même si nous tentions d’effectuer une seule et unique tâche, conceptuellement considérée comme simple à un plus haut niveau.

Pour générer notre bibliothèque Sketch, il nous fallait en passer par les étapes suivantes :

Compiler un script pour le navigateur avec webpack, qui contient html-sketchapp et la logique idoine pour pouvoir sélectionner et convertir les éléments.
Démarrer un serveur web statique sur un port disponible.
Lancer Puppeteer (une version headless de Chromium).
Naviguer jusqu’à la bonne URL.
Injecter le script compilé dans l’instance Puppeteer en train de tourner.
Redimensionner la fenêtre du navigateur plusieurs fois, et prendre des captures pour chaque taille d’écran voulue en appelant les fonctions définies dans notre script compilé.
Enregistrer les fichiers JSON générés sur le disque.
Éteindre le serveur web statique.
Éteindre le navigateur headless.

Il nous paraissait évident que tout cela pourrait être abstrait dans une seule commande — qui nous permette de simplement pointer une URL et de commencer à capturer les composants.

C’est donc ce que nous avons fait.

Voici donc `html-sketchapp-cli`

Moins d’un mois après avoir commencé à intégrer html-sketchapp dans notre style guide, nous avons ouvert le code source de html-sketchapp-cli, un petit utilitaire en ligne de commande qui vous évite d’avoir à coder tout ça.

💎🚀 Super excited to unveil html-sketchapp-cli 🎉

Quickly generate Sketch libraries from HTML documents—powered by html-sketchapp.

Add this:
<div data-sketch-symbol="Button/Primary">…</div>

Run this:
$ html-sketchapp --file sketch.html --out-dir disthttps://t.co/vFH256rLRK
— Mark Dalgleish (@markdalgleish) December 19, 2017

Maintenant, nous pouvons parvenir au même résultat en déclarant une seule dépendance dans notre fichier de configuration :

module.exports = {
  serve: "docs/dist",
  url: "/sketch-exports",
  outDir: "dist/asketch",
  viewports: {
    Desktop: "1024x768",
    "Mobile Plus": "414x736",
    Mobile: "320x568"
  }
};

La bonne surprise c’est qu’en utilisant html-sketchapp-cli dans notre style guide, nous avons pu supprimer beaucoup de code.

To get an idea of why I created html-sketchapp-cli, check out how much code it let me delete from our style guide: https://t.co/2AABh2T6T8
— Mark Dalgleish (@markdalgleish) December 19, 2017

Un processus de design continu

Tout cet outillage fait désormais partie de notre de recette standard de déploiement continu, et nous permet d’étendre la portée de notre code — au-delà de la seule communauté des développeurs, il aide les designers dans leur travail quotidien.

À chaque génération réussie de notre style guide — non seulement nous déployons automatiquement notre site sur GitHub Pages (à l’aide de gh-pages) et nous publions la bibliothèque de composants sur npm (à l’aide du paquet semantic-release) — mais nous générons automatiquement les fichiers asketch, prêts à être importés et à être convertis dans notre bibliothèque Sketch officielle.

Cette librairie Sketch est ensuite distribuée via un disque partagé de notre équipe de designers, ce qui veut dire que nos designers ont en permanence une copie à jour de la bibliothèque, qui se synchronise en temps réel, même quand Sketch est ouvert.

Grâce au support natif des bibliothèques dans Sketch, les designers peuvent ouvrir le menu “Bibliothèque de Style Guide de SEEK” et commencer à sélectionner les composants, en sachant que les conventions de nommage et les styles visuels respectent les attentes des développeurs dans leurs équipes.

Depuis cette adoption, nous avons commencé à voir des changements continus dans notre code se propager dans Sketch — même si parfois les personnes qui font ces changements n’ont même pas Sketch d’installé sur leur machine. Puisque notre style guide est connecté à nos applications en production, il est constamment amélioré par tout un tas de personnes dans nos équipes, et nous pouvons maintenant être sûrs que tous ces changements mettent bien à jour notre bibliothèque Sketch.

Même si nous continuons de travailler sur différents formats et médias, nous mettons tout en œuvre pour créer l’illusion de tous parler une même langue.

Et maintenant ?

Aussi génial puisse être ce développement pour nous, nous le considérons toujours comme une solution temporaire. Effectuer le rendu de contenus web dans Sketch s’avère incroyablement puissant, et c’est une nouvelle étape obligatoire de notre quête, mais notre industrie doit encore aller plus loin.

Les frontières entre nos différents médias sont peut-être un peu plus floues, mais les outils de design futurs devront supprimer cette frontière pour de bon. Pour que nous puissions vraiment libérer son potentiel, nous avons besoin d’outils de conception qui ne se contentent pas d’imiter le médium ciblé, nous avons besoin qu’ils soient bâtis avec.

Heureusement, il y a beaucoup de gens qui travaillent sur ce problème actuellement. Des outils comme Compositor, Interplay, Alva, Haiku, Webflow et UXPin cherchent à faire tomber les murs techniques entre les outils de design et le code final, et d’autres outils du même genre continuent d’arriver.

Qui sait, nous pourrions même commencer à voir des outils de conception plus traditionnels adopter cette approche pour rester à la page, particulièrement quand les design systems font partie de la palette standard d’outils de conception moderne.

En attendant de nouveaux outils de conception qui embrassent véritablement l’époque actuelle des principes qui régissent les design systems, des projets comme react-sketchapp and html-sketchapp font un travail incroyable pour nous préparer à cette façon de penser dès à présent.

Honnêtement, il n’y a jamais eu un meilleur moment pour s’y mettre.

La métaphore du skateboard et de la voiture revisitée

2018-06-07T20:26:00+02:00

Peu d’équipes pratiquent le Lean et l’agilité de manière efficace, surtout quand elles ne comprennent pas en leur sein des personnes avec de vraies compétences en design de service et en commerce. Marty Cagan est un coach produit expérimenté qui milite pour de vraies équipes multi-disciplinaires à même d’aller encore plus vite dans la résolution de problème et dans la livraison d’une solution adaptée et bien conçue.

Il y a un peu plus d’un an, Henri Kniberg, un de mes coaches Agile préféré, publiait un article qui explique très bien comment les équipes de développement peuvent s’appuyer sur le concept de MVP pour s’assurer de bien comprendre les valeurs fondamentales des méthodes agiles. Si vous n’avez pas encore lu l’article d’Henrik, j’espère que vous prendrez quelques minutes pour le faire avant de continuer à lire celui-ci.

Je mets volontairement en emphase “les équipes de développement” car je vais essayer ici de nuancer le concept lorsqu’il s’applique à de véritables équipes produit multi-disciplinaires.

Soyons clair, par “équipes de développement” j’entends des équipes soit uniquement composées de développeurs, soit qui comprennent un membre qui fait office de product owner (et non un vrai product manager).

À contrario, une équipe produit comprend un vrai product manager, un product designer expérimenté et quelques développeurs.

Ne vous méprenez-pas, beaucoup d’entreprises n’ont que des équipes de développement, avec un product owner désigné chargé de faire respecter les rituels de l’Agile et de la gestion du backlog, mais avec peu ou pas de compétences pour être capable d’assurer les fonctions plus larges de responsable produit.

C’est souvent la même chose avec le product designer. L’équipe peut avoir accès à un graphiste, mais pas au product designer dédié auquel je fais référence, avec des compétences en design d’expérience utilisateur, en prototypage, en recherche utilisateur et en design d’interaction.

En tout cas, si l’équipe ne possède pas un vrai product manager ou un vrai product designer, je les redirige généralement vers l’article d’Henrik et je leur dis que c’est ce qu’ils peuvent faire de mieux.

Mais si c’est une vraie boîte qui développe un produit basé sur de la technologie, alors je leur indique qu’ils doivent et qu’ils peuvent faire bien mieux que ça.

Donc si vous disposez d’une véritable équipe produit multi-disciplinaire, avec un product manager expérimenté ainsi qu’un product designer qui travaillent tous deux aux côtés des développeurs, comment allez-vous vous attaquer à ce problème ?

Dans l’exemple d’Henrik, l’équipe travaille à la fois sur le produit le plus adéquat à concevoir ainsi que sur sa réalisation. Et ils n’ont qu’un seul outil générique à leur disposition : les développeurs. On a donc un produit développé progressivement, avec un soin particulier apporté à avoir quelque chose qu’on peut tester avec de vrais utilisateurs à chaque itération.

Henrik insiste qu’ils sont en train de développer pour apprendre, mais ils font avec le seul outil dont ils pensent disposer : des développeurs qui écrivent du code. Si vous lisez attentivement, Henrik dit bien que les développeurs n’ont pas vraiment besoin de développer les produits — ils pourraient développer des prototypes, mais dans la plupart des équipes que j’ai rencontré, ce point passe souvent inaperçu, car elles ne comprennent pas qu’ils existent plusieurs types de prototypes, donc la majorité n’ont pas vocation à être crées par des développeurs.

Considérons à présent le premier principe que j’énonce dans Au-delà du Lean et de l’Agilité. Si vous n’avez pas encore lu cet article, faites-le dès maintenant sans quoi ce qui suit n’aura pas forcément de sens pour vous.

Le premier principe consiste à minimiser les risques dès le départ, avant que nos développeurs n’aient à écrire la moindre ligne de code pour la production. Plutôt que de nous contenter de la notion relativement simpliste du skateboard et de l’itération testable au plus tôt, nous analysons les risques beaucoup plus en détail et considérons explicitement la valeur, l’utilisabilité, la faisabilité et la viabilité commerciale du produit.

Ensuite, en fonction des zones considérées comme risquées, nous choisissons le bon outil ou la bonne technique pour faire le job (le but de cet article n’est pas de vous les décrire tous, mais sachez qu’il y a quatre types principaux de prototypes) et nous décidons si cela doit être testé qualitativement ou quantitativement. Et non seulement nous faisons des tests avec de vraies personnes et des clients, mais aussi avec les autres membres de notre équipe et les différentes parties impactées de notre modèle commercial.

C’est la phase d’exploration du produit. Nous cherchons quel est le produit adéquat à développer.

C’est le product manager et le product designer qui guident la majeure partie de cette activité d’exploration, le designer crée la plupart des prototypes dont nous avons besoin pour évaluer ces risques. Et les développeurs sont inclus dans chaque étape de recherche, à la fois pour mesurer la faisabilité de la solution proposée, mais aussi et surtout pour aider à améliorer la solution en elle-même.

Ce n’est pas que nous ne pourrions pas avoir recours aux développeurs pour créer les itérations d’apprentissage, que décrit Henrik, c’est juste que ça prendrait beaucoup plus de temps (d’après mon expérience, d’au moins un ordre de grandeur), et que ce serait en grande partie du gâchis, sans parler des coûts d’opportunités¹.

Un produit peut nécessiter un travail oscillant entre 5 et 15 itérations avant qu’il ne fonctionne comme il devrait (également parfois appelé “time to money”, soit la période pendant laquelle le produit ne permet pas de gagner de l’argent).

Si toutes ces itérations demandent de faire appel à des développeurs et que chacune demande des mises en production, on parle ici de plusieurs mois voire de plusieurs années, si le management ou l’équipe n’as pas encore perdu patience. Toutefois, si nous pouvons réaliser 10 à 15 itérations pendant une semaine d’exploration, le temps nécessaire à proposer la bonne solution (à savoir à la fois développer le bon produit et bien le développer) à nos clients passera de quelques mois à quelques jours.

J’aimerais aussi vous faire une autre remarque que le modèle conceptuel d’exploration/livraison illustré sur le graphique ci-dessus (au risque de trop vous en dire d’un coup, mais je pense que celle-ci est importante).

Une fois que nous connaissons le produit que nous avons besoin de développer, les développeurs vont devoir non seulement développer et livrer ce produit, mais ils vont devoir le faire de façon scalable, performante, sûre et maintenable et dans beaucoup des entreprises avec qui j’ai travaillé, qui sont déjà d’une taille considérable, ce n’est pas si simple. Et ce n’est certainement pas le genre de chose qu’on va vouloir reconsidérer nonchalamment à chaque itération.

Les ingénieurs vont vraiment devoir savoir qu’ils doivent construire une voiture avant de proposer une architecture qui réponde au besoin et il se peut qu’ils choisissent d’implémenter cette solution avec une stratégie de livraison différente de celle utilisée pendant la phase d’apprentissage rapide.

Par exemple, ils vont peut-être finir par d’abord tester un ensemble de micro-services (les pneus et le moteur de la voiture pour vous donner une image grossière) et s’attaquer à l’expérience de la partie client plus tard. Nous cherchons toujours à éviter la livraison façon Big Bang, mais encore une fois c’est une décision qui revient aux ingénieurs et qui n’a pas besoin d’être une stratégie de livraison optimisée pour l’apprentissage —la phase exploratoire est là pour ça.

Il y a en outre un deuxième effet important à faire de l’exploration de produit de la sorte. Comme on s’attaque aux risques dès la phase exploratoire et qu’on a plus de certitudes sur ce qu’on doit livrer, ce travail de livraison progresse plus vite qu’il ne le ferait autrement.

Vous avez peut-être déjà entendu ce vieux dicton “un problème bien énoncé est un problème à moitié résolu”. Quand les développeurs peuvent jouer avec un prototype crée pendant la phase exploratoire, poser des questions et identifier les cas d’utilisation manquants, alors si on décide qu’on doit vraiment bâtir une implémentation robuste de cette solution, ce travail de mise en production pourra être effectué plus rapidement, et ce sans toutes les circonvolutions et les délais si coûteux en temps en en argent.

L’article d’Henrik explique très bien les valeurs de base de l’agilité — et ce n’est pas rien car beaucoup d’équipes n’ont toujours pas compris ces valeurs. Ce que j’essaie d’expliquer ici c’est comment les équipes produit multi-disciplinaires expérimentées ont dépassé le Lean et l’Agile pour attaquer les risques de front, résoudre les problèmes difficiles pour leurs clients et leur business grâce à la collaboration entre le produit, le design et l’ingénierie, et pour porter leur attention sur les résultats commerciaux et non pas la simple mise en production de fonctionnalités.

Merci à Jeff Patton pour ces commentaires encourageants pendant la rédaction de cet article et à Henrik pour toutes ses contributions à notre industrie.

Le coût d’opportunité est le manque à gagner potentiel entre deux investissements ou deux types de financement. Le coût d’opportunité mesure la perte des biens auxquels on renonce en affectant les ressources disponibles à un autre usage. Le coût d’opportunité d’un investissement est le coût de la non-réalisation d’un investissement. Ce critère est l’un de ceux utilisés dans les choix d’investissement. Le coût d’opportunité sert ainsi à faire des arbitrages entre placements. (source) ↩

Non, les design systems ne feront pas le travail des designers

2018-05-21T00:00:00+02:00

Un débat anime en ce moment la communauté des designers numériques : les design systems vont-ils sonner leur disparition ou au contraire leur permettre de mieux faire leur travail ? Cinq designers de la Silicon Valley penchent plutôt pour le deuxième scénario alors qu’Adam Michela, le créateur des design systems de Airbnb et Facebook, pense plutôt qu’ils vont prendre la place des designers.

Le design numérique est en train de vivre sa plus grande révolution culturelle depuis l’iPhone d’Apple, avec l’émergence des design systems.

À l’heure où les entreprises mettent en place de nouveaux procédés pour designer à grande échelle, on n’imagine pas à quel point ces systèmes vont impacter l’organisation des structures. Ils pourraient bien changer radicalement la manière de concevoir des produits numériques - à minima, nous éviter le travail de base de manipulation de pixels.

Cela nous amène à nous poser une question importante : est-ce que les design systems vont remplacer les designers, de la même manière que les machines automatiques ont remplacé les ouvriers dans les usines ? C’est un sujet sensible — une possibilité que personne ne veut considérer — mais c’est quelque chose que l’industrie doit regarder en face alors que ces systèmes sont de plus en plus proéminents.

Cinq perspectives

Nous avons parlé à cinq figures importantes du design et recueilli leur point de vue sur comment les design systems pourraient changer - ou supprimer - le rôle du designer.

Notre panel d’experts en faveur du “non” :

Diana Mounter Responsable de l’équipe Design Systems chez GitHub

Ben Wilkins Design Technologist, Airbnb

Craig Wattrus Designer Produit, Braintree

Mikael Keussen Designer, Lever

Rasmus Andersson Designer, Figma

Malgré de grandes différences de parcours du consommateur à l’entreprise, tous ceux avec qui nous avons parlé sont persuadés que les design systems ne voleront pas le travail des designers… où du moins l’espèrent-ils.

Je suis intimement persuadé que des personnes vont se dire, “Oh maintenant que vous avons un design system, nous n’avons donc plus besoin d’autant de designers” nous dit Ben Wilkins, design technologist chez Airbnb. “C’est une mauvaise conclusion. Elles n’en tirent pas la bonne leçon.”

La précieuse ressource

De nos jours on s’arrache les designers numériques. Il n’y a simplement pas assez de designers qui possèdent l’habilité et l’expérience dont l’industrie numérique a besoin : sensibilité esthétique, résolution de problèmes, pensée critique, compétences techniques (et souvent une expérience de programmation ou d’analyse de données), etc. C’est une interdisciplinarité unique — un savant mélange d’art, de mathématiques et de psychologie - et contrairement à l’informatique, le design numérique n’a pas de programmes universitaires dédiés pour apprendre aux gens. La plupart des personnes qui finissent par designer dans les entreprises de Silicon Valley le font par accident.

Le manque de designers formés ne posait pas de problèmes dans les années 90 et au début des années 2000, à une époque où la tech était encore dans son âge d’or. Mais avec la portée grandissante d’Internet et l’arrivée du mobile, les entreprises se sont lancées dans une quête éperdue de pouvoir du design. Ce qui a amené une grande pénurie de bons designers — les designers sont devenus une ressource aussi précieuse que le pétrole et l’eau dans la Silicon Valley au même titre que les célébrités de l’ingénierie.

Quand de nouveaux designers sont disponibles, ce n’est jamais, “OK, allons faire un tour” dit Craig Wattrus, designer produit, chez Braintree. Mais c’est toujours, “À quels nouveaux problèmes pouvons-nous nous attaquer maintenant ?”

C’est en partie pour cette raison que les équipes ont besoin de design systems en premier lieu — pour que le travail de conception fonctionne à grande échelle et qu’il ne ralentisse pas la croissance. Avec des procédés en place — conventions sur des composants comme les barres de navigation et les menus déroulants, les façons de les mettre à jour automatiquement, des accords sur quand créer de nouveaux éléments, des conseils précis sur comment tout cela s’articule — le poids de la création d’interface est enlevé des épaules des designers.

Maintenant qu’elle n’est plus requise pour réinventer la roue (ou une icône), l’attention des designers peut se pencher sur divers types de défis. “Je veux que les designers de GitHub se demandent comment rendre plus simple la gestion de projet pour les développeurs, les responsables produit et les designers dans les entreprises ?” dit Diana Mounter, en charge de l’équipe design systems chez GitHub. Et non, “Quelle apparence devrait avoir ce bouton ? Comment dois-je le coder ?”

C’est le rêve : que les design systems donnent aux designers la possibilité de se concentrer sur ce qui compte: la vue d’ensemble. Après tout, très peu de designers rejoignent une entreprise pour tourner à vide et cracher indéfiniment des wireframes.

Avec des systèmes en place, les designers espèrent pouvoir :

Passer plus de temps à faire des recherches, des interviews et des études d’utilisateurs.
Parler plus souvent aux ingénieurs pour comprendre leurs contraintes et adoucir le processus de transfert.
Explorer et tester plus de pistes et d’options pour de nouveaux produits ou de nouvelles fonctionnalités.
Penser les nouvelles fonctionnalités dans leur ensemble, savoir comment les changements vont se répercuter sur l’expérience générale d’utilisation.
Maintenir et faire évoluer le design system lui-même, au fur et à mesure que de nouveaux besoins apparaissent.
Parvenir à une cohérence tout au long de l’expérience d’utilisation.
Aller plus vite…sur tout.

C’est une vision agréable du futur, qui n’est pas sans précédent. Au cours des soixante dernières années, les progrès dans l’ingénierie ont permis aux gens de se focaliser sur l’avancement technologique, au lieu de devoir effectuer de la programmation de bas-niveau.

Par exemple dans les années 50, les ingénieurs codaient directement sur le matériel informatique, ils écrivaient des instructions machines pour le processeur. Plus tard, des développements et des langages comme l’assembleur ont permis d’accélérer le processus. “Aujourd’hui on pourrait poser la question : est-ce que tous les ingénieurs informatiques savent comment marche la mémoire ?” a dit Rasmus Andersson, designer chez Figma designer. “À l’époque, tout le monde devait le savoir.”

L’outillage et les nouveaux frameworks ont fait faire un bon en avant à l’industrie — et ont crée plus d’emplois en informatique qu’ils n’en ont supprimé.

Diana de chez GitHub se veut optimiste et espère qu’il en sera de même pour le design. “ Si nous arrivons à résoudre ce problème maintenant avec les design systems”, cela va nous mettre de nous attaquer à de nouveaux défis de conception dans le futur”.

Mais tout le monde partagera-t-il cette vision ? “Peut-être que chez Facebook, vous n’aurez pas besoin de centaines de designers si vous avez un système mieux établi” a confié Mikael de chez Lever. “Mais c’est difficile à dire car les designers utilisent de plus en plus de données, définissent de plus en plus d’expériences, font du AB testing, et ont une vision de l’expérience de plus en plus globale.”

Malheureusement, dans le secteur de la technologie, tout le monde ne comprend pas la vraie valeur de l’ensemble des compétences d’un(e) designer. Certains la réduise à l’art de la finition de peinture. Comment pouvons nous espérer que les décideurs, une fois qu’on leur aura montré un design system avec des composants prêts à l’emploi, comprendront encore qu’il y a besoin de designers ?

Quand j’ai évoqué cette possibilité avec les designers avec qui j’ai parlé, ils paraissaient tous un petit peu nerveux. Certains ont admis que ce serait une éventualité, surtout dans les plus grandes entreprises. D’autres pensent que ça n’arrivera pas. De toutes les façons, ils sont tous farouchement opposé à un monde dans lequel les design systems remplaceraient les designers.

“Si vous prenez les Lego par exemple, les Lego sont un design system” dit Ben de Airbnb. “Ce n’est pas parce que le système est en place que nous n’avez pas besoin de quelqu’un pour le concevoir.”

C’est à ceux qui créent des design systems d’aider à dessiner cette vision du futur. Soit à travers des sessions d’informations ou des conversations informelles, les designers doivent parler des manières dont les design systems vont bénéficier à tous — y compris aux designers eux-mêmes.

Bien entendu, l’équipe marketing sera à même de concevoir ses propres campagnes d’emailings, les commerciaux pourront générer leurs slides de présentation, les managers produit et les exécutifs pourront réaliser des maquettes haute-fidélité de leurs idées, les ingénieurs pourront jouer avec les composants pour comprendre les changements qu’ils doivent implémenter dans le code. Mais même avec toute cette autonomie, au final il y aura besoin d’une équipe qui vérifie et qui supervise toutes ces briques changeantes pour assurer une cohérence — et c’est là que les designers ont un rôle à jouer.

“Les design systems ne sont pas comme des véhicules autonomes qui remplacent le conducteur,” dit Craig de Braintree. “Il faut les voir plus comme une conduite assistée.”

Oui, les design systems remplaceront des designers

2018-05-21T00:00:00+02:00

Adam Michela, un des principaux instigateurs des design systems chez Facebook et AirBnb, pense que les design systems auront un profond impact non seulement sur la façon de travailler des équipes et donc sur le rôle des designers, mais aussi sur la façon qu’auront les entreprises numériques de concevoir leurs produits.

Les design systems présentent leur lot de défis stratégiques — comment démarrer, comment les adapter et les maintenir, etc. Mais la question la plus importante reste celle de la culture : quid des designers numériques dont une partie du travail est de plus en plus automatisée ?

Nous avons parlé avec quelques designers qui sont persuadés que les design systems ne feront pas leurs jobs. De tous ceux que nous avons interviewé, un seul est un fervent défenseur de la thèse opposée : Adam Michela, qui cumule les rôles de designer et d’investisseur.

Adam — beaucoup plus connu sous son pseudo Twitter @soopa — n’est pas quelqu’un que vous pouvez exclure de cette conversation. Il est en effet le créateur des design systems de Facebook et d’Airbnb, deux des exemples visibles les plus significatifs au cœur la tendance actuelle des design systems.

Nous lui avons posé quelques questions sur la direction qu’était en train de prendre le monde du design numérique. Nous avons raccourci et édité le contenu pour plus de clarté et de brièveté.

Allons directement au cœur du sujet. Penses-tu que les design systems vont supprimer des postes de designers ?

Oui, les design systems vont remplacer beaucoup de jobs de design tel que nous les connaissons actuellement — c’est même déjà le cas.

Les patrons de développement d’interface, les procédés et les outils sont des parties interchangeables des lignes d’assemblage d’une usine — des outils de productivité industrielle qui permettent à moins de personnes de faire le même produit que précédemment.

Tu es la seule personne que j’ai interviewé qui tienne ce discours.

L’adoption rapide des design systems peut représenter une réalité inconfortable pour ceux qui ont embrassé le métier de designer de logiciel et qui le voit comme un travail d’artisan. Cette dissonance est surtout manifeste quand vous parlez à des diplômés fraîchement sortis des écoles d’art : “On m’a appris à devenir un artiste, et maintenant on me demande d’éviter l’expression artistique ?”

Lorsque le design visuel et d’interface est standardisé, le travail de production de design devient un des plus abondants.

Mais la plupart des designers te diront que leur vraie compétence ce n’est pas de déplacer des pixels - c’est de résoudre des problèmes, c’est-à-dire d’avoir une approche systémique et empathique pour construire une expérience d’utilisation.

C’est vrai que beaucoup de designers savent résoudre des problèmes et que leurs compétences vont bien au-delà de leur capacité à utiliser des outils comme Figma ou Sketch. Mais beaucoup d’autres disciplines dans ces organisations technologiques modernes savent aussi raisonner de cette manière. Ce qui distingue souvent un designer c’est son aptitude à utiliser des outils visuels et sa passion pour la création d’artéfacts visuels. C’est le dilemme des designers : ce qui les motive et souvent les distingue c’est un artisanat qui n’est pas nécessaire en quantité dans les travaux à grande échelle.

Beaucoup des designers d’aujourd’hui ne sont pas préparés à ça et ne veulent pas forcément des nouvelles demandes liées à leur rôle.

Donc tu es en train de dire que les jobs de designers d’interface vont complètement disparaître ?

Il y aura toujours besoin de talent artistique, mais ce sera un besoin situé plus en amont et en quantité beaucoup moins importante pour les entreprises. Prenons l’exemple de l’industrie automobile : le designer de véhicule existe encore et c’est souvent un artisan capable de dessiner ou de modeler de l’argile. Mais dans cette industrie, les postes de designer en relation avec la production sont très limités. Cela sera aussi vrai dans la technologie.

Beaucoup de designers actuels doivent assembler des composants pré-conçus — une tâche qui sera de plus en plus automatisée. Ils vont devoir gagner des compétences plus génériques afin de répondre à des fonctions plus élevées dans les entreprises. Les responsables produit d’aujourd’hui sont peut-être les designer produit de demain.

J’ai l’impression que tu as les atouts dans ton jeu dans ce débat, puisque tu as participé activement à l’émergence des premiers vrais design systems chez AirBnb et Facebook. Tu peux nous parler de cette expérience ?

Il y avait 18 designers quand j’ai rejoins Facebook. Lorsque nous avons commencé à travailler sur le design system actuel de Facebook un an plus tard, il y en avait plus de 40, mais le département d’ingénierie produit était fort de 1000 personnes et le management produit approchait les 200. L’entreprise souffrait d’une croissance lente du département design.

Nous avons remédié à cela en assouplissant nos critères de recrutement, en construisant des outils et des procédés qui réduisaient le besoin pour les nouvelles recrues d’avoir des compétences hyper-spécialisées tout en assurant une production de haute qualité. C’est l’idée derrière les design systems modernes.

Mais il y a beaucoup, beaucoup plus de designers maintenant chez Facebook qu’avant. J’ai entendu des rumeurs comme quoi le but était d’en recruter plus de 800. En quoi cela s’articule-t-il avec ton discours ?

Il faut bien avoir ces deux réalités en tête :

Nous sommes toujours en phase d’innovation sur les design systems. Ils n’ont pas encore atteint leur plein potentiel. Quand de jeunes entreprises vont implémenter et améliorer les design systems, elles vont changer fondamentalement la façon de gérer et de faire croître leur organisation.
Quand j’y étais, Facebook était effectivement encore un business et un seul produit. Maintenant c’est devenu plusieurs business et plusieurs produits indépendants. Même chose chez Airbnb. Les design systems permettent de développer des produits plus rapidement, et permettent par la même occasion à ces entreprises de développer plus de produits. En valeur absolue il y a plus de designers dans ces entreprises, mais la nature de leur mission a changé, et il y a besoin de moins de designers par produit.

Bon — ça a l’air plutôt une bonne nouvelle, non ?

Oui ! Les design systems sont une évolution incroyablement positive de l’industrie technologique. Ils permettent à davantage de personnes de contribuer à la création d’un produit sans avoir besoin d’être un artiste ou de maîtriser un art. Une industrie plus productive et plus accessible va permettre à plus d’entreprises de produire plus de produits de meilleure qualité et à moindre coût.

C’est mieux pour tout le monde… sauf pour l’artisan.

Comment faire de votre empathie une force ?

2018-03-05T18:14:07+01:00

Refouler ses émotions en permanence, ne pas se sentir écouté ou compris, c’est très fréquent. C’est rarement tenable sur le long terme, l’être humain est une créature hautement émotionnelle. Apprendre à écouter l’autre, savoir écouter ses propres émotions, autant de conseils qui pourraient s’avérer bien utiles pour améliorer vos rapports personnels et professionnels.

Quand j’étais plus jeune, on me disait tout le temps que j’étais « celle qui savait écouter ». Être une personne très sensible signifie avoir le don de ressentir les émotions des autres, même lorsqu’ils sont silencieux. J’ai petit à petit compris quel pouvoir l’empathie pouvait avoir. Maintenant que je fais du coaching et du social, cela figure même en bonne place sur ma fiche de poste.

Mais qu’est-ce que l’empathie au juste ?

Dans un monde complexe, où tout le monde est très occupé et très stressé, l’empathie est le ciment des relations humaines. C’est la faculté de pouvoir détecter les émotions des autres et de comprendre leur point de vue. Lorsque nous nous sentons acceptés et reconnus, cela crée de la confiance, guérit et conduit à davantage de bonheur.

L’empathie n’est pas non plus exclusivement réservée à nos vies personnelles. Vous en aurez besoin pour réconforter un collègue en deuil, faire adhérer les gens à vos idées ou apaiser les tensions avec votre supérieur par exemple.

Nul besoin d’avoir suivi une formation pour faire preuve d’une véritable empathie. Inspirez-vous de ces 8 leçons apprises lors mes centaines de séances de coaching de clients pour devenir un ninja de l’empathie et constater une nette amélioration dans vos relations dès à présent :

Soyez pleinement présent

Avant de voir mes clients, je crée un environnement où je me sens à l’aise et où je peux me concentrer pleinement. Pour rentrer dans cette zone empathique, vous devez faire de même.

Éteignez votre téléphone. Désactivez vos notifications. Respectez cette personne et donnez-lui votre entière attention. Ne voudriez-vous qu’on en fasse de même pour vous ?

Maîtrisez l’art de l’écoute active

En tant que coach, il est de mon devoir d’aider à surmonter des obstacles, de manière à pouvoir agir pour atteindre leurs objectifs. Cela revient à commencer par s’assurer que je comprenne bien leurs priorités et leurs envies.

De la même manière, dans n’importe quelle relation, l’empathie demande d’écouter sans juger et de laisser vos à priori de côté. Vous allez plutôt vouloir utiliser vos capacités d’écoute active pour arriver à mieux connaître la personne, cela inclut :

Refléter « Ce que je comprends c’est que tu dis que… » ou « Selon moi on dirait que… »
Confirmer Sourire, acquiescer ou utiliser de brèves affirmations verbales comme « Je vois… » ou « mmmhmm »
Encourager « Et ensuite ? »

Adaptez ces réponses avec votre style à vous de manière à ce que ça sonne vrai. Faites-les vôtres.

Passez en communication non-verbale

La communication ce n’est pas juste des mots. Si vous remarquez qu’une personne se crispe ou détache soudain son regard, ce sont des signaux forts qui indiquent que vous pouvez utiliser l’empathie pour établir un contact.

Quand je sens qu’un client réagit fortement, que la colère ou les larmes montent, je laisse de côté notre objectif typique orienté action et j’en profite pour explorer ce qui arrive. Plutôt que de les laisser ignorer l’émotion qui vient, je leur demande gentiment de décrire ce qu’ils ressentent à ce moment-là.

Cela leur permet de partager ouvertement le stress qu’ils ressentent, ils savent qu’il ne seront ni jugés ni critiqués. Se laisser librement envahir par l’émotion peut être un moyen de résoudre efficacement un problème.

Utilisez des temps de pause

Nous ne pensons pas à mal quand nous intervenons pour finir la phrase d’une personne, que nous lui donnons un conseil ou que nous l’interrompons. Dès aujourd’hui, lors d’une conversation, attendez cinq secondes avant de répondre. C’est pénible mais vous serez surpris par l’efficacité de s’exercer à ne presque rien dire.

Apprendre à être à l’aise avec le silence est sûrement le compétence la plus précieuse que j’ai apprise pour établir rapidement un rapport et une connexion.

Remplacez les conseils par de la curiosité

Plutôt que de donner votre opinion, posez des questions pour mieux comprendre le point de vue de la personne en face de vous, comme par exemple :

Dans quel état cela vous met-il ?
Pouvez-vous m’en dire plus ?
Qu’entendez-vous par là ?
Qu’est-ce qui pourrait être utile ?
Qu’en faites-vous?

Dites « nous » plutôt que « je »

Quand des gens viennent me voir, ils se sentent confus et isolés dans leurs luttes. Pour leur montrer qu’ils ne sont pas tous seuls, j’évoque rapidement comment nous allons relever ses défis ensemble, avec l’équipe — en utilisant toujours le « nous » — de manière à ce qu’ils reprennent confiance et qu’ils se sentent soutenus.

La recherche démontre que modifier votre façon de parler est un premier pas vers l’adoption d’une attitude empathique. Les personnes qui s’expriment davantage à la seconde personne savent mieux interpréter les pensées, les sentiments et les comportements de leurs semblables — l’essence même de l’empathie.

Quand vous êtes vraiment connecté avec une personne, créez un lien en parlant de vos objectifs communs. Par exemple : « OK, parlons de ce que nous allons ensuite faire pour résoudre ce problème » ou « nous allons y arriver ».

Imaginez leur point de vue

J’essaie également de me mettre à la place des gens : à quelles peurs font-ils face ? Quel est le changement positif dont ils rêvent ?

Prêtez-vous à cet exercice (en silence) en vous entraînant à deviner le point de vue de cette personne. Surtout si c’est une personne difficile à gérer, il est important de partir du principe que son but est louable. Donnez aux personnes le bénéfice du doute, qu’elles partent avec de bonnes et non de mauvaises intentions.

Ce changement d’état d’esprit peut grandement améliorer votre humeur et vous aider à rester dans un état empathique.

Travaillez sur votre propre lecture émotionnelle

Affûtez votre vocabulaire émotionel de manière à pouvoir mieux discerner et nommer ces émotions chez les autres.

Même s’il y a des moments, où je suis moins compatissante que je le voudrais, comme tout le monde (je deviens vite irritable quand j’ai très faim par exemple, j’ai vraiment du mal à me contrôler), lorsque cela se produit, cela veut dire que je dois d’abord songer à prendre soin de moi.

Assurez-vous également de vous occuper de vos propres émotions. Vous ne pouvez pas piocher de l’empathie si vos réserves sont vides.

Pourquoi les développeurs web doivent se soucier de l’interactivité

2017-12-21T00:00:00+01:00

Difficile de se passer de JavaScript dans les interfaces modernes de nos sites web, mais ajouter du code JavaScript dans une page ne doit pas forcément signifier dégrader l’expérience de l’utilisateur : l’empêcher de naviguer rapidement entre les pages et effectuer les tâches qu’il souhaite réaliser sans qu’il ait à attendre que la page réagisse à ses actions. Philipp Walton est ingénieur chez Google et a regroupé dans cet article tout ce que les développeurs web devraient savoir de la gestion de l’interactivité des interfaces sur le web. Cela devrait aider pas mal de développeurs JavaScript à rendre le web plus utilisable pour tous.

Si vous avez déjà parcouru le web sur votre téléphone, vous avez forcément dû expérimenter un jour ou l’autre ce genre de situation :

Vous ouvrez une page web et vous cliquez quelque part mais rien ne se passe.
Vous cliquez à nouveau dessus — mais toujours rien.
Vous cliquez ailleurs — non plus, toujours rien.

C’est une expérience assez frustrante en soi, mais souvent ça ne s’arrête pas là. Généralement, voici ce qui se passe ensuite :

Vous commencez à cliquer un peu partout pour vous assurer que quelque chose répond encore, que votre téléphone est bien en état de marche — et soudain une série d’actions s’exécutent en même temps, vous vous retrouvez sur une page complètement différente et vous n’avez aucune idée de la façon dont vous êtes arrivé là.

Si ça vous rappelle quelque chose, c’est que vous avez fait l’expérience de l’opposé de l’interactivité sur le web. Mais qu’entend-t-on exactement par “interactivité” ?

J’imagine que la majorité des personnes qui lit cet article sait probablement ce que le mot “interactivité” signifie en règle générale. Le problème c’est que, depuis quelques années, ce mot a revêtu une nouvelle signification technique (comme par exemple dans la métrique qui mesure le temps qui s’écoule avant de pouvoir interagir avec la page ou TTI en anglais) mais malheureusement les spécificités de cette signification sont rarement explicitées.

C’est pour cela que dans cet article, nous allons voir en détail ce que veut dire interactivité sur le web. Après tout, c’est une des choses les plus importantes dont les développeurs devraient se soucier.

Interactivité sur le web

Pour qu’une page soit interactive, elle doit pouvoir répondre rapidement à une action de l’utilisateur. Que ce soit quand une personne clique sur un lien, tapote sur un composant d’interface personnalisé ou fasse simplement défiler du contenu, si la page peut répondre rapidement (d’une façon qui paraisse plus ou moins “instantanée” pour la personne), alors on peut dire que la page est interactive.

Je pense que généralement la plupart des développeurs comprennent ce principe. Mais je pense que la plupart ne comprennent pas toujours les raisons pour lesquelles une page n’est pas interactive, et c’est là un problème bien plus grave.

Il y a essentiellement seulement deux raisons pour lesquelles une page ne serait pas en mesure de répondre rapidement à l’action d’un utilisateur (si l’on excepte les erreurs JS et les autres anomalies manifestes) :

la page n’a pas fini de charger le code JavaScript nécessaire pour contrôler son DOM ;
le processus principal du navigateur est occupé à faire autre chose.

La première raison est importante et a déjà été débattue par beaucoup de gens dans la communauté, je ne vois pas grand intérêt à là répéter ici (cette vidéo de 5 minutes résume très bien la problématique si elle vous intéresse).

La deuxième raison est complexe et souvent négligée, et c’est principalement ce point que je vais développer ici.

Quand le processus principal du navigateur est déjà occupé

Bien qu’on entende souvent les gens dire que les navigateurs savent faire tourner plusieurs processus en parallèle (ce qui est vrai jusqu’à un certain point), la réalité est qu’une grande partie des tâches d’un navigateur doit être lancée dans le même processus (souvent appelé “processus principal” ou “processus de l’interface graphique”).

Sans trop nous plonger dans les rouages internes des navigateurs (tels que les tâches, les files d’attente de tâches, et la boucle évènementielle¹), l’important est de comprendre qu’il y a beaucoup de situations où le navigateur veut exécuter du code (comme déclencher un évènement en réponse à un clic de l’utilisateur), mais qu’il ne peut pas car il doit attendre la fin de l’exécution d’une autre fonction. On dit alors que le processus principal est “occupé” ou “bloqué”.

Le meilleur moyen de le montrer c’est encore à l’aide d’une démo. Jetez un coup d’œil à ce bout de code qui exécute une boucle while en continu pendant 10 secondes.

function blockMainThreadUntil(time) {
  while (performance.now() < time) {
    // Do nothing...
  }
}

blockMainThreadUntil(performance.now() + 10000);

Pendant l’exécution de de code, aucun autre code ne peut être exécuté par le processus principal. Cela signifie qu’un utilisateur ne peut pas :

cliquer sur un lien,
sélectionner un texte,
cliquer dans une case à cocher,
regarder un GIF animé,
taper dans une balise <input> ou <textarea>.

Avant de vous faire une démo, je tiens à prendre un moment pour dire à quel point cette expérience est mauvaise. Quand le code précédent est en train de s’exécuter, il ne bloque pas seulement l’exécution d’un autre code JavaScript, il bloque toutes les tâches du processus principal et cela inclus les interactions dites natives dont on ne pense pas forcément qu’elles puissent être affectées par du code écrit par un développeur.

En fait, même des interactions comme le défilement (qui sont généralement gérées dans un processus distinct) peuvent parfois être affectées lorsque le processus principal est occupé (par exemple si un écouteur d’évènement comme wheel, touchstart ou touchmove a été ajouté à la page)².

Pour voir un processus principal bloqué en action, cliquez sur le bouton ci-dessous (qui va ajouter un écouteur d’évènement wheel et touchstart et exécuter la boucle while précédemment vue), puis essayez de sélectionner du texte, de cliquer sur un lien ou de faire défiler la page. Vous remarquerez également que l’animation GIF est stoppée :

Element	Exemple
`<img>`
`<a>`	https://example.com
`<input>`	Cochez moi

Attention ! Vous pourriez vous retrouver soudainement sur une nouvelle page une fois le processus principal débloqué !

Ce qui bloque le processus principal

Vous pourriez penser: OK, mais mon code n’exécute pas une boucle while pendant 10 secondes; ai-je vraiment besoin de me préoccuper de cela ?

Malheureusement le réponse est oui. Il est beaucoup plus simple pour des pages de bloquer le processus principal qu’on pourrait le penser. En réalité, le simple fait de charger du JavaScript va bloquer le processus principal pendant que le navigateur analyse et compile le code.³

Mon collègue Addy Osmani a réalisé une étude sur plus de 6000 sites web développés à l’aide de frameworks web populaires et a constaté qu’en moyenne ils bloquent le processus principal pendant 4,4 secondes rien qu’en parcourant et en compilant le code JavaScript. Ce sont 4,4 secondes pendant lesquelles les gens ne peuvent pas cliquer sur un lien ou sélectionner du texte !

En plus de l’analyse et de la compilation, exécuter du JavaScript bloque aussi le processus principal. Chaque fonction JavaScript exécutée dans votre page va bloquer le processus principal pendant un certain temps. Bien que les fonctions JavaScript aient tendance à être petites et à s’exécuter aussi rapidement, plus vous lancez de fonctions à la fois, plus vous aurez de chance qu’elles viennent s’ajouter à quelque chose qui sera remarqué par l’utilisateur.

C’est particulièrement vrai si vous utilisez un framework web ou une bibliothèque de DOM virtuel qui gère un nouveau rendu de composant après un changement d’état. Beaucoup de ces bibliothèques définissent des méthodes de cycle de vie d’un composant qui sont toutes lancées de manière synchrone à chaque fois qu’il y a un changement. Pour une application qui embarque beaucoup de composants, cela peut facilement représenter des milliers d’appels de fonction.

Un point important à bien comprendre, c’est que ce n’est pas nécessairement la quantité de code que vous allez lancer qui compte, c’est la manière dont vous le lancez.

Par exemple, si vous avez 1000 fonctions qui prennent chacunes 1 ms à se lancer et que vous les lancez de manière séquentielle dans la même pile d’appel, elles vont bloquer le processus principal pendant 1 seconde. Mais si vous découpez l’exécution de ces fonctions en plusieurs tâches distinctes et asynchrones (ou que vous utilisez quand c’est possible requestIdleCallback), cela prendra peut-être plus de temps mais ça ne bloquera pas le processus principal. Le navigateur sera capable d’interagir entre les appels et de répondre aux entrées utilisateur.

Cette stratégie est parfaitement employée dans les récents changements architecturaux de React (alias fiber). Pour citer le billet de publication du billet annonçant la sortie de React 16:

Peut-être que l’une des choses les plus passionnantes sur lesquelles nous travaillons est le rendu asynchrone — une stratégie pour programmer de manière coopérative le travail de rendu en laissant périodiquement l’exécution au navigateur. Résultat, grâce au rendu asynchrone, les applications sont plus réactives puisque React prend soin d’éviter de bloquer le processus principal.

Enfin, je m’en voudrais de ne pas mentionner ce qui est peut-être la plus grande cause de non-interactivité sur le web : les publicités et les widgets issus de tierces parties — qui exécutent souvent une quantité bien trop importante de code et accèdent fréquemment aux propriétés du document principal, affectant ainsi des tâches supplémentaires au processus principal.

On retrouve généralement ces publicités et ces widgets issus de tierces parties sur des sites de contenus plutôt que sur des sites “applicatifs”, ce qui soulève un autre sujet important…

Les sites applicatifs face aux sites de contenus

J’entends beaucoup de gens dire des choses comme : je m’occupe d’un site de contenus, pas d’une application, donc je n’ai pas vraiment besoin de me soucier de l’interactivité.

Mais c’est faux ! Comme je l’ai déjà dit plus haut, quand vous bloquez le processus principal vous empêchez les utilisateurs de cliquer sur des liens ou de sélectionner du texte ; et dans certains cas vous pouvez même les empêcher de faire défiler la page ! Ce sont des choses dont doivent se préoccuper les sites de contenus.

Comment savoir si vous avez un problème d’interaction

Le problème délicat avec l’interactivité c’est qu’une même page peut très bien être interactive pour une personne (qui utilise un ordinateur de bureau rapide) mais pas du tout réactive pour une autre (qui utilise un téléphone d’entrée de gamme). En tant que développeurs, il est important de bien comprendre cela et de bien mesurer l’interactivité sur les appareils similaires à ceux utilisés par nos utilisateurs dans la vraie vie.

J’ai dit plus tôt que pour qu’une page soit interactive, elle doit pouvoir répondre rapidement à une action declenchée par un utilisateur. La plupart des définitions actuelles de l’interactivité définissent “rapidement” à l’aide de la recommandation du modèle RAIL au sujet de la réactivité, qui la situe sous les 100 ms.

J’ai aussi mentionné le fait que le première cause de non réactivité d’une interface, ce sont les tâches qui bloquent le processus principal. Afin de vous assurer de répondre à une action utilisateur en moins de 100 ms, il est crucial qu’aucune tâche ne tourne pendant plus de 50 ms. Pour la bonne raison que si l’action se produit pendant une autre tâche et que l’écoute de l’action elle-même (de sa propre tâche) prend également du temps pour s’exécuter, alors ces deux tâches devront se terminer en moins de 100 ms pour que l’interaction paraisse instantanée pour l’utilisateur.

Pour rendre-compte de tout cela, les outils et APIs qui mesurent l’interactivité considéreront qu’une page est interactive si elle ne fait tourner aucune tâche pendant plus de 50 ms sur une période donnée.

Pour savoir si votre propre site est interactif, il y a généralement deux approches :

l’utilisation d’outils ou de simulateurs (soit de la mesure en laboratoire) ;
récupérer les données auprès des vrais utilisateurs (désigné par l’appellation RUM, real-user monitoring, en anglais).

Et il existe également deux façons de penser à l’interactivité et à ses effets :

la probabilité qu’un utilisateur expérimente des pages non interactives ou qui ne répondent pas ;
le fait qu’un utilisateur réel expérimente vraiment une page non interactive ou qui ne répond pas alors qu’il essaie d’interagir avec.

Cela ressemble au problème philosophique de l’arbre qui tombe dans la forêt : Si une page web n’est pas interactive, mais que l’utilisateur n’en fait pas l’expérience, est-ce un problème ?

Ma réponse à cette question est que ce qui compte vraiment au final c’est l’expérience véritablement vécue par les utilisateurs. Toutefois les mesures en laboratoire sont des outils précieux pour prévenir des mauvaises expériences utilisateurs en premier lieu.

En d’autres mots, nous devrions nous soucier de toute ce que nous venons de voir.

Comme outils de mesure, je recommande vivement des outils comme Lighthouse et WebPageTest qui mesurent tous les deux le temps écoulé avant de pouvoir interagir avec la page (TTI) et qui donnent également des informations supplémentaires sur l’interactivité. Par exemple WebPageTest affiche une bannière “la page est interactive” en bas de la vue en cascade. C’est super pratique pour visualiser quand ces mauvaises expériences sont susceptibles de se produire.

Et Lighthouse vous attribue un score pour l’estimation de la latence d’action:

Attention, c’est une “estimation de la latence d’action” car c’est une simulation en laboratoire ; aucun utilisateur n’est vraiment en train d’interagir avec la page, c’est simplement une mesure de probabilité.

Si vous voulez mesurer la véritable latence d’action (faire une mesure réelle de l’utilisation), vous pouvez utiliser des outils d’analyse comme Google Analytics. Par exemple, si votre site a un bouton de menu actionnable, vous pourriez vouloir savoir toutes les fois où cela prend plus de 50 ms pour que le code de l’écouteur d’évènement se lance (à partir du moment où l’utilisateur clique). Le code pour faire ça ressemble à quelque chose comme :

const menuToggleBtn = document.querySelector('#menu-toggle');
menuToggleBtn.addEventListener('click', (event) => {
  // Mettez la logique de votre actionnement du menu ici…

  // Puis mesurez quand cela fini de s'exécuter.
  const latency = performance.now() - event.timeStamp;

  // Si ça prend plus de 50 ms, notez le dans Google Analytics.
  if (latency > 50) {
    // En présupposant que requestIdleCallback(ou un shim) soit supporté.
    requestIdleCallback(() => {
      ga('send', 'event', {
        eventCategory: 'Métriques de PerformanceObserver'
        eventAction: 'input-latency',
        eventLabel: '#menu-toggle:click',
        eventValue: Math.round(latency),
        nonInteraction: true,
      });
    });
  }
});

Ce code tire parti du fait que la méthode event.timeStamp donne le temps écoulé jusqu’à ce que le système d’exploitation reçoive effectivement le clic tandis que performance.now() (appelé dans l’écoute d’un évènement) donne le temps d’exécution réel du code.

Bien qu’il soit possible d’ajouter ce genre de code à tous les boutons de votre site, je vous recommande de commencer par les composants les plus critiques de l’interface utilisateur, puis de continuer avec d’autres composants par la suite.

Vous pouvez aussi mesurer l’interactivité générale avec de vraies données utilisateurs grâce à la nouvelle API Long Tasks qui, en conjonction avec PerformanceObserver, peut vous indiquer toutes les fois où une tâche bloque le processus principal pendant plus de 50 ms. Le code pour pister cela dans Google Analytics ressemble à ça :

// Définition d'un callback qui envoie les données sur les tâches longues à Google Analytics.
function sendLongTaskDataToAnalytics(entryList) {
  // Présuppose que requestIdleCallback (ou un shim) soit disponible.
  requestIdleCallback(() => {
    for (const entry of entryList.getEntries()) {
      ga('send', 'event', {
        eventCategory: 'Métriques de performance',
        eventAction: 'longtask',
        eventValue: Math.round(entry.duration),
        eventLabel: JSON.stringify(entry.attribution),
      });
    }
  });
}

// Crée un objet PerformanceObserver et commence à surveiller les tâches longues.
new PerformanceObserver(sendLongTaskDataToAnalytics).observe({
  entryTypes: ['longtask'],
});

Ces données vous permettront d’avoir connaissance de toutes les fois où le processus principal n’est pas totalement interactif. Elles vous indiqueront également quelles sont les frames du document (via la propriété attribution) qui génèrent les tâches longues, ce qui sera particulièrement utile pour déterminer si des publicités ou des widgets issus de tierces parties contribuent à de mauvaises expériences sur votre site.

Si vous voulez savoir comment traquer les métriques relatives à l’expérience utilisateur dans votre code, j’en ai parlé en détail dans cette présentation lors de Google I/O. Et si vous recherchez des conseils pour traquer proprement les choses avec Google Analytics, vous pouvez vous référer à mon article la configuration Google Analytics que je mets en place sur tous les sites que je développe.

Pourquoi l’interactivité est-t-elle si importante ?

Récemment, un groupe de chercheurs chez Google qui travaillent avec la coalition pour de meilleures pubs a conduit une expérience pour déterminer à quel point les différents types de publicités agacent les gens. Un type de publicité “agaçante” qu’ils ont testé bloquait le processus principal pendant 10 secondes dès que la publicité était visible.

Lorsque l’étude fut terminée et que les résultats furent publiés, cette publicité bloquante se trouvait être parmi les moins agaçantes.

Ne sachant pas pourquoi c’était le cas, quelques chercheurs ont demandé à certains participants pourquoi ils ne trouvaient pas agaçant qu’une publicité les empêche d’interagir avec la page.

La réponse qu’ils reçurent communément fut :

Oh, je n’avais pas compris que c’était la publicité qui ralentissait la page. Je pensais que c’était la page elle-même vu que la plupart des pages web sont lentes sur les téléphones.

Quand j’ai appris ça, ça m’a plutôt attristé, mais cela souligne aussi à quel point le problème est immense. Puisque nous, les développeurs, n’avons pas fait de l’interactivité une priorité, les gens en sont venus à s’attendre à ce que les choses soient lentes par défaut. C’est encore pire quand le coupable est un script de tierce partie et que c’est le site en lui-même qui en est quand même tenu responsable.

Donc c’est à nous développeurs de tenir les tierces parties pour responsables de leur mauvais comportement. C’est de notre responsabilité puisque cela affecte l’expérience de nos clients et leur opinion sur notre plate-forme.

J’entends beaucoup de développeurs web dire des choses comme “Je veux que le Web gagne”, mais la seule manière d’y parvenir c’est si nous faisons tous de l’expérience utilisateur notre priorité, surtout sur les appareils mobiles. Et la première étape est d’aller voir si nos sites n’ont pas un problème de ce côté-là.

Et après ?

J’espère que vous comprenez mieux maintenant ce qu’est l’interactivité et pourquoi elle est si importante. Je vous encourage vivement maintenant à mesurer l’interactivité de vos propres sites sur de vrais appareils et avec des vrais utilisateurs. D’après mon expérience, les développeurs sont généralement surpris par ces résultats.

Enfin, si vous cherchez des manières pour améliorer vos métriques relatives à l’interactivité, les recommandations d’Addy Osmani pour réduire le coût du lancement de JavaScript sont un bon endroit pour commencer. Je vais également dans le sens des recommandations d’Alex Russel pour allouer un budget pour la performance.

Notes

Jake Archibald explique très bien quelques-uns de ces concepts dans son article Tâches, micro-tâches, files d’attente et planifications. Si vous n’aimez pas lire les spécifications, cela peut être une meilleure façon de vous y mettre. ↩
C’est en parti résolu par les écouteurs d’évènement passifs, mais ceux-ci ne sont pas supportés par tous les navigateurs, et parfois un framework ou un script externe vont ajouter des écouteurs sans que vous en ayez forcément conscience. ↩
Dans certains cas le navigateur peut analyser un script dans un processus distinct, mais puisque ce n’est pas le cas dans tous les navigateurs et vu que cela n’est pas toujours vrai, je considère toujours que l’analyse de script peut bloquer le processus principal. ↩

Pourquoi l’agile tourne en rond ?

2017-11-26T00:00:00+01:00

Basecamp, anciennement 37 signals, est la société éditrice du logiciel de gestion de projet bien connu du même nom. Elle est également connue pour avoir initié le développment du framework Ruby on Rails, ainsi que pour la publication de livres majeurs comme Getting Real, Rework et Remote. Basecamp est un PME américaine qui connait un fort succès, elle est reconnue pour son management sain et pragmatique. La direction privilégie une croissance lente mais soutenue et qui favorise l’équilibre et le bien-être de ses salariés. Ryan Singer, en charge de la stratégie produit, partage au travers de cet article ce qui pourrait simplement passer pour du bon sens aux yeux de certains, mais qui est malheureusement encore bien trop souvent oublié par les équipes et la direction qui sous-estiment toujours la difficulté de concevoir un logiciel utile et performant. La confrontation au plus tôt avec le réel, la priorisation, la confiance, la préservation de l’attention, autant de choses essentielles ici appliquées à la lettre alors que ces aspects sont encore bien trop souvent négligés dans les projets numériques.

Pourquoi l’agile ne marche pas et ce que nous faisons différemment

Au départ, l’agile était un ensemble de valeurs. Mais ces valeurs sont subtiles et abstraites. Et lorsque l’agile s’est répandu, ce ne sont pas les valeurs qui se sont propagées mais le travail en cycles. Les cycles c’est simple à expliquer et facile à copier.

Dans notre industrie, les gens pensent donc qu’ils ont arrêté de faire du cycle en V et qu’ils sont passés à l’agile. La vérité, c’est qu’ils sont simplement passés à du cycle en V à haute-fréquence.

L’agile est devenu synonyme de rapidité. Tout le monde veut toujours plus, toujours plus vite. Et une des choses que les équipes ne font jamais assez vite, c’est livrer. Les cycles sont donc devenus des sprints et la vélocité est devenue la métrique de référence.

Mais ce n’est pas la vitesse le vrai problème. Et les cycles à eux-seuls ne vous aideront pas à livrer. Le vrai problème, c’est de ne pas faire ce qu’il faudrait faire, de suivre des spécifications à la lettre et de se laisser distraire.

Déclarer qu’il y a une vraie Méthode Agile™ quelque part dans le passé ou le futur n’est pas non plus d’une grande aide. Quand vos équipes bataillent pour livrer, vous avez besoin d’étapes concrètes que vous pouvez appliquer dès à présent, pas de viser un idéal.

Les cycles c’est chouette. Nous travaillons par itérations chez Basecamp. Mais en plus des cycles, vous avez besoin de trois autres pratiques pour pouvoir livrer à temps et en bonne santé.

Une allocation de ressources réfléchie

Les concepteurs et les développeurs n’avanceront pas dans leurs tâches si leur attention est constamment requise par d’autres personnes. Peu importe que le support ait trouvé une anomalie ou que le commercial ait besoin d’une nouvelle fonctionnalité. Allouer des ressources signifie dédier des ressources. Les personnes responsables de l’attribution du temps et de l’argent pour développer une fonctionnalité doivent également protéger l’équipe afin qu’elle puisse faire ce qui lui est demandé. L’équipe fait une chose et une seule pendant le cycle.

Chez Basecamp, nous démarrons chaque cycle de travail avec une équipe de trois personnes : un designer et deux développeurs. Ils n’ont rien d’autre à faire que ce projet.

Aussi, si vous sentez que vous devez corriger les anomalies dès qu’elles se produisent, alors dédiez des ressources à cela. Si une tension existe entre le service des ventes et le produit, faites un choix pour ce cycle-là. Si vous n’avez pas assez d’effectifs, alternez les cycles entre chaque service.

Notez que seul le management peut être garant de l’attention. Dire à l’équipe de rester concentrée ne fonctionne que si la direction les aide dans cette tâche.

Des exigences modifiables

Lorsqu’une équipe travaille d’après des spécifications précises, le travail par itération ne sert à rien, le but du travail incrémental étant de pouvoir changer de direction en cours de route. Or, définir le projet à l’avance et dans les moindres détails oblige l’équipe à fonctionner en cycle en V. En se devant de respecter ces spécifications à la lettre, les équipes n’ont ainsi aucune marge de manœuvre lorsque quelque chose s’avère plus difficile ou moins important que prévu, ou encore lorsque la réalité contredit le plan établi.

Chez Basecamp, nous démarrons chaque projet avec un concept de base. Nous étudions bien notre stratégie en amont de manière à nous assurer qu’une des versions de notre idée est réalisable dans le temps alloué. Nous savons bien que le concept ne sera pas forcément livré à 100%. Tout ne pourra pas être fait, mais les choses importantes le seront. Si nous ne sommes pas sûrs, nous mettrons autre chose dans le cycle afin de pouvoir revenir ultérieurement sur une fonctionnalité une fois que nous aurons suffisamment affiné son concept.

Pour que vos équipes puissent démarrer de cette manière, vous devez séparer l’essentiel du superflu. Séparer les choses qui sont vraiment primordiales de celles qui sont simplement une idée qu’on a eu pour y parvenir.

Une simple décision relative à l’interface utilisateur peut entrainer une semaine de travail inutile. Un développeur peut batailler avec la refactorisation d’une partie du code JavaScript pour ensuite s’apercevoir que ce point de détail n’était pas vraiment primordial pour le concept envisagé. Le designer avait simplement opté pour cette interaction sans avoir aucune idée du coût engendré.

En pratique, cela veut dire qu’on donne le pouvoir aux équipes de redéfinir le périmètre d’intervention. Certaines choses sont essentielles, d’autres non. L’équipe doit être capable de faire la différence et de faire les choix en fonction. Afin que ceci soit bien clair pour tout le monde, nous donnons aux équipes des ébauches sommaires dessinées à la main en début de cycle et passons plus de temps sur la définition des enjeux de cette fonctionnalité plutôt que sur les détails spécifiques d’implémentation de l’interface.

Une des ébauches de Jason pour l’équipe en charge du développement des groupes de TODO. L’équipe a fini par choisir de ne pas développer les boutons ajouter en dessous de chaque groupe.

Stratégies progressives

Les équipes qui suivent la vélocité et les points de story considèrent le développement comme un travail linéaire. Or, le développement logiciel n’a rien à voir avec le déplacement d’un tas de pierres.

Si c’était le cas, on pourrait compter le nombre de pierres, mesurer le temps nécessaire pour en déplacer une, faire nos calculs et ce serait terminé.

Une tâche qui nécessite de résoudre un problème ressemble plus à une colline. Il y a une phase ascendante dans laquelle on doit comprendre ce qu’il faut faire. Puis arrivé au sommet, on peut voir l’autre versant et le chemin qu’il reste à parcourir.

La phase ascendante est pleine de faux pas, de boucles et d’impasses. C’est là où on se confronte à l’inattendu. Le développeur dit “OK, ça va prendre deux jours” mais ensuite il va toucher au code et la réalité va s’avérer bien plus complexe. Ou bien le designer va dire “cette interaction sera parfaite” et quand il la testera sur un appareil, il se rendra compte que ce n’est pas ce à quoi il s’attendait.

La question la plus importante pour une équipe n’est pas Que reste-t-il à faire ? mais Qu’est-ce qu’on ne sait pas encore ? Avez-vous examiné le problème sous tous les angles ? Avez-vous poussé le concept et vu tout ce qui a besoin d’être modifié ? La seule manière d’en être sûr est de relever ses manches et d’aller se confronter à la réalité des problématiques.

Chez Basecamp, nos équipes partent en quête des recoins inexplorés les plus effrayants et travaillent en priorité dessus. Ce travail en amont nécessite d’adopter des stratégies. Nous les avons évoquées dans Getting Real. Ouvrez votre éditeur de code, concevez quelque chose de fonctionnel, utilisez de vraies données et testez votre concept. Lorsque la fonctionnalité est trop importante pour être déclinée en prototype, sélectionnez les parties les plus importantes et affinez-les.

Les différentes phases du travail en amont et en aval

La phase ascendante, c’est celle où vous prenez connaissance des difficultés et où vous portez des jugements de valeur. C’est à ce moment-là que vous décidez quelles sont les exigences modifiables car vous connaissez les coûts réels et les opportunités dans l’implémentation. Apprendre en amont demande du temps et de la concentration. Ce sont des ressources qui doivent être allouées de manière réfléchie aux équipes.

Nous travaillons de manière informelle depuis de nombreuses années en nous focalisant sur les inconnues et en nous y attaquant en priorité. Nous avons récemment formalisé cela avec le graphique de la colline. Une question que nous nous posons beaucoup ces temps-ci est Où est-ce que cela se situe sur la colline ?.

Voici une capture d’écran de la fonctionnalité du projet de recherche intégrée que nous avons livré en octobre.

D’abord nous avons retravaillé les résultats de recherche, puis nous les avons déplacé dans la navigation.

Voici quelques-unes des étapes du projet sur les groupes de To-Do.

Les trois parties les plus importantes ont passé le sommet en premier.

Fin de la descente

Livrer est l’affaire de tous

Que les équipes travaillent en cycles ou non, ne dit pas tout de l’histoire. Une équipe agile n’ira pas très loin si le management ne protège pas le temps alloué. Et si l’équipe ne peut pas changer les contraintes pendant qu’elle apprend, c’est l’assurance de passer des nuits courtes et de livrer en retard.

Les designers et les développeurs peuvent apprendre les stratégies progressives dans Getting Real afin de gagner en assurance au lieu de se contenter d’espérer en croisant les doigts. La personne qui définit les besoins peut donner aux équipes la marge de manœuvre nécessaire en les délimitant clairement pendant la phase exploratoire. Et les personnes qui allouent les ressources peuvent davantage se responsabiliser pour faire en sorte de maintenir l’attention de leurs équipes sur le projet en cours.

Cela fait 15 ans que nous procédons de la sorte. Nous espérons que le fait de partager quelques-unes de ces techniques vous aidera à en faire de même.

Développer une culture de la sécurité psychologique

2017-08-27T00:00:00+02:00

Il existe des entreprises où l’humain est au centre des préoccupations et il s’avère que cela produit des équipes plus performantes. Certaines startups couronnées de succès ont bien compris l’intérêt de veiller sur leurs employés. Pas en mettant à leur disposition des sodas sucrés, un baby-foot ou une console de jeux, non, en prenant bien soin de créer un cadre de confiance qui aide les salariés à donner le meilleur d’eux-mêmes. John Looney, ingénieur en chef chez Intercom, donne ici quelques conseils pour bâtir une équipe dans laquelle il fait bon évoluer.

illustration : Clay Hickson

Quand je travaillais pour Google en tant qu’ingénieur qualité, j’ai eu la chance de faire le tour du monde avec un groupe appelé “développement d’équipe”. Notre mission était de concevoir et de donner des cours de team-building aux équipes qui souhaitaient travailler ensemble, de façon plus efficace.

Nos découvertes furent publiées plus tard sous le nom de Projet Aristote. Notre plus grande découverte c’est que l’indicateur principal d’une équipe qui réussit n’était pas la fonction, l’ancienneté ou les niveaux de salaire, mais la sécurité psychologique.

Pensez à une équipe avec qui vous travaillez en étroite collaboration. Avec quels points êtes-vous d’accord parmi ces cinq affirmations ?

Si je tente ma chance et que j’échoue, cela sera retenu contre moi.
Notre équipe a un sens de la culture très développé qui rend difficile l’intégration de nouvelles personnes.
Mon équipe met du temps à aider les gens en difficulté.
L’utilisation de mes compétences et de mes talents uniques passe après les objectifs de l’équipe.
Il est pénible d’avoir des conversions honnêtes et ouvertes à propos des problèmes sensibles de l’équipe.

Les équipes qui obtiennent un score élevé à ce genre de questions peuvent être réputées “à risques” : risque d’innover, risque de résoudre un conflit, risque de reconnaître qu’elles ont besoin d’aide. Les équipes à risque peuvent livrer pendant de courtes périodes, du moment qu’elles sont focalisée sur les objectifs et ignorent les problèmes interpersonnels. Mais à la longue, les équipes à risques ne tiendront pas le coup ou seront bien moins performantes car les personnes ne pourront pas introduire du changement.

les équipes à risques ne dureront pas ou seront bien moins performantes car les personnes ne pourront pas introduire du changement.

Mettons en évidence l’impact qu’une équipe à risques peut avoir sur les individus qui la compose à travers le regard d’une nouvelle tête fraîchement diplômée qui a fini dans les meilleurs de sa classe.

Cette diplômée imaginaire, appelons la Karen, a lu un article à propos d’une optimisation qui pourrait réduire le verrouillage bas-niveau des bases de données distribuées et réalise que cela pourrait être appliqué au service pour lequel son équipe travaille. Elle décide de faire des tests, il en ressort un gain de 15% de CPU sur le cluster de test. Dans l’effervescence, elle décide de déployer en production. Comme c’était un changement du fichier de configuration d’une base de données, il n’a pas suivi le processus habituel de revue de code.

Malheureusement, cela a provoqué un verrouillage matériel de la base de données, causant une panne brève mais totale du site web. Heureusement ses collègues plus expérimentés ont vite vu le problème et ont pu annuler le changement en moins de 10 minutes. Comme ils sont professionnels, cet incident a été mentionné lors de la réunion post-mortem hebdomadaire.

“Si je tente ma chance et que j’échoue, cela sera retenu contre moi.”

Lors de la réunion, l’ingénieur en chef fait savoir à tout le monde que provoquer une indisponibilité parce qu’on cherche à faire des petites optimisations était inacceptable. Karen a été qualifiée d’ “irresponsable” devant tout le monde et l’équipe a proposé des solutions pour éviter que cela ne se reproduise. L’ingénieur en chef a rapidement oublié cette histoire. Mais Karen n’a jamais oublié cet échange. Elle n’essaiera plus jamais d’innover sans une permission explicite.

“Notre équipe a un sens de la culture très développé qui rend difficile l’intégration de nouvelles personnes”

L’impact sur Karen a en fait été amplifié car personne ne l’a soutenue. Personne n’a pointé du doigt que le manque de revues de code sur la configuration de la base de donnée a permis ce genre d’erreur. Personne n’a relevé la différence entre souligner un acte irresponsable et traiter quelqu’un d’“irresponsable”. L’équipe était tellement fière de la fiabilité de son système que défendre sa réputation était plus important qu’une personne nouvellement embauchée.

Karen a appris que son équipe et son manager ne la soutenait pas.

“Mon équipe met du temps à aider les gens en difficulté.”

Comme Karen était nouvelle en “production”, elle n’avait pas vraiment été formée à la gestion d’incident, à l’importance de garder une production saine et encore moins au dépannage de systèmes distribués. Comme son équipe était constituée de gens possédant des dizaines d’années d’expérience, ils n’avaient jamais eu besoin de formation ou de documentation pour les nouveaux arrivants. Il n’y avait rien qui indiquait que c’était OK pour une jeune diplômée de passer du temps à acquérir ces compétences.

Karen a développé le syndrome de l’imposteur. Elle n’a pas compris comment elle a réussi à être embauchée et se demande souvent pourquoi elle n’a pas encore été licenciée.

“L’utilisation de mes compétences et de mes talents uniques passe après les objectifs de l’équipe.”

Karen a étudié les algorithmes, les structures de données et l’informatique distribuée. Elle a compris que le système existant n’était pas optimal dans son ensemble et ne pourrait jamais tenir des pics de charge.

L’équipe avait toujours reproché aux clients le dépassement de leurs taux contractuels, ce qui revient à s’en prendre au météorologue pour la pluie qui tombe pendant un barbecue en Irlande.

Karen a proposé un nouveau design, basé sur la technologie qu’elle avait utilisé pendant son stage. Ses collègues étaient peu familiers avec cette nouvelle technologie et l’ont considéré comme trop risquée. Karen a laissé tomber sa proposition sans discuter. Elle voulait écrire du code et construire des systèmes, pas répondre à de vains arguments.

“Il est pénible d’avoir des conversions honnêtes et ouvertes à propos des problèmes sensibles de l’équipe.”

Lorsqu’une importante charge de trafic chez un client a provoqué une indisponibilité de plusieurs heures, le CEO a organisé une réunion avec l’équipe chargée des opérations. Beaucoup de détails furent passés en revue et Karen a expliqué que la conception actuelle ne pourrait jamais faire face à de tels pics, elle a alors mentionné sa solution. L’ingénieur en chef lui a rappelé que sa proposition de design avait déjà était refusée pendant une revue avec l’équipe technique et a promis au CEO qu’ils pouvaient améliorer le design existant.

Karen a discuté de la réunion avec un de ses collègues peu après. Elle a trouvé consternant que l’ingénieur en chef ne se rende pas compte que son système soit la cause première de tous leurs problèmes. Le collègue a haussé les épaules et a fait remarquer qu’ils avaient fourni un très bon service pendant les cinq dernières années écoulées, il n’y avait donc aucun interêt à discuter de conceptions alternatives avec le directeur.

Karen décida de rentrer tôt chez elle et de chercher un nouvel emploi. Lorsqu’elle est partie, elle n’a pas été regrettée par l’entreprise. Après tout, elle était “insouciante, pleurnicheuse et avait un problème avec l’autorité”. Ils n’ont jamais compris qu’elle avait une approche qui aurait pu sauver le produit de l’exode de clients dû aux pannes répétées.

Comment bâtir une sécurité psychologique dans votre équipe ?

Alors, qu’y-a-t-il de si spécial dans l’ingénierie qui nous pousse à écarter tant d’ingénieurs prometteurs et qui permette à tant d’autres de ne pas arriver à donner le meilleur d’eux-mêmes ?

Nous devons être capables de trouver un juste équilibre entre le respect pour notre culture avec une nécessaire ouverture au changement.

Nous savons qu’un sens aigu de la culture, une compréhension partagée et des valeurs communes font partie des clefs du succès. Nous devons donc être capable de trouver un juste équilibre entre ce respect pour notre culture et une nécessaire ouverture au changement. Une équipe - à la base contente de travailler de la maison - doit changer sa façon de travailler si elle veut pouvoir engager des stagiaires. Une équipe - fière que ses ingénieurs soient mobilisés pour leur service - peut avoir besoin de se professionnaliser autour d’une équipe resserrée d’ingénieurs axés sur les opérations au fur et à mesure que le risque qu’une panne potentielle puisse impacter la production augmente.

Nous devons bien réfléchir à la façon dont nous mettons en balance le travail que les gens aiment faire avec celui que l’entreprise doit réaliser. Les bons managers sont proactifs quand il s’agit de déplacer un ingénieur qui n’est pas adapté à la charge de travail de son équipe. Les meilleurs managers augmentent le périmètre d’intervention de leur équipe pour mieux tirer parti de tous les ingénieurs à leur disposition, afin de s’assurer que leurs compétences et leurs talents soient appréciés à leur juste valeur. Les ingénieurs à qui on confie un travail et qui n’ont pas les compétences pour réussir à le mener à bien se sentiront conditionnés pour échouer.

Le respect doit faire partie de la culture de votre équipe

C’est dur de se donner à 100% si vous dépensez votre énergie mentale à prétendre être quelqu’un que vous n’êtes pas. Nous devons faire en sorte que les gens puissent être eux-mêmes en nous assurant de prendre la parole lorsque nous sommes témoins d’un manque de respect. David Morrisson (chef des armées australiennes) a parfaitement capturé ce sentiment dans son message : “the standard you walk past is the standard you accept”

Ne pas se préoccuper des sentiments et des expériences des personnes peut les amener à se renfermer sur elles-mêmes. Voici quelques exemples où je suis intervenu personnellement :

Quelqu’un accueille une nouvelle chef de projet dans l’équipe, part du principe qu’elle n’a pas un profil technique et utilise un vocabulaire enfantin pour lui expliquer un service. Je fais remarquer que le nouveau chef de projet possède un doctorat en informatique. Il ne pensait pas à mal et fut mortifié que son introduction rigolote puisse être aussi mal prise.
Lors d’une conversation à propos des fonctions exercées précédemment, quelqu’un mentionne qu’il a travaillé pour une entreprise qui a par la suite échoué. Un collègue se moque de lui pour être “assez courageux” de le reconnaître. J’ai rappelé que se moquer des gens n’était pas professionnel et que ça n’avait pas sa place ici. Les personnes présentes ont compris qu’il y avait une ligne, qui n’était pas visible auparavant, à ne pas franchir.
Un ingénieur calme et brillant est constamment interrompu par des personnes extraverties pendant les réunions. Je fais remarquer aux gens “bruyants” que nous nous privons qu’un point de vue important en ne permettant pas à tout le monde de s’exprimer librement. Les personnes présentes en ont pris conscience par la suite.

Il est essentiel de réagir immédiatement à tout manque de respect, poliment et devant toutes les personnes qui ont entendu le manque de respect. Ça aurait été génial si quelqu’un avait rappelé au responsable de Karen, devant tout le groupe, que la panne n’était pas bien méchante et que l’équipe devrait améliorer sa couverture de tests.

Laissez la place à l’expérimentation

On parle de 20% du temps de travail dans certaines entreprises. Intercom a des semaines “tampon”, intercalées entre leurs sprints de 6 semaines. Les gens en profitent souvent pour s’attaquer à un problème qui les tracassent, sans impacter les engagements externes pris par l’équipe. Inciter tous les membres de l’équipe à penser hors du cadre et faire en sorte que toute l’équipe puisse en même temps faire du hors-piste, c’est un message fort.

Faites bien attention à ce que ce temps dédié à l’innovation ne soit pas le seul pendant lequel les personnes puissent prendre des risques. Une entreprise dans l’industrie du transport considère par exemple que le “temps pour innover” c’est tous les mardis à 14h30. Imaginez combien Karen aurait été reconnaissante si pendant la revue un ingénieur sénior lui avait proposer de travailler sur son design avec elle pour que ce soit mieux accepté par le reste de l’équipe. Améliorez les idées des personnes plutôt que d’en douter.

Indiquez clairement quand votre équipe se porte bien

J’aime la façon dont mon équipe écrit ses objectifs sur des Post-It pendant nos standups quotidiens et nos réunions d’objectifs hebdomadaires. Ces marques visibles de succès peuvent être célébrées lorsqu’elle passent dans la colonne “fini”.

Mais nous pouvons aussi fêter les échecs retentissants. Il y a quelques années, lorsque je dirigeais une équipe chargée de la fiabilité de l’infrastructure, nous étions arrivés à la moitié d’un projet de 3 ans qui devait remplacer le vieux système de fichiers de Google.

Nous pouvons aussi fêter les échecs retentissants.

À cause de l’accumulation de problèmes d’alimentation, de mauvais firmware, d’outillage pauvre, de logiciels non testés, d’un calendrier de déploiement audacieux et de deux pannes de courant, nous avons perdu une cellule de stockage entière pendant plusieurs heures, et bien que tous les autres services aient eu du stockages dans les autres zones disponibles, l’équipe a passé trois longues journées et trois longues nuits à reconstruire cette zone. Une fois que ce fut fait, tout le monde - et moi le premier - était découragé. Démoralisé, défait. Un manager exceptionnel qui nous rendait visite dans le bureau a vu que j’étais abattu. Il a souligné que nous avions plus appris sur notre nouvelle unité de stockage pendant ces trois jours que pendant les trois derniers mois. Il a estimé qu’une célébration était de rigueur.

J’ai acheté du vin pétillant bon marché à la supérette du coin et avec un autre manager, nous avons occupé une grande salle de conférence pendant quelques heures. À chaque fois que quelqu’un notait quelque chose qu’il avait appris au tableau blanc, nous portions un toast. L’équipe qui a quitté cette pièce était totalement différente de celle qui y était rentrée.

Je suis sûr que Karen aurait aimé qu’on la remercie pour avoir découvert les faiblesses de la couverture de code non testé de l’équipe et le manque de documentation à propos de leur amour invétéré du temps de disponibilité.

Rendez votre communication claire et vos attentes explicites

Plutôt que de crier sur une équipe d’ingénierie à chaque fois qu’il y a une panne, aidez-les à développer des outils de mesure de qualification de pannes, un suivi objectif du niveau de service et contribuez à mettre en place une vraie culture qui leur laisse de la latitude entre leurs objectifs et la réalité pour les aider à choisir le travail qui aura le plus d’impact.

Demandez un engagement spécifique plutôt que de supposer que tout le monde s’accorde sur le degré d’urgence.

Lorsque vous évoquez les échecs, les gens doivent se sentir suffisamment en sécurité pour partager toutes les informations pertinentes, en comprenant bien qu’ils ne seront pas jugés sur la manière dont ils se sont plantés, mais sur comment leur gestion des échecs aura contribué à améliorer l’équipe, le produit et l’entreprise dans son ensemble. Les équipes avec des responsables des opérations doivent se réunir et discuter des pannes et de la gestion des échecs. Il est essentiel d’aborder tout cela comme des opportunités ludiques d’apprentissage, et non comme des persécutions obsessionnelles du coupable.

J’ai vu une équipe paralysée qui essayait de décider s’il fallait livrer un gain efficace qui aurait augmenté la latence de l’utilisateur final de 20%. Une rapide discussion avec l’équipe produit a entrainé des mises à jour de l’objectif de niveau de service qui détaillaient “l’impact estimé des différents niveaux de latence sur la retention des utilisateurs” et l’impact financier résultant sur l’entreprise. Tous les membres de l’équipe ont rapidement pu se rendre compte que la faible latence était bien plus importante que les coûts matériels qui, au lieu de cela, étaient considérablement trop approvisionnés.

Si vous attendez quelque chose de quelqu’un, demandez un engagement spécifique - “Quand cela pourrait être fait ?”, plutôt de croire que tout le monde s’accorde sur son urgence. La confiance peut être entamée par des engagements manqués.

Karen aurait apprécié qu’un manager la prévienne à l’avance que l’équipe considérait que la fiabilité c’était sacré et lui demande de travailler sur des améliorations de cette fiabilité plutôt que sur des optimisations.

Faites en sorte que votre équipe se sente en sécurité

Si vous avez envie de faire en sorte que votre équipe se sente psychologiquement plus en sécurité, voici quelques trucs que vous pouvez faire dès maintenant :

Faites un rapide sondage et partagez les résultats avec votre équipe.
Discutez ce que la “sécurité” représente pour votre équipe, est-ce que les personnes partagent entre elles quand elles ne se sentent pas “en sécurité” ?
Développez une culture du respect et d’une communication très claire, en commençant par vos actions.

Considérez la sécurité psychologique comme un indicateur clé du business, tout aussi important que les recettes, les coûts de vente ou le temps de disponibilité. Cela va se répercuter sur l’efficacité de votre équipe, la productivité, la rétention des employés et tout autre métrique business que vous chérissez.

Sept ans de Sud Web

2017-05-21T00:00:00+02:00

Une page se tourne, puisque l’édition qui vient de s’achever à Aix-en-Provence était ma dernière en tant que membre de l’équipe d’organisation. Comme Loïc ou Thomas avant moi, après plusieurs années à m’être impliqué dans ce projet qui me tient tant à cœur, j’ai décidé de passer la main en toute sérénité.

Pendant toutes ces années l’équipe a acquis l’expérience nécessaire pour organiser une édition avec une logistique impeccable, même dans une ville où aucun membre de l’équipe ne réside. D’autre part je suis confiant dans la résilience du projet, si j’en crois l’implication affichée par les nouveaux membres arrivés ces dernières années.

Mon départ — ainsi que celui de Nathalie — permettra aussi à l’équipe de bénéficier de sang neuf, d’une vision différente qui lui permette d’expérimenter à son gré comme nous avons essayé de le faire au cours des précédentes éditions.

Il y a de la place pour continuer à casser les codes de ce qu’on peut attendre d’une conférence liées aux métiers du Web, mais qui tient aussi à rappeler aux participants que nous sommes des êtres humains avant tout, dotés d’émotions, de valeurs et d’envies, qui font que notre implication dans des projets est subordonnée au sens qu’elle revêt pour nous.

C’est un message que nous n’avons cessé de rappeler d’édition en édition, et cette année encore, nous avons pu voir que les projets personnels permettent de progresser voire de s’affranchir d’un travail dans lequel on ne se sent pas complètement soi-même et qui nous empêche de donner le meilleur de nous-mêmes.

Sud Web a été un terrain de jeu formidable à ce niveau et nous avons fait en sorte que chaque membre de l’équipe puisse s’investir comme il le souhaitait. Comme dans la journée de l’open space du samedi, il n’y a pas forcément besoin de planifier quoi que se soit pour que les personnes se proposent spontanément pour s’attribuer des tâches.

Le cadre et les objectifs sont suffisamment clairs pour que chacun sache si ce qu’il veut entreprendre aura un impact positif sur le résultat attendu.

Ce sont souvent les conférences et les leçons apprises lors des éditions précédentes qui ont alimenté notre envie de toujours nous améliorer. D’où l’importance de la curation et de la sélection des sujets qui vont amorcer les discussions qui auront lieu ensuite. De ces discussions naîtront des apprentissages, des réflexions, des décisions…

Il suffit de dire oui.

“J’aimerais gérer le budget.”

Oui Nathalie.

“J’aimerais refaire la charte graphique.”

Oui Enza.

“J’aimerais revoir la présentation du site.”

Oui Mathieu.

“J’aimerais particper à la curation et faire évoluer nos offres de partenariat.”

Oui Boris.

“J’aimerais m’occuper de l’animation.”

Oui Amanda.

“J’aimerais m’occuper du design des stickers.”

Oui Alexandra.

“J’aimerais prendre les photos pendant l’évènement.”

Oui Bertrand.

Ces trois dernières années, les intégrations des nouveaux membres ont été plus que réussies. Amanda, Enza, Alexandra, vous m’avez bluffé. Boris, Bertrand, Matthieu, vous avez assuré.

Moment de complicité avec Amanda

Le secret a été d’ajouter toujours plus d’humain.

Si Sud Web est organisé à distance depuis le début, il n’en reste pas moins important de nous voir et de partager des moments de convivialité. Les quelques week-ends que nous passons ensemble permettent d’établir une relation de confiance et un esprit d’équipe, qui nous anime tout au long de l’année.

Il n’y a donc aucune raison pour ne pas laisser la place pour que ce bel évènement continue d’exister grâce à l’implication et à l’énergie d’anciens participants, qui à leur tour, vont vouloir apporter à Sud Web, autant que Sud Web leur a apporté.

L’énergie que nous mettons dans l’organisation nous est rendue au centuple lors de l’évènement, cette énergie j’ai maintenant envie de la mettre au service de nouveaux projets.

Cette année encore le témoignage de Sabine me conforte dans l’idée que tout est toujours possible. J’ai envie d’apprendre de nouvelles choses, faire de nouvelles expériences, mettre mes savoirs aux services de personnes animées comme moi par l’envie de vivre dans un monde où nos rapports sont basés avant tout sur le respect et la confiance.

Cette édition de Sud Web me donne des envies d’ailleurs, je ne sais pas encore de quoi l’avenir sera fait, mais je trouverai en moi la force nécessaire pour continuer de vivre en accord avec moi-même.

Merci à toutes les personnes que j’ai croisées au cours de toutes ces années, pour tous ces échanges qui ont animé mes réflexions. Je ne serai pas la personne que je suis aujourd’hui si je n’avais pas croisé votre route. Je quitte une belle aventure pour en vivre une nouvelle.

Une mention spéciale pour mes ancien·ne·s camarades de jeu, vous m’avez donné envie de donner faire de mon mieux, vous avez fait de moi une personne meilleure.

Merci d’avance à tous ceux qui feront perdurer ce bel évènement.

Longue vie à Sud Web, prenez en soin. C’est un moment tellement précieux, qui communique de belles valeurs, des valeurs qui continueront de m’animer dans tout ce que j’entreprendrai par la suite.