Comment répondez-vous: «Depuis la mise à jour…» aux questions des clients? [fermé]

Depuis la mise à jour, les gens continuent d'appeler et de dire "Depuis la mise à jour, X, Y et Z sont lents, mauvais et plantent"

Cela s'est produit depuis l'aube des mises à jour.

Qu'attendent les gens? Gamma vient après la bêta, et les tests gamma transforment toujours nos utilisateurs en The Incredible Hulks ...

Peut-être que vous n'avez jamais entendu cela d'un client, peut-être que vous êtes à l'université ou un développeur FLOSS qui peut répandre le blâme autour de plus de 5 ou 6 gars, peut-être que vous testez votre code, peut-être que vous n'êtes pas dans cette situation intéressante où les clients vous appellent pour demander l'heure exacte de la journée, vous publierez le patch d'aujourd'hui (j'adorerais le faire à Microsoft) ou peut-être que vous êtes un fils de biscuit comme moi qui vient d'expédier un nouveau mise à jour et rentra chez lui et redoute de retourner au travail demain.

Quoi qu'il en soit, vous serez plus intelligent que moi de toute façon. Comment répondez-vous aux critiques formulées dans "Vous devez être un mauvais programmeur parce que vous aggravez votre logiciel"?

Si cela vous arrive à chaque fois que vous déployez, il peut y avoir une grave faille dans votre processus de développement. Je soupçonne deux ou trois choses qui causent les problèmes.

1. Développez-vous avec une base de données de la même taille (à peu près) que la production? Si ce n'est pas le cas, vous aurez toujours ces problèmes, car les requêtes qui conviennent à de petits ensembles de données sont souvent des chiens avec de grands.
2. Chargez-vous le test en QA? Ce qui fonctionne bien avec un test utilisateur est très différent de la façon dont les choses vont réagir avec 1000 utilisateurs essayant de faire les choses en même temps.
3. Supposez-vous que la perception de l'utilisateur est fausse et traitez-le comme s'il était stupide de se plaindre? Si tel est le cas, alors votre attitude est à l'origine de plus de plaintes, pas de les diminuer.
4. Faites-vous un bon travail de test? Les fonctionnalités des tests de régression n'ont-elles pas changé pour voir si elles sont affectées par le changement? Vous souciez-vous même du temps que les choses prennent avant qu'elles ne frappent la prod?
5. Faites-vous attention au moment opportun pour les utilisateurs lorsque vous déployez ou déployez-vous gaiement un changement dans le système comptable le jour de la paie et vous demandez-vous pourquoi les utilisateurs sont en colère contre le ralentissement?
6. Avez-vous des différences environnementales entre dev et prod. Parfois, ces différences embêtantes dans les systèmes d'exploitation ou les versions de base de données peuvent également causer des problèmes comme celui-ci. C'est souvent une bonne idée d'avoir un environnement de mise en scène qui ressemble exactement à prod, certains équipements, le même système d'exploitation, la même base de données avec des données aussi proches que possible des données de prod. Ceci est utilisé pour tester votre déploiement. Exécutez-le d'abord sur ce serveur et demandez à certains utilisateurs ou testeurs d'y accéder et d'exécuter certains tests.
7. Quelle est la qualité de votre processus de déploiement, vous manquez souvent des étapes? Peut-il être exécuté par une personne autre que le développeur car il est clair quel code va dans la branche que vous déployez? Nous avons beaucoup mieux déployé le code lorsque nous avons obtenu une équipe de gestion de la configuration et que personne n'avait le droit de s'asseoir avec prod et de faire du babysitting pour apporter des modifications "oopsie". L'automatisation de votre build peut être extrêmement utile. Personne ne devrait deviner ce qui doit aller à la production car il aurait dû aller à l'AQ et à la mise en scène en premier et tous les problèmes d'épuisement ont été résolus. Les modifications de la base de données de script sont également essentielles. Ils doivent être dans des scripts et dans le contrôle de source, donc le processus de construction peut les récupérer sans que personne n'ait à se rappeler, oh oui, nous devons changer la longueur de la colonne B à 241 de 50.

Comment répondez-vous aux critiques formulées dans "Vous devez être un mauvais programmeur parce que vous aggravez votre logiciel"?

Mais une telle critique est surtout justifiée. Une nouvelle version ne devrait pas être pire que la précédente, mais comme nous le savons, en réalité c'est souvent le cas, et c'est de notre faute parce que nous l'avons faite.

