À quelle fréquence la vitesse du logiciel est-elle évidente aux yeux des clients?

En théorie, les clients devraient pouvoir ressentir les améliorations des performances logicielles grâce à une expérience de première main.

Dans la pratique, les améliorations ne sont parfois pas suffisamment perceptibles, de telle sorte que pour rentabiliser les améliorations, il est nécessaire d'utiliser des chiffres de performance dans le marketing afin d'attirer des clients.

Nous connaissons déjà la différence entre les performances perçues (latence de l'interface graphique, etc.) et les performances côté serveur (machines, réseaux, infrastructure, etc.).

À quelle fréquence les programmeurs doivent-ils aller plus loin pour "rédiger" des analyses de performances pour lesquelles le public n'est pas d'autres programmeurs, mais des managers et des clients?

Bien que @jwenting soulève de bons points, je ne suis pas d'accord avec l'évaluation générale.

Souvent, un utilisateur ne remarque pas d'améliorations mineures des performances.

Avec cela, je suis d'accord.

Là où je suis en désaccord tourne autour de cette déclaration:

la plupart des applications destinées aux utilisateurs finaux passent la plupart de leur temps à attendre les commentaires des utilisateurs.

Maintenant, avant de sauter de haut en bas, je suis également d'accord avec cette affirmation! Cependant, cette déclaration met en évidence un fait souvent ignoré par ceux qui ne comprennent pas correctement comment un utilisateur perçoit réellement un système.

Un utilisateur sera qu'une demande est lent quand ils doivent attendre qu'il se charge. Un utilisateur le remarquera lorsqu'il devra faire une pause pour le programme entre la saisie de ses données.

Les performances d'un logiciel sont évidentes pour un utilisateur lorsqu'il rompt une interaction naturelle et fluide avec le système.

Un utilisateur ne remarquera les performances du système que s'il fonctionne parfaitement et ne retient pas l'utilisateur.

Certaines améliorations de performances ne sont pas considérées comme des performances. Le client remarquera simplement que le système "se sent" mieux.

Le subconcieux fonctionne à des vitesses bien plus rapides que le concious. Nos cerveaux sont programmés pour une rétroaction instantanée et lorsqu'ils sont confrontés à une séquence de tâches, nous devons les parcourir l'un après l'autre. Une légère pause dans la rétroaction provoque la décomposition de ce processus, ce qui augmente les niveaux de stress. Les gens double-cliqueront automatiquement sur un bouton sans y penser s'il y a une pause dans la rétroaction.

Très souvent, les améliorations des performances sont si mineures que le client ne le remarque jamais directement. Au mieux, ils peuvent avoir un flux d'application légèrement plus fluide au cours de leur utilisation, mais pas assez pour être consciemment remarqué.

N'oubliez pas que la plupart des applications destinées aux utilisateurs finaux passent la majeure partie de leur temps à attendre l'entrée de l'utilisateur, et non à la traiter. Donc, même si vous réduisez de 10% les 100 ms nécessaires pour traiter ce clic sur le bouton et mettre à jour l'écran, l'utilisateur remarquera à peine car il ne fera rien avec cet écran mis à jour pendant 10000 ms après.

Qui remarquera est l'administrateur système qui voit un travail par lots qui prenait auparavant 2 heures pour terminer maintenant terminé en 90 minutes, mais il remarquera seulement que s'il doit attendre le résultat et se mettre en colère, le retour plus rapide l'interrompt à mi-chemin à travers son film :)

Comme d'autres le disent aujourd'hui, il s'agit davantage de performances perçues et de "fluidité" que de la vitesse brute réelle.

Cela signifie que vous pouvez vous en sortir avec un système lent (euh) simplement en ayant une sensation et un rythme naturels dans l'interface utilisateur de votre logiciel, au lieu d'avoir certaines choses trop rapides et d'autres très lentes. (En tant qu'humains, nous remarquons très bien les irrégularités, car il pourrait s'agir d'un tigre qui se faufile en nous ...)

Ceci est essentiel pour masquer des latences sur lesquelles vous ne pouvez rien faire, c'est donc une bonne compétence à pratiquer.

Je voulais juste sauter ici et offrir un cas inhabituel où ...

* _{LES CLIENTS SE SOUFFRENT DE LA PERFORMANCE ET AVIS CHAQUE CHANGEMENT!} .

C'est dans mon domaine que nous couvrons le rendu de production qui a tendance à être analysé à mort en termes de performances par les clients eux-mêmes. Un ralentissement de 2% des performances par rapport à une version mineure peut équivaloir aux ralentissements signalés sous forme de «rapports de bogues» en masse.

Les discussions sur le forum sont souvent lancées avec des clients qui comparent leurs scènes avec différentes versions du logiciel, où les clients comparent plus que les développeurs eux-mêmes. "Cette scène a pris 1 heure et 40 minutes pour être rendue dans la version X. Elle prend maintenant 32 minutes dans la version Y."

"Cette scène a pris 18 minutes à charger dans la version X, maintenant il faut 4 minutes pour la charger dans la version Y."

Ils sont extrêmement reconnaissants lorsque des optimisations sont appliquées, et cela seul peut suffire à justifier l'achat d'une nouvelle mise à niveau très coûteuse du logiciel, et parfois avec seulement des améliorations modestes comme une réduction de 10% des temps.

