Suivi de l’équipe offshore 

Les mesures univoques

Lorsqu’on construit un reporting, il faut avant tout s’assurer que les mesures et les événements que l’on observe ont la même signification pour tous. Certaines mesures ne conviennent pas, sont ambiguës ou, pire, poussent à des comportements qui ne sont pas dans l’intérêt du projet. Par exemple, sachant que le client observe certains indicateurs, le prestataire peut vouloir en favoriser la bonne tenue. Une erreur fréquente consiste à construire un indicateur pour mesurer la qualité d’une équipe de développement à tenir ses engagements de livraison du code source. Cette livraison, certes importante dans un cycle de développement, devrait en fait passer au second plan pour laisser la primauté à la livraison recettée, en sortie de test, avec un niveau de qualité minimal ou, si l’on veut absolument un événement plus proche des développements, la fin d’une recette unitaire vérifiée par l’équipe de test. Faute de cela, la livraison en sortie de développement sera peut-être réalisée dans les temps, mais avec un niveau de qualité tellement variable que l’on ne pourra pas en déduire de façon certaine une date d’intégration. C’est pourtant cette date, à laquelle le code est testé et déployable, qui intéresse avant tout le client. Une autre mesure maladroite courante est illustrée par le taux d’avancement des modules en cours de création. Cette estimation est proposée au jugé par les développeurs, alors qu’ils ne sont pas certains eux-mêmes de la valeur qu’ils communiquent. On constate parfois que des taux d’avancement régressent, comme si le développeur défaisait ce qu’il avait réalisé la veille. Des modifications des couches techniques nécessitent en fait de retravailler des couches fonctionnelles, et la prise en compte de ce travail mène à une estimation plus défavorable du temps restant, ce qui explique la régression apparente.  Certains indicateurs en apparence simples fournissent ainsi des valeurs souvent trompeuses. En réalité, la plupart des mesures sont ambiguës et ne concordent pas avec ce qu’elles sont censées représenter. La raison à cela est qu’elles sont entachées d’une part d’interprétation. Les livrables, que l’on parle de programmes, de documents ou de formations, doivent être correctement définis pour qu’il n’y ait pas d’ambiguïté sur le niveau de qualité, qui est toujours difficile à définir, ni sur le travail encore nécessaire pour en disposer dans un état utilisable. La mesure elle-même, si elle est subjective, doit être définie clairement entre les participants. Par exemple, si l’on parle d’un niveau d’avancement du développement d’une fonctionnalité jusqu’à la livraison en production d’une fonction recettée, on peut définir certains pourcentages clés, comme 10 % pour la fin de l’analyse et de design, 75 % pour la fin du développement (avec une recette unitaire réalisée par le développeur), etc. On peut ainsi définir des niveaux d’avancement pour chaque jalon correctement atteint selon l’avancement du codage et des tests d’une fonction. Une autre erreur commune consiste à s’appuyer sur des mesures qui ne signifient pas la même chose chez le client et chez le prestataire. La collecte des informations se fait assez facilement chez le prestataire, car il comprend qu’elles sont réellement utiles au client. Par exemple, si un planning détaillé s’accompagne de mises à jour de la progression de chaque tâche et que certaines tâches montrent un retard significatif, le chef de projet du client qui suit la progression de ces tâches blâme l’équipe en retard. Pourtant, cette dernière n’a fait que respecter les nouvelles directives du client en corrigeant une fonctionnalité de toute urgence. Si le chef de projet du client accuse à tort l’équipe distante, alors qu’elle a peut-être remarquablement travaillé, c’est qu’il suit un indicateur qui n’est plus significatif du travail de cette équipe. Certains managers du client peuvent avoir tendance à piloter le projet uniquement à travers certains indicateurs, alors que ceux-ci ne rendent compte que d’une partie infime de la situation en offshore. Lorsqu’un de ces managers demande à l’équipe en offshore d’expliquer ses dysfonctionnements, il apparaît, comme dans l’exemple précédent, qu’une grande partie de ceux-ci se trouvent injustement exagérés par les moyens de mesure et ne rendent pas compte d’autres problèmes ou directives tout aussi importants. Le manager ne peut dès lors que perdre rapidement du crédit aux yeux de l’équipe distante du fait de son mode de suivi très éloigné de la réalité. Un suivi serré du planning peut faire apparaître que l’équipe en offshore n’a pas respecté ses engagements de livraison, mais aucun indicateur n’expliquera facilement les raisons qui ont mené à cette situation. Il se peut que des changements importants aient entraîné des retards ou bien que le planning, s’il n’a pas été géré par itération et qu’il date d’une période déjà ancienne, soit très éloigné de l’ordonnancement et de l’estimation réels des tâches. Les reproches que l’on adresse alors sont injustifiés et démontrent l’incapacité du client à suivre le projet.

Les visites au prestataire

Les déplacements réguliers chez le prestataire ne peuvent être évités si l’on veut suivre précisément les prestations de l’équipe en offshore. Aussi sophistiqués soient-ils, les indicateurs et mesures que l’on met en place ne sauraient rendre compte de toutes les situations. Certains processus peuvent être finement et efficacement suivis par une série d’indicateurs, tandis que des paramètres tels que la motivation des équipes ou une perte de productivité sont pratiquement impossibles à rapporter. Des indicateurs peuvent être considérés comme les effets d’une démotivation sans pour autant permettre de détecter les causes des dysfonctionnements. Pour mesurer pleinement ces sujets généralement complexes, il faut se rendre régulièrement chez le prestataire en offshore. Comme expliqué précédemment, les visites chez le prestataire doivent être ouvertes afin de construire et maintenir un esprit collaboratif. Il est beaucoup plus facile de détecter les dysfonctionnements les plus importants avec l’aide du management du prestataire plutôt qu’en essayant de les repérer s’il cherche à les dissimuler. Une fois les problèmes repérés, on peut prendre les mesures qui conviennent et mettre en place, lorsque c’est possible, certains indicateurs spécifiques afin de suivre l’amélioration du dysfonctionnement de façon systématique, sur la base de sources d’information existantes ou créées spécialement pour suivre ce sujet. Lors des voyages chez le prestataire, on retrouve presque toujours les mêmes sujets à traiter : • Communication sur le projet tel qu’il est perçu par le client, avec présentation des insatisfactions les plus importantes et, éventuellement, félicitations pour les réussites. • Analyse de chaque sujet difficile avec les intéressés et mise en place des actions correctives et des indicateurs de suivi lorsque c’est possible. Présentation de l’analyse qui est faite des indicateurs sur les sujets délicats et prise en compte des commentaires sur leur usage. • Formations complémentaires ou explications détaillées de ce que l’on attend des équipes . • Vérification avec les personnes concernées du respect des procédures en place et amélioration de ces procédures. Ces entretiens peuvent être personnels ou s’élargir à des groupes de personnes. Il est fortement recommandé d’organiser les réunions avec toutes les personnes concernées et de ne pas se limiter aux supérieurs hiérarchiques.