Faire des erreurs est humain, et cela ne fait de personne un "mauvais programmeur", alors ne prenez pas personnellement la critique (je ne prendrais jamais au sérieux aucune critique professionnelle d'un non-collègue). Remerciez simplement le client d'avoir signalé le problème et corrigez-le dès que possible. C'est votre travail de bon programmeur.

Eh bien, au travail, nous n'interagissons pas beaucoup directement avec les clients, donc je vais devoir répondre à celui-ci à partir d'un travail de projet personnel. J'écris un moteur de jeu que les gens peuvent utiliser pour créer leurs propres jeux. C'est toujours en pré-alpha, mais j'ai quelques utilisateurs intéressés, et parfois je reçois des bugs.

Lorsque je reçois un rapport comme celui-ci d'un utilisateur, j'essaie d'utiliser la touche personnelle. Je ne voulais pas introduire de bogues, et je veux qu'ils aient une bonne expérience avec mon moteur, donc je dois leur faire croire cela. Tout d'abord, procurez-vous une poignée de messagerie instantanée afin que nous puissions parler. Je vais interroger l'utilisateur sur son projet et essayer d'en obtenir une copie. Cela rend la reproduction beaucoup plus facile. Demandez-leur ce qu'ils faisaient lorsque le problème est survenu. Pendant ce temps, j'ai le moteur ouvert dans le débogueur et j'aborde la question pendant que nous parlons.

Si c'est une exception, c'est généralement assez simple. Reproduisez le problème et le débogueur le saisit et vous emmène directement à l'emplacement de l'erreur avec une trace de pile complète, et c'est évident ce qui se passe. S'il s'agit de performances lentes ou d'un comportement incorrect, cela peut prendre un peu plus de temps. Mais dans la plupart des cas, je peux avoir un correctif prêt dans les 20 premières minutes, en haut. Je le zippe et je le leur envoie pour le tester. "D'accord, je pense que je l'ai. Voyez si cela fonctionne de votre côté?"

La réponse est presque universellement un mélange d'étonnement et de gratitude, car la plupart des développeurs (lire: éditeurs de logiciels) ne corrigent tout simplement pas les bogues et ne les relancent pas si vite. Et puis, si c'est effectivement corrigé, j'ai transformé un critique potentiel en fan. C'est une très bonne technique; Je souhaite juste que plus de développeurs l'adoptent.

Personnellement, je prends le problème positivement. J'interagis tout le temps avec beaucoup de clients, et je code toujours aussi.

Quand ils téléchargent une nouvelle version et me disent quelque chose comme ça, je dis toujours quelque chose comme ça:

Merci de m'avoir signalé ce bug. Peut-être qu'il a été introduit ensemble avec toutes les nouvelles fonctionnalités que nous avons ajoutées. Nous allons le réparer dès que possible.

En fait, le client est votre vrai patron. Si l'expérience avec vous est mauvaise, elle l'est aussi pour vous.

Même s'il n'a pas raison, vous en tant que membre de l'entreprise, vous devriez saisir cette occasion pour:

• apprendre de lui, en collectant les améliorations potentielles que vous pourriez apporter au produit.
• convertir un client mécontent en un client heureux, tellement heureux qu'il parlera de vous (y compris de votre patron)
• soyez fier de ce que vous faites

Détails, détails, détails. Je demande ce qu'ils faisaient et quand, soyez précis. Ce pourrait être quelque chose ou ce pourrait être simplement que la vidéo de Justin Beaber vient de sortir sur YouTube. Les fichiers journaux sont votre ami dans les deux cas.

Je demande aussi des dates quand ils l'ont remarqué. Parfois, en particulier dans les magasins d'entreprise, les utilisateurs ne savent pas quand une version sort, ils savent juste que quelque chose prend beaucoup de temps et ils s'en plaignent maintenant.

Job Shadow. Je ne saurais trop insister sur ce point. Si vous avez la chance d'avoir des utilisateurs à proximité, regardez-les travailler de temps en temps. Je trouve souvent qu'ils ignorent les problèmes flagrants et ne les signalent jamais. Souvent, ils ne se plaindront que lorsqu'ils savent que quelque chose est nouveau ou qu'ils remarquent initialement un problème.

L'étape 1 est que vous devez provenir d'un état d'esprit que cela (la mise à jour casse d'autres choses) n'est pas normal. Votre mise à jour ne doit pas interrompre ni ralentir d'autres parties de l'application. Ce n'est pas bien, ce n'est pas normal et ce n'est pas la faute de l'utilisateur quand il s'en plaint. Vous devriez faire autant de tests que possible pour essayer de l'empêcher. Lorsque cela se produit, vous avez un problème urgent.

