Yazılım hızı müşterilerin gözünde ne sıklıkla görülür?

Teorik olarak, müşteriler yazılım deneyimindeki gelişmeleri ilk elden deneyimleyebilmelidir.

Pratikte, bazen iyileştirmeler yeterince fark edilmez, böylece iyileştirmelerden para kazanmak için, müşterileri çekmek için pazarlamada alıntılanabilir performans rakamlarının kullanılması gerekir.

Algılanan performans (GUI gecikmesi, vb.) Ve sunucu tarafı performans (makineler, ağlar, altyapı, vb.) Arasındaki farkı zaten biliyoruz.

Programcıların, kitlenin diğer programcılar değil, yöneticiler ve müşteriler olduğu performans analizlerini "yazmak" için ne kadar zamana ihtiyacı vardır?

@Jwenting iyi bir noktaya işaret etse de, genel değerlendirmeye katılmıyorum.

Bir kullanıcı genellikle küçük performans iyileştirmeleri fark etmez.

Bununla hemfikirim.

Katılmıyorum nerede bu açıklama etrafında döner:

kullanıcılara yönelik son uygulamaların çoğu zamanlarının çoğunu kullanıcı girdisini bekleyerek geçirir.

Şimdi, yukarı ve aşağı zıplamadan önce, bu ifadeye de katılıyorum! Bununla birlikte, bu ifade, bir kullanıcının bir sistemi gerçekten nasıl algıladığını yeterince anlamayanlar tarafından sıklıkla göz ardı edilen bir gerçeği vurgular.

Bir kullanıcı bir uygulamanın yüklenmesini beklemek zorunda kaldığında yavaş olduğunu fark edecektir . Kullanıcı , verileri girmek arasında program için duraklatmak zorunda kaldığında bunu fark edecektir .

Yazılım performansı, kullanıcı için sistemle doğal ve akıcı bir etkileşimi bozduğunda belirgindir.

Bir kullanıcı sistem performansını ancak kusursuz bir şekilde çalıştığında ve kullanıcıyı beklemediğinde fark etmez.

Bazı performans geliştirmeleri performans olarak fark edilmez. Müşteri sadece sistemin "daha hoş" olduğunu fark edecektir.

Bilinçaltı, bilinçli olandan çok daha hızlı çalışır. Beynimiz anında geri bildirim için programlanmıştır ve bir dizi görevle karşı karşıya kaldıklarında birbiri ardına dolaşmamız gerekir. Geri bildirimde hafif bir duraklama, bu sürecin ayrılmasına neden olur, bu da stres seviyelerini artırır. Geri bildirimde bir duraklama varsa, insanlar düşünmeden bir düğmeyi otomatik olarak çift tıklar.

Çoğu zaman performans iyileştirmeleri o kadar küçüktür ki müşteri asla doğrudan fark etmez. En iyi ihtimalle, kullanımları üzerinde biraz daha akıcı bir uygulama akışına sahip olabilirler, ancak bilinçli olarak fark edilmek için yeterli değildir.

Son kullanıcılara bakan uygulamaların çoğunun zamanlarının çoğunu bu girdiyi işlemek için değil, kullanıcı girdisini beklemek için harcadığını unutmayın. Bu nedenle, bu düğmeyi tıklamak ve ekranı güncellemek için gereken 100 ms'lik kapalı% 10'luk tıraş olsanız bile, kullanıcı, güncellenmiş ekranla hiçbir şey yapmaz, ancak 10000ms daha sonra fark etmez.

Kimin farkına varacak olan sysadmin, şimdi tamamlamak için 2 saat süren bir toplu iş gören 90 dakika içinde tamamlandı, ancak sadece sonucu beklemek zorunda ve sinirlenecekse, daha hızlı geri dönüşün yarıda kesildiğini fark edecek filmi boyunca :)

Diğerlerinin bugün söylediği gibi, gerçek ham hızdan daha çok algılanan performans ve "akışkanlık" ile ilgilidir.

