Que vous travailliez en freelance, dans une agence web parisienne ou au service informatique d’une grosse entreprise, une des principales batailles pour les travailleurs du web se trouve toujours autour du temps.
Cette donnée est variable, mais on prend comme base de référence trois données:
- temps estimé: c’est le temps qui a été estimé lors du devis, et transmis au client pour approbation
- temps réel passé: c’est le temps réellement passé par toute l’équipe (chefs de projet, graphistes, développeurs, etc…) pour mener à bien le projet.
- temps facturé: c’est le temps facturé au client.
Idéalement les trois temps sont plus ou moins égaux, mais en réalité ces trois données sont pour le moins disparates.
La meilleure des configuration reste: un temps estimé légèrement supérieur au temps passé et un temps facturé encore un poil supérieur au temps estimé (ou un tout petit peu inférieur si c’est un bon client…).
Evidemment cette situation idéale, ne correspond en rien à la réalité, en général le temps estimé est volontairement sous-estimé (principalement pour obtenir la signature du client), le temps réel passé et difficilement quantifiable (l’apparition et la résolution de bugs peut s’avérer problématique) et le temps facturé se situe la plupart du temps entre les deux…

La question principale est donc la suivante:
Comment faire pour réaliser un site, sans perdre de l’argent?

1. Bien quantifier le travail
Cela passe par plusieurs étapes cruciales. La première est une conception fonctionnelle (nous y reviendrons dans un autre article) sans faille, puis faire faire une estimation de la charge de travail par le département créatif (pour la réalisation de la charte, le montage HTML, le flash si besoin, etc…) et technique (pour valider le temps alloué à chaque fonctionnalité du site et évaluer la cohérence de la conception fonctionnelle, que rien ne manque).
En faisant cela, vous n’éviterez pas les revirements de dernière minute du client, mais vous expurgerez 90% des zones d’ombres qui peuvent faire exploser votre temps de réalisation. Cette estimation a bien évidemment un coup, mais celui-ci est bien inférieur à celui d’incessantes modifications quand le projet est en production (et vos monteurs, graphistes et développeurs vous en remercieront soyez en sûr…)

2. Un développement modulable et flexible
Que ce soit pour le montage HTML ou pour le développement (que ce soit de l’OpenSource ou du propriétaire), une bonne démarche est de prévoir un montage/développement modulaire et flexible, cela veut dire en général adopter la méthode MVC (Model/View/Controller) qui permet de détacher les accès à la base de données (ou aux bases de données), le Template c’est à dire le montage HTML, et la logique applicative (je clique ici je fais telle action, cette page fait ceci, cela… les actions côté serveur et client).
Cela vous permettra, de gérer les évolutions possibles du projet, le changement de base de base de donnée par exemple se fait sans trop de dommage (pour passer de MySQL à Oracle par exemple, toutes les requêtes sont parfaitement identifiées dans des fichiers séparées et vous n’avez pas à retoucher toutes les pages), le changement de charte graphique, etc… (je reviendrais un jour sur cette optique MVC qui est vitale pour un développement propre, cohérent et modulaire)

3. Une gestion de projet intelligente
Je sais que ça paraît bête de dire ça, et évident pour certains, mais après avoir bien défini les besoins et estimé la charge de travail, et mis le montage et développement sur la bonne voie, une gestion de projet “à la culotte” aussi bien fonctionnelle que technique est indispensable.
Qu’est ce que ça veut dire en clair?
Cela veut dire, savoir anticiper les problèmes, voir les points de blocage qui arrivent aussi bien fonctionnels que techniques, faire des aller-retours fréquents avec le client, pour lui montrer que le projet avance bien, pour avoir son avis, ses retours (plus on l’a tôt et plus vite on peut redresser la barre), etc… et surtout ne livrer que des pages et fonctionnalités qui ont été testés fonctionnellement sur la majorité des navigateurs et environnements (il n’y a rien de pire que de tester les dev sur un seul environnement, par exemple IE, en oubliant Firefox ou Safari).
La pire des situation a éviter est de présenter le dev finalisé, à un client qui découvre son site et qui n’est pas content, cela signifie souvent des semaines de travail pour corriger l’application, l’exaspération de toute l’équipe et un client pas content… mais surtout une perte sèche pour l’entreprise qui doit financer un debuggage et changement pas prévu.

Bon, bien sûr cette description est un peu naïve, j’ai rarement vu dans mon parcours professionnel un projet qui se déroule bien sur toutes les étapes, et le plus souvent on a pas le temps ni de faire une étude fonctionnelle et technique correcte, ni de mettre en place un développement propre, ni de dialoguer régulièrement avec le client… c’est une situation idéale, mais qui se rencontre peu, malheureusement.

Cet article a été posté le Friday 23 February 2007 à 2:00 pm et a été classé dans la catégorie Gestion de projet.