Discovering what life is about

Les 6 grandes phases d’un projet

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…


Gestion de projet technique: mes quelques conseils…
Publié le 20 October 2008, par Babozor

dans la catégorie Développement, Gestion de projet


Voilà près de 10 ans que je suis dévelopeur web et quelques années maintenant que je suis chef de projet technique (et le plus souvent les deux en même temps) et voici donc quelques conseils, tirés de mon expérience… sur les projets en général et la gestion de projet technique.


1. Vision macroscopique du projet
Il est extrêmement important de pouvoir avoir une vision macroscopique, c’est à dire voir le projet dans son ensemble… le concept, l’application de ce concept, les implications techniques divers, aujourd’hui, demain, les gens qui vont utiliser le produit… pour pouvoir laisser des portes ouvertes pour d’éventuelles évolutions.
Il est important aussi de voir les différentes parties et les différentes personnes qui en seront en charges pour pouvoir évaluer précisément les différentes tâches à répartir aux différentes personnes de votre équipe (en fonction de leurs compétence et disponibilité).
Il est aussi très important d’identifier les différents interlocuteurs pour les différentes parties du projet: graphisme, montage, données, développement, etc… pour éventuellement aller leur donner ou chercher différentes informations.

2. L’attention au détail: vue microscopique
L’attention au détail est primordial, je ne dis pas de chipoter mais de très tôt pouvoir être capable de redresser une situation. Cela veut dire suivre les personnes qui sont sur le projet, parler régulièrement avec eux… et revoir le code ensemble. Plus vous laissez passer et plus les gens prennent des libertés, donc mon conseil, soyez con très tôt, frappez fort et vite et vous verrez ça améliorera grandement la qualité de votre projet.
Vous risquez cependant conflits et engueulades mémorables, donc choisissez bien vos batailles, cela doit être des points importants, primordiaux, pas des clopinettes. Vous devez aussi expliquer cela ne sert à rien de brailler bêtement.

3. Dialoguer
Avec tout le monde, mais avec vos développeurs de préférence… Soyez là pour eux, si ils ont de problèmes, des questions, des trucs qui les embêtent. 50% du rôle de CdP Technique est d’accompagner l’équipe dans tous ses tracas, aussi techniques, administratifs, personnels.
Je ne dis pas d’être cul et chemise avec tout le monde, mais votre rôle est d’être le grand frère vers qui les gens peuvent se tourner pour avoir des conseils, des débuts de réponse. C’est aussi votre expérience que les gens recherchent, donc ne vous enfermez surtout pas dans le rôle du pseudo chef, écoutez (très souvent vos dev ont autant voir plus à vous apprendre que vous même)…
Tenez aussi très souvent au courant vos boss de l’avancement du projet, des différentes difficultés, des problèmes à venir, etc…

4. Proposer des alternatives: se délester des décisions stratégiques
Ne prenez pas les décisions à la place de vos boss, ce sont à eux de les prendre, mais exposez clairement les différentes alternatives et surtout les conséquences techniques et les différents coûts qui leur sont liés.
Souvent les CdP Techniques pensent faire une faveur en prenant à leur charge ce genre de décisions, sans penser aux lourdes conséquences qu’elles peuvent avoir pour eux.

5. Etre à l’écoute de nouvelles solutions/technologies
Cela fait partie de votre travail… trouver des solutions alternatives, tester différents produits, etc… Souvent vos boss trouveront que c’est une vilaine perte de temps, jusqu’au jour où vous trouverez une alternative qui leur permettra d’économiser deux mois de développement. Cela partie de votre travail, de vous tenir informer des nouvelles technos, des tendances, etc…
N’ayez donc pas honte ou peur de prendre du temps pour tester telle ou telle techno, pour faire de la veille

6. Laisser tomber le papier, s’imprégner du projet… demander des précisions / explications… tout le temps
Les cahiers des charges fonctionnels ou techniques c’est très bien, mais cela ne reflète pas la réalité du projet, cela représente pus le fantasme du projet que sa réalité. Faites vous expliquer le projet, ses implications, faites des dessins, des schémas, privilégiez le contact direct plus qu’une source papier, qui peut être interprétée de manière différentes suivant les acteurs qui l’écrivent ou la lisent.

Ref :  http://www.travailleursduweb.com/2008/10/23/les-6-grandes-phases-dun-projet.html

---
Categories : Work    Themes : Project
Share |
add a comment...

0 Comment

Leave a Comment