17 légendes urbaines de l’IT

17 légendes urbaines de l’IT
  1. Trop d’info tue l’info, il faut simplifier :
    Non. Ce n’est pas l’excès mais la rétention d’information qui tue la collaboration, en particulier la rétention involontaire basée sur l’illusion “ce que je sais les autres le savent aussi, il est donc inutile d’en parler”. Et si la réalité est complexe, il est contre-productif de chercher à en simplifier la représentation à outrance. Comprendre ensemble, voir ensemble, agir ensemble.
  2. Pour produire deux fois plus, il faut évidemment deux fois plus de monde.
    Non. Pour produire deux fois plus Il suffit de trouver et d’éliminer à peine 10 % des gaspillages inhérents au fonctionnement aberrant actuel. Démontré des centaines, des milliers, des millions de fois par les millions de personnes qui ont essayé à travers le monde, depuis des dizaines d’années que le lean existe. Mais toujours aussi in-croyable.
  3. Sur un grand projet, on finit toujours par être obligé de sacrifier soit la qualité, soit les délais, soit les coûts.
    Non. Sacrifier la qualité amène immanquablement à sacrifier les délais, donc les coûts. Trois pour le prix d’un seul !  L’illusion du quick and dirty aboutit immanquablement dans les faits à disgusting and so late.
  4. Mieux vaut commencer par le plus compliqué, comme cela tout le reste sera beaucoup plus facile ensuite.
    Non. Il ne viendrait à l’idée de personne de commencer la découverte des mathématiques par le plus compliqué, comme les équations de Shroedinger, de Maxwell, ou de Black et Sholtes, au motif que le théorème de Thales serait plus facile à comprendre ensuite, même si c’est vrai. Et pourtant on continue.
  5. Éviter de rédiger une documentation de toute manière toujours obsolète, c’est éviter un gaspillage.
    Non. Se passer de documentation, en particulier en exploitation, est bien évidemment le meilleur moyen de créer des montagnes d’erreurs à corriger sans la moindre boussole : pour éviter la traversée du Jura une fois, on devra escalader le Mont Blanc chaque jour. Excellent choix, puisque ce sont deux équipes différentes.
  6. La vérité est dans le code et nulle part ailleurs.
    Non. La seule vérité dans le code, c’est qu’il mériterait un bon refactoring qu’on ne trouve jamais le temps de réaliser. Cf point 14.
  7. C’est toujours le plombier précédent qui a fait du sale boulot.
    Oui. Plombier ou dev, PO ou chef de projet, manager ou DSI, il a toujours soigneusement appliqué les 15 autres préceptes en étant convaincu de faire bien.
  8. Les erreurs, en particulier humaines, sont inévitables.
    Non. Presque toutes les erreurs humaines ont une cause racine évitable. Il faut juste chercher un peu plus loin que la simple réponse au premier pourquoi ?
  9. Les incidents de production sont chaque fois différents.
    Non. Si les manifestations d’un incident en production sont très souvent différentes, leurs causes racines tournent toutes autour des mêmes familles de banalités crasses : absence de monitoring, de tests, de maintenance préventive, de gestion de l’obsolescence, de séparation homme-machine, de formation, de formalisation de la connaissance ou de standard. Qui se résument à une seule : absence de budget, donc de volonté, de ne rien céder sur la qualité. Point.
  10. Zéro défaut, c’est juste impossible.
    Non. Dans l’industrie on compte les défauts en ppm (partie par million), quand dans l’industrie logicielle on les compte en ppc (partie par centième, ou encore pourcentage) soit 1 000 000 / 100
    = une tolérance à l’erreur 10 000 fois plus élevée. Impossible, vraiment le zéro défaut ?
  11. Avec une bonne réorganisation, on résout beaucoup de problèmes.
    Non. On n’aura rien amélioré du tout avec une reorg : ni le processus, ni la manière de l’opérer, ni les connaissances des collaborateurs, ni les pratiques managériales, sauf par grand hasard. On aura juste dégradé les réseaux et collaborations informelles existantes et repoussé l’acceptation du problème à la troisième enveloppe.
  12. Le plus important, c’est d’éviter que les gens ne perdent du temps à se tourner les pouces sans rien produire.
    Non. Le plus important, c’est d’éviter que le flux de production ne soit interrompu, ce qui n’a rien à voir avec une soi-disant “optimisation” de l’activité des personnes.
  13. Si on pouvait recruter plus d’experts bien formés, ça irait beaucoup mieux.
    Non. Il n’y a aucun expert disponible dehors ; les seuls experts du sujet sont ceux qui triment chez nous sans répit depuis trois ans sur le sujet. Donc le problème est ailleurs. Peut-être dans le temps riquiqui que nous consacrons à former efficacement ceux de nos collaborateurs moins experts, sans parler des prestataires ?
  14. Charger les gens à 110 % c’est les rendre plus efficients.
    Non. Charger au maximum les équipes, c’est les empêcher délibérément de prendre le recul, i.e. le temps nécessaire pour résoudre définitivement certains de leurs irritants. La plus grande, et la plus classique des erreurs managériales, sans doute possible.
  15. Le plus important dans une réunion c’est de la finir à l’heure pour ne pas démarrer en retard la suivante.
    Non. Dans une réunion l’important c’est de faire participer les bonnes personnes sans en oublier ni en manquer.
  16. Le client ne sait jamais ce qu’il veut, rien ne sert de perdre trop de temps avec lui ; mieux vaut un PO ou une AMOA qui parle en son nom.
    Non. Le client sait très bien ce qu’il veut. C’est nous qui ne nous intéressons pas vraiment à ses usages, au motif fréquent que ce serait vraiment trop “chronophage”.
  17. Il vaut mieux ne pas participer à une réunion d’une heure trente si c’est pour ne s’exprimer que 5 minutes, on aura évité de perdre 1h25 de son temps.
    Non. Il vaut mieux disposer au plus tôt des informations qui nous auraient évité une erreur de conception d’architecture remettant en cause toute la réalisation du projet de 18 mois à dix jours du « go live ».

