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

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.

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.)

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.

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.

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.

Ê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.