Dans ma publication de la semaine dernière, j’évoquais le fait que la solution à un problème logiciel ne provient pas nécessairement du code. Mais concrètement, que cela signifie-t-il ?
Voir la publication originale
Cette dernière est republiée ici afin de ne pas dépendre entièrement d'une plateforme tierce.
Pour illustrer le propos, prenons un exemple concret: un logiciel de gestion pour lequel nous souhaitons mettre en place des tableaux de bord métier pour les utilisateurs. Création de graphiques, filtres dynamiques, export de données, gestion des droits d’accès, etc. Une charge de travail conséquente.
Pourtant, est-ce réellement nécessaire ? N’existe-t-il pas de solution existante et intégrable répondant à ce besoin ? C’est le genre de questions et de réflexions qui peut transformer des mois de développement en quelques semaines d’intégration.
C’est le concept du “build vs buy”, construire ou acheter. Et la réponse est moins simple qu’il n’y paraît puisqu’il y a de nombreuses variables à prendre en compte.
Si une équipe décide de construire une solution sur-mesure, il faut que cela représente un réel avantage concurrentiel, une différenciation forte. Idéalement, il faut que le développement se rapproche du cœur de métier de la solution. Si ce n’est pas le cas, c’est de l’investissement qui ne serait pas optimisé pour apporter une réelle valeur à l’utilisateur finale.
C’est une vraie décision stratégique à arbitrer et il est pourtant fort probable que le réflexe de toute équipe de développement sera de développer sa propre solution. C’est là que la prise de recul et une vision business suffisante sont indispensable pour faire la différence.
