Wie oft ist die Geschwindigkeit der Software in den Augen der Kunden erkennbar?

Theoretisch sollten Kunden in der Lage sein, die Verbesserungen der Softwareleistung aus erster Hand zu spüren.

In der Praxis sind die Verbesserungen manchmal nicht spürbar genug, so dass zur Monetarisierung der Verbesserungen im Marketing zitierfähige Leistungszahlen verwendet werden müssen, um Kunden anzulocken.

Wir kennen bereits den Unterschied zwischen der wahrgenommenen Leistung (GUI-Latenz usw.) und der serverseitigen Leistung (Maschinen, Netzwerke, Infrastruktur usw.).

Wie oft müssen Programmierer die zusätzliche Länge aufbringen, um Leistungsanalysen zu "schreiben", für die das Publikum keine Programmierkollegen, sondern Manager und Kunden sind?

Obwohl @jwenting einige gute Punkte hervorhebt , muss ich der allgemeinen Einschätzung nicht zustimmen.

Ein Benutzer bemerkt häufig keine geringfügigen Leistungsverbesserungen.

Dem kann ich zustimmen.

Wo ich nicht einverstanden bin, dreht sich um diese Aussage:

Die meisten Endbenutzeranwendungen verbringen die meiste Zeit damit, auf Benutzereingaben zu warten.

Bevor Sie auf und ab springen, stimme ich dieser Aussage ebenfalls zu! Diese Aussage hebt jedoch eine Tatsache hervor, die häufig von jenen übersehen wird, die nicht ausreichend verstehen, wie ein Benutzer ein System wirklich wahrnimmt.

Ein Benutzer wird feststellen, dass eine Anwendung langsam ist, wenn er auf das Laden warten muss. Ein Benutzer wird es bemerken, wenn er zwischen der Eingabe seiner Daten für das Programm pausieren muss.

Die Softwareleistung ist für einen Benutzer offensichtlich, wenn eine natürliche und flüssige Interaktion mit dem System unterbrochen wird.

Ein Benutzer wird die Systemleistung nur dann nicht bemerken, wenn sie einwandfrei funktioniert und den Benutzer nicht aufhält.

Einige Leistungsverbesserungen werden nicht als Leistung wahrgenommen. Der Kunde wird nur bemerken, dass sich das System besser anfühlt.

Das Unterbewusstsein arbeitet mit einer Geschwindigkeit, die viel schneller ist als das Bewusstsein. Unser Gehirn ist auf sofortiges Feedback programmiert, und wenn wir mit einer Abfolge von Aufgaben konfrontiert werden, müssen wir sie nacheinander durcharbeiten. Eine leichte Pause in der Rückkopplung führt dazu, dass dieser Prozess unterbrochen wird, was den Stresspegel erhöht. Die Benutzer doppelklicken automatisch auf eine Schaltfläche, ohne darüber nachzudenken, wenn das Feedback eine Pause enthält.

Sehr oft sind Leistungsverbesserungen so gering, dass der Kunde sie nie direkt bemerkt. Bestenfalls haben sie einen etwas flüssigeren Anwendungsfluss während ihrer Verwendung, aber nicht genug, um bewusst bemerkt zu werden.

Denken Sie daran, dass die meisten Endbenutzeranwendungen die meiste Zeit auf Benutzereingaben warten und diese nicht verarbeiten. Selbst wenn Sie 10% der 100 ms sparen, die für die Verarbeitung dieses Schaltflächenklicks und die Aktualisierung des Bildschirms erforderlich sind, wird der Benutzer dies kaum bemerken, da er nach weiteren 10000 ms nichts mehr mit diesem aktualisierten Bildschirm tun wird.

Wer es bemerken wird, ist der Systemadministrator, der sieht, dass ein Batch-Job, dessen Fertigstellung früher 2 Stunden dauerte, jetzt in 90 Minuten abgeschlossen ist. Er wird jedoch nur bemerken, dass ihn die schnellere Rückkehr auf halbem Weg unterbricht, wenn er auf das Ergebnis warten und möglicherweise wütend werden muss durch seinen Film :)

Wie andere heute sagen, geht es mehr um wahrgenommene Leistung und "Fluidität" als um tatsächliche Rohgeschwindigkeit.

Das bedeutet, dass Sie mit einem langsamen (er) System davonkommen können, indem Sie ein natürliches Gefühl und einen natürlichen Rhythmus in der Benutzeroberfläche Ihrer Software haben, anstatt einige Dinge zu schnell und andere sehr langsam zu haben. (Als Menschen bemerken wir Unregelmäßigkeiten sehr gut, da es sich möglicherweise um einen Tiger handelt, der sich an uns heranschleicht ...)

Dies ist wichtig, um Latenzen zu verbergen, gegen die Sie nichts tun können. Daher ist es eine gute Fähigkeit zu üben.

Ich wollte nur hier reinspringen und einen ungewöhnlichen Fall anbieten, in dem ....

* _{DIE KUNDEN SORGEN FÜR LEISTUNG UND BEACHTEN JEDE KLEINE ÄNDERUNG!} .

In meinem Bereich befassen wir uns mit Produktions-Rendering, das in Bezug auf die Leistung der Kunden selbst zu Tode analysiert wird. Eine Leistungsverlangsamung von 2% gegenüber einer Nebenversion kann mit einer Massenverlangsamung gleichgesetzt werden, die in Form von "Fehlerberichten" gemeldet wird.

Forum-Threads werden häufig mit Kunden gestartet, die ihre Szenen mit verschiedenen Versionen der Software vergleichen, wobei die Kunden tatsächlich mehr als die Entwickler selbst vergleichen. "Das Rendern dieser Szene in Version X dauerte 1 Stunde und 40 Minuten. In Version Y dauert es jetzt 32 Minuten."

"Das Laden dieser Szene in Version X dauerte 18 Minuten, jetzt dauert das Laden in Version Y 4 Minuten."

Sie sind äußerst dankbar, wenn Optimierungen angewendet werden, und dies allein kann ausreichen, um den Kauf eines neuen, sehr teuren Upgrades der Software zu rechtfertigen, und manchmal mit nur bescheidenen Verbesserungen wie einer 10% igen Verkürzung der Zeit.

In einigen größeren Kontexten kann dies dem Kunden auch enorme Geldbeträge einsparen, wenn das Produkt beschleunigt wird, da einige größere Studios Renderfarmen verwenden, in denen sie Hunderte von Maschinen bezahlen müssen, die den ganzen Tag rendern, und jede Verbesserung in Zeiten hier kann Beschleunigen Sie den gesamten Produktionsprozess (und erzielen Sie möglicherweise sogar bessere Ergebnisse, wenn Künstler produktiver Kunst schaffen, als darauf zu warten, dass sie gerendert wird).

Es gibt also Felder wie dieses, in denen die Kunden wirklich, wirklich, wirklich bemerken - manchmal sogar mehr als die Entwickler selbst, und dies außerhalb von UI-Interaktionskonzepten, bei denen es mehr um Latenz als um Durchsatz geht.

Wie oft müssen Programmierer die zusätzliche Länge aufbringen, um Leistungsanalysen zu "schreiben", für die das Publikum keine Programmierkollegen, sondern Manager und Kunden sind?

In unserem Fall die ganze Zeit mit fast jeder kleineren Veröffentlichung. Geschwindigkeit ist eines der wichtigsten Verkaufsargumente, und selbst die technischsten Benchmarks und Leistungsanalysen werden von Kunden und Managern geschätzt und verstanden. Die Wahrnehmung der Kunden ist oft wie bei tollwütigen Wölfen, die nach mehr Optimierungen hungern und versuchen, den Entwicklern Vorschläge zu machen, wie sie möglicherweise die Dinge schneller machen können. In diesem Fall ist Disziplin erforderlich, um einigen Kundenanforderungen zu widerstehen, sich weiter zu optimieren und sich auf andere Messgrößen wie Wartbarkeit und Funktionsverbesserungen zu konzentrieren.

Die einzigen Male, auf die ich stoße, sind:

1. Die Software verbessert sich, indem mehr Arbeit im gleichen Zeitraum ausgeführt wird.
2. Das Offline-Rendern oder Verarbeiten ist deutlich schneller, aber unsichtbar.
3. Geschwindigkeitssteigerungen sind eher nominell, aber Verbesserungen verhindern zukünftige Engpässe
4. Parallele Verarbeitung, die für viele die gleiche Arbeit mit der gleichen Geschwindigkeit erledigt.
5. Jedes Mal, wenn nicht wahrnehmbare Geschwindigkeitssteigerungen auftreten, wirkt sich dies stark auf die Produktivität aus.

