TravailleursDuWeb se BLACK OUT contre HADOPI

Les 6 grandes phases d’un projet

Publié le 23 October 2008, par Babozor dans la catégorie Gestion de projet

phase.jpg

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…



Laissez un commentaire