L'étape 2 est que vous devez savoir ce que vous avez fait. Votre système de contrôle des sources peut peut-être vous aider, ou une sorte de système de suivi du travail, mais vous devez être en mesure de dire la minute où vous recevez l'une de ces plaintes "ok, j'ai ajouté une colonne à ce tableau, modifié cette grille pour calculer les nouvelles taxes, a ajouté ces deux nouveaux rapports ... "et ainsi de suite.

L'étape 3 est que vous devez avoir de l'expérience pour trouver rapidement des problèmes de performance et des plantages, afin de savoir quelles sortes de choses sont susceptibles de les causer et que vous pouvez résoudre le problème immédiatement. Cette chose a été mise en ligne et vous devez trouver le problème rapidement et obtenir un patch. La modification d'un rapport ne peut pas ralentir une partie de l'application qui n'utilise pas le rapport. Vous êtes maintenant en mode d'urgence et devez déterminer où est l'erreur et que faire à ce sujet - sans interrompre une autre partie de l'application dans le processus.

L'étape 4 est pour chacune de ces misères, vous devriez apprendre une leçon que vous testerez pour la prochaine fois. Vous deviendrez "ce type" qui s'oppose à certaines constructions parce que "ce sera horrible quand il y aura 10 000 enregistrements".

Un peu plus sur le front "c'est normal". Je gère (parmi toutes les autres choses que nous avons en cours) un projet agile pour un client externe. Nous produisons environ toutes les 6 semaines depuis deux ou trois ans maintenant. Et oui, la sortie est prévue à la minute près. Nous en avons fait un à 8h hier. Et à peu près à chaque 4e ou 5e version (une ou deux fois par an, en d'autres termes), quelque chose se casse en direct, et nous passons à l'action et faisons les choses le plus rapidement possible. Même si nous testons et testons et testons avant la sortie. Ensuite, nous leur disons ce qui s'est passé. "Il y avait un petit bogue dans le déploiement de juin qui laissait ce champ vide, mais nous ne l'avons jamais remarqué parce que nous n'utilisions pas la valeur à ce moment-là. Ensuite, dans ce déploiement lorsque nous avons commencé à utiliser le champ, ceux qui étaient vides ont causé ce message d'erreur que vous avez vu. Nous J'ai corrigé le bogue afin qu'il ne puisse pas être vide, mis des valeurs dans les mauvais enregistrements et confirmé qu'il ne faisait plus exploser. Nos excuses. "Ou" Ce changement d'urgence que vous aviez demandé, deux jours seulement avant la libération, a eu des conséquences auxquelles nous n'avons pas pensé et que nous n'avons pas testés. Rappelez-vous pourquoi nous résistons aux changements d'urgence? "Je ne suis peut-être pas un mauvais programmeur pour avoir aggravé la situation avec la mise à jour, mais j'ai sûrement fait une mauvaise chose. Et je dois faire les choses correctement. Je ne suis peut-être pas un mauvais programmeur pour avoir aggravé la situation avec la mise à jour, mais j'ai sûrement fait une mauvaise chose. Et je dois faire les choses correctement. Je ne suis peut-être pas un mauvais programmeur pour avoir aggravé la situation avec la mise à jour, mais j'ai sûrement fait une mauvaise chose. Et je dois faire les choses correctement.

Juste pour couvrir un autre aspect:

Nous gardons une liste de clients qui le réclament alors que ce n'est pas le cas. Bien que nos logiciels soient bogués, souvent très bogués, beaucoup de nos clients vont prétendre "avoir commencé avec la mise à jour" pour attirer l'attention rapidement, ne réalisant pas que cela finit par perdre du temps à tout le monde car nous parcourrons les deltas de la fonctionnalité indiquée à la recherche du problème. Si le client dit la vérité, cela a tendance à être trouvé rapidement. Si le client est trop souvent sur la fausse liste, cela ne nous dérange pas car nous n'aimons pas perdre du temps.

Je ne peux pas imaginer quel état d'esprit est nécessaire pour penser que nous dire un mensonge accélérerait le processus. Ces personnes sont ou travaillent avec des médecins et devraient bien savoir ce qui se passe quand les gens mentent aux médecins. Le même principe s'applique.