Seberapa sering kecepatan perangkat lunak terbukti di mata pelanggan?

Secara teori, pelanggan harus dapat merasakan peningkatan kinerja perangkat lunak dari pengalaman langsung.

Dalam praktiknya, terkadang perbaikan tidak cukup terlihat, sehingga untuk menghasilkan uang dari perbaikan, perlu menggunakan angka kinerja yang dapat dikutip dalam pemasaran untuk menarik pelanggan.

Kita sudah tahu perbedaan antara kinerja yang dirasakan (latensi GUI, dll) dan kinerja sisi server (mesin, jaringan, infrastruktur, dll).

Seberapa sering pemrogram perlu melakukan ekstra panjang untuk "menulis" analisis kinerja yang audiensnya bukan sesama programmer, tetapi manajer dan pelanggan?

Meskipun @jwenting membuat beberapa poin bagus, saya harus tidak setuju dengan penilaian umum.

Seorang pengguna sering tidak melihat peningkatan kinerja kecil.

Dengan itu, saya bisa setuju.

Di mana saya tidak setuju berkisar pada pernyataan ini:

sebagian besar aplikasi yang dihadapi pengguna akhir menghabiskan sebagian besar waktunya menunggu input pengguna.

Sekarang, sebelum Anda melompat-lompat, saya setuju dengan pernyataan itu juga! Namun, pernyataan ini menyoroti fakta yang sering diabaikan oleh mereka yang tidak cukup memahami bagaimana pengguna benar-benar memahami suatu sistem.

Seorang pengguna akan melihat bahwa suatu aplikasi lambat ketika mereka harus menunggu untuk memuat. Seorang pengguna akan melihatnya ketika mereka harus berhenti untuk program di antara memasukkan data mereka.

Kinerja perangkat lunak terbukti bagi pengguna ketika itu memecah interaksi alami dan cairan dengan sistem.

Seorang pengguna hanya tidak akan melihat kinerja sistem ketika berfungsi dengan sempurna dan tidak menahan pengguna.

Beberapa peningkatan kinerja tidak diperhatikan sebagai kinerja. Pelanggan hanya akan melihat bahwa sistem "terasa" lebih baik.

Subconcious bekerja dengan kecepatan jauh lebih cepat daripada yang sadar. Otak kita diprogram untuk umpan balik instan dan ketika dihadapkan dengan urutan tugas, kita perlu mengaduknya satu per satu. Sedikit jeda dalam umpan balik menyebabkan proses ini menjadi terputus-putus, yang meningkatkan tingkat stres. Orang-orang secara otomatis akan mengklik tombol dua kali tanpa memikirkannya jika ada jeda dalam umpan balik.

Cukup sering peningkatan kinerja sangat kecil sehingga pelanggan tidak pernah memperhatikan secara langsung. Paling-paling, mereka mungkin memiliki aliran aplikasi yang sedikit lebih lancar daripada penggunaannya, tetapi tidak cukup untuk diperhatikan secara sadar.

Ingat bahwa sebagian besar aplikasi yang menghadapi pengguna akhir menghabiskan sebagian besar waktu mereka menunggu input pengguna, bukan memproses input itu. Jadi, bahkan jika Anda mencukur 10% dari 100 ms yang diperlukan untuk memproses klik tombol itu dan memperbarui layar, pengguna hampir tidak akan melihat karena dia tidak akan melakukan apa pun dengan layar yang diperbarui untuk 10.000 ms setelahnya.

Yang akan melihat adalah sysadmin yang melihat pekerjaan batch yang biasanya membutuhkan waktu 2 jam untuk menyelesaikan sekarang selesai dalam 90 menit, tetapi dia hanya akan melihat bahwa jika dia harus menunggu hasilnya dan mungkin marah, pengembalian lebih cepat memotongnya di tengah jalan. melalui filmnya :)

Seperti yang dikatakan orang lain hari ini, ini lebih tentang kinerja yang dirasakan dan "fluiditiy" daripada kecepatan mentah yang sebenarnya.

Itu berarti bahwa Anda dapat pergi dengan memiliki sistem yang lambat (er) hanya dengan memiliki rasa alami dan ritme dalam UI perangkat lunak Anda, alih-alih memiliki beberapa hal yang terlalu cepat dan yang lain sangat lambat. (Sebagai manusia, kami melihat penyimpangan dengan sangat baik, karena itu mungkin harimau yang menyelinap ke atas kami ...)

Ini sangat penting dalam menyembunyikan latensi yang tidak dapat Anda lakukan, jadi ini adalah keterampilan yang baik untuk berlatih.

Saya hanya ingin melompat di sini dan menawarkan kasus yang tidak biasa di mana ....

* _{PELANGGAN FREAKING CARE TENTANG KINERJA DAN PEMBERITAHUAN SETIAP PERUBAHAN KECIL!} .

Itu di bidang saya di mana kita membahas rendering produksi yang cenderung dianalisis sampai mati dalam hal kinerja oleh pelanggan sendiri. Perlambatan 2% dalam kinerja dibandingkan versi minor dapat disamakan dengan perlambatan yang dilaporkan dalam bentuk "laporan bug" secara massal.

Forum threads sering dimulai dengan pelanggan membandingkan adegan mereka dengan berbagai versi perangkat lunak, di mana pelanggan sebenarnya melakukan benchmark lebih dari pengembang itu sendiri. "Adegan ini membutuhkan waktu 1 jam 40 menit untuk merender dalam versi X. Sekarang butuh 32 menit dalam versi Y."

"Adegan ini membutuhkan waktu 18 menit untuk memuat dalam versi X, sekarang dibutuhkan 4 menit untuk memuat dalam versi Y."

Mereka sangat menghargai ketika optimasi diterapkan, dan itu saja sudah cukup untuk menjamin pembelian upgrade perangkat lunak baru yang sangat mahal, dan kadang-kadang dengan hanya perbaikan sederhana seperti pengurangan 10% di kali.

Dalam beberapa konteks yang lebih besar, ini juga dapat menghemat uang dalam jumlah besar kepada pelanggan ketika produk dipercepat, karena beberapa studio yang lebih besar menggunakan pertanian render di mana mereka harus membayar ratusan mesin yang disumbangkan sepanjang hari, dan setiap peningkatan waktu di sini dapat mempercepat seluruh proses produksi mereka (dan bahkan mungkin menghasilkan hasil yang lebih baik ketika seniman lebih produktif menciptakan seni daripada menunggu untuk dirender).

Jadi ada bidang seperti ini di mana pelanggan benar-benar, benar-benar memperhatikan - kadang-kadang bahkan lebih dari pengembang itu sendiri, dan ini di luar konsep interaksi UI yang lebih tentang latensi daripada throughput.

Seberapa sering pemrogram perlu melakukan ekstra panjang untuk "menulis" analisis kinerja yang audiensnya bukan sesama programmer, tetapi manajer dan pelanggan?

Dalam kasus kami, setiap saat, dengan hampir setiap rilis kecil. Kecepatan adalah salah satu poin penjualan teratas, dan bahkan tolok ukur paling teknis dan analisis kinerja sebenarnya dihargai dan dipahami oleh pelanggan dan manajer. Persepsi pelanggan sering seperti serigala gila, haus akan lebih banyak optimisasi, dan mencoba memberikan saran kepada pengembang tentang cara berpotensi membuat segalanya berjalan lebih cepat. Dalam hal ini, sebenarnya dibutuhkan disiplin untuk menolak beberapa keinginan pelanggan untuk mengoptimalkan lebih lanjut dan fokus pada metrik lain seperti pemeliharaan dan peningkatan fitur.

Satu-satunya saat saya bertemu adalah:

