Il semble que le PO soit “pris au milieu” : un “subordonné” s'est plaint aux responsables de l'entreprise qu'un chef d'équipe/directeur de projet le remettait en question. Pour diverses raisons, cela ressemble à une équipe de logiciels. Bien que cela ne soit pas strictement pertinent, le problème est peut-être que la personne qui occupe un poste d’“ingénieur” est censée gérer son temps comme le ferait un employé d'un magasin de détail - elle entre à 8 heures et sort à 17 heures. On dirait qu'il y a d'autres problèmes ici aussi, mais ils ne sont pas détaillés.
La question, telle qu'elle est affichée, est “Que dois-je dire à la direction générale ? Cela suggère que la première préoccupation du PO est la façon dont il est perçu par ses propres managers. Du point de vue du cadre supérieur, deux ego se livrent un combat de chat - l'un rédigeant le code et l'autre gérant un projet. Cela implique une certaine distance sociale entre le "développeur” et le “superviseur”. Le superviseur semble essayer de dire à son subordonné : “vous avez été engagé pour faire ce qu'on vous dit de faire - ne remettez pas en cause l'autorité”. Bien que le lieu réel ne soit pas évident d'après le contenu, cela ressemble à un magasin quelque part en Asie.
Ce que la direction veut entendre, c'est que les deux belligérants ont trouvé un moyen de faire leur travail avec un minimum de frictions. La question de savoir s'il va apporter tous les points négatifs de son supérieur ou non serait un mauvais choix - vraiment mauvais. Tout ce que les seniors constatent à ce stade, c'est que deux employés se disputent plutôt que de faire leur travail.
Donc, au risque de “ne pas répondre à la question”, je propose que :
Le PO détermine les paramètres applicables pour mesurer la performance du développeur. Il est peu probable qu'il s'agisse d'un pointage d'entrée et de sortie. Il s'agira probablement de la production de produits livrables - code, documentation, correctifs et assistance aux utilisateurs dans des délais raisonnables. Cela pourrait s'appliquer aussi facilement à d'autres formes d'ingénierie - conception de puces, projet architectural ou pont. Toutes ces formes comportent des mélanges complexes de “conception de base”, de documentation, de révisions et de réponses aux commentaires des consommateurs.
Une fois que vous aurez déterminé les paramètres, appliquez-les au développeur/ingénieur. Écrit-il le code, corrige-t-il les problèmes et assiste-t-il les utilisateurs de manière satisfaisante ? Si oui, arrêtez de le provoquer avec des choses qui le dérangent manifestement. Voyez s'il est possible d'identifier les problèmes de temps qui ne sont pas visibles pendant les heures de travail, tels que les appels téléphoniques tard dans la nuit, le travail le week-end ou toute autre activité qui perturbe la semaine normale de 40 heures.
L'introspection a une certaine valeur. Le PO s'engage-t-il dans un jeu de pouvoir juste pour établir ou maintenir son “rang” ? Les ingénieurs se disputent sans cesse avec leurs “supérieurs hiérarchiques” à propos de la tenue vestimentaire, des pauses, de la langue, des horaires de travail et des protocoles de contact avec les utilisateurs ou les clients. Les ingénieurs considèrent le comportement des cadres comme obstructionniste, plus soucieux des apparences et des conditions préalables que de l'accomplissement des tâches. Le PO pourrait profiter de cette occasion pour déterminer si les habitudes acquises dans un autre type d'organisation (ou de structure familiale) sont ici contre-productives.
Après avoir fait ces choses, il est temps de s'asseoir avec le développeur - idéalement en dehors du bureau - disons au déjeuner. Encouragez et permettez au développeur de parler de la façon dont il passe son temps jour après jour - les morceaux disponibles pour le codage/la conception, les interruptions des superviseurs, les interruptions des utilisateurs, les problèmes qui le tiennent occupé en dehors des heures de travail, les changements de spécifications “à l'improviste”, etc. Ne soyez pas surpris si la conversation s'éloigne - si c'est le cas, remettez-lui doucement le couvert.
A partir de là, essayez de comprendre quels sont les événements particuliers qui pourraient déclencher le retard ou la longue pause de quelqu'un - parmi les choses qui déclenchent le premier (d'après mon expérience personnelle), il n'a qu'une vague idée de ce qu'il doit faire ensuite. Il m'arrivait souvent de rester assis dans mon fauteuil roulant à la maison pendant deux ou trois heures, en pensant simplement à la façon de structurer quelque chose, puis, lorsque la réponse arrivait, je me précipitais au travail et je le faisais. J'ai eu beaucoup de superviseurs qui se sont plaints de mon heure d'arrivée - aucun de la qualité de ce que j'ai fait.
Si l'ingénieur est souvent interrompu, le travail des OP consiste à trouver comment les intercepter pour qu'il y en ait moins. Cela signifie, en particulier, ne pas en créer arbitrairement d'autres. D'où viennent les interruptions, et peut-on les diminuer ? C'est souvent ce que les superviseurs sont censés faire - garder les ponts dégagés pour que les programmeurs/concepteurs/ingénieurs puissent se concentrer sur la sortie de leurs affaires.
Si le développeur n'est pas vraiment capable d'expliquer où son temps passe, alors il peut y avoir un problème de compétence. Là encore, il s'agit de se concentrer sur le résultat, et non sur la pointeuse. Les délais sont-ils dépassés parce que rien n'est fait ou parce que quelqu'un d'autre change constamment d'avis ? Si le programmeur doit sans cesse recommencer à zéro, rien ne sera fait. Si c'est le cas, pourquoi cela se produit-il ? Les superviseurs sont censés verrouiller les exigences afin que l'équipe puisse travailler sur un objectif fixe.
Si toutes ces choses devaient arriver, le pourrait signaler à la direction générale que la productivité s'améliore et que les utilisateurs disposent de l'infrastructure informatique dont ils ont besoin.