Les correctifs sont-ils un mauvais signe pour le client? [fermé]

14

Au bureau, nous venons de sortir d'une longue période où nous sortions des patchs trop fréquemment. Vers la fin de cette période, nous faisions presque trois patchs par semaine en moyenne.

Outre le fait que cela était très démotivant pour les développeurs, je me demandais ce que le client en penserait. J'ai posé la question moi-même et j'ai conclu que je n'avais jamais connu de logiciel mis à jour aussi fréquemment. Cependant, pour le cas qui se rapproche le plus, je m'en fiche vraiment car les patchs sont appliqués assez rapidement.

Les clients qui ont reçu ces correctifs diffèrent beaucoup les uns des autres. Certains attendaient vraiment le correctif alors que d'autres ne s'en souciaient pas vraiment, mais ils ont tous reçu les mêmes correctifs. Le temps de mise à jour du logiciel client est inférieur à 30 secondes, je ne m'attends donc à aucun problème de temps. Ils doivent cependant être déconnectés.

Donc, ma question plus en détail: les mises à jour donnent-elles fréquemment un message «négatif» au récepteur?

Bien sûr, je pourrais demander aux clients, mais je ne suis pas dans cette position et je ne veux pas "Réveiller les chiens endormis".

PS: S'il y a quelque chose que je pourrais faire pour améliorer ma question, veuillez laisser un commentaire.