1. Perangkat lunak membaik dengan melakukan lebih banyak pekerjaan dalam kerangka waktu yang sama.
2. Perenderan atau pemrosesan offline sangat cepat, tetapi tidak terlihat.
3. Peningkatan kecepatan agak nominal tetapi peningkatan mencegah kemacetan di masa depan
4. Pemrosesan paralel yang menghasilkan pekerjaan yang sama pada kecepatan yang sama, bagi banyak orang.
5. Setiap saat kecepatan yang tidak diketahui meningkat sangat memengaruhi produktivitas.

Jika pelanggan tidak akan melihat peningkatan kecepatan, mengapa pengembang mengerjakannya? Mungkin ada alasan bagus. Mengapa menghasilkan uang yang berfungsi jika transparan bagi pengguna?

Contoh: Apple mengenakan biaya sekitar $ 130 untuk setiap peningkatan Mac OS X. Kecuali pada Snow Leopard yang dijual $ 30. Pengembang telah bekerja keras pada versi itu tetapi ada sedikit perbaikan yang terlihat dari sudut pandang pengguna. Jadi Apple memutuskan untuk mengenakan biaya minimum.

Seberapa sering pemrogram perlu melakukan ekstra panjang untuk "menulis" analisis kinerja yang audiensnya bukan sesama programmer, tetapi manajer dan pelanggan?

Saya percaya ini tergantung pada industri. Dalam dunia kontraktor pertahanan yang aneh, kita sering melakukan ini. Kami memiliki persyaratan khusus untuk membuat produk berkinerja dengan cara tertentu - dan metrik kinerja ini tidak selalu terkait langsung dengan sesuatu yang dialami pengguna akhir. Dan kami umumnya melakukan pengujian kami sendiri untuk melihat di mana produk keluar. Kedua jenis tes ditulis dalam laporan dengan beberapa pemikiran serius tentang artinya.

Yang mengatakan, saya tidak yakin itu berlaku dalam situasi di mana basis pelanggan dan penyebaran kurang terspesialisasi (yaitu, dunia komersial). Mengingat kami membeli COTS yang perlu memenuhi spesifikasi kinerja, saya dapat mengatakan bahwa beberapa pembeli meminta spesifikasi kinerja seperti itu, tetapi menurut pengalaman saya, perusahaan COTS yang saya kunjungi tidak selalu memiliki begitu banyak analisis kinerja. tersedia. Tampaknya tergantung pada industri, ukuran perusahaan dan sifat persaingan. Ah ... kapitalisme.

Pendapat saya adalah jika kenaikan kinerja tidak terlihat, maka tidak dapat dipasarkan. Dengan kata lain, mengapa seseorang membayar lebih untuk perangkat lunak yang tidak terlihat membaik?

Saya pikir klaim pemasaran atas peningkatan kinerja yang tidak terlalu mencolok telah mengarahkan pengguna pada umumnya untuk memberikan sedikit bobot pada klaim tersebut. Sebagai contoh, ketika saya ingin mulai menggunakan kontrol versi terdistribusi, saya mengabaikan klaim kinerja git karena saya percaya perbedaannya dapat diabaikan. Hanya dengan mencobanya sendiri, saya menemukan bahwa mereka kredibel, terutama ketika dikombinasikan dengan dukungan yang tidak mendukung.

Saya akan membuat pengecualian untuk peningkatan kinerja yang tidak terkait langsung dengan pengalaman pengguna akhir. Misalnya, throughput server akan penting bagi orang yang membeli dan memelihara server, bahkan jika pengguna akhir tidak melihat perbedaan. Dalam hal itu, "peningkatan persen sederhana di atas X" sederhana sudah cukup.

Tergantung pada siapa Anda menjual produk perangkat lunak Anda.

Lebih sering daripada tidak, pelanggan Anda bukan pengguna akhir / hari ke hari. Sering kali Anda berakhir dengan membuat laporan yang lebih bagus dan berkilau alih-alih memperbaiki masalah kinerja. Karena Anda benar-benar menjual kepada manajemen, bukan pengguna akhir.

Yang berarti dalam hal ini, Anda akan kesulitan untuk mengikuti beberapa masalah kinerja tetapi akan menghasilkan banyak uang untuk mengotomatisasi laporan itu.