Dans cette lettre personnelle et directe aux clients, Allan Kelly n’y va pas par quatre chemins et explique pourquoi les projets informatiques ne se déroulent pas toujours parfaitement pour toutes les parties concernées.

Je ne suis pas en accord avec tous les constats mais ils ont au moins le mérite d’être clairement énoncés. Quels sont vos propres retours d’expérience sur ce sujet assez controversé ?

Dear Customer: The Truth about IT Projects

https://www.agileconnection.com/article/dear-customer-truth-about-it-projects par Allan Kelly

Cher client,

Je pense qu’il est temps que nous, dans l’industrie informatique, disions la vérité sur la façon dont nous vous facturons, pourquoi nos factures sont parfois un peu plus élevées que ce à quoi vous pourriez vous attendre et pourquoi tant de projets informatiques entraînent des déceptions. La vérité est que lorsque nous commençons un projet informatique, nous ne savons pas combien de temps et d’efforts il faudra pour le mener à bien. Par conséquent, nous ne savons pas combien cela coûtera. Ce n’est peut-être pas un message que vous aimez entendre, d’autant plus que vous êtes absolument certain de savoir ce que vous voulez.

C’est là que réside une autre vérité, que je vais essayer d’exprimer aussi poliment que possible. Vous êtes, après tout, un client, et, vraiment, je ne devrais pas vous offenser. Vous connaissez le dicton « Le client a toujours raison » ? La vérité, c’est que vous ne savez pas ce que vous voulez. Vous le savez peut-être en termes généraux, mais le diable est dans les détails et plus vous essayez de nous donner de détails à l’avance, plus vos désirs sont susceptibles de changer. Chaque fois que vous nous donnez plus de détails, vous offrez plus de prise au hasard.

L’expert en génie logiciel Capers Jones pense que les choses que vous voulez (« exigences », comme nous aimons les appeler) changent de 2% par mois. Personnellement, je suis surpris que ce pourcentage soit si faible !

Pour compliquer les choses, le monde est incertain. Les choses changent, et des entreprises font faillite. Vous vous souvenez d’Enron ? Vous vous souvenez de Lehman Brothers ? Les goûts des clients changent. Vous vous souvenez de Cabbage Patch Kids ? La mode change, les gouvernements changent et les concurrents font de leur mieux pour vous rendre la vie difficile. Donc, vraiment, même si vous savez absolument ce que vous voulez lorsque vous nous parlez pour la première fois, il est peu probable que cela reste statique très longtemps.

J’ai peur de dire qu’il y a des gens dans l’industrie informatique qui vont profiter de cette situation. Ils souriront et seront d’accord avec vous lorsque vous leur direz ce que vous voulez, jusqu’au moment où vous signerez. À partir de ce moment-là, c’est une autre histoire ; Ils savent que les changements sont inévitables et ils prévoient de tirer un profit substantiel des demandes de changement et des ajouts tardifs à vos frais.

Pendant que j’y suis, il aussi est vrai que « nous plaquons parfois les choses en or ». Vous n’aurez peut-être pas besoin d’un entrepôt de données pour votre magasin en ligne dès le premier jour. Oui, certains de nos ingénieurs aiment faire plus que ce qui est nécessaire, et oui, nous avons un intérêt direct à ajouter des choses afin de pouvoir vous facturer plus.

Il est également vrai que vous pensez tout à fait légitimement aux caractéristiques et aux fonctionnalités que vous aimeriez avoir après que nous ayons commencé. Vous supposez naturellement que quelque chose est « à l’intérieur » du périmètre lorsque nous supposons qu’elle est « à l’extérieur ». Et, dans un esprit d’ouverture, pouvez-vous honnêtement dire que vous n’avez jamais essayé de nous imposer un de ces sous-entendus ? (Ne parlons même pas des bogues pour l’instant, cela ne fait que compliquer l’ensemble.)

