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.

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

  • Définition, théorie et stratégie parce que les projets sont partout

    Je vous propose une histoire en trois volets, pour les trois prochains jours. Aujourd'hui, nous verrons la partie théorique avec une théorie, une définition et une stratégie. Demain et après demain, deux exemples d'application de cette stratégie.

    La théorie de la côté de bœuf :

    cote-de-boeuf.jpgThéorie qui consiste à découper le morceau de viande. Plus le morceau est gros, plus on va mastiquer longtemps en bouche. Par analogie, découper un projet permet d'aléger sa "digestion".

    Le ticket d'entrée :

    Je défini le ticket d'entrée d'un projet par le temps absolu (opposé au temps homme) qu'il est nécessaire d'attendre (pour le chef de produit ou travailler pour un développeur) avant de disposer d'une première solution minimaliste mais fonctionnelle de A à Z. Exemple : le développement d'un site Internet communautaire avec le nombre nécessaire et suffisant de fonctionnalités pour répondre au besoin immédiat et délivré en ligne peut prendre 2 mois tandis que le périmètre fonctionnel final peut prendre 6 mois. Le ticket vaut deux mois. Expérimentalement, le ticket d'entrée d'un projet ne doit pas excéder dans nos start-up 3 mois. Le ROI d'un projet ou chantier en dépend.

    Pourquoi ne pas prendre en compte le temps homme ? Si le projet est vital pour l'entreprise on sera toujours enclin à lui allouer plus de ressource en lui affectant une priorité plus élevée. Plus de trois mois ça doit donner la puce a l'oreille que quelque chose est mal dimensionner ou que l'imprévu prend le dessus.

    Stratégie de l'escalier qui déssert deux étages :

    Stratégie qui consiste à utiliser la théorie de la côte de boeuf afin de mutualiser une partie des efforts dans le but de diminuer le ticket d'entrée de plusieurs projets qui auraient des parties communes. Aussi appellée stratégie "faire d'une pierre deux coups". Cette stratégie est une méthode lean car elle permet d'économiser des temps de muda.

    J'espère vous avoir mis l'eau à la bouche. Les deux prochains articles donneront des exemples concrêts des ces théories. A demain.

  • Evaluer son projet

    Principe : "On ne peut gérer que ce qui se mesure."

    projet1.jpgIl y a quelques semaines je vous parlais du Kanban sur lequel j'affiche des "fiches projets". Ces fiches projets d'une format A4, se veulent synthétiques et résumer pour tous les acteurs du projet l'objectif. Elle se compose de plusieurs paragraphes :

    • Les contacts (emails et téléphones)
    • Le résumé du projet (concept)
    • Les users story (développements spécifiques)

    J'ai organisé la fiche projet en 3 étapes :

    1. Avant le projet : la période de "conception" qui récolte toutes les données (maquettes graphique, ...)
    2. Pendant le projet : la période d'intégration et développement pour le montage du projet
    3. Après le projet : récolte du feedback

    La fiche projet n'est jamais figée. Elle est remplie au fur et à mesure en fonction des nouveaux éléments.

    Les temps d'intégration sont conciliés sur cette fiche ce qui permet de calculer le ROI de chaque projet. Depuis 2 mois que j'ai installé ce système (20 projets environs), il me permet de consulter l'historique pour évaluer les temps d'un nouveau projet par similarité.

    Au final, il devient possible de mettre en évidence l'équilibre Coût / Délais / Qualité / Satisfaction-client.

    D'ici quelques semaines, à la lumière de notre tableau papier, nous pourront développer un ERP sur mesure.