Wenn der Kunde keine Geschwindigkeitsverbesserungen bemerkt, warum hat der Entwickler daran gearbeitet? Es gibt wahrscheinlich einen guten Grund. Warum diese Arbeit monetarisieren, wenn sie für den Benutzer transparent ist?

Ein Beispiel: Apple berechnet für jedes Mac OS X-Upgrade etwa 130 US-Dollar. Außer bei Snow Leopard, der 30 US-Dollar kostet. Entwickler haben hart an dieser Version gearbeitet, aber es gibt nur sehr wenige Verbesserungen, die aus Anwendersicht sichtbar sind. Deshalb hat Apple beschlossen, ein Minimum zu berechnen.

Wie oft müssen Programmierer die zusätzliche Länge aufbringen, um Leistungsanalysen zu "schreiben", für die das Publikum keine Programmierkollegen, sondern Manager und Kunden sind?

Ich glaube, das hängt von der Branche ab. In der verrückten Welt der Verteidigungsverträge tun wir dies ziemlich häufig. Wir haben spezielle Anforderungen, damit die Produkte auf bestimmte Weise funktionieren - und diese Leistungsmetriken stehen nicht immer in direktem Zusammenhang mit etwas, das ein Endbenutzer erlebt hat. Und wir führen im Allgemeinen unsere eigenen Tests durch, um festzustellen, wo das Produkt den Boden erreicht. Beide Arten von Tests sind in Berichten niedergeschrieben, in denen ernsthaft darüber nachgedacht wird, was dies bedeutet.

Ich bin mir jedoch nicht sicher, ob dies in Situationen zutrifft, in denen die Kunden- und Bereitstellungsbasis weniger spezialisiert ist (dh die Geschäftswelt). Angesichts der Tatsache, dass wir COTS kaufen, die den Leistungsspezifikationen entsprechen müssen, kann ich sagen, dass einige Käufer nach solchen Leistungsspezifikationen fragen, aber meiner Erfahrung nach haben die COTS-Unternehmen, zu denen ich gegangen bin, nicht immer so viele Whitepaper zur Leistungsanalyse verfügbar. Es scheint von der Branche, der Größe des Unternehmens und der Art des Wettbewerbs abzuhängen. Ah ... Kapitalismus.

Meiner Meinung nach sind die Leistungssteigerungen nicht marktfähig, wenn sie nicht spürbar sind. Mit anderen Worten, warum sollte jemand mehr für Software bezahlen, die nicht merklich verbessert wird?

Ich denke, Marketing-Behauptungen über nicht wahrnehmbare Leistungsverbesserungen haben dazu geführt, dass Benutzer diesen Behauptungen im Allgemeinen wenig Gewicht beimessen. Als ich zum Beispiel mit der Verwendung der verteilten Versionskontrolle beginnen wollte, ignorierte ich Ansprüche auf Git-Leistung, weil ich glaubte, dass die Unterschiede vernachlässigbar wären. Erst als ich es selbst ausprobierte, fand ich sie glaubwürdig, besonders wenn sie mit inotify-Unterstützung kombiniert wurden.

Ich werde eine Ausnahme für Leistungssteigerungen machen, die nicht direkt mit der Endbenutzererfahrung zusammenhängen. Beispielsweise wäre der Serverdurchsatz für Personen, die Server kaufen und warten, von Bedeutung, selbst wenn der Endbenutzer keinen Unterschied bemerkt. In diesem Fall ist eine einfache "prozentuale Verbesserung gegenüber X" ausreichend.

Es hängt davon ab, an wen Sie Ihr Softwareprodukt verkaufen.

Meistens ist Ihr Kunde nicht der Endbenutzer. So oft erstellen Sie schönere und glänzendere Berichte, anstatt Leistungsprobleme zu beheben. Weil Sie wirklich an das Management verkaufen, nicht an den Endbenutzer.

In diesem Fall wird es Ihnen schwer fallen, sich für einige Leistungsprobleme zu qualifizieren, aber Sie werden bei der Automatisierung dieses Berichts den höchsten Preis verdienen.