CEO : la qualité logicielle est trop importante pour être laissée à votre CTO

TL;DR: produire du logiciel de qualité implique des aspects organisationnels qui dépassent la Tech et peuvent réduire à néant les efforts du CTO.

Posons les choses :

• Vous dirigez une entreprise qui vend du logiciel ou repose de manière essentielle sur du logiciel ;

• Vous constatez ou suspectez des problèmes de qualité (bugs, explosion des délais et des coûts, voire démissions en cascade) ;

• L'informatique n'est pas votre métier.

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é n'est pas un sujet informatique : c'est un sujet d'entreprise. Une équipe ou des équipes agiles travaillant en village gaulois au sein d'une entreprise qui ne l'est pas, ça ne marche pas. À cause des adhérences : si les décisions stratégiques sont prises en ComEx et que ce dernier se réunit tous les 2 mois, c'est mort.

• Parce que l'Agilité n'est pas un sujet Tech, c'est autant un sujet Produit : imaginez des développeurs essayant d'être agiles quand le Produit pense waterfall. Quelles sont les chances que ça marche ? D'ailleurs, je ne suis même pas sûr de comprendre la distinction entre équipes Produit et Tech tant les deux avancent ensemble.

• 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 ; constituer une équipe Support/Recette en charge du test de tous les actifs informatiques, c'est se tirer une balle dans le pied ; constituer une équipe DevOps, c'est un contre-sens 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…

• Parce que l'informatique est une affaire de personnes et que c'est parfois le CTO qu'il faut coacher ! Si certain(e)s se montrent ouverts à l'idée, vous conviendrez avec moi que la position d'un coach mandaté par le CTO rend les choses moins évidentes quand il s'agit de lui expliquer qu'il est le facteur limitant…

Alors certes, il y a toujours des problèmes techniques, il y a toujours des choses à améliorer et à parfaire. Mais l'informatique est rarement le seul sujet. Aussi, s'il veut avoir la latitude de travailler les problèmes à la racine, un expert en qualité logicielle (Bibi, pour vous servir 💜) 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.