Comment évaluer la performance de mon équipe de Développement TI ?

Voir la version AMP

Notice: Undefined offset: 1 in H:\root\home\emalayamm-001\www\analystik\blogue\wp-content\plugins\wp-links\wp-links.php on line 175

Notice: Undefined offset: 1 in H:\root\home\emalayamm-001\www\analystik\blogue\wp-content\plugins\wp-links\wp-links.php on line 175

Notice: Undefined variable: style in H:\root\home\emalayamm-001\www\analystik\blogue\wp-content\plugins\wp-links\wp-links.php on line 149

Notice: Undefined variable: wplinks_image in H:\root\home\emalayamm-001\www\analystik\blogue\wp-content\plugins\wp-links\wp-links.php on line 149

Notice: Undefined offset: 1 in H:\root\home\emalayamm-001\www\analystik\blogue\wp-content\plugins\wp-links\wp-links.php on line 175

Notice: Undefined offset: 1 in H:\root\home\emalayamm-001\www\analystik\blogue\wp-content\plugins\wp-links\wp-links.php on line 175

Notice: Undefined variable: style in H:\root\home\emalayamm-001\www\analystik\blogue\wp-content\plugins\wp-links\wp-links.php on line 149

Notice: Undefined variable: wplinks_image in H:\root\home\emalayamm-001\www\analystik\blogue\wp-content\plugins\wp-links\wp-links.php on line 149

Comment évaluer la performance de mon équipe de Développement TI ?

La question n’est pas simple; comment pourriez-vous évaluer la performance de votre équipe de Développement TI avec certitude ?

Il est moins simple qu’il y paraît d’évaluer la performance d’une équipe de Développement TI. Le fait est que les projets TI varient beaucoup en scope, en budget et échéancier; dans ce contexte, il est difficile de comparer !

Dans ce billet, nous ne parlerons pas de méthodes « mathématiques » comme celle des « points de fonction » (FFP) qui permettent d’évaluer la charge nécessaire associée à un développement en termes de points.  Cette évaluation donne des résultats constants, ce qui change est le nombre d’heures nécessaire par l’équipe de développent pour programmer un point de fonction. Malheureusement ces méthodes ne sont pas très répandues.

Nous parlerons de quelques éléments de base…

Les résultats parlent souvent d’eux-mêmes; le client est satisfait, votre équipe n’a pas dépassé le budget, les livrables ont été livrés dans l’échéancier, etc.

Quand c’est le cas, alors Bravo, même si ces résultats ne disent pas tout car ils peuvent être trompeurs à plusieurs égards :

  • Le projet a été livré en temps mais une grande quantité d’heures supplémentaires a été consommée
  • Les livrables ont été livrés dans l’échéancier mais l’architecture de l’application ou la qualité du code sont-ils à la hauteur ?
  • Le projet est livré en temps mais ne répond pas aux attentes

Bref, en avez-vous pour votre argent avec votre équipe de Développement ?

Et lorsqu’on s’interroge, c’est qu’on a un doute…

 

La voie de l’évaluation en développement logiciel ou comment démystifier la performance de votre équipe de développement

Bien que cela ne soit pas simple, il y a quelques pistes qui peuvent vous éclairer en tant que Directeur TI. Et la première question à se poser est : qu’est-ce qu’il faut regarder ?

Voici trois paramètres de base que tout Directeur TI devrait pourvoir évaluer sans trop de difficulté :

  • Avez-vous une bonne méthodologie de Développement ?
  • Vos Projets TI sont-ils bien définis ? (scope / portée / priorité)
  • Quelles sont les métriques que vous avez instauré sur vos Projets TI ?

 

Méthodologie

La Méthodologie Agile est à l’heure du jour depuis plus de 10 ans maintenant. Elle met l’emphase sur la valeur livrée de tout projet TI, principalement en termes de fonctionnalités.

La méthodologie Agile repose sur quelques principes fondamentaux :

  • Fixation d’objectifs à court termes
  • Communication claire / Client et Équipe de Développement
  • Cycle de court de Développement / Sprint (2-3 semaines)
  • Concept d’Équipe / Mobilisation de toutes les Ressources
  • Structure / Projets & Sous-Projets & Tâches

 

