Après avoir bien défini les contours du projet comme je l’expliquais dans ce billet, il a fallu passer à la réalisation du site, dont nous avions la responsabilité.  Nous avons obtenu cette partie du contrat du fait des coûts que nous proposions et de notre proposition de solution qui contrairement à d’autres réponses à l’appel d’offre semblait réaliste étant donné le délai très court (moins de 8 semaines pour la première version).

Nous avons pu proposer cela grâce à:

  • Une équipe de développement offshore (reduction des coûts)
  • Une méthode de conduite de projet agile (gain de vitesse et de qualité)


La mise sur pied d’une équipe de développement offshore

Pour pouvoir proposer des coût compétitifs de développement, Kimind travaille depuis l’origine avec des équipes de développement offshore (localisées en Chine). Nous avons acquis un certain savoir-faire à ce sujet, éprouvé sur différents projets. Le développement offshore, un sujet à la mode… Il est clair que cela nécessite une grande habitude du travail collaboratif à distance. Cela tombe bien car tout le monde télétravaille chez Kimind!

En plus de l’avantage financier, le fonctionnement agile de l’équipe de développement, nécessaire du fait de la distance pour éviter tout dérapage, contribue grandement à fluidifier le déroulement du projet.

Suivi de la qualité et du respect des délais, reporting

Notre client n’a pas eu à faire avec l’équipe de développement directement. Un consultant Kimind a fait office d’interface et a été le point unique de contact et de gestion du projet. Cela évite les problèmes de communication liés à l’offshore.

Le consultant fait office de coordinateur entre les différents acteurs (client, développeurs, designers…) et prend en charge la définition des spécifications fonctionnelles détaillées basée sur les retours et effectue le suivi qualité et d’avancement.

Le reporting s’est fait de façon transparente à l’aide d’une plate-forme projet collaborative, –Google Sites dans ce cas-, où il était possible à nos clients de suivre l’évolution du projet en temps réel et de donner leur feedback quand nécessaire. En effet les développeurs reportaient directement leur progrès à cet endroit et les spécifications et autres documentations y étaient stockées, évitant tout malentendu fonctionnel.

Au passage, on remarque que cela permet bien souvent de sensibiliser les personnes aux méthodes de travail 2.0, et qu’ils en ressortent souvent conquis! (Une fois qu’est dépassé l’appréhension de l’absence de cahier des charges ultra-détaillé (a.k.a “le parapluie”) 🙂 )

Nous avons pu faire preuve d’une grande flexibilité. La méthodologie agile employée, basée sur de courtes itérations et de nombreux feedbacks du client permet d’anticiper et de résoudre rapidement les problèmes, mais également de faire évoluer les spécifications tout au long du projet si nécessaire en gardant bien en tête les impératifs de temps.

Au final

Nous avons géré de bout en bout le projet, de la définition des besoins à la livraison, assurant à la fois l’expertise fonctionnelle et l’exécution technique. Ceci à des coûts très concurrentiels du fait de l’équipe de développement offshore et de l’utilisation de produits Open Source. Le client a été très satisfait du résultat qu’il a pu montrer dans un salon professionnel moins de 8 semaines après le démarrage du projet et qui a parfaitement couvert ses attentes (fonctionnelles, budgétaires, de délai). Les retours sur le déroulement du projet ont été très positifs, notamment concernant la réactivité des différents acteurs et notre flexibilité. Mais tout ceci n’a été possible que parce qu’une relation de confiance réciproque s’est établie: personne ne s’est abrité derrière un cahier des charges rigides de 200 pages, et tout le monde (le client, nous-mêmes, les développeurs, les designers…) a travaillé avec le seul but en tête de mener à bien le projet, en prenant ses responsabilités. C’est le pendant d’une gestion de projet “allégée” : une grande confiance et la fiabilité des collaborateurs.

Lectures similaires: