Müşteriyi kurum içi KG testi yapmaya teşvik etmek nasıl?

Güncelleme / Açıklama Benim istemci anlar kendi içerisinde yapılan testlere ihtiyacını ve o / onlar her zaman onlar (yani bir şey yapmak) "daha iyisini" olacak yemin ama sadece olmaz. Dış testler için bütçeleri yoktur. Sanırım bir "erken test, sık sık test, hedef makinelerin ethos'u üzerinde test nelerin aşılanabileceğini soruyorum (belirsiz bir şekilde onaylıyorum)?

Soru: kullanıcıları, üretim projelerinde "giderken test et" değil, yeni sürümlerle ilgili sorunları açıkça test etmek ve raporlamak için zaman ayırmaya nasıl teşvik edersiniz.

Arka plan: Bir grup multimedya sunum aracı yazdığım küçük bir müşterim var. Onlar güzel bir müşteri ve iyi bir ilişkimiz var. Proje devam ediyor ve ilerledikçe özellikler ekliyor.

İki sorunum var:

1. Özellik tanımı anında, genellikle telefon üzerinden, değişime, revizyona, tersine çevrilerek yapılır. (biraz Kennedy'nin "Ay'a gidip diğer şeyleri yapacağız" gibi - Ben her zaman bunun "diğer şeyler" kısmı tarafından eğlendim)

2. Neredeyse hiçbir KG testi yapılmaz.

Aşağı yukarı # 1 ile başa çıkabilirim. Bu, toplantıdan önce bir spesifikasyon bile okuyan bir müşteri değil, bir tane yazsın. Ben buna alışığım. Sorunla ilgili 2. maddem: yeni sürümleri test etmiyor veya test etmiyorlar. Yaptıkları şey onları üretim için kullanmaktır, böylece hatalar ortaya çıktığında ya bir geçici çözüm bulurlar ve bildirmezler ya da projeyle başa çıkmak için acele ederler, hata raporları belirsizdir.

Tüm bunlar hakkında birçok tartışma yaptık, ancak sadece biraz dürtebildim (örneğin, sorunları izlemek için github kullanıyoruz - çoğunlukla kullanıyorum). Kök nedenler iki yönlüdür: küçük bir danışmanlık şirketidir ve test için kaynaklara (ya da dış kaynak kullanımı için bütçeye) sahip değildirler (ya da sahip olduklarını düşünmezler). Ve kültürel: kendilerini "geliştiriciler" olarak düşünmelerine rağmen, gerçekten sadece bir multimedya yazılım paketinin kullanıcıları. (örneğin , "gerçek" geliştiricilerin ayrıntılarına obsesif nevroz ilgisinin hiçbiri yoktur ).

Bu beni beklediğiniz gibi etkiler: geri bildirim olmadan bir özelliğin tamamlandığını (bkz. # 1) veya başka sonuçlar olup olmadığını söyleyemem. Ayrıca beni biraz tembel yapıyor.

"gerçek" geliştiricilerin ayrıntılarına obsesif nevroz ilgisi yok

Önsöz : Burada kullandığınız dil türü benim için genellikle kırmızı bir bayraktır. İnsanların "gerçek" geliştiriciler veya (tek ve tek) "doğru" yol hakkında konuştuğunu duyduğumda, tünel vizyonlu kargo kült geliştiricileri düşünmeye başlıyorum .

Şimdi, kesinlikle bu geliştiricilerden biri olduğunuzu söylemiyorum (bunu iddia etmek için yeterli kanıtım yok), ama eğer öyleyseniz, bu cevaptan yararlanabilirsiniz.

Cevap

Sizin ve müşterinizin farklı şeyler için optimize ettiği anlaşılıyor. Yazılım mühendisliğinde, çoğu zaman işin ve geliştiricilerin isteklerinin zorunlu olarak sıralanması talihsiz bir gerçektir.

Yazılım geliştiricileri genellikle iyileştirmeye odaklanan tutkulu insanlardır. Yazılım performansını, geliştirme sürecini, iş süreçlerini, iletişim yöntemlerini vb. Geliştirmeyi severler. Ve bu harika. Bu şeylere odaklanmak, zanaatkârları ve zanaatkârları akılsız anahtarlıklardan ayıran şeydir.

Ancak müşteriniz yazılım ustası değil. Müşteriniz tamamen farklı önceliklere sahip bir işletmedir. Ve bazen, bu öncelikler biz yazılım zanaatkarlarına karşı saçma görünüyor ... ama bu sadece farklı şeyleri optimize ettiğimiz için.

İşletmeler genellikle pazara erken çıkış ve kısa vadeli maliyet tasarrufu gibi şeyler için optimizasyon yapmak ister. Bunu yaparken KG, Kullanıcı Deneyimi, uzun vadeli maliyet tasarrufu ve geliştiricilerin işaretlemesini sağlayan diğer şeylerden fedakarlık etmeleri gerekebilir.

Bu kötü bir şey mi? Pek değil. Tüm işletmeler için konuşamam, ancak deneyimlerime göre, müşterilerim kendi yatırım getirilerini (yatırım getirisini) artırmak için bunları yapıyor. KG, UX inceltme ve uzun vadeli planlama gibi şeyleri yapmak onlara daha düşük YG sağlar. Daha da kötüsü, birçok işletme sürdürülebilir yaklaşımların ve uzun vadeli kazançların aksine sadece kısa vadeli kazançları ödüllendiren yatırım yapılarına sahiptir.

Yani, süre olabilir müşteriniz size vakit ve onlarla ilişkinizi ıkınma olabilir için QA fikrini satmaya çalışıyorlar. En iyi durumda, fikirlerinizi denemek için istekli birine sahip olursunuz (olası değil). En kötü durumda, tüm şirketi teşvik yapılarını yeniden işlemeye ikna etmeniz gerekir, böylece KG gibi uzun vadeli yatırımlar ödüllendirilir. Her iki durumda da, başarı şansınız düşüktür.

İlginç soru, müşterinizin kendi testlerini yapıp yapmadığı değil, ödeme yaptığınız zamandır.

• Zamanınıza göre ödeme alırsanız, sorun değil.
• peşin ödeme alırsanız, sorun değil.
• Müşteri projenin "tamamlandığını" beyan ettiğinde ödeme alırsanız, büyük sorun.

Sorun, müşterinin yazılımı ne zaman kabul ettiğini ve size ödeme yapacağını nasıl bilebilirsiniz. Müşteri, belirsiz bir şekilde tanımlanmış yeni taleplerle projeyi sürekli olarak değiştirdiğinde bu açıkça işe yaramaz. Bu, ödeme gününün her zaman ertelendiği ve her istekle daha olası olmadığı anlamına gelirse, bu sizin için savunulamaz hale gelir.

Tüm özellikleri dikkatle belirten ve müşterinin bu özellikleri hangi koşullarda kabul edeceğini tanımlayan sabit bir sözleşme açıkça çok katıdır, ancak projeyi önceden planlamanıza izin verir (ayrıca bir sonraki proje). Ayrıca, spesifikasyona uygun olarak teslim ettiğiniz yazılım için paranızı alacağınızı garanti eder. Böyle bir senaryoda, müşterinin tek sorumluluğu sözleşme tanımlama aşamasında ve sonunda kabul testidir .

Bir müşteri tarafından yapılan bu tür kabul testleri diğer test türlerinden ayrıdır:

• birim testleri
• sistem entegrasyon testleri
• kullanılabilirlik testleri
• yük testleri
• yayın öncesi testler

Mümkün olduğunca, herhangi bir utançtan kaçınmak için işlevselliği sunmadan önce kabul testlerini bekler ve bunları kendiniz yaparsınız. Kabul testlerinin yanı sıra ( yazılım kalitesini değil, sadece sözleşme yerine getirilmesini ölçen ), tüm Kalite Güvencesi sizin sorumluluğunuzdadır. Özellikle, müşterinizin mutlaka bir KG zihniyeti, gerekli teknik altyapısı veya KG yapmak için sözleşme yükümlülüğü yoktur. Ayrıca, müşteriye oldukça profesyonelce dış kaynak hata avı bulmak.

Bu, hataların olmayacağı anlamına gelmez. Müşterinizle proje tabanlı bir ilişkiniz olduğunu varsayarsak, nazik olmak ve hızlı bir şekilde düzeltme sağlamak ve mevcut sürümü ihtiyaçları için yeterli olarak kabul ettiklerini açıklamak istersiniz - büyük değişiklikler yeni bir sözleşme gerektirir. Devam eden bir destek sözleşmeniz varsa, elbette kararlaştırdığınız hizmet düzeyine bağlı kalmanız gerekir.

Çevik bir ortamda, müşteri ihtiyaçlarına cevap vermek, sözleşmenin mektubuna bağlı kalmaktan daha değerlidir, ancak yine de ödeme almak isteyeceksiniz. Bu nedenle, birçok çevik yönelimli proje metodu, müşterinin ekibin bir parçası olabileceği noktaya kadar yakın müşteri etkileşimine değer verir. Daha sonra, gerekli noktaları açıklığa kavuşturmak için her zaman bu "ürün sahibi" ile konuşabilirsiniz. PO, değerli buldukları herhangi bir özellik üzerinde çalışmak için size zaman verme yetkisine sahip olduğundan, bu, belirsiz müşteri ihtiyaçları ile başlarken bile işe yarayabilir. Bu kadar yakın bir iletişiminiz yoksa, daha resmi bir yaklaşım izlemeniz gerekir.

• Yeni müşteri ihtiyaçlarını öğrendiğinizde, bunları gereksinimlere dönüştürmek için müşteriyle birlikte çalışın. Bu, müşterinin gerçekte istediklerini almasına yardımcı olur.
• Gereksinimler nesnel olarak ölçülebilir - ya yerine getirilir ya da getirilmez. Bu, müşteriyi sadece bu tür işlerin yarı çözümlerinden kurtarır.

• Faturalayabilmeniz için tüm müşteri talepleri yazılı olarak yapılmalıdır. Bu, onları üzerinde çalışmak istediğiniz gibi hissettiğiniz şeyler için faturalandırılmaya karşı korur - örneğin bir düğmenin farklı hizalanmasını isterken tüm arayüzü yeniden yazmak gibi.

  Şahsen veya telefon üzerinden çok fazla iletişim yapılabilir, ancak sonunda müşterinin bu gereksinimler üzerinde çalışmanızı istediğini belgelemek için bir kağıt parçası istersiniz . Basit durumlarda, bir telefon görüşmesini yeniden özetlemek ve sizden ne yapmanızı istediklerini doğrulamak için onlara bir e-posta göndermek yeterli olabilir.

Hata raporları her zaman zordur. Müşterileriniz ihtiyaçlarınızı anlayabildikleri için yardımcı olacak geliştiricilerin kendisiyse: yeniden üretmek için net adımlara sahip olmak. Güçlü bilgi elde etmenin basit bir yolu, konuşlandırılan yazılımda günlüğe kaydetmeyi etkinleştirmektir. Veri gizliliği sorunlarının çözülebilmesi şartıyla, her hata raporunun mevcut günlüğün eklenmesini gerektiren yalnızca yazılı iletişimi garanti etmekle kalmaz, aynı zamanda kullanıcının gerçekte ne yaptığını da söyler (yapmaya çalıştıklarını düşündüklerinin aksine) .

Hataların iletişimini teşvik etmenin yolu, özelliklerin sık ve ayrıntılı iletişimini teşvik etmektir. Sıfır törenle herhangi bir şey isteyebilecekleri bir şirketi eğitirseniz, bu özelliği küçük hatalar için de kullanırlar. Bu değişiklikler hayatlarını kolaylaştırmadıkça müşterinizin iş akışında değişiklik yapmayı bırakın.

Müşterinizin şirket içi test yapmasını sağlamak zordur, ancak hataları gerçekten bildirmelerini sağlamak göründüğü kadar zor değildir. Daha fazla geri bildirim almanın yolu, kullanıcı sürtünmesini azaltmaktır ... bu sürtünmenin bir kısmını kendinize aktarmak anlamına gelse bile.

1. Bu araçlar yetersiz ve uygunsuz olsa bile daha basit araçlar kullanın. Örneğin, BaseCamp oldukça korkunç bir hata izleyicidir (çünkü proje yönetimi için tasarlanmıştır), ancak insanlar aslında bunu kullanmaya istekli.

2. Kullandığımız hata izleyicileri görüntü kopyalama-yapıştırma özelliğini desteklemediğinden, aslında geçerli pano görüntüsünü diske (Guid olarak) kopyalayan, ardından Guid'i panoya kopyalayan önemsiz bir program yazdım. Minimum eğitimden sonra, kullanıcı baskı ekranına basarak, bir düğmeyi tıklatarak ve ardından hata gönderme aracının dosya seçici iletişim kutusuna yapıştırarak pano görüntülerini sorunlara ekleyebilir.

Bir ekran görüntüsü (muhtemelen MS Paint'te ek açıklamalarla düzenlenmiştir) ve 1-2 cümle çoğu özelliği / hatayı tespit etmek için yeterlidir.

Bu önerilerden ikisi sürtünme noktaları hedefliyoruz ben deneyimli ve bu önerilerin her ikisi Ancak fazla 10 faktöre göre raporlama arttı, kendi sürtünme noktaları hedef gerekecektir.

Müşterinizin testini kolaylaştırın, ancak müşterinizin üretimdeki denenmemiş bir sürümdeki yeni özellikleri kullanmasını gerçekten zorlaştırın. Bu, aşağıdaki gibi gerçekleştirilebilir:

Yeni bir özellik sunduğunuzda, bunu ilk olarak "üretim için değil" işaretiyle açıkça işaretlenmiş bir "beta sürümünde" uygularsınız. Bu beta sürümünü istemcinin sınama için hazır hale getirirsiniz. Ayrıca, gerçek üretim için kullanacağı en yeni "üretim sürümünü" (yeni özellikler olmadan, ancak en son hata düzeltmeleriyle birlikte) sağlarsınız ve birisinin geri bildirimini alana kadar yeni beta özelliklerini üretim sürümüne aktarmayı reddedersiniz. müşteri tarafı en azından önce denedi.

İstemci, beta sürümünü gerçek üretim verilerinde kullanmaya başlarsa da, programı her başlattığında her zaman büyük bir "Üretim kullanımı için değil" mesajı gösterirse, ona yardım edemezsiniz, ama en azından üretimi kaybettiğinde çünkü beta'yı yanlış bir amaç için kullandı. İstemci bundan bir şey öğrenmezse, sonuçları gerekirse "beta" da diske kaydetmek gibi bazı önemli işlevleri devre dışı bırakarak istemcinizin üretimdeki "beta" özelliğini kullanma özelliğini devre dışı bırakmayı düşünebilirsiniz.

Ayrı bir "beta" sağlamak sizi uygun sürüm kontrolü / yapılandırma yönetimi kurmaya zorlar, böylece bir üretim dalını ve bir beta test dalını sorunsuz bir şekilde yan yana yönetebilirsiniz. Ancak Github ile çalıştığınız için, sanırım GIT gibi bir şey kullanıyorsunuz, bu da bu tür bir yönetimi çok basit hale getiriyor.