Comment gérer cette situation malheureusement non hypothétique avec les utilisateurs finaux?


22

Je travaille dans une entreprise de taille moyenne mais avec une très petite force informatique.

L'année dernière (2011), j'ai écrit une application qui est très populaire auprès d'un grand groupe d'utilisateurs finaux. Nous avons atteint une date limite à la fin de l'année dernière et certaines fonctionnalités (j'appellerai funcA à partir de maintenant) n'ont pas été ajoutées à l'application souhaitée à la toute fin. Donc, cette application fonctionne en live / production depuis fin 2011, je pourrais ajouter sans problème.

Hier, tout un groupe d'utilisateurs finaux a commencé à se plaindre que funcA qui n'était jamais dans l'application ne fonctionne plus. Notre priorité dans cette entreprise est que si une application est cassée, elle doit être corrigée avant les projets prioritaires.

J'ai comparé le code et les requêtes et il n'y a pas de différence depuis 2011, ce qui est proofA. J'ai ensuite pu convaincre l'un des utilisateurs finaux d'admettre que cela n'avait jamais fonctionné proofB, mais depuis lors, cet utilisateur final est revenu et a dit qu'il fonctionnait auparavant ... Je crois que la horde d'utilisateurs finaux a assimilé sa. J'ai également revu mes notes pour ce projet qui a des exigences et des mises à jour quotidiennes concernant le projet qui stipule spécifiquement, "funcA non atteint en raison de contraintes de temps", proofC.

J'ai parlé avec beaucoup d'entre eux et je peux voir où ils pourraient être confondus car ils sont très éloignés de la programmation, mais je sais aussi qu'ils sont assez intelligents pour agir en groupe afin de contourner les ordres de priorisation des projets afin d'obtenir fonctionnalités qu'ils veulent rendre leur travail plus facile.

Le pire, c'est que maintenant la réflexion de groupe s'installe et mon patron et le responsable informatique commencent à les croire, même s'il n'y a pas de changement de code ou de requête. En ce qui concerne l'examen de l'état de la logique, il est très coupé et sec au point que si 1 = 1, funcA ne fonctionnera pas.

Donc, c'est la fin de la description de mon scénario, mais j'essaie de ne pas me laisser gravement influencer par mes mesures de performance à cause de cela, ce qui m'aurait essentiellement amené à résoudre un problème de production qui n'existe pas et qui prendra probablement le relais 1 mois.


1
Nous ne sommes pas un forum au sens traditionnel du terme, nous sommes un site de questions / réponses qui recherche des questions fiables. Les déclamations, les sondages et les discussions ne correspondent généralement pas à notre format.
maple_shaft

12
@maple_shaft: Je ne suis pas d'accord. Il s'agit d'une question sérieuse à la recherche d'un moyen de résoudre un problème réel qui se produit lorsque nous traitons, dirons-nous, avec des utilisateurs finaux peu convaincants. Nous l'avons tous vu et frustré, n'est-ce pas? Les idées sur la façon de gérer de tels scénarios conviennent donc parfaitement au format de ce site.
Mason Wheeler

1
N'est-il pas possible qu'il puisse y avoir une réponse à cette question? Qui surveillera les observateurs?
Utilisateur Smith

2
Pour que les autres lisent ceci, ce cas représente une autre leçon pour ceux d'entre nous qui croient que la documentation est secondaire et que les exigences de chant ne sont pas importantes.
NoChance

1
"rien n'a changé" fameux derniers mots.
JeffO

Réponses:


18

Les différends concernant des faits facilement observables sont en fait assez faciles à résoudre: observez simplement les faits. Si je dis "il y a un arbre avec du bois violet à l'extérieur de ma maison", toute personne capable de venir chez moi peut vérifier la vérité ou le mensonge de ma déclaration par elle-même.

S'ils se plaignent que FuncA était dans le produit et fonctionnait dans une version antérieure et maintenant que cela ne fonctionne pas, et que vous ne pensez pas qu'il ait jamais été dans le produit, demandez-leur de le prouver. (Ou, en termes plus doux, dites quelque chose comme "nous avons du mal à reproduire le problème. Pourriez-vous nous aider ici?")

