La qualité logicielle est trop importante pour être laissée à votre CTO (ou l'art de se tirer une balle dans le pied)
Amis CEO, posons les choses :
-
Vous dirigez une entreprise qui vend ou repose de manière essentielle sur du logiciel ;
-
Vous constatez ou suspectez des problèmes de qualité (bugs, délais/coûts en nette augmentation, démissions en cascade) ;
-
Et surtout, votre expertise n’est pas l’informatique.
Naturellement, vous discutez avec votre CTO et cherchez à comprendre. S’il y a des bugs, c’est qu’il y a des failles dans le test des applications. Vous vous dites qu’un coach technique (coach « Craft ») pourrait l’aider. À moins que ce soit un problème d’agilité, auquel cas vous lui suggérez de faire appel à un coach agile. Dans tous les cas, vous décidez d’allouer une rallonge budgétaire à la Tech, en espérant un retour sur investissement prochain 🤞
Bravo, vous venez de vous tirer une balle dans le pied, car vous vous interdisez d’emblée de traiter 70% des causes de la non-qualité logicielle.
Pourquoi ?
-
Parce que l’Agilité est un sujet fonctionnel avant d’être un sujet technique : la majeure partie des bugs tient au fait que la conception fonctionnelle a été bâclée, quand elle a eu lieu. La majeure partie de l’argent jeté par les fenêtres tient au fait d’avoir travaillé gaiement pendant 12 mois sur des hypothèses non vérifiées (effet tunnel).
-
Parce que l’Agilité est un sujet d’entreprise : une équipe informatique « agile » travaillant en village gaulois au sein d’une entreprise non-agile, ça ne marche pas. Si les décisions stratégiques sont prises par un comité qui se réunit une fois par mois, c’est mort, la friction entre cette équipe et le reste de l’entreprise sera trop grande.
-
Parce que le problème est le plus souvent organisationnel : l’informatique comme centre de coûts, c’est se tirer une balle dans le pied, again ; constituer une équipe Recette en charge du test de vos actifs informatiques, c’est se tirer une balle dans le pied ; constituer une équipe DevOps, c’est un contresens et c’est encore se tirer une balle dans le pied. Je pourrais multiplier les exemples, mais il n’y a plus assez de pieds depuis longtemps…
-
Parce que l’informatique est une affaire de personnes et que c’est parfois sur le CTO lui-même/elle-même qu’il faut agir. Vous conviendrez avec moi qu’un consultant tenant son mandat du CTO n’est pas vraiment incité à le contredire, comme son éthique le lui commanderait pourtant.
Alors certes, il y a toujours des problèmes techniques, il y a toujours des choses à améliorer et à parfaire. Mais le développement en tant que tel est rarement le cœur du sujet. Aussi, s’il veut avoir la latitude de travailler les problèmes à la racine, le consultant doit impérativement tenir son mandat du dirigeant de l’entreprise elle-même, et non du CTO.
C’est d’ailleurs l’erreur que font tous les coachs « techniques », et même les coachs « agiles » : ils invoquent des moyens au lieu de parler de la finalité, la qualité logicielle.