Une pensée émue pour tous ces grands projets Louvois, Scribe, Sirhen, ONP, LUMM, dégommés dans les rapports de la Cour des Comptes : hommage aux grands projets tombés au champ de déshonneur de l’IT, embourbés dans ces 17 biais cognitifs si bien partagés.


Vous souhaitez être accompagnés ou connaître nos offres ? Contactez-nous à l’adresse contact at operaepartners point com, par téléphone au 01 40 05 96 88 ou avec le formulaire ci-dessous :


Value in – value out

Value in – value out

Fred Mathijssen, Director of Technology de Nike Europe, avait fait afficher dans la salle de son management visuel, en grand :

« 1 euro investi ici rapporte 1 200 euros. »

Il nous a expliqué que le chiffre était parfaitement inexact mais que c’était le résultat du premier calcul de ROI conduit par ses équipes. Embarrassées par l’affichage, les équipes avaient essayé de mieux comprendre quelle valeur apportait l’informatique et, rapidement, le ratio avait diminué pour atteindre un niveau raisonnable, toujours enthousiasmant, et qui restera confidentiel.

Cela m’a amenée à réfléchir à une notion de « valeur in – valeur out » :

  • Valeur in : est-ce que je suis capable de produire la même valeur, avec des moyens internes (« in ») plus faibles ?
  • Valeur out : est-ce que j’apporte plus de valeur aux bénéficiaires de mes services ?
Lire la suite « Value in – value out »

Le MVP, une bonne pratique lean

Le MVP, une bonne pratique lean

Le Minimum Viable Product (MVP) est une percée dans le monde de la conception de produits numériques. Le produit se construit comme une suite de poupées ukrainiennes, d’une petite (le MVP) vers une plus grande qui peut l’absorber et ainsi de suite jusqu’au produit final. Travailler en MVP sécurise à la fois le service rendu par le produit et la qualité du produit.

Le Minimum Viable Product (MVP) a du sens dans le domaine suivant : construire une stratégie de construction d’un produit numérique qui sécurise à la fois le service rendu par le produit et la qualité du produit. Le MVP sécurise beaucoup d’aspects de la conduite de projet : la définition du produit cible, l’identification très en amont des difficultés techniques, la collecte des dépendances qu’il faudra traiter, un meilleur étalement de la charge pour les testeurs, un début de formation des utilisateurs, un identification précoce des éventuelles erreurs de conception,  etc.

Nous vous proposons dans cet article plusieurs bonnes pratiques issues de notre expérience.

Lire la suite « Le MVP, une bonne pratique lean »

Comment le pilotage de la performance au quotidien favorise la réussite de l’équipe

Comment le pilotage de la performance au quotidien favorise la réussite de l’équipe

Quelle que soit son activité, réussir son année commence par réussir chaque journée. L’application de ce principe à une équipe, nécessite au préalable de définir les critères d’une journée réussie pour cette équipe.

Pour ce faire, elle doit d’abord s’interroger sur sa mission et sur sa participation aux principaux enjeux de l’entreprise afin d’identifier les indicateurs et les objectifs qui concrétiseront cette réussite au quotidien, et dont l’atteinte pourra faire sa fierté.

Lire la suite « Comment le pilotage de la performance au quotidien favorise la réussite de l’équipe »

Initiation au Lean : rendez-vous le 31 mai à Paris 19e

Initiation au Lean : rendez-vous le 31 mai à Paris 19e

