Hata izlemeyi programcılar ve teknik olmayan personel için uygun bir şekilde nasıl ele alırsınız? [kapalı]

Aslında Mantis'i projelerimiz için kullanıyoruz. Yoksa "kullanmaya çalışıyoruz" demeliyim. Bildiğim tüm hata izleyicilerindeki sorun, programcılar tarafından programcılar için yapıldığıdır. Yani tasarım mevcut değil veya tamamen saçma.

Tabii ki, bir programcı olarak, mantis'i sorunsuz bir şekilde kullanabilirim, ancak bir projede yer alan tüm insanlar onları o kadar kötü tasarlanmış ve kullanmak o kadar zor bulduklarında bir hata izleyici ne kadar yararlıdır? buldukları hata veya öneri olabilir.

Bir forum yüklemek üzereyim, bana bir hata izleyici ve düz madde işareti listesi arasında "ortada" bir çözüm gibi görünüyor. En azından bir forum, bir öneri hakkındaki tartışmayı izlemeye ve merkezileştirmeye izin verir.

Endişem net değilse, sorum şu şekilde özetlenebilir:

Teknik olmayan kullanıcıya yönelik hata ve öneri raporunuzu nasıl ele alıyorsunuz?

** İlgili olarak, gerçek müşteri veya son kullanıcı demek ETMİYORUM. Entegratörümüzü, proje yöneticilerimizi ve KG ile ilgilenenler hakkında düşünüyorum.

Bu yılın başlarında Mantis'ten FogBugz'a (ve Fırın) geçtik, ancak değiştirmediğimiz tek şey, "kullanıcıların" hata izleyiciye erişmesine izin vermememizdi. Diğer bölüm başkanlarının bazıları salt okunur erişime sahiptir, ancak dürüst olmak gerekirse yöneticilerdir ve genellikle birkaç hafta içinde unuturlar. Yazılımımızın kullanıcıları, bir yapılandırma sorunu, kullanıcı hatası veya bir yazılım hatası olup olmadığını belirleyen tek bir sorun giderme adamıyla ilgilenir. Bu kişi daha sonra gerçek sorunları FogBugz'a girmek için kapı bekçisi olarak hareket eder. Bu, sistemimizin gerçekten alakalı olmayan sorunlarla karıştırılmasını önler.

Yani gerçek sorunuzu cevaplamak .... bizim için gerçekten bir sorun değil, hata izleme yazılımı "programcılar tarafından", "programcılar için" çünkü sadece "programcılar" bunu kullanır. Diğer herkes doğrudan bir insanla ilgilenir.

(Ürünümüzün büzülme olmadığını ve tüm kullanıcılarımızın doğrudan çalışan olduğunu veya servis departmanındaki bir çalışanla çalıştığını unutmayın.)

Bu tür şeyler için redmin kullanıyoruz . Anahtar hile kullanıcılarının büyük bir kısmı asla bkz onlar sadece support@example.com e-posta göndermek - redmine. Birkaç ileri hile kullanarak - özellikle de redmine hesabımızı BCCing ve # sayısını da dahil ederek - güncellemelerin redmine geçmesini sağlayabiliriz. Daha ileri düzey insanlar için, sadece MANTIS'ten biraz daha modern ve kullanıcı dostu olduğu için doğrudan redmin kullanmalarına izin veriyoruz.

Şu anda MKS kullanıyoruz. Programcı olmayanlar için, bazı raporlar ve ilgilendikleri özetler içeren bir pano oluşturdum. Bu, ilk kurulumu yapmak zorunda olduğum anlamına geliyor, ancak kusurların ilerlemesini ve genel özeti izleyebildikleri anlamına geliyor. verileri raporlara ve gösterge tablolarına nasıl erişeceklerini gösterdikten sonra. Ayrıca biletlerini değiştirmek için biraz eğitime ihtiyaçları vardı, ancak her zaman biraz ek yük olacak. Neyse ki, ilgili özelliklerle orantılıydı.

Redmine'i ikinci olarak kullanıyorum ve kişisel olarak The Bug Genie (evet, sevimsiz isim, ancak iyi tasarlanmış; PHP ortamındaysanız ve / veya Ruby'yi herhangi bir nedenden dolayı çalıştıramazsanız) teknoloji kullanıcıları.

Bunun yanı sıra, anahtarlardan biri, son kullanıcıların varsayılan olarak koyduklarından daha fazla sorun görmemeleri gerektiğidir (isteğe bağlı olarak, yinelenen biletlerden kaçınmak için arama yeteneğine sahip olabilirsiniz, ancak bu ihtiyaçlarınıza ve kurulumunuza bağlıdır). Tüm sorunların görülmesi arayüzün dağınıklığına neden olacak ve son kullanıcının kafasını karıştıracaktır. Kullanıcılar genel olarak yalnızca görmek istediklerini görmelidir, bu nedenle proje yöneticileri yalnızca kontrol ettikleri projelerle ilgili sorunları görebilir. Diğerlerinin de belirttiği gibi, son kullanıcılar için bilet ibrazını ne kadar basit yaparsanız o kadar iyi olur. İzleyicinin kullanıcı arayüzünü bile gerektirmeyen bilet gönderiminiz varsa bonus puanlar (e-posta yoluyla veya yalnızca bilet göndermek için gerekli alanları içeren basit bir form aracılığıyla).

Daha önce Team Systems olarak bilinen "Visual Studio'nun Uygulama Yaşam Döngüsü Yönetimi özelliklerini" kullanıyoruz. Bizim için büyük bir avantaj, bir sorgu sonucunu ("tüm gereksinimler" veya "bir sonraki sürümde olmayacak pri 2 veya daha düşük tüm hataları" gibi) bir e-tabloya veya Proje belgesine aktarabilmenizdir. Proje yöneticileri, son kullanıcı temsilcileri, paydaşlar vb. Bu dosyaları düzenleyebilir - önceliği değiştirmek, açıklamaları güncellemek, başkasına atamak, ne olursa olsun - ve dosya TFS'ye bağlı bir makineye geri döndüğünde, Yayınla ve değişiklikler depoya geri döner. Programcılar iş öğeleriyle doğrudan Visual Studio'dan çalışır, ancak programcı olmayanlar hiçbir zaman VS'nin yanına gitmez. Ayrıca her TFS projesi için bir paylaşım noktası sitesi var.

Belki bir VS dükkan değilseniz bir seçenek değil, ama olup olmadığını düşünmeye değer.

KG / PM personeli ile konuşuyorsanız, çeşitli açık ve kapalı kaynak izleme araçlarını değerlendirmeniz gerekir. Yapılar, vb. Ayarlama yeteneğine sahip olanlar iyidir, böylece KG / PM çalışanları belirli bir yapıya karşı bilet koyabilir ve bir sorunu düzelttiğinizde hangi yapıyı test edeceğini bilebilirler.

Kullandığım çoğu uygun araç aslında programcı olmayanlar için programcılardan daha ayarlıdır. StarTeam benim için oldukça iyi çalışan biriydi, ama hala etrafta olup olmadığını bilmiyorum. İsterseniz alanları özelleştirebilirsiniz. Sadece bununla denize düşmediklerinden emin ol.

Son kullanıcılar hakkında konuşuyorsanız, yardım masası yazılımına bakmanız ve ardından yardım masası personelinizin gerektiğinde hata aracına yükselmesini sağlamanız gerekir.