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.

Produits et projets web - Page 7

  • 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.

  • Le spleen du samedi soir : L'équilibre

    equilibriste.jpgImaginez. On est au cirque. La piste est circulaire. Les tigres et les lions viennent de faire leur numéros. La musique baisse d'intensité, l'air de la mélodie envahi la salle, on aurait dit qu'on voulait nous souffler une comptine. Les projecteurs s'allument puis se dirigent lentement vers le ciel passe sur une forme puis s'arrête comme si le projectionniste avait louper quelque chose. Le faisceau lumineux fait demi tour puis revient. Les spectateurs se mettent à retenir leur souffle. En plein milieu du vide, une jeune fille est assit sur un filin. La demoiselle se redressa avec grâce sur sa ligne de vie. C'était doux, on aurait dit du coton et puis c'était petit tout là haut ! Et puis le nuage s'est effacé. Le rêve est terminé ; la vie reprend étourdi et un peu déséquilibré.

    La vie est un équilibre. L'équilibre rassemble l'excès et la modération. L'équilibre des équilibristes, c'est une pratique à risque : c'est se mettre en danger. C'est aussi le piment de la vie. Mais vivre équilibrer c'est doser chacune des bouchées que l'on donne à la vie. L'équilibre, c'est aussi refaire surface quand on est sur la corde raide.

    Un projet aussi est une somme d'équilibre. L'équilibre budgétaire, …

    Je vous laisse poursuivre le fil de cette histoire avec le degré de folie qu'il convient pour en profiter.

  • 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.

  • Evaluer ses collaborateurs

    entretiens_gabs_cafeteria.gifOuf c'est fini !

    C'est le début de l'année et traditionnellement, vient à cette période les évaluations de fin (ou début) d'année. Aussi dans la série "évaluer" voici un mot sur ma méthode pour évaluer mes collaborateurs. Pour mémoire, mon équipe est constituée de chefs de projets, d'intégrateurs web, d'un designer, et de développeurs.

    Certains managers redoutes d'être en face à face avec leurs collaborrateurs, je trouve cela enrichissant et nécessaire. Voici les étapes que je retiens :

    1°) Lancement des entretiens avec mailling de la fiche d'autoévaluation. Celle-ci n'est autre qu'une grille de case à coche et de questions ouvertes qui guideront mes collaborateurs à préparer leur entretien.

    2°) L'entretien. Je prend le temps qu'il faut (1 à 2 heures par personnes) pour passer en revue les points de chacun, leurs attentes, les points forts et les points d'amélioration, ...

    3°) Le plan RH à 6 mois. En fonction des objectifs de la société, je conçois mon plan RH : mes besoins, mes ressources, et tente de répondre à "qu'est ce qui me manque pour répondre aux objectifs ? Où va-t-on avec l'équipe en place ?". Je présente ce plan à mon suppérieur hiérarchique qui peut apporter son point de vue, ses améliorations et son aval.

    4°) Le compte rendu. La fiche d'autoévaluation une fois complétée fait un excellent résumé que je signe et remet en main propre avec les objectifs et/ou points à développer.

  • 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.