L'expérience de Management est plus importante que l'expertise informatique
Branche: Génie mécanique - ascenseurs
Fonction: Chef de projet IT
Thème: Développement logiciel (outil de diagnostic), Scrum
Chiffre d'affaire: > 9 Mrd. CHF
Employés: 54'000
Situation initiale
Dans une grande entreprise, il y avait 2 outils de diagnostic pour les plates-formes de produits respectives afin de soutenir les ingénieurs de terrain les plus qualifiés. Un tel instrument n’existait pas encore pour une nouvelle plate-forme. Les utilisateurs des outils existants en étaient généralement très satisfaits. Cependant, un inconvénient majeur était que chaque fois qu'un produit était changé, l'outil de diagnostic devait également être adapté.
C'est ainsi qu'est née l'idée du projet de développer un nouvel outil de diagnostic basé sur une «approche générique», c'est-à-dire UN outil logiciel pour les 3 plates-formes de produits, basé sur un langage commun des interfaces et indépendant des évolutions du produit. Cette approche générique n'était apparemment plus compatible, du moins pour les ingénieurs de développement, avec une fonctionnalité qui était auparavant utilisée par les ingénieurs de terrain dans la plupart des opérations et qu'ils jugeaient indispensable.
De plus, les équipes de développement des 3 plates-formes avaient des points de vue différents sur les concepts de diagnostic et de maintenance sur le terrain. Mis à part une plateforme, ces concepts n'existaient que dans l'esprit des membres de l'équipe. Le seul concept documenté d'une plate-forme était obsolète et le document n'était plus valide.
Solution:
- Il s'agissait en premier lieu de mettre le projet sur les rail, c'est-à-dire de mener à bien la préparation du projet. Les parties les plus importantes ont été la structuration du projet (structure choisie: chemin-résultat-matrice), le développement de l'organisation du projet (incluant toutes les parties prenantes et le comité de pilotage) et la planification du projet. Lors de la planification, il fallait trouver un équilibre entre la réalisation des objectifs à court terme (environ 8 mois) et le développement à long terme (environ 4 ans) afin d'éviter cela après l'objectif à court terme (soutien pour le lancement d'une nouvelle plate-forme) pour le projet à long terme ne doit pas être recommencé.
- Il fallait veiller à ce que toutes les parties prenantes puissent être «impliquées». Il est rapidement apparu qu'il n'y avait pas de confiance mutuelle entre les utilisateurs et les développeurs de logiciels et que cela devait être établi en «écoutant» et en recherchant activement de nouvelles solutions. Un certain manque d'orientation client dans l'équipe de développement ne pouvait être négligé.
- Il est rapidement devenu clair qu'il y avait un conflit d'objectifs classique. Cela a été traité avec un cycle de résolution de problèmes. L'approche clé consistait à définir le problème clairement et sans ambiguïté. Les variantes de solution ont ensuite été évaluées et une stratégie a été définie à partir de la «meilleure» variante. Pour vérifier cela, cette stratégie a été soumise à un test de résistance (et si, basé sur des «cas» spécifiques de l'activité quotidienne).
- Avec des analyses constantes et en posant des questions stupides de ma part en tant que "non-informaticien" (avec pour conséquence que je devais parfois prendre des commentaires défavorables), les ingénieurs de développement ont néanmoins trouvé une solution qui servait de "stratégie de sortie d'urgence" afin de calmer la situation et convaincre, en particulier les parties prenantes fortement inquiètes, de la solution globale.
- Un autre moyen de convaincre les parties prenantes était la définition claire de l'approche générique, qui allait également au-delà du projet proprement dit, avec des solutions possibles pour un concept global de diagnostic et de maintenance. Ce faisant, je devais parfois utiliser «l'axe de puissance» de l'organisation.
- L'ingénierie des exigences était une tâche majeure, et j'ai choisi une «approche GAP» pour cela. Sur la base de l'outil de diagnostic utilisé jusqu'à présent, les GAP's, les différences entre les nouveaux et les exigences existantes ont été décrites. Cela a permis de les définir très rapidement et sous une forme bien comprise par les parties prenantes. Cela a été suivi par une sorte de «traduction» dans la langue des développeurs de logiciels avec la définition de cas d'utilisation.
- Avec le développement et la présentation d'un projet de GUI (Graphical User Interface), et ceci en plusieurs phases, les ingénieurs terrain (principaux utilisateurs) ont pu très bien être intégrés.
- Le processus de planification du développement du logiciel a été mis en œuvre avec un nouvel instrument logiciel basé sur l'approche SCRUM.
- Un concept de marketing de projet a complété les approches de solution. Le projet devait être soutenu de manière optimale avec la définition d'approches générales, mais surtout la mise en œuvre d'actions spécifiques.
Résultat:
- Élaboration réussie (cycle de résolution de problèmes) et mise en œuvre (implication des parties prenantes) d'une stratégie pour surmonter un conflit d'objectifs déterminant pour la réussite du projet
- Résoudre le conflit entre l'objectif intermédiaire à court terme (février 2015) et le paquet global à long terme (2018)
- Création des conditions d'un démarrage réussi du développement logiciel
- Pontage réussite des barrières entre le «langage» des utilisateurs (parties prenantes) et le «langage» des ingénieurs de développement. Sensibilisation des développeurs aux préoccupations des utilisateurs.
