Con quale frequenza la velocità del software è evidente agli occhi dei clienti?

In teoria, i clienti dovrebbero essere in grado di percepire i miglioramenti delle prestazioni del software dall'esperienza diretta.

In pratica, a volte i miglioramenti non sono abbastanza evidenti, in modo tale che, al fine di monetizzare dai miglioramenti, è necessario utilizzare dati di performance quotabili nel marketing per attirare i clienti.

Conosciamo già la differenza tra prestazioni percepite (latenza GUI, ecc.) E prestazioni lato server (macchine, reti, infrastruttura, ecc.).

Quante volte è necessario che i programmatori facciano il possibile per "scrivere" analisi delle prestazioni per le quali il pubblico non è un collega programmatore, ma manager e clienti?

Anche se @jwenting fa alcuni aspetti positivi , non sono d'accordo con la valutazione generale.

Un utente spesso non nota miglioramenti minori delle prestazioni.

Con ciò, posso essere d'accordo.

Dove non sono d'accordo ruota attorno a questa affermazione:

la maggior parte delle applicazioni rivolte all'utente finale trascorre la maggior parte del tempo in attesa dell'input dell'utente.

Ora, prima di saltare su e giù, sono d'accordo anche con questa affermazione! Tuttavia, questa affermazione evidenzia un fatto spesso trascurato da coloro che non comprendono adeguatamente come un utente percepisce realmente un sistema.

Un utente si accorge che un'applicazione è lento quando devono aspettare che si carichi. Un utente lo noterà quando dovrà fare una pausa per il programma tra l'inserimento dei propri dati.

Le prestazioni del software sono evidenti per un utente quando interrompe un'interazione naturale e fluida con il sistema.

Un utente non noterà le prestazioni del sistema solo quando funziona perfettamente e non regge l'utente.

Alcuni miglioramenti delle prestazioni non vengono notati come prestazioni. Il cliente noterà semplicemente che il sistema "sembra" più bello.

Il subconcio lavora a velocità molto più veloce di quello cosciente. I nostri cervelli sono programmati per un feedback immediato e di fronte a una sequenza di compiti abbiamo bisogno di sfogliarli uno dopo l'altro. Una leggera pausa nel feedback fa sì che questo processo diventi disgiunto, il che aumenta i livelli di stress. Le persone fanno automaticamente doppio clic su un pulsante senza pensarci se c'è una pausa nel feedback.

Molto spesso i miglioramenti delle prestazioni sono così minori che il cliente non se ne accorge mai direttamente. Nel migliore dei casi, possono avere un flusso di applicazione leggermente più fluente sul loro utilizzo, ma non abbastanza per essere notato consapevolmente.

Ricorda che la maggior parte delle applicazioni rivolte agli utenti finali trascorre la maggior parte del loro tempo in attesa dell'input dell'utente, non dell'elaborazione di tale input. Quindi, anche se ottieni il 10% di sconto sui 100 ms necessari per elaborare il pulsante e aggiornare lo schermo, l'utente noterà a malapena poiché non farà nulla con quello schermo aggiornato per altri 10000 ms dopo.

Chi noterà è l'amministratore di sistema che vede un lavoro batch che impiegava 2 ore per completarsi ora completo in 90 minuti, ma noterà solo che se deve aspettare il risultato e potrebbe arrabbiarsi, il ritorno più veloce lo interrompe a metà strada attraverso il suo film :)

Come altri dicono oggi, si tratta più della prestazione percepita e della "fluiditismo" che della reale velocità pura.

Ciò significa che puoi cavartela con un sistema lento (er) semplicemente avendo una sensazione e un ritmo naturali nell'interfaccia utente del tuo software, invece di avere alcune cose troppo veloci e altre molto lente. (Come umani, notiamo molto bene le irregolarità, dal momento che potrebbe essere una tigre che si intrufola tra noi ...)

Questo è essenziale per nascondere latenze di cui non puoi fare nulla, quindi è una buona abilità esercitarsi.

Volevo solo saltare qui e offrire un caso insolito in cui ...

* _{I CLIENTI CHE TRASFERANO CURA DI PRESTAZIONI E AVVISO OGNI PICCOLO CAMBIAMENTO!} .

È nel mio campo che trattiamo il rendering di produzione che tende ad essere analizzato a morte in termini di prestazioni dai clienti stessi. Un rallentamento del 2% delle prestazioni rispetto a una versione minore può equivalere ai rallentamenti segnalati sotto forma di "segnalazioni di errori" in massa.

I thread del forum vengono spesso avviati con i clienti che confrontano le loro scene con varie versioni del software, in cui i clienti stanno effettivamente confrontando più degli sviluppatori stessi. "Il rendering di questa scena ha richiesto 1 ora e 40 minuti nella versione X. Adesso ci vogliono 32 minuti nella versione Y."

"Il caricamento di questa scena ha richiesto 18 minuti nella versione X, ora sono necessari 4 minuti per il caricamento nella versione Y."

Sono estremamente apprezzati quando vengono applicate le ottimizzazioni e questo da solo può bastare a giustificare un acquisto di un nuovo aggiornamento molto costoso del software, e talvolta con miglioramenti solo modesti come una riduzione dei tempi del 10%.

In alcuni contesti più grandi, può anche risparmiare al cliente enormi quantità di denaro quando il prodotto viene accelerato, poiché alcuni studi più grandi utilizzano fattorie di rendering in cui devono pagare centinaia di macchine per il rendering per tutto il giorno, e qualsiasi miglioramento nei tempi qui può accelerare l'intero processo di produzione (e possibilmente anche produrre risultati migliori quando gli artisti sono più produttivi creando arte piuttosto che aspettare che venga resa).

Quindi esistono campi come questo in cui i clienti lo notano davvero, davvero, a volte anche più degli stessi sviluppatori, e questo è al di fuori dei concetti di interazione dell'interfaccia utente che riguardano più la latenza che la velocità effettiva.

Quante volte è necessario che i programmatori facciano il possibile per "scrivere" analisi delle prestazioni per le quali il pubblico non è un collega programmatore, ma manager e clienti?

Nel nostro caso, sempre, con quasi ogni versione minore. La velocità è uno dei principali punti di forza e persino i benchmark più tecnici e le analisi delle prestazioni sono effettivamente apprezzati e compresi da clienti e manager. La percezione dei clienti è spesso come lupi rabbiosi, affamati di ulteriori ottimizzazioni e cercando di dare suggerimenti agli sviluppatori su come far andare le cose potenzialmente più velocemente. In questo caso, in realtà ci vuole disciplina per resistere ad alcune delle richieste del cliente di ottimizzare ulteriormente e concentrarsi su altre metriche come la manutenibilità e i miglioramenti delle funzionalità.

Le uniche volte in cui mi imbatto sono:

1. Il software migliora facendo più lavoro nello stesso lasso di tempo.
2. Il rendering o l'elaborazione offline è marcatamente più veloce, ma invisibile.
3. L'aumento di velocità è in qualche modo nominale ma i miglioramenti impediscono futuri colli di bottiglia
4. Elaborazione parallela che compie lo stesso lavoro alla stessa velocità, per molti.
5. Ogni volta che aumenti impercettibili della velocità influiscono fortemente sulla produttività.

Se il cliente non noterà miglioramenti della velocità, perché lo sviluppatore ha lavorato su di essi? C'è probabilmente una buona ragione. Perché monetizzare quel lavoro se è trasparente per l'utente?

Un esempio: Apple addebita circa $ 130 per ogni aggiornamento di Mac OS X. Tranne Snow Leopard che viene venduto $ 30. Gli sviluppatori hanno lavorato duramente su quella versione ma ci sono pochissimi miglioramenti che sono visibili dal punto di vista dell'utente. Quindi Apple ha deciso di addebitare un minimo.

Quante volte è necessario che i programmatori facciano il possibile per "scrivere" analisi delle prestazioni per le quali il pubblico non è un collega programmatore, ma manager e clienti?

Credo che dipenda dall'industria. Nel mondo stravagante dei contratti di difesa, lo facciamo abbastanza frequentemente. Abbiamo requisiti specifici per far funzionare i prodotti in determinati modi e queste metriche delle prestazioni non sono sempre direttamente correlate a qualcosa che un utente finale ha sperimentato. E generalmente eseguiamo i nostri test per vedere dove il prodotto esce dal fondo. Entrambi i tipi di test sono scritti in rapporti con una seria riflessione su ciò che significa.

Detto questo, non sono sicuro che sia vero in situazioni in cui il cliente e la base di distribuzione sono meno specializzati (vale a dire, il mondo commerciale). Dato che acquistiamo COT che devono soddisfare le specifiche di prestazione, posso dire che alcuni acquirenti chiedono tali specifiche di prestazione, ma nella mia esperienza, le aziende COTS con cui sono andato non hanno sempre così tanti white paper sull'analisi delle prestazioni a disposizione. Sembra dipendere dall'industria, dalle dimensioni dell'azienda e dalla natura della concorrenza. Ah ... capitalismo.

La mia opinione è se i miglioramenti delle prestazioni non sono evidenti, quindi non sono negoziabili. In altre parole, perché qualcuno dovrebbe pagare di più per un software che non è notevolmente migliorato?

Penso che le affermazioni di marketing di miglioramenti prestazionali impercettibili abbiano portato gli utenti in generale a dare poco peso a tali affermazioni. Ad esempio, quando volevo iniziare a utilizzare il controllo della versione distribuita, ho ignorato le affermazioni sulle prestazioni di git perché credevo che le differenze sarebbero state trascurabili. È stato solo provandolo da solo che ho scoperto che erano credibili, soprattutto se combinato con il supporto inotify.

Farò un'eccezione per i miglioramenti delle prestazioni che non sono direttamente correlati all'esperienza dell'utente finale. Ad esempio, il throughput del server è importante per le persone che acquistano e gestiscono i server, anche se l'utente finale non nota alcuna differenza. In tal caso, è sufficiente un semplice "miglioramento percentuale rispetto a X".

Dipende da chi stai vendendo il tuo prodotto software.

Più spesso no, il tuo cliente non è l'utente finale / giornaliero. Così spesso finisci per creare rapporti più belli e brillanti invece di risolvere i problemi di prestazioni. Perché davvero stai vendendo al management, non all'utente finale.

Il che significa che in quel caso, ti verrà difficile fare pressioni per alcuni problemi di prestazioni, ma guadagnerai il massimo in termini di automazione del rapporto.