Bu, bazı şeylerin çok hızlı ve diğerlerinin çok yavaş olması yerine, yazılımınızın kullanıcı arayüzünde doğal bir his ve ritim ile yavaş (er) bir sisteme sahip olmaktan kurtulabileceğiniz anlamına gelir. (İnsanlar olarak, usulsüzlükleri çok iyi fark ediyoruz, çünkü bu bize gizlice giren bir kaplan olabilir ...)

Bu, hiçbir şey yapamayacağınız gecikmeleri gizlemek için önemlidir, bu yüzden pratik yapmak iyi bir beceridir.

Sadece buraya atlamak ve sıradışı bir durum sunmak istedim nerede ....

* _{MÜŞTERİLERİN HER KÜÇÜK DEĞİŞİM PERFORMANSI VE BİLDİRİMİ İLE İLGİLİ BAKIM FREKANSI!} .

Benim alanımda, müşterilerin performansları açısından ölümle analiz etme eğilimi gösteren üretim renderlemeyi ele alıyoruz. Küçük bir versiyona göre performansta% 2'lik bir yavaşlama, toplu olarak "hata raporları" şeklinde bildirilen yavaşlamalara eşit olabilir.

Forum konuları genellikle müşterilerin sahnelerini yazılımın çeşitli sürümlerine göre karşılaştırmasıyla başlar ve müşterilerin aslında geliştiricilerin kendilerinden daha fazla kıyaslaması yapar. "Bu sahne X sürümünde oluşturulması 1 saat 40 dakika sürdü. Şimdi Y sürümünde 32 dakika sürüyor."

"Bu sahne X sürümüne yüklenmek 18 dakika sürdü, şimdi Y sürümüne yüklenmek 4 dakika sürüyor."

Optimizasyonlar uygulandığında son derece takdir ediyorlar ve tek başına, yazılımın yeni, çok pahalı bir yükseltmesini satın almayı garanti etmek için yeterli olabilir ve bazen zamanlarda% 10'luk bir azalma gibi mütevazı iyileştirmelerle.

Bazı büyük bağlamlarda, ürün hızlandırıldığında müşteriye çok büyük miktarda para tasarrufu sağlayabilir, çünkü bazı büyük stüdyolar, gün boyu render eden yüzlerce makine için ödemek zorunda oldukları render çiftliklerini kullanır ve buradaki zamanlardaki iyileştirmeler tüm üretim süreçlerini hızlandırır (ve sanatçılar daha üretken sanat yaratmayı beklemek yerine daha üretken olduklarında muhtemelen daha iyi sonuçlar verir).

Bu nedenle, müşterilerin gerçekten, gerçekten, gerçekten fark ettiği - bazen geliştiricilerin kendisinden bile daha fazla olduğu alanlar var ve bu, iş akışından daha fazla gecikme ile ilgili olan UI etkileşim kavramlarının dışında.

Programcıların, kitlenin diğer programcılar değil, yöneticiler ve müşteriler olduğu performans analizlerini "yazmak" için ne kadar zamana ihtiyacı vardır?

Bizim durumumuzda, her zaman, neredeyse her küçük sürümle. Hız en çok satan noktalardan biridir ve en teknik ölçütler ve performans analizleri bile müşteriler ve yöneticiler tarafından takdir edilir ve anlaşılır. Müşterilerin algısı genellikle kuduz kurtlar gibidir, daha fazla optimizasyona açtır ve geliştiricilere işlerin nasıl daha hızlı ilerleyeceği konusunda önerilerde bulunmaya çalışır. Bu durumda, daha fazla optimizasyon yapmak ve sürdürülebilirlik ve özellik geliştirmeleri gibi diğer metriklere odaklanmak için bazı müşteri dürtülerine direnmek disiplini gerektirir.

Karşılaştığım tek zaman:

1. Yazılım aynı zaman diliminde daha fazla iş yaparak gelişir.
2. Çevrimdışı oluşturma veya işleme belirgin şekilde daha hızlıdır, ancak görünmezdir.
3. Hız artışı biraz nominaldir ancak iyileştirmeler gelecekteki darboğazları önler
4. Birçoğu için aynı işi aynı hızda gerçekleştiren paralel işleme.
5. Fark edilmeyen hız arttıkça üretkenlik güçlü bir şekilde etkilenir.

Müşteri hızdaki gelişmeleri fark etmezse, geliştirici neden bunlar üzerinde çalıştı? Muhtemelen iyi bir sebep var. Kullanıcı için şeffafsa neden bu çalışmadan para kazanın?

Bir örnek: Apple, her bir Mac OS X yükseltmesi için yaklaşık 130 $ ücret alıyor. 30 $ satılan Snow Leopard hariç. Geliştiriciler bu sürüm üzerinde çok çalıştı, ancak kullanıcı bakış açısından görülebilen çok az iyileştirme var. Bu yüzden Apple minimum ücret talep etmeye karar verdi.

Programcıların, kitlenin diğer programcılar değil, yöneticiler ve müşteriler olduğu performans analizlerini "yazmak" için ne kadar zamana ihtiyacı vardır?

Sanırım sektöre bağlı. Tuhaf savunma sözleşmesi dünyasında, bunu oldukça sık yapıyoruz. Ürünlerin belirli şekillerde performans göstermesi için özel gereksinimlerimiz var - ve bu performans metrikleri her zaman doğrudan son kullanıcının yaşadığı bir şeyle ilgili değildir. Ve genellikle ürünün nerede dibe vurduğunu görmek için kendi testimizi yaparız. Her iki test türü de ne anlama geldiğine dair ciddi düşüncelere sahip raporlarda yazılır.

Bununla birlikte, müşteri ve dağıtım tabanının daha az uzmanlaştığı durumlarda (yani ticari dünya) doğru olduğundan emin değilim. Performans spesifikasyonlarını karşılaması gereken COTS satın aldığımız göz önüne alındığında, bazı alıcıların bu tür performans spesifikasyonlarını istediğini söyleyebilirim, ancak deneyimlerime göre, gittiğim COTS şirketleri her zaman çok fazla performans analizi teknik incelemesine sahip değil mevcut. Sanayiye, şirketin büyüklüğüne ve rekabetin doğasına bağlı gibi görünüyor. Ah ... kapitalizm.

Bence performans kazançları farkedilemezse, o zaman pazarlanamazlar. Başka bir deyişle, neden belirgin bir şekilde iyileştirilmemiş yazılımlar için daha fazla ödeme yapılır?

Fark edilmeyen performans iyileştirmeleriyle ilgili pazarlama iddialarının, kullanıcıları genel olarak bu tür iddialara çok az ağırlık vermeye yönlendirdiğini düşünüyorum. Örneğin, dağıtılmış sürüm denetimini kullanmaya başlamak istediğimde, git performansı iddialarını göz ardı ettim, çünkü farklılıkların ihmal edilebileceğine inandım. Sadece kendim için deneyerek, özellikle inotify desteği ile birleştirildiğinde güvenilir olduklarını gördüm.

Son kullanıcı deneyimiyle doğrudan ilgili olmayan performans kazançları için bir istisna yapacağım. Örneğin, sunucu çıkışı, son kullanıcı bir fark fark etmese bile, sunucu satın alan ve bakımını yapan kişiler için önemli olacaktır. Bu durumda, basit bir "X üzerinde yüzde iyileşme" yeterlidir.

Yazılım ürününü kime sattığınıza bağlıdır.

Daha sık olmamakla birlikte, müşteriniz son / günlük kullanıcı değildir. Sonuçta, performans sorunlarını düzeltmek yerine daha güzel ve parlak raporlar elde edersiniz. Çünkü gerçekten son kullanıcıya değil, yönetime satıyorsunuz.

Bu, bu durumda, bazı performans sorunlarına işaret etmek için zorlanacaksınız, ancak bu raporu otomatikleştirirken en yüksek doları elde edeceksiniz.