Dans certains contextes plus vastes, cela peut également faire économiser au client d'énormes sommes d'argent lorsque le produit est accéléré, car certains grands studios utilisent des fermes de rendu où ils doivent payer pour des centaines de machines rendant toute la journée, et toute amélioration des délais ici peut accélérer tout leur processus de production (et peut-être même donner de meilleurs résultats lorsque les artistes sont plus productifs en créant de l'art plutôt qu'en attendant qu'il soit rendu).

Il existe donc des domaines comme celui-ci où les clients remarquent vraiment, vraiment, vraiment - parfois même plus que les développeurs eux-mêmes, et cela est en dehors des concepts d'interaction d'interface utilisateur qui sont plus sur la latence que sur le débit.

À quelle fréquence les programmeurs doivent-ils aller plus loin pour "rédiger" des analyses de performances pour lesquelles le public n'est pas d'autres programmeurs, mais des managers et des clients?

Dans notre cas, tout le temps, avec presque toutes les versions mineures. La vitesse est l'un des principaux arguments de vente, et même les références et analyses de performances les plus techniques sont réellement appréciées et comprises par les clients et les managers. La perception des clients est souvent comme des loups enragés, avides de plus d'optimisations et essayant de faire des suggestions aux développeurs sur la façon de faire accélérer les choses. Dans ce cas, il faut en fait de la discipline pour résister à certaines des demandes pressantes du client d'optimiser davantage et de se concentrer sur d'autres mesures telles que la maintenabilité et les améliorations des fonctionnalités.

Les seules fois que je rencontre sont:

1. Le logiciel s'améliore en effectuant plus de travail dans le même laps de temps.
2. Le rendu ou le traitement hors ligne est nettement plus rapide, mais invisible.
3. Le boost de vitesse est quelque peu nominal mais les améliorations empêchent de futurs goulots d'étranglement
4. Traitement parallèle qui accomplit le même travail à la même vitesse, pour beaucoup.
5. À tout moment, une augmentation de vitesse inaperçue affecte fortement la productivité.

Si le client ne remarque pas d'amélioration de la vitesse, pourquoi le développeur y a-t-il travaillé? Il y a probablement une bonne raison. Pourquoi monétiser ce travail s'il est transparent pour l'utilisateur?

Un exemple: Apple facture environ 130 $ pour chaque mise à niveau de Mac OS X. Sauf sur Snow Leopard qui est vendu 30 $. Les développeurs ont travaillé dur sur cette version mais il y a très peu d'améliorations visibles du point de vue de l'utilisateur. Apple a donc décidé de facturer un minimum.

À quelle fréquence les programmeurs doivent-ils aller plus loin pour "rédiger" des analyses de performances pour lesquelles le public n'est pas d'autres programmeurs, mais des managers et des clients?

Je pense que cela dépend de l'industrie. Dans le monde loufoque des contrats de défense, nous le faisons assez fréquemment. Nous avons des exigences spécifiques pour que les produits fonctionnent de certaines manières - et ces mesures de performances ne sont pas toujours directement liées à quelque chose qu'un utilisateur final a vécu. Et nous faisons généralement nos propres tests pour voir où le produit se termine. Les deux types de tests sont consignés dans des rapports avec une réflexion sérieuse sur ce que cela signifie.

Cela dit, je ne suis pas sûr que cela se vérifie dans les situations où la clientèle et la base de déploiement sont moins spécialisées (c'est-à-dire le monde commercial). Étant donné que nous achetons des COTS qui doivent répondre aux spécifications de performance, je peux dire que certains acheteurs demandent de telles spécifications de performance, mais d'après mon expérience, les sociétés COTS dans lesquelles je suis allé n'ont pas toujours autant de livres blancs sur l'analyse des performances. disponible. Cela semble dépendre de l'industrie, de la taille de l'entreprise et de la nature de la concurrence. Ah ... le capitalisme.

À mon avis, si les gains de performance ne sont pas perceptibles, ils ne sont pas commercialisables. En d'autres termes, pourquoi quelqu'un paierait-il plus pour un logiciel qui n'est pas sensiblement amélioré?

Je pense que les allégations marketing d'amélioration des performances imperceptibles ont conduit les utilisateurs en général à accorder peu de poids à ces allégations. Par exemple, lorsque j'ai voulu commencer à utiliser le contrôle de version distribué, j'ai ignoré les affirmations de performances git parce que je pensais que les différences seraient négligeables. Ce n'est qu'en l'essayant par moi-même que j'ai trouvé qu'ils étaient crédibles, surtout lorsqu'ils étaient associés à un soutien inotify.

Je ferai une exception pour les gains de performances qui ne sont pas directement liés à l'expérience de l'utilisateur final. Par exemple, le débit du serveur est important pour les personnes qui achètent et entretiennent des serveurs, même si l'utilisateur final ne remarque pas de différence. Dans ce cas, une simple "amélioration en pourcentage par rapport à X" suffit.

Cela dépend à qui vous vendez votre logiciel.

Plus souvent que non, votre client n'est pas l'utilisateur final / quotidien. Si souvent, vous vous retrouvez avec des rapports plus agréables et brillants au lieu de résoudre des problèmes de performances. Parce que vous vendez vraiment à la direction, pas à l'utilisateur final.

Dans ce cas, vous aurez du mal à corriger certains problèmes de performances, mais vous gagnerez le plus d'argent en automatisant ce rapport.