Dans la première partie de cette mini-série en deux parties, nous avons déjà décrit 6 erreurs de raisonnement que l'on peut commettre lors de la planification, de la réalisation et de la gestion de projets logiciels. Et nous en avons tiré une première conclusion : Fixer et mesurer la réalisation des objectifs aide à évaluer sa propre situation de manière réaliste, la diversité des opinions et des personnes est également importante dans l'industrie du logiciel et, de manière générale, on peut également tomber dans des erreurs de raisonnement dans les projets numériques que nous connaissons également dans la vie quotidienne. Pour ceux qui n'ont pas encore lu le premier blog : Vous trouverez ici la première partie, dans laquelle nous avons bien entendu expliqué les raisons et les motivations de ces deux blogs. Pour tous ceux qui ont déjà lu la première partie, voici maintenant les erreurs de raisonnement 7 à 12.
7. Sensibilité des incitations - Incentive-Superresponse-Tendency
Comme nous l'avons déjà brièvement évoqué dans la première partie, cette erreur de raisonnement décrit la problématique des systèmes d'incitation : Que ce soit en politique, dans la société ou dans l'économie, dès qu'une incitation est définie pour ou contre quelque chose, cela a une forte influence sur la pensée et le comportement des gens.
Dans le cadre du développement de produits numériques, cela peut signifier que si l'on fixe des incitations telles que le respect d'une date de livraison, d'autres mesures importantes telles que la couverture des tests, l'expérience d'utilisation, l'attention portée aux détails ou l'efficacité dans le projet peuvent en pâtir, simplement parce que l'incitation a été fixée "uniquement" sur le respect d'une date limite.
Il est donc très important d'être très conscient de ce qui peut se passer en définissant des systèmes d'incitation. Il est absolument essentiel que les objectifs de l'équipe et les objectifs personnels des collaborateurs découlent des objectifs de l'entreprise et du business, afin de garantir qu'une valeur ajoutée soit créée pour l'ensemble de l'organisation.
Se concentrer trop fortement sur des objectifs individuels avec des incitations importantes peut être très dangereux. C'est ce que l'on peut observer par exemple dans le secteur financier, lorsque des bonus sont fixés pour la conclusion de crédits en tant qu'incitations et que les collaborateurs incités accordent le plus de crédits possible, sans toutefois tenir compte de la durabilité de ces crédits. Il est vrai qu'il n'y avait pas de mauvaises pensées derrière cet objectif, mais en même temps, on a oublié que les gens réagissent fortement aux incitations, mais qu'ils ne tiennent souvent pas compte de l'intention réelle derrière l'incitation mise en place.
En 2016, Samsung a lancé le Galaxy Note 7 en automne, comme d'habitude : Un nouveau produit phare sur le marché exactement au moment prévu. Le respect absolu du calendrier de sortie n'est-il pas à l'origine d'un contrôle qualité insuffisant, d'une explosion des batteries et d'une campagne de rappel de millions d'appareils ?
8. Distorsion des résultats - The Outcome Bias
Un biais de résultat se produit lorsqu'une décision est basée sur le résultat d'événements antérieurs, sans tenir compte de la manière dont ces événements antérieurs ont évolué. Dans le cas d'un biais de résultat, les facteurs qui ont conduit à un événement antérieur ne sont pas analysés. Au lieu de cela, les événements qui ont précédé le résultat sont minimisés et le résultat est surévalué.
Supposons que dix personnes reçoivent chacune 1 million de francs pour développer et commercialiser une application à succès. Au bout d'un an, cinq projets n'ont absolument aucun succès, quatre autres marchent moyennement et une app semble être sur la bonne voie pour devenir un très grand succès. Au bout de deux ans, cinq projets sont complètement anéantis sans jamais avoir connu le succès, deux autres arrivent tout juste à se maintenir à flot, deux ont atteint le seuil de rentabilité et un seul projet d'application a connu un tel succès qu'il a été acheté plusieurs centaines de milliers de fois dans le monde et est utilisé régulièrement. C'est ce que l'on appelle maintenant "l'app à succès" et les médias, ainsi que de nombreux spécialistes et experts, vont maintenant essayer de trouver la "recette du succès" de cette app et d'en faire un rapport, un article de blog ou même un livre intitulé "La recette du succès pour le développement d'apps".
Cette histoire décrit la tendance à évaluer les décisions en fonction du résultat plutôt que du processus décisionnel de l'époque. Pour évaluer la qualité des décisions, il faut se placer au niveau de l'information initiale et filtrer tout ce que nous n'avons appris qu'après coup à ce sujet. Le fait que ce soit précisément cette application qui ait eu le plus de succès ne doit pas être pris en compte dans l'évaluation des processus de décision. Nous ne pouvons vraiment évaluer les décisions de l'app à succès que si nous connaissons un peu le développement de l'app, si nous observons attentivement l'approche et la réalisation de toutes les activités et si nous évaluons ainsi le processus et non le résultat.
Exemple : les applications de rencontre - l'une des catégories d'applications les plus populaires : Il y a des millions d'utilisateurs*. Mais seules quelques-unes ont du succès, des centaines d'apps de ce type "traînent" dans les App Stores. Bien que Tinder ait manifestement beaucoup de succès, il ne faut pas oublier les nombreuses apps qui ont échoué.
9. L'illusion du contrôle
Tout comme l'écueil de la surestimation de soi, cette erreur de raisonnement consiste à croire que nous maîtrisons quelque chose que nous ne pouvons tout simplement pas (influencer). As-tu déjà remarqué, par exemple, que le grand public lance un dé plutôt plus fort lorsque l'objectif est un chiffre élevé et plutôt plus faible lorsqu'un chiffre bas est souhaité ? C'est souvent le cas pour moi et pour mes enfants.
Dans le domaine des applications, nous constatons souvent que les clients souhaitent que nous puissions leur dire, dès le premier entretien, si leur idée de produit numérique sera un succès ou non. Ce que nous pouvons offrir à nos clients, c'est uniquement notre évaluation subjective de l'idée, qui ne doit en aucun cas être considérée comme de la monnaie sonnante et trébuchante. Nous ne pouvons influencer que dans une faible mesure si le groupe cible visé appréciera le problème que le produit est censé résoudre et s'il utilisera donc régulièrement l'outil numérique. Afin de pouvoir évaluer le plus tôt possible si une idée fonctionne ou non, nous recommandons d'impliquer des utilisateurs finaux potentiels dans le développement du concept dès les premières phases et de valider les hypothèses sur lesquelles se base l'idée à l'aide de prototypes avant même d'écrire une ligne de code. Nous avons décrit plus en détail le prototypage dans l'article de blog suivant.
Comment échapper à l'illusion de pouvoir contrôler des choses sur lesquelles nous n'avons guère d'influence ?
Let it flow : nous devrions laisser faire les choses sur lesquelles nous n'avons pas d'influence, plutôt que d'essayer de prendre un contrôle artificiel.
Tester les hypothèses : grâce au prototypage, à la recherche utilisateur et à une approche centrée sur l'utilisateur, nos hypothèses devraient être validées très tôt dans la phase de conception et d'idéation.
Think Again : se demander si l'on peut vraiment contrôler quelque chose (par ex. le succès d'un produit) ou si cela dépend simplement de trop d'inconnues ou de facteurs non influençables.
Se concentrer sur les choses qui peuvent être influencées : Investir plutôt le temps dans des choses que nous pouvons influencer/contrôler efficacement et en grande partie.
Procédure itérative et conception centrée sur l'utilisateur : la co-création et l'implication des groupes cibles dès le début peuvent nous éviter de faire des suppositions erronées sur les besoins, les problèmes, les intérêts et les sentiments des utilisateurs finaux.
10. La dissonance cognitive
La dissonance cognitive peut s'expliquer ainsi : La faiblesse de s'avouer des erreurs ou des faiblesses, ainsi que la capacité de l'être humain à influencer positivement ses propres sentiments, même avec de petits mensonges, agissent de telle sorte qu'une décision clairement erronée devient soudain une décision OK plausible.
La fable d'Ésope explique l'erreur de raisonnement
Le poète grec Ésope a illustré cette erreur de raisonnement très répandue par une fable. Un renard qui, malgré plusieurs tentatives, n'a pas pu attraper les raisins juteux à cause de la hauteur, se contente finalement de se convaincre que les raisins ne sont de toute façon pas encore assez mûrs pour lui et donc acides.
C'est justement en tant que chef de produit, responsable des ventes ou du marketing que cette erreur de raisonnement peut très vite arriver.
Il ne m'est pas rare d'accepter de participer à un projet malgré un sentiment d'instinct et des conditions non optimales. Dans de nombreux cas, notre intuition ne nous a pas trompés et le projet devient difficile, de nombreux problèmes imprévisibles apparaissent, des malentendus existent et donc toutes les personnes concernées sont plutôt stressées et vivent une mauvaise expérience. Lors des débriefings, il n'est alors pas rare que je me surprenne à dire "c'était quand même bien d'avoir fait ce projet, car nous avons pu apprendre beaucoup de choses". L'objectif initial était en fait de réaliser un projet réussi, instructif et durable pour le client et pour nous. Comme ce résultat ne s'est pas concrétisé, je peux maintenant soit
a) essayer de mener le projet à bien malgré tout
b) admettre que c'était une erreur de lancer le projet dans ces circonstances ou
c) en adaptant l'objectif et en se faisant un peu d'illusions, qualifier tout de même le projet de "succès" en se contentant de dire que nous avons appris quelque chose de ce projet.
Bien sûr, les échecs et les projets difficiles sont aussi très importants pour nous, mais il faut pouvoir les admettre à 100% pour en tirer efficacement des leçons.
De mon point de vue, c'est une grande compétence que d'être capable de reconnaître entièrement ses erreurs et de se consacrer au processus d'apprentissage afin d'éviter l'erreur à l'avenir. Faire une erreur ne doit pas faire mal, mais doit susciter un bon sentiment de "Ouais, j'ai encore appris quelque chose ! C'est précisément pour cette raison qu'il est important de permettre l'émergence, au sein d'une organisation, d'une culture dans laquelle les échecs et les mauvaises décisions peuvent être discutés ouvertement et dont on peut tirer des enseignements.
11. L'effet d'ancre - the Anchoring Effect
L'effet d'ancrage est un terme de psychologie cognitive qui décrit l'assimilation d'un jugement numérique à un standard de comparaison prédéfini (ancre). Le problème est que nous sommes influencés par ce standard de comparaison prédéfini lorsque nous prenons des décisions, sans que nous soyons conscients de cette influence. L'effet d'ancrage est donc la tendance à se fier trop fortement à une information initiale, appelée ancre, lors de la prise de décision. Je connais cet effet d'une part de mes voyages dans des pays lointains, où les prix des produits ne sont pas fixés dès le départ, mais doivent justement être négociés. Que ce soit sur un marché au Maroc ou dans un bazar en Turquie, lorsque l'on négocie un prix, le premier prix cité sert généralement d'ancre et représente ainsi le point de départ des négociations. Dans de nombreux cas, la proposition de prix communiquée au départ influence donc le résultat final des négociations.
Mais cet effet se retrouve aussi souvent dans le développement de logiciels. Par exemple, lorsqu'il s'agit de calculer une estimation sérieuse des coûts d'une nouvelle application native, d'une application web ou encore d'un backend ou d'une interface. Si nous communiquons à l'équipe que le client dispose d'un certain budget avant même d'estimer les coûts pour les exigences logicielles existantes, il y a de fortes chances que le prix estimé s'oriente finalement vers cet ancrage.
Un deuxième exemple dans le même contexte est que l'estimation des développeurs iOS (Swift), par exemple, est souvent influencée si un développeur Android a déjà inscrit les efforts (heures estimées par exigence) dans le document d'estimation.
Quelques conseils pour éviter l'effet d'ancrage lors de l'estimation des dépenses :
Ne jamais communiquer un budget existant ou souhaité avant les travaux d'estimation, mais laisser tous les participants à l'estimation estimer le plus librement possible (sans ancrage).
Masquer les heures déjà estimées d'une discipline (par ex. le développement Android) lorsque les mêmes exigences sont estimées pour la deuxième plateforme (par ex. le développement iOS). Cela devrait éviter qu'une partie soit influencée par l'estimation de l'autre partie.
Faire estimer les mêmes exigences par différentes personnes, sans qu'elles connaissent l'estimation des autres. Après que plusieurs personnes ont évalué indépendamment les unes des autres, les chiffres peuvent être comparés ; si les différences sont minimes, la valeur moyenne peut être considérée comme une bonne estimation. En cas de différences plus importantes, tous les points qui présentent des différences très importantes et qui sont donc probablement liés à des hypothèses différentes peuvent être discutés en équipe.
12. L'erreur de rareté
Rara sunt cara - Ce qui est rare est précieux. Jusqu'à présent, je n'ai écrit que sur les problèmes liés aux erreurs de raisonnement. Il est temps de montrer comment tirer profit des erreurs de raisonnement omniprésentes.
L'erreur de raisonnement sur la rareté consiste à considérer que les choses dont la disponibilité est limitée ont plus de valeur, même si elles n'ont pas d'autres caractéristiques de qualité ou de fonctions supplémentaires. Le simple fait qu'il n'existe pas un nombre infini d'exemplaires / de pièces / d'accès / d'invitations de quelque chose en fait (soi-disant) un bien de plus grande valeur.
Exemples d'application de l'erreur de rareté dans le développement de jeux vidéo
Supposons que tu souhaites lancer avec succès un nouveau jeu mobile sur le marché. Comme d'habitude, tu vas essayer de créer au préalable une communauté aussi large que possible. Comme tu sais que les gens accordent plus de valeur aux choses rares, tu restreins artificiellement le nombre de versions préliminaires (communauté de bêta-testing), par exemple à 50 utilisateurs bêta*. Sur une page de renvoi, on peut alors lire : "s'inscrire immédiatement pour obtenir l'une des 50 préversions exclusives". Cela donne aux personnes intéressées le sentiment qu'elles doivent s'inscrire immédiatement, sinon la chance d'obtenir cette version exclusive est perdue. Bien sûr, on peut encore renforcer cet effet psychologique en affichant un compteur qui indique le nombre de créneaux encore disponibles et qui diminue aussi régulièrement.
C'est justement dans la publicité ou le commerce électronique que l'on joue très souvent avec cette erreur de raisonnement. Par exemple sur les plateformes de réservation de chambres d'hôtel. On y lit souvent "il ne reste plus qu'une chambre" et "deux autres personnes sont en train de consulter cette offre ! Cela produit un stress intérieur et un sentiment de "maintenant ou jamais". Les discounters travaillent de la même manière avec les rabais spéciaux quotidiens et hebdomadaires, qui sont limités dans le temps ou dans leur nombre ("jusqu'à épuisement du stock") et qui nous font donc croire à tort que l'on a trouvé ici une offre particulièrement bonne.
Comment échapper à l'erreur de la rareté
Le fait que quelque chose soit rare ou disponible seulement pendant une certaine période (p. ex. Black Friday, Cyber Monday, etc.) ne devrait pas jouer de rôle dans la décision d'acheter ou non. Les critères importants pour quelqu'un lors de l'achat d'un objet sont hautement individuels. L'important est d'appliquer ces critères et de ne pas en inventer de nouveaux, comme par exemple que le produit soit rare ou qu'il n'ait été proposé à ce prix que pendant une semaine. Je ne pense pas que quiconque ait sérieusement de tels critères d'achat, à moins bien sûr d'être marchand d'art, collectionneur ou autre.
Conclusion : 12 erreurs de raisonnement ou pièges dans le business numérique
Voici un aperçu des erreurs de raisonnement décrites dans ces deux blogs. Outre les désignations pures, qui sont souvent difficiles à retenir, j'ai ajouté à chaque fois une question ou un élément qui devrait aider à éviter cette erreur de raisonnement.
Partie 1:
Le piège de la surestimation de soi - Overconfidence-Bias
Demander un feedback à d'autres personnes sur sa propre évaluation aide généralement à réduire la surestimation de soi. En général, la modestie aide également, ce que Socrate savait déjà : "Je sais que je ne sais rien".
Le piège des coûts irrécupérables - Sunk Cost Fallacy
Veille à atteindre les objectifs fixés au lieu de prendre en compte les investissements déjà réalisés lors de la prise de décisions pour l'avenir.
Le piège de la confirmation - Confirmation Bias
Recherche explicitement des preuves contraires (Disconfirming Evidence) et accorde à celles-ci au moins autant d'attention qu'à celles qui soutiennent ta propre théorie.
Le préjugé d'autorité - Authority Bias
Avant de prendre une décision ou d'émettre une opinion basée sur les déclarations d'un expert ou d'une autorité, nous devrions réfléchir par nous-mêmes et chercher des opinions contraires. La diversité et une culture ouverte du feed-back dans les organes de décision et les équipes permettent généralement d'éviter le biais d'autorité.
Le biais de la survivance - Survivorship Bias
Cherche absolument les échecs dans le grand cimetière des apps ou des projets web qui ont échoué. Tu constateras bientôt qu'il y a probablement X fois plus d'échecs, mais que la présence ressentie des produits numériques réussis est naturellement beaucoup plus grande.
L'illusion du corps du nageur
Réfléchis et pose-toi la question suivante : quelle est vraiment la cause et quel est l'effet ?
Partie 2:
Sensibilité des incitations - Incentive-Superresponse-Tendency
Pose-toi la question de savoir si, en définissant les conditions-cadres du projet, tu as créé un système d'incitation qui aura des répercussions négatives sur le déroulement, les décisions ou le produit final.
Distorsion des résultats - The Outcome Bias
Ne juge jamais une décision déjà prise en fonction de son résultat.
L'illusion du contrôle
Le succès ou l'échec de l'outil numérique est-il vraiment sous mon contrôle ? Quels sont les facteurs qui influencent effectivement le résultat ?
La dissonance cognitive
Ne te mens pas à toi-même, assume tes erreurs et essaie d'en tirer des leçons. Si tu parviens à identifier tes erreurs, à les assumer et à trouver des solutions alternatives à ton problème, cela peut réduire la dissonance cognitive.
L'effet d'ancre - the Anchoring Effect
Réfléchis à ta propre situation et essaie de déterminer si une décision a déjà été influencée par une information préalable (ancre). Demande un deuxième avis et assure-toi que la personne à qui tu demandes un deuxième avis n'est pas déjà influencée par ta propre opinion/décision.
L'erreur de rareté
Puis-je augmenter la valeur perçue (demande) de l'offre en raréfiant artificiellement l'offre ?
Conclusion sur les erreurs de raisonnement et les pièges dans le développement de logiciels
Tout le monde fait des erreurs de raisonnement quasiment tout le temps et j'aimerais beaucoup rencontrer personnellement tous ceux qui prétendent que ce n'est pas le cas pour eux. Même après que j'ai écrit ce blog et que vous l'avez lu, cela ne nous libérera pas des erreurs de raisonnement et de la mauvaise orientation "systématique" de notre cerveau. Cela conduit sans doute à la question : pourquoi donc tout cela ? Eh bien, il y a un certain espoir qu'en raison de la connaissance de ces erreurs de raisonnement, notre propre capacité de réflexion soit augmentée et que nous ayons ainsi plus de chances de découvrir nos propres erreurs de raisonnement et d'introduire des tactiques pour réduire ces erreurs de jugement. La question suivante est bien sûr de savoir si cela correspond déjà à l'erreur de raisonnement de la surestimation de soi..😉 De mon point de vue, la réflexion sur soi-même, la demande de feedbacks de diverses personnes et la recherche active d'opinions et de preuves contraires sont déjà de bonnes mesures pour éviter plusieurs erreurs de raisonnement ou pour réduire leur influence négative.
Pour conclure, il est important de mentionner que cette série de blogs n'a décrit qu'une petite partie des erreurs de raisonnement existantes et qu'il existe donc encore beaucoup d'autres erreurs de raisonnement possibles, également dans le développement de logiciels, auxquelles il convient de prêter attention afin d'éviter des décisions erronées fatales. Nous serions heureux de connaître vos idées, expériences et conseils sur les erreurs de raisonnement dans le développement de logiciels.