Müşterilerden gelen “Güncellemeden beri…” sorularına nasıl yanıt veriyorsunuz? [kapalı]

Güncellemeden beri insanlar "X, Y ve Z güncellemelerinin yavaş, kötü ve çöktüğünden beri"

Bu, güncellemelerin başlangıcından beri oldu.

İnsanlar ne bekliyor? Gama betadan sonra gelir ve gama testi her zaman kullanıcılarımızı The Incredible Hulks'a dönüştürür ...

Belki bunu bir istemciden hiç duymadınız, belki de kolej veya suçu 5 veya 6'dan fazla erkeğe yayabilen bir FLOSS Dev'siniz, belki kodunuzu birim olarak test edersiniz, belki de bu ilginç durumda değilsinizdir. müşterilerin sizi tam olarak günün tam saatini talep ettiklerinde, bugünkü yamayı yayınlayacaksınız (bunu Microsoft'a yapmak isterim) ya da belki de benim gibi yeni bir sevkıyat yapan üzgün bir bisküvi oğlusunuz güncelleme ve eve gitti ve yarın işe geri dönmeyi hayal ediyor.

Her neyse, benden daha akıllı olacaksın. "Yazılımınızı daha da kötüleştirdiğiniz için kötü bir programcı olmalısınız" çerçevesindeki eleştiriyi nasıl değerlendiriyorsunuz?

Her konuşlandırışınızda bu gerçekleşirse, geliştirme sürecinizde ciddi bir kusur olabilir. Sorunlara neden olan birkaç şeyden şüphelenirim.

1. Üretim ile aynı boyutta (kabaca) bir veritabanı geliştiriyor musunuz? Değilse, her zaman bu sorunlara sahip olursunuz çünkü küçük veri kümeleriyle iyi olan sorgular genellikle büyük olan köpeklerdir.
2. KG'de test yüklüyor musunuz? Bir kullanıcı testinde işe yarayan şey, aynı anda bir şeyler yapmaya çalışan 1000 kullanıcıyla işlerin nasıl tepki vereceğinden çok farklıdır.
3. Kullanıcının algısının yanlış olduğunu mu düşünüyorsunuz ve onlara şikayet etmek için aptalmış gibi mi davranıyorsunuz? Eğer öyleyse, tutumunuz onları azaltmayan daha fazla şikayete neden oluyor.
4. İyi bir test işi mi yapıyorsunuz? Değişiklikten etkilenip etkilenmediğini görmek için regresyon testi özelliklerini değiştirmediniz mi? Eşyalara çarpana kadar ne kadar sürdüğü umurunda mı?
5. Konuşlandırırken kullanıcılar için iyi bir zamanın ne olduğuna dikkat ediyor musunuz, yoksa günlük bordro çalıştığında muhasebe sisteminde bir değişiklik yapmakta ve kullanıcıların yavaşlamaya neden kızgın olduklarını merak ediyorsunuz?
6. Dev ve prod arasında çevresel farklarınız var mı? Bazen işletim sistemlerindeki veya veritabanı sürümlerindeki sinir bozucu farklılıklar da bu gibi sorunlara neden olabilir. Genellikle prod, bazı ekipman aynı işletim sistemi, dat ile aynı veri tabanına mümkün olduğunca yakın olan bir evreleme ortamına sahip olmak iyi bir fikirdir. Bu, dağıtımınızı test etmek için kullanılır. Önce bu sunucuda çalıştırın ve bazı kullanıcıların veya test cihazlarının ona gidip bazı testlerden geçmesini sağlayın.
7. Dağıtım işleminiz ne kadar iyi, sık sık adımları kaçırıyor musunuz? Konuşlandırdığınız dalda hangi kodun gittiği açık olduğu için geliştirici dışında biri tarafından çalıştırılabilir mi? Bir konfigürasyon yönetim ekibimiz olduğunda kod dağıtımında çok daha iyi bir hale geldik ve hiç kimse "oopsie" değişiklikleri yaparak prod ve babysit oturmak hakkına sahip değildi. Yapınızı otomatikleştirmek çok yardımcı olabilir. Hiç kimse QA'ya gitmeli ve önce evreleme yapmalı ve herhangi bir zorlama sorunu çözülmelidir. Komut dosyası veritabanı değişiklikleri de anahtardır. Komut dosyalarında ve kaynak kontrolünde olmalılar, bu yüzden derleme işlemi bunları hatırlamak zorunda kalmadan onları alabilir, oh evet, B Sütunundaki uzunluğu 50'den 241'e değiştirmemiz gerekiyor.

"Yazılımınızı daha da kötüleştirdiğiniz için kötü bir programcı olmalısınız" çerçevesindeki eleştiriyi nasıl değerlendiriyorsunuz?

Ancak bu tür eleştiriler çoğunlukla haklıdır. Yeni bir sürüm öncekinden daha kötü olmamalı, ama bildiğimiz gibi, gerçekte sık sık öyle ve bizim yaptığımız için bizim hatamız.

Hata yapmak insandır ve kimseyi "kötü bir programcı" yapmaz, bu yüzden eleştiriyi kişisel olarak almayın (meslektaşımdan hiçbir zaman profesyonel bir eleştiriyi ciddiye almam). Sorunu bildirdiği için müşteriye teşekkür edin ve mümkün olan en kısa sürede düzeltin. İyi bir programcı olarak işiniz.

İş yerinde doğrudan müşterilerle çok fazla etkileşim kurmuyoruz, bu yüzden buna kişisel proje çalışmasından cevap vermeliyim. İnsanların kendi oyunlarını oluşturmak için kullanabileceği bir oyun motoru yazıyorum. Hala alfa öncesi, ama birkaç ilgilenen kullanıcı var ve bazen hata alıyorum.

Bir kullanıcıdan böyle bir rapor aldığımda, kişisel dokunuşu kullanmaya çalışıyorum. Hataları tanıtmak istemedim ve motorumla iyi bir deneyim yaşamasını istiyorum, bu yüzden onlara inandırmam gerekiyor. İlk olarak, konuşabilmemiz için bir IM tanıtıcısı alın. Kullanıcıya projelerini soracağım ve bir kopyasını almaya çalışacağım. Bu üremeyi çok daha kolay hale getirir. Aksaklık meydana geldiğinde onlara ne yaptıklarını sorun. Bu arada, motoru hata ayıklayıcıda açtım ve konuşurken konuya giriyorum.

Bir istisna varsa, genellikle oldukça basittir. Sorunu yeniden oluşturun ve hata ayıklayıcı, tam bir yığın izlemesiyle sizi doğrudan hata konumuna götürür ve neler olduğu açıktır. Yavaş performans veya yanlış davranışsa, biraz daha uzun sürebilir. Ancak çoğu durumda ilk 20 dakika içinde hazır bir düzeltmeye sahip olabilirim, üstler. Fermuarlı ve test etmek için onlara gönderiyorum. "Tamam, sanırım anladım. Bunun sonunda işe yarayıp yaramadığını görüyor musun?"

Yanıt neredeyse evrensel olarak şaşkınlık ve şükranların bir karışımıdır, çünkü çoğu geliştirici (okuma: yazılım şirketleri) hataları düzeltmez ve bu kadar hızlı yeniden yayınlamaz. Ve sonra, eğer gerçekten sabitse, potansiyel bir eleştirmeni bir hayrana dönüştürdüm. Gerçekten iyi bir teknik; Keşke daha fazla geliştiricinin benimsemesini isterdim.

Ben şahsen problemi olumlu alıyorum. Her zaman çok sayıda müşteriyle etkileşimde bulunuyorum ve hala kod yazıyorum.

Yeni bir sürüm indirip bana böyle bir şey söylediklerinde her zaman böyle bir şey söylerim:

Bu hatayı bana bildirdiğiniz için teşekkürler. Belki de eklediğimiz tüm yeni özellikler birlikte tanıtıldı. En kısa sürede düzeltiriz.

Aslında, müşteri gerçek patronunuzdur. Sizinle deneyiminiz kötü ise, sizin için de kötüdür.

Haklı olmasa bile, şirketin bir parçası olarak, bu fırsatı kullanmalısınız:

• ürün üzerinde yapabileceğiniz olası iyileştirmeleri toplayarak ondan öğrenin.
• Mutsuz bir müşteriyi mutlu bir müşteriye dönüştürün, o kadar mutlu ki etrafınızda konuşacak (patronunuz dahil)
• ne yaptığınla gurur duy

Ayrıntılar, Ayrıntılar, Ayrıntılar. Ne yaptıklarını ve ne zaman yaptıklarını soruyorum. Bir şey olabilir ya da sadece Justin Beaber videosunun youtube'da yayınlanmış olması olabilir. Günlük dosyaları her iki durumda da arkadaşınızdır.

Ben de fark ettiler tarihleri ​​isterim. Bazen özellikle kurumsal mağazalarda kullanıcılar bir sürümün ne zaman çıktığını bilmiyorlar, sadece bir şeyin tamamlanmasının uzun zaman aldığını biliyorlar ve şimdi bundan şikayet ediyorlar.

İş Gölge. Bunu yeterince vurgulayamıyorum. Yakınlarda kullanıcılara sahip olacak kadar şanslıysanız, zaman zaman çalışmalarını izleyin. Sık sık göze çarpan sorunları görmezden gelirler ve asla rapor etmezler. Genellikle sadece bir şeyin yeni olduğunu bildiklerinde veya başlangıçta bir sorun olduğunu fark ettiklerinde şikayet ederler.

Adım 1, bunun (güncelleme diğer şeyleri kırar) normal olmadığının bir zihniyetten gelmenizdir. Güncellemeniz uygulamanın diğer bölümlerini kırmamalı veya yavaşlatmamalıdır. Tamam değil, beklenen değil ve onlar şikayet edince kullanıcının hatası değil. Bunu önlemek için mümkün olduğunca çok test yapmalısınız. Bu olduğunda, bir sorunun ve acil bir sorunun var.

2. Adım, ne yaptığınızı bilmeniz gerektiğidir. Kaynak kontrol sisteminiz size veya bir tür iş takip sistemine yardımcı olabilir, ancak bu şikayetlerden birini aldığınızda dakika diyebilmelisiniz "tamam, bu tabloya bir sütun ekledim, hesaplamak için bu ızgarayı değiştirdim yeni vergiler, bu iki yeni raporu ekledi ... "vb.

Adım 3, mükemmel sorunları ve çökmeleri hızlı bir şekilde bulma deneyimine sahip olmanız gerektiğidir, bu nedenle bunlara ne tür şeylerin neden olabileceğini bilirsiniz ve soruna hemen ulaşabilirsiniz. Bu şey yayına başladı ve sorunu çabucak bulmalı ve bir yama almalısın. Raporun değiştirilmesi, uygulamanın raporu kullanmayan bir kısmını yavaşlatamaz. Şimdi acil durum modundasınız ve uygulamanın nerede başka bir kısmını kırmadan - hatanın nerede olduğunu ve bununla ilgili ne yapacağınızı anlamanız gerekiyor.

Adım 4 bu sefaletlerin her biri için, bir dahaki sefere test edeceğiniz bir ders almalısınız. Belirli yapılara itiraz eden “o adam” olacaksınız çünkü “10.000 kayıt olduğunda korkunç olacak”.

"Bu normal" cephesinde biraz daha. Harici bir müşteri için çevik bir proje yürütüyorum (diğer tüm şeylerin yanı sıra). İki ya da üç yıldır kabaca 6 haftada bir yayın yapıyoruz. Ve evet, sürümün dakika olarak planlanması. Dün sabah 8'de bir tane yaptık. Ve kabaca her 4. veya 5. sürümde (yılda bir veya iki kez, başka bir deyişle) bir şey canlı olarak kırılıyor ve harekete geçiyoruz ve olabildiğince hızlı hale getiriyoruz. Her ne kadar sürümden önce test edip test edip test etsek de. Sonra onlara ne olduğunu söyleriz. "Haziran konuşlandırmasında bu alanın boş olmasına izin veren küçük bir hata vardı, ancak o zaman değeri kullanmadığımız için hiçbir zaman fark etmedik. Sonra alanı kullanmaya başladığımızda bu konuşlandırmada, boş olanlar gördüğünüz hata mesajını. hatayı düzeltmemeleri, kötü kayıtlara değerler koymaları ve artık patlamamasını onaylamaları için hatayı düzelttik. Özür dileriz. "Veya" Serbest bırakılmadan sadece iki gün önce yalvardığınız acil durum değişikliğinin, düşünmediğimiz ve test etmediğimiz sonuçları oldu. Neden acil durum değişikliklerine karşı koyduğumuzu hatırlıyor musunuz? "Güncellemeyle daha da kötüleştirdiğim için kötü bir programcı olmayabilirim, ama kesinlikle kötü bir şey yaptım. Güncellemeyle daha da kötüleştirdiği için kötü bir programcı olmayabilirim, ama kesinlikle kötü bir şey yaptım. Ve bunu düzeltmem gerek. Güncellemeyle daha da kötüleştirdiği için kötü bir programcı olmayabilirim, ama kesinlikle kötü bir şey yaptım. Ve bunu düzeltmem gerek.

Sadece başka bir yönü kapsayacak şekilde:

Bu olmadığı ortaya çıktığında bunu talep eden müşterilerin bir listesini tutarız. Yazılım buggy, genellikle çok buggy olsa da, müşterilerimizin birçoğu hemen dikkat çekmek için "güncelleme ile başladı" iddia edecek, bu sorunu arayan belirtilen özellik için deltalar yürürken herkesin zaman israf biter farkında değil. Müşteri doğruyu söylüyorsa, hızlı bir şekilde bulunma eğilimindedir. Müşteri yanlış listede çok fazla ise, zaman kaybetmekten hoşlanmadığımız için rahatsız etmiyoruz.

Bize bir yalan söylemenin süreci hızlandıracağını düşünmek için ne tür bir zihniyetin gerekli olduğunu düşünemiyorum. Bu insanlar ya da doktorlarla birlikte çalışırlar ve insanlar doktorlara yalan söylediğinde ne olduğunu tam olarak bilmelidirler. Aynı prensip geçerlidir.