Mixxiphoid
la source
@downvoter, voulez-vous expliquer?
Mixxiphoid
6
Si vous vous inquiétez de la perception des clients, peut-être les décrire comme des «mises à jour» plutôt que des «correctifs»? :)
Chris Taylor
Bien que ce ne soit pas une réponse directe, si vous pouvez garder le déploiement des correctifs aussi intrusif et automatique que possible (par exemple, télécharger les mises à jour en arrière-plan, exécuter un service de mise à jour à appliquer en mode inactif), vous pouvez atténuer l'anxiété de l'utilisateur final en ne rendant les mises à jour évidentes. Par exemple: combien de mises à jour de Google Chrome avez-vous reçues au cours du mois dernier? (Réponse: beaucoup ) Ils pouvaient sortir 5 patchs pour Chrome par jour, et personne ne levait un sourcil. Les mises à jour automatiques de Windows (lorsqu'elles sont activées) en sont un autre exemple.
Jason C
"Le temps de mise à jour du logiciel client est inférieur à 30 secondes, donc je ne m'attends pas à des problèmes de temps. Ils doivent cependant être déconnectés." Qu'en est-il du client testant lui-même le correctif? Je ne sais pas avec quel type de logiciel vous travaillez, mais s'il est presque essentiel à la mission de quiconque, il voudra tester une mise à jour avant de la mettre en service dans un environnement de production. Bien que l'installation du correctif puisse être rapide et facile, ce test va prendre beaucoup de temps et d'efforts de la part du client.
un CVn
@ MichaelKjörling Le problème est que, pendant cette période, les fonctionnalités critiques de la mission ont échoué, donc peu importait que l'environnement de production ou l'environnement de test soit mis à jour en premier. Il avait juste besoin de fonctionner dès que possible.
Mixxiphoid

Réponses:

24

Comme pour beaucoup de choses en informatique, cela dépend. Si les correctifs sont une réponse aux demandes des clients pour de nouvelles fonctionnalités ou améliorations, votre entreprise sera considérée comme réactive. Si, en revanche, vos correctifs sont une réponse aux rapports de bogues, votre entreprise sera considérée comme incompétente.

entrez la description de l'image ici

Tester un logiciel sur vos clients est de loin le moyen le plus coûteux de détecter les bugs, quoi qu'en dise quelqu'un. C'est une fausse économie; la main-d'œuvre gratuite que vous pensez obtenir est plus que compensée par l'effort du service client, interrompant le cycle de vie du développement logiciel et perdant la confiance des clients.

Robert Harvey
la source
3
Peut-être que cela devrait être une question différente, mais de toute façon: nous savions que nous testions via nos clients mais ne pouvions pas arrêter cela à ce moment-là, nous étions pris au piège dans un cycle. Que pourrions-nous faire pour sortir?
Mixxiphoid
3
Robert, j'ai déjà vu ce diagramme plusieurs fois auparavant. C'était probablement correct lorsque le développement de logiciels suivait un modèle purement en cascade, mais comme les logiciels peuvent être développés et déployés en petits cycles, ils se sont de plus en plus trompés. Pour être précis - pour une petite quantité de bogues et de logiciels, la tendance est toujours vraie, pour beaucoup de bogues, c'est définitivement faux.
Doc Brown
2
@DocBrown: Le graphique est toujours correct. Des cycles de développement plus courts signifient moins de coûts par cycle, ce qui est cohérent avec le graphique. Mais cela ne signifie toujours pas que vous devez tester alpha votre logiciel sur vos clients, à moins qu'il n'y ait une compréhension claire et un accord que cela fait partie du processus.
Robert Harvey
Eh bien, le coût des défauts diminue à mesure que le bogue est détecté et corrigé. Et la probabilité qu'un bogue soit détecté augmente considérablement à mesure que vous sortez votre logiciel. Bien entendu, cela ne signifie pas qu'il faille mettre en production des logiciels non testés. Je recommande, par exemple, cet article agileelements.wordpress.com/2008/04/22/cost-of-software-defects
Doc Brown
1
Tout ce qu'il faut, c'est un peu d'auto-réflexion pour voir que le principe lui-même est solide, même si les chiffres ou la forme de la courbe ne sont que des suppositions sauvages. Nous avons même un nom pour cela dans le langage de programmation: Fail Fast.
Robert Harvey
10

J'ai l'impression que la publication de plusieurs correctifs à proximité reflète mal la société. Cela me donne toujours l'impression qu'ils n'ont pas testé suffisamment à l'avance, que les développeurs sont incompétents ou que la direction n'a aucune idée de ce qu'ils font.

Cela dit, l'autre côté du jeton est que la publication de plusieurs correctifs les uns à côté des autres montre que l'entreprise adopte une approche proactive de son produit et continue d'améliorer son produit pour le consommateur.

Je suis plus enclin à penser que le premier est la façon dont la plupart les verront du point de vue du consommateur, mais parler directement avec eux sera (évidemment) le meilleur choix, mais soulèvera également le problème au sein de la clientèle qu'ils peuvent pas au courant au départ.

Jack
la source
Donc, en fin de compte, devrions-nous essayer de patcher uniquement les clients qui en ont vraiment besoin, et les autres à un moment ultérieur en «vrac» pour améliorer notre image?
Mixxiphoid
5
Corriger pour les clients individuels semble que cela pourrait être un mal de tête, surtout s'il y a une grande clientèle. Déployer des correctifs selon un calendrier régulier (mensuel, bimensuel, etc.) et promouvoir les correctifs auprès des clients pourrait être un bon moyen de susciter l'intérêt pour "ce qui va suivre" de votre produit, ainsi que de résoudre les problèmes qui sont aplanies. Bien sûr, une documentation et une notification appropriées sont essentielles pour communiquer à l'utilisateur final avec des notes de mise à jour.
Jack
Cela clarifie vraiment beaucoup pour moi. Il semble que nous devrions faire un effort pour utiliser nos correctifs afin d'améliorer notre image. Jusqu'à présent, j'étais convaincu que ce n'était pas possible. Toujours considéré les patchs comme un mal nécessaire.
Mixxiphoid
dépend aussi du moment du cycle de libération. Si les correctifs sont proches les uns des autres dans les premiers jours après leur sortie, cela donne une impression différente de celle où ils sont (encore) rapprochés plusieurs mois plus tard.
jwenting
7

De plus en plus d'entreprises suivent les traces de Chrome et proposent des versions clients de plus en plus fréquentes.

La condition préalable à la mise en œuvre de cycles de version courts est une mise à niveau indolore - en chrome, par exemple, la mise à niveau est effectuée sans aucune intervention de l'utilisateur au démarrage de l'application, et si l'utilisateur garde son application toujours active, il reçoit un indicateur mineur lui conseillant de redémarrer l'application à l'heure qui lui convient, puis l'application s'efforce de le ramener à son état antérieur après le redémarrage.

Cette méthode laisse le client satisfait, car il n'a pas besoin d'être au courant de chaque mise à jour, et comme les versions des fonctionnalités sont fréquentes, les versions de correction de bugs seront tout aussi bienvenues.

Si, d'un autre côté, les correctifs surviennent après des bogues flagrants et qu'ils se présentent en grappes, car les précédents n'ont pas réussi à corriger le bogue ou ont créé un bogue plus important - soyez assuré que vos clients le sentiront. Cela reflétera certainement mal la réputation professionnelle du fournisseur et réduira les normes logicielles perçues par le fournisseur. La livraison continue repose en grande partie sur des tests unitaires et des tests d'intégration efficaces pour garantir son succès.

En ce qui concerne le fait de ne pas parler à vos clients de «laisser mentir les chiens endormis», je pense que c'est une mauvaise stratégie - les clients ne sont pas aveugles et ils ne sont pas dupes. Je crois qu'une bonne communication avec vos clients ne peut que les rassurer qu'ils sont votre priorité et que vous êtes réceptif à leurs critiques. Si vous avez livré de mauvaises versions à quelques reprises et que vous ne les entendez pas se plaindre - vous devriez certainement vous inquiéter - ce n'est pas qu'ils ne l'ont pas remarqué, ils sont probablement trop occupés à trouver un remplaçant pour vous ...

Uri Agassi
la source
2
+1, en tant que client régulier de logiciels, je veux que les gars avec des mises à jour fréquentes et de bons moyens de les déployer. Les produits qui stagnent sont le véritable drapeau rouge ici - à tout le moins, cela signifie que le fournisseur n'investit pas dans le produit. Ou investir dans vNEXT pour lequel ils veulent que vous payiez à nouveau.
Wyatt Barnett
Ce que je comprends de votre dernier paragraphe, c'est que nous devons toujours être honnêtes et transparents dans notre communication avec le client. Existe-t-il des situations dans lesquelles nous ne devrions pas (encore) informer le client de certaines choses?
Mixxiphoid
1
Bien sûr, être honnête avec le client ne signifie pas laisser la ligne ouverte lorsque vous organisez une réunion de panique pour atténuer une catastrophe qui vient de se produire. Vous devez communiquer les informations après avoir évalué la situation, avoir une stratégie pour y remédier et pouvoir dire honnêtement que tout est sous contrôle. Vous pouvez vous retrouver à embellir la vérité, mais les mensonges purs et simples ont un moyen de vous hanter plus tard ...
Uri Agassi
2

Les correctifs spécifiquement destinés aux clients qui ont détecté un problème devront évidemment être distribués dès que possible.

J'ai vu des logiciels dans de grandes entreprises adopter l'approche selon laquelle d'autres clients recevraient ces correctifs sous forme de service pack à intervalles réguliers. Normalement, car les correctifs demandent un certain effort pour être installés et testés dans l'environnement client, mais dans votre cas, ils pourraient simplement être utilisés pour réduire l'impact possible de l'effet qui vous préoccupe.

J'ai également vu des gens préconiser la mise en place de correctifs dans des référentiels ou sur des sites Web où les clients peuvent télécharger et installer ceux qu'ils souhaitent. Cela peut créer des problèmes pour savoir quels correctifs les clients ont, donc quand ils appellent avec un problème, vous devez déterminer exactement le code qu'ils exécutent, mais avec soin qui peut être suivi. Vous pouvez ensuite forcer les gens à passer à l'un des plus grands `` packs '' quand l'un est publié qui regroupe de nombreux correctifs.

Les correctifs de sécurité sont l'exception. Une grande société de logiciels basée à Washington est connue pour entrer dans l'eau chaude en attendant le troisième jeudi du mois avant de publier des correctifs de sécurité critiques et des informations sur le piratage ont été divulguées et leur ont forcé la main tôt pour encore plus d'embarras.

Google Chrome contourne le problème en mettant à jour automatiquement très fréquemment, eux aussi vous obligent à faire un cycle du programme (redémarrez Chrome, ou dans votre cas, déconnectez-vous). Ils ont maintenant fait cette pratique normale pour les navigateurs et les gens n'y pensent même plus. Mais tout le monde ne peut pas être Google.

Les applications SaaS contournent tout le problème en effectuant les mises à jour en arrière-plan.

Cependant, surtout, à moins que vous ne fassiez une intégration continue ou une mise à jour avec de nouvelles fonctionnalités demandées par les utilisateurs très fréquemment, je pense que nous sommes encore à une époque où les gens s'attendent à ce que vous ayez fait une quantité décente de tests avant la sortie. Si vous seriez gêné de rencontrer vos clients et de parler de la fréquence des corrections de bogues, vous ne faites probablement pas assez de tests. Avez-vous divulgué le niveau de risque que vous preniez avant de publier le code. Il y a un argument pour publier très tôt un code bogué tant que vous savez que c'est ce que c'est, mais je pense que vous devez avoir une bonne compréhension de votre qualité connue, ce qui signifie comprendre et garder sous contrôle votre temps pour connaître la qualité.

Encaitar
la source
+1, c'est le point clé - plus vite vous pouvez corriger un bogue (et déployer), mieux c'est - tant que l'utilisateur / client n'a pas d'effort supplémentaire à déployer. Lorsque le client doit se déployer manuellement, ou que les mises à jour interrompent simplement son flux de travail, il est important de trouver la bonne fréquence pour les déploiements. Des sites comme Facebook déploieront plusieurs correctifs par jour et la plupart des gens ne le remarqueront même pas.
Doc Brown
donc je suppose que nous avons de la chance sur cette partie. Nos mises à jour nous ont coûté (à part le stress et le codage et tout) seulement 1 ou 2 heures. Il faut au client 1 minute pour se remettre au travail. J'examinerai l'approche du «service pack», cela peut en effet être utile pour ceux qui n'ont pas besoin du patch directement.
Mixxiphoid
J'ai trouvé cette référence pour Facebook: blogs.wsj.com/cio/2013/04/17/… , donc il semble y avoir deux versions, pas plusieurs, par jour. Toujours aussi impressionnant, je suppose.
Doc Brown
J'ai «entendu» ce code push amazon toutes les 17 secondes. Mais je le mets dans un commentaire parce que je ne me souviens pas qui m'a dit et un google ne le montre pas. :-)
Encaitar
@Encaitar: Oui, l'architecture d'Amazon a des centaines de services en interaction. Je ne suis donc pas surpris s'ils poussent quelque chose extrêmement fréquemment, mais je doute fort que chaque poussée affecte directement plus d'un composant. Ce que vous voyez comme un site Web unique n'a pas nécessairement une version globale. Cela revient plus à dire que le réseau routier de la ville est mis à jour toutes les 17 secondes parce que vos équipes peignent au total 5 000 lignes fraîches par jour :-)
Steve Jessop