Gouvernance des projets mobiles

L’environnement “ mobile ” introduit des spécificités dans la gouvernance des projets, dont l’impact est très fortement dépendant du niveau de maturité des acteurs du projet (sponsor compris) vis-à-vis du mobile.

Si le côté innovant et excitant de ce type de projet est bénéfique dans la mesure où il induit une forte implication de l’ensemble de ses acteurs, il peut également faire que de nouveaux interlocuteurs souhaitent s’y greffer (parfois à des hauts niveaux de responsabilité), ce qui vient complexifier fortement les phases de cadrage et de conception car apparaissent alors des circuits de validation parallèles et parfois contradictoires, difficilement arbitrables en Comité de Suivi.

Plutôt que chercher à empêcher ces acteurs de participer au projet, mieux vaut les intégrer très tôt à ses étapes clés (lancement, validation du cadrage, livraison en avant première). Il faudra aussi veiller à ne pas perturber les équipes projets (DP, CP) du côté client mais aussi du côté prestataire par rapport aux orientations qui pourraient résulter de l’intégration des remarques de ces acteurs. Même si on ne peut affirmer qu’un projet mobile est obligatoirement un projet d’intégration, nous constatons que l’intégration et tous les sujets périphériques liés (sécurité, développement métier, interface, hébergement, roadmap…) sont déterminants dans la réussite d’un projet mobile.

Il faut donc bien s’assurer en amont du cadrage et de la conception que les problématiques liées à l’intégration (c’est-à-dire la capacité à amener des informations d’un système central vers un système réparti) aient été identifiées, calibrées et validées par les équipes en charge de ces systèmes. Une attention particulière devra être portée à bien échanger “ entre experts ” sur les spécificités, les forces et les faiblesses de l’environnement mobile.

A la différence du web où les scénarii de test sont relativement prédictifs (navigateurs, réseau, plugin…), le mobile introduit une grande quantité de variables qui ne seront pas toujours évidentes à anticiper :

  • Paramètres hardware (écran, mémoire, CPU, version OS…)
  • Paramètres réseau (non connecté, WIFI non connecté à internet, WIFI, 3G, 3G dégradé dans une zone à forte densité d’utilisateurs, edge, temps de latence, instabilité de la connexion…)
  • Paramètres abonnement data (filtrage de port, bande passante dégradée, contenus interdits ou billés différemment, vidéo…)
  • Paramètres d’utilisation des ressources du terminal par les autres applications (alertes mémoire, plus de disque local disponible, appel téléphonique, appareil photo…)

Il est donc absolument indispensable, au-delà des séquences habituelles de test (tests unitaires, de non régression, recette partielle…) d’introduire une phase de recette supplémentaire dans un environnement réel c’est-à-dire :

  • Avec de vrais terminaux, avec d’autres applications (jeux, actualités…) et de vrais abonnements data conformes à ceux utilisés par les clients de l’application (ne pas sous estimer les divergences qui pourront apparaître d’un opérateur à l’autre par exemple) ;
  • Dans des zones de couverture réseau en rapport avec la cible adressée par l’application. Cette spécificité liée au contexte mobile est systématiquement minimisée d’un point de vue planning mais aussi d’un point de vue des moyens à mobiliser (déplacement, matériel…).

Il s’agit donc de veiller à suivre rigoureusement l’organisation et prendre en compte impérativement ces étapes dans le cadre de la gouvernance de projets mobiles.

0 commentaires

votre commentaire

Se joindre à la discussion ?
Vous êtes libre de contribuer !

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Inscription newsletter

Ne manquez plus nos derniers articles !