La plupart des projets informatiques échouent à cause d’un mauvais management. Il n’y a pas forcément de responsable(s) à désigner, et il n’est pas évident de trouver les éléments à améliorer, qui peuvent varier d’un projet à l’autre voire d’un sprint (en Scrum) à l’autre. Néanmoins, l’expérience montre que certains besoins reviennent régulièrement.
Distinguer productivité et disponibilité
La productivité est le Saint Graal des chefs de projets MOE en quête de réussite. Abattre le plus de projets avec le moins de jour/homme, tel est leur credo. Certains n’hésitent pas à jongler pour déplacer des collaborateurs d’une équipe à une autre, au gré des besoins, demandant à chaque développeur le nombre exact de jours nécessaires pour réaliser une tâche et calculant les plannings au jour près.
Seulement voilà : déplacer des collaborateurs pour remplir des besoins verbalisés ne fonctionne pas. D’abord, parce qu’il est excessivement difficile de prévoir le coût d’un projet au jour près avant d’en avoir atteint environ le tiers. Le cône d’incertitude est trop large, et les estimations varient d’un quart à quatre fois le temps réellement nécessaire. Ensuite, parce que les incertitudes autour des spécifications du projet entrainent des aller-retour avec les commanditaires et que ces aller-retour peuvent entrainer des ré-évaluation du temps nécessaire. Même en itérant des petites tâches avec un modèle agile. Enfin, cela ne fonctionne pas parce qu’un collaborateur n’est pas un poids que l’on déplace sur une balance pour la faire pencher : sa contribution n’est pas égale, d’un projet à un autre. Pire : sur un projet qu’il maitrise peu, un collaborateur peut freiner la dynamique d’une équipe qui n’hésitera pas à l’aider à prendre ses marques en dépit de sa productivité immédiate.
Si vous souhaitez réellement améliorer la productivité de vos collaborateurs, ne modifiez pas la taille de vos équipes. Concentrez-vous plutôt sur deux choses : la motivation et le leadership. Donnez une direction à vos équipes, faites-leur entrevoir une finalité à laquelle ils auront contribué. Une fois qu’il auront une bonne idée de l’objectif et de l’importance de leur participation, donnez-leur une voix à suivre (celle de leur responsable, du technicien le plus expérimenté, du collaborateur le plus passionné) qui sera leur guide. Si un de vos développeurs a besoin d’aide, faites en sorte qu’il se sente libre de le dire et donner lui des opportunités de l’exprimer.
N’hésitez pas, également, à mettre en place une stratégie de montée en compétences communes. Pour cela, favoriser l’échange plutôt que la rédaction de documents et n’hésitez pas à faire basculer un développeur, un jour par semaine, sur la même tâche qu’un autre. Cela vous fera perdre du temps, c’est certain. Mais à termes, la qualité du code produit tout comme la capacité de l’équipe à absorber l’absence d’un membre seront améliorées. Et vos développeurs seront ravis d’avoir eu l’occasion de toucher à l’ensemble des projets, car ils auront une meilleure vision de la solution globale.
Garder le commanditaire à la périphérie du projet
Nous devons comprendre ce que les commanditaires veulent, et quand ils en ont besoin. Cet impératif est d’autant plus fort quand les projets prennent du retard. Il est courant que les commanditaires ne soient pas mis au courant, afin de « ne pas les inquiéter », car le chef de projet pense que le dépassement pourra être rattraper dans une phase postérieure du projet. Mais le plus souvent, ce retard n’est pas rattrapé et ce n’est qu’une fois au pied du mur que le chef de projet décale la date de livraison. Le retard devient alors réellement problématique alors que s’il avait été communiqué plus tôt, il aurait pu être anticipé par le commanditaire.
La raison de ce comportement est simple et compréhensible : la peur de décevoir. La solution est simple aussi : communiquer. Si vous communiquer régulièrement avec vos commanditaires sur les difficultés rencontrées, et l’énergie que vous dégagez à essayer de les résoudre, leur déception en cas d’imprévu sera moindre, car cela ne sera pas une surprise. Mieux, ils seront en mesure de comprendre ce qui, dans leur demande, a pu générer des difficultés. Ils pourront ainsi, sur certains projets dont la date de livraison est cruciale, réfléchir avec vous, en amont, à l’élimination des risques.
L’équilibre est délicat à trouver car un commanditaire trop présent peut nuire à un projet en ajustant trop souvent sa demande ou en analysant les zones ponctuelles d’avancement rapide comme une absence de charge de l’équipe. À vous, chef de projet, de trouver la juste mesure dans votre communication et garder vos commanditaires sous contrôle.
Considérez les retours de vos développeurs
Un chef de projet doit penser plus loin que ses développeurs, mais ce n’est pas une raison pour ne pas les écouter. Dans le développement logiciel, vos collaborateurs sont votre seule ressource : il n’y a rien de plus important que de vérifier qu’ils ont tout ce qu’il leur faut pour faire leur travail. Malheureusement, de nombreux chefs de projet préfèrent se focaliser sur des dates, des réunions ou des échéances, ce qui est aussi une bonne chose car cela permet de pousser le projet en avant, mais parfois le retour des développeurs est négligé. S’en suit des problématiques de productivité, des raccourcis techniques mal pensés, des développements de mauvaise qualité…
Et ne croyez pas que vos développeurs ne vous demandent rien parce qu’ils ne vous demandent rien. Leur silence est en soin une demande. Aucun projet n’est parfait et aucun développeur ne rencontre jamais de problèmes. S’ils ne vous en parlent pas, c’est qu’ils considèrent soit que vous ne pouvez pas les aider, soit qu’ils n’ont pas le niveau pour les résoudre eux-même. Dans la plupart des cas, le problème n’est pas tant technique qu’une blessure à l’égo. Ce silence peut alors devenir le symptôme d’un cercle vicieux où le développeur aura tendance à se replier sur lui-même et ses défauts.
Écoutez vos développeurs. Sachez capturer les plaintes récurrentes et les silences suspects. À vous ensuite de tenter de les résoudre ou au moins d’y apporter une réflexion, une valeur ajoutée, ou une réorganisation du projet qui permettra aux personnes en difficulté de bénéficier des connaissances de développeurs plus expérimentés. Rien de sert de faire durer les choses en les formalisant par des sprint de revue de code ou des processus extrêmement formalisés. Souvent, une discussion Over-The-Shoulder sur une portion de code difficile suffit à débloquer une situation. Arrangez-vous juste pour que cette discussion ait lieu, en permettant à vos développeurs d’exposer leurs problèmes sans pénaliser leur égo.