Donnez-leur une copie de la version antérieure s'ils n'en ont pas encore, faites-les participer à un LiveMeeting et demandez-leur de vous montrer comment ils utilisaient FuncA. S'ils ne peuvent pas le faire, alors (espérons-le), ils se rendent compte que ce n'était pas là après tout et retirez votre cas à ce sujet, ou essayez au moins une tactique différente pour le mettre en œuvre. (Et assurez-vous que quelqu'un de la direction ou du PM participe au LiveMeeting.)


Ils ont montré une capture d'écran de la preuve que je peux expliquer, mais ce n'est qu'une partie, donc les détails du scénario sont ce qu'ils disent qu'ils ne sont pas vraiment définis via la capture d'écran. Fondamentalement, ce qui revient à dire que MGMT n'est pas très conscient de la logique et à ce stade, c'est la parole d'un département entier contre un programmeur modeste. (La version précédente est également la même que le déploiement initial qui a eu lieu en 2011)
Utilisateur Smith

3
@UserSmith: C'est pourquoi j'ai dit d'utiliser un LiveMeeting. Il est plus difficile de se tromper sur ce qui se passe lorsque vous devez réellement le faire avec des gens qui regardent.
Mason Wheeler

1
Cette réponse fournit une bien meilleure définition de la preuve que "l'utilisateur final le dit" ou "j'ai lu le code". Arrêtez-vous et souvenez-vous des 10 dernières fois qu'en tant que programmeur, vous étiez complètement sidéré, vous pourriez vous tromper malgré le fait de regarder 1 = 1 dans le code (alors qu'il aurait vraiment dû être 1 == 1, par exemple). Si vous pensez à la preuve en termes de "lecture de code" en tant qu'humain sujet aux erreurs, alors franchement, vos mesures de performances devraient en prendre un coup. @MasonWheeler vous a proposé une épistémologie plus précise et plus séduisante, il vous appartiendrait de la suivre.
djechlin

Dans les négociations, il y a un dicton "Si vous devez vous défendre, vous avez déjà perdu". La preuve des faits est la forme ultime de défense - en règle générale, il vaut mieux ne pas le faire sauf si on vous le demande, même dans ce cas, garder si bref - moins c'est plus.
mattnz

1
Marqué comme réponse probablement la réponse la plus concrète. Même si j'avais déjà fait des réunions en direct avant de poster cette question. De plus, on en avait quelques autres qui étaient en partie de bonnes réponses. Honnêtement, à ce stade, je ne me soucie pas de mes mesures, c'est plus le fait que la structure fondamentale de notre organisation informatique est en si mauvais état que cela se produit même qui m'inquiète.
Utilisateur Smith

13

Ce n'est pas une question qui peut être traitée sur des faits - si vous essayez, vous perdrez votre crédibilité.

Tout d'abord, acceptez que le logiciel soit "cassé" - car il ne fait pas ce que les utilisateurs veulent qu'il fasse. Maintenant, acceptez que les utilisateurs ont le droit de faire faire au logiciel ce qu'ils veulent, c'est donc le logiciel. Nous avons donc un logiciel défectueux et un ingénieur refusant de le réparer .....

Par conséquent, si le système que vous exécutez pour définir des priorités, ces utilisateurs ne peuvent pas réparer leur logiciel en passant par les canaux normaux, ils utilisent donc des canaux latéraux et escaladent des demi-vérités plus haut dans la chaîne alimentaire pour essayer de manœuvrer le système, dans en attendant, ce qui rend votre KPI mauvais (votre principale préoccupation devrait être les clients, pas vos KPI) - Vos KPI sont considérés comme des «dommages collatéraux» s'ils vous aiment, ou comme un effet secondaire bénéfique s'ils ne le font pas. Cependant, ils ont un certain contrôle sur ce qui se passe - mieux ils vous aiment.