Le retour en présentiel de notre « atelier cocottes » a confirmé le succès du concept d’initiation ludique au Lean management. Si vous n’avez pas encore testé le jeu, rendez-vous le 31 mai prochain dans nos locaux parisiens pour une matinée où l’on apprend :

  • à comprendre ce que veut son client,
  • à voir ensemble les obstacles que rencontrent les collaborateurs sur le terrain,
  • à réfléchir en équipe pour trouver des axes d’amélioration.

Ce jeu permet aussi de prendre conscience de l’intérêt de la formation sur le terrain et de comprendre en quoi le Lean management est un vrai levier d’amélioration de la qualité de vie au travail.

Gratuit et sur inscription, le jeu se déroulera de 9h à 12h30 dans les locaux d’Operae Partners à Paris 19e, il sera suivi d’un moment d’échanges entre participants autour d’un buffet.

Pour vous inscrire, rendez-vous sur ce lien : https://hs.operaepartners.fr/inscription-atelier-lean-31-mai-2022

Des verbatim de la dernière édition :

« On apprend de façon simple et ludique ». « Cela permet de remettre le client au centre » « C’est concret, si je remplace les cocottes par ce que je produis moi, je me projette dans mon job ! »

« On ne nous a jamais dit que la qualité c’était important avant de mettre en prod »

« On ne nous a jamais dit que la qualité c’était important avant de mettre en prod »

C’est l’histoire de 3 équipes super. 3 équipes dans 3 entreprises radicalement différentes. 3 équipes dans 3 villes différentes. 3 équipes qui ne se connaissent pas mais qui ont en commun d’avoir la responsabilité de mettre en production un gros système sur lequel elles travaillent depuis 2 ans.

Et sur lequel elles ont beaucoup travaillé, n’ont pas compté leurs heures. Les membres de ces équipes voulaient tous réussir leur projet, faire réussir leur entreprise et livrer le projet à la date promise, « respecter la deadline », « le time to market », « la date de mise en prod ». Ils ont donc codé, débuggé, corrigé, recodé, testé, corrigé, re-livré (parfois le soir, la nuit, le week-end)… et fiers d’arriver devant leur comité de pilotage à temps – certes avec des bugs, « mais pas tant que ça ! » pour présenter leur projet, leur bébé… ils se sont vu recevoir un « NO GO » en pleine face.

Lire la suite « « On ne nous a jamais dit que la qualité c’était important avant de mettre en prod » »

Comment diviser par 4 le temps de cycle des user stories ? Rendez-vous le 21 avril à 19 heures

Comment diviser par 4 le temps de cycle des user stories ? Rendez-vous le 21 avril à 19 heures

Venez écouter Tycho Tatitscheff, architecte développeur chez BAM expliquer comment il est parvenu à atteindre le zéro bug en travaillant sur la dette technique et les meilleures pratiques de développement logiciel selon la démarche Lean IT.

BAM est l’agence experte du développement de solutions business sur mobiles.

Ce meetup se déroulera à partir de 19h le 21 avril chez Operae Partners à Paris 19e et à distance sur Zoom.

Inscrivez-vous ici : https://www.meetup.com/fr-FR/Lean-IT-Paris/events/284924321

Comment embarquer une équipe dans l’amélioration continue ?

<strong>Comment embarquer une équipe dans l’amélioration continue ?</strong>

Donnez-lui plus d’autonomie et les moyens de résoudre ses problèmes

Vous voulez transformer et améliorer votre entreprise de façon pérenne et continue ? Alors le Lean Management est fait pour vous !

Comment s’y prendre ? Le kaizen (ou amélioration continue) peut vous montrer le chemin 😉

Cette démarche marque un tournant pour l’organisation : elle lui permet de devenir apprenante. Avec le kaizen, les collaborateurs deviennent véritablement acteurs, autonomes dans le pilotage de leurs tâches, processus, indicateurs et résolutions de problème.

Lire la suite « Comment embarquer une équipe dans l’amélioration continue ?« 

Valeur métier dans l’IT : la quête du Graal !

Approches agiles, démarche produit, feature teams, lean startup … toutes ces approches ont en point commun la volonté de livrer le maximum de valeur pour ses clients ou utilisateurs.

Mais quelle est cette valeur et comment atteindre ce Graal ? Comment les équipes peuvent-elles atteindre cet objectif en plus des habituels correctifs, maintenance, dette technique…?

Lire la suite « Valeur métier dans l’IT : la quête du Graal ! »

Lean management et vente à distance

Lean management et vente à distance

Dans le domaine de la vente à distance, nous avons accompagné des managers dans leurs résolutions de problèmes. Un des PDCA portait sur une perte de chiffre d’affaires car les télévendeurs n’exploitaient pas toutes les opportunités de vente. Dans ce cas précis, on parle d’un montant de 600 000 euros de ventes non réalisées par une équipe de 12 télévendeurs.

Lire la suite « Lean management et vente à distance »