Les 6 grandes phases d’un projet
Publié le 23 October 2008, par Babozor dans la catégorie Gestion de projet
Peu importe la typologie de votre projet, son importance et le temps de développement, que ce soit un projet pro ou perso… il passera par ces différentes phases avec ses pièges et ses spécificités:
1. Le concept
C’est la phase où l’idée germe, où on passe du temps à essayer de mettre des mots sur cette idée, à tenter de trouver le moyen de la concrétiser. Bon des idées tout le monde en a… mais là c’est plutôt essayer de trouver un nouveau concept, une nouvelle interface ou encore une nouvelle approche par rapport à un problème récurrent.
Le piège principal de cette phase est de tomber soit dans un délire trop technoïde (et que personne n’adoptera à par vous et vos trois potes geek), soit que le marché n’est pas propice et aucune façon de se faire de l’argent avec par un moyen ou un autre (oui, je sais ça peut paraître bourgeois, mais à un moment ou un autre il faut bien payer pour tout ce travail…)
2. Conception fonctionnelle
Là on passe du délire conceptuel à une vraie conception… quels écran, quels formulaire, les différents pasges, les différentes fonctionnalités à mettre dans le site ou le service.
Ici gros danger de vouloir mettre trop, trop compliqué… c’est une tentation je le sais (moi aussi j’aime bien imaginer des idées et pages farfelues avec plein d’Ajax partout), mais bien avoir à l’esprit deux choses:
- plus de fonctionnalités = plus de temps = plus d’argent à dépenser
- plus de fonctionnalités = plus de bugs possibles = plus d’argent à dépenser
Donc pour une première version d’un site ou service, mon conseil: commencer par une base simple, saine et stable (et ensuite on pourra toujours rajouter des trucs au fur et à mesure)
3. Conception technique
On tente de concevoir du point de vue technique (technologies dynamiques, serveurs, base de donnée, les différentes communication, le workflow de données, etc…) le projet. C’est souvent là où viennent se poser les problèmes de timing (pour des décisions prises à la conception fonctionnelle) et de charge de travail.
C’est une étape cruciale (et trop souvent zappée malheureusement), puisqu’elle permet de câler les différentes technologies mais aussi d’avoir un retour technique sur les différentes fonctionnalités.
Le piège ici est double:
- sous estimer la charge de travail, soit parceque la conception fonctionnelle a été mal transmise, soit par méconnaissance
- l’expérimentation de techno pas stable ou pas éprouvé en production (je sais que c’est rigolo de tester des nouveaux trucs, mais pas en prod)
4. Réalisation
Sans aucun doute la partie où réside le plus grand nombre de pièges… et qui doit occuper facilement 50% du temps du projet (je reviendrais très certainement sur cette partie), mais plusieurs pièges classiques:
- le projet presque parfait jamais fini: peu importe ce que l’on fait, un site ou service web n’est jamais parfait… et vouloir le rendre parfait à tout prix, va vous mener seulement à ne jamais le rendre public (et donc va mourrir faute de financement/release)
- changement de techno en cours de route: penser qu’un changement de technologie va changer fondamentalement la pente qu’est en train de prendre votre projet est illusoire. Si les même personnes sont aux commandes ou derrière les claviers, peu importe la technologie choisie, les problèmes resteront.
- modifications fonctionnelles incessantes: sans doute le piège le plus chiant pour les développeurs (puisque ce sont eux qui en subissent les conséquences directement)… on change telle fonctionnalité et deux jours plus tard on demande à revenir à la version précédente, etc… chiant, crispant et frustrant (et au final un sacré retard, juste parcequ’on ne sais pas où on veut aller)
il y en a encore pleins de trucs dans le genre, mais ces trois là sont les plus dangereux et les plus insidieux…
5. Tests / maintenance évolutive-corrective
C’est la phase béta ou de pré-release, ou en teste le service juste avant de le rendre public. Là aussi quelques pièges relativement classiques:
- tests incomplets: c’est très souvent le cas, puisque soit vous ne testez pas toutes les fonctionnalités de votre service, soit vous les testez sur un nombre limités de plateformes (avec parfois des résultats étonnants sur certains navigateurs et/ou OS)
- maintenance qui se transforme en nouvelles fonctions: très souvent, en testant à fond une application on découvre des failles dans son application, des choses qui semblent manquer… et là nous viens la tentation de venir rajouter pleins de “petites” fonctionnalités (d’où danger).
6. Release
99% du boulot est fait, plus qu’à mettre tout ça en ligne et à aller se reposer… Erreur! car d’autres (et on espère ultimes) dangers vous guettent:
- la fameuse release du vendredi soir à 19h47: je penses que tout le monde (en particulier en agence) a dû connaître ça… pression, fatigue et on release une bouze, qu’on mets quelques heures à stabiliser (alors que le Lundi à 9h13 tout se serait bien passé)
- ne pas tester sa release (ou partiellement): du fait du changement de plateforme et même si votre plateforme de développement est iso-prod (même machine, même config, même environnement, etc…) vous vous devez de tout re-tester, ne serais ce que pour savoir si votre mailer marche en ligne, etc…
- étendre le jeu de test: autant en environnement de test vous étiez dans un environnement semi protégé, en production vous vous exposez au monde, donc testez tout… la modification farfelue de variable passée en GET, l’injection MySQL, etc…
6 grandes phases de projets, des typologies de pièges différentes.
Ah la la, difficile de penser à tout et de ne rien oublier…
le 23 October 2008 à 21h10
Bravo, tu viens de (re)découvrir le cycle en V !-)
Plus sérieusement, tu devrais peut-être sed s/phases/activités/g. Même s’il est vrai que _sur la durée d’un cycle_ on tends à faire plus de conception au début et plus de maintenance sur la fin, il y a quand même en pratique beaucoup de perméabilité entre ces activités, et il est courant que ce qui est finalement publié soit assez différent de l’idée de départ. Le fait est que pour vraiment se rendre compte de ce qu’un concept / une conception vaut, il faut généralement avoir une première implémentation (même incomplète). Et ceci vaut à tous les niveaux, et pour toutes les activités listées ci-dessus.
Tu notes que la “phase” réalisation est “sans aucun doute la partie où réside le plus grand nombre de pièges… et qui doit occuper facilement 50% du temps du projet”. C’est AMHA révélateur du fait qu’on pense trop en termes de “phases”, et qu’on ne tient pas assez compte de la perméabilité entre les différentes activités. Si on observe plus attentivement ce qui se passe durant cette phase, on voit des aller-retours incessants entre conception fonctionnelle, conception technique, *implémentation*, et tests. Voire même parfois (et pas exceptionnellement…) des évolutions du concept initial.
Bref, la réalité d’un cycle d’un projet, c’est trois pas en avant, deux pas en arrière, et un nombre aléatoire de pas sur le côté, jusqu’à ce qu’on arrive à quelque chose qui ait une chance de tenir la route. Arrivé là, c’est comme le shampoing : laisser agir, rincer, répéter.
Attention, je ne dis pas qu’il soit vain d’essayer de _gérer_ un projet, bien au contraire. Juste que croire qu’on puisse le découper ainsi en ‘phases’ successives – et cloisonnées – est AMHA totalement illusoire, dans le sens où _au mieux_, ce qu’il en sortira sera conforme à la lettre aux specs initiales, et totalement inutile / inutilisable. Il vaut certainement mieux accepter dès le début l’idée qu’un projet est une cible mouvante, que pas mal de choses vont se préciser, s’affiner, ou parfois franchement changer en cours de route.
Le challenge est alors de repérer au plus vite les incertitudes, les changements de cap éventuels, et les points essentiels en matière de valeur ajoutée, afin soit d’avoir effectivement quelque chose de fonctionnel *et* ayant une réelle valeur ajoutée
à livrer à la fin d’un cycle – quite à faire l’impasse (au moins dans un premier temps) sur les bells&whistles-, soit – au pire – d’arrêter les frais (ou au moins de faire une pause pour reconsidérer toute l’affaire) avant d’avoir bouffer tout le budget pour rien.
Et puis bien sûr, il n’existes pas “un” projet dans l’absolu, donc il n’y a pas de recette miracle. Là aussi, il faut savoir comprendre au plus vite ce qui fait la spécificité de *ce* projet particulier, pour avoir la moindre chance de mettre en place une stratégie adaptée (même s’il faudra de toutes façon (re)évaluer cette stratégie en cours de route).
Bon, on l’aura compris, je ne suis *pas* chef de projet (même si j’ai eu en pratique à assumer ce rôle en quelques occasions, plus ou moins à mon corps défendant), et je n’ai pas la prétention d’une quelconque compétence dans ce domaine, si ce n’est l’expérience d’avoir participé à quelques dizaines de projets informatiques (web ou non) de différentes envergures ces dix dernières années. A défaut d’autre chose, cette expérience m’aura permis de me faire une idée de ce qui ne marche pas en tout état de cause !-)
le 24 October 2008 à 07h55
Bonjour,
Bonne analyse, mais moi je rajouterais au début l’étape de la réponse à l’appel d’offre, dans laquelle tu vas t’engager sur des temps de réalisation et sur un prix ; des données de départ qu’il va falloir essayer de respecter.
Je rajouterais aussi une étape à la fin du projet que l’on peut appeler le bilan de projet, qui va te permettre de faire le point avec ton équipe d’une part et ton client d’autre part sur ce qui n’a pas marché, l’analyser, et trouver des solutions pour que les futurs projets ne reproduisent pas les mêmes erreurs.
le 24 October 2008 à 09h16
@buh31:
“je rajouterais au début l’étape de la réponse à l’appel d’offre”
Tous les projets ne sont pas liés à des appels d’offres !-)
le 23 December 2008 à 02h48
Ouiiiiii !
Alorsj’ajoute que dans l’élan de mon implication/investigation, tout en faisant “marche-avant, marche-arrière” (laotseu), je fais des pas de gauche et de droite, qui, pour rejoindre Buh31, me permettent de préserver l’expérience (le vécu, où j’ai déjà “planté des drapeaux”, où j’ai fais mieux que de semer des petits ‘graviers blanc’, de manière à donner plus de largeur à ma route, et… bon sang, éviter de REperdre 20% à chaque fois.
Maintenant, Y’a une question qui m’ennuie: je m’entoure de piles de paperasses criblées de notes, et je rêve d’une bonne gestion de toutes ces données, en plus des infos hébergeurs, registrars, dates inscription, ID contacts, admin, accès, snapshots… Si y’a un collègue qui me file un bon tuyau, il aura -au moins- une bouteille de Jura.
A bientôt,
DeN