Apakah tambalan merupakan pertanda buruk bagi pelanggan? [Tutup]


14

Di kantor kami baru saja keluar dari periode yang lama di mana kami merilis tambalan terlalu sering. Menjelang akhir periode itu, kami melakukan hampir tiga tambalan per minggu.

Selain itu sangat mendemotivasi para pengembang, saya bertanya-tanya apa yang pelanggan pikirkan tentang ini. Saya mengajukan pertanyaan sendiri dan menyimpulkan bahwa saya tidak pernah tahu perangkat lunak yang sering diperbarui. Namun, untuk kasus yang paling dekat saya tidak terlalu peduli karena tambalan cukup cepat diterapkan.

Pelanggan yang menerima tambalan ini sangat berbeda satu sama lain. Beberapa benar-benar menunggu tambalan di mana yang lain tidak benar-benar peduli, namun mereka semua mendapatkan tambalan yang sama. Waktu untuk memperbarui perangkat lunak pelanggan adalah kurang dari 30 detik, jadi saya tidak berharap ada masalah mengenai waktu. Mereka perlu keluar sekalipun.

Jadi pertanyaan saya secara lebih rinci: Apakah mendapatkan pembaruan sering memberikan pesan 'negatif' kepada penerima?

Tentu saja, saya bisa bertanya kepada pelanggan, tetapi saya tidak dalam posisi itu dan saya juga tidak ingin 'Membangkitkan anjing tidur'.

PS: Jika ada yang bisa saya lakukan untuk meningkatkan pertanyaan saya, silakan tinggalkan komentar.


@ downvoter, mau jelaskan?
Mixxiphoid

6
Jika Anda khawatir tentang persepsi pelanggan, mungkin menggambarkannya sebagai "pembaruan" daripada "tambalan"? :)
Chris Taylor

Meskipun ini bukan jawaban langsung, jika Anda dapat menjaga penyebaran tambalan sebagai tidak mengganggu dan seotomatis mungkin (mis. Pembaruan unduhan di latar belakang, memiliki layanan pembaruan yang berjalan untuk diterapkan saat idle), maka Anda dapat mengurangi kecemasan pengguna akhir dengan tidak membuat pembaruan jelas. Misalnya: Berapa banyak pembaruan Google Chrome yang Anda terima dalam sebulan terakhir ini? (Jawab: banyak ). Mereka bisa merilis 5 tambalan untuk Chrome per hari, dan tak seorang pun akan mengangkat alis. Pembaruan Windows otomatis (ketika diaktifkan) adalah contoh lain.
Jason C

"Waktu untuk memperbarui perangkat lunak pelanggan adalah kurang dari 30 detik, jadi saya tidak berharap ada masalah mengenai waktu. Namun mereka perlu keluar." Bagaimana dengan pelanggan yang menguji tambalan itu sendiri? Saya tidak tahu perangkat lunak seperti apa yang Anda gunakan, tetapi jika mendekati kritis untuk siapa pun, mereka ingin menguji pembaruan sebelum menjalankannya di lingkungan produksi. Meskipun pemasangan tambalan mungkin cepat dan mudah, pengujian itu akan memakan banyak waktu dan upaya dari pihak pelanggan.
CVn

@ MichaelKjörling Masalahnya adalah, pada periode itu fitur kritis misi gagal, jadi tidak masalah apakah lingkungan produksi atau lingkungan pengujian diperbarui terlebih dahulu. Itu hanya perlu bekerja secepatnya.
Mixxiphoid

Jawaban:


24

Seperti banyak hal dalam komputasi, itu tergantung. Jika tambalan merupakan respons terhadap permintaan pelanggan untuk fitur atau peningkatan baru, maka perusahaan Anda akan dianggap responsif. Jika, di sisi lain, tambalan Anda merupakan respons terhadap laporan bug, maka perusahaan Anda akan dianggap tidak kompeten.

masukkan deskripsi gambar di sini

Menguji perangkat lunak pada pelanggan Anda sejauh ini merupakan cara termudah untuk mendeteksi bug, tidak peduli apa kata orang. Ini ekonomi palsu; tenaga kerja gratis yang Anda pikir Anda dapatkan lebih dari diimbangi oleh upaya layanan pelanggan, memutus siklus hidup pengembangan perangkat lunak, dan kehilangan kepercayaan pelanggan.


3
Mungkin ini harus menjadi pertanyaan yang berbeda, tetapi bagaimanapun: Kami tahu kami menguji melalui pelanggan kami tetapi tidak bisa menghentikan itu pada saat itu, kami terjebak dalam sebuah siklus. Apa yang bisa kita lakukan untuk keluar?
Mixxiphoid

3
Robert, saya telah melihat diagram ini beberapa kali sebelumnya. Itu mungkin benar ketika pengembangan perangkat lunak mengikuti model air terjun murni, tetapi karena perangkat lunak dapat dikembangkan dan digunakan dalam siklus kecil, itu semakin salah. Tepatnya - untuk sejumlah kecil bug dan perangkat lunak kecenderungannya masih benar, untuk banyak bug itu pasti salah.
Doc Brown

2
@DocBrown: Grafiknya masih benar. Siklus pengembangan yang lebih pendek berarti lebih sedikit biaya per siklus, yang konsisten dengan grafik. Tetapi itu masih tidak berarti Anda harus menguji perangkat lunak Anda pada pelanggan, kecuali ada pemahaman dan kesepakatan yang jelas bahwa ini adalah bagian dari proses.
Robert Harvey

Nah, biaya cacat berkurang semakin awal bug ditemukan dan diperbaiki. Dan kemungkinan bug ditemukan meningkat secara dramatis semakin awal Anda mendapatkan perangkat lunak Anda. Itu tidak berarti seseorang harus mendorong perangkat lunak yang belum diuji ke dalam produksi, tentu saja. Saya merekomendasikan, misalnya, artikel ini agileelements.wordpress.com/2008/04/22/cost-of-software-defects
Doc Brown

1
Yang diperlukan hanyalah sedikit refleksi diri untuk melihat bahwa prinsip itu sendiri adalah bunyi, bahkan jika angka atau bentuk kurva hanyalah tebakan liar. Kami bahkan memiliki nama untuk itu dalam bahasa pemrograman: Gagal Cepat.
Robert Harvey

10

Saya merasa seperti melepaskan beberapa tambalan di dekat mencerminkan buruk pada perusahaan. Itu selalu membuat saya merasa seperti mereka tidak menguji secara menyeluruh di muka, bahwa pengembang tidak kompeten, atau manajemen tidak tahu apa yang mereka lakukan.

Yang sedang berkata, sisi lain dari token adalah bahwa melepaskan beberapa tambalan yang berdekatan satu sama lain menunjukkan bahwa perusahaan mengambil pendekatan proaktif terhadap produk mereka dan terus meningkatkan produk mereka untuk konsumen.

Saya lebih cenderung merasa bahwa yang pertama adalah cara kebanyakan orang akan melihatnya dari sudut pandang konsumen, tetapi berbicara langsung dengan mereka akan (jelas) menjadi pilihan terbaik, tetapi juga akan mengangkat masalah di dalam basis pelanggan sehingga mereka dapat awalnya tidak menyadari.


Jadi bottomline, haruskah kita mencoba untuk hanya menambal pelanggan yang benar-benar membutuhkannya, dan yang lain di kemudian hari dalam 'jumlah besar' untuk meningkatkan citra kita?
Mixxiphoid

5
Menambal untuk masing-masing pelanggan terdengar seperti sakit kepala, terutama jika ada basis pelanggan yang besar. Meluncurkan tambalan pada jadwal reguler (bulanan, dua bulanan, dll.) Dan mempromosikan tambalan kepada pelanggan bisa menjadi cara yang baik untuk meningkatkan minat pada "apa yang akan terjadi selanjutnya" dari produk Anda, serta mengatasi masalah tersebut. yang sedang disetrika. Tentu saja, dokumentasi dan pemberitahuan yang tepat sangat penting untuk berkomunikasi dengan pengguna akhir dengan catatan tempel.
Jack

Itu sangat menjelaskan bagi saya. Sepertinya kita harus berupaya menggunakan tambalan untuk meningkatkan citra kita. Sampai sekarang saya yakin itu tidak mungkin. Selalu melihat tambalan sebagai kejahatan yang perlu.
Mixxiphoid

