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.

temps

  • Pour quoi perdre du temps ?

    Paklein_01.jpgrcequ'il y en a marre des gens pressés qui prennent pas soin de faire les choses correctement !

    Parcequ'il y en a marre de recommencer un travail déjà fait mais bourré de bugs !

    Parcequ'il y en a marre des mastodontes incontrôlables, j'ai déclaré la guerre au temps !

    Voilà mon manifeste du jour (lire en prenant le phrasée d'Arlette L. ) : "on vous ment, on vous spolie tous les jours en vous racontant que la performance des capitaux passe par la performance à tout prix des ouvriers du web. Faites la révolution car plus on avance moins vite moins on avance plus vite." Stop ! Ça suffit les discours. Restons sérieux.

     

    Je la refais "Plus on avance moins vite, moins on avance plus vite.". Lapalissade, me direz-vous. Oui si on sait perdre du temps pour en gagner à chaque instant... En fait, juste une question de rentabilité appliquée à l'humain. Vous trouverez cela un peu inhumain donc paradoxal, alors prenons un exemple.

    Une nouvelle recrue arrive :

    - bonjour Fatou

    - bonjour, euuh Cloture, c'est ça ?

    - oui Clotaire. ton poste est là, tes accès sur le post-it, le dossier de travail sur Béatrice dans le répertoire projet. Je reviens à midi, t'auras fini normalement. Si tu as besoin je suis là. Allez, bienvenue et courage.

     

    Ok pour perdre du temps pour en gagner par la suite ! Mais là c'est évident.

    Regardez dans nos startup, si vous les côtoyez, cette propension infernale à vouloir absolument embaucher des profils séniors. C'est bien pour avoir quelqu'un d'opérationnel tout de suite et donc réduire le temps de formation. Cela pose donc une question importante : est ce que la part d'expérience interne (connaître les produits de la société ou savoir développer avec le framework maison) est plus important que la part de standard (un logiciel graphique, le langage php) ?

    Ayant accueilli trois nouveaux collaborateurs (et trois nouveaux doivent arriver) en moins de trois mois, je tire les conclusions suivantes :

    - diminuer les connaissances spécifiques internes et les remplacer par des outils standards permets une plus grande adaptation (également importante si on envisage d'externaliser, c'est le même levier)

    - abaisser le niveau moyens d'accès des connaissances internes. La compréhension du produit phare de la société est connu de tous, tandis que l'utilisation de bases de données postgreSQL (moins courantes que mysql) requiert une compétence technique de plus haut niveau. Lors du remplacement d'un collaborateur ou pour en faire évoluer un autre, ce point est important à retenir.

    La formation n'est donc pas du muda de niveau 1 (gâchis qui ne rapporte rien) mais du muda de niveau 2 (perte indispensable que l'on cherche à minimiser).

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