Le développement de logiciels n’a rien à voir avec la construction et voici pourquoi

Il existe une recrudescence saisonnière des discussions autour des indicateurs de performance clés (KPI) et comment les mesures et les métriques que l’organisation de vente de logiciels, sont souvent des indicateurs avancés qui conduisent à des indicateurs plus substantiels qui parlent des clients capturés, la valeur des affaires négociées et les revenus que tout cela apporte à une organisation.

Du point de vue des produits logiciels, c’est important parce que c’est le moteur de la croissance du produit et cela aide à convaincre l’entreprise de poursuivre ou même d’augmenter les niveaux d’investissement.

A une époque où la vitesse transactionnelle est plus rapide que jamais, il est donc étonnant que le cycle de vie d’un contrat d’infrastructure logicielle à grande échelle reste extraordinairement long, même si certaines agences de développement en Suisse proposent des solutions de développement éclair..

Je n’ai pas réussi à trouver des valeurs absolues en termes de KPI de courtage de transactions, mais il n’est pas inconcevable que des projets d’adoption de logiciels importants puissent prendre jusqu’à un an ou deux avant qu’un bon de commande signé n’arrive sur les genoux d’un vendeur et en fait six à neuf mois avant que ce même produit logiciel se concrétise en un projet « gone-live ».

Je ne parle bien sûr pas ici de développement de logiciels personnalisés ou sur mesure. Je parle en fait de la mise en œuvre de logiciels courants prêts à l’emploi (COTS).

Contrairement à la construction de bâtiments où il est possible d’estimer assez précisément la durée d’un projet à partir des plans et de la conception, il n’en va pas vraiment de même pour le développement ou la mise en œuvre de logiciels.

On fait valoir que les projets de développement et de mise en œuvre de logiciels sont très différents des projets de construction. La majorité des implémentations logicielles, que ce soit à partir de zéro ou par le biais de la configuration, impliquent la collecte d’exigences et la prise de décision à grande échelle.

En prenant la simple analogie des fondations, vous pouvez considérer qu’avec la construction, une évaluation initiale de la propriété déterminera s’il est préférable d’utiliser des fondations en béton profondes ou peu profondes qui peuvent ou non nécessiter des pieux.

La décision est souvent simplement l’une des conditions environnementales et la spécification de la construction. Avec le développement et l’implémentation de logiciels, l’arbre de décision peut être infiniment plus complexe, couvrant des sujets tels que le système d’exploitation, la version du système d’exploitation, l’environnement de code source préféré, la mise à l’échelle, le renforcement de la sécurité et le cloud par opposition au sur site.

Tout cela avant même que nous ayons défini ce que sera le référentiel de données sous-jacent et à quoi devraient ressembler l’expérience utilisateur et les fonctionnalités.

Enfant, je me souviens avoir été fasciné par les fondations de la maison construite sur le terrain en face de chez nous. Il s’agissait de tranchées étroites et profondes remplies de barres d’armature qui se sont miraculeusement retrouvées submergées par du béton soigneusement coulé mélangé à des agrégats quelques jours plus tard. Quand j’ai voyagé en Asie du Sud-Est, les maisons étaient construites sur pilotis et bien sûr, qui peut oublier à quel point il fallait choisir avec soin un arbre approprié pour construire un fort ou une cabane en bois.

Oui, avec les solutions logicielles, c’est plus complexe, et le genre de personnes qui ont besoin de prendre les décisions ont tendance à être composées de plus grandes équipes de personnes ayant une expérience et des antécédents plus variés.

Dernièrement, j’ai eu l’avantage d’avoir non seulement des développeurs seniors, des maîtres de mêlée et des développeurs ordinaires qui pèsent sur les conceptions, mais aussi des architectes d’entreprise, des architectes de sécurité et des architectes de bases de données, chacun ayant sa spécialité et ses compétences qui s’appliquent à la conception globale.

Les discussions entre ces divers groupes d’intérêt peuvent être aussi intéressantes que frustrantes. C’est en partie une fonction des personnalités, mais c’est aussi un sous-produit direct de toutes les considérations qui doivent être prises en compte lors de la création ou du déploiement de logiciels pour l’entreprise. Un bon nombre de solutions se construisent sans que l’entreprise n’ait à l’esprit et échouent lorsqu’elles sont adoptées à plus grande échelle.

Ainsi, même si la conception finale peut prendre un peu plus de temps à préciser, l’intention est de créer quelque chose qui non seulement répond aux besoins actuels, mais qui, espérons-le, pourra évoluer et s’adapter à l’évolution des demandes et des options de déploiement dans le futur.

Vous pouvez soutenir que les bâtiments ont les mêmes attentes, et bien sûr, c’est un peu vrai, mais en même temps, contrairement aux terrains dont la disponibilité est limitée et qui ne peuvent être recyclés qu’après démolition, les produits logiciels peuvent être réinventés avec peu ou pas d’impact sur les environnements actuels dans lesquels ils existent et si vous choisissez de les modifier ou les étendre, cela peut être fait plus facilement dans les contraintes des premiers choix que vous faites en matière d’architecture applicative.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

*

code