En adaptant une bonne méthodologie de développement logiciel, on assure une bonne communication et on s’assure donc qu’il n’y aura pas de déviation des priorités au cours du Projet TI, tant du côté Client que du côté Développement. La méthodologie Agile offre des bénéfices clairs :

  • mise en marché très rapide
  • meilleure gestion de projets et meilleur suivi Client
  • augmentation supérieure de la satisfaction de la clientèle et des employés
  • flexibilité organisationnelle permettant de répondre rapidement à tout changement

 

Mais il y a un bénéfice intangible de la méthodologie Agile qui se voudra très utile à tout Directeur TI, c’est qu’elle révèle rapidement l’incompétence par le fait qu’il est rapidement visible qu’une ressource n’est pas en mesure de livrer ou pas en mesure de livrer dans le temps alloué…

N.B.  Et si vous visez une Performance et une Qualité supérieure de vos Projets TI, alors inscrivez vos King Pins à une formation à la méthodologie SCRUM.

 

 

Gestion & Définition du Projet

Doit-on souligner l’importance de la Définition du Projet et de son « scope »; de l’impact de définir clairement le Projet et de bien communiquer les objectifs visés et les priorités ?

Étonnamment, oui !

Une bonne définition initiale implique que tout le monde comprend bien les objectifs, priorités et livrables du Projet; ce qui vous assurera que tous comprennent bien ce qu’il faut suivre, mesurer et livrer.

Et pourtant, on ne compte plus le nombre de Projets TI qui démarre dans une direction et qui bifurque à mi-parcours pour ensuite revenir à l’essentiel… avec des résultats mitigés.

La faute à qui ?  La faute aux DDC (Demandes De Changement).

INDICE : les DDC (Demandes De Changement) sont le pire ennemi d’un Projet TI et la principale cause de dérive d’un Projet TI à cause d’un mauvais suivi des DDC et de la mauvaise attribution du niveau de priorité de certaines DDC.

Exemple : une DDC qui entraîne un changement de scope dans un Sprint !!!

Il est donc primordial de créer les demandes de changement.  De plus, le lien suivant énumère 5 étapes pour faire de meilleures demandes de changement.

 

Ce qui nous amène à l’importance de la définition des Rôles prioritaires : Gestionnaire de Projet & Product Owner (Business Analyst)

Le Gestionnaire de Projets travaillera main dans la main avec le Product Owner et ce travail débutera dès la définition du Projet.

Incidemment donc, cette étroite collaboration se poursuivra au fil du projet et surtout, lors de l’émergence de DDC, car il en va de la responsabilité du Gestionnaire de Projets d’établir clairement les canaux de communication et de dicter les protocoles de gestion des DDC.

Le bon Gestionnaire de Projets aura développé avec le temps un sens de l’anticipation de l’impact des DDC. Il sera aussi capable d’anticiper la performance de ses développeurs et les délais de livraison en regard des DDC.

C’est le genre de faculté que l’on acquiert avec l’expérience mais qui peut aussi nous venir plus facilement avec de bons outils…

 

Métriques & Outils

La réussite d’un Projet de Développement TI s’appuiera sur une bonne méthodologie, une définition claire du scope du Projet, un Gestionnaire de Projets expérimenté et de bons outils (DevOps / Jira) dans un environnement adéquat de développement.

À cela, il faudrait ajouter un Tableau de Bord bien sûr et peut-être aussi un autre outil qui en s’intégrant à DevOps / Jira permettrait au Gestionnaire de non seulement suivre le Reste-À-Faire pour chacune des tâches de son Projet mais aussi de connaître en temps réel, le nombre d’heures réellement exécutées. Ainsi, le Gestionnaire sera en mesure de comparer le Travail exécuté avec le Reste-à-Faire.

Le Gestionnaire de Projets, à l’aide cet outil, serait en mesure de suivre ses Projets en temps réel et de mesurer la Performance réelle de ses Développeurs, de son équipe de Développement.

Finalement, les normes ISO 9001 – ISO 9126 sont sans contredit les nouveaux standards de Contrôle Qualité auquel toute entreprise doit se conformer en matière de TI, comme partout ailleurs.

 

Conclusion

Dans l’ensemble des facteurs critiques à la bonne réussite d’un Projet TI, il nous apparaît que le facteur le plus fondamental est le degré de collaboration entre le Gestionnaire de Projets, le « Product Owner » et l’ensemble des parties impliquées dans un projet car comme disait l’autre : « Business Relationship Always Comes Down to Human Relationship. »

Laisser un commentaire

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