Franchement, compte tenu de tout cela, il est touchant que vous ayez autant confiance en la technologie pour livrer des solutions. Mais, quand l’informatique tient ses promesses, elle livre gros. Regardez ce qu’elle a réalisé pour Bill Gates et Larry Page, ou Amazon et FedEx. N’est-il pas intéressant que lorsque l’industrie informatique développe des choses pour elle-même, nous nous retrouvons avec des multimillionnaires. Lorsque nous développons pour d’autres personnes, celles-ci finissent par perdre de l’argent.

Comment avons-nous pu vous convaincre de tout cela ? Eh bien, nous emballons joliment ce gâchis disgracieux et essayons de vous le vendre. Pour ce faire, nous devons cacher tous ces désagréments. Nous commençons par un rituel appelé estimation, c’est-à-dire le temps que nous pensons que le travail prendra. Ces « estimations » ne valent guère mieux que des suppositions. Les humains ne sont pas capables d’estimer. Nous le savons depuis au moins la fin des années 70, lorsque Kahneman et Tversky ont décrit le « sophisme de planification » (“planning fallacy”) en 1979 et remporté un prix Nobel. Fondamentalement, les humains sous-estiment constamment la durée du travail et sont trop confiants dans leurs estimations.

Pour aggraver les choses, nous avons une mauvaise habitude dont nous devrions vraiment nous débarrasser. Entre l’estimation du travail et l’exécution du travail, nous changeons généralement l’équipe. L’estimation peut être faite par l’équivalent informatique de Manchester United ou des Mets de New York, mais l’équipe qui fait réellement le travail est plus que probablement un groupe hétéroclite de codeurs, d’analystes et de managers qui ne se sont jamais rencontrés auparavant.

Les données historiques (données sur les estimations, les données réelles, les coûts, etc.) peuvent aider à éclairer la planification, mais la plupart des entreprises ne disposent pas de leurs propres données. Pour ceux qui ont des données, la plupart d’entre elles sont pires qu’inutiles. En fait, Capers Jones suggère que des données historiques inexactes sont un facteur majeur d’échec du projet. Par exemple, les ingénieurs logiciels sont rarement payés pour leurs heures supplémentaires, de sorte que les systèmes de suivi oublient souvent ces heures supplémentaires.  En effet, certaines entreprises interdisent aux employés d’enregistrer plus que leurs heures officielles dans leurs systèmes.

Donc, nous faisons cette supposition (pardon, estimation) et la doublons, nous pourrions même la tripler. Si le nouveau nombre semble trop élevé, nous pourrions le réduire. Une fois que nos ingénieurs ont fini de malaxer les chiffres, nous les donnons aux vendeurs, qui les malaxent un peu plus. Après tout, nous voulons que vous disiez oui au prix le plus élevé que nous puissions obtenir. Cela peut sembler horrible, mais rappelez-vous : nous aurions pu le deviner dès le départ.

S’il vous plaît, ne me tirez pas dessus, je ne suis que le messager.

Nous ne savons pas quel chiffre est « correct », mais pour le rendre acceptable pour vous, nous prétendons qu’il est certain et nous assumons le risque. Nous ne pouvons le faire que si le nombre est suffisamment gras (et, même dans ce cas, nous nous trompons). Si le risque est payant, alors nous obtenons un gros bénéfice. Si ce n’est pas le cas, nous n’obtenons aucun profit et nous risquons de subir des pertes. Si c’est vraiment mauvais, vous n’obtenez rien et nous nous retrouvons devant les tribunaux ou fermons boutique.

L’alternative est que vous preniez le risque – et le bazar – et que vous le fassiez vous-même. Malheureusement, une autre triste vérité est que l’informatique interne est généralement encore pire que les fournisseurs spécialisés.  Pour une entreprise de logiciels, le développement est une compétence de base, de telles entreprises vivent ou meurent en fonction de leur capacité à fournir des logiciels et si elles sont peu performantes, elles cessent leurs activités.  L’évolution élimine les mauvais élèves.

L’informatique d’entreprise, en revanche, détruit rarement une entreprise, bien qu’elle puisse nuire aux bénéfices. En effet, les recherches de Capers Jones suggèrent également que les fournisseurs spécialisés sont généralement meilleurs que les services informatiques des entreprises.