tergantung kapan siklus rilis juga. Jika tambalan berdekatan pada hari-hari pertama setelah rilis, itu memberikan kesan berbeda dari ketika mereka (masih) berdekatan beberapa bulan kemudian.
jwenting

7

Semakin banyak perusahaan mengikuti jejak Chrome dan memiliki semakin banyak pelanggan yang dirilis.

Prasyarat untuk menerapkan siklus rilis singkat adalah peningkatan tanpa rasa sakit - di chrome, misalnya, peningkatan dilakukan tanpa campur tangan pengguna sama sekali saat memulai aplikasi, dan jika pengguna tetap menjalankan aplikasinya, ia menerima bendera kecil menasihatinya untuk me-restart aplikasi pada waktu yang tepat, dan aplikasi kemudian berusaha untuk mengembalikannya ke keadaan sebelumnya setelah restart.

Metode ini membuat pelanggan senang, karena ia tidak perlu mengetahui setiap pembaruan, dan karena rilis fitur sering datang, rilis perbaikan bug akan disambut sama baiknya.

Jika, di sisi lain, tambalan muncul setelah mencolok bug penghenti acara, dan mereka datang dalam kelompok, karena yang sebelumnya gagal untuk memperbaiki bug, atau menciptakan bug yang lebih besar - yakinlah pelanggan Anda akan menciumnya. Ini jelas akan berdampak buruk pada reputasi profesional vendor, dan menurunkan standar perangkat lunak yang dirasakan vendor. Pengiriman berkelanjutan sangat bergantung pada pengujian unit yang efektif dan pengujian integrasi untuk menjamin keberhasilannya.

Mengenai tidak berbicara dengan pelanggan Anda untuk 'membiarkan anjing tidur berbaring', saya percaya ini adalah strategi yang salah - pelanggan tidak buta, dan mereka bukan orang bodoh. Saya percaya bahwa komunikasi yang baik dengan pelanggan Anda hanya dapat meyakinkan mereka bahwa mereka adalah prioritas Anda, dan bahwa Anda menerima kritik mereka. Jika Anda telah mengirimkan rilis buruk beberapa kali, dan Anda tidak mendengar mereka mengeluh - Anda pasti khawatir - bukan karena mereka tidak memperhatikan, lebih mungkin mereka hanya sibuk mencari pengganti untuk Anda ...


2
+1, sebagai pelanggan perangkat lunak yang sering, saya ingin orang-orang dengan pembaruan yang sering dan cara yang baik untuk menyebarkannya. Produk yang mandek adalah bendera merah asli di sini - setidaknya itu berarti vendor tidak berinvestasi dalam produk tersebut. Atau berinvestasi dalam vNEXT yang mereka ingin Anda bayar lagi.
Wyatt Barnett

Apa yang saya pahami dari paragraf terakhir Anda adalah bahwa kita harus selalu jujur ​​dan transparan dalam komunikasi kami terhadap pelanggan. Apakah ada situasi yang kita seharusnya (belum) memberi tahu pelanggan tentang hal-hal tertentu?
Mixxiphoid

1
Tentu saja, bersikap jujur ​​kepada pelanggan tidak berarti membiarkan garis itu terbuka ketika Anda mengadakan pertemuan panik untuk mengurangi bencana yang baru saja ditemukan. Anda harus mengomunikasikan informasi setelah menilai situasi, memiliki strategi untuk memperbaikinya, dan dapat dengan jujur ​​mengatakan bahwa semuanya terkendali. Anda mungkin mendapati diri Anda membumbui kebenaran, tetapi kebohongan yang jujur ​​memiliki cara menghantui Anda nanti ...
Uri Agassi

2

Tambalan khusus untuk pelanggan yang mendeteksi masalah jelas perlu keluar sesegera mungkin.

Saya telah melihat perangkat lunak di perusahaan-perusahaan besar kemudian mengambil pendekatan bahwa pelanggan lain akan mendapatkan tambalan itu sebagai paket layanan pada interval yang dijadwalkan secara teratur. Biasanya karena tambalan perlu upaya untuk menginstal dan menguji di lingkungan pelanggan, tetapi dalam kasus Anda itu hanya dapat digunakan untuk mengurangi kemungkinan dampak dari efek yang Anda khawatirkan.

Saya juga melihat orang menganjurkan memasang tambalan di repositori atau di situs web tempat pelanggan dapat mengunduh dan menginstal yang mereka inginkan. Ini dapat menimbulkan masalah dengan mengetahui tambalan apa yang dimiliki pelanggan, jadi ketika mereka memanggil masalah Anda harus menentukan dengan tepat kode apa yang mereka jalankan, tetapi dengan hati-hati yang dapat dilacak. Anda kemudian dapat memaksa orang untuk meng-upgrade ke salah satu 'paket' yang lebih besar ketika satu dirilis yang mengikat banyak tambalan.

Pengecualiannya adalah patch keamanan. Sebuah perusahaan perangkat lunak besar yang berbasis di Washington diketahui masuk ke dalam air panas dengan menunggu hari Kamis ketiga bulan itu sebelum merilis tambalan keamanan penting dan informasi tentang peretasan telah bocor dan memaksa tangan mereka lebih awal untuk mempermalukan yang lebih besar.

Google chrome mengatasi masalah dengan memperbarui otomatis sangat sering, mereka juga mengharuskan Anda untuk siklus program (restart chrome, atau dalam kasus Anda keluar). Mereka sekarang telah melakukan praktik normal untuk browser dan orang-orang bahkan tidak memikirkannya lagi. Tetapi tidak semua orang bisa menjadi Google.

Aplikasi SaaS mengatasi seluruh masalah dengan melakukan pembaruan di latar belakang.

Namun, yang terpenting, kecuali Anda melakukan integrasi terus-menerus atau memperbarui dengan fitur yang diminta oleh pengguna baru sangat sering, maka saya pikir kami masih berada di masa ketika orang-orang berharap Anda telah melakukan sejumlah pengujian yang layak sebelum rilis. Jika Anda merasa malu untuk bertemu dengan pelanggan Anda dan berbicara tentang frekuensi perbaikan bug, Anda mungkin tidak melakukan pengujian yang cukup. Apakah Anda melepaskan seberapa besar risiko yang Anda ambil sebelum merilis kode. Ada argumen untuk merilis kode kereta paling awal asalkan Anda tahu apa itu, tapi saya pikir Anda perlu memiliki pemahaman yang baik tentang kualitas yang Anda ketahui, yang berarti memahami dan tetap mengendalikan waktu Anda untuk mengetahui kualitas.


+1, itulah titik kunci - semakin cepat Anda dapat memperbaiki bug (dan menyebarkan), semakin baik - selama pengguna / pelanggan tidak memiliki upaya tambahan dengan penyebaran. Ketika pelanggan harus menggunakan secara manual, atau pembaruan hanya akan mengganggu alur kerjanya, penting untuk menemukan frekuensi yang tepat untuk penempatan. Situs-situs seperti Facebook akan menyebarkan beberapa tambalan sehari dan kebanyakan orang bahkan tidak akan menyadarinya.
Doc Brown

jadi saya kira kita beruntung pada bagian itu. Pembaruan kami membebani kami (di samping stres dan coding dan semuanya) hanya 1 atau 2 jam. Membutuhkan pelanggan 1 menit untuk kembali bekerja. Saya akan melihat pendekatan 'paket layanan', ini mungkin memang berguna bagi mereka yang tidak membutuhkan tambalan secara langsung.
Mixxiphoid

Menemukan referensi ini untuk Facebook: blogs.wsj.com/cio/2013/04/17/… , jadi sepertinya ada dua rilis, bukan beberapa, per hari. Masih mengesankan, kurasa.
Doc Brown

Saya 'mendengar' kode push amazon itu setiap 17 detik. Tapi saya memasukkannya ke dalam komentar karena saya tidak ingat siapa yang memberi tahu saya dan google tidak menunjukkannya. :-)
Encaitar

@Encaitar: Benar, arsitektur Amazon memiliki ratusan layanan yang saling berinteraksi. Jadi saya tidak terkejut jika mereka mendorong sesuatu dengan sangat sering, tetapi saya sangat ragu bahwa setiap dorongan secara langsung mempengaruhi lebih dari satu komponen. Apa yang Anda lihat sebagai satu situs web tidak harus memiliki versi keseluruhan. Ini lebih seperti mengatakan jaringan jalan kota diperbarui setiap 17 detik karena kru Anda melukis total 5 ribu baris baru setiap hari :-)
Steve Jessop
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.