Soyez feignants, soyez radins, soyez impatients, soyez agiles : collez au standard

Nombre de DSI achètent des solutions applicatives pour répondre à leurs besoins et minimiser leur risques (ERP, solutions ECM, WCM, BI, et la reine en la matière, SharePoint) dans la construction de leurs applications internes. Et bizarrement, la première chose qu’elles font au premier projet qui se présente, c’est de faire des développements spécifiques. Alors voici un petit rappel des arguments à présenter systématiquement quand votre interlocuteur insiste pour avoir sa super killer-feature dont il est si fier.

Rester dans le standard, c’est plus rapide.

Forcément, vous ne passez pas par la phase de développement. Ca peut vous faire économiser plusieurs mois dans le délai de livraison de votre projet et si votre application est vraiment importante pour lui, votre utilisateur préférera une appli qui marche tout de suite, qu’une appli qui marchera peut-être demain.

Rester dans le standard, ça coute moins cher.

Dans les projets IT, vous avez deux centres de couts, les licences, et le cout des personnes travaillant sur le projet (le service). Le temps de ces personnes se traduisant directement en cout, vu qu’on a économisé du temps (voir point précédent), on a donc économisé de l’argent. Et si votre client a trop d’argent, qu’il le dépense plutôt à faire de la formation, de la communication et de la gestion du changement autour du futur outil, parent pauvre trop souvent oublié des projets et pourtant facteur de réussite et grand accélérateur de retour sur investissement (donc d’argent économisé, encore une fois)

Rester dans le standard, c’est moins de soucis pour les montées de versions de l’application.

Ca, généralement, il n’y a que les équipes techniques qui comprennent cet argument mais il est énorme. Ajouter une clause dans un appel d’offre disant que les développements « doivent être compatibles avec les futures versions de l’application » est une blague. Personne ne sait ce qui sera compatible avec la future version de l’application, parfois même pas l’éditeur de l’application. Les dangers derrière cela :

  • freiner les montées de version de l’application
  • mais aussi, dans le cas de bug ou problème de performance de l’application, devoir engager une interminable partie de ping-pong avec le support de l’éditeur qui vous dira que ce n’est pas la faute de l’application mais celle de vos développements spécifiques (et pour arriver à démontrer que le problème est sur l’application uniquement, c’est parfois juste impossible)

Et enfin, rester dans le standard, c’est être agile.

Celle-là, ils ne l’ont pas vu venir 🙂 Etre agile, c’est être capable de réagir vite au changement. Même si vous êtes avec des équipes de supers développeurs qui scrument comme des ninjas à coup de sprints de deux semaines, vous avez toujours à peu prés un sprint pour passer de l’idée à quelque chose de formalisé en termes d’expression de besoin, un sprint d’implémentation, et un sprint pour passer les phases de tests et délivrer en production. Au total, au mieux du mieux, 1,5 mois pour délivrer une nouvelle fonctionnalité. Vous êtes en standard, vous cliquez sur le bouton, c’est fait.

Alors ça ne veut pas dire qu’il n’y a plus de travail pour les développeurs dans les DSI, loin de là. Je continue de gérer des projets de plusieurs centaines de jours hommes de développement pour certains. Mais ça veut dire qu’avant de faire quoi que ce soit, il faut prendre le temps de voir s’il n’y a pas moyen de répondre partiellement au besoin avec ce dont on dispose déjà. Ca se fait soit en se faisant accompagner par un expert de l’application, soit en prenant le temps de chercher, tester, faire des POC. Gardez le dev pour l’indispensable, votre service finance sera content, votre DSI sera content et votre développeur aussi sera content. Car oui, il n’est rien de plus inutile que de travailler efficacement à faire quelque chose qui n’aurait pas dû être fait (Peter Drucker) et ça, tout développeur ayant mené des projets de bout en bout le sait. Bien des fois, ça finit à la poubelle, ou personne ne clique sur le bouton. Et puis des développeurs, des bons, on en manque cruellement, autant les faire travailler sur l’essentiel.

Ajoutons à ça, mais ça ne parlera qu’aux développeurs, que faire du test unitaire de bout en bout (on vous dit partout qu’il faut en faire sur les projets agiles, à juste titre) sur des projets d’intégration, c’est impossible (il faudrait tester unitairement le standard de l’application sur laquelle vous vous reposez, bon courage). Et puis, la meilleure ligne de code qui soit, c’est celle qui n’existe pas.

Bref, soyez feignants, soyez radins, soyez impatients, soyez agiles : collez au standard.

Votre commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l’aide de votre compte WordPress.com. Déconnexion /  Changer )

Photo Google

Vous commentez à l’aide de votre compte Google. Déconnexion /  Changer )

Image Twitter

Vous commentez à l’aide de votre compte Twitter. Déconnexion /  Changer )

Photo Facebook

Vous commentez à l’aide de votre compte Facebook. Déconnexion /  Changer )

Connexion à %s

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur la façon dont les données de vos commentaires sont traitées.