00:00:04 Introduction à la Frankensteinisation logicielle.
00:00:35 Impact de la Frankensteinisation logicielle sur les logiciels B2B.
00:01:31 Comment les demandes des clients influencent la Frankensteinisation logicielle.
00:02:32 « Cicatrices » sur le logiciel et leurs implications.
00:05:33 Coûts de maintenance de la Frankensteinisation logicielle.
00:08:00 Défis et coûts des nouvelles fonctionnalités logicielles.
00:08:57 Fonctionnalités sans complexité : perspectives B2C.
00:10:36 Problèmes liés à l’approche B2B des solutions logicielles.
00:13:18 L’expérience de Lokad : bien vs rapide & dette technologique.
00:15:14 Envision : la solution de Lokad à la complexité.
00:16:30 Script spécifique au domaine : éviter les limitations et les conflits.
00:17:43 Aborder le bloatware logiciel dans les supply chain.
00:18:01 Stratégies pour simplifier les logiciels complexes.
00:20:54 Gérer la ‘masse technologique’ dans les systèmes logiciels.
00:22:00 Synergie entre IT, supply chain et marketing dans les changements de système.
00:22:43 Problèmes liés à une personnalisation logicielle excessive.
00:23:48 Tester l’intégrité du fournisseur de logiciels via la personnalisation.
00:24:00 Gagner en influence sur la stratégie de développement produit.
00:26:08 Choisir des logiciels allégés et ciblés pour éviter la personnalisation.
Summary
Sur Lokad TV, Joannes Vermorel présente le concept de Frankensteinisation logicielle, se référant à la façon dont les logiciels B2B évoluent par des modifications hasardeuses qui ne correspondent pas à leur conception originale. Il compare ces changements à des « cicatrices », contribuant ainsi à la création d’un système logiciel composite et évolué. ERPs sont présentés comme un exemple, soulignant le dilemme entre le maintien de l’architecture logicielle et la satisfaction des nouvelles demandes. Vermorel met en garde contre les décisions précipitées, qu’il affirme souvent aboutir à des cicatrices logicielles et à une augmentation des coûts de maintenance. Tout en reconnaissant la complexité inévitable de la gestion logicielle, Vermorel souligne l’importance de s’inspirer des modèles B2C pour contrôler les interactions des fonctionnalités. La réponse de Lokad à ce problème est “Envision”, un langage de programmation spécifique au domaine qui sépare les problèmes d’infrastructure et les problèmes spécifiques au domaine.
Extended Summary
Dans le dernier épisode de Lokad TV, la conversation tourne autour du concept de Frankensteinisation logicielle, un terme introduit par Joannes Vermorel, le fondateur de Lokad. Il l’utilise pour décrire la transformation des logiciels B2B au fil du temps, en particulier les logiciels à longue durée de vie et ceux de supply chain, alors qu’ils évoluent au gré des négociations continues et des grands contrats entre les fournisseurs de logiciels et leurs clients.
Vermorel explique que la Frankensteinisation logicielle se produit lorsque des ajustements sont apportés au logiciel en réponse aux demandes des clients. Ces modifications sont souvent en décalage avec l’architecture, la philosophie et la conception originales du logiciel. En conséquence, le logiciel accumule ces altérations, ou « cicatrices », au fil du temps, le transformant en ce que Vermorel décrit comme un « monstre Frankenstein » - un système logiciel composite et étrangement évolué.
Il souligne en outre que ce phénomène est particulièrement prononcé dans les logiciels de supply chain, mais qu’il est également courant dans de nombreux types de logiciels B2B. Néanmoins, il précise que le terme « cicatrice » ne doit pas être interprété comme intrinsèquement négatif. Ces modifications peuvent améliorer le logiciel en ajoutant de nouvelles fonctionnalités, améliorant ainsi sa performance.
Vermorel donne l’exemple des logiciels Enterprise Resource Planning (ERP), qui partent du principe que la saisonnalité peut être capturée à l’aide de profils fixes de 52 semaines. Ce modèle fonctionne bien jusqu’à ce qu’une demande survienne qui ne rentre pas dans ce cadre, comme la modélisation du Nouvel An chinois, du Ramadan ou de Pâques, qui suivent des calendriers différents et dont les dates changent chaque année.
Dans de tels cas, le fournisseur de logiciels est confronté à un compromis. Il peut répondre à la nouvelle demande en intégrant une solution « bricolée », qui ne s’intègre pas harmonieusement dans l’architecture du logiciel mais fournit la fonctionnalité requise. Cependant, cette approche conduit souvent à davantage de « cicatrices », contribuant à la Frankensteinisation du logiciel.
Soulignant le rythme rapide des négociations avec les clients clés dans le secteur des logiciels, Vermorel avertit que l’urgence peut involontairement conduire à des « cicatrices logicielles ». Il définit ce phénomène comme un processus où l’implémentation précipitée de fonctionnalités augmente la complexité et le coût de maintenance du logiciel au fil du temps.
En expliquant les subtilités de l’architecture logicielle, Vermorel note que chaque ligne de code ou fonctionnalité nécessite une maintenance. À mesure que davantage de fonctionnalités sont ajoutées, les interconnexions deviennent plus complexes, entraînant un « problème de complexité quadratique ». Essentiellement, les interactions potentielles augmentent de manière exponentielle avec le nombre de composants, provoquant toutes sortes de problèmes tels que des bugs, des plantages et des menaces de sécurité.
Vermorel insiste sur l’importance d’une architecture logicielle méticuleuse pour contrôler le nombre d’interactions entre les fonctionnalités. Il explique que l’objectif devrait être de ne doubler que la maintenance requise lorsque le nombre de fonctionnalités est doublé, plutôt que de la quadrupler ou plus, comme cela survient souvent lorsque le développement est précipité.
Lorsqu’on lui demande comment les entreprises de logiciels peuvent introduire de nouvelles fonctionnalités sans ajouter une complexité excessive, Vermorel suggère de s’inspirer des entreprises de logiciels B2C telles que Google et Netflix. Elles prennent le temps de comprendre les problèmes spécifiques qu’elles tentent de résoudre et conçoivent des solutions qui répondent à une large catégorie de problèmes similaires. Il oppose cette approche au monde B2B, où les clients arrivent souvent non seulement avec des problèmes mais aussi avec leurs propres solutions proposées.
En réaction à cette prise de conscience, Lokad a conçu une solution unique : un langage de programmation spécifique au domaine appelé “Envision”. L’objectif d’Envision est de séparer les problèmes d’infrastructure des problèmes spécifiques au domaine, permettant à Lokad de gérer l’ajout et la maintenance de nouvelles fonctionnalités de manière plus efficace sans ajouter une complexité excessive.
Vermorel continue d’élaborer sur la manière dont les produits logiciels, notamment dans le secteur de la supply chain, font souvent face à un problème de gonflement dû à une personnalisation poussée pour chaque client. Alors que la personnalisation vise à fournir des solutions sur mesure, elle aboutit souvent à un système complexe et difficile à gérer nécessitant un effort considérable pour être maintenu et mis à jour. Pour éviter cela, Vermorel explique comment Lokad utilise un script spécifique au domaine, Envision, pour créer des solutions hautement personnalisées, mais gérables, pour leurs clients.
Abordant le sujet de la complexité logicielle, Chandler s’interroge sur ce que les entreprises de logiciels peuvent faire pour éviter le bloatware. Vermorel répond que le scénario dépend du fait qu’une entreprise ait accès ou non à son logiciel. Sinon, l’entreprise doit faire face à la complexité du logiciel acquis. Cependant, si l’accès est possible, le logiciel peut être simplifié en identifiant et en supprimant les éléments inutilisés, réduisant ainsi considérablement la complexité.
En changeant de perspective pour se concentrer sur les responsabilités des services IT et des Supply Chain Scientist, Vermorel observe que, bien que le personnel IT possède généralement le savoir-faire technique, il manque souvent de compréhension de la valeur commerciale de certaines fonctionnalités. Cela entraîne un décalage entre les fonctionnalités nécessaires et celles qui ne le sont pas. Par conséquent, les décideurs doivent collaborer étroitement avec l’IT pour prioriser et simplifier le système.
Vermorel donne des conseils aux dirigeants de supply chain souhaitant investir dans de nouveaux logiciels. Il met en garde contre l’exigence d’une personnalisation excessive, car elle peut engendrer davantage de problèmes. Il recommande aux dirigeants de maintenir un contact régulier avec les chefs de produit ou les CTO du fournisseur afin de communiquer directement leurs besoins. Plutôt que d’imposer des fonctionnalités spécifiques dans un contrat, l’objectif devrait être de présenter les problèmes à ceux capables d’ingénier des solutions.
Enfin, Vermorel conseille aux entreprises de choisir des logiciels qui excellent dans un domaine, plutôt que d’opter pour des solutions globales. Cette approche ciblée facilite les améliorations et réduit la complexité causée par une pléthore de fonctionnalités interconnectées. En restant proche de ceux qui contrôlent la feuille de route et en choisissant des logiciels fortement ciblés, les entreprises peuvent mieux gérer la complexité et améliorer la productivité.
Transcription Complète
Kieran Chandler: Today, we’re going to be tackling the subject of software Frankensteinization. So, Joannes, this is a topic that’s fairly difficult to pronounce, so I’m probably going to leave this one to you. I’m assuming we’re not talking about a big green monster today. What exactly are we talking about?
Joannes Vermorel: We are talking about a process that drives the evolution of software, specifically B2B software, and even more specifically, supply chain software. It mostly applies to long-lived B2B software. This process, which I refer to as “Frankensteinization,” evolves the software over the years with an ongoing stream of large deals negotiated between the software vendors and its clients. The interesting thing, where the “Frankensteinization” part comes from, is that every large deal negotiated between the vendor and one of its large clients is likely to leave a scar in the software.
It’s a gradual process where a vendor negotiates with a large company. The large company has demands, and in order to meet those demands, adjustments are made to the software that don’t fit with the overall architecture, philosophy, or original design. The feature gets added, but in a somewhat hackish way. That’s a scar. The problem is, if you repeat this process over and over for years, what you end up with in terms of software is, in a way, a Frankenstein monster. It’s a beast made of many scars that look somewhat hideous and super composite. It evolves in weird ways, and that’s how you end up with these Frankenstein software monsters. This is something that happens in most databases, but in supply chain software, it’s like it’s on steroids.
Kieran Chandler: Let’s talk about these scars, as you refer to them. What do they look like? I mean, they’re improving the software, right? They’re adding extra features. Is that such a bad thing?
Joannes Vermorel: Yes, obviously that’s the trade-off. You want to improve your software, but a piece of software is a very complicated object. It’s not like a building where you can just add a floor or expand nicely. Software comes with lots of inviolable design assumptions made very early on that give the software some integrity—architectural integrity.
Let’s take many ERPs as an example, which were built around the idea of capturing seasonality with profiles that are exactly 52 weeks, representing a given year. So, you literally have a table with 52 columns, one column per week, and you have all these seasonality profiles that you can apply to any item you’re producing or selling. But what if you want to model something like Chinese New Year? It doesn’t fit into this 52 weeks grid because it’s going to move from one year to the next according to the traditional Chinese calendar, not the Gregorian calendar. You will face similar problems with Ramadan or even Easter.
You have this very nice assumption that can fall apart when you face a demand that doesn’t fit into your framework. And that can take many forms. The problem is that as a software vendor, you don’t actually have the time to rewrite your entire software stack so that these new features integrate into your architecture in a completely native way. In the end, it’s a bit hackish.
Kieran Chandler: You’re negotiating with an important client, so you don’t have years to close the deal. And then, you don’t have years to deliver the future either. So, things have to be done in a relative emergency every single time, just due to the fact that it’s actually a bigger than usual negotiation to close a sale. Things are rushed almost by design. But when does something become a scar and when does something become a good feature? Because all these software’s have got to evolve, they’ve got to change, they’ve got to work for their clients. So what differentiates the two? How do you know that something you’re developing isn’t going to become a scar?
Joannes Vermorel: The question is how much will it cost in terms of maintenance? Every single line of code that exists in your big enterprise software is something that you will have to maintain. One thing that people do not always realize, even software professionals, is that the software is like intricate machinery where every single part has to interact somehow with all the other parts. You have a quadratic complexity problem.
What does that mean? It means that if I have ten parts, I’ve basically got about 100 potential interactions, you know, 10 x 10. If I have a thousand parts and they are all interacting, then I have 1,000 by 1,000 interactions. Every potential interaction is a recipe for all sorts of problems: security issues, bugs, crashes, incorrect results, or just massive slowdowns in the software.
When you add more parts, you increase the number of potential interactions between the parts in your software, and it increases much more rapidly than the number of parts. And when I say parts, you can think of features, capabilities, screens, data options, or entries.
Si vous êtes très prudent avec votre architecture logicielle, vous pouvez préserver le nombre d’interactions entre vos fonctionnalités afin de le garder sous contrôle. Si vous doublez le nombre de fonctionnalités dans votre logiciel, vous ne voulez pas multiplier le nombre d’interactions par 4, car cela signifie que lorsque vous doublez le nombre de fonctionnalités, vous quadruplez en réalité la quantité de maintenance à effectuer.
Mais c’est très difficile. Quand vous êtes pressé, lorsque vous doublez le nombre de fonctionnalités, vous multipliez en réalité par 4 voire plus l’effort que vous devez investir dans la maintenance. Au fil du temps, le coût de la maintenance explose, et votre capacité à déployer de nouvelles choses diminue de plus en plus. Chaque fois que vous introduisez une nouvelle fonctionnalité, cela déclenche une vague entière d’incompatibilités et d’interactions inattendues et bizarres entre différentes parties, parce qu’elle n’a pas été entièrement réfléchie. La douleur s’intensifie avec le temps.
Kieran Chandler : D’accord, alors pensons du point de vue de cette entreprise de logiciels. Comment peuvent-ils introduire ces nouvelles fonctionnalités ? Comment peuvent-ils mettre en œuvre ces fonctionnalités pour garder leurs clients satisfaits, sans introduire cette couche supplémentaire de complexité ? Que peuvent-ils faire ?
Joannes Vermorel : Je pense que la leçon vient du monde des logiciels B2C. Google ne déploie pas de nouvelles fonctionnalités pour Google Search, ni Netflix de nouvelles fonctionnalités pour Netflix simplement parce qu’ils signent un nouveau client. Ils ne prennent pas de nouveaux clients et ne commencent pas à discuter avec eux en disant, “Oh, si nous n’avons pas ces fonctionnalités, alors vous ne vous inscrirez pas chez nous, donc nous devons le faire maintenant.”
Ils ne fonctionnent pas de cette manière. Ils pensent à ce qu’est le domaine, quel est le problème spécifique qu’ils essaient de résoudre. Ils essaient d’avoir une perspective très globale sur ce problème, puis réfléchissent.
Kieran Chandler : Vous évoquez une approche qui vise à générer des solutions pour l’ensemble d’une catégorie de problèmes, plutôt qu’un simple micro-problème. Cela nécessite de réarchitecturer le logiciel afin de répondre à un large éventail de problèmes similaires. Et cela arrive tout le temps. Lorsqu’on interagit avec des clients, on écoute leurs problèmes, pas leurs solutions proposées. En comparaison, dans le monde du B2B, les clients ont tendance à présenter non seulement leur problème, mais aussi une solution. Cette solution peut ou non s’intégrer à votre pile logicielle existante ou à l’évolution de ce problème. Est-ce donc une question de ne pas vraiment écouter ?
Joannes Vermorel : Précisément, il s’agit davantage de comprendre réellement le problème fondamental plutôt que de se fixer sur une solution particulière. De grandes entreprises comme Google et Netflix en sont d’excellents exemples.
Kieran Chandler : Donc, vous dites que les entreprises n’écoutent pas vraiment. Mais qu’en est-il de ces pop-up agaçants demandant un retour d’information ? Est-ce que quelqu’un les examine réellement ?
Joannes Vermorel : Les pop-ups dont vous parlez sont généralement des fonctionnalités indésirables. Mais il faut reconnaître la contribution d’entreprises comme Google. Ces pop-ups, où vous devez accepter les conditions, n’étaient pas leur choix. Ils ont été contraints de les mettre en place en raison des contraintes réglementaires. Donc, bien qu’il puisse sembler que ce soit une fonctionnalité bizarre, ce n’était pas de leur fait. De plus, si l’on regarde qui a gagné sur le web, ce ne sont pas les entreprises avec des publicités super agaçantes. Ce sont celles comme Google, qui avaient des publicités claires et discrètes. Ils pensaient à leurs clients au lieu de dévaloriser leur produit avec quelque chose d’aussi agaçant. Ils prennent le temps de bien réfléchir à leurs fonctionnalités.
Kieran Chandler : Dans les entreprises de logiciels B2B, en particulier dans le supply chain, il y a beaucoup de diversité. Il peut y avoir des centaines de scénarios, et souvent à la dernière minute, les gens négocient de nombreuses fonctionnalités qui finissent presque toujours par s’avérer être de mauvaises idées six mois plus tard. Alors, seriez-vous d’accord pour dire que la Frankensteinisation du logiciel est une mauvaise chose ? Et si oui, qu’avez-vous fait différemment chez Lokad pour éviter ce problème ?
Joannes Vermorel : Absolument, la Frankensteinisation du logiciel est un problème. Durant les premières années chez Lokad, nous avons été confrontés à ce même problème. Ce fut un compromis difficile. Si vous voulez bien faire, cela peut prendre un ou deux ans, ce qui est trop long. Si vous ne le faites pas correctement, vous pouvez conclure en quelques semaines ou mois, mais alors vous vous retrouvez avec une grande cicatrice, un hack laid. Vous finissez par accumuler une dette technique. Ainsi, pendant les premières années de Lokad, nous n’avions pas de solution, mais nous prenions de plus en plus conscience du problème. Même en tant que startup, la dette technologique s’accumulait, ce qui était préoccupant. C’est à ce moment-là que j’ai réalisé que la tendance était défavorable. En regardant quelques décennies plus loin, je pouvais voir comment les concurrents, avec leurs logiciels gonflés pour l’optimization de la supply chain, ajoutaient sans cesse de nouvelles fonctionnalités sans aucune cohérence.
Kieran Chandler : Il semble que les entreprises de logiciels ajoutent toujours de nouvelles fonctionnalités, et le résultat final peut être un produit confus et gonflé. Pouvez-vous nous parler de votre approche de ce problème chez Lokad ?
Joannes Vermorel : Absolument. La manière dont un logiciel tend à devenir gonflé est d’ajouter une mauvaise fonctionnalité à la fois. Si vous continuez sur cette voie pendant 20 ans, vous finissez avec un produit monstrueux. Ce n’est pas que les développeurs soient incompétents ou insensés, ils font simplement un travail convenable par étapes, en essayant de gagner un client à la fois. Cependant, cette approche polit le logiciel un client à la fois, et le résultat final est généralement très, très mauvais.
Nous avons donc décidé d’adopter un angle complètement différent chez Lokad, ce qui a conduit à la création d’Envision, notre langage de programmation spécifique au domaine. Avec Envision, nous avons effectivement scindé tous les problèmes. Nous avons séparé l’infrastructure, l’infrastructure de données, et l’infrastructure de machine learning. Ce sont des produits à long terme que nous souhaitons maintenir et améliorer, et c’est un effort pluriannuel à chaque fois que nous décidons de les changer et de les améliorer.
Ensuite, séparément, pour chaque client, nous créons une implémentation entièrement sur-mesure rédigée en scripts dans Envision. Comme Envision est spécifiquement conçu pour l’optimization de la supply chain, nous pouvons écrire quelque chose de totalement personnalisé pour chaque client, avec une haute productivité, tout en le rendant complètement sur-mesure.
Nous partons donc d’une feuille blanche, la personnalisons complètement, et ensuite nous n’avons pas à faire face à une situation où le client nous demande quelque chose que nous ne prenons pas en charge. Grâce aux capacités programmatiques d’Envision, si nous devons faire quelque chose de spécial pour un client, le pire des cas est que le script que nous écrivons ne soit pas aussi compact que d’habitude. Cependant, nous pouvons toujours bénéficier d’une infrastructure conçue pour faciliter la résolution de certains types de problèmes.
Si vous introduisez des capacités programmatiques avancées spécifiques au domaine dans votre plateforme, alors soudainement vous n’avez plus à précipiter une négociation qui laissera une cicatrice sur votre produit. Vous pouvez effectuer la personnalisation dans votre environnement programmatique, qui est sur-mesure pour chaque client, puis continuer à déployer des mises à niveau pour votre plateforme selon votre propre calendrier, qui ne correspondra très probablement pas au calendrier de vos clients.
Kieran Chandler : Vous avez identifié ce problème assez tôt. Quels conseils donneriez-vous aux autres entreprises de logiciels confrontées à ce genre de bloatware ? Peuvent-elles y remédier ? Devraient-elles commencer à supprimer certaines de ces fonctionnalités pour simplifier les choses ?
Joannes Vermorel : La situation dépend de plusieurs facteurs. Si vous êtes une grande entreprise qui possède le logiciel, tel qu’un WMS, ERP, MRP, etc., il se peut que vous n’ayez même pas accès au logiciel lui-même, ce qui pourrait n’être qu’un produit du fournisseur. Si vous n’avez pas accès au produit, alors vous êtes coincé avec la complexité du logiciel que vous avez acquis.
Si vous avez accès au logiciel et souhaitez le simplifier, alors oui, vous devriez commencer par examiner toutes les choses que vous n’utilisez pas et les éliminer de manière agressive. Beaucoup de gens craignent généralement de supprimer des parties d’un logiciel existant parce qu’ils sont préoccupés par la perte de certaines capacités. Il est vrai que si vous supprimez des capacités, vous les perdez. Cependant, si vous éliminez quelque chose qui est presque jamais utilisé, vous pouvez également supprimer des catégories entières de problèmes qui étaient causés par la simple présence de cette petite fonctionnalité.
Nous voyons souvent des implémentations ERP chez Lokad avec littéralement des milliers de tables. Vous pouvez avoir un ERP avec, disons, cinq mille tables. Chaque table peut comporter entre 10 et 200 champs, entraînant une complexité massive. Même la simple sauvegarde de l’ERP peut être incroyablement compliquée.
Kieran Chandler : Parce que vous avez tellement de tables, il vous faut une table pour stocker la liste des tables et autres. C’est le genre de situation où, si vous pouvez identifier des tonnes de tables qui ne sont même plus utilisées, ou des écrans qui ne sont plus utilisés, en les supprimant simplement, vous simplifiez tout.
Joannes Vermorel : Exactement, par exemple, si vous devez mettre à niveau d’une version de votre base de données à une autre, l’un des problèmes que vous pouvez rencontrer est que vous devez mettre à niveau des parties de logique qui ne sont plus utilisées par personne. Chaque ligne de code qui existe, qu’il s’agisse de Java, C Sharp, SQL ou autre, est quelque chose que vous devez maintenir tant que la ligne de code existe. Si vous la supprimez, cela signifie que lors de votre prochaine intégration ou migration, les gens n’auront pas à se poser la question de comment migrer cette chose vers la prochaine version du système ou vers un autre système.
Et c’est quelque chose auquel les cadres de supply chain doivent penser. Lors de l’achat d’un logiciel, ils devraient vraiment adhérer au principe de parcimonie - si vous n’en avez pas vraiment besoin, il vaut mieux ne pas avoir cette partie du système. Ce ne sera qu’un fardeau. Il est vital de prêter une attention constante à la masse technologique de la solution que vous acquérez et exploitez.
Cette masse technologique ne vient pas gratuitement. Si vous avez plus d’écrans, vous avez besoin de plus de personnes pour les former. Si vous pouvez supprimer quelques écrans, cela signifierait moins de formation, moins de bugs signalés, moins de conflits avec l’informatique, etc. Il s’agit de gérer la complexité de l’IT, mais la partie difficile est que typiquement, l’informatique n’en a aucune idée car elle n’a pas accès à la valeur commerciale. Elle ne peut pas différencier entre les fonctionnalités réellement nécessaires et celles qui ne le sont pas absolument. Elle ne peut pas traduire les tables, les champs, les écrans ou les capacités en euros ou en dollars. C’est quelque chose que seules les personnes de la supply chain ou du marketing, selon le système concerné, peuvent faire. C’est pourquoi l’IT a besoin du soutien de ces personnes, les décideurs de l’entreprise, pour conduire la priorisation et le changement vers la simplification du système.
Kieran Chandler : Et donc, pour conclure, vous avez mentionné que si je suis un cadre de supply chain qui souhaite investir dans un nouveau logiciel pour mon entreprise, il semblerait que je ne devrais pas vraiment demander autant de personnalisation car cela introduit des problèmes. Alors, que devrais-je rechercher ?
Joannes Vermorel : Oui, demander de la personnalisation ou des fonctionnalités spéciales est comme une recette pour générer des problèmes. Si votre fournisseur de logiciel n’avait pas assez de problèmes propres, vous créez simplement de nouveaux problèmes qui ne feront qu’aggraver la situation. Donc, en réalité, vous ne devriez pas faire cela. Si vous pouvez réellement demander de la personnalisation, ne serait-ce qu’à titre de test, car si le fournisseur s’engage volontairement dans la discussion avec vous sur la personnalisation, cela signifie que le fournisseur n’a aucune intégrité. Cela signifie que le fournisseur fait cela avec chaque client, ce qui veut dire que même si le produit est bon aujourd’hui, dans cinq ans, ce sera un cauchemar.
Premièrement, si vous demandez de la personnalisation, il est bon de le faire et vous devriez vraiment vous attendre à ce que cette demande soit rejetée. Sinon, c’est un problème.
Kieran Chandler : Une chose que les gens devraient demander, ce sont des fonctionnalités spéciales, n’est-ce pas ? Je veux dire, s’il y a une chose à demander, cela pourrait être l’accès au CTO ou au responsable produit du côté du fournisseur. L’inclure dans le contrat, peut-être ? Comme vouloir avoir une réunion avec cette personne pendant deux heures une fois par mois. Pourquoi ?
Joannes Vermorel : Si vous négociez pour avoir un accès direct aux personnes qui élaborent la roadmap du fournisseur, vous pouvez simplement présenter vos changements. Vous n’avez pas besoin de leur imposer votre solution ; présentez simplement votre problème. Car, en tant qu’ingénieurs, que font-ils lorsqu’on leur présente un problème ? Ils commencent à travailler sur une solution. Si vous avez une réunion de routine où vous présentez vos problèmes, vous n’avez pas besoin de négocier pour des fonctionnalités spécifiques dans le contrat. En quelques années, des fonctionnalités commenceront à apparaître dans le produit qui semblent correspondre exactement au problème que vous avez exposé.
Kieran Chandler : Pouvez-vous expliquer un peu plus à ce sujet ?
Joannes Vermorel : Si vous faites le calcul, considérez le CTO d’une entreprise de logiciels. Combien de réunions cette personne peut-elle avoir avec des clients en un mois ? Disons qu’elle peut en avoir au maximum 20. Si vous avez une réunion par mois, vous obtenez essentiellement environ cinq pour cent de la capacité mentale du CTO, qui dirige le développement technologique du fournisseur avec lequel vous travaillez. Cela signifie que vos problèmes bénéficient d’une attention significative.
Kieran Chandler : Alors, quelle est votre suggestion ?
Joannes Vermorel : Ma suggestion, si vous voulez jouer malin, est de vous rapprocher des personnes qui ont le contrôle sur la roadmap. C’est plus intelligent que de négocier précipitamment pour des fonctionnalités défaillantes que vous allez probablement jeter dans six mois parce que votre solution n’était pas bonne ou parce que votre problème a changé. De plus, une autre catégorie de conseil serait d’éviter les logiciels qui en font trop. Vous devez penser à un logiciel qui fait une chose et le fait bien, plutôt qu’à un logiciel avec des capacités étendues qui finit par tout faire de manière médiocre.
Kieran Chandler : Pouvez-vous développer davantage ce point ?
Joannes Vermorel : Il est plus facile d’améliorer un logiciel très ciblé que d’améliorer un cadre gigantesque qui fait tout. Chaque fois que vous allez ajuster quelque chose, pensez au nombre quadratique d’interactions. Si vous avez mille fonctionnalités et que vous en ajoutez une, vous devez considérer toutes les interactions avec les 1 000 fonctionnalités préexistantes. Ainsi, si vous introduisez une fonctionnalité, vous examinez toutes les 1 000 interactions. Cependant, si vous n’avez que dix fonctionnalités et que vous en ajoutez une onzième, il n’y a que dix interactions à revoir. Donc, encore une fois, concentrez-vous sur quelque chose de mince et fortement axé sur le problème spécifique que vous essayez de résoudre.
Kieran Chandler: Super ! Je crains toutefois que nous devions nous arrêter là pour aujourd’hui, mais je suppose qu’il y a quelques CEO qui ne vous remercieront peut-être pas beaucoup pour cela, et qui vont probablement recevoir quelques appels en plus maintenant. Eh bien, c’est tout pour cette semaine. Nous serons de retour la semaine prochaine avec un nouvel épisode. D’ici là, prenez soin de vous.
Joannes Vermorel: Merci.
