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.

  • Système lean

    Je lis en ce moment "Système Lean".

    lean.jpg

    Ce livre nous fait découvrir le lean manufacturing des entreprises industrielles de sa première mis een place chez Toyota à nos jours.

  • Un projet automobile pour inspirer les projets web

    C'est vendredi et le vendredi c'est détente. Je vous propose aujourd'hui le feuilleton reportage du journal de 13h de France 2. L'équipe de journaliste a suivi pendant plus de 6 mois la conception et la réalisation de la nouvelle Citroën C3 à travaers les concepteurs, ingénieurs, ouvrier de lignes qui ont mené à terme ce projet de réalisation d'une voiture.

    Ce reportage est vraiment complet. Il y a énormément à puiser dans les processus de l'automobile. On le sait les méthodes lean sont empruntés à Toyota. Ici, c'est Citroën qui est filmé.

    Quand on cherche à industrialiser des processus lié à des produits et des projets, les contraintes sont les mêmes. Automobile et web, la rigueur dans l'approche et la concrétisation du projet doit être la même.

    A voir absolument (25 min). Naissance d'une automobile.

     

  • Projets, la relation au temps

    Il y a  deux choses qui sont partulièrement difficiles en gestion de projet : les relations humaines, et les relations au temps. Cette relation au temps se décompose en deux : le délais et la vélocité qu'il faut fournir (en jour homme) pour atteindre l'objectif.

    S'il nous arrive souvent d'être rattrapé par le temps, c'est qu'il est une contrainte forte. Elle est même si forte qu'elle fait oublier les béabas. Le mois dernier je reçois un coup de fil d'un ancien collègue qui en me donne de ses nouvelles :

    - Je comprend pas quand tu bossais avec nous, on avait moins de retours clients, on arrive pas à comprendre pourquoi ?

    - Tu as des exemples de retours ?

    - La semaine dernière on a raté une mise en production, il y a une partie du site qui répondait plus. Les ingénieurs ont réparés en catastrophe, mais le client était pas content.

    Tu m'étonnes ! En cherchant à savoir si les exigences de chaque environnement (de développement, de préproduction, tests et production) étaient respectées, je me suis aperçu que la préproduction était devenu l'espace de développement.

    En réalité, ce n'est jamais aussi flagrant, et les ingénieurs sont persuadés de faire leur développement en local, et une fois terminé, de le passer en préproduction. Mais ce qui biaise la procédure, c'est que par manque de temps, certains développements, à peine terminés, sont intégrés aux travaux stables en préproduction sans même être testé par le développeur sur son environnement local. Plusieurs raisons sont fréquentes : le délais pour livre la fonctionnalité, l'environnement n'est pas à jour des contributions des coéquipiers, une contrainte spécifique au client l'empêche de reproduire fidèlement l'espace de production. Par suite, le bêta testeur va se focaliser sur les erreurs les plus énormes. Il y aura beaucoup d'aller-retour sur l'environnement de préprod. Au final, les bugs plus "cachés" ne sont détectés qu'en production.

    Comment redresser la situation ?

    1°) Les indices de ce "glissement d'environnement" font penser illico qu'il faut ajouter une étape à la procédure entre la préprod et le dév : une recette sur l'environnement de développement. En premier lieu j'ai eu le réflexe de conseiller cette méthode, puis me suis raviser.

    En fait, oui pour une étape supplémentaire si elle est automatisé (cas de x programming) : jeu de tests unitaires, fonctionnels, ... dans ce cas elle est intégré au build. Non si c'est pour une recette des bêta testeurs : le développeur lui même doit livrer un travail le plus parfait possible et fonctionnel.

    Si on ajoute une étape en croyant que cette contrainte sera un passage de plus dans un tamis garantissant moins de bugs, on se trompe. Si on ne contient pas ce phénomène de glissement d'environnement, en établissant les raisons, on ajoutera des tamis et toujours plus de tamis. Cela apportera une rigidité à l'ensemble néfaste pour la bonne conduite du projet. (voir l'algorithme de mon médecin)

    2°) Rédiger simplement par écrit les procédures et en faire la communication

    Il me semble important que l'équipe comprenne pourquoi le respect de chaque espace est important pour ne pas mettre en péril la qualité des mises en production. Dans la plupart des projets web, les procédures doivent rester à la mesure du projet, donc légères.

    Finalement, c'est la communication qui sauvera l'affaire pour expliquer que certains raccourcis ne sont pas à prendre quand le temps presse en fin de sprint ou quand le délais du projet arrive à échéance.

  • Le know-how plus important que le produit

    savoir-faire.jpgAvoir un produit high-tech, avec plein de fonctionnalités pour satisfaire le besoin de l'utilisateur, c'est génial. Cependant, et spécialement avec les logiciels, il est rare qu'un soft soit utilisé à 100% de ses capacités. Prenez MS Word. Qui utilise plus de 20% de ses capacités ? Quasiment personne !

    Dans la plupart des cas, on s'aperçoit que le client ne connaît pas telles ou telles fonctionnalités ou possibilités offertes par le produit. Quand on travaille en B2B, il est concevable d'apporter ce savoir faire sous forme de service, mais certains clients n'ont pas forcement le temps de s'occuper de l'art et la manière d'utiliser leur produit.

    Disposer d'une base de connaissance solide, de documentations techniques orientées client, d'exemples d'utilisation est un plus incontournable. La liste des fonctionnalités ne suffit pas ! Et la diffusion de plus en plus large d'API (webservices) pour relier les applications nécessite d'ouvrir également sa documentation pour tirer le maximum de profit du produit.

  • Gestion de tickets clients

    error404ek2.jpgUne des clés des méthode Agile, c'est de répondre au besoin des clients. Ainsi les priorités de développement sont celles du clients et non de la facilité de développement cet tel ou tel module. Les itérations de développement, cycle d'environ un mois qui répond à un objectif déterminé à l'avance, sont priorisés pour répondre aux fonctions essentielles du projet. A la fin de chaque itération, il est toujours temps de faire des retours ce qui ne remet pas la totlité du projet en cause. Il est entendu que l'intégration du client (ou client interne) au sein du projet est un bénéfice, car lui est mobilisé pour la réussite du projet et les développeurs sont obligés de sortir de leur "mutisme" légendaire de l'informaticien. Pour organiser, à la fois les retours lors du développement et ensuite lors de la maintenance, mettre en place un outil de tickets clients permet une meilleure maîtrise des coûts de retours qui doit être obsession pour chasser le gaspillage.

    Faire son possible pour que les développements soient cadrés, c'est intégrer de la qualité continue grâce à l'extrem programming, qui permet de baisser le nombre de retours, car les bugs sont corrigé au plus tôt grace aux tests. Pour savoir si un projet a déraillé, il faut absolument mettre en place des indicateurs de performance, le nombre de retours clients est l'un d'entre eux.

    J'ai testé OTRS un outil de gestion de tickets. Conserver l'historique des demandes des clients et leurs réponses permet d'allier la qualité de service, tracer les échanges, organiser les échanges et améliorer les chances de succès du projet et des suivants. Un client envoie un mail au service maintenance qui est reçu et archivé par OTRS, comme un help desk digne de ce nom ! Les statistiques du help desk permettent de suivre l'activité des retours. Seul bémol à cet outil, les API encore dans la "todo list". La conséquance est évidente, impossibilité de remonter les stats dans l'outil de X-Programming (Hudsons).

     

    Liens utiles :

  • Fin de service

    atterrissage10122007141533.jpg

    Après avoir terminé de configurer un load balancer rebelle, me voilà sur le départ de nouvelles aventures et quitterais mes activités de directeur technique pour prendre de nouvelles fonctions.

    Depuis un mois, je me suis mis dans la peau d'un responsable produits et projets à travers ce blogs, dénomination interne qui ne correspond pas forcement aux standards rapporté dans ce blog, mais peu importe la fonction, l'objectif est le plus important. Comme dirait l'autre, on se comprend.

    J'ai dit "On se comprend." ? Oui, le principal est et reste que parmi toutes les méthodes management, management par la qualité, management par les tests, ... c'est d'avoir une communication efficace tand avec le client que les équipes.

    J'ai incarné la fonction virtuellement, il va falloir passer au concrêt et retomber sur terre : commander des stickers colorés, des stabilos, .... et faire connaissance avec mes nouveaux défis, clients, projets et coéquipiers !