Donc, ce qui se passe, c'est que le système est en panne, et tout le monde essaie de manipuler les choses pour obtenir ce qu'elles veulent. Ils veulent une fonctionnalité, et vous voulez garder vos KPI impeccables.

À moins que vous ne puissiez réparer le système ou apprendre à jouer à la politique de bureau très rapidement, la partie se termine: vous perdez.

Remarque: aucune de ces discussions ne concerne les délais, les discussions sur les bogues et les fonctionnalités, qui paie, etc. Ce sont des faits - et les faits n'ont pas d'importance (enfin, ils le font en quelque sorte, mais ils peuvent être manipulés de nombreuses manières ... ) dans la politique du bureau.


1
Comment pouvez-vous perdre la crédibilité si vous pouvez le prouver ?
Thomas Eding

3
@ThomasEding La crédibilité dans le monde des affaires dépend davantage de la façon dont les autres vous perçoivent que des faits. Si vous devenez une cible, aucune quantité de faits ne vous protégera. Combien de développeurs rock-star avez-vous rencontrés qui étaient des fraudes complètes? J'en ai rencontré plus que je ne voudrais l'admettre.
maple_shaft

2
Je suis d'accord avec une bonne partie de cela, c'est certainement une forme de politique de bureau. Lorsque je suis confronté à n'importe quelle situation, je pense que la première mesure à prendre serait de traiter les faits, alors vous m'avez un peu perdu là-bas, mais je suis d'accord avec les clients qui viennent en premier kpis en second lieu jusqu'à ce que vous soyez bien sûr viré. +1 pour une vision différente de la situation. +1
Utilisateur Smith

2
Ne jamais se plaindre, ne jamais se justifier. Se disputer vous fait paraître faible. Il est bon d'écouter les demandes polies. Dire que vous discuterez de leur demande avec votre patron pour la priorité est une bonne chose. Si vous vous disputez, faites ce sur quoi ils ont crié, cela renforce leur comportement désagréable. S'ils s'intensifient, le pouvoir de position de votre patron impose la politesse. Votre patron peut expliquer diplomatiquement son choix pour votre temps. Cela montre également qu'ils ne sont pas votre patron. Lorsque vous abordez le problème tranquillement avec votre patron, vous pouvez entendre des mots comme «ne vous inquiétez pas, je vous ai aidé». Restez concentré, fabriquez des produits, les coups de gueule s'arrêteront.
DeveloperDon

@thomas Demandez à tout accusé innocent s'il s'agit d'un crime immoral particulier ....
mattnz

9

Sur le plan organisationnel, je sens un problème.

Il existe une hiérarchie qui comprend le responsable informatique et votre patron. Si votre organisation est traditionnelle (cela ne ressemble pas à Agile), vous êtes une ressource et ce sont des gestionnaires de ressources. Vous avez un travail à temps plein appelé développement de logiciels. Si les utilisateurs finaux demandent directement des fonctionnalités, définissent vos priorités et tentent de gérer votre temps, vos gestionnaires sont redondants. Ils peuvent être responsables devant les utilisateurs finaux, mais s'ils font leur travail, vous êtes responsable envers eux et ils doivent vous empêcher de passer du mode développeur ciblé au mode développeur défensif .

Quelques points pour situer le contexte de ma réponse:

  • Les développeurs de logiciels ne sont pas des voyageurs temporels, donc les résultats doivent être jugés pour ce qu'ils sont, pas pour ce qu'ils auraient pu être.
  • Si une fonctionnalité était dans une spécification d'exigences, un calendrier et a été priorisée au-dessus du travail terminé, il peut y avoir une plainte légitime. Sinon, quelle est la justification pour vous tenir responsable?
  • Votre punition, si elle est méritée, doit provenir de votre chaîne de commandement. Tout comme le marketing et les ventes ne souhaiteraient pas que le développement de produits gronde les clients, la plupart des organisations ont des chefs de produit pour recevoir la colère (et les éloges) des clients et la transmettre via des canaux.
  • Les chefs de produit peuvent créer des relations extrêmement difficiles s'ils se prélassent dans la chaleur des parties réussies des projets, mais ne font que céder le fouet lorsqu'ils font face aux développeurs.
  • Si vous avez livré un produit fonctionnel avec une année de travail et qu'il faut un mois (ou deux) pour ajouter la fonctionnalité souhaitée, d'après ce que j'ai vu dans notre industrie, votre estimation était supérieure à la moyenne.
  • Pour résoudre le problème de manière équitable et productive, les gens doivent remettre les doigts de la faute dans leurs poches et faire un plan pour aller de l'avant.

