Ok

En poursuivant votre navigation sur ce site, vous acceptez l'utilisation de cookies. Ces derniers assurent le bon fonctionnement de nos services. En savoir plus.

Méthodologie - Page 2

  • Pourquoi j'aime travailler avec des collègues créatifs ?

    L'hcolisposte.jpgistoire commence sur Twitter où un ancien collègue se plaint de Laposte qui a perdu son recommandé. "A vous d'inventer la vie qui avec !" pourrait convenir tout à fait puisque un collègue lui répond en image, preuve à l'appui. Je la reproduit ici (.chez kek.). Je dois avouer que je suis tombé sous le charme (à voir le nombre de commantaires, je suis pas le seul). Décryptons un peu cette image.
    - il y a ce que tout le monde voit.
    - il y a l'imaginaire très fertile de l'artiste à moins qu'il ne connaisse très bien laposte ;)
    Ça fonctionne super bien, en effet :
    - qui ne s'est pas demandé comment arrivait un taxi quand on appelle à la boite vocale de get7 ou taxisbleus ?
    - qui ne s'est jamais demandé comment se fabriquent les fraises tagada ?
    - ...

    Plutôt que de parler de l'organisation de Laposte où tout à déjà été dit, parlons de la créativité. Reprennons l'image de notre humoriste : il y a ce que les clients voient et ce que l'équipe fait en aval pour faire tourner "l'usine" ! C'est donc que l'équipe doit être créative pour ne pas sombrer dans "l'usine à gaz". C'est justement cela qui m'intéresse !

    Créativité individuelle :
    On a tous un collègue qui de lui même aura la brillance de sortir une solution d'on ne sait trop où ! Mais si, en général c'est pas le plus doué communication, il est plutôt introverti certains disent même qu'il est un peu autiste et se pationne pour des sujets techniques (geeks). Oui mais ses solutions sont géniales à rendre jaloux plus d'un. Et bien votre collègue est atteint du syndrome d’Asperger. En fait, c'est un hypercréatif individuel. Il est parfois insupportable pour l'équipe mais indispensable. Pour valoriser et cultiver toute cette créativité, il faut la croiser avec d'autres sous forme de brainstorming.

    L'échec un ressor à refuser mais pas à blâmer
    Qu'il s'agisse de notre "autiste" ou d'autres collègues, on sait tous qu'on apprend en marchant. Refuser l'échec c'est ne pas s'en satisfaire, en faire défaitistement une règle inéluctable, mais c'est savoir tirer les leçons de l'échec : débrieffer en somme.
    Blâmer un échec est à rebour destructeur de créativité. En agissant comme jugemment, il génére du stress et la peur de mal faire, ce qui démotive au partage d'idées. Les collègues se sentent alors déresponsabilisés, on observe alors une fermeture.

    L'imaginaire fertile est contagieux
    Pour créer, inover, trouver "the killer idea" il faut savoir penser autrement, se mettre dans des conditions différentes qui vont permettre d'être créatif. La richesse d'une équipe se trouve aussi dans son caractère pluriel, pluri-culturel. Et ça marche parceque la créativité des uns appelle la créativité des autres !

    Reflexe créatif
    Corriger un bug "vicelar", demande une expérience et aussi une méthode et des réflexes pour passer au crible l'ensemble des symptômes.
    J'ai travaillé chez ArjoWiggins (papeterie) où le chef du BE avait toutes les réponses. Voilà comment il travaillait : tu l'appelles à n'importe quelle heure du jour ou de la nuit, il t'ecoute parler, 
    raccroche, va fumer un cigarette. Dix minutes plus tard, il te rappelle avec la solution avec la sagesse du vieux singe.
    Une démarche créative doit être accompagné de rigueur. Il ne s'agit pas simplement d'expérience mais surtout de permettre à ses neurones de se connecter pour explorer un très large panel de possibilité. Contrairement aux idées reçues, apprendre à être créatif, ce n'est pas laisser son collègue aborder le problème comme il l'entend. L'accompagner en créant un plan d'exploration ou un rapport d'étonnement est essentiel.
    Un tas de préjugé, de faux semblants nous bride au quotidien. Il agisse comme des oeillères.

    La démarche AWAW (Artist Way At Work)
    J'ai connu cette démarche avec Isabelle Fouchecour alors que je n'étais qu'étudiant et j'en retiens un excellent souvenir. J'en retire encore quelques pratiques. Awaw c'est la créativité au travail, comment rester créatif sous le stress, c'est acquérir certains réflexes qui aident à se sortir des situations bloquées parce qu'on se sera libèré mentalement de contraintes, les fameuses œillères.
    Décharger ses pulsions en rédigeant des pages rush, passer une journée "ordinaire" avec un appareil photo pour pouvoir se questionner a posteriori sur ce qui a attiré notre regard au quotidien sont autant d'atelier qui cassent les habitudes, le train-train et qui nous questionnent sur nos choix en utilisant tous nos sens au maximum de leur capacité.

    Au quotidien, c'est quoi être créatif ?
    Certes on peut dire c'est créer, inover mais on fait guère avancer le schmiliblick. C'est avoir une attitude résolument ouverte c'est faire fis de chaque problème, technique, fonctionnel, financier, humain, ... 
    Et apporter des réponses qui sont résollument positives parce qu'utile, fonctionnelles et concraites.

    L'ouverture de ce blog avait pour unique objectif de mieux appréander ma nouvelle fonction. C'est une manière créative de faire le point sur ses connaissances et le bilan des questions auxquels je suis confronté au quotidien. En celà, je peux anticiper, prendre le temps d'établir un plan qui sera forcément créatif et inovant en remettant en cause constamment les recettes de cuisines.

    Tout cela c'est l'inspiration d'un exercice awaw !

  • Mon bureau est rangé et puis c'est tout

    Après avoir visité les coulisses de ma société par les sentiers hors piste, nous partons cette semaine dans ma sphère presque intime mon bureau.
    Attention : ce billet pourrait choquer la sensibilité des plus susceptibles. En cas de crise de maniaquerie aigüe, l'éditeur de ce blog décline tout responsabilité.

    "Mon bureau est rangé." Ceci est une affirmation, et pour être transparent avec le lecteur, je colle ici une photo.

    bureau.jpg

    Comme mon honnêteté ne peut être mis en cause, je vais vous expliquer comment je prends soin de mes affaires. Chaque dossier est rangé aux archives quand il ne sert plus. Pour être dans l'air du temps, je jette dans la corbeille "recyclage" ce qui peut l'être : un acte citoyen en somme. Mais je ne m'arrête pas là : quatre fois par semaine je passe une lingette nettoyante anti-poussières, anti-bactérie. Ma tasse à café est elle aussi netoyée avant chaque départ, le soir. Pour moi, ranger son bureau, c'est essentielle à la vie. Quand on aime son travail, on aime son bureau et on le maintien en ordre. C'est non seulement du civisme, c'est la quintessence du professionnalisme, une fiéreté de ...


    - Aïe ! Quoi Pascal ? J'en fais trop ?
    - Ma note était pas sur le nettoyage du bureau ? Ben, je sais ça ! Et alors ...

    photo.jpg

    - T'avais pas le droit, je pers tout mon crédit maintenant. Tand pis je vais faire une pirouette.


    La semaine dernière Pascal fait part à l'équipe technique d'un bug affreux : une histoire de nuage de tags mal rangés, classés par ordre alphabétique au lieu d'un classement par popularité. La première suggestion de l'intégrateur (voir la première photo pour comprendre la duperie) qu'il n'y a qu'à regarder de toute évidence le client avait dû faire une erreur en saisissant ses tags ou bien. En étudiant la requête qui récupère les tags, je me suis aperçu (voir photo 2) qu'une "bannette" hors du champs de vison avait été placée pour masquer le bug. De fait tout semblait ok à première vue.

    - Et voilà Pascal !
    - quoi, c'est tout ? Tu voulais de la philosophie ?
    - non pas cette fois. Tu veux une conclusion socio-comportementale ? Bon Ok.

    Humilité. L'humilité face au client. L'humilité face au bug, à la machine, à la vie. Pour faire correctement son travail, de chef de projet ou de développeur il faut être créatif au sens américain du terme, dépasser les prejugés, remettre en cause le bon sens, ... Bref faire sauter les barrières mentales : be aware !

  • L'ordre des choses

    métronome.jpgCette semaine j'ai eu une question "surprenante" (sic) de la part d'un nouveau collègue. Cette question je l'ai posée je ne sais pas combien de fois quand j'étais encore développeur.

    "Par quoi je commence ?"

    Quand on établit un planning, on a effectivement les clefs pour jongler avec les projets et les rendus. Jongler n'est pas un vain mot, il s'agit d'être le métronome de l'équipe en rythmant les efforts et le chef d'orchestre en réglant la partition... Entre parenthèses, c'est mon grand challenge pour 2010 que je prend très à coeur.

    Quelle fut ma réponse ?

    La priorité en terme de qualité, c'est la stabilité de la production et des développements, donc :

    1. La correction de bug critique (et moins critique) en production.
    2. La correction de tests unitaires rouges (pour éviter les régressions).
    3. Le développement de fonctionnalités.

    1 et 2, c'est du temps de gâché (Muda de niveau 2 - aucune valeur ajoutée pour le produit mais indispensable), toute l'équipe doit le minimiser. Il va de soit que c'est 3 qui apporte de la valeur ajoutée (et notre raison d'être) donc que l'on a intérêt à faire le maximum de 3. De plus, plus 3 est soigné, moins il y aura de 1 et 2.

    Donc la priorité en terme de produits :

    1. Le développement de fonctionnalités.
    2. La correction de tests unitaires rouges.
    3. La correction de bug.

    C'est l'opposé.

    Cette apparente contradiction correspond au point de vue de deux rôles de la méthode Scrum : le ScrumMaster versus le Product Owner.

  • La règle du ticket d'entrée dans des chantiers à forte valeur ajoutée

    Après avoir traité la stratégie face au chantier d'élimination du muda (gâchi), nous allons nous détailler la mise en place d'une organisation lean pour le développement de logiciel.

    Le cercle vertueux de développement logiciel

    Voici les actions que nous allons mener dans les mois qui viendront. Nos produits sont relativement jeunes et ont besoin de souplesses. Leurs contours initiaux éolluent en fonction des projet et des besoins clients. Lors des premiers cycles de développements, il faut prendre garde à ne pas trop marquer le produit par les volontés d'un unique client.

    cercle-produit.jpg

    Ce cercle vertueux est un cycle d'étude et développement que l'on peut retenir pour concilier la qualité, la rapidité d'exécution et la souplesse dans la gestion de la Road Map produit.

    Comment cela se passe ?

    Le backlog produit c'est la liste des fonctionnalités à développer. Quand on gère un produit web qui n'est pas encore mature, on vend au client un projet web. C'est les idées du client qui enrichissent fonctionnellement le produit. Une réunion mensuelle, réunion de planification, permet à la lumière des études du mois passé de sélectionner en fonction des priorités et de la charge, ce qui rejoindra le développement. Les éléments sélectionnés constituent la release ou backlog de sprint.

    Un cycle (sprint) dure un mois. Cela permet d'entamer des gros chantiers. Parallèlement, une livraison hébdomadaire des développements permet d'assurer des recettes sur les serveurs de préproduction plus courte et livrer des projets qui demande certaines fonctionnalités. Un cycle comprend une partie étude technique préléminaire au gros chantier du mois à venir et une partie développement. En cela, je m'écarte de la méthode SCRUM pure, nous ne sommes pas suffisamment nombreux. Je considère qu'une étude de faisabilité est souvent plus importante que le développement que c'est un travail apparentière.

    Pour les développeurs les plus juniors, j'ai mis en place des fiches de développements. Un chef de projets ou produits décrit fonctionnellement le besoin puis je détaille techniquement, en relation avec le responsable R&D, la meilleure manière technique d'arriver à la solution.

    Les bénéfices

    • Préparer le terrain par des études c'est s'assurer de ne pas avoir de surprise et de ne pas exploser le sprint.
    • L'autonomie dans les livraisons permet d'évaluer son rythme et de se mettre une pression "seine" en fonction des attentes des clients.
    • Avoir une idée des chantiers à 3 ou 6 mois (c'est beaucoup dans le web) permet d'anticiper (son plan RH, la sortie d'un nouveau produit, ...)
    • Les arbitrages fonctionnelles du produit sont fait par le chef des produits par le feedback permanent avec le développeur.

    Conclusion

    Les cycles permettent une remise en cause régulière de ce que l'on fait. Même si on jette à la poubelle un sprint car le besoin n'est plus là on a perdu qu'un mois. Le cahier des charges suit le besoin au plus près. Imaginez faire six mois de dévelloppement et arrive au constat que l'on est à côté de la plaque car le cahier des charges a été construit au début à partir d'arbitrages fonctionnelles judicieux à la hauteur des connaissances du démarage d'un projet.

  • L'engagement client face aux développements produits

    illustration204.gifLa semaine denière j'avais annoncé trois notes de suite .... Et puis je suis tombé malade, donc je n'ai pas eu le temps de rédiger la note. Alors vous l'attendez toujours ? Oui mais cela vous permet d'avoir un billet subsidaire qui introduit le dernier billet de la série (et qui me demande plus de soins) ! Et puis vous aurez peut-être des nouvelles de mon médecin et de son bon sens légendaire ...

    Ce qui est bien avec un blog, c'est qu'on a le droit de ne pas tenir sa promesse, ou de l'honorer plus tard, quand on a un peu plus de temps.

    Quand on gère une équipe projets et produits, ce n'est plus possible :

    1°) Le produit est constamment relégué en priorité inférieure.

    2°) Le projet, c'est le client qui le commande et c'est lui qui nous fait "manger".

    3°) Le produit est consommateur de R&D qui se rentabilise sur du long terme.

    Comment donc concilier la progression du produit et la sortie des projets à l'heure ?

    On pourrait considérer qu'en surdimensionnant l'équipe, cela permet de former une équipe produits et une équipe projets distincte. Sauf qu'en période de pénurie de profils expérimentés, c'est un raisonnement difficile à tenir.

    La première technique, qui profite que je suis le seul à gérer produits et projets, est inspiré de la "stratégie de l'ascensseur qui déssert deux étages". On priorise les développements spécifiques des clients en fonction de ce qu'on peut réutiliser pour d'autres. C'est-à-dire qu'on profite du besoin d'un client pour alimenter et faire avancer la road map. L'avantage c'est qu'on peu sortir régulièrement des nouveautés et que le client est est satisfait. Mais il faut pour cela avoir un excellent chef de projet qui saura "exhausser" le voeux du client dans un rendu le plus standard possible. L'inconvéniant, c'est qu'on ne peut pas envisager des gros dossiers ou des refontes majeures.

    La deuxième technique est d'adopter un profile Agile... (Pas la prochaine note, mais surement la suivante !)

  • La règle du ticket d'entrée dans des chantiers lean

    Dans nos petites entreprises, "faire d'une pierre deux coups" n'est pas simplement un besoin, ce doit être une stratégie obsessionnelle. Voici un exemple d'approche Lean pour éliminer le Muda de niveau 1 dans les start-up et chez les éditeurs de logiciels.

    Problématique : désengorger les serveurs de fichiers.

    L'arrivée de gros clients potentiels nous ont obligé il y a 6 mois à se pencher sur certains points faibles de notre architecture.

    Le brainstorming

    Il y a six mois, je découvre un projet d'entreprise sur l'installation de Mogile FS. C'est un software juste génial qui dispatche des fichiers sur plein de serveurs pour équilibrer la charge.

    En réfléchissant et en faisant le point sur les autres chantiers, je découvre un autre projet d'exploitation super intéressant : le packaging logiciel (façon d'encapsuler des fichiers sources de logiciel pour en faciliter le déploiement, en l'occurence package Debian).

    Comme on peut pas tout faire en même temps, il est décidé de faire un rapide comparatif (je vous la fait courte).

    Les moins

    Les plus

    Mogile FS

    - intégration longue et r&d pas évidente

    - cache de fichiers statique via memcache déjà en place

    - ticket d'entrée élevé (6 mois)

     

    - diminuer les accès disques des fichiers statiques sur les serveurs de fichiers

    - supprimer un spof*

    - stimulation de bosser sur des techno hypes (faut bien motiver ses troupes)

    Package

    - changer de système de versioning (plus rapide)

     

    - limiter les accès disques des fichiers dynamiques

    - amélioration des temps de chargement des pages meilleurs

    - ticket d'entré faible (3 mois) : (1 produit packagé)

    - stabilité de l'exploitation

    Il s'avère que les deux projets de nature différentes semblent avoir en partie les mêmes objectifs. Pour se persuader de la priorité, il convient d'étudier l'impact de la mise en place de l'une et l'autre des solutions. On cherchera à savoir pour l'affichage d'une page quel est le stress sur le serveur de fichier engendré par l'appel des fichiers dynamiques et celui des fichiers statiques. En première approximation nous considérons le nombre d'accès disque.

    Je vous passe l'étude technique et financière et passe au choix qui a été décidé.

    Le choix stratégique :

    Au final, nous avons retenu le chantier packaging comme prioritaire. L'étude a montré que l'importance de ne pas centraliser les fichiers des software est prépondérante. Deplus le ticket d'entrée est plus faible. En cas d'arrivée d'un nouveau client, il a été décidé d'investir (ou location) dans un serveur de fichier supplémentaire (netapp pour 50kE qui équilibre l'installation de Mogile FS) si les gros clients sont finalement signés le temps de mettre en place MogileFs qui sera d'abord installé pour les nouveaux produits logiciels ce qui diminue le ticket d'entrée. La migration des soft existant serait trop couteux.

    Le choix du système de packaging à fixer comme premier palier la mise en place d'un nouvel outil de versionning (Bazaar) qui permet de gérer les images contrairement à notre ancien outil. Nous avons mutualisé les efforts pour diminuer le ticket d'entrée et avons cherché à dimuner le muda de niveau 1 (voir méthode lean). En effet, installer un outil de versionning n'apporte aucune valeur ajoutée au produits logiciels que nous vendons, c'est donc du gâchi, qu'il faut éliminer. Deplus l'investissement permet une efficacité dans l'exploitation au quotidien (encore du muda de niveau 1 éliminé).  La deuxième étape reste aujourd'hui de mettre en place le packaging logiciel.

    Conclusion :

    En conclusion, dans nos start up, les patrons nous demande toujours de délivrer plus vite. Côté technique une contrainte essentielle pour moi est le ticket d'entrée d'un projet doit toujours être inférieur à 3 mois.