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.