Vous serez en mesure de faire un travail de bien meilleure qualité avec une meilleure motivation si vous êtes apprécié au lieu d'être la chèvre dans un processus que le responsable informatique devrait posséder. C'est la voie juste et la voie productive. J'espère que vous serez géré de cette façon, et dans le futur, j'espère que vous gérerez les autres de cette façon.


DevDon, j'aimerais que ce soit dans la réponse n ° 1 car je pense que c'est une grande partie de notre problème .... notre structure informatique pour ce scénario est extrêmement aléatoire. +1
Utilisateur Smith

1

En cas d'échec de la réalité comme celui-ci, le mieux est d'avancer. Au lieu de discuter du passé, parlez de le faire fonctionner et de la facilité ou de la difficulté. Peu importe que le problème soit résolu ou implémenté pour la première fois. Si la direction veut que A soit fait avant B, faites-le.


Bien sûr, cela est vrai, mais lorsque l'utilisateur final découvrira qu'il peut manipuler le système de cette manière, mon entreprise sera sérieusement orientée vers le bas si cela continue car les ressources seront utilisées de cette manière par rapport à celles utilisées pour la stratégie globale de l'entreprise. directives qui vont vraiment conduire le résultat net des entreprises.
Utilisateur Smith

0

Êtes-vous le seul développeur à avoir travaillé sur ce projet? On dirait que vous avez répondu à quelqu'un pendant le projet. Où est cette personne dans tout ça? Où est la documentation du projet indiquant ce qui a été livré?

Il devrait y avoir une trace documentaire. Un document de formation montrant comment utiliser l'application. Une spécification fonctionnelle décrivant ce qui a été développé. Si une fonctionnalité n'était pas incluse, il devrait également y avoir de la documentation à ce sujet. Quelqu'un aurait dû signer pour dire qu'il accepte cela.

Ce ne devrait pas être votre mot contre le leur, tout devrait être dans la documentation.

Si vous n'avez pas cette documentation ... alors je crains que vous n'ayez à mordre celle-ci. Considérez cela comme une leçon de vie. Au bout du compte, vos utilisateurs sont vos clients, et comme le dit le dicton: le client a toujours raison. Élaborez comment ajouter cette fonctionnalité et combien de temps cela prendra. Avoir une réunion et dire quelque chose dans le sens de «Nos dossiers montrent que cette fonctionnalité n'a jamais été mise en œuvre, mais nous pouvons l'obtenir en x semaines. Faut-il aller la tête?

Et pour l'amour de tout ce qui est saint ... obtenez la documentation dont vous avez besoin pour montrer qu'elle a été approuvée.


Oui, j'étais le seul à avoir travaillé sur ce projet. Il y a de la documentation avec des mises à jour quotidiennes que j'ai appelé proofC dans ma question.
Utilisateur Smith

@UserSmith ~ J'ai compris que cela signifiait davantage une mise à jour quotidienne de l'état. Ce n'est pas vraiment la documentation dont je parlais. Quelqu'un a-t-il signé le produit final? Y a-t-il une formation ou une documentation d'application que vous avez donnée à l'utilisateur final ou à la partie prenante?
Tyanna

Malheureusement non. Il y avait une formation mais une très courte période de formation. Il existe une documentation d'application mais elle ne couvre pas l'absence de cette fonctionnalité. Les mises à jour quotidiennes sont essentiellement un outil de journal que nous utilisons pour décrire les descriptions initiales, quotidiennes et finales de ce qui s'est passé avec un projet.
Utilisateur Smith
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.