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 3

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

  • Quand mes deux vies se rejoignent

    La première est ici et la deuxième . J'aurais pu écrire ma note sur l'un ou l'autre des blogs. Figurez-vous que le projet d'installation d'une micro-centrale hydroélectrique auquel je participe est dans sa phase de "recette". Dans notre cas on dit mise en route. Pour une usine hydroélectrique refaire de A à Z, c'est 6 mois de boulot : un peu plus que la recette d'une site web !

    Côté organisation, c'est semblable à toutes les recettes en pire. On s'aperçoit que certaines choses ne vont pas. Des petites qui prennent quelques heures et d'autres plus longues qui nécessite du matériel, du technique, de l'administratif, ... Notre soucis est de démarer le plus rapidement possible, question de rentabilité. Ce business étant saisonnier, il faut si possible décaler pour l'été.

    Recetter et résoudre les problème en suivant est d'expérience chronophage. Il est souvent préférable d'avoir une vision globale des problèmes, de les lister, de les classer par priorité et de trouver les solutions.

     

     

    Urgent

    Moins Urgent

    Post production

    Court

    (1 jour max)

    - Chauffe du palier => mettre de l'huile

    - Brancher les capteurs du vérin

    - Courroie non centrée

    - Serrer la poulie sur son axe

    - Lancer abonnement EDF => appeler

    - Connecter la vanne sur l'automate

     

    Long

    - Passage de la courroie => modifier palier

    - suivi chantier toiture

    - creuser le fond du canal de sortie

    - carte d'acquisition

    Ce tableau présente un format de check list classé. C'est génrique pour l'industrie ou le web ...

    L'avantage, c'est que l'historique des solutions peut-être conservé au cas où le problème revient quelques années plus tard.

  • De l'art et la manière de gérer les projets web des clients

    Ma société a géré en 2009 plus de 150 projets clients avec en moyenne une centaine d'heure de travail pour une équipe de 6 personnes. Avant d'aborder 2010, il nous fallait préparer la croissance en utilisant un outil adapté. On pense souvent qu'un ERP permet de gérer de A à Z les processus d'une entreprise. C'est pas toujours vrai. En période de croissance rapide, il est souvent difficile d'utiliser un outil lourd et long à mettre en place que tout le monde doit s'approprier et pour lequel connaître son activité est essentiel pour la réussite de sa mise en place.

    KANBAN.jpg

    Pour 15 Euros (tout compris), voici un ERP "maison" qui nous permettra d'étudier plus souplement notre business et développer en interne l'outil informatique qu'il nous faut pour piloter notre activité.

    Objectif :

    • améliorer la visibilité sur les projets en cours
    • fiabilité les rendus
    • rendre plus autonomie chaque acteur
    • communiquer sur l'état d'avancement d'un projet
    • alerter des retards d'un projet

    Pour cela nous avons mis en place un Kanban : tableau d'étiquettes.

    Pourquoi une méthode japonaise et pourquoi pas scout non plus ?
    Les japonnais et surtout Toyota ont inventé des méthode d'une efficacité redoutable appliqué dans de nombreux domaines. Si ça marche dans l'industrie, pourquoi pas chez nous.

    On a déjà essayé des calendriers géant ça n'a pas marché, pourquoi Kanban marcherait-il ?

    Parceque Kanban n'est pas un calendier. Il a pour but et finalité d'apporter plus de solution que de contraintes et permet de responsabiliser tous les acteurs d'un projet.

    Comment ça marche ?
    Il s'agit d'une liste de tache (workflow) à réaliser et dont on bouge l'étiquette au fur et à mesure du "cap" qu'elle franchi. Il existe 5 caps :  signé (une fiche projet est alors crée avec le détail de la mission), conception (les inputs sont rassemblé et les développements custom font l'objet de spécifications), intégration (le développeur et l'intégrateur sont en cours de travail), en recette puis en production. Si une tache pose problème, on peut coller un post-it de couleur pour indiquer au chef du projet ou produit qu'un point de blocage empêche de poursuivre, ou que la tache nécessite un arbitrage (choix d'ergonomie par exemple).
    bulle-kanban.jpg

    Entre chaque étape, les conditions de passage d'un projet sont soumise à condition. Des bulles sont là pour mémoriser les "check points" de la gestion du projet.

     

    Sur quel projet cela s'applique ?
    Tous les projets clients de plus de 2 jours.

    Qui met a jour les étiquettes ?
    Chacun à son niveau : développeur, intégrateur, exploitation.

    Qui choisi les tâches à effectuer ?
    En général, une réunion quotidienne appelée daily standup meeting, devant le kanban, permet d'affecter à chacun des tâches. D'un coup d'oeil, tout le monde sait où en sont les autres membres de l'équipe. Donc si un membre est absent, on sait où il en est.

    Sur quels critères sont-elles partagées ?
    Ce n'est pas encore une habitude de travailler ainsi et le Kanban permet de raccourcir les temps de développements (puisque que plusieurs développeurs ou intégrateurs travaillent sur le même dossier en même temps). Cela permet d'être plus réactif auprès des clients et de fournir un travail de meilleur qualité.

     

    Parrallèlement à cette mise en place papier nous travaillons sur un outil informatique pour récencer et historiser toutes les données des projets et relier l'ensemble des services de l'entreprise (technique, exploitation, communication, facturation, bureau commercial, SAV, ...).

  • Suciter la curiosité à travers le rapport d'étonnement

    La caricature du développeur, c'est d'être dans son monde déconnecté de toute réalité. Cette situation engendre souvent des finitions sur les produits pas toujours évidentes ce qui gâche tout. J'entend par finition, l'ergonomie, le montage graphique, ... Quand vous utilisez un Iphone, vous vous dites que c'est intuitif. Quand vous utilisez un logiciel dédié à votre activité professionnelle (si vous êtes comptable dans une banque et que l'on vous as développé un soft) vous vous dites que c'est fonctionnel. C'est la preuve que la réputation des informaticiens est au moins en partie vraie.

    Pour susciter l'introspection sur les développements, j'ai commencé à utiliser le rapport d'étonnement. Depuis 1 mois, un de mes client m'appelle tous les jours et me laisse 3 à 4 emails par jour. C'est d'ailleurs celui qui m'apporte le plus de retours. Un nombre de bugs impressionnants chez l'autre prestataire du client, une solution technique nécessitant des webservices pas toujours maitrisés et une migration en dépis du bon sens ont fait que la situation s'est tendue. Pour reprendre la main et maîtriser le flux de retour, j'ai opéré le week-end dernier à un rapport d'expérience utilisateur sur le portail que nous avons développé. A force de corrigé des bugs (de notre fait et non), de changer les spécifications fonctionnelles et techniques, nous avons mis en place un formulaire de création de compte qui ne peut pas déboucher, des messages incohérents par rapport au scénario utilisateur, ... pour être honnête une bouse !

    J'ai trouvé ce lien (puis 2 3 4) qui détaille tout.

    Je vais maintenant essayer de le transmettre à mes développeurs, chefs de projets et intégrateurs en définissant qu'est ce qui doit déclancher le rapport d'étonnement chez eux.

     

    A suivre ...

  • Les courriers électroniques

    A l'occasion d'un changement d'ordianteur, j'ai réinstallé ma messagerie et voici quelques statistiques sur 3 semaines :

    • nombre d'emails traités : 1333 soit 89 emails par jour
    • nombre de clients : plus de 35 dossiers clients différents dont un dossier qui qui apporte plus 10% des emails

    Je n'ai pas le temps de faire le tour des stats qui me semblerais intéressantes de détailler mais celle-ci ammène plusieurs réflexions.

    90 mails par jour sur une journée de 8 à 10h, ça fait un mail toutes les 6 minutes en continue qui arrive et demande de l'attention, de juger s'il faut traiter à l'instant ou non, ... A mon sens cela fait beaucoup, voire trop. Pour être franc, certain mail sont lu en diagonal.

    Globalement, cela veut dire qu'une journée est constamment en poitillé à telle point que certains jours je suis obligé de ne pas recupérer mes mails le matin pour me permettre de me concentrer sur un dossier. Il n'est pas rare non plus de s'apercevoir que la journée peut commencer à 18 heure pour la simple raison que le flot de mails se ralenti !

    Je m'aperçois également de plusieurs difficutés pour une équipe produits et projets :

    • envoyer un mail qui pourrait attendre parasite la concentration d'un développeur.
    • un chef de projet a pour job de qualifier les emails des clients. Un transfert sans explication n'apporte aucune valeur ajoutée.
    • le fait de faire un mail ou un transfert est une manière de se dégager du problème : la balle n'est plus dans mon camp. Or ce qui est important c'est d'assurer le suivi du mail ou du dossier. Stratégiquement, il peut être intéressant d'utiliser cette méthode dans le cas d'une validation, cela peut permettre de gagner du temps, mais en général il faut savoir relancer.

    Exemples de solutions pour adapter sa communication à son besoin :

    • mettre en place un tableau visuel des taches à faire (kanban, excel, ...) peut permettre d'éliminer une communication par email mal appropriée
    • passer par de la messagerie instantanée ou un coup de téléphone pour tracker un sénario utilisateur qui mène sur un bug est plus simple que de se comprendre par email ... (ping-pong)
    • imposer à ses collègues de mettre dans le titre du mail "[nom du client]" permet de cibler directement le mail.

    Il existe des tas d'astuces pour améliorer la fluidité de la transmission d'informations (vous pouvez en ajouter dans les commentaires). A mon sens, la maitrise des outils de communicatione est primordiale, passé un certain volume d'échange.

  • Les Temps Modernes informatisés

    C'est vendredi alors petite vidéo pour introduire le thème.

    Quand on dispose d'une chaîne de production de sites internet, comme c'est le cas des start up qui disposent d'un parc de plate-forme en modèle SAAS (OVH par exemple), il est difficile de distinguer clairement le produit du service, d'autant plus si le produit est un service. Pour un ingénieur en mécanique comme moi, il faut une bonne dose d'immersion virtuelle pour définir les contours d'un produit complètement immatériel. Quel idée saugrenue, aussi ?! Disons que pour auditer une chaîne de production, il faut bien commencer par un bout.

    Adapter la chaîne de production au produit :
    Prenons l'exemple d'un produit chargé de délivrer des mails, le besoin est que le destinataire soit informé du contenu du mail. Dans certaines entreprises, la secrétaire imprime les trois emails reçus par semaine et les présente sur papier au patron. Le contrat est remplit de manière efficace. Prenons maintenant le produit GMail, disons que je vois mal une armée de petites mains faire le facteur des millions de mails des utilisateurs.

    Pourtant, il est rare de constater que la mise en place de la chaîne production soit parfaitement adaptée aux contraintes que le produit et ses développements vont imposer (par exemple la communication auprès des clients que telle fonctionnalité est mises à disposition, son déployement à travers les environnements de travail ou la customisation aux couleurs du client). Pourtant, on aurait pas idée de construire la Citroen C3 sur la même chaîne de production que celle d'une 2CV. Et pour reprendre le film de la naissance d'une voiture, la chaîne de la citroen C3 a tourné 6 mois à vide sans voiture, juste pour répéter les gestes et prévoir les moindres défauts. C'est pousser l'anticipation à l'extrême ? Oui, et alors, faut-il le regretter ?

    C'est justement en intégrant les contraintes de la chaîne de production que l'on gagne l'efficience. Des amis m'ont dit la semaine dernière qu'il faisait construire une maison en bois. Ils font confiance au charpentier, qui fait son devis sans étudier à fond le dossier. Au moment du montage il s'est aperçu que son atelier était trop petit pour monter l'assemblage ! Il a dû louer un atelier pour les travaux. Je doute que le projet ait été rentable pour le charpentier. Quel gaspillage !