<\/HEAD>
Dans le roman classique de Mary Shelley Frankenstein<\/EM>, lorsque Victor Frankenstein se lance dans la réalisation de son objectif, il cherche à créer l'homme parfait. Après avoir réalisé qu'un humain de taille moyenne nécessiterait un assemblage délicat, il fabrique sa créature (Adam) de 8 pieds de haut, avec des membres proportionnés, des cheveux noirs brillants et des dents blanches nacrées. Tellement absorbé par les détails de l'assemblage et de l'animation de la créature pendant plusieurs années du projet, il ne s'est jamais arrêté pour regarder l'ensemble.<\/P>Ce n'est qu'après le premier spasme de vie parcourant sa création qu'il a réalisé :<\/P>J'avais travaillé dur pendant près de deux ans, dans le seul but d'insuffler la vie à un corps inanimé. Pour cela, je m'étais privé de repos et de santé. Je le désirais avec une ardeur qui dépassait largement la modération ; mais maintenant que j'avais terminé, la beauté du rêve avait disparu, et une horreur haletante et un dégoût remplissaient mon cœur. Incapable de supporter l'aspect de l'être que j'avais créé, je me précipitai hors de la pièce et parcourus longtemps ma chambre à coucher, incapable d'apaiser mon esprit pour dormir.<\/EM><\/P>Shelley a peut-être publié Frankenstein en 1818, mais ce moment dans le roman est une analogie exceptionnelle pour le processus de développement de projet et d'application. En tant que professionnels géospatiaux, chefs de projet et développeurs, il y a une tentation certaine pour nous de travailler sans relâche sur un développement technique sans prendre le temps de regarder la vue d'ensemble.<\/P>Je sais que personnellement j'apprécie le défi d'attacher les veines, artères et fibres musculaires d'une application et je suis sûr que beaucoup d'entre vous ressentent la même chose. Cependant, il est important de s'assurer que l'innovation technique d'une application ne fasse pas oublier son objectif initial. Il est peu probable qu'une application ou un projet prenne vie et tue mes proches, comme dans Frankenstein<\/EM>, mais les conséquences d'un produit final qui ne correspond pas au besoin métier original peuvent être graves.<\/P>J'ai vu les effets des projets et applications mal exécutés de première main. Après avoir travaillé dans une organisation, si j'entendais quelqu'un mentionner une suite logicielle particulière, je finissais par lever les yeux au ciel si fort que je pouvais voir l'intérieur de mon crâne. J'ai aussi dû passer de longues périodes à restaurer la confiance d'un utilisateur dans ArcGIS, voire à le convaincre que les outils géospatiaux valaient la peine d'être poursuivis, tout cela à cause d'une mauvaise expérience.<\/P>Travaillant dans le SIG, les projets ou le développement d'applications, nous construisons rarement un résultat pour notre propre bénéfice. Comme un cadre pour lequel j'ai travaillé l'a dit : « nous ne sommes pas une glace qui se lèche elle-même ». Les applications et projets que nous supervisons sont destinés à résoudre un besoin métier défini. Si ce besoin n'est pas satisfait, votre application risque de ne pas être utilisée par les clients ou utilisateurs pour lesquels vous l'avez développée. En tant que consultant, votre client pourrait ne pas être aussi enthousiaste à l'idée de futurs contrats avec votre entreprise si vous n'avez pas pu fournir ce pour quoi il a payé. Si vous travaillez directement pour une organisation, votre manager ou cadre pourrait perdre confiance en votre capacité à livrer ce qu'ils souhaitent.<\/P>Une fois qu'une organisation a consacré du temps et de l'argent au développement d'une solution, elle voudra naturellement un retour sur cet investissement. Une application qui n'apporte aucun bénéfice ne sera pas utilisée, mais planera sur le lieu de travail comme une mauvaise odeur, risquant potentiellement d'altérer l'impression que les gens ont de vous ou de la suite logicielle que vous utilisez.<\/P>Lorsque nous nous concentrons sur la vue d'ensemble, nous veillons à ce que nos applications répondent aux besoins des utilisateurs plutôt qu'à l'aspect technique. Il est compréhensible d'être enthousiasmé ou fier d'un morceau de code que vous avez écrit ou d'une manipulation inspirée des données, mais cela ne peut pas se faire au détriment du besoin réel qui nous a été donné.<\/P>La dernière chose que nous voulons voir est ce premier spasme de vie traverser quelque chose auquel nous avons consacré temps et efforts, pour réaliser ensuite que nous avons créé un monstre.<\/P><\/BODY><\/HTML>
