samedi 1 mars 2014

Échec ou réussite d’un projet applicatif, la ligne est mince


Voilà maintenant 10 ans que j’œuvre dans le monde du web et j’ai eu l’occasion de travailler sur une multitude de projets de toute taille. À travers ces projets et grâce aux collègues de travail avec lesquels j’ai collaboré, j’ai développé plusieurs compétences telles que l’analyse et la rédaction.

Aujourd’hui, je vous dirais que j’ai une préférence pour les projets qui ont un caractère applicatif (boutique en ligne, extranet, intranet et service web). Ces projets sont rarement propices à la technique du « copier/coller », car ils exigent l’aide de nos méninges en raison du grand nombre d’éléments développés sur mesure.

J’ai remarqué à travers mes expériences que la clé du succès des projets applicatifs réside dans les points suivants :

  • Travail d’équipe client/fournisseur;
  • Compréhension des besoins du client et des utilisateurs;
  • Maîtrise des règles d’affaire du client;
  • Définition des phases du projet;
  • Analyse des fonctionnalités;
  • Schématisation de l’ensemble du projet;
  • Production d’un prototype illustrant les principales interfaces;
  • Rédaction d’un plan de projet constamment mis à jour pendant le développement;
  • Récupération des commentaires des utilisateurs;
  • Documentation du système :
  • Document de formation pour les usagers;
  • Document technique pour les développeurs.

Tout ça semble simple à appliquer, mais en réalité il est facile de négliger ou d’ignorer un de ces points et de compromettre la réussite du projet à court, moyen ou long terme. Outre la documentation qui est souvent négligée, il y a les utilisateurs. Ce sont eux qui vont utiliser le produit et qui vont déterminer s’il s’agit d’un échec ou d’une réussite.

D’un autre côté, il faut aussi savoir se limiter dans l’analyse et la documentation pour éviter de transformer le projet en éléphant blanc.

Mon dernier conseil : Considérez tous les projets web comme un investissement qui donne naissance à un produit qui pourra évoluer dans le temps selon les besoins et non pas comme une dépense unique pour obtenir un produit final.

Aucun commentaire:

Publier un commentaire