Comment faire de beaux sites web comme les Australiens?
Nous avons vu Lundi dans “Réaliser le meilleur portail web” que les sites australiens étaient souvent d’une meilleure conception que les sites français. J’apporte dans cet article des éléments de solution: L’Agile n’est pas compatible avec les projets au forfait; les appels d’offres public doivent porter sur des unités d’oeuvre et non des spécifications; plusieurs techniques pour mettre l’utilisateur comme objectif ultime et avouer que les participants (les développeurs) sont le coeur qui fait battre le projet; chasser les processus qui font rouiller les entreprises; rendre le travail plus ludique… et recruter un designer.
Pour en savoir plus… Écoutez Carlos Goncalvez (DSI de la SGCIB) parler de l’Agilité chez la Société Générale dans 01 Informatique.
Arrêter les projets “au forfait”
L’Agile permet d’aboutir à des pratiques plus pragmatiques et, en particulier, l’Agile ne vous incite surtout pas à rester au forfait. Il est impossible d’écrire toutes les spécifications d’un système complexe et de les transformer en contrat. Il y a des expériences d’utilisateurs, des histoires vécues par des personnes derrière les écrans qui seront systématiquement trahies par des spécifications écrites à l’avance. Un projet au forfait, c’est la recette de la défaite. C’est le rôle des SSII de conseiller les clients sur les méthodes, notamment l’Agile. D’un côté, la tradition de faire des contrats informatiques ne les y incite pas. D’un autre, elles n’ont pas les compétences “modernes” en interne. Les employés n’y sont pas passionnés d’informatique et les employeurs sont contents de “staffer” des “ressources” sur des “projets”, sans talent ni développement personnel. Et si l’on entrait dans une spirale d’excellence ?
En Agile, l’utilisateur est la finalité du projet
Les critères de réussite doivent être établis sur les métriques d’adoption par les utilisateurs plutôt que le nombre de règles de gestion implémentées. S’il est obligatoire de recourir à un contrat, ledit contrat devra éviter les spécifications. On peut écrire un contrat portant sur un nombre de sprints ou d’unité d’oeuvre et un certain niveau d’expertise des développeurs.
Pourquoi on ne peut pas déléguer le risque à la SSII
Il est tentant d’utiliser le mode “forfait” pour laisser à la SSII tous les risques du projet. Après tout, c’est eux qui s’y connaissent en réalisation de projets informatique, n’est-ce pas ? Tout faux. Ils s’y connaissent très bien et votre contrat les incite à réduire les coûts. Malheureusement c’est à vous, cher client, d’internaliser les compétences web. Pourquoi ?
- Vous êtes la dernière façade avant les utilisateurs finaux !
- C’est donc vous qui engrangez les recettes ou déficits si le logiciel est efficace ou non,
- Et vous avez le bébé sur les bras sur le long terme.
Certains diraient follement: “Mais c’est comme si on demandait à nos actionnaires de s’y connaître en informatique !” En l’occurrence, s’ils investissent dans votre entreprise, c’est effectivement leur devoir de savoir juger si votre informatique tient la route, aussi dur cela soit-il.
En résumé, les projets au forfait, l’externalisation des compétences, c’est directement le gros panneau clignotant: “Warning! Aucune maîtrise ahead!’
En Agile, le coeur qui fait battre le projet, ce sont les participants
En dégageant un budget pour moderniser les technologies du projet, non seulement on évite de tomber dans l’obsolescence, mais en plus on excite la passion du développeur. Il renouvelle ses connaissances, il ne s’inquiète pas de son employabilité, il acquiert de la matière pour présenter des talks à des confs de dévloppeurs, et c’est ainsi que vous vous entourez de personnes talentueuses. Il y a cette idée préconçue que “le projet ne peut pas être mieux parce que tel développeur/tel service est nul.” Malheureusement il faut être un peu plus entreprenant: et si le développeur ne demandait qu’à être sur des projets excitants? Et si l’on réveillait son côté geek? Et si on laissait tomber ce document Word et qu’on allait expliquer en direct ce que l’utilisateur ressent?
Chasser la rouille, activement
Les entreprises se consolident à l’aide de règles. Mais les premières sont souvent les moins bonnes. Les services suffoquent, les coûts s’envolent, les employés se sédentarisent avec l’achat de maisons. On fait de la gestion de projet de masse. C’est la nature. En plus de ralentir le projet, chaque norme attaque la vélocité du développeur et dilue ce qui le passionne le plus: Conquérir le monde à travers la programmation. Est-ce qu’on vise juste dès la première fois où l’on écrit les règles? Pour garder la forme, il faut constamment éliminer la graisse.
Le seul processus qui doit être unifié, c’est le changement.
Les processus unifiés sur plusieurs départements, c’est optimiser la mauvaise chose: Le seul processus qui doit être unifié, c’est le changement. Au cours de rétrospectives, le team lead doit surtout prendre note des frictions et constamment traquer les processus parasites. Cela implique d’être pédagogue auprès de la hiérarchie, et cela donne tout son sens au team lead. Au lieu d’unifier les processus dans l’entreprise, on devrait se concentrer sur le développement des expertises, sur la communication et sur le partage des bonnes pratiques. Cela nous envoie hors de notre zone de confort car la collaboration n’est pas une donnée mesurable.
La DSI, une boîte à outils
Éliminer les processus, cela déplace aussi le rôle de la DSI. Au lieu d’offrir un contrôle déterministe et souverain sur l’informatique du groupe, elle doit devenir une boîte à outils. Qui peut programmer aujourd’hui sans:
- Sans Git ?
- Sans un repo Maven ?
- Sans une machine de build ?
- Sans un Paas comme Heroku ?
- Sans toolkit javascript ?
- Sans une charte graphique ?
- Sans une politique de validation des licences ?
Et si la DSI laissait un peu les différents services réaliser leurs projets informatiques dans leur coin, mais leur offrait une infrastructure qui dope leurs capacités et unifie leur culture de développeur ?
Des artifacts colorés, ludiques
Certains processus qualité ajoutent des étapes fastidieuses: Trop de documentation, trop de fiches techniques, des rapports à la chaîne, une vie ennuyeuse… L’Agile recommande un recours fréquent à la communication orale et de se reposer sur des artifacts palpables: Des peluches pour faire tourner les rôles, des lanternes de bureau pour les alertes, des wallboards pour le suivi de production.
Le toucher et l’aspect ludique permettent de mieux imprégner les apprentissages.
Il n’est pas rare que je lise un document d’architecture et que je n’en imprime que le graphique coloré de l’introduction. Qu’on le veuille ou non, seuls les artifacts visuels resteront à la pérénité. Alors d’un côté, cessons d’écrire des tableaux de spécifications et faisons plus confiance à la communication orale. D’un autre, trouvons différents vecteurs, tels que des diagrammes, des wallboards et des post-its pour communiquer une information sous forme visuelle. De préférence, plein de couleurs et un peu ludiques, pour réveiller nos capacités d’apprentissage.
Comme à la maternelle.
Les geeks sont de grands enfants.
De grands enfants très fiers quand leur site web est utilisé.
Et pour conclure: recrutez un designer
Ce n’est pas une recommandation Agile. C’est du bon sens. Le chef de projet, aussi conscient soit-il de l’expérience web, ne peut pas porter tout seul l’exigence “utilisateur”.
Pourquoi je n’ai pas mis le designer en critère #1?
Parce qu’un designer dans une équipe procédurière ne pourra pas faire bouger les limites. En fait, les conseils du designer sont perdus dans des papiers s’ils ne sont pas livrés en direct au développeur. Ce qui fait l’ergonomie d’un site web, ce n’est pas le nombre de chefs de projets, c’est le développeur. S’il n’est pas honnête dans son développement, s’il n’est pas amoureux du produit et s’il n’a pas un designer pour organiser et défendre les améliorations, alors lâchez votre clavier: Vous ne serez pas compétitifs.
Pour aller plus loin avec l’Agile
Atlassian vient de publier une série de vidéos sur leurs pratiques de l’Agile. Les entreprise prennent les pratiques qui sont les plus adaptées chez elles, il est temps de vous faire un portfolio avec un ensemble d’outils.
Et prenez le temps de vous moquer un peu de ceux qui sur-spécifient: