Yamalar müşteri için kötü bir işaret mi? [kapalı]


14

Ofiste, yamaları çok sık yayınladığımız uzun bir dönemden yeni çıktık. Bu sürenin sonuna doğru haftada ortalama üç yama yapıyorduk.

Bunun geliştiriciler için çok rahatsız edici olmasının yanı sıra, müşterinin bu konuda ne düşüneceğini merak ediyordum. Soruyu kendim sordum ve o kadar sık ​​güncellenen yazılımı hiç tanımadığım sonucuna vardım. Ancak, en yakın gelen durumda, yamalar oldukça hızlı bir şekilde uygulandığından gerçekten umrumda değil.

Bu yamaları alan müşteriler birbirlerinden çok farklıdır. Bazıları, diğerlerinin gerçekten umursamadığı yamayı gerçekten bekliyordu, ancak hepsi aynı yamaları aldı. Müşteri yazılımını güncelleme süresi 30 saniyeden azdır, bu nedenle zamanla ilgili herhangi bir sorun beklemiyorum. Ancak çıkış yapmaları gerekir.

Yani sorum daha ayrıntılı: Güncellemelerin alınması sık sık alıcıya 'olumsuz' bir mesaj veriyor mu?

Tabii ki, müşterilere sorabilirim, ama o pozisyonda değilim ve 'Uyuyan köpekleri uyandırmak' da istemiyorum.

Not: Sorumu geliştirmek için yapabileceğim bir şey varsa, lütfen bir yorum bırakın.


@ downvoter, açıklamak ister misin?
Mixxiphoid

6
Müşteri algısı konusunda endişeleriniz varsa, bunları "yamalar" yerine "güncellemeler" olarak tanımlayabilirsiniz? :)
Chris Taylor

Bu doğrudan bir yanıt olmasa da, yama dağıtımını mümkün olduğunca müdahaleci olmayan ve otomatik tutabiliyorsanız (ör. Güncellemeleri arka planda indirin, boştayken uygulamak için çalışan bir güncelleme hizmetiniz olsun), son kullanıcı kaygısını güncellemeleri açık hale getirmek. Örneğin: Geçen ay içinde kaç Google Chrome güncellemesi aldınız? (Yanıt: çok ) Chrome için günde 5 yama yayınlayabilirler ve kimse kaşlarını kaldırmazdı. Otomatik Windows güncellemeleri (etkinleştirildiğinde) başka bir örnektir.
Jason C

"Müşteri yazılımını güncelleme süresi 30 saniyeden az, bu yüzden zamanla ilgili herhangi bir sorun beklemiyorum. Yine de çıkış yapmaları gerekiyor." Müşteri yamayı kendileri test etmeye ne dersiniz? Ne tür bir yazılımla çalıştığınızı bilmiyorum, ancak herkes için kritik öneme sahip bir yerdeyse, bir üretim ortamında canlı yayına geçmeden önce bir güncellemeyi test etmek isteyeceklerdir. Düzeltme ekinin kurulumu hızlı ve kolay olsa da, bu test müşteri için çok fazla zaman ve çaba gerektirecektir.
CVN

@ MichaelKjörling Sorun, o dönemde görev kritik özelliklerinin başarısız olmasıydı, bu yüzden önce üretim ortamının veya test ortamının güncellenip güncellenmediğinin önemi yoktu. Sadece ASAP çalışmak gerekiyordu.
Mixxiphoid

Yanıtlar:


24

Bilgi işlemdeki birçok şeyde olduğu gibi, duruma göre değişir. Yamalar, yeni özellikler veya iyileştirmeler için müşteri taleplerine bir yanıtsa şirketiniz duyarlı olarak görülecektir. Öte yandan, yamalarınız hata raporlarına bir yanıtsa, şirketiniz yetersiz olarak görülecektir.

resim açıklamasını buraya girin

Müşterilerinizdeki yazılımları test etmek, herkes ne derse desin, hataları tespit etmenin en pahalı yoludur. Bu yanlış bir ekonomi; elde ettiğinizi düşündüğünüz ücretsiz emek, müşteri hizmetleri çabasıyla, yazılım geliştirme yaşam döngüsünü bozarak ve müşteri güvenini kaybetmekten daha fazla dengeleniyor.


3
Belki de bu farklı bir soru olmalı, ama yine de: Müşterilerimiz tarafından test ettiğimizi biliyorduk, ancak o zaman durduramadık, bir döngüde sıkışıp kaldık. Dışarı çıkmak için ne yapabiliriz?
Mixxiphoid

3
Robert, bu diyagramı daha önce defalarca gördüm. Yazılım geliştirme saf bir şelale modelini takip ettiğinde muhtemelen doğruydu, ancak yazılım küçük döngülerde geliştirilebildiğinden ve dağıtılabildiğinden, daha da yanlışlaştı. Kesin olmak gerekirse - az miktarda hata ve yazılım için eğilim hala doğrudur, birçok hata için kesinlikle yanlıştır.
Doc Brown

2
@DocBrown: Grafik hala doğru. Daha kısa geliştirme döngüleri, grafik ile tutarlı olan döngü başına daha az maliyet anlamına gelir. Ancak bu, sürecin bir parçası olduğu konusunda net bir anlayış ve anlaşma olmadığı sürece, yazılımınızı müşterileriniz üzerinde alfa test etmeniz gerektiği anlamına gelmez.
Robert Harvey

Eh, kusurların maliyeti daha erken böcek bulunursa azalır ve sabit. Ve bir hatanın bulunma şansı, yazılımınızı kapıdan ne kadar erken çıkarırsanız önemli ölçüde artar. Bu, test edilmemiş yazılımı elbette üretime itmesi gerektiği anlamına gelmez. Örneğin, bu makaleyi öneririm agileelements.wordpress.com/2008/04/22/cost-of-software-defects
Doc Brown

1
Tek yapmanız gereken, eğrinin sayıları veya şekli sadece vahşi eşek tahminleri olsa bile, prensibin kendisinin sağlam olduğunu görmek için biraz kendi kendine yansımadır. Programlama alanında da bir ismimiz var: Hızlı Başarısız.
Robert Harvey

10

Birkaç yamayı yakın bir yerde bırakmak gibi hissediyorum şirket kötü yansıtıyor. Her zaman yeterince iyice test etmediklerini, geliştiricilerin yetersiz olduğunu ya da yönetimin ne yaptıklarını bilmediğini hissettiriyor.

Bununla birlikte, tokenin diğer tarafı birbirine yakın birkaç yama yayınlamanın şirketin ürünlerine proaktif bir yaklaşım gösterdiğini ve tüketici için ürünlerini geliştirmeye devam ettiğini gösteriyor.

Birincisinin bir tüketicinin bakış açısından ona en çok bakacağı yol olduğunu hissetmeye daha meyilliyim, ancak doğrudan onlarla konuşmak (açıkçası) en iyi seçim olacaktır, ancak aynı zamanda müşteri tabanındaki sorunu da gündeme getirecektir. başlangıçta farkında değildi.


Sonuç olarak, resmimizi geliştirmek için sadece gerçekten ihtiyacı olan müşterileri ve daha sonra diğerlerini 'toplu' olarak yamalamaya mı çalışmalıyız?
Mixxiphoid

5
Bireysel müşteriler için yama yapmak, özellikle büyük bir müşteri tabanı varsa, bir baş ağrısı olabilir. Yamaları düzenli bir programda (aylık, iki ayda bir vb.) Yayınlamak ve yamaları müşterilere tanıtmak, ürününüzden "sırada ne olacak" konusundaki ilgiyi artırmak ve sorunları çözmek için iyi bir yol olabilir. ütüleniyor. Tabii ki, son kullanıcı ile yama notlarıyla iletişim için uygun dokümantasyon ve bildirim çok önemlidir.
Jack

Bu gerçekten benim için çok netleşiyor. Görünüşümüzü geliştirmek için yamalarımızı kullanmak için biraz çaba harcamalıyız gibi görünüyor. Şimdiye kadar bunun mümkün olmadığına ikna olmuştum. Yamaları her zaman gerekli bir kötülük olarak gördüm.
Mixxiphoid

serbest bırakma döngüsünde ne zaman olduğuna bağlıdır. Yamalar yayınlandıktan sonraki ilk günlerde birbirine yakınsa, bu birkaç ay sonra (hala) birbirine yakın olduklarından farklı bir izlenim verir.
Mart'ta jwenting

7

Giderek daha fazla şirket Chrome'un izinden gidiyor ve giderek daha sık müşteri sürümüne sahip oluyor.

Kısa sürüm döngülerinin uygulanması için ön koşul ağrısız bir yükseltmedir - kromda, örneğin yükseltme, uygulama başlatıldığında kullanıcı müdahalesi olmadan yapılır ve kullanıcı uygulamasını her zaman açık tutarsa, küçük bir bayrak alır başvuruyu uygun zamanda yeniden başlatmasını tavsiye eder ve uygulama daha sonra yeniden başlattıktan sonra önceki durumuna döndürmek için çaba gösterir.

Bu yöntem, her güncellemenin farkında olması gerekmediği için müşteriyi mutlu eder ve özellik sürümleri sık sık geldiği için hata düzeltme sürümleri de hoş karşılanır.

Öte yandan, yamalar şov durdurucu hatalardan sonra gelirse ve daha önce olanlar hatayı düzeltemediğinden veya daha büyük bir hata yarattığından kümeler halinde gelirse, müşterilerinizin koklayacağından emin olabilirsiniz. Bu kesinlikle satıcının profesyonel itibarına zayıf bir şekilde yansır ve satıcının algılanan yazılım standartlarını düşürür. Sürekli teslimat , başarısını garanti etmek için büyük ölçüde etkili birim testi ve entegrasyon testine dayanır.

Müşterilerinizle 'uyuyan köpeklerin yatmasına izin vermek' için konuşmama konusunda, bunun yanlış bir strateji olduğuna inanıyorum - müşteriler kör değil ve aptal değiller. Müşterilerinizle iyi iletişim kurmanın, onlara yalnızca sizin önceliğiniz olduğunu ve onların eleştirilerine açık olduğunuzu güvence altına alabileceğine inanıyorum. Birkaç kez kötü bültenleri teslim ettiyseniz ve şikayet ettiklerini duymuyorsanız - kesinlikle endişelenmelisiniz - fark etmedikleri değil, sadece sizin için bir yedek bulmakla meşgul olmaları daha olasıdır ...


2
+1, yazılımın sık müşterisi olarak, sık güncellemeleri ve bunları dağıtmak için iyi yolları olan erkekleri istiyorum. Durgun ürünler burada gerçek kırmızı bayraktır - en azından satıcının ürüne yatırım yapmadığı anlamına gelir. Ya da vNEXT'e yatırım yaparak tekrar tekrar ödeme yapmanızı isterler.
Wyatt Barnett

Son paragrafınızdan anladığım, müşteriyle iletişimimizde her zaman dürüst ve şeffaf olmamız gerektiğidir. Müşteriyi belirli şeyler hakkında (henüz) bilgilendirmememiz gereken durumlar var mı?
Mixxiphoid

1
Tabii ki, müşteriyle dürüst olmak, az önce bulunan bir felaketi azaltmak için panik toplantısı düzenlerken çizgiyi açık bırakmak anlamına gelmez. Bilgiyi iletmelidir sonra size durumu değerlendirdik bunu düzeltmek için bir strateji, ve dürüstçe her şeyin kontrol altında olduğunu söyleyebiliriz. Kendinizi gerçeği süslerken bulabilirsiniz , ancak düpedüz yalanların daha sonra size musallat olmanın bir yolu var ...
Uri Agassi

2

Bir sorun tespit eden müşteriler için özel yamalar, en kısa zamanda dışarı çıkması gerekecektir.

Büyük firmalarda yazılım gördüm ve diğer müşterilerin bu yamaları düzenli olarak belirli aralıklarla bir hizmet paketi olarak alacağı yaklaşımını benimsiyorum. Normalde yamalar müşteri ortamına kurmak ve test etmek için biraz çaba harcadığından, ancak sizin durumunuzda, endişe duyduğunuz etkinin olası etkisini azaltmak için kullanılabilir.

İnsanların depolarda ya da müşterilerin istediklerini indirip yükleyebilecekleri web sitelerinde yama eklemeyi savunduğunu gördüm. Bu, müşterilerin hangi yamalara sahip olduklarını bilmede sorunlar yaratabilir, bu nedenle bir sorunla aradıklarında tam olarak hangi kodu çalıştırdıklarını belirlemeniz gerekir, ancak izlenebilir. Daha sonra insanları, çok sayıda yamayı bir araya getiren daha büyük 'paketlerden' birine yükseltmeye zorlayabilirsiniz.

İstisna güvenlik yamalarıdır. Büyük bir Washington merkezli yazılım şirketinin, kritik güvenlik yamaları yayınlamadan önce ayın üçüncü Perşembe günü bekleyerek sıcak suya girdiği biliniyordu ve bilgisayar korsanlığı hakkında bilgi sızdırıldı ve ellerini daha da utanmaya zorladı.

Google Chrome, çok sık otomatik güncelleme ile sorunu çözer, siz de programı döngüye almanızı gerektirir (chrome'u yeniden başlat veya vaka oturumunuzda). Artık tarayıcılar için normal bir uygulama yaptılar ve insanlar artık bunu düşünmüyorlar. Ancak herkes Google olamaz.

SaaS uygulamaları arka planda güncellemeler yaparak tüm sorunu çözer.

Bununla birlikte, her şeyden önce, sürekli entegrasyon yapmıyorsanız veya yeni kullanıcı talep edilen özelliklerle çok sık güncelleme yapmıyorsanız, o zaman hala insanların yayınlamadan önce iyi bir test yapmayı bekledikleri bir zamanda olduğumuzu düşünüyorum. Müşterilerinizle tanışmaktan ve hata düzeltmelerinin sıklığından bahsetmek için utanırsanız, muhtemelen yeterli test yapmıyorsunuzdur. Kodu yayınlamadan önce ne kadar risk aldığınızı serbest bıraktınız mı? Bunun ne olduğunu bildiğiniz sürece çok erken buggy kodu yayınlamak için bir argüman var, ancak bence bilinen kalitenizi iyi anlamanız gerekiyor, bu da kaliteyi bilmek için zamanınızı anlamak ve kontrol altında tutmak anlamına geliyor.


+1, kilit nokta budur - bir hatayı ne kadar çabuk düzeltebilirseniz (ve konuşlandırırsanız) o kadar iyidir - kullanıcı / müşteri dağıtım için ek bir çaba göstermediği sürece. Müşterinin manuel olarak dağıtması gerektiğinde veya güncellemeler sadece iş akışını kesintiye uğratırsa, dağıtımlar için doğru frekansı bulmak önemlidir. Facebook gibi siteler günde birkaç düzeltme eki uygular ve çoğu kişi fark etmez bile.
Doc Brown

yani sanırım bu konuda şanslıyız. Güncellemelerimiz bize (stres ve kodlamanın yanı sıra) sadece 1 veya 2 saattir. İşe geri dönmesi müşteriye 1 dakikaya mal olur. 'Hizmet paketi' yaklaşımına bakacağım, bu doğrudan yamaya ihtiyaç duymayanlar için gerçekten kullanışlı olabilir.
Mixxiphoid

Facebook için bu referansı buldu: blogs.wsj.com/cio/2013/04/17/… , bu nedenle günde iki sürüm var, birkaç tane değil gibi görünüyor. Hala etkileyici, sanırım.
Doc Brown

Amazon itme kodunu 17 saniyede bir 'duydum'. Ama bir yorumda belirtiyorum çünkü bana kimin söylediğini hatırlamıyorum ve bir google bunu göstermiyor. :-)
Encaitar

@Encaitar: Doğru, Amazon mimarisinin yüzlerce etkileşimli servisi var. Bu yüzden, bir şeyi çok sık itiyorlarsa şaşırmadım, ancak her itmenin doğrudan birden fazla bileşeni etkilediğinden şüpheliyim . Tek bir web sitesi olarak gördüğünüz şeylerin genel bir sürümü olması gerekmez. Daha çok şehir yol ağının her 17 saniyede bir güncellendiğini söylemek gibi, çünkü mürettebatınız günde toplam 5 bin taze çizgide resim yapıyor :-)
Steve Jessop
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.