Les vendeurs sont peut-être absents, mais l’ensemble du processus d’estimation est ouvert aux jeux provenant de nombreuses autres sources et pour de nombreuses autres raisons. En fin de compte, si vous décidez de prendre ce risque, vous risquez en fait d’augmenter le risque.

Je sais que cela ressemble à un scénario sans issue. Vous pouvez simplement vous asseoir sur un banc et attendre que Microsoft ou Google résolvent vos problèmes avec une solution packagée, mais vos concurrents resteront-ils immobiles pendant que vous le faites ? Serez-vous toujours à la tête d’une entreprise lorsque Google produira une version gratuite de ce dont vous avez besoin ?

Soit dit en passant, méfiez-vous des charlatans qui vendent des applications prêtes à l’emploi. Une fois que les gens commencent à parler de « personnalisation » ou de « configuration », vous vous engagez sur une pente glissante.  La configuration d’une grande installation SAP ne consiste pas à sélectionner des outils, des options, puis à cocher une case. La configuration de logiciels volumineux est une activité majeure de développement logiciel, peu importe ce qu’on vous a dit.  Les personnes qui entreprennent la configuration peuvent être appelées « consultants », mais ce sont en réalité des développeurs de logiciels spécialisés.

Il n’y a pas vraiment de solution simple et agréable à tout cela. Nous ne pouvons pas résoudre ce problème pour vous. Nous avons besoin de vous, mais vous devez travailler avec nous. En tant que client, vous devez être prêt à travailler avec nous, le fournisseur, encore et encore afin de réduire les risques.  Gérer les risques de manière opportune et rentable implique des décisions et des compromis au niveau de l’entreprise.  Si vous n’êtes pas là pour vous aider, nous pouvons soit prendre la décision pour vous (en ajoutant le risque que vous ne soyez pas d’accord), soit consacrer votre temps et votre argent à la résoudre.

Vous devez être prêt à accepter et à partager le risque avec nous. Si vous n’êtes pas prêt à prendre le moindre risque, nous vous facturerons beaucoup pour tous les risques que nous prenons.

Le partage du risque a pour effet de réduire le risque, car une fois le risque partagé, vous, le client, êtes motivé à réduire le risque.  L’un des risques majeurs sur les projets informatiques est le manque d’implication des clients. Vous pouvez y contribuer simplement en restant impliqué.

En fin de compte, tous les risques sont les vôtres. Vous êtes le client et vous payez pour ce projet, d’une manière ou d’une autre. S’il ne parvient pas à créer de la valeur, c’est votre entreprise qui en souffrira. Lorsque vous partagez les risques et que vous êtes étroitement impliqué dans ce processus, les risques peuvent être traités immédiatement plutôt que d’être laissés s’envenimer et se développer.

Enfin, vous avez peut-être de grandes ambitions, mais nous devons travailler par petits morceaux. Je sais que cela peut ne pas sembler très sexy, mais la création de logiciels fonctionne mieux lorsqu’elle est petite. Les économies d’échelle n’existent pas. En fait, nous avons des déséconomies d’échelle, nous devons donc travailler par petits morceaux encore et encore. Si vous êtes prêt à accepter ces suggestions, alors appuyons sur le bouton de réinitialisation de notre relation et allons un peu plus loin.

Cordialement, L’industrie de l’informatique

Allan Kelly

Allan Kelly inspire les équipes numériques à fournir efficacement de meilleurs produits grâce aux technologies agiles. Ces approches permettent de raccourcir les délais, d’améliorer la prévisibilité, d’augmenter la valeur, d’améliorer la qualité et de réduire les risques. La plupart de son travail se fait avec des équipes innovantes, des petites entreprises – y compris des scale-ups ; Il est spécialisé dans le développement de produits et l’ingénierie. Il utilise un mélange de formation expérientielle et de  consultation continue.

Il est à l’origine des Retrospective Dialogue Sheets, Value Poker et Time-Value Profiles.

Allan est l’auteur de l’essai : « Dear Customer, the truth about IT » et de plusieurs livres, dont : « Xanpan – team centric Agile Software Development » et « Business Patterns for Software Developers ». Il a récemment terminé « Continuous Digital », le livre #NoProjects.