Les conditions d’un bon ratage

Pourquoi certains projets fonctionnent et d’autres non ? Est-ce lié au niveau technique des membres de l’équipe, à un manque d’organisation, un manque de visibilité, un manque de documentation ? Je vais vous partager mon expérience et ma conviction sur ces questions.

Mes petits camarades et moi même avons déjà parlé sur ce blog des clés de succès d’un projet, mais rarement (voire pas du tout) des causes d’échec.
Qu’est-ce qu’un projet raté ? voici mon échelle personnelle de notation (qui vaut ce qu’elle vaut) :
– le ratage ultime : beaucoup de temps perdu, de l’argent dépensé avec aucun résultat (même pas une page de connexion à se mettre sous la dent ou un petit batch qui tourne la nuit)
– le ratage pur et simple : le produit est en prod, les utilisateurs sont frustrés, le client mécontent (trop de temps et d’argent dépensés pour un résultat médiocre)
– la pseudo réussite : l’appli est en prod, ça fonctionne, mais le client reste sur sa faim (le budget a été globalement maîtrisé, mais idéalement ça aurait pu mieux se passer)
– la réussite : l’appli est en prod, les utilisateurs sont heureux (le client également) et le budget a été maîtrisé et tout a été livré et installé dans les temps

Cette échelle peut s’appliquer sur tous les types de projets qu’ils soient réalisés en interne, chez le voisin ou en offshore à des milliers de kilomètres.
Je vais m’attarder ici à parler de ce que je maîtrise le mieux, les projets offshores.

Selon moi, la cause principale d’un échec sur un projet offshore est le manque de confiance du client envers son prestataire. Et ce manque de confiance se traduit par différents phénomènes…

1. Une avalanche de documentation

Un client qui débute en offshore risque parfois de demander ou de fournir de la documentation à outrance en pensant que plus on rédige, plus l’équipe à distance saura ce qu’elle a à faire et le fera bien. C’est ce que j’appelle la crise de documentitude aiguë. Il faut bien sûr formaliser un minimum, expliquer ce qu’on veut ou va faire, dessiner les écrans (l’ergonomie est importante), définir les règles de gestion… mais à trop vouloir documenter (rédiger le document qui permet d’expliquer comment on utilise le serveur de sources, celui qui explique que chaque ligne doit être commentée, un autre qui précise l’utilisation du téléphone et la codification lors de l’envoi d’un mail) on en arrive à des situations dans lesquelles 30% du temps est passé à rédiger ou mettre à jour de la doc, avec des documents qui se contredisent (plus on a de documentation, plus le risque est important). De plus, j’ai rarement rencontré des gens passionnés par la rédaction (je ne côtoie sans doute pas les bonnes personnes), mais c’est un constat que je fais. Et forcément, on a toujours mieux à faire, le délai de rédaction grandit, le planning s’allonge, l’équipe qui ne produit rien de concret se démotive et le produit n’avance pas.

2. Être trop exigeants sur les profils

Souvent nos clients demandent à valider les profils que nous leur proposons pour leur équipe. C’est normal et ça peut se comprendre. La dérive de cette démarche apparaît chez certains lorsqu’ils commencent à refuser des profils qu’ils auraient acceptés s’ils avaient été Français et chez eux ou alors qui décident de sortir une personne de l’équipe à la première petite erreur. Les conséquence de cette situation sont donc une équipe qui peine à se constituer, des changements fréquents et donc un manque de stabilité. A ceci s’ajoute le fait de former les nouveaux arrivants, de gérer tout ce qui tourne autour (ouverture/fermeture de comptes, demande d’accès aux outils…). On perd en efficacité. On perd du temps. Le produit n’avance pas.

3. Vouloir gérer le projet à distance

J’ai eu une expérience de cette nature par le passé (avec une équipe en Roumanie et un chef de projet en France) : ça ne fonctionne pas ! …ou alors sous certaines conditions. Alors lorsqu’un client nous demande de monter une équipe, mais refuse que le management soit fait chez nous, nous le mettons en garde. Manager à distance une équipe qu’on ne connait pas, c’est un peu comme faire construire sa maison secondaire dans un pays lointain, sans architecte, ni maître d’œuvre sur place et en communiquant directement avec les ouvriers tous les matins pour leur expliquer quel mur monter, quel robinet installer. On a l’impression de tout maîtriser, mais finalement l’ouvrier ne comprend pas ce qu’il fait, n’a pas la vision complète de ce qu’il est en train de construire. Il devient simple exécutant alors que c’est un professionnel du métier. La comparaison est peut-être osée, mais on comprend bien que ce n’est pas cohérent. En conclusion, la maison (le produit) n’avance pas et surtout ne correspond pas aux attentes.

4. Demander trop de reporting et d’indicateurs

Pour être sûr que l’équipe avance, les clients qui débutent en offshore ont parfois tendance a mettre en place trop d’indicateurs, de demander à chaque membre de l’équipe d’expliquer ce qu’ils font au quart d’heure près… Et malheureusement ça ne rassure personne : l’équipe se sent observée à la loupe et se stresse, elle perd du temps à fournir ces infos et produire tous ces indicateurs. Le client, quant à lui, passe énormément de temps à tout analyser, il peut parfois en tirer de fausses conclusions (si des indicateurs se contredisent). On perd en efficacité. Le produit n’avance pas.

Il y a d’autres dérives du manque de confiance d’un client envers son prestataire, mais cela résume déjà assez bien quels peuvent être les écueils.

« C’est bien joli tout ça », me direz-vous, « mais moi, client, je ne vous connais pas trop. On s’est rencontré 2 fois lorsque nous vous avons exposé notre besoin, puis lorsque vous nous avez présenté votre proposition. Mon produit va être réalisé à plusieurs milliers de kilomètres par des gens que je ne vois pas et que je ne connais pas. Qui me dit que je vais en avoir pour mon argent, que l’application développée sera robuste, qu’elle répondra à mes attentes. »

Il « suffit » simplement de considérer le projet comme une sorte de partenariat, d’engagement mutuel : vous devez accorder votre confiance et nous devons entretenir et faire grandir cette confiance. Cela passe bien sûr par plusieurs étapes :
– se mettre d’accord sur ce qui est le plus important pour vous : la qualité ? la réactivité ? la traçabilité ? En fonction de votre activité, de votre projet, la part de chacune de ces composantes change.
– rencontrer l’équipe : cela permet d’humaniser la relation, d’apprendre à se connaître, à se faire confiance (cela peut se faire via la mission pivot au démarrage du projet ou lors de présentations régulières sur site de vos objectifs, des enjeux du produit…)
– mettre en place des indicateurs simples et peu nombreux qui mesurent l’équipe sur vos priorités (on ne peut pas demander à une équipe d’être réactive, de produire 0 anomalie, d’avoir une architecture toujours à la pointe de ce qui existe, en demandant des évolutions et des changements toutes les semaines 🙂 )
– valider l’efficacité de l’équipe sur des délais de 1 à 2 semaines (le temps d’une itération ou d’un sprint par exemple) et non sur des tâches de 15 minutes avant de tirer des conclusions et de mettre en place des actions. Un développeur peut passer 1/2 journée à faire une tâche et 30 minutes sur les suivantes (au lieu de 1h par tâche comme cela avait été estimé).
– accepter de votre équipe offshore ce que vous accepteriez dans votre entreprise
– et bien sûr, pour nous le prestataire, être complètement transparent sur les succès et les échecs et partager les risques.

En respectant ces quelques règles de bon sens, vous avez toutes le cartes en main pour